Showing posts with label http. Show all posts
Showing posts with label http. Show all posts

Tuesday, 26 April 2011

New transport protocols for a better user experience

In the 1980s the telecom industry decided they needed a “broadband standards” and started defining some protocols under the project name “Asynchronous Transfer Mode”. Today people know ATM for something completely different because the project, which actually led to significant deployment in the telecom gears of various countries, came to a stop because of a competing technology called Internet Protocol.
A decade later IP, that did not require an access speed of 155 Mbit/s like ATM, started being deployed with a bitrate that on average did not even reach 3 orders of magnitude less the ATM’s. IP seemed to provide the level of speed that could make customers happy keeping the Plain Old Telephone System (POTS) in place while ATM required reaching millions of subscribers homes with optical fibers.

No one can blame telcos for trying to save trillions of dollars of optical fibers for the less costly Asymmetric Digital Subscriber Line (ADSL). The reality, though, is that our society is more and more video dependent but the fixed telecommunication infrastructure cannot provide the bandwidth that its users require. A lot of talk is being made these days around the “Next Generation Network” (NGN) acronym and, in due time, something is bound to come out, but very little prospects exist for the mobile network which is squeezed between a terrestrial broadcasting industry that sticks to its Ultra High Frequency (UHF) legacy while the need to carry video on mobile networks multiplies by the day.

Video is a strange beast. From time to time I regularly receive the question: How many bit/s are required to transmit video? My regular answer is: as many as you want, even no bits at all. I agree that some may see this answer as non-collaborative, but it contains a profound truth, namely that video is a really flexible beast because you can decide how many bit/s you use to transmit video. No matter how few bits you use, your correspondent will always see “something”.

Operators have exploited this feature to cope with the wide dynamics of networks characteristics. If transmitter is informed that receiver is unable to receive all the bits that it needs to decode a video, it can switch to a version of the video encoded at a lower bitrate. The user at the receiving side will see a less crisp picture and he may complain about the shortsightedness of telcos that did not invest in ATM (if they had done it, what would the phone bill be today?), but that is still better than a picture that keeps on freezing.

The problem is that operators has independently decided to use their own transmitter-receiver protocols. This was acceptable at a time when video was a past time of few, but it is no longer a solution today when video is so pervasive.

MPEG has spotted this problem and is close to releasing a new standard called DASH. The acronyms stands for Dynamic Adaptive Streaming over HTTP and is almost self-explanatory. The pervasive HyperText Transport Protocol is used to stream video but the bitrate used is dynamically adapted to network conditions using a standard protocol that any implementer can use to build interoperable solutions.

See a technical explanation at http://mpeg.chiariglione.org/technologies/mpeg-b/mpb-dash/index.htm

Leonardo Chiariglione

Tuesday, 1 February 2011

Behind the scene, the Web APIs

Once upon a time the web used to be a lot different. If you think about it for a second, you'd surely recall that just few years ago the web was all about emails, static web sites and file sharing (either legal or not) .
It's fascinating how much it evolved, and how close the web applications are getting to the old fashion applications you used to install on your laptop.
This was surely because of the evolution of the network itself (growing bigger and faster all over the world) but mainly because lately new paradigms (such as the ad Software as a Service and Web Service ones) came along opening a whole new prospective on how the software can be delivered.

The Wim.tv project started taking deeply in account those new paradigms and focused on delivering a rich user experience to both its business partner and to the consumer joining the platform. But it wasn't until recently that we started to implement a key feature to become successful web platform: a Web API.
When used in the context of web development, an API is typically a defined set of Hypertext Transfer Protocol (HTTP) request messages, along with a definition of the structure of response messages, which is usually in an Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format. While "Web API" is virtually a synonym for web service, the recent trend (so-called Web 2.0) has been moving away from Simple Object Access Protocol (SOAP) based services towards more direct Representational State Transfer (REST) style communications. Web APIs allow the combination of multiple services into new applications known as mashups . This is a key feature of modern web applications because it allows web developers to exploit the APIs in ways never even imagined by the API's development team itself, letting the web evolve. Wim.tv strongly believes in openness and interoperability and it's working hard to provide a simple and reliable Web API to allow other web developers to interact with the platform as much as possible and to integrate our technologies into their web applications.
Alberto Aresca