On Wednesday 03 November 2010 20:00:48 Robert Hailey wrote: > > Example patch attached. Small, but untested!
Could you please explain what it is that you think is going on, and what the patch will do to fix it? In theory, announcements are routed to a specific random keyspace location (expressed as a number), starting from the seednode. They rapidly approach the target location, and thus having the opportunity to connect on each node should roughly give us the 1/d distribution that theory tells us is necessary: A few long links and a lot of short links. As far as I can see, your theory is that 1) announcements are making up a large proportion of a node's connections, and 2) announcements are tending to get a bunch of noderefs that are *all* very close to the target, rather than getting the 1/d distribution which we need, which would include lots of short links but also some long links. Which results in all your peer locations being clustered together, with apparently no long links, as you've shown. This is plausible given that I'd expect the nodes close to the seednodes, where you might get your few long links from, to be overloaded. What can we do to further investigate this theory? It would be good to gather some more data before applying potentially major changes. What exactly does your patch do, and what is it intended to do (not necessarily the same thing)? I include our discussion on IRC for reference: [16:27:43] <osndok> toad_: I've got an announcement question for you [16:29:33] <osndok> toad_: it seems like the algorithim sends replies shallow-first, and the receiver accepts first-come-first-serve (at same priority as path folding). Is this intentional? [16:30:01] <osndok> it does not seem like it qualifies as destination sampling, therefore :( [16:31:09] <osndok> is it possible that this is the "clump" issue? [18:57:44] <osndok> toad_: ack announcement question? [19:05:45] <toad_> osndok: will look into it later, i do not understand; we give opportunities for each node on the path to reply, so i'd expect that you'd get some long links (early on) and some short links (late on) [19:06:16] <toad_> arguably stuff close to the seednodes is less likely to accept so it may be skewed towards short links -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101104/9d515e6e/attachment.pgp>
