On 2010/11/04 (Nov), at 3:06 PM, Ian Clarke wrote: > On Thu, Nov 4, 2010 at 2:09 PM, Robert Hailey <robert at freenetproject.org > > wrote: > As best I can see, then, there may be major problems with the > current announcement and path folding implementations: > (1) announcements gather at non-destination points (in fact, shallow > first), > (2) the RequestSender logic will always eat an incoming path folding > request if we want a peer (often for very short paths), > (3) the RequestHandler logic will probabilistically drop an incoming > path folding request (about once every HTL) > (4) if path folding request is dropped (or not wanted), an > intermediate node might forward it's reference instead > > I think the behavior of 2, 3, & 4 are more likely to be making the > peer-clumps, which (as you said) might not be a horrible thing. But > I think all of these points go against the original intent of > destination sampling. > > I think the behavior of 1 (this patch) is forming a specialized > "backbone" of routability around the seed nodes. > > This looks interesting, is there a way we can test your hypotheses > in a controlled way? > > Ian.
That is a great question. We can test the low-level operability of the announcement change (to make sure the patch doesn't break anything). We might also be able to drum-up a histogram stat for announcement replies (if toad is concerned for long links). I already suggested comparing routing stats from seed & common nodes. As for the rest, we can make a test-fix that causes behaviors 2 & 4 to occur only 1/3rd the time and see if network health improves :) The trouble is... I think that announcement & path folding tend to effect each other, so if we axe #4 (possibly the easiest and most maleffective feature to disable) I would expect far fewer path folding connections (i.e. proportionally more announcement connections) and exacerbate #1. But in short, I wouldn't change anything till #1 is taken care of, it is also the most benign-looking fix. It should also be known that most of these have been put in place to actually avoid "destination sampling", because then you know who sent you the data (and you could freely connect to them) or know who requested the data from you. There might be some onion routing magic that could save this, but I doubt it; if you use opennet, you might just have to rely on the fact that there are very few path-folding requests (compared to requests at-large) [security through obscurity/ rareness]. I don't have much time to presently offer, though :( -- Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101104/707def4a/attachment.html>
