Chris Carlin wrote: > Benjamin Coates wrote: > > 4. This state persists until B sends A a "go-ahead" message, or a timeout (1 > > hour?) expires, in case B malfunctions and forgot who it owes a message. > > I instinctively question the "go ahead" part of this idea. > > Perhaps it would be preferable to instead include a suggested timeout > (based on whatever) in the "leave me alone" message?
How do we know how long the node will be overloaded? Should we just guess a number, or should we somehow try to prove a way of guessing the time the node will be overloaded (alchemy)? The purpose of this scheme is to prevent such alchemy from being written. There is no magic. When the node is grossly overloaded, it QRs everything in such a way as to stop the nodes from trying to contact them again. When the overload condition is removed, it tells the nodes that it is available again. > This way the overloaded node doesn't have to keep track of who it's told > to go away and then offer services to nodes that might no longer wish to > issue requests. Since you've suggested a timeout of an hour it seems as > if there's time for this and other similar problems to occur. > > ~Chris -Mathew _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
