

A WebSocket Primer - caitiem20
http://caitiem.com/2013/12/02/a-websocket-primer/
An overview of the basics of the WebSocket protocol, what you need to get started
======
pornel
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/](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).

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

~~~
yogo
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](http://caniuse.com/eventsource)

Compare with [http://caniuse.com/websockets](http://caniuse.com/websockets)

~~~
dspillett
_> 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).

------
shubber
Related: definitely check out
[https://github.com/sockjs](https://github.com/sockjs)

~~~
TheMakeA
Also check out
[https://github.com/primus/primus](https://github.com/primus/primus) It's an
abstraction layer over sockjs, socket.io, etc.

~~~
jdp23
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?

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

------
general_failure
Does anyone know the purpose of Sec-WebSocket-Key and the associated Accept? I
know the hashing stuff
([https://en.wikipedia.org/wiki/WebSocket](https://en.wikipedia.org/wiki/WebSocket))
but I don't understand why it exists.

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

~~~
general_failure
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)

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

------
tibbon
Found out today that WebSockets now work on Heroku. Wrote a little quick app
that uses them:
[http://colorchats.herokuapp.com/](http://colorchats.herokuapp.com/)

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

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

~~~
brudgers
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?

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

~~~
tlb
Libwebsockets contains a simple command line client and server:

[http://libwebsockets.org/](http://libwebsockets.org/)

------
firen
Great explanation!

