[erlang-questions] question re. message delivery
Mon Sep 25 08:53:09 CEST 2017
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
More information about the erlang-questions