
You might not need a WebSocket - 650REDHAIR
http://blog.fanout.io/2014/06/24/you-might-not-need-a-websocket/
======
tribaal
I live in Africa.

Websockets _suck_ here. BGP routers here flap very often, nuking TCP
connections because hey, power cuts. Guess what happens?

Tip: If you're "out to change the world", make sure you can turn your wifi
card every 30 seconds and still get a decent-ish experience (yes, long-polling
HTTP works, so does good old timer-based polling).

~~~
jkarneges
Indeed. These days, you have to expect users will wander out of their wi-fi
range or have crappy mobile connections. Whenever I ride the train with my 4G
tether, my TCP sockets die every few miles.

I lose ssh and my websockets, but long-polling apps keep working. Kind of
ridiculous, but that's the world we live in.

Making your websockets resilient means pinging and aggressive reconnecting.

~~~
saosebastiao
It would be nice if you could drop the http overhead for long-polling though,
which is the main reason I use websockets.

~~~
tribaal
I'm fine with sending a couple of extra kb if that means I actually get an
answer :)

------
Swizec
> Long-polling gets a bad rap.

Yes it does, but not for the reasons you mentioned. The main objection against
long-polling in the olden days was that it would spin up a new server process
every time, leading to server overload. Websockets solved this by allowing a
single server to handle multiple connections on the same socket.

However, these days that is arguably not the case anymore. I think most
servers don't make a new process for every request anymore, but I could be
wrong. Am I wrong?

Regardless, long-polling has left a sour taste in people's mouths and now
they've moved on.

But I agree, websockets are overkill for most cases and I have personally
never found them to be a very reliable piece of technology. They're super
fragile and finnicky and I never liked working with them.

~~~
timmclean
>> most servers don't make a new process for every request anymore

That's correct. Most designs use either a prefork model (e.g. Apache) or an
asynchronous event-driven model (e.g. Nginx). With prefork, a number of worker
threads or processes are created on start up, and each services one request at
a time. In the asynchronous model, a smaller number of (typically single-
threaded) processes are created on start up, and each services one event at a
time. An event could be an incoming request, a database query returning, etc.
In either model, thread/process creation typically happens entirely on start
up.

~~~
meritt
Side-note: Apache 2.4 finally has an event-driven mpm. A little late, as nginx
rules the web now, but it's still nice to see they finally realized their
style didn't scale.

------
stephenblum
Justin, this is awesome! The overhead of websocket is also surprising when all
layers are considered including TCP Frames
[http://tavendo.com/blog/post/dissecting-websocket-
overhead/](http://tavendo.com/blog/post/dissecting-websocket-overhead/)

~~~
jkarneges
Interesting! I'm surprised that browsers wouldn't batch up many outbound
messages into single TCP frames. The server behaves more the way I would
expect.

That reminds me of a related point: The number of TCP frames can be considered
more important than the number of bytes-per-frame when it comes to network
performance. Most message exchanges, whether over WebSocket or HTTP, will
occupy a comparable number of TCP frames, even if HTTP uses more bytes for the
headers.

------
BoppreH
If you are interested in Server-Sent-Events, I made a small library a while
ago that may be helpful: [https://github.com/boppreh/server-sent-
events](https://github.com/boppreh/server-sent-events)

------
manishsharan
Some use cases for applying websocket in finance/banking: a) near real time
quotes b)order fill notifications c)miscellaneous alerts generated by
background(regulatory monitoring) tasks.

We also support long polling etc. but websocket servers are idling while our
polling/push servers are at higher cpu utilization with comparatively lower
loads.

~~~
swah
If notifications only go one way, server side events should also be
considered.

...but I don't remember the advantages anymore :)

~~~
rakoo
Have a look at this [0]:

\- Automatic reconnection

\- Event ids

\- Straightforward protocol built on plain old HTTP

[0]
[http://www.html5rocks.com/en/tutorials/eventsource/basics/](http://www.html5rocks.com/en/tutorials/eventsource/basics/)

------
ebbv
WebSockets are super easy to use and the proper solution to real time data
communication between browser and server.

Yes, there are other ways to accomplish this, but why would you choose a
kludgey way like long polling when an elegant solution is available? It makes
no sense to me.

~~~
650REDHAIR
WebSockets are super easy to use (we still love it offer support for it), but
if your users are on older devices or browsers you're going to run into
problems.

You also have to take into consideration different network issues, for
instance last year Verizon 3G blocked WebSockets without any documentation. Or
fragile wireless networks where the socket will break.

------
munro
While adding chat to a site, I realized the same conclusions. I started adding
browser->server commands to my WebSocket instance, but then I realized I had
everything already setup to do that in my API, and I was just splaying
browser->server logic over two transports.

WebSockets definitely complicate the code, since you now have to deal with the
connection before you can send a request. Keeping it constrained to realtime
events cleaned things up nicely.

I was also trying to build some persistence into replaying chat messages on
reconnection (data sync), but it was way easier to just turn
"get_last_messages" into an endpoint that gets called on page load, or on
socket reconnection.

~~~
pedalpete
If I understand your first problem correctly, you could have setup an RPC
system so you only write your apis once. Use the same 'endpoint' of your api
as the data call in your socket connection, and you only end up writing your
api once.

~~~
munro
I can definitely hit the API from the websocket server, but I just didn't even
bother! :D I just wrote the websocket server to do publishing events, and left
syncing issues to the API

------
lionheart
So I'm curious, what's the difference between fanout.io and something like
pusher.com?

My company's application has some real-time components and we've just been
using pusher to handle it because it's simple and cheap. Is fanout something I
should consider instead?

~~~
jkarneges
Fanout's great for powering a public-facing realtime API. For example, you can
see what Superfeedr did with it here: [http://blog.superfeedr.com/stream-
superfeedr/](http://blog.superfeedr.com/stream-superfeedr/)

If you're not making an API, and you're just pushing data to your own client
applications that you control, then Pusher and Fanout are more or less the
same. Although you might like Fanout's simpler pricing model and our more open
philosophy.

~~~
johne20
What would be the best technology for building real-time browser based chat
application available today where I own the client?

~~~
jkarneges
I think I'm too biased to answer this properly. :) All of the realtime-as-a-
service options have good resiliency. Pair one of them with RESTful AJAX for
the chat db/logic and you'll do well.

------
oDot
Interesting bit from Derby's FAQ[0]

    
    
      Why racer-browserchanel uses long pooling and not web sockets?
      Web sockets does not guarantee order of messages between client and server, which is critical for OT.
    
    

[0] [https://github.com/derbyparty/derby-
docs/blob/master/faq.md#...](https://github.com/derbyparty/derby-
docs/blob/master/faq.md#why-racer-browserchanel-uses-long-pooling-and-not-web-
sockets)

------
qubyte
Server Sent Events aren't used enough. I'm a big fan, so I wrote a little
Node.js library which wraps (with options for preprocessing) an event emitter
in an express middleware for the company I work for.
[https://www.npmjs.org/package/nudge](https://www.npmjs.org/package/nudge)

------
damon_c
by the way, if anyone is dealing with websocket implementations for the web,
have a look at SockJS, it makes things much easier and includes fallbacks for
situations where sockets are not supported.

[https://github.com/sockjs/sockjs-client](https://github.com/sockjs/sockjs-
client)

(no affiliation, I just like it)

------
vegancap
Probably not, but they're so addictive! The novelty is yet to wear off, for me
anyway.

~~~
650REDHAIR
Are you using WebSockets in a big production environment or just for
hacks/projects?

------
jkarneges
Author here. For what reasons do HN folks choose WebSockets? Is it purely
technical? Joining the bandwagon? Used by preferred frameworks? Would love to
hear some opinions.

~~~
damon_c
Conceptually, polling just seems dirty.

if (some event occurred){ do something over and over every so often that
requires multitudes of processes including authentication, DNS etc. across
many machines, that might not even ever return any value to the user. }

is not as nice as,

on('the arrival of a message', doSomething)

edit: pardon the sloppy pseudo syntax...

~~~
YZF
agreed but "long polling" is not really polling because you're blocking on the
HTTP request. Something over UDP sounds like the answer to the complaints
about TCP connections getting dropped though. TCP was built for streaming...

~~~
colanderman
TCP _technically_ relies only on state on the endpoints, so it "should" never
be dropped unless the endpoints agree. But NAT and various other interlopers
ruin this model, as state is then kept in middle-boxes.

UDP would evince the same problem when traversing NAT, since it also would
require state to be kept in middle-boxes. The only difference is that instead
of periodically reconnecting, you'd need to periodically ping.

------
swah
But when you're in a good, stable, wired network on your PC, websockets means
a faster experience right?

Maybe we just change the user to long poll after a couple disconnects?

~~~
jkarneges
I like this. The other day we were thinking about how the suggested practice
these days is to start with long-polling first, then attempt to upgrade to
WebSockets (as opposed to the other way around). But, in some cases it's not
the browser but the network that prevents WebSockets from working. This means
if you wander to another network that doesn't support WebSockets, you actually
still want a way to downgrade back to long-polling.

Maybe such best practices could also include some kind of poll/ping interval
that adjusts based on the apparent stability of the link. Stable or wired
connections could have very large intervals.

~~~
tribaal
That will introduce yet another delay/flapping point for people on unreliable
connections:

You start with a longpoll and get some data, then negotiate websockets (hey,
my network and browsers _are_ websockets capable!). Then the connection drops.
And then you go through another round of everything again when you get back
online (http + longpoll + websockets, instead of just http + longpoll).

Odds are, your website _doesn 't_ need websockets anyway, and 99% of your
users are just fine with waiting a couple of seconds more to get their
notification (and in the process, people with unreliable connections can still
use your site).

Of course, if you're doing online stock trading notifications or something
like that, you might actually need these two seconds. But then I'll strongly
question your choice of using a browser for that :)

EDIT: fixed stray "*"

~~~
nmjohn
> Odds are, your website doesn't need websockets anyway

Odds are your website doesn't need CSS, but it certainly can benefit from it!
I don't disagree that almost all websites _could_ get by just fine without
websockets, but that seems like an incredibly anti-innovative approach to web
development to me. Instead we should focus on making the experience better, as
opposed to just avoiding innovation altogether.

> 99% of your users are just fine with waiting a couple of seconds

Pretty much every study done in the last few years has suggested that is
completely false, that as wait times rise above a second, the number of
visitors who simply close out rises exponentially.

~~~
tribaal
I question the value of websockets in most cases, because in most applications
I can think of (except maybe games and high-frequency trading), they don't
bring me any value and actually prevent me from interacting with the website
in a meaningful way (yes my connection is crappy, but that is the case for a
big chunk of the online population).

Sure, I can't think of _all_ applications that would benefit from websockets,
but so far, none of the ones I've seen do. I'm certain you can find at least a
few exceptions, but my point is that it is only this: exceptions.

~~~
davecombs
Anything that has a volume of changing data that needs to be close to real
time would benefit. Anything that has that requirement and also wants to be
available on the web would most certainly benefit. High-frequency trading and
games/betting/TV-related-data (e.g. NASCAR), etc are definitely cases. How
about just anything that is currently done via polling and wants to reduce
network overhead? There are a lot of those types of applications. (full
disclosure - I work for Kaazing, the leading enterprise WebSocket company,
though I'm most definitely not speaking for them in any capacity).

