SSE is realtime server->client protocol that's fully compatible with HTTP and has lower handshake overhead (no Upgrade roundtrip, doesn't require HTTPS to go through proxies).
> isn't it just some form of polling at the end of the day?
Probably long-poll, a single connection from client to server kept alive with the occasional byte sent one way which sends the message and disconnects when there is something to send (the disconnect, requiring a new request from the client is because some clients won't process what has been sent immediately unless the connection is closed).
I once wrote a messaging client that operated this way. It is efficient in terms of bandwidth use and client footprint, though if you are using a process based we server it can be quite inefficient there (an event driven service on few processes/threads is far more efficient for handling many long-lived low-activity connections).
Do SSEs now support CORS? I know when writing a webapp at the start of this year we went with Websockets because we needed to work in a cross domain environment and SSEs didn't support it; I know it was to be added to the standard, and Firefox had unofficial support of it, but I can't find anything anywhere indicating if Chrome and Safari are supporting it (and IE will probably get it in 12 eyeroll).
Does any have experiences with Primus they can share?
The idea of being able to insulate the rest of the code from the specifics of which lower-level library I'm using is very attractive. On the other hand, any abstraction layer can introduce bugs in its own right. Thoughts about the tradeoff?
I'm using it now for a project that's due to go live early next year and so far it's been a dream. Case in point, I ran in to a bug on Monday and it turned out to be with engine.io itself rather than Primus. The workaround was a one line code change swapping the transformer to something else.
Arnout Kazemier (the lead dev) is a really nice guy and when I pinged him about the egine.io bug, he pushed out a change to Primus 24 hours later that worked around the bug and let me continue to use engine.io as the transformer.
I was using socket.io until about two weeks ago when I ran into some reconnecting issues that weren't fixed. I decided to use Primus + Multiplex + Emitter. I have only run into one issue so far with Multiplex on IE10, but that was fixed quickly. Otherwise the package seems rather solid.
Does anyone know the purpose of Sec-WebSocket-Key and the associated Accept? I know the hashing stuff (https://en.wikipedia.org/wiki/WebSocket) but I don't understand why it exists.
It's there to help guarantee that the server the browser is connecting to actually understands websockets and isn't being "tricked" into opening a connection through clever request formulation. With that guarantee in place, browsers can trust servers to properly check for and limit cross-domain requests and the like and not need to use something like CORS to negotiate that stuff.
Why not skip all the hashing stuff? Why not just have Sec-Key: 'secret' and expect a reply with Sec-Accept: 'secret'. (where secret is hardcoded constant)
I've actually been writing a MUD in Node.js with WebSockets (well, Socket.IO, thus I get failover support). It's been a lot of fun, and has been really easy to use.
What is really interesting is just how easy it is to use WebSockets with the latest libraries. I've got a project in .NET that relies on a lot of Microsoft-specific libraries right now. But with the ease of WebSockets, I can rewrite the UI in HTML5 like we always wanted and get around to rewriting the MS-specific stuff in Java or Python more likely whenever I feel like it.
It's like completely platform agnostic pipes, in a way that TCP/IP sockets never seemed to quite do.
EDIT: I think it's just that I don't have to listen for new connections and figure out how to bind them in a loop that I keep alive myself. I get an event when users connect.
Maybe C# was just the language at hand when the research was done, perhaps as part of a day job. Why not blog something up about web sockets in JavaScript?
http://www.html5rocks.com/en/tutorials/eventsource/basics/
SSE is realtime server->client protocol that's fully compatible with HTTP and has lower handshake overhead (no Upgrade roundtrip, doesn't require HTTPS to go through proxies).