Hmm. It is possible that your node is suffering from the increased aggressiveness of the ARK resolution code; I changed it from 20 consecutive failures to trigger a lookup to 10... is it a very slow, or very busy node, or one with a very large rtMaxNodes?
On Sat, Mar 15, 2003 at 01:51:11PM -0500, Michael Wiktowy wrote: > > > 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 > -- Matthew Toseland toad at amphibian.dyndns.org/amphibian at users.sourceforge.net Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at ICTHUS. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20030315/1f8f8460/attachment.pgp>
