Robert Bihlmeyer <robbe at orcus.priv.at> writes:
> 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.)
>
The route did succeed, so this behavior may be reasonable.
> 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.
>
CP isn't a way to punish nodes for anything and everything. It's
meant very specifically to decrease the amount of work fred spends
trying to contact nodes that are offline. The build conflict may be a
good enough reason to stop contacting that node until your node is
updated, but you don't want to trash that node's CP value for when you
do update and are able to route with 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.
>
An overloaded node still able to reject should have CP=1.0, and be
routed to whenever it's supposed to be routed to. The fact that it's
not responding to the requests means that the routing system will not
be making more references to it, and other nodes will be contacted
more often because they're successfully responding to requests.
> 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
Using CP to punish nodes that QRej is definitely not the right way.
CP is a transport level feature, that's all. It's not meant to deal
with application level problems, and shouldn't be used in that way.
Thelema
--
E-mail: thelema314 at bigfoot.com Raabu and Piisu
GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB
_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://lists.freenetproject.org/mailman/listinfo/devl
