>>I think the only necessary constraints on routing algorithms are those I >>outlined in my reply to Oskar: a node should route every insert to somewhere; >>a node should route any two inserts with the same key to the same place; a >>node should route an insert and a request with the same key to the same >>place. This rules out adaptive routing, but it doesn't rule out weighting th e >>links with fixed weights. > >Not that the second constraint isn't even true of the current or any model >we have discussed. Where a request/insert gets sent is a function of the >current state of the datastore and depends greatly (in fact, it may very >well change with every time that key is requested).
You're right, I have oversimplified because I didn't take caching into account. However, I don't think the existence of caching violates that second constraint. Think of memory caches - the fact that you can put an SRAM cache in front of your DRAM to reduce average latency doesn't affect the principle that the same DRAM address should always point to the same item (if you need to go to DRAM). Similarly, the fact that you may be able to retrieve an item from the data store doesn't affect the principle that the same key should always get routed to the same node (if you need to go outside your own node). The other oversimplification I made was to ignore changes to the node's view of the network due to node discovery (the DataSource field). This obviously violates the second constraint, and in fact I think it is a possible point of attack for somebody who wants to damage the efficiency of the network. If a malicious node gives a different DataSource for every document it serves up, nodes will constantly update their routing tables and there will not be time for documents to cluster properly. You can introduce entropy into the network topology, undoing the effects of caching (which tends to reduce the randomness of data distribution). I need to think hard about this, and now is not the time because I'm going to the pub in a minute. Please save your flames until Monday. :) Michael _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
