Cloud Broadcasting - Integration

Broadcast engineers have a whole plethora of tools available in their kit-bag to integrate systems. The common denominators are SDI, AES and MADI for media exchange, serial and ethernet protocols for control, and the trusted GPI should everything else fail.

Third party vendors provide specialized operational control panels for “VT”, video and audio servers and even red tally lights. Products exist allowing us to route controls into one unit, detect a vision switcher and audio desk routings, determine which camera and microphone is on-air, and send a tally signal or perform routing in a matrix.

Cloud broadcasting does not have any useable serial ports or GPI’s. SaaS systems are generally closed and don’t take too kindly to be controlled by some esoteric system designed by a broadcast engineer to circumnavigate a complex workflow.

No GPI's in the Cloud

There are two challenges to overcome; firstly, the only Cloud connection we have is through the internet, and secondly, SaaS Cloud systems are generally web-apps and are not accustomed to being controlled by a VT control panel and jog wheel. There are no GPI’s, or Sony RS422 connections in the Cloud.

There are ways to control SaaS services but we must think like an Enterprise Software Developer and use protocols more akin to online banking and commerce.

To leverage the power of public and private Cloud computing, software providers must adopt the web server-client model. A web server sits behind a load-balancer in a Cloud datacenter and processes HTTP (Hyper Text Transfer Protocol) messages from a browser on the user’s computer. HTTP messages are divided and split between several IP packets, and in turn the IP packets are usually encapsulated by ethernet packets. Whether ethernet encapsulation is used or something like ATM depends on the underlying network.

Access to cloud webservers is achieved using HTTP commands over IP/Ethernet.

Access to cloud webservers is achieved using HTTP commands over IP/Ethernet.

An HTTP message representing the user input is sent to the web-server, this is processed and the result is sent back to the user’s browser.

Web-server applications such as SaaS are fundamentally different from broadcast applications as they are stateless operations. In other words, when a browser sends an HTTP message, the web-server processes that message, creates a result and sends it back to the browser, but doesn’t retain any information about that request. In effect, the web-server treats each request individually.

Cookies Identify You

Websites need to store information about the user for authenticated secure sites, that is, sites you need to supply a username and password to log into. This is also referred to as “stateful” information. Stateless and stateful systems are mutually exclusive so cookies are used to store stateful information on the users’ computer.

When a user log’s onto a website with a username and password, the website will create a random sequence of characters compliant with HTTP and unique to that user, store them in its database, and send them to the users’ computer. The sequence is stored in the users’ computer memory for session cookies, or on the hard disk drive if the cookie is persistent. 

Persistent Cookies Never Expire

Each time the user sends a request to the web server it must include this session ID. When received, the web server looks up the session ID in its database so it knows which user made the request, and sends back a response based on the user-attributes.

Cookies can expire depending on the configuration of the web-server and the application being run. Session cookies tend to expire when the browser application is closed, but persistent cookies expiration time is set by the browser when the ID is first requested. The expiration date can be anywhere from a few minutes to many years.

Webservers use cookies to identify users

Webservers use cookies to identify users

Representational State Transfer (REST) web services are a way of integrating data between Cloud services through an Application Programming Interface (API). REST was developed by Roy Fielding as part of his 2000 PhD dissertation, and is a formalization of HTTP commands to exchange data, embracing the design philosophy of performance, scalability, simplicity, modifiability, visibility, portability and reliability.

REST is Stateless

At the core of REST is the assumption that we are using the stateless client-server computer model with HTTP. RESTful API’s are used to exchange data in the client server model using four different commands; GET, PUT, POST and DELETE. They vary in how much they affect the data within a web server; a system in computer science called side effects.

Understanding the REST commands is key for any broadcast engineer looking to fault find and log events within a network. The system relies on the client sending a request command to the server for some specific data. For example, a web browser will often send “GET /” to request the homepage of a website from a server.

GET is the safest of all four commands and is both safe and has no side effects. Continually sending a GET command to a web server will not change any data in the web server. This command could be used to get the status of a server, or retrieve the homepage.

Beware of Multiple Triggers

PUT is not safe but is idempotent. In computer science, idempotent describes an event that will give the same result if executed once or multiple times. This will stop multiple triggering of an event or continuous updating of data in the web server. It’s not safe because it has side effects, sending it will change a data value or parameter within the web server or database, but only once.

POST is not safe and is not idempotent. Sending a POST command multiple times will trigger the event the same amount of times in the web server. Like PUT, it’s not safe because it has side effects; some data within the server domain is changing. If we POST a “cue playout”” command and then send it five times, the media will recue five times, even if it is already playing. The developer needs to protect against this.

DELETE is not safe but it is idempotent. Like PUT it will change data, but only once.

We're in the Hands of Developers

Adherence to this system is entirely at the hands of the developers and assumes they both understand the subtle differences between the commands and have programmed accordingly.

As we move into private and public cloud systems, broadcasters must adhere to philosophies such as REST to leverage the cost savings within IT systems. The efficiencies of cloud computing rely on all parties speaking the same language, otherwise we create complexity, which will increase costs and decrease reliability.

Let us know what you think…

Log-in or Register for free to post comments…

You might also like...

CTA and NAB Jointly Promote ATSC 3.0 “Living Lab”

Two years ago proponents of ATSC 3.0 began looking for a facility to host the testing of the country’s next-generation TV broadcasting standard. Similar to the early days of digital broadcasting—when the 8-VSB modulation scheme was being considered for use…

BCE - Going Deeper - Choosing Routers

At the start of 2013, BCE at RTL City was a hole in Luxembourg’s ground and in less than four years they were on air broadcasting 35 different channels across Europe and Singapore. Costas Colombus is BCE’s Special Projects Manager and…

Articles You May Have Missed – November 1, 2017

Despite the rapid expansion of live streaming, CDNs have yet to reliably deliver on the many promises they made about IP streaming. The recent pay-per-view boxing match between Mayweather-McGregor demonstrated just how difficult it can be for CDNs to transport…

Cloud Broadcasting - Free Software

As well as providing functionality, tangible products present the opportunity of adding worth through their aesthetic appearance, cost of manufacture and development expenditure adds to the perceived barrier to entry for other vendors, and combined with low volumes, the cost…

BCE Going Deeper - Part 1 - Cable, Standards and ITIL

At the start of 2013, BCE at RTL City was a hole in Luxembourg’s ground and in less than four years they were on air broadcasting 35 different channels across Europe and Singapore. Costas Colombus is BCE’s Special Projects Manager and…