On Monday 27 October 2003 07:54 am, Some Guy wrote: > --- Nick Tarleton <[EMAIL PROTECTED]> wrote: > > I have heard a lot about Freenet's emergent behavior and would like to > > understand just what mechanisms in the code make this happen. > > I'll do my best to answer these guys for you. > > > 1. How does specialization occur? Specifically, how does a new node's > > datastore begin to focus in one or a few particular areas?
Actually, I get this now; once a new node handles one request well, other nodes start to route to it for that, causing it to cache more data there, and also accumulate in its RT other specialized nodes. > Don't think about the datastore's specialization. The routing > specailization for the most part is supposed to cause the datastore > specialization more that vise versa. Routing specialization comes of knowing what other nodes specialize in this. If the data is to be found, however, it must eventually reach a node with the data in the DS, so ultimately routing specialization must be grounded in DS specialization. Think about it: Let's say nodes A-E all specialize in keyspace section DEADBEEF. A does because he knows to route to B, B does because he knows to route to C, and so on. However, it can't go on like this forever if you want the data to be found. So E must have DS specialization here. > > After that, how does routing specialization develop? > > Postive feedback. If a node is "good" in particular area it should get > more "good", because other nodes should give it more messages for that area > of hashspace. If it's "bad" in an area, it should get worse too. I see. > > Do nodes prefer to talk > > to nodes with similar DS specializations? > > Yes and no. The chance that two nodes know eachother should be about > inversely proportional to the "distance" between thier specializations (I > think I can informaly prove this must be the case for log(N) routing). So > a node will have many neighbors that are very close to it, but also a few > that are very different. > > > 2. How does DoS resistance work? > > DoS is a big discussion. There are two types of DoS. > A) Those that try to make the whole system unusable. > B) Those that try to censor a particular bit of data in the system. > > > According to the website (I think), if you > > have some evil nodes inserting megabytes of nonsense and some other evil > > nodes requesting it, eventually they will move close together in the > > network. What algorithm makes this happen, and won't the few nodes now > > between them still suffer? > > This is a type A attack. This resistance is supposed to happen because > nodes sometimes give thier IPs back with responses and sometimes nodes up > the chain will connect to these an shorten the chain. I'm not sure it's > 100% accurate, because the adversarial requestor can't be forced to connect > to the adversarial insertor. But, here's how I see it: A, the evil inserter, spews inserts of 1MB keys randomly to some nodes, at HTL 25. Z, the evil requestor, requests these keys from some other nodes at HTL 25. The data goes from A along random paths, sits there, and eventually returns to Z along random paths. Obviously, path shortening on insertion doesn't work. Path shortening on request will help, but won't save you. And the network doesn't know that keys from A will always be requested by Z, and these keys are randomly distributed throughout the keyspace. So, how does this 'convergence' happen, if at all? > > > 3. Recently, I saw a message about how NGR will know whether to go to a > > fast, unreliable or a slow, reliable node. Is this some complicated > > result of the estimators? > > Yes. > > > How does it know which to go to for a given key? > > Please make sure you've read this: > http://www.freenetproject.org/index.php?page=ngrouting Makes sense. But this message (which I'm afraid I don't remember) implied that it will know whether to go to a fast, unreliable or slow, reliable node for any given key. Since this isn't based on keyspace position, this can't happen, right? > > Is key size part > > of the routing calculation? (If not, it probably should be.) > > Key size is small; you probably mean the size of the data asssociated with > the key. A requester usually has no clue how large the data is until he > get's it back. > > Size is corrected for when we calculate how long it takes a node to reply. I mean data size, which IS actually known to the requestor. CHKs contain a field with the rounded-up log2 of the data size, which a really smart routing system would probably want to take into account (say, for the slow-reliable vs. fast-unreliable decision). SSKs and KSKs can stick with the mean-size *for that keytype only*. -- "I love deadlines. I love the whooshing sound they make as they go by." - Douglas Adams Nick Tarleton - [EMAIL PROTECTED] - PGP key available _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
