Minority Opinions

Not everyone can be mainstream, after all.

Broadcast over IP

leave a comment »

In the spirit of half-baked ideas, I present an idea that has been kicked around the office by people who barely know what we’re talking about:  A new protocol for real-time broadcast streams.  This could potentially offer speed boosts, or at least network traffic reductions, to services like:

  • Video conferencing
  • Cable television
  • Internet radio
  • Chat rooms
  • Webcams
  • Twitter

Each of the above involves sending identical packet streams to multiple recipients.  Each would also like to know how many people, or at least how many clients, are listening.  Can both problems be solved at once?

The key is in the subscription request.  Each client would send toward the server, every thirty seconds or so, a packet requesting a particular stream.  Whether this stream is described as a URI or an unsigned integer is up for grabs; the former takes up more bandwidth and memory, but would offer a better user interface.  The request would also contain a field for the number of listening clients; each end client would set this to one.

The traffic reduction occurs when a router notices that multiple clients are subscribing to the same stream.  They would be encouraged to collapse multiple subscriptions into one upstream request, adding together the values of the connections fields.  Then, when it receives matching packets from the server, it routes them to each of the subscribing clients.  Clients can be dropped from the list if they let their subscription lapse for a minute or two.

It might be worthwhile to have an information packet in the stream, that could be cached by the router, but the router already has enough memory issues just dealing with the subscription requests.  Fortunately, if it lacks enough memory to store a request, it can pass it on untouched; another router can handle it, or the server itself can.  In fact, if there are no routers between the server and the client, or if none of the routers know how to condense subscriptions, the service still works; it’s just less efficient that way.  (In practice, it would probably be a very good idea to put at least one such router in front of the server, to reduce the server’s load, and ISPs would catch on quickly enough if it saves them money.)

Video and audio streams would need to be encoded in a way that lets the client jump in at any point, or at least quickly enough that the user doesn’t notice.  Streams can even be encrypted, as long as the client can collect a decryption key out of band.

It’s possible that IP multicasting provides enough functionality for this usage, but it seems a little tricky.  IGMPv3 allows a computer to join a group that receives multicast messages from a particular server, or even list of servers, but doesn’t seem to have the ability to report number of connections.  On the other hand, perhaps that’s for the best; it avoids the issue of having the connections field overflow for really popular requests.  However, it seems to require router support to be viable at all; is it already ubiquitous enough to be relied on?  There seem to be some people using it for IPTV, but I haven’t seen it getting used for streaming from the browser.  Then again, what I’m envisioning could be almost invisible, and it’s entirely possible that greater minds have created something even more so.


Written by eswald

11 Apr 2011 at 1:36 pm

Posted in Technology

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s