Building the Theta Protocol: Part II
Overview of the Hybrid Mesh Streaming Technology
By Jieyi Long, CTO Theta Labs
In this blog post I’ll provide an overview of the hybrid mesh streaming technology we’ve been working on. Hybrid mesh streaming utilizes both peer-to-peer and content delivery network (CDN) for video delivery, and thus combines the advantages of both worlds, namely high scalability of the peer-to-peer approach with the high availability of CDN delivery. Our in-progress development shows that the hybrid mesh streaming technology results in significant CDN bandwidth usage reduction in a sandbox environment.
Peer-to-peer streaming focuses on timely delivery of audio and video content under strict, near real-time parameters. Peer-to-peer livestream delivery works best when many people tune in for the same stream at the same time. High concurrent user count means more peering resources are available, and thus the peer nodes can pull the stream from each other more effectively. The whole system capacity increases as more peer nodes become available. Moreover, robustness of the system is increased in a peer-to-peer network, as nodes do not need to rely on a centralized server to retrieve content. This point is especially important in cases of server failure. In contrast, for centralized CDN-based delivery, high concurrent users instead places scalability pressures on the CDN servers.
However, the shortcoming of pure peer-to-peer streaming is availability. Peers may come and go anytime, which makes it difficult to predict the availability of any given peer node. There are also uncontrollable differences of nodes, such as upload and download capacities. On the other hand, CDN service is more reliable and robust, and hence it can serve as a reliable “backup” when the stream is not available from peer nodes.
Our goal is to achieve maximum CDN bandwidth reduction without sacrificing the quality-of-service (QoS) which is critical to established streaming platforms such as Netflix, YouTube, Twitch, Facebook and others. This means whenever possible we want the peer nodes to pull the stream from each other instead of from the CDN. To achieve this goal, it’s crucial for the peer nodes to be able to identify neighboring nodes effectively. If a node can identify multiple peers in close proximity, chances are that it can find peers that can provide the video stream segments much more consistently. On the contrary, if the identified peers are further away (in terms of network hops), the node might not be able to pull stream from peers consistently causing a bad user experience like stuttering, frequent rebuffering, etc.
To address this problem, Theta has designed and currently implementing a strategy which combines both a hyper-optimized tracker server and player client-side intelligence. Essentially, the tracker server provides high level guidance (e.g. a list of candidate peers) for the player client, while the player client implements a peer filtering algorithm at a finer granularity based on multiple variables to find the neighboring nodes that can best serve them.
Hyper-optimized Tracker Server
In order to provide a list of candidate peer nodes to each client, the tracker server records the location information whenever a peer joins the network, including its IP address, latitude/longitude, a number of other performance parameters. With this information the server can organize the nodes in a spatial database. Theta’s “hyper-optimized” spatial database is optimized for storing and querying data that represents objects defined in geometric space. As a peer node joins the network, the server can perform a spatial query to retrieve a list of candidate peers that are in the close proximity very quickly and efficiently. The tracker servers and the spatial databases can be maintained by video streaming sites that use the Theta network and/or by community peers for content delivery.
As we mentioned earlier, a peer node might leave the network anytime. Hence the tracker server also needs to be aware of which nodes are active. To achieve this, an active peer node needs to maintain a socket connection with the server and send heartbeat signals consistently. If the server doesn’t receive a heartbeat for a certain amount of time, it considers that peer node as having left the network, and updates the spatial database accordingly.
An important distinction is that the “distance” between two peer nodes is measured by the number of router hops between them rather than the geographical distance. Typically network distance and geographical distance are highly correlated, but aren’t necessarily equivalent. For example, two computers could sit next to each other physically, but connect to different ISPs so there might be many hops between them. Hence, aside from geographical information, the tracker server also utilizes the connectivity between the IP addresses collected in the past to analyze and select neighbor candidates. For example, candidates returned by the spatial query can go through another filter to exclude those that are not connected to the same ISP as the viewer’s.
Intelligent Player Client
Each peer node may act both as a viewer, a caching node or both. As the node launches, during the handshake step, it retrieves a list of candidate peers from the tracker server for the livestream it’s playing. Then, it performs a speed and availability test to select a subset that has optimized performance, connectivity and can reliably provide the video stream segments. The client performs the speed and availability tests regularly during a live stream session and continuously refines its neighbor list.
To avoid QoS degradation, local buffer management is critical. The client player maintains a local cache to buffer the downloaded stream data. If the duration of the cached stream data is less than a certain threshold, the player checks with the neighboring peers to see if they have the desired video stream segment. In the event when none of the neighbors has that segment, the play intelligently falls back to the CDN. To achieve the best QoS possible, the player fetches an updated candidate list from the tracker server on a regular basis during the stream session.
The first version of the client video player will be a web/HTML5 based player which employs the WebRTC protocol for stream delivery among peers. Deploying web-based players requires minimal effort. Streaming sites and platforms simply embed the player onto their webpages, and it instantly has access and “launches” millions of end user nodes in the mesh network. Thus the deployment of Theta’s mesh streaming technology is very light-weight and frictionless.
Theta also plans to release desktop and mobile client support. The advantage of a desktop client app over the web/HTML5 player is that it can run in the background to facilitate video stream relay (with the consent of the user) even when the end user is not watching any video streams. Further, Theta is investigating dedicated hardware, IOT devices and related approaches that are specifically designed for stream relay and re-broadcast. Such devices can provide potentially better availability and bandwidth.
In summary, I hope I’ve been able to give you some insights into Theta’s hybrid mesh streaming technology. In subsequent posts, we’ll dive into the interaction between the peering nodes and our “purpose-built” video streaming blockchain, and how the peer nodes can transparently and efficiently receive token rewards by providing the stream relay services to other nodes. Stay tuned for more!
