On Tuesday 22 January 2002 04:38, you wrote:
> > After digging around the innards of Fred I came to the conclusion that
> a QueryRejected always results in a call to routeSucceeded (see
> Pending.java:102) which will (in CPAlgoRoutingTable.java:159) be
> treated as a success, i.e. that the peer is fine and a good target for
> future requests (CP goes up). (I'm no expert on Fredology so this
> hypothesis may be wrong.)
Kind of. CP really only means that you can get a connection to the node.
The routing should decide whether or not the node is a good target for future
requests.
>
> I don't think this behaviour is correct. For example a QueryRejected
> {Close=false,Sustain=false,DataLength=0,{UniqueID=...,
> Reason=Build older than last good build 453,HopsToLive=5,}}
> is certainly no good reason to keep contacting the node often.
What this really means is that your node is obsolete and you should
upgrade it.
>
> Second, isn't this counter-productive to the recent changes that
> overloaded nodes respond by rejecting queries? I.e. an overloaded node
> still able to cleanly reject will rise higher in CP and get hammered
> even more.
>
> My suggestion is to decrease CP in the first case, or even dereference
> that peer outright (it's very improbable that it will decrease its
> build# later). In the second case, decreasing CP or at least keeping
> it constant (peer is alive but not well) would be good.
The CP mechanism is to keep track of which nodes are contactable.
Contactable means a) you can get transport level connectivity to the node and
b) the node's link crypto accepts the key you used. Messing with the CP to
solve the version mismatch is the wrong thing to do -- you don't want to cut
the CP of the node that's not responding because your node is obsolete, you
want to completely dereference it, so your node never tries to contact it
again.
We could quickly fix the problem (for future versions) by checking the
message String in Pending, and dereferencing nodes that return "Build older
than last good build*", but that would be a pretty gross hack. Otherwise, we
could change the protocol to include a reason code in the QueryRejected.
This is a real problem, even for the new nodes. My public node was sending
at least 1 obsolete build QR per second last night.
Oskar what is your call? a) quick hack b) change protocol c) do nothing
because this problem shouldn't come up that often.
Why isn't the routing adapting to reduce the number of requests to nodes that
don't ever respond?
--gj
--
Freesites
(0.3) freenet:MSK at SSK@enI8YFo3gj8UVh-Au0HpKMftf6QQAgE/homepage//
(0.4) freenet:SSK at npfV5XQijFkF6sXZvuO0o~kG4wEPAgM/homepage//
_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://lists.freenetproject.org/mailman/listinfo/devl
