[erlang-questions] Sender punishment removed

[Guilherme Andrade]

On 25 January 2018 at 14:28, Jesper Louis Andersen <
jesper.louis.andersen@REDACTED> wrote:
>
> This would work exactly as advertised. When the message enters the mailbox
> on the receiving nodes end. You cannot in any way build a safe time
> construct over multiple nodes, so you opt for the next best case: a lower
> bound on the sojourn. This means that a message has spent at least XXms in
> queues inside the system. But it could have spent more time than that.
>

How would this work? Monotonic timestamps originating on different nodes
are not comparable. Let's imagine:

- There's two nodes connected through distribution: A and B;
- There's a process named Alice at node A;
- There's a gen process named Bob at node B;
- At a given instant T1, monotonic_timestamp{A} = 3s and
monotonic_timestamp{B} = 10s;
- Alice calls Bob; it attaches monotonic_timestamp{A} to the call message;
- Excluding buffering and network delays, the call message arrives at Bob
with a measured Sojourn of (10 - 3) = 7s and gets dropped, even though ~0s
have passed.

And this is the ugly case, of course. Reverse the roles of Alice and Bob
and we would get the bad case, as it would mean a lot of work would go
through even if arriving terribly late.

As an alternative, a temporary caller process could always be launched on
the same node the gen process resides in; it would be inside this caller
process that the timestamp would get attached and the actual call
performed, and so local Sojourn would be measurable, but that implies
higher saturation of the distribution channels, besides telling us nothing
of buffer or network -induced delays.

I would very much like to see this working, I just don't see a good way of
dealing with distribution. But please correct me if I'm wrong in any of the
assumptions above.


-- 
Guilherme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180125/69973047/attachment.htm>