[erlang-questions] question re. message delivery

[zxq9]

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.

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). If C sends B the messages 4, 5, 6
in that order those will also certainly arrive in that order for B.
If A sends B and C the messages 1, 2 and 3, and as a reaction C starts
sending B the messages 4, 5, 6 -- we can never know what order of
interleaving these will have.

It could be [1,2,3,4,5,6], or [1,2,4,5,3,6] or [1,4,5,6,2,3] or whatever,
but only the relative ordering between a pair of processes can be known.


A digression about design implications...

One magical side effect of these strict guarantees AND strict ambiguities
is that right from the start of a project in Erlang, even one running on
a local system, you wind up staring the CAP theorem straight in the face.
This tends to result in a better understanding of the constraints
introduced by concurrency and distribution because they are present in the
mind of every developer right from the start. The general outcome I've
noticed (but don't know how to quantify with a metric of any sort) is
that consideration of design tradeoffs rules architecture, even on a
subconscious level, and this really bears itself out as a project matures.

-Craig