A WebSocket Primer | Hacker News Reader

A WebSocket Primer

caitiem.com

79 pointscaitiem2023 comments

An overview of the basics of the WebSocket protocol, what you need to get started

It's funny that the article says "This enables server sent events" without actually referring to the HTML5 Server Sent Events API:

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).

Agreed. Both approaches have their place, but I see SSE getting overlooked too often.

I'm not 100% up to speed on SSE but since there is no way to "push" to a client isn't it just some form of polling at the end of the day?

It's also not supported by IE yet: http://caniuse.com/eventsource

Compare with http://caniuse.com/websockets

That's in keeping with how I think of it: open connection from the client with some reasonable expectations set around e.g. reconnection behavior.

Looks like Chrome and Firefox have had support for quite some time. I'm alright with that.

IE is just trying to look all hip and cool and EventSource hasn't generated much hype so it doesn't get implemented.. shame.

> 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).

Thanks for the pointer! This seems much more straightforward than websockets.

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).

Related: definitely check out https://github.com/sockjs

Also check out https://github.com/primus/primus It's an abstraction layer over sockjs, socket.io, etc.

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 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.

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.

YMMV but so far I've no regrets using it.

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.

Found out today that WebSockets now work on Heroku. Wrote a little quick app that uses them: http://colorchats.herokuapp.com/

Need to clean up a few things, but it was a neat 45 minutes.

Would have rather seen sample code as Plain Old Javascript, or some other language that you can use without buying into the Microsoft ecosystem.

Suggest the title be changed to:

A WebSocket Primer for .Net 4.5

The rest of it is a cool read, though. Thanks for submitting.

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?

Is there a commandline http client that can negotiate WebSockets? If so, I might be tempted to experiment.

Libwebsockets contains a simple command line client and server:

http://libwebsockets.org/

Great explanation!

Reply on news.ycombinator.com