On 2011/01/26 (Jan), at 1:15 PM, Matthew Toseland wrote:
The following is relevant to Robert's thread. It's close to what he
was talking about. TheSeeker is the other big contributor.
On a node which does a lot of downloads, the peers approach a flat
circle: They are more or less evenly distributed.
On a node which just routes we get a very strong small world effect.
Wow, that makes sense. I think that you have found the direct cause,
PRO:
- Routing is no longer disproportionately optimised for local
requests. Hopefully higher overall performance.
- Prevents the trivial opennet path-folding-originator-sampling
attack.
CON:
- No direct theoretical backing at present. We need to talk to a
theoretician.
- We should not deploy this while there are other big network things
happening.
Theoretical backing?
Facts...
(1) Path folding presently operates across local & remote requests
Axioms...
(1) local requests tend to be evenly distributed,
(2) remote requests tend to be highly specialized,
(3) some nodes have disproportionately high local requests (downloaders)
(4) some nodes have disproportionately high remote requests (browsers)
I would expect...
(5) downloaders to have a routable view of the network,
(6) browsers will have a routable view of there local network &
*might* over specialize
(7) when browsers "start browsing again" the node might quickly latch
onto the nearest downloader b/c it can satisfy the requests
(8) when browsers go idle, any long connections or connections to
downloaders will start dropping off
The FOAF routing scheme probably makes the #7 & #8 behaviour much more
real.
I recall the whole 'run a spider and freenet starts working' argument
and now wonder if it was more routing than caching.
As an aside, my understanding is that opennet routing would
theoretically work even if every node simply held onto it's two
nearest connections (left & right; neglecting load concerns entirely
for the moment); this is the circular klienberg model which the
simulators use.
In my former investigation (which I appreciate you bringing back up
for its relevance), it seemed like my 'browser' nodes were becoming
way too specialized; e.g. 5-7 fold redundant links to nearby nodes. It
was this 'downloader' / 'browser' role separation is what I was
refering to when I said the network might be behaving like a scale
free network (maybe wrong terminology).
My original thought on improving this situation (if it does have such
a negative effect), was to only accept a path folding request for
local requests (i.e. eliminate the causing fact #1). This would surely
cut down on the number of path folds accepted by browser-nodes, but
they would be 'healthier'.... or at least become the same as the
'downloaders' path folding, so the network would be more homogenous
(if nothing else). It would be interesting to hear theories and
opinions on this change.
Should we only start path folding once HTL drops below the caching
threshold?
I don't totally understand the implications of that, but it sounds
like you're looking for a solution on the origination side of path
folding, and creating a new tunable. I would consider modifications on
the acceptance side of path folding first, and nail down what it means
(in code) to 'want' a new opennet peer enough to grab a path folding
request.
--
Robert Hailey
_______________________________________________
Devl mailing list
[email protected]
http://freenetproject.org/cgi-bin/mailman/listinfo/devl
