> > But wait, consider the fact that people aren't out
> > requesting random keys (though the search keys may
> > "look" random). Consider this senerio with 4
> nodes
> > {A,B,C,D}.
> >
> > Both A and B sepecialize in keyspace X. C and D
> > request from A and B. C tends to have requests
> for
> > freesites about cats, and likewise D gets them for
> > dogs.
> >
> > It seems posible to have a network where C has
> learned
> > to get data from A and D from B. A has a cache
> full
> > of kitty pics and B has one full of doggy pics.
> >
> > C would have reason to believe A is better than B
> in
> > keyspace X.
> > D would have reason to believe B is better than A
> in
> > keyspace X.
> > Therefore, how good A and B are in X is
> "subjective".
>
> Why is that a problem?
1) Privacy. If "like minded" nodes wind up clustering
together, it becomes easier for someone to inflitrate
them by running a simular node.
2) Routing. Consider what happens if C has to answer
some doggy requests in keyspace X, for a new neighbor.
It'll send those requests to A. If your lucky, A
will answer slowly. You may get nothing.
In the long run you may wind up either untraining C->A
for C->B or never changing much if the majority of
requests from C are still cat requests.
There may also be a problem of requests tring to
escape a cluster of "taste" related nodes.
I'm not 100% certain how serious these affects are.
I'm just pointing out that learning that a neighbor
handles *my* requests well in a keyspace may be
keeping me from learning what neighbor will do well in
that keyspace in the future for *our* requests.
This is just a hunch. It just seems like something in
the real world which may not have been accounted for
in the initial freenet experiments.
__________________________________________________________________
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Logos und Klingelt�ne f�rs Handy bei http://sms.yahoo.de
_______________________________________________
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
