On 2010/11/04 (Nov), at 3:06 PM, Ian Clarke wrote:
On Thu, Nov 4, 2010 at 2:09 PM, Robert Hailey <rob...@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
_______________________________________________
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl
