On Tue, Jan 22, 2002 at 06:58:51PM +0100, Oskar Sandberg wrote:
> On Tue, Jan 22, 2002 at 11:49:00AM -0600, Edgar Friendly wrote:
> > Robert Bihlmeyer <robbe at orcus.priv.at> writes:
> >
> > > 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.
>
> I agree with thelema here - clearly the routing table is adaptive
> already, there is no need to make the CP include all reasons to avoid a
> node. Specifically, the CP is good for temporary errors that can be
> recovered from suddenly, while an overloaded node (for example)
> indicates a constant problem.
The way Gianni has done the routing table, CP is really being used to
store long-term information about the node, while the other factors
(failure intervals, failures per interval, interval timeouts, masking
effects) are used to deal with temporary network errors.
-tc
_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://lists.freenetproject.org/mailman/listinfo/devl
