On Friday 21 September 2007 11:17, Jusa Saari wrote: > On Thu, 20 Sep 2007 20:07:44 +0100, Matthew Toseland wrote: > > > On Thursday 20 September 2007 17:37, Jusa Saari wrote: > >> What happens to the datastore when a node swaps its position? From what > >> I've understood, the requests are routed based on node locations, which > >> causes the contents of a node's datastore to reflect its position; if a > >> node changes its position to the other side of the position ring, it > >> will receive very few requests relevant to its datastore, which means > >> that the store will effectively get wiped clean every time the node > >> swaps. > >> > >> I tried to look at freenetproject.org for this, but the documentation > >> there (http://freenetproject.org/understand.html) seems to be describing > >> the routing algorithm which predated NGRouting. > >> > >> So, given this, would it make sense to simply delete from the store any > >> keys not near the current location after a swap? They can't be accessed > >> anyway except by pure luck, and will simply waste store space which > >> could otherwise be used to fill the store up with relevant keys. > > > > It's not necessary. They will be automatically deleted when new keys are > > added, in accordance with the Least Recently Used cache replacement > > algorithm. Until new data comes in we may as well keep the old data. > > Hmm... In that case, perhaps it would be worth it to remember recent > swaps? Because if we get a request relevant to our new position, the node > which last occupied it could still have the key in its datastore. > > But then again, this would mess with a pure LRU cache replacement > algorithm, neccessiating adding the closeness of the key to our current > position as a factor. Argh :(.
Not necessarily - we could remember who we've recently swapped with and ask them for the keys as a last resort, if they're closer to the key than we are. > > > Also I'd expect *generally* that long range swaps occur mostly towards the > > beginning of a node's lifetime, rather than later on. > > In a stable network with long-living nodes, yes. The few times I tried to > get into the "darknet", I lost all my contacts (from #freenet-refs or > whatever it was called) in a week or so. This would likely be true of > opennet as well; in fact I'd say that at any time, most freenet nodes have > only been in the network for a short time. #freenet-refs sucks, this we know. :( Opennet is likely to have high join/leave churn just as #freenet-refs does, and for the same reason - lots of people join, find they don't like it, and leave. And yes, this is likely to mess with routing, especially during a slashdotting. > > This could potentially mean that, since those short-lived nodes are unable > to do anything very useful, the semi-permanent network nodes which form > the "core" of Freenet will end up serving most requests, and therefore get > overloaded easily, while the nodes not directly connected to them won't be > able to find anything. Also true. Hopefully announcements will do something to limit the damage. It might be worth considering increasing the opennet peers limit, to get more connections in case many of them are unstable, and to speed up routing generally (fewer hops) ... otoh, some attacks are easier, and very few pure darknet nodes will have 30+ connections... > > Is there a way to simulate the effect of constantly adding and shortly > afterwards removing large amounts of node to Freenet? It's been done. By the gnunet folk who wrote a paper on it, and by vive. More simulations are however always welcome. The conclusion was that it causes node locations to cluster together in a really unhelpful way (you can also achieve this by a deliberate attack); randomly resetting locations from time to time seems to resist this. -------------- 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/tech/attachments/20070921/fb1ef51f/attachment.pgp>
