6 ms·
You might not need a WebSocket
- jkarneges 12y agoAuthor 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 agoConceptually, 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 agoagreed 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 agoTCP 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 agoWhy 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 agoMostly 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 agoI 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 agoI 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 agoFor 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 agoI 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.
- tribaal 12y agoI 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 12y agoIndeed. 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 12y agoIt would be nice if you could drop the http overhead for long-polling though, which is the main reason I use websockets.
- nawitus 12y agoHave you tried socket.io-based web applications on the train? It does pings and reconnecting.
- different-opini 12y ago
- Swizec 12y ago> 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.
- plorkyeran 12y agoModern setups don't even involve spawning a new thread per request anymore as even that doesn't scale well enough.
- timmclean 12y ago>> 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 12y agoSide-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 12y agoJustin, 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 12y agoInteresting! 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.
- lionheart 12y agoSo 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 12y agoFanout'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 12y agoWhat would be the best technology for building real-time browser based chat application available today where I own the client?
- jkarneges 12y agoI 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.
- lionheart 12y agoThat sounds great actually. We don't have an API now but we're planning to start one in the next 30 days and I was wondering about how we were going to do the real-time aspect. I'm going to bookmark this.
- manishsharan 12y agoSome 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 12y agoIf notifications only go one way, server side events should also be considered. ...but I don't remember the advantages anymore :)
- rakoo 12y agoHave 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/
- manishsharan 12y agoOnce you introduce a websocket on your html simple page app, it makes sense to send all the user/browser side events to server over the websocket as well. Use socket.io like aggressive websocket connectivity tests and failover to normal REST ajax.
- damon_c 12y agoby 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 12y agoProbably not, but they're so addictive! The novelty is yet to wear off, for me anyway.
- 650REDHAIR 12y agoAre you using WebSockets in a big production environment or just for hacks/projects?
- munro 12y agoWhile 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 12y agoIf 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 12y agoI 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
- swah 12y agoBut 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 12y agoI 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.
- swah 12y agoIts also interesting how Gmail doesn't try to hide that its connection problems.
- tribaal 12y agoThat 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 12y ago
- ebbv 12y agoWebSockets 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 12y agoWebSockets 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.
- nailer 12y agoSSE is also a proper solution. If you have a REST setup, you can use the same HTTP resources for both pulling and pushing.
- BoppreH 12y agoIf 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
- oDot 12y agoInteresting 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#why-racer-browserchanel-uses-long-pooling-and-not-web-sockets https://github.com/derbyparty/derby-docs/blob/master/faq.md#...
- qubyte 12y agoServer 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