The love and curse of the client-side or how we managed P2P networks to run in iOS Safari
Over time, many Internet applications, such as the streaming industry, have adapted and improved their software, especially on the client-side. This has the advantage that software and services of different kinds happen incredibly close to the client and allow detailed analysis and data collection as well as user-related customization. But selling client-side software has not only advantages. A significant difficulty that arises is the adaptation of the software to almost infinite different devices. Depending on the client’s operating system, browser, version, or device, the software must be adapted and prepared for each of these possibilities. And the list of different use-cases is growing exponentially every day. For instance, a specific software can work flawlessly for a client who uses the latest Chrome browser running on a Microsoft powered device, but not for another client who is using Safari on an iOS device.
Why client-side software can be a problem for content delivery networks
This is often a problem when it comes to providing CDN or eCDN solutions, which are also client-side software and, therefore, have to be kept up to date and adapt to new versions of operating systems and the sheer number of different possibilities and differences at the client-side. The new Chrome-based Microsoft browser “Edge,” released in January 2020, now supports WebRTC – a great innovation that makes it easier for client-side software providers to make their software usable for every customer. In general, eCDN software can also be a WebRTC based software (depending on the provider). However, for various reasons, iOS and the associated browser Safari are still a significant problem for adjusting software the way it works for any client. WebRTC has only been supported by iOS and Safari since 2017, while MEDIA SOURCE EXTENSIONS still cannot be used. It is important to understand that, these extensions are indispensable for integrating the P2P client of browser-based eCDN solutions such as StriveCast Enterprise into the streaming application.
In this article, we’ll explain how we’ve created a very flexible way of building client-side software that covers 95% of all devices out of the box – along with a solution for the remaining 5%.
How to build a plugin that isn’t a plugin
In order to build a P2P network, you need to intercept the player’s connection to its HTTP source. Typically, the player connects to an HLS stream and starts downloading segment by segment, delivered by a eCDN. StriveCast, as a mesh network provider, needs to determine for each video segment if we can actually get it from another peer instead of going back to the eCDN to create a stable streaming structure.
To decide if the user will get the next segment from the source or a peer, we need to gather information about every user to determine which clients can connect with each other. There are different ways to collect this information.You could either build a typical plugin in the form of a code integrated into the player. Or you intercept the user’s data outside of the player, for instance, at the XHR object, which can be understood as a technical communication instance between player and original server. The latter’s advantage is that you don’t have to adapt to every player and continuously update your software because the XHR object remains identical even with different players and versions.
Another way to intercept the user’s HTTP source without building a plugin for the player can be the fetch API. This is actually the same process as mentioned above, but the point to intercept is another. The key is building a plugin for the HTTP interface, not the player. Once enough WebRTC connections are established, the proxies start to fetch video segments from each other instead of from the HTTP origin. This way, only some of the locally running proxies will download the segments from the HTTP origin. Most traffic will occur internally between those proxies. As the name “proxy” suggests, it acts as the same interface to the video player as any standard HTTP interface would, so the entire video delivery process is fully transparent to the player, making the proxy independent from it. So this intercepting method allows us to separate our P2P proxy client from whichever video player (and version) in use, making integration very easy and flexible.
The problems with iOS/Safari and its solution for P2P video streaming
What has been the actual problem with iOS and Safari? Of course, Safari can also play an HLS stream. But the whole thing happens under the hood. Safari doesn’t support the MEDIA SOURCE EXTENSIONS we use in the cases described above. However, these are urgently needed. Basically, they allow interaction with the browser’s media playback system. So it seems that there is no opportunity to influence how exactly the stream is running. Without the MEDIA SOURCE EXTENSIONS, it appears that no user data can be intercepted at the XHR object or the fetch API, and creating a cluster for peer-to-peer streaming is almost impossible. So traffic-saving P2P eCDN solutions could not be provided for Apple products for a long time. But what has changed now?
How to make P2P run in iOS and Safari
Luckily there is another way to intercept HTTP traffic while streaming on an iOS device. Even if iOS restricts the possibilities to make adjustments in the browser’s background to make it perfectly cooperating with your own coding and software, there is a way iOS allows developers to insert some web applications inside of Safari. This standard is called “ServiceWorker.” With these ServiceWorkers, you can implement your own software inside of your browser. The ServiceWorkers only give limited freedom, but it’s enough to make a P2P mesh network possible. We revised our software to make the iOS ServiceWorkers work for us: StriveCast is now supporting traffic interception directly within the website’s context or via the ServiceWorker API. That means that the StriveCast products now support Safari and iOS to increase traffic savings even more. But even if this is really great news, there are still some hurdles to negotiate when using it. To maintain a high-security standard, Safari does not allow foreign software to be integrated into the browser with the help of ServiceWorkers. This is only possible if the software is hosted on the same server as the web page. So the iOS ServiceWorkers only work if they are hosted under the same domain as the main page, meaning that a client running a website needs to host our web SDK on his own servers instead of getting it from our public cloud.
The solution may not be completely perfect yet, but it solves a significant problem that made P2P streaming completely impossible on iOS devices using Safari for a long time. To make the StriveCast P2P-based products work in Safari, and thus on iPhones, iPads, Macbooks and iMacs, a longer integration process is necessary. But once it’s done, this allows larger traffic savings, which promises better quality, shorter loading times, and a great success of your stream.