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.)
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.
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.
--
Robbe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.ng
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20020122/f5cdee0c/attachment.pgp>
