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. 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. Making the comm/encryption setup and tare down as quick as possible should be a constant endeavour. 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. OK ... enough rambling ... I hope someone has read this far and understood what I am talking about but I doubt it. /Mike _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
