On Fri, Mar 14, 2003 at 11:15:16PM -0500, Michael Wiktowy wrote: > I have been trying out the latest and greatest unstable builds. They > have been performing rather well showing very good resource usage ... > hovering around 40-50% load and being responsive. As of > freenet-unstable-20030313.tgz build the node has become catatonic after > 24 hours of uptime. It will not even load the gateway page. > > I was using bandwidth limiting so that it could stay in the background > and my box would still be functional. If this functionality has been > removed inthe unstable builds also ... as seems to be indicated in > Matt's post here: > http://hawk.freenetproject.org:8080/pipermail/devl/2003-March/004723.html > ... > 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. > > Some thoughts on healing the wound rather then building a bigger, better > bandage: > > The load on the network placed by each message would be made up of a > number of factors: > 1) the number of nodes that it has to pass through > - the more nodes that are involved with a particular message, the > more load each node will have to carry. > 2) the time it spends transiting the network > - the more messages that are in flight in the network at a > particular moment in time the faster circular buffers will overflow, > timeouts will cancel pending messages which will have to be resent, etc. > 3) the ratio of messages handled to messages generated for a particular node > - if there are more and more nodes that are leeches then the load > will increase for those that are active in the network and serving up > requests > > Directions for improvement: > > Item 1): > More agressive path compression ... as much as possible without > compomising anonymity > - maybe nodes should have the option of setting data source as the > node where it got the data from originally instead of itself even if it > was cached locally (improves anonymity, compresses path, makes sure that > ubernodes do not become the source of all freenety goodness ... doesn't > help prevent evil ubernodes that want to do this but it will help > unitentional ubernodeness) > A guaranteed max and min path length that can be adjustible for tuning > purposes. > - I suppose that we have a guaranteed max (maxHTL) but there is no > limit of path compression as far as I know other then a fuzzy > equilibrium that will be established between caching and path > compression ... I am more convinced that it is a fuzzy doughnut rather > then a fuzzy ball ... another reason for the "original DataSource" > setting of nodes residing in the doughnut so that they can fill in the > center ... mmmmmm ... filled doughnuts ... I'm getting hungry. > > 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. > > 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. > > Item 3): > The current trend towards making nodes more permenant will help this a > lot. There are still nodes that might like to be permanent but cannot > for different reasons > - behind NAT - perhaps some sort of polling solution or a non-NATed > buddy node system (sort of like a C/O post office addresss) could help > integrate some of these inaccessible nodes into the network > - local load too high to run on a desktop with other things going on > - if Freenet bogs down your desktop then people will not keep it on and > you will get a lot of "transient" permanent nodes screwing with the > routing tables > - 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. > > OK ... enough rambling ... I hope someone has read this far and > understood what I am talking about but I doubt it. > > /Mike -- Matthew Toseland toad at amphibian.dyndns.org/amphibian at users.sourceforge.net Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at http://80-192-4-36.cable.ubr09.na.blueyonder.co.uk:8889/0bIANZmR~K8/ 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/f8c2fc62/attachment.pgp>
