> From: Matthew Toseland <toad at amphibian.dyndns.org> > Date: 15 Mar 2003 04:26:22 +0000 > > On Fri, Mar 14, 2003 at 11:15:16PM -0500, Michael Wiktowy wrote: > > I would guess that that would be responsible for the recent DOS flood my > > node is getting. > > > > Removing this feature was like ripping off a bandage without the wound > > having healed first it would seem. > > You are misinterpreting. I disabled bandwidth limiting _FOR > AUTHORIZATIONS ONLY_. This is a very small amount of bandwidth, it > occurs once on every connection open. It was also essential for > performance since the bandwidth limiter seemed to be a major cause of > the ridiculously long connectingTime's we were seeing.
Yes I was misinterpreting what you meant by "during setup". While this may not be the culprit, the fact remains that my node went from running quite processor-friendly after running for days on end to going comatose. It seemed to be logging still, I just couldn't connect to it locally (and therefore could not get further diagnostics) and it was slowing down my system. It may be the weird slowdown that occurs just before every release ... hmmmmm ... lots of new transient-permanent nodes? Someone load testing Freenet? Is there something in the node that makes sure that each node connection getting handled get equal share of its time or is it first come, first served or the faster the requester, the first served? Is there a FCP bypass that will allow local clients in at the highest priority so that they can get diagnostics on a dazed node? ... > > Item 2): > > More utilization of already open persistent connections. Perhaps a bias > > towards "close enough" still open connections rather then opening a new > > one (and closing an old one) to a node that is slightly closer. Might > > lead to a more statically linked mesh of nodes. Still needs a bit of pot > > stirring to defy traffic analysis but perhaps not the tempest that the > > routing table is now. > > No way. We cannot compromize routing to reduce hop times, it will be a > disaster. What we can do is implement multiplexing to reduce the need > for multiple simultaenous connections to the same node, and nio to let > us keep 2-3x rtMaxNodes connections open at once without using > gazillions of threads. What you suggest as your future actions are very good ideas. I was not suggesting breaking routing but rather investigating the trade off between routing to closest-open-connection-in-routing-table rather then closest-in-routing-table. Multiplexing over one connection would definitely be a requirement first otherwise there would be no savings if you had to open *another* connection to the same node. It is the trade off between adding a few open connection hops to the route vs. going the more direct route but having to take the time to encrypt a tunnel first. Something left for post 0.5.x I suppose. > > > > Making the comm/encryption setup and tare down as quick as possible > > should be a constant endeavour. > > That is precisely what I was engaged in in the above mentioned change. Now I see what you were doing. If that is the only significant thing that you did between build 678 and 681 then that might have caused my node to become very unresponsive. You might want to prevent authorization flooding by forcing remote nodes to authorize one connection per remote node at a time. Once again, multiplexing might help with this since you could conceiveably only allow one incoming connection per remote node. ... > > - nodes running for only a short period of time - if a node can pop > > out without disruption (connection handoff/no new connections while > > others finish off while shutting down) and become a functional part of > > the network quickly upon start up (either first time or after a > > temporary downtime) freenet will be a better place. > > Routing has become rather more dynamic recently. How so? Excessively dynamic routing will just add more load to Freenet as a whole as routing tables will get outdated quicker. Or do you mean that holes in the routing are worked around quicker and new nodes integrated quicker? I don't have any evidence of ARKs working as they should since all my diagnostics pages are blank for those parameters. There are a few ARKs showing up in my routing table though. Thanks for responding. /Mike message thread breakage due to replying to digest -- Michael Wiktowy <mwiktowy at gmx.net> _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
