The only problem with this is c10k - you have to have something writing to the socket and this "something" was basically a process in most cases. It's a great fit for async things like Node or Twisted/Tornado, though. And for Erlang.
The only problem with this is c10k - you have to have something writing to the socket and this "something" was basically a process in most cases. It's a great fit for async things like Node or Twisted/Tornado, though. And for Erlang.
Also, unlike WebSockets it's also easy to add SSE support for mobile clients. I've implemented a SSE client class in just over 100 lines of Java, and it's similarly easy to do this with NSURLConnection/NSURLSession on iOS. The W3 standard provides an implementation section that reads like pseudocode.[2]
[1]: https://en.wikipedia.org/wiki/Comet_%28programming%29
[2]: http://dev.w3.org/html5/eventsource/#event-stream-interpreta...
The browser will try hard to keep the connection always on for you (unless instructed otherwise). You don't have to implement your own logic for offline/online detection, exponential backoff, etc. Thanks to id:/Last-Event-Id header the server can make error recovery transparent to the client.
You do need node/tornado/etc to take full advantage of it, but if all you have is PHP or such, then you can still make it real-time-ish. Because SSE automatically reconnects you can have any behavior ranging from a single persistent TCP/IP connection, through Comet, to regular polling. You control this with the `retry:` line and by (not) closing connection on the server (e.g. keep persistent connection when load on the server is low, set high `retry:` and close the connection when the load is high).