[erlang-questions] Message multiplexing

[Matthias Lang]

 > On Jul 27, 2007, at 3:59 PM, "Jim McCoy" <jim.mccoy@REDACTED> wrote:

 > ... whether or not Erlang does any multiplexing of messages
 > being sent between processes (esp. processes on different nodes)?  The
 > fact that there are no ordering assurances for message sending 

I'm aware of just one guarantee. It's not strong enough to cover your
case. (Two processes P and Q. P sends two messages to Q. Those
messages are guaranteed to arrive in the same order as transmitted.)

Looking at the distribution protocol spec
(./erts/emulator/internal_doc/erl_ext_dist.txt), there's no mechanism
for sending partial messages, so given TCP's properties there's not
going to be any reordering.

Looking at the source (in dist.c, pack_and_send(), dist_send()), I
don't see any reordering or fragmenting code either, though this is
the first time I've looked at that part of the source.

Conclusion: I don't think there's any multiplexing.

Ryan Rawson writes:
 > Sounds like the real question is, does the distribution protocol use 1  
 > or more tcp sockets?  

That is not an equivalent question. It would be _possible_ to send
erlang messages over a single TCP socket in such a way that a short
erlang message sent (shortly) after a long one would arrive before the
long one. RFC3080/RFC3081 is an example of a protocol which allows
(requires!) that complication. The accompanying waffle in RFC3117 is
classic. In case I created the wrong impression: I am not recommending BEEP!

Matthias