See this paper:
http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf
pdf for a description of Lamport clocks.
The method: each time a process sends a message to
another it sends a serial number (which comm already
does.) Upon receipt the receiver of a message sets its
serial number to the larger of its serial number, and
the serial number sent by the sender.
In a two-endpoint comm connection this makes no
difference, but in an n-endpoint comm connection, the
serial number of each endpoint's serial will always be
one greater than the last serial number it received.
This enables a server to establish a partial ordering
between requests when different systems' real-time
clocks run at different rates - a sender whose clock is
greater wins, as it has evolved through communication
events, and is in some sense 'later' than the other.
The only current constraint on serial is that it be
locally unique, there is no requirement that it
monotonically increase, or that it only increase by
one. The proposed change would specify that serial
increases monotonically, and change the protocol to
include an extra timestamp on reply/callback protocol
messages: the serial value of the replying endpoint.
Comm provides for protocol extension, and the
implementation would degrade to the previous protocol
version's behavior.
A patch will follow.
Logged In: YES
user_id=75003
This might also need a way to ask for the current serial
number, no ? I do not believe that we have that already, so
it needs to be added.
Logged In: YES
user_id=19214
We're covered: [$chan config -serial] will give us the
serial number.
Logged In: YES
user_id=75003
Do we have a patch for this ?