Hacker News Reader

"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.

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.

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.

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...