Re: Delays in receiving messages

Kevin,

It has been a while since I touched that code, but I think that
it is likely that the scenario you present will lead to the representative
holding the token unnecessarily. If so, this is entirely my fault -
you got me here algorithmically :)

We'll need to think of an elegant algorithmic solution for this - should
not be too hard, but may take a bit of time.

Meanwhile - here are two ways fix this behavior in a non-elegant way:

1. Edit the file protocol.c in the daemon directory and modify the Is_token_hold
    and To_hold_token functions to always return (0).
    This will avoid the representative holding the token.

2. Alternatively, you can reduce the hurry timeout to a more acceptable value (50ms?)

Thank you for tracking this. I guess one learns something every day!

	:) Yair.


On 2/1/11 11:26 AM, Kevin Everets wrote:
>>> 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)
> 
> _______________________________________________
> Spread-users mailing list
> [email protected]
> http://lists.spread.org/mailman/listinfo/spread-users