On Thu, Aug 16, 2007 at 02:14:48PM +0100, Michael Rogers wrote: > vive wrote: > > Note that this is a natural part > > of running the swapping algorithms and having some tight-connected > > neighborhoods. > > I see - so we're talking about clusters that already exist in the > topology being reproduced in the locations; would you also expect > location clustering to occur in opennet, where there are presumably no > tight clusters in the topology?
Perhaps even then, since opennet does not change the fact that some positions flow in, some flow out with short-lived nodes. A pure opennet should not hold tight clusters on average, but still variations due to the random influence of destination sampling. Even from randomness, there could be some weaker clustered nodes that have happened to get close positions by chance. The goal is to know whether a low-frequent but steady in/outflow of positions through the system will add to even slight clustering in positions (if it happens even under opennet, then it can surely happen in opennet+darknet). I'm not claiming it will typically happen, but its good to experiment with it to know some about how important clustering is. > > Once in a while the randomized position from a newbie node will fit well > > enough > > with the later group, so some nodes in that cluster will want to consume > > (with > > swapping) the newbie addresses if it lets them specialize even further > > (brings > > them closer in keyspace, due to the nature of the swapping algorithm). > > That would make sense if there were only a single cluster of long-lived > nodes. But haven't we always assumed that the social network contains > many clusters, with a Kleinberg-like overall structure? If that's the > case, there are not only strong ties pulling each cluster together - > there are also weak ties between clusters, stretching the clusters out. > The nodes in each cluster shouldn't become more and more tightly > clustered, even if they have a constant supply of suitable locations, > because the inter-cluster ties should counterbalance the intra-cluster > ties. If that's not happening, it seems like the problem is with the > topology (too few inter-cluster links) rather than with churn. Just because the topology is not tightly clustered, it does not mean it can not vary to produce the result by accident (using destination sampling). The clusters may be "stretched out" in the network, but close on the circle thus specializing in addresses/data. We need to check for it at least over some different scenarios. > > Using the current locations is not the same as generating the Kleinberg > > model > > from the beginning. > > Really? The connection probabilities are independent, so I would have > thought that if you removed a node and replaced it with a new node, the > new node's links would be independent of the existing links (and thus > could be generated using just the current locations). Should be correct directly after generated from Kleinbergs model. But what do you mean with current locations? Referring here to the current locations on the circle, where closeness does not have to mean being close in the network after having swapped and done destination sampling (where positions affect swapping). Is your suggestion to introduce nodes in roughly the same part of the network where others just disappeared? As a side note, I have looked through the freenet opennet implementation. It seems like 5 minutes is a minimum time having a connection before being able to drop it for another destination sampling, if a node has accumulated the max 15 opennet peers already. (So if destination sampling happens to produce some clustering for a while, it may be there for a period, as with the speculation above.) Swaps are initiated every 2 seconds if not locked, on the other hand. Are the opennet values experience from previous implementations or under some current experimentation? :-) (when I originally tried to understand destination sampling, it was depending on probabilities for rewiring rather than times) Best, /Vilhelm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20070817/f313648f/attachment.pgp>
