Not related to the question of spec and standards processes but it is interesting to ask the question of whether web sockets are architecturally sound.
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.
"If we use websockets unwisely we could end up painting ourselves into a corner."
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.
WebSockets could easily end up doing terrible things for scalability of a service. However, so can misusing Comet, improper database structures, etc. At the end of the day, developers need to make an informed decision about what technologies to use and not use; in many cases, that'll mean foregoing WebSockets in favor of other solutions, but sometimes they're simply the best tool for the job.
This is definitely true. My question is more along the lines of "what scalability lessons will we have to learn now that the World of Warcraft guys already know" (more or less). It'll be a different world from the firestorm of short lived (often stateless) connections we worry about now.
Server-sent events (implemented in Opera by 2006) is older than Websocket (first proposed in 2008), but is less well supported by browsers. They have pretty much the same properties w/r/t scaling, but SSE is a slightly higher level spec, which could make your app either easier or harder to implement, depending on your use case.
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.
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.
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 built an OSS pusher protocol alternative, and have this same problem with the fan-in. I got around it by using a library called Hazelcast which does distributed data structures among clusters. It also includes topic subscription functionality, which is something I used.
There is another pusher protocol implementation called Slanger, and they use Redis for centralized pubsub, which has pubsub built in.
You can also use a real distributed queue or zeromq. The problem is that it's easy to do all of the websocket notification in on process, and a lot of examples people follow (e.g. node.js) seem to assume there's one process to manage everything.
Haven't looked deeply into the issues Tim Bray raises, but I think when he talks about architectural soundness he's referring to security model, not scalability...
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.