On Wednesday 19 December 2001 17:55, Ian wrote: > > I have noticed that the nodestatusapplet doesn't seem to work if there > are no working references in the datastore (hopefully not a common > occurance). I'll fix this.
> > Additionally, the node testing code should possibly consider, if all > references are backed off, trying the backed off reference with least > time to go. Unfortunately, I don't think this will help. >From what I can tell the reason the network is so bad now isn't that there are too many zombie nodes out there that are never responding. The problem is that the network is massively overloaded. I was seeing something like 70 incoming connection attempts per minute last night on my public node. Of which it only accepted < 5%. This while it was handling ~=80 incoming requests per minute. The reason noderefs are backed off in the first place is because they have failed to respond. Retrying them even harder won't do anything but increase traffic. It becomes a race to the bottom. Here are some things that I think might improve performance. 0) Bump up Version.buildNumber and Version.lastGoodBuild to get any old nodes without the Restart htl decrement fix off the network. see: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/freenet/Freenet/node/states/request/Pending.java (HEAD branch) 1) Come up with better diagnostics to figure out where all the traffic is coming from. I think thelema has been working on this. 2) Implement per host inbound connection limits. I think what's happening now is that your node manages to contact a few other nodes and accumulates a pool of cached connections to them which is constantly recycled. That's why your node reliably connects to so few other nodes, and why the nodes that it does connect to change seemingly at random. Since there's a fixed connection limit (30 by default), once the OCM connection cache fills up almost all inbound connections from other nodes will be rejected. Placing a per host limit on inbound connections would decrease the severity of this problem. I have been looking into this. It's kind of tricky because you don't want to reject an incoming connection for a message chain that your node originated, but you don't have the message chain ID until after you have accepted the connection. Any ideas? 3) Implementing throughput limits If we know that fred has a maximum throughput rate, it shouldn't try to handle more requests than that, or it will just oversaturate downstream nodes. Of course it goes without saying that the DS bug needs to be fixed too. --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
