<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>On 9/25/17 2:13 PM, Jesper Louis Andersen wrote:<br>
</p>
<blockquote type="cite"
cite="mid:CAGrdgiUOyRHQz21qePMjRtzWYbit5QsPPSf8_3iGW+CxA87szg@mail.gmail.com">
<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"
moz-do-not-send="true">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>
</div>
</blockquote>
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.<br>
<br>
Miles<br>
<br>
<blockquote type="cite"
cite="mid:CAGrdgiUOyRHQz21qePMjRtzWYbit5QsPPSf8_3iGW+CxA87szg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra</pre>
</body>
</html>