2012-05-14

While working on MuttonChop, I was unhappy with the way that the Web UI updated based on the state of of the player. The reason for my displeasure, was the use of polling to determine the player state.

In pseudo-code, the polling is something like the following:

function check_player_state
    //get the player state
    state = get_player_state
    //parse the state and update the UI accordingly
    update_web_ui ( state )
    //sleep for 2 seconds
    sleep 2
    //check the state again
    check_player_state

Every 2 seconds, the Web UI checks the player state and then updates the UI.

Obviously I could shorten the polling time, but this leads to two issues that I'd rather not deal with.

  1. Constant polling creates far too much network traffic for my tastes.
  2. The steady amount of pulled data forces the client to work to much. If the client is running on a mobile device, this will cause unnecessary battery usage.

The solution, at least for me while coding MuttonChop, was to use a push technology known as Server Sent Events, which are part of the HTML5 specification.

In a nutshell, Server Sent Events work as follows:

  1. a client makes a connection to a server
  2. when the server has new data for the client, the server sends the data over the connection for the client to process

When not processing events, the client can be idle and save battery life (hopefully).

A Real World Scenario

While listening to music, when the track changes, the client interface should show the new track title and artist.

With polling, it may take 2 seconds for the UI to display the change.
With Server Sent Events, the update is almost in realtime.

The usage of Server Sent Events can make a sluggish polling based UI much more responsive to user interaction, and when dealing with Web apps, this speed up in responsiveness is very noticeable.

Client Support

Not all clients support Server Sent Events (in JavaScript terms, it is called EventSource). For example, the browser on my n900 doesn't support EventSource, and apparently the next version Internet Explorer doesn't support it either. fancy that.

In the case of MuttonChop, both polling and Server Sent Events are used. When the Web UI is first accessed, a line of JavaScript detects if the client can use EventSource. If the client can not use EventSource, the UI falls back to using polling.

Since the connection for using Server Sent Events uses HTTP and the data is transferred as text, it should be fairly easy to write programs to process the events using any language that has an HTTP library.

To see what the events look like for MuttonChop (if you are interested in such things), open the command line and curl the "events" url of a playing muttonchop machine.

curl MUTTONCHOP_HOST:2876/events

Taking this a step further, open a few connections to a MuttonChop server using a web browser or the curl method mentioned above, and change the volume on one client; the other clients should update the volume bar almost instantaneously. sweet sauce!

A great introduction to coding using Server Sent Events is available at http://www.html5rocks.com/en/tutorials/eventsource/basics/

Until later, happy hacking!

Comments
Name:
not required
Email:
not required (will not be displayed)
Website:
not required (will link your name to your site)
Comment:
required
Please do not post HTML code or bbcode unless you want it to show up as code in your post. (or if you are a blog spammer, in which case, you probably aren't reading this anyway).
Prove you are human by solving a math problem! I'm sorry, but due to an increase of blog spam, I've had to implement a CAPTCHA.
Problem:
3 plus 6
Answer:
required
subscribe
 
2016
2015
2014
2013
2012
2011
2010
December
November
October
September
August
July
June
May
April
March
February
January
2009
December
November
October
September
August
July
June
May
April
March
February
January
2008