Server client communication: Long Polling, Comet, & Server-sent Events (SSE)

Question

I am developing a web application that is connected to a server and I need the server to push some information to the clients on a given time.

Therefore I started to read about Server-sent Events (SSE) because the website is been developed on HTML5 and SSE seemed that fit what I was looking for. But what a surprise when I read that what SSE was really doing was sending request FROM the client to the server instead of the opposite way(Yesterday I think I understood that long polling is sort of a push emulation). Therefore I start to read about web sockets (but it seamed that the standard is still a draft) and also had a look to Comet. But I think I cannot fit all the pieces on my mind.

Would someone highlight these technologies (and maybe some other push tec.) that fit my problem and which situation is more appropriate for each one?

Thanks so much, I think I am totally lost on this field.

Answer 1

This post is a better explanation, discussing the difference/advantages/etc, about Long Polling, Comet, SSE and WebSockets.

For the most part, the client usually has to make the first request to the server to establish a connection. Once a connection is established, then the server can push data to the client. So even with WebSockets, the client will make the initial request to the server for establishing a reliable connection between the two.

Server-Sent Events uses a normal HTTP GET request to establish a connection with the server. It's also a read-only connection for the client. It has the benefit of having an easy implementation since we don't have to define a new protocol. The issue is that HTTP connections, even as persistent-connections, are closed after around 15 seconds by most web servers. Even for long standing requests, the web server often has a timeout after which it closes the connection. This is where the idea of long polling comes in. It's a simple idea that we make a normal ajax request to the server and the server leaves it open for as long as possible. If the request is closed by the server for whatever reason, you immediately make the same request again. You can implement a long polling mechanism (ie. Comet) pretty easily with a server such as Node.js and a normal Ajax request from the browser. Server-Sent Events tries to abstract away the browser side implementation of this with EventSource. So instead of you having to implement the browser/client side code for long polling/comet, the browser handles this for you. It provides a nice abstraction of what seems like a persistent connection. Your web server just needs to look out for GET requests which specify the Content-Type, in the header, as "text/event-stream" and leave the HTTP connection open as long as possible.

I would suggest that you don't over complicate what Server-Sent Events are. If you understand a normal HTTP GET request, then you likely already have a 90% understand of the idea behind it.

There is one difference between SSE/Comet and traditional long polling that might be worth highlighting. From my experience, the idea behind long polling is that your request doesn't return until you have an update. At which point the HTTP connection is closed and another request is made immediately afterwards. With SSE, though you can close the HTTP connection right after you send the updated message, your aim is to flush the data from the server to the client without actually closing/ending the HTTP request. This avoids the overhead of actually making a GET request. This can be achieved with a regular ajax request, but again SSE provides a nice/efficient implementation with EventSource.

Edit: clarify distinction between SSE and long polling.