Gianni Johansson <giannijohansson at mediaone.net> writes: > 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.
Ok. But like Tavin said, the routing had a hard time when almost no node successfully returned data. > > Reason=Build older than last good build 453,HopsToLive=5,}} > What this really means is that your node is obsolete and you should > upgrade it. Sure -- I just didn't because I forgot about some sticky CVS tags being in effect. These build-to-old failures should probably be escalated when a large share of one's peers keep returning them. Hunting through the debug-level log is ok for a development branch, but a stable release audience will probably be at a loss unless fproxy alerts them. (One solution of course is to never shove out a mandatory build in a stable series.) > The CP mechanism is to keep track of which nodes are contactable. Hmm, being too busy seems like a link-level problem to me. As I see it, it was treated as such until returning QRej rather than outright closing connection broke this assumption and punted the busyness problem up to the routing level. It could be that the routing is perfectly capable to deal with that -- I don't know. > 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. I agree, although Tavin's idea of keeping the ref for future use (when our build is upgraded) is probably even better. At least for times when node refs don't go stale as quickly as they seem today. -- 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/20020124/6d202853/attachment.pgp>
