<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Sep 25, 2017 at 6:02 PM Miles Fidelman <<a href="mailto:mfidelman@meetinghouse.net">mfidelman@meetinghouse.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <p><span style="font-family:FSBaskerville;font-size:14pt">(I'm also interested in the logic of why it's easier
      to program around missing messages than out-of-order messages.)</span><br></p></div><div text="#000000" bgcolor="#FFFFFF"><span style="font-size:14.000000pt;font-family:'FSBaskerville'">
      <br></span></div></blockquote><div><br></div><div>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.</div><div><br></div><div>However, ordering is a very nice property in practice, and many streaming scenarios requires that messages have order. If you get e.g.</div><div><br></div><div>{data, FromPid, Binary} | {done, FromPid}</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div></div>