WebSockets Follow-Up
tbray.org
tbray.org
It certainly seems that for games like BrowserQuest they are more or less necessary. But they do have a crucial property that a long lived connection lives on one server - for a long time.
I have a location service where users are notified about other nearby users. However, whenever I look at scaling the server responsible for this across multiple threads or machines, I am always concerned by this massive fan-in effect. Where multiple servers or threads will have to send nearby notifications back to a single process to have that information sent down a specific connection. This seems like it may become a bottleneck.
I don't know how this approach will turn out. I have thought about using Server-Sent Events instead, but that is newer than websockets and is getting less attention, so I don't feel secure that the support will be there.
I think that forgoing long lived connections is a very useful tool for simplifying and scaling up web services. If we use websockets unwisely we could end up painting ourselves into a corner.
Anyone has any thoughts on this? Some experience would be great to hear about.
NB: I put this same question to the blog itself.
There is another pusher protocol implementation called Slanger, and they use Redis for centralized pubsub, which has pubsub built in.
Neither is any less “architecturally sound” (from the perspective of your comment) than TCP itself.
> Where multiple servers or threads will have to send nearby notifications back to a single process to have that information sent down a specific connection. This seems like it may become a bottleneck.
Every messaging platform has potential bottlenecks. But there’s been quite a bit of work in the last 30-40 years on scaling such systems. What kind of back-end architecture you want to use depends a lot on your intended use. I recommend playing with ZeroMQ if you want to make your own messaging platform, to get a feeling for how it should scale. A “safer” solution of course is to just pull some existing scalable message platform off the shelf.
They're sockets. If you can't build a scalable service on sockets, give up now, because they're already the only choice you have. The web is built on slightly simpler sockets (TCP). All IM services are built on slightly simpler sockets. All email runs over slightly simpler sockets.
Sockets themselves do not fail to scale. Your code may fail to scale, but it's not the socket's fault.
The only issue that sockets have is that there's this web server in the way which may or may not have actually been built to deal with the sockets, but that will resolve itself soon enough. I'm sure over time every language will grow the thinnest possible HTTP socket server shim possible for binding sockets as similarly to TCP as possible, and there will be plenty of socket proxies built on every platform known.
Why do you have to keep all clients connected to a single process? We've solved this problem years ago by load balancing client connections to multiple processes across multiple machines, even multiple data centers.
(I waned to write a self-hosting webpage, but WS doesn't get you there--the real-time communication stuff might, though.)
I'm not suggesting that it would be foolproof for consumer applications or what have you--but being able to write something like netcat in javascript for my browser would be pretty cool.
WTF? It's like Tim Bray took a long vacation from relevance when he went to work at Google, and never came back.