On Wed, Oct 15, 2003 at 01:26:34PM -0500, Brandon Low wrote: > That sounds like a pretty good idea overall, things to consider: > -How long does the rejection last? Sometimes a node (mine for instance) > gets locked up for unknown reasons, but will be back and fully > functional within 5 minutes, if we start rejecting all queries from a > node we should make sure we allow again when it becomes contactable (or > remove it from the deny list once all connections to it close)... a bit > complex.
Initially I am assuming that the node has NEVER been successfully contacted, despite several attempts... we will continue trying to contact it. I'm not absolutely sure how this would interact with message queueing - if we have tried to contact it, we've wanted to send something to it, so presumably we accepted a request at some point. > -How does this change effect overall success rates? Sometimes a node > may be firewalled (accidentally or on purpose) but have worthwhile data > that we can eventually get from them via the connections the open to us. There is an argument that such behaviour is malicious. It certainly is not conducive to path folding, which remains an important mechanism... However, "hostile environment" nodes would operate in exactly that manner, so maybe we should accept requests from nodes in our routing table as long as they keep adequate connections open to us. > > Assuming you address my first point so that nodes don't stay blacklisted > when they were just having temporary problems then I for one am for this > adjustment. > > Another idea to reduce overall loading problems we are experiencing > might be to expand the default (or suggest raising) the failure table > size while keeping the failure table time the same, this change would > probably help the network cope better with frost. > > --Brandon > > On Wed, 10/15/03 at 19:14:16 +0100, Toad wrote: > > Suggestion: > > What if we were to reject all queries from any node which either has no > > return address, or we have tried to contact and it has never succeeded > > and failed more than once? This would substantially discourage nodes > > from antisocial behaviour, eliminate some useless load, and so on. > > Especially since what connections they do have will be quickly occupied > > with trailing fields. That will however change when we have > > multiplexing, and this would have to be reevaluated. Any suggestions for > > wider freeloading measures would be interesting too. > > -- > > Matthew J Toseland - [EMAIL PROTECTED] > > Freenet Project Official Codemonkey - http://freenetproject.org/ > > ICTHUS - Nothing is impossible. Our Boss says so. > > > > > _______________________________________________ > > Devl mailing list > > [EMAIL PROTECTED] > > http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl > _______________________________________________ > Devl mailing list > [EMAIL PROTECTED] > http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
