> > Alex writes: > > This is why in my proposal, the data would be inserted in five different > > directions (one to the epicentre of A, one to the epicentre of B etc.) > > Wouldn't this approach have the problem of overloading the nodes? > > Keywords like "music", "sex", "freenet" would be essentially useless because > so many documents would try to be indexed under those keys that no node could > hold them all. >
I recognise this, and my proposal includes the scheme where instead of going straight to the epicentre, a node forwarding a search request chooses a node which is close to the epicentre but not at the epicentre. You kind of spiral-in towards the epicentre, then bail out when you have enough matches, hopefully not having to reach the centre. A node is considered to be close to the epicentre if there is a reference to some metadata close to that in the search criteria. For example, someone searching for "Content-type=audio/mp3" may get sent towards a node containing "Content-type=audio/midi". This node is also likely to contain mp3 metadata, due to clustering. The point is that there are many more nodes just around the epicentre than those at the centre, but clustering means that these nodes are able to serve requests. The request is guaranteed to get a little closer to the epicentre every time due to nodes telling the next node the maximum distance away from the epicentre the next forwarding should be. In the example above, nodes will only forward requests to the DataSources of mp3 metadata if there is nowhere else left to go. > Hal > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev > _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
