<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>On 9/24/17 11:53 PM, Raimo Niskanen wrote:<br>
</p>
<blockquote type="cite"
cite="mid:20170925065309.GA41893@erix.ericsson.se">
<pre wrap="">On Sun, Sep 24, 2017 at 11:24:31PM -0700, Miles Fidelman wrote:
</pre>
<blockquote type="cite">
<pre wrap="">See below....
On 9/24/17 6:10 PM, zxq9 wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 2017年09月24日 日曜日 16:50:45 Miles Fidelman wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Folks,
I've just been re-reading Joe Armstrong's thesis, and I'm reminded of a
question that's been nagging me.
As I understand it, message delivery is not guaranteed, but message
order IS. So how, exactly does that work? What's the underlying
mechanism that imposes sequencing, but allows messages to get lost?
(Particularly across a network.) What are the various scenarios at play?
</pre>
</blockquote>
<pre wrap="">This is sort of backwards.
Message delivery is guaranteed, assuming the process you are sending a
message to exists and is available, BUT from the perspective of the
sender there is no way to tell whether the receiver actually got it,
has crashed, disappeared, fell into a network blackhole, or whatever.
Monitoring can tell you whether the process you are trying to reach
is available right at that moment, but that's it.
The point is, though, that whether the receiver is unreachable, has
crashed, got the message and did its work but was unable to report
back about it, or whatever -- its all the same reality from the
perspective of the sender. "Unavailable" means "unavailable", not matter
what the cause -- because the cause cannot be determined from the
perspective of the sender. You can only know this with an out of
context check of some sort, and that is basically the role the runtime
plays for you with regard to monitors and links.
The OTP synchronous "call" mechanism is actually a complex procedure
built from asynchronous messages, unique reference tags, and monitors.
</pre>
</blockquote>
<pre wrap="">
Note that I didn't ask about the synchronous calls, I asked about raw
interprocess messages.
</pre>
<blockquote type="cite">
<pre wrap="">What IS guaranteed is the ordering of messages *relative to two processes*
If A sends B the messages 1, 2 and 3 in that order, they will certainly
arrive in that order (assuming they arrive at all -- meaning that B is
available from the perspective of A).
</pre>
</blockquote>
<pre wrap="">
But that's the question. Particularly when sent via network, 1, 2, 3
may be sent in that order, but, at the protocol level, they may not
arrive in that order.
</pre>
</blockquote>
<pre wrap="">
What protocol level?
Erlang distribution has to use or implement a reliable protocol. Today
TCP, but anything is possible. Note that this protocol is between two
nodes, both containing many processes. But the emulator relies on the
transport protocol being reliable.
</pre>
</blockquote>
<br>
No. It doesn't. It could simply send UDP packets. I'm asking
about implementation details. In Joe's thesis, he says that the
behavior is a "design choice." I'm asking about the implementation
details. How does BEAM actually handle message delivery - locally,
via network?<br>
<br>
<blockquote type="cite"
cite="mid:20170925065309.GA41893@erix.ericsson.se">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
With a reliable transport protocol - say TCP - if the message-containing
packets arrived as 1, 3, 2, the protocol engine would wait for 2 to
arrive and deliver 1,2,3 in that order. If It received 1 & 3, but 2 got
lost, it would request a re-transmit, wait for it to arrive, and again,
deliver in that order.
But the implication of Erlang's stated rules is that an unreliable
transport protocol is being used, if you send 1, 2, 3, and what arrives
</pre>
</blockquote>
<pre wrap="">
What? What is stated?</pre>
</blockquote>
From Joe Armstrong's Thesis:<br>
<br>
"<span style="font-size: 14.000000pt; font-family: 'FSBaskerville'">Message
passing is assumed to be unreliable with no guarantee of
delivery."
</span> <br>
<br>
"<span style="font-size: 14.000000pt; font-family: 'FSBaskerville'">Since
we made no assumptions about reliable message passing, and
must write our application so that it works in the presence of
unreliable
message passing it should indeed work in the presence of message
passing
errors. The initial e</span><span style="font-size: 14.000000pt;
font-family: 'FSBaskervilleExpert'">c</span><span
style="font-size: 14.000000pt; font-family: 'FSBaskerville'">ort
involved will reward us when we try to scale up
our systems."<br>
<br>
</span><span style="font-size: 14.000000pt; font-family:
'FSBaskerville'"></span><span style="font-size: 14.000000pt;
font-family: 'FSBaskerville'">"2. Message passing between a pair
of processes is assumed to be ordered meaning that if a sequence
of messages is sent and received
between any pair of processes then the messages will be received
in
the same order they were sent."<br>
<br>
</span>"<span style="font-size: 14.000000pt; font-family:
'FSBaskerville'">Note that point two is a design decision, and
does not reflect any under-
lying semantics in the network used to transmit messages. The
underlying
network might reorder the messages, but between any pair of
processes
these messages can be bu</span><span style="font-size:
14.000000pt; font-family: 'FSBaskervilleExpert'">ff</span><span
style="font-size: 14.000000pt; font-family: 'FSBaskerville'">ered,
and re-assembled into the correct order
before delivery. This assumption makes programming message passing
applications much easier than if we had to always allow for out of
order
messages."<br>
<br>
---<br>
I read this as saying, messages will be delivered in order, but
some may be missing. <br>
<br>
I'm really interested in this design decision, and how it's
implemented. (I'm also interested in the logic of why it's easier
to program around missing messages than out-of-order messages.)<br>
<br>
</span>Miles<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>