intertwingly

Regardless of how this pattern might work, it definitely seems a bit early to declare the death of that laundry list of popular web technologies.

Sockets can be passed between servers, see; [link] for an example.

Sockets can be passed between server

Forgive me, but unless I’m missing something, that only passes a socket between processes on a single server.

No, You’re right - sockets can be moved between hosts, but it needs trickery like IPVS - [link] for an implementation.

At this point I’m wondering if the Linux Virtual Server is a leaky abstraction or simply black magic.  Servers like node.js rely on the select API working fast, and I simply don’t see how that can be accomplished transparently and correctly across a network.

All problems can be solved by adding another layer of abstraction, or in this case another tier. You could have a tier that manages the long-lived WebSocket connections and proxies events to a pool of app servers; I think Orbited already works this way.

It’s not that hard to share the state from a TCP stack across multiple hosts. In most implementations the incoming traffic is routed to a deterministic host (usually with flow hashing) in a cluster and then synchronized via a back-channel to the “moved to” target host. The target host then sends the outgoing traffic asymmetrically. The TCP state is synchronised (ala CARP) via the same shared channel. LVS is probably the most widely known, but there are other implementations of this technique, some load-balancers can do it too.

It can certainly be done across a network correctly, whether or not it’s efficient is a whole different question probably best put in terms of amdahl’s law.

why only single node Erlang?

My understanding, perhaps incorrect, is that a socket, once open, is bound to a specific host.  I don’t understand how another layer of abstraction or deterministic hosts allows one to effectively load balance, something which often needs to be done retroactively.

I’m entirely OK with WebSockets solving a common, albeit not universal problem — yielding to the current solutions to address the remaining needs.

Or perhaps this needs to be addressed at at the application level.

I must be missing something, because this looks like the exact problem distributed Erlang was designed to solve. Wouldn’t the design to go with be a pretty simple socket reader process with the actual application workload executed in a different Erlang process that may or may not be on the same node?

I do agree that the last two bullet points probably won’t vanish because of web sockets.

It wouldn’t be just a reader process: in order to send data back, one would have to find the server with the socket.  But you are right, this can be solved via application code in Erlang.  I’m still less clear on how this could work with PHP or Rails.