[erlang-questions] question re. message delivery

[Raimo Niskanen]

On Sun, Sep 24, 2017 at 11:24:31PM -0700, Miles Fidelman wrote:
> 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.

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.

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

What?  What is stated?

> 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?

Aah.  That would not be possible,  1 might be delivered to a Pid1,
and 3 to Pid2, if you send to a registered name.  But if you send to a Pid;
1 might be delivered and 2 & 3 discarded, 1 & 2 delivered and 3 discarded,
or 1 & 2 & 3 delivered.

The order is guaranteed while the destination is available, and if it is
not, the messages are discarded.

But if you send to a registered name the Pid behind that name may change
any time.  Still order is guaranteed - up to a point all messages are
delivered in order, then some may be discarded, then when the new pid is up
and registered all messages are delivered in order again.

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

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB