Joe Armstrong: After a small amount of experimentation I was able to make Erlang talk to a web page using pure asynchronous message passing. I think this means the death of the following technologies:
I see the appeal for a single node Erlang or Eventmachine or node.js server. (Can sockets be passed between servers?)
I’m less clear about how this could work with request/response servers like PHP or Rails. Event loops on the server are not typically application patterns for applications using such frameworks — shared nothing is more of the norm.
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.
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.
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.