[mnet-devel] notes from IRC -- who to hello

[Arno Waschk]

for the moment i would rather prefer sending too many hellos (which can't 
be many according to our actual MT desity) then cutting them down, since 
then we can see whether we can have up-to-date data being sent by MTs to 
the brokers, and then we can see whether we still have that Bermuda black 
hole. If not we have a stabel network, and i would propose cutting down 
message sending redundancy(spelling?) then if not showing to be urgent 
before. in the moment one single left out hello to one certain MT (due to 
a peerman level or what ever) leeds to that broker being unmetioned in 
list servers request due to 20 minute timeout....

On 7 Jan 2004 12:05:50 -0500, Bryce Wilcox-O'Hearn <zooko at zooko.com> wrote:

>> thanks, i had read that code already. it leads to not asking
>> known-to-be-online MTs.
>
> How can that happen?
>
> The MT which has failed the least recently is always returned by 
> peerman.  In
> addition, other MTs in the same "liveness level" are also returned.  So 
> for
> example if there are two MTs in liveness-level-0, and then one fails 
> (i.e., you
> can't open a TCP connection to it, or you send a message to it and then 
> you
> don't hear back within the timeout), then the one that failed will be 
> demoted to
> liveness-level-1 and (with 50% probability) will be excluded from the 
> next
> hello.  However, if the other one also fails, then both will be demoted 
> to
> liveness-level-1, and since liveness-level-0 will then be empty, all MTs 
> will
> get promoted one level until liveness-level-0 is non-empty again.
>
> I don't see how the current algorithm can lead to a problem where there 
> is an
> MT which is known to be online but which is not helloed.
>
> Oh, but maybe it is the log(n) selection that is causing the problem.  
> For
> example, if there are 3 MTs returned from peerman, then this algorithm 
> sends
> "hello" to only two of them.  You are saying that this "minimum MTs" 
> number
> should be not "mojoutil.logish()", but a higher number?  That sounds 
> reasonable.
>
> But that there is already a mechanism in place to handle the case that 
> all of
> the hellos fail.  In that case, it demotes the failing MTs and tries 
> again,
> I *think*.
>
> Before increasing the "minimum to hello" number we should see if that 
> "retry
> hello on failure" mechanism didn't work, and if it didn't work why not.  
> Do you
> agree?
>
> Regards,
>
> Zooko
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> mnet-devel mailing list
> mnet-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mnet-devel
>



-- 
www.arnowaschk.de


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
mnet-devel mailing list
mnet-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mnet-devel