Hacker News Reader

Comment by tribaal | Hacker News Reader

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

View on HN

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.

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

It sounds like EventSource would be a good solution in that case: low overhead, and you'd get auto reconnect for free.

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

Have you tried socket.io-based web applications on the train? It does pings and reconnecting.

Do you know of any public socket.io apps?

Etherpad uses socket.io.

Here's one hosted Etherpad: https://etherpad.wikimedia.org/

Dasher (http://dasher.im), uses socket.io. We're using socker.IO-objc for our iOS client: https://github.com/pkyeck/socket.IO-objc

And will be launching a web client in the coming weeks.

So far, so good. We do handle the reconnects ourselves, but otherwise it's been treating us well.

Have you tried http://mosh.mit.edu/?

That looks awesome. Will definitely check it out. Broken ssh connections make me sad.

Mosh is great, I use it on an almost daily basis.

Setting an alias like "alias sssh='mosh'" greatly helps with muscle memory, too (of course, don't override "ssh", you might still need it).

Funny anecdote: I live in a city called "Moshi"

I don't recommend replacing ssh, but when you do want to shadow a command, you can always call the original using \, e.g.:

  \ssh

If the connections are dropped quietly (client side does not find out the connection is gone) then how does the long poll case know that the existing poll conn is not going to return any data and a new one needs to be initiated?

Or is it just that long polls generally have short timeout compared with what you might implement for a websocket ping?

Correct, long polling clients generally have timeouts. I wouldn't say they are necessarily shorter or longer than typical websocket ping intervals (I've seen as low as 20 seconds and as long as 2 minutes), but they do need to be there for the client to recover quickly.

So if connection resets are the problem, as opposed to router/proxy software problems... In cases where long polling seems to work as you say, why wouldn't an automatic WebSocket reconnect work just as well?

You're right, in that case it'll work just as well. The problem is that it's easy to get wrong, so the developer needs to know what he/she is doing.

Fortunately wrappers like Socket.io, SockJS, Primus, etc can help with this.

Also it just completely falls down in the case of many proxy servers and often the end user has no control over that.

Reply on news.ycombinator.com