[erlang-questions] question re. message delivery

[Jesper Louis Andersen]

On Mon, Sep 25, 2017 at 6:02 PM Miles Fidelman <mfidelman@REDACTED>
wrote:

> (I'm also interested in the logic of why it's easier to program around
> missing messages than out-of-order messages.)
>
>
In principle, you could allow for messages in any order with missing
messages as well. This would enforce most Erlang processes to implement a
reassembly buffer and have the client set a unique counter in each message
if they need a specific order. It is not impossible to do at all.

However, ordering is a very nice property in practice, and many streaming
scenarios requires that messages have order. If you get e.g.

{data, FromPid, Binary} | {done, FromPid}

ordering ensures that you don't need to know a counter on each 'data'
block. Many protocols also have state transitions and packets forcing those
transitions arrive in certain orders. Requests that "cancel" stuff usually
requires that everything before that cancel was correctly processed in
order to build a graceful shutdown (one example: the GOAWAY frame in
HTTP/2). Reordering is fatal to correctness here as well as it destroys the
"happens before" relationship.

In short, certain invariants can be easier maintained between mailbox
receives if you know that things in the mailbox happens in order.
Furthermore, the guarantee is fairly easy to uphold between any two pairs
of processes.

Missing messages often requires some kind of exception or timeout to
trigger in order to clean up internal state in a process. But this is often
built into typical protocols anyway. I won't say it is easier or harder to
handle compared to ordered messages however.

If you squint your eyes a bit, then a missing message is simply a message
arriving at timepoint "infinity" (i.e., never). So it can be understood as
a reordered message unless *every* message after the missing one is also at
timepoint "infinity". BEAM is currently using TCP as the transport between
nodes, so this observation holds: reassembly at the TCP level ensures
messages arrive in order and if a message goes missing it means connection
loss rather than later message arriving properly. By this view, UDP is not
an allowed protocol because it breaks the squinted eye view of message
ordering.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170925/e3595eb3/attachment.htm>