Mozilla

A Wall Powered by EventSource and Server-Sent Events

EventSource landed in Aurora 6. It is a new and simplified way to open long-lived connections to a server, and let the browser create events as the server streams messages to the client. It is also available in Chrome and Opera and there are fallback solutions for other browsers.

Creating a wall/feed for a social app…

…in a few lines of code (full project available on Github).

The messages

The server will send two kinds of messages:
 ● simple messages, starting on a new line prefixed with “data:”
 ● messages with specific event names, similar to simple messages but with “event: <anEventName>” on the previous line

In this case, simple messages are treated as users’ statuses and specific events will be inserted in the timeline with specific colors, although they could appear in different places on the page. The message data will be sent as JSON, although it could be flat text strings.

The server

The server will be a dummy .php script that reads sample statuses from a text files and stream them, one at a time, to the client, using appropriate headers.

The Client

The client will create an event source and register event handlers for each specific event name, as well as an onmessage handler for simple messages.

The missing pieces of the code are available on Github.

Fallbacks

Here is a short list of polyfills/fallbacks available for other browsers:
 ● Remy Sharp’s polyfill
 ● Yaffle’s polyfill
 ● Rick Waldron’s jquery plugin

Have you got examples of EventSource based Web app to share?

Posted by on at

23 comments

Comments are now closed.

  1. louisremi wrote on June 16th, 2011 at 7:44 am:

    It should be noted that the EventSource specification currently prevents the server script from being hosted on a different domain.

    The first implementation we deliver complies to the specification, but we think this possibility could benefit developers, as it is a good practice to serve persistent connections on their own domain.

    We are going to experiment with making EventSource Cross-Origin compatible, and you can follow our progress here: https://bugzilla.mozilla.org/show_bug.cgi?id=664179

  2. David illsley wrote on June 16th, 2011 at 11:09 am:

    The piece of the puzzle I’ve been missing is dealing with failures… Dropped connections etc. Do I have to worry about this, or will reconnection happen automatically ?

    1. louisremi wrote on June 16th, 2011 at 11:18 am:

      Interesting questions: We do not have any documentation about that yet, but reading the spec should help you: http://www.w3.org/TR/eventsource/#eventsource
      I’ve noticed that (at least in Firefox) the connection is closed if the user hits the Esc key in my demo.

  3. David Illsley wrote on June 16th, 2011 at 11:37 am:

    :( I looked at the spec a couple of weeks ago and it’s nowhere near specific enough for interoperability. Was kinda hoping that Mozilla might be setting the standard… too many flaky/hostile mobile networks and laptop lids which close to assume the connection is robust.

  4. sonny wrote on June 18th, 2011 at 10:39 am:

    Good article despite I wouldn’t have use a “Wall” example since it’s typically the kind of application that would benefits from being WebSocket (bi-directional) powered.
    Instead I would have use an example where a radio website would be able to push the name of the current song to listeners.

    1. louisremi wrote on June 20th, 2011 at 8:13 am:

      Hey Sonny,
      Let me disagree, on those kind of walls you typically receive way more data than you send, and the data that you send back don’t need to be treated in near-real-time.
      With EventSource you can use a standard Web server to stream data to the client (WebSockets need a special setup on the server side), and use XHR to send data to the server from time to time.

  5. alain wrote on June 21st, 2011 at 5:53 am:

    I like the demonstration, works just fine !
    I read today this article about the evolution of the API :

    http://blog.whatwg.org/weekly-back

    I think this wall example would be more “complete” with a multi-client version, louisremi, can you confirm that we would need some kind of server database access to realize such an application ? Since the php file is not aware of the different clients, I think we need something like that (that could be a flat file on the server maybe).

    1. louisremi wrote on June 21st, 2011 at 6:18 am:

      Yes, you need something like a message queue on the server to handle multiple clients

  6. alain wrote on June 21st, 2011 at 6:26 am:

    Thanks :)

  7. Vitaliy Kupets wrote on July 11th, 2011 at 5:54 am:

    I would be happy to see WebSockets ready finally instead

  8. davide wrote on July 16th, 2011 at 4:52 am:

    Hi, thanks for posting on this interesting feature.
    Is the approach shown above, i.e. the server, say sse.php, running an infinite loop and waking up every N seconds to check if there’s any event/message to send, the only one to use always?
    The question comes from the idea of using events in an MVC application as follows: while the user is visiting a certain page of the site, say fun.php, an event needs to be sent. Would it be possible to send the message directly from fun.php rather than passing the data to build the message to sse.php (via queue, etc.)?

    1. louisremi wrote on July 20th, 2011 at 6:40 am:

      You can definitely send events from the script generating the page being visited.
      For performance reason, you might want to host long-lasting connection on a different server hosting more appropriate technology, such as node.js for example.

  9. Jerome Louvel wrote on July 21st, 2011 at 12:09 pm:

    Great to see “Server-Sent Events” moving forward into Firefox. What is cool about it compared to Web-Sockets is that it doesn’t invent another protocol and fits perfectly with HTTP and the REST architecture style.

    It might not cover 100% of real-time use cases, but does what it does in a very standard, simple, yet powerful way. In the Restlet Framework, we are planning on adding its support, both server and client-side.

  10. Louis-Pierre Beaumont wrote on August 9th, 2011 at 2:06 am:

    Hi,

    Thank you for this nice demo. Between I can’t get EventSource working on my machine. I’m always getting an error stating that Firefox cannot establish a connection with the server.

    I made a little program that listens for connections then enters a simple loop
    that sends events every 2 seconds. When i point my browser to it’s url, I can see the updates. But When using new EventSource(urlOfProgram), nothing.

    Do I need to host both the page and program on the same address AND port?

    1. louisremi wrote on August 13th, 2011 at 12:21 am:

      Yes, there used to be such a restriction on server-sent events.
      You’ll soon be able to use CORS headers to have the event source on another domain

  11. Louis-Pierre Beaumont wrote on August 9th, 2011 at 5:16 pm:

    About my last comment:

    I’m now hosting the page and program on the same address AND port and everything works perfectly.

  12. Aaron wrote on August 16th, 2011 at 9:12 am:

    On Apache+PHP, won’t this inevitably max out the number of concurrent connections allowed?

    1. louisremi wrote on August 17th, 2011 at 2:11 am:

      Sorry Aaron, I’m no specialist of Apache and PHP and cannot answer that question.

      1. Davide wrote on August 17th, 2011 at 2:23 am:

        I had the same concern and, not having found any clear answer yet, I refrained from using SSE at least for now.

  13. Srirang (brahmana) wrote on September 7th, 2011 at 3:28 am:

    Hi,

    Are these persistent connections counted towards the maximum simultaneous connections to a host limitation? AFAIK, the limit is currently 6 simultaneous connections to a host.

    I am guessing that these are indeed counted and that is one of the reasons why the author suggested that these should be hosted on a separate domain.

    1. Sergiu wrote on March 20th, 2013 at 3:04 am:

      I have an issue when adding the sixth EventSource in my application, the server stops responding. Can I customize the number of allowed simultan connections? Or is it a pre-defiend rule?

  14. Victor wrote on September 28th, 2011 at 4:46 am:

    This EventSource polyfill supports CORS in (IE8, Firefox, Chrome, Safari):

    https://github.com/Yaffle/EventSource

  15. Gary Tessman wrote on October 27th, 2012 at 5:02 pm:

    I’m using OSX Lion 10.8.2, Firefox 16.0.2, Tomcat 7, Spring MVC app, with DWR as well. Server Sent Events appear to stop working in Firefox after awhile with a simple clock, sending with retry every 1000ms. I’ve written a WebServlet and also a Spring MVC controller app and firefox seems to stop receiving/responding to Server Sent Events in less than 20 minutes. Chrome does not have this problem and continues overnight. I suspect this is a bug in Firefox since side by side, Chrome keeps going… Firefox stops. I’m really interested in any suggestions anyone might have and am willing to send any code as demo if desired. Has anyone tried SSE in Firefox for any extended period?

    Thank you,
    Gary Tessman

Comments are closed for this article.