> the persistent WebSocket connection allowed a set of assumptions around the shared state of the client and server that would have to be re-negotiated when reconnecting. The fact that this renegotiation was non-trivial was a major driver in selecting WebSockets in the first place. With HTTP, regardless of HTTP2 or QUIC, your application protocol very much is set up to re-negotiate things on a per-request basis. And so the issues I list don't tend to affect HTTP-based applications.
I think this describes a poor choice in technology. There's no silver bullet here, and it sounds like you made a lot of questionable tradeoffs. Assuming that "session" state persists beyond the lifetime of either the client or the server is generally problematic. It's always easier for one party to be stateless, but you can become stateful for the duration of the transaction.
Shared state is best used as communications optimization, and maybe sometimes useful for security reasons.
I am the author of Centrifugo server (https://github.com/centrifugal/centrifugo) - where the main protocol is WebSocket. Agree with many points in post – and if there is a chance to build sth without replacing stateless HTTP to persistent WebSocket (or EventSource, HTTP-streaming, raw TCP etc) – then definitely better to go without persistent connections.
But there are many tasks where WebSockets simply shine – by providing a better UX, providing a more interactive content, instant information/feedback. This is important to keep - even if underlying stack is complicated enough. Not every system need to scale to many machines (ex. multiplayer games with limited number of players), corporate apps not really struggle from massive reconnect scenarios (since number of concurrent users is pretty small), and so on. So WebSockets are definitely fine for certain scenarios IMO.
I described some problems with WebSockets Centrifugo solves in this blog post - https://centrifugal.dev/blog/2020/11/12/scaling-websocket. I don't want to say there are no problems, I want to say that WebSockets are fine in general and we can do some things to deal with things mentioned in the OP's post.
There are severe limitations in what cloud vendors can support on concurrent web socket connections without rolling and maintaining your own. Persistent connections may fit for specific use cases where continuous real-time updates are needed but are a poor fit for most UI - backend interactions.
Not using websockets, but thanks! I have to look into it again. Right now the service is working fine so I haven't been motivated to work on it again. (in-memory CDN based on vertx-web + Caffeine + custom on-disk LRU cache)
Cool thanks for the heads up. Might have to check that out, since I'm still searching for how I'm going to manage my websocket connections to a server....
Most use a websocket library like sockjs or socket.io which uses websockets and falls back to long polling if there's an issue with that.
Some IRC servers are starting to implement native websockets but that introduces several issues, so many networks use a websocket gateway to accept websockets to their network, such as https://github.com/kiwiirc/webircgateway
Then for IRCv3, most clients these days do support their specs in some form of way, and it's growing :)
Will people stop writing crap "on" HTTP please and use TCP like you're supposed too! :)
Websockets is a great transport protocol for bi-direction realtime persistent connections. And it's very easy to write your own application protocol or just use WAMP from http://wamp.ws.
Arguing that "WebSockets are bad, because the principals we use for HTTP scalability are not applicable to them" is not wrong, but feels short sighted. Yes: Scaling numerous persistent connections is hard, seeing that most of the available infrastructure is geared towards short-lived HTTP request/response requirements. But there are realtime specific alternatives. You wouldn't want to build your realtime backend from scratch, but rather use something like http://deepstream.io which takes care of the heavy lifting.
Try playing with WebSockets, they're pretty easy to get going. Is there something about them keeping you away? Or would it require quite a re-architecture?
Opening a new WebSocket for each client sounds like a lot of stress on the server, do you need the persistent connection? What if the client visits a new page? A new connection is created?
Sure. Look I'm not advocating for any particular solution here, just trying to point out the hopefully obvious fact that websockets are not a silver bullet. You've basically described why websockets unlock optimizations, which was my point.
Nothing in the GP's post is novel to websockets. Session based resource management is difficult, doubly so for long lived sessions. Relying on websockets to magically make that easy is foolish.
> Not only could this add a lot of complication, now you've actually introduced the problem of state outliving your endpoints!
I only want to point out that this is true with websockets as well, so I find this argument unconvincing. For websockets, what do you do when re-establishing a connection? You start anew or find the existing session. What if the client suddenly disappears without actively closing the connection? You have some sort of TTL before abandoning the session.
Websockets imply persistent connections between servers and clients. That long-term state tightly couples the two: deploying a change to servers now requires draining all running connections, for example. Load balancing is much harder. Throttling client behavior is much harder, so you’re not as insulated from bad client behavior or heavy hitters. Consequences of that decision ripple through the entire architecture.
I really like the polling approach used here. It’s simple, easy to reason about, and loosely coupled. It will be reliable and resilient.
Saying it might have taken a week to learn websockets completely misses the point. I’ve built large architectures on persistent connections and deeply regretted it.
When it comes to nginx and apache you can always go down the hosted realtime infrastructure route. That way you can use WebSockets in your client (app) but you don't need to worry about installing mods or handling the persistent connections on your server.
reply