It’s just data

WebSockets

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.

Posted by Scott Johnson at

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

Posted by Colm MacCarthaigh at

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.

Posted by Sam Ruby at

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

Posted by Colm MacCarthaigh at

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.

Posted by Sam Ruby at

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.

Posted by Wes Felter at

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.

Posted by Colm MacCarthaigh at

why only single node Erlang?

Posted by Robert Sayre at

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.

Posted by Sam Ruby at

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.

Posted by Robert Sayre at

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.

Posted by Sam Ruby at

Add your comment