[erlang-questions] question re. message delivery

[Miles Fidelman]

On 9/25/17 2:13 PM, Jesper Louis Andersen wrote:

> On Mon, Sep 25, 2017 at 6:02 PM Miles Fidelman 
> <mfidelman@REDACTED <mailto: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.)
>
>
>
I think that your examples essentially demonstrate that, for a lot of 
applications, one pretty much has to implement one's own message passing 
protocol on top of Erlang's - to guarantee that all messages are 
delivered, and delivered in order.  Some applications can tolerate 
missed messages, a lot can't.

Miles

> 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.
>

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170925/d901947c/attachment.htm>