[erlang-questions] question re. message delivery

[Miles Fidelman]

See below....


On 9/24/17 6:10 PM, zxq9 wrote:
> On 2017年09月24日 日曜日 16:50:45 Miles Fidelman wrote:
>> 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?
> 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.
>

Note that I didn't ask about the synchronous calls, I asked about raw 
interprocess messages.

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

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.

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 
is 1, 3, 2 - then what would be delivered to the receiving PiD is 1 & 3 
and 2 would be discarded.  Is that a correct assumption about the 
underlying transport mechanism?  Is that guaranteed behavior?


Miles Fidelman

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