4 ms·

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 som

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 12y ago
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 12y ago
  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 12y ago
    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.
- matt_kantor 12y ago
  Why not server-sent events[0]? var source = new EventSource('/some/url/path'); source.onmessage = doSomething; [0] http://dev.w3.org/html5/eventsource/ http://dev.w3.org/html5/eventsource/
drbawb 12y ago
Mostly technical, I need the performance, and my problem maps pretty well to raw sockets. The application I'm currently writing can push upwards of 60msgs/sec to the websocket client. Using long-polling, etc. this just doesn't seem feasible. I'm sure my HTTP stack _could_ push small messages in <17msec fairly reliably... but that's not what it's built to do. Tossing the request all the way down my HTTP stack just seems wasteful. There might be middleware hitting persistent caches, there might be a reverse proxy out in front, etc. -- This all takes non-negligible resources away from other requests, and this all takes time. --- I should note that I do use SSE or long polling for things like event notifications. So in the end I fully agree with the article. WebSockets are not a tool that should be applied haphazardly. In my stack WebSocket upgrade requests hit an entirely different server, so I take great care in electing where to use them.
munro 12y ago
I used Socket.io for my site, so I don't care what the implementation. I just needed a way to push realtime events to the user. Side note: Thinking about switching to SockJS since I use 1% of Socket.io features, but it's working well as is
mey 12y ago
I don't use WebSockets mostly because of general lack of support and stability in the frameworks I use and clients I want to support. I typically use an in memory buffer server side of events generated to send down, the client polls (as rapidly as desired, sometimes on the minutes time frame, sometimes on the seconds) passing up the last package ID it received (or nothing if it's just starting up). The server from memory sends back all messages it has as the delta. This combined with keep-alive has worked rather well. I would not recommend this for mobile users or users who would be on metered connections, but the behavior of the client is easy to implement using ajax and throttling on the javascript side. By it's nature it automatically recovers from network drops or reroutes with no additional logic.
jkrems 12y ago
For me it was just "the thing everyone was talking about". Was amazed when I discovered EventSource and puzzled why it wasn't more widely known. Axed the socket.io complexity immediately. Thanks for putting the word out about this!
thedufer 12y ago
I suspect we originally started using WebSockets because of the bandwagon, but it still feels like what we want. We use them to subscribe to various message feeds; client->server messages are used to add/remove subscriptions and server->client push messages that are on the subscribed feeds. We have a small abstraction over the browser WebSocket object that gives auto-reconnect (and catches disconnects through polling frames) and an interface that looks more like a Node.js EventEmitter. We fall back to (normal) polling if the socket takes more than a few seconds to connect.

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 12y ago

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 12y ago
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 12y ago
  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.
matt_kantor 12y ago
Why not server-sent events[0]? var source = new EventSource('/some/url/path'); source.onmessage = doSomething; [0] http://dev.w3.org/html5/eventsource/ http://dev.w3.org/html5/eventsource/

drbawb 12y ago

Mostly technical, I need the performance, and my problem maps pretty well to raw sockets. The application I'm currently writing can push upwards of 60msgs/sec to the websocket client. Using long-polling, etc. this just doesn't seem feasible. I'm sure my HTTP stack _could_ push small messages in <17msec fairly reliably... but that's not what it's built to do. Tossing the request all the way down my HTTP stack just seems wasteful. There might be middleware hitting persistent caches, there might be a reverse proxy out in front, etc. -- This all takes non-negligible resources away from other requests, and this all takes time. --- I should note that I do use SSE or long polling for things like event notifications. So in the end I fully agree with the article. WebSockets are not a tool that should be applied haphazardly. In my stack WebSocket upgrade requests hit an entirely different server, so I take great care in electing where to use them.

munro 12y ago

I used Socket.io for my site, so I don't care what the implementation. I just needed a way to push realtime events to the user. Side note: Thinking about switching to SockJS since I use 1% of Socket.io features, but it's working well as is

mey 12y ago

I don't use WebSockets mostly because of general lack of support and stability in the frameworks I use and clients I want to support. I typically use an in memory buffer server side of events generated to send down, the client polls (as rapidly as desired, sometimes on the minutes time frame, sometimes on the seconds) passing up the last package ID it received (or nothing if it's just starting up). The server from memory sends back all messages it has as the delta. This combined with keep-alive has worked rather well. I would not recommend this for mobile users or users who would be on metered connections, but the behavior of the client is easy to implement using ajax and throttling on the javascript side. By it's nature it automatically recovers from network drops or reroutes with no additional logic.

jkrems 12y ago

For me it was just "the thing everyone was talking about". Was amazed when I discovered EventSource and puzzled why it wasn't more widely known. Axed the socket.io complexity immediately. Thanks for putting the word out about this!

thedufer 12y ago

I suspect we originally started using WebSockets because of the bandwagon, but it still feels like what we want. We use them to subscribe to various message feeds; client->server messages are used to add/remove subscriptions and server->client push messages that are on the subscribed feeds. We have a small abstraction over the browser WebSocket object that gives auto-reconnect (and catches disconnects through polling frames) and an interface that looks more like a Node.js EventEmitter. We fall back to (normal) polling if the socket takes more than a few seconds to connect.