[erlang-questions] Message multiplexing
Sat Jul 28 09:44:54 CEST 2007
> On Jul 27, 2007, at 3:59 PM, "Jim McCoy" <> 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!
More information about the erlang-questions