[Spread-users] Delays in receiving messages

[Kevin Everets]

>> http://lists.spread.org/pipermail/spread-users/2010-July/004316.html
> Definitely worth a try, at least.  Will report back with the findings.

All of the daemons were built as 32-bit binaries, so unsurprisingly
this didn't appear to have an effect.

There's a theory being floated about hitting the Hurry_timeout, and we
wanted to see if this fits (theoretically, or in current
implementation):

The problem seems to happen when the second daemon (the common sender)
believes the leader is holding the token, but the token is still
"in-flight". The second daemon sends a hurry request to the leader
while the downstream daemons are still forwarding the token around.
The leader then responds by re-transmitting the in-flight token, but
the second daemon has already seen that token and does not transmit
anything. When the leader finally sees the original token there's been
no messages sent and hence he holds the token.

Is that the expected behaviour?  It seems to fit what's currently happening.

Here's a short example:

1. The network has been quiet.
2. The leader sends the token for the final time before holding it for
the hurry timeout
3. The second daemon receives the token and forwards it with no messages sent
4. The second daemon receives a message and sends a hurry request
5. The leader receives the hurry request and retransmits the old token
6. The leader receives the original token, no messages were sent.
Leader holds the token and starts the hurry timeout
7. The leader receives and ignores the retransmitted token
8. 2 second delay until the hurry timeout expires

Does that seem plausible?

Cheers,

Kevin (and Brian)