On Monday 11 August 2003 11:36 am, Some Guy wrote:
> > > 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.
The only thing the nodes know is the hash. So if A seems better to C it is
only because A is faster overall for C biased on the requests that C gets. So
if C routes lots of requests to A, A's specialization will slowly become
closer to C's. However C will never route to A for a request if it thinks B
is a better match. If C does not know B very well and so does not know that
it is a better match, and it routes a request to A, yes that is non optimal,
but the only solution is for C to learn more about B.
_______________________________________________
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
