2 Approaches to Video Streaming Redundancy: CDN vs XDN

webrtc streaming
SHARE

Your live streaming app is all set. It’s fully scalable and has all sorts of built-in security and custom features. All set and ready to go. Right? Maaaaybe not quite. What happens when one of your servers goes down? If you’re using a cloud-based hosting architecture, you can spin up a new server. However, those… Continue reading 2 Approaches to Video Streaming Redundancy: CDN vs XDN


Your live streaming app is all set. It’s fully scalable and has all sorts of built-in security and custom features. All set and ready to go. Right?

Maaaaybe not quite. What happens when one of your servers goes down? If you’re using a cloud-based hosting architecture, you can spin up a new server. However, those users connected to the crashed server will have to wait for the system to finish setting up that new instance which could be a matter of minutes. With a live streaming event or conference, this could mean missing a minute or two of the live stream which could be a big issue.

Of course, if you are using your own bare metal servers, you’d better have a backup server available.

This is why redundancy is so important. You need back-up servers so dropped connections can be quickly reestablished with minimal downtime in case of an unforeseen outage. You also need a way to manage all those connections and make sure that any dropped connections will be rerouted.


How CDNs Create Redundancy

Content delivery networks (CDNs) are commonly used to deliver live streaming video. Built on an HTTP architecture, a CDN is a group of point of presence (PoP) servers distributed around the world that allows streaming providers to host media files near the physical location of end users. (Of course, HTTP protocols such as HLS and DASH along with efforts to improve the latency like CMAF and LLHLS will never be fast enough for real-time live streaming as discussed elsewhere on our blog.)

CDNs have agreements with other CDNs to provide redundancy in case something goes wrong with one of the providers. When building an application, it may not be clear exactly how your CDN provider has everything set up.

This lack of transparency can be unsettling as you are essentially placing all your trust into assuming that the CDN will just work. It might not be clear how your streams will perform on the secondary networks that your main CDN provider employs. Most CDN providers try to lock you into their platform, so if your provider changes their pricing or just doesn’t work for you, switching over to another provider is usually development intensive and very costly.

Such concerns might encourage you to build your own multi-CDN approach. However, configuring and managing each CDN and integrating the corresponding APIs of each platform to work together can also be a costly process. Of course, once created, you will still lack a centralized API for all the different CDN providers which, in turn, could create complications from managing different systems.


Using a Flexible XDN

An experience delivery network (XDN) is the next milestone in the live streaming industry. Rather than trying to improve the outdated, HTTP-based CDN model, XDN uses the modern web standards–based WebRTC protocol to deliver live streams with under 500 milliseconds of latency.

Similar to the multi-CDN approach, an XDN uses a series of cloud servers configured in clusters to distribute live streams. Each cluster consists of three types of server nodes with different roles: edge, origin, and relay. The edge nodes are used for egress while origin nodes are used for ingest.  To scale, the origin can connect to multiple edges to support thousands of users. Relay nodes are used for larger deployments to scale the cluster by receiving stream(s) from the origin(s) and relay it to multiple edges, allowing it to support millions of users.

Building an XDN with Red5 Pro involves using the Red5 Pro stream manager to organize a network of infrastructure-as-a-service (IaaS) cloud operators. To create the highest degree of flexibility, Red5 Pro is hosting agnostic and supports both the major cloud operators — AWS, Google Cloud Platform, and Microsoft Azure — as well as lesser known providers such as DigitalOcean.

Furthermore, Red5 Pro is fully integrated with the Terraform cloud controller to support any of the over 200 platforms using Terraform and can be extended to include private networks. This large base of cloud options reenforces the reliability of your live streaming. The stream manager provides an API that centralizes the integration of the various IaaS operators. Thus it avoids the CDN problem of managing disparate APIs.

Using the same system of edge, origin, and relay nodes, the stream manager monitors the network traffic in real time, automatically spinning up and spinning down nodes as needed. Each node in the system can be deployed on a relatively low-powered, cloud-based virtual machine that achieves high availability by scaling horizontally without using expensive, highly performant machines.

A Red5 Pro–based XDN can be controlled by one or more sets of stream managers deployed on one or more platforms. As long as the stream managers share the same database, all of them will be aware of the state of the whole network. Moreover, if a stream manager goes down, others can temporarily handle its requests while a new one is spun up. To ensure that the system is always available, the database deployment uses a replication strategy to avoid any data loss or a single point of failure.

With these attributes in place to support automatic scaling, Red5 Pro is well suited to support the automated redundancy that’s essential to fail-safe operations and video stream redundancy. With persistent performance monitoring of all engaged resources, the platform can instantaneously shift processing from a malfunctioning component within a node to another appliance in that node or, in the event of the entire node going offline, move the processing to another node with no disruption to the flow or increase in latency.


Load Balancing

Software-based load balancing maintains reliable performance by safeguarding against usage spikes crashing a server. In the event of server instability or failure, load balancing can act as a failover measure to assure website availability. If a server goes down, the load balancer can immediately redistribute traffic to the remaining stable servers, preventing a service outage and increasing reliability.

With a Red5 Pro–based XDN, the stream manager is designed to distribute the streaming load to the different Red5 Pro nodes in the cluster which ensures consistent and even performance. In this way it acts as a load balancer. Of course, CDNs use load balancing as well.

Creating video stream redundancy is an essential part of building a successful live streaming application that not just works well but works well consistently. As we all know too well, tech is often subject to unanticipated failures, so ensuring that you have redundant and reliable systems in place is essential.

Want to create your own fail-safe, real-time latency, XDN-based streaming app? Send an email to info@red5.net or schedule a call. We’d love to show you what we can do.