clayton rollins zei: >>Quoting Raphael Manfredi >> >>I expect that a lot of PARQ entries will obsolete at some point: >>servents that >>have requested them will disconnect and no longer be reacheable. Only >>servents up 24x7 will be able to maintain their queued entries, >>
> <<<< SNIP >>>> > A reasonable solution, it seemed to me, would be to count the amount of > timeouts/connection failures for those hosts and remove all entries if > this exceeded the user defined amount, using that as a guideline for a > non-existant host. Of course, connection failures like "too many > uploads" wouldn't enter into this, as they at least indicate that a > servent is there. Well, according to the PARQ specifications a host which didn't retry within the timeout specified in the Retry-After header should be removed from the queue. However, if queues can get large, this isn't a modem friendly thing. A cable user would be able to have an uptime of 24x7 (I do) and thus maintaining their queue position. A modem user which is only online 1 a 3 hours a day will never be able to reach an upload slot. So I wondered if it would be a good thing to reserve a queued slot for 7 days. However, if such a slot isn't retried within the Retry-After period it doesn't move forward into the queue, but stays at the current position.This will give the '1 hour online' modem users the ability to retreive an upload slot, allthough it might take a bit longer than a cable user.To determine wether an (or or more) upload slot is already reserved for client the GUID should be used I guess as IP and port might and probably will change when a modem user reconnects (does this still 'break' morpheus?). I know this is not according to the PARQ specs but I do think it is another point for 'fairness'. Does it make sense? With regards, Jeroen ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
