I agree that adding special routing tables for every single situation is just asking for confusion. Also, asking nodes to make the automatic decision to blacklist funky neighbours may be "cutting of your nose to spite your face" and may leave out vast quantities of untapped freenet capacity.
I would like to propose a flexible plan that might get around these issues. There is no doubt that there is some importance to a node knowing the "quality" of its surrounding neighbours. This could include ping time, node uptime, node cpu load, available bandwidth and could be passed back and forth to nodes through the handshaking mechanism (a mechanism which has amazing application potential for future freenet development ... for all those people questioning "why do we bother with a handshake?"). This quality data could be stored in a single table mapping various IPs to their associated vitals. This data would be useful to many different parts of the code but here I would single in on routing ... Instead of letting the nodes have sole descretion on the routing of data requests (and possibly inserts ... though this would be far less useful and possibly lead to your insert being harder to retrieve for everyone) have a "type of service" flag associated with the datarequest that will bias the routing of requests. This sort of thing is already done in the TCP/IP protocol (TOS bits indicating maximum throughput/minimum delay/maximum reliability/ etc.) and only one type of service can be specified at the creation time of a packet. The TOS flags that I would suggest would be: normal : (default) the way things are routed now throughput : the node accesses the node status table and strongly biases the routing to nodes with high bandwidth speed : the node accesses the node status table and biases routing to nodes with low ping times load : bias routing to nodes with low cpu load random : just selects a node on the list at random (the desparate, shotgun option to request data from those hard to reach places ... might get data from that lone node that still holds some rare items) and many many more as future needs/ideas arise. These TOS flags could be associated with the ID so that they get passed from node to node and nodes that do not understand TOS would just route them as normal. For instance, a random number is generated for the message ID and a number can be added to the beginning of the ID that could represent the TOS byte. If tacking this first number on the front would put the number out of range from 64 bits then the last number can be truncated until the ID is coerced into range. Comments? Mike > Date: Sun, 16 Apr 2000 21:00:04 PDT > From: Mike Glover <mpg4 at duluoz.net> > To: freenet-dev at lists.sourceforge.net > Subject: Re: [Freenet-dev] hwo do we want it? > Reply-To: mpg4 at duluoz.net > Reply-To: freenet-dev at lists.sourceforge.net > > On Sun, 16 Apr 2000, Oskar Sandberg wrote: > > How do we want the discouraging of nodes that don't reply to work? Should > > we > > simply remove the the reference in question (which doesn't mean removing > > all > > references to that node, only one at a time) or should we include some > > sort of > > extra blacklisting system where nodes that have bad uptimes are avoided > > by some > > probability, or is it time we did a complete redesign of how the node > > chooses > > nodes to forward to so that, together with closeness, it also considers > > the > > reliability, locality, and speed of the other node. > > I think that we should avoid adding in special-purpose tables like > "blacklisting" into the node. Eventually, there will be eleventy > "special" tables that a node has to consult before it does anything, > and the code to do that will be a mess. > > I like the "scoring" idea: nodes are given a score for each closeness, > reliablility, speed, etc. Then multiply each score by it's > user-configurable weight and add them up. Highest score wins. Later, > we can add hooks to automatically take certain actions when a score > is below a given level. > > -mike > > > > > Can we decide this now? > > > > -- > > > > Oskar Sandberg > Mike Glover wrote: > > Then multiply each score by it's > > user-configurable weight and add them up. > > User configuration really doesn't fly for things like this. The > behavior of Freenet as a whole is an emergent phenomenon which depends > on the behavior of the individual nodes. The behavior of the nodes > needs to be carefully controlled to produce the desired behavior, or > Freenet will fragement, lose data, die due to message floods, etc. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
