Table of Contents
CDN or Content Distribution Networks are used to improve user experience and for the users to achieve efficiency in their network resource utilization. CDN or ECDN (Enterprise Content Distribution Networks) are a globally distributed network of servers deployed for the purpose of faster content delivery by replicating the digital content across all the servers in the ECDN. The digital content is then made available in many places all at once and when a user accesses it, the content from the nearest server is delivered or served to the user.
Without the ECDN, conventionally deployed single servers are a cause of network congestion and delayed delivery due to sudden and numerous requests from the users when they all try to access the same content at the same time.
VIDIZMO uses the ECDN to distribute Live as well as On-Demand video content. It is important to mention here that VIDIZMO ECDN caches and locally serves only those files that can be published in the VIDIZMO application.
ECDN is used for the scalability of digital content whether it is in the form of a binary file, software update, images, videos or just static content. For example, you are delivering a software update to thousands of geographically dispersed users at the same time. If this is done using a single server, without any ECDN, imagine the resources required by the server, bandwidth consumption challenges faced and the time it will take to complete the task. When using ECDN, the same task can be completed a lot quicker and with lesser resources.
ECDN use servers deployed at different geographical locations where enterprises expect the highest levels of traffic, to serve content. On a high level, following are the steps involved in the way ECDN works:
- Data is uploaded to the Origin Server
- An identical copy of data is placed on each Edge Server and cached there for serving
- User requests a file
- ECDN intelligently routes the user to the geographically closest streaming server
- The file is served to the user
In VIDIZMO, the ECDN is a complete Add-on Solution comprising of different components consisting of ECDN Management, an Origin Server and Edge Servers.
This module, installed centrally, is VIDIZMO platform's built-in module which contains the Location Management and Streaming Server Management. Streaming Servers can either be Origin or Edge type Servers and are described below.
VIDIZMO ECDN Management is where Edge nodes are setup from the application. ECDN in VIDIZMO is setup by associating it with a location so that when users come from a specific location, they get served by that ECDN Node being setup. Thus the location, which is bound to a Subnet, helps the ECDN to interpret the user's IP dynamically and figure out the location to serve the content.
To learn more on how Locations are setup in VIDIZMO, click here on How to Setup Locations.
Click here to learn more on How To Setup VIDIZMO ECDN.
Click here on How VIDIZMO ECDN Provides Fallback During Live Streaming for more details on how locations are used to reroute the user to capture the nearest stream.
Origin server are the main servers deployed for the purpose of serving Live or On-Demand digital content. For scale and resilience, a number of Origin Servers can be deployed, each configured to run as a Live Origin server or for On-Demand content delivery. Click on Using ECDN for Live Streaming over Intranet / WAN section to learn more on the number of ways Live and On-Demand Origin Servers work.
Edge nodes are the interface between the Origin Server and the outside network. These Edge Nodes provide data to caches, and are deployed in a hierarchy to allow tiered caching.
VIDIZMO Edge Nodes can be configured to serve on the basis of user's geographical location, thus making content available from the servers that fall within their proximity. Some of the key benefits to such a deployment include:
- User proximity allows greater response and latency time.
- Allows increased download speeds and less likelihood of errors over shorter distance, thus providing file integrity.
With Multiple locations, there is less likelihood of bandwidth congestion from multiple requests.
In VIDIZMO, Streaming Servers communicate about their health with the main Application Server to let it know whether they are in a healthy state or not. When ECDN is created, a Heart-line shaped health indicator is displayed next to it on the screen where ECDN are listed in the main VIDIZMO application. This feature is only used in combination with the VIDIZMO player and the VIDIZMO Streaming Server and works in two ways:
1. If the server is healthy and based upon the server health, it checks whether the publishing point can be setup or not.
2. If the checkbox "Accessible to VIDIZMO" is selected, it will allow access to streaming servers which are behind a firewall.
The VIDIZMO player also takes the health of the Server into consideration while searching for a connection with one of the Edge Nodes and it will not attempt to connect if the Server is not healthy. This health status is monitored by a service being run in the Streaming Server, which checks with the main Application Server whether a response is received or not. The service sends a request at predefined intervals and keeps checking for a response. On the other hand, the main Application Server has a response threshold within which the Streaming Server needs to connect, failing which the main Server considers the Streaming Server to be unavailable i.e. dead. Appropriate measures are then taken to find out what caused the server to be unavailable.
As shown in the image below:
1. A green Heart-line icon indicates a Healthy Server, with the mouse-over Alt text displaying "Server is Healthy", and
2. A Grey Heart-line icon indicates "Server is not Healthy"
VIDIZMO ECDN is intelligently configured to identify user's geographical proximity and based upon that, the ECDN re-routes the user to the nearest server. Behind this intelligence is the the Domain Name Routing, which can be implemented in two ways:
One of the ways is to detect the IP using Dynamic DNS which helps the ECDN to interpret the IP dynamically to find out where the user is coming from. As soon as a user sends a request for content, the Edge Node re-directs it to the Node closest to the user's proximity. Take an example where, for the same Domain name i.e. www.google.com, a user in the South America gets a different IP than the user in North America because the DNS looks for the user's location, where the request originated.
Enterprises serve their global customers by deploying data centers in different locations so that if user is coming from location-A, he will get IP of the Data Center in location-A and if the user is coming from location B, the IP of will be of the Data Center in location-B and so on but the domain name remains the same.
The second method involves dynamically changing the URL so that when a user connects to a domain, the URL of the domain is fetched based upon the proximity of the user. To identify on which Edge Server to land the request on, enterprises deploy data caching appliances all over the world, either in conjunction with local ISPs or by using customer's own appliances in the region, in order to serve the content from the closest server to the user. In either case, the URL that gets displayed is of the geographical location of the server from where the content is being served. For example, users coming to www.google.com from France will see www.google.com.fr while those from Australia hitting the same Google URL will be re-directed to www.google.com.au.
VIDIZMO Streaming Servers use the Dynamic URL method to identify where the user request originated from and connects the user to the closest Edge Node.
VIDIZMO focuses mainly upon the Video technology and comes across many challenges when it comes to handling Streaming Protocols. VIDIZMO ECDN handles these challenges effectively for customers who use RTMP for streaming or those customers who prefer to stream using HTTP.
The difference between RTMP and HTTP streaming is that in RMTP, the stream is in real time, while in HTTP the content first downloads, then it is served and then played in the form of a file.
The Real Time Messaging Protocol (RTMP) is a low-latency streaming protocol used by Flash Player to play on-demand and live streams. RTMP maintains persistent connections, enabling audio, video, and data to move between the VIDIZMO and a Flash client. VIDIZMO Streaming Servers are capable of taking RTMP input as well as serve it and since the stream need to be pushed, it has to be available beforehand on the Edge Servers to be served.
For enterprises who have a large number of Edge Servers deployed across multiple locations, using a single encoder to push the RTMP stream on all the edge servers would seem improbable, requiring considerable resources. One solution would be to use two Origin servers to push the stream and also configure them in such a way that when you push to one Edge, the stream trickles down to others.
The other way would be to use VIDIZMO Streaming Servers since theyare already configured to take the Origin’s stream and replicate it automatically on the other Edge Servers.
HTTP does not stream in real time and this protocol is in existence since the web was created. Since it is a part of the Open Consortium, it has matured considerably which is why people have started using this for everything, even for streaming.
HTTP streams use file based streaming and run On-Demand, where a request is first received, and if the content is not previously available in the cache, the request goes to the Origin Server and downloads on the Edge Server to serve the stream. The Edge Server also caches the content so that when a user requests the same content, it quickly becomes available to the user.
HTTP Streaming is also referred to as Adoptive Streaming, using the popular protocols like MPEG Dash, Smooth, HLS/HDS to stream. DASH is an industry-standard format for Dynamic Adaptive Streaming over HTTP (DASH). Unlike Live Streaming where the stream is continuous, in Adoptive Streaming using MPEG Dash, the file is written in small chunks and as soon a connection opens, those small chunks get downloaded.
Some other factors over which HTTP has an edge over RTMP is that RTMP cannot be cached and since it not text based, you cannot apply rules on it. Also, unlike HTTP, RTMP requires a separate port.
On a local network comprising of a multi-tiered streaming servers, VIDIZMO provides its own CDN to the customers and, by incorporating a fallback methodology, ensures an uninterrupted streaming experience to customers. Here are some scenarios where the multi-tiered streaming servers can be setup:
- Standalone VIDIZMO Streaming Server or Standards based Streaming Server
- VIDIZMO ECDN with VIDIZMO Streaming Server Edge Nodes
- VIDIZMO ECDN with HTTP Caching Proxy Edge Nodes
- VIDIZMO ECDN with Wowza Streaming Engine Edge Nodes
- VIDIZMO ECDN with Windows Media Server for Multicasting
- VIDIZMO ECDN with Standards based Streaming Servers
To learn more about multi-tiered streaming servers can be setup, click here on Understanding Live Streaming in VIDIZMO.
In order to provide an optimum Live Stream experience for a viewer, the Live Stream has to be available as soon as the viewer connects. There may be instances like system failures such as a crash, or communications failures, when the stream may not be able to fulfill this ideal user experience.
VIDIZMO ECDN are intelligently configured to handle such situations by providing failover to the viewer's request using a fallback logic that allows the Edge Node to fallback to other available Nodes in the network. This fallback methodology ensures that the stream is always available to the viewer.
Like other networks, the Edge Nodes in the network can be setup under a tiered hierarchy with each Node acting as a fallback appliance to serve the stream in case a live stream is inaccessible. These Edge Node hierarchies are defined on the basis of IP addresses and Subnets, which help identify all those Nodes that exist on the network.
During a Live Stream, the player sends out a request to search and locate the closest Node, since it is the IP which determines which Node is the closest to the player's IP. When the player does not find the Node or experiences connecting problems, it then goes on to search the available stream in next fallback node.
The progression of the player to search an available stream is described with the help of the diagram below:
When looking for a stream, VIDIZMO player searches for nodes that are associated with the IP that is falling within the player's Subnet. The player intelligently selects the node based upon the IP Subnet that maps to the nearest node in the ECDN. If it does not find any such node, it traverses upwards to the node until that Subnet is found. In this way, the player relies upon the location hierarchy as it is the location that is the point of reference for the player to identify Subnets.
In the same way, the diagram above also shows how the Edge Nodes can be implemented in an hierarchy for the player to fallback upon if a local Edge Node is not found. The benefits of having multiple Edge Nodes on a location is that they can provide load balancing and the cater to multiple Subnets. In this scenario, the physical location remains the same and multiple Edge appliances are deployed.
In the example as shown by the diagram above, the Edge Servers are setup by three locations, having different Subnets, as well as on a nodes in an hierarchy:
- Server #1 (220.127.116.11/24): There are limited users in this location and the Subnet is also different, which is why only one Server is used.
- Server #2 (18.104.22.168/24): Since there are three Subnets running under this Edge Server, and due to redundancy and load balancing, three servers are used, with two in the same network and one in a different network.
- Server #3 (22.214.171.124/24): Due to the number of users in this location, load balancing is achieved using two Servers falling in the same Subnet.
For On-Demand Streaming, behavior of the player is little different as compared to Live Streaming described above. During On-Demand Streaming, instead of coming back to the lowest child node again, the player goes to the Content Provider to play the stream.
Content Provider is essentially an origin where the content is uploaded. To learn more about it, click here on What is a Content Provider.
Subject: Content Server
Action: Content Server (Add/Update/Delete) and must be account not channel