> In the first place, some data won't be searched for very much, so it
> won't be widely cached.  Freenet generally allocates space to data
> depending on how popular it is.  Technical or obscure data will be on
> a relatively small number of nodes so it still won't be easy to find if
> the routing lacks precise targeting.

As is the case with most web searches - to find rare data you must be
specific, this is probably inevitable in any form of search.

> In the second place, retrievals of data may be via different keywords.
> Going back to my example where the data is inserted with keywords
> A,B,C,D,E; one retrieval may be looking for B&D while another is looking
> for A&E, etc.  These two searches won't go anywhere near each other.

They will, because if people who search for B&D find data P, and people
searching for A&E also find data P, then paths will form towards P for
those types of searches.

> I still don't see how the insert and search will find each other.
> Think of a network with 100,000 nodes, and the data you want has been
> inserted, but you are the first person fetching it.  It lies on maybe
> 10 nodes in the network.  There are 10,000 to 1 odds against any given
> node holding it.  This means you need accurate routing if your search
> is going to find it in 10 hopes.

Of course you do!  This would be inevitable with *any* search mechanism,
you must be very specific to find rare data, but once some "pioneers"
have stumbled upon the data a few times, then paths will form, and it
will become common enough to be found easily.  I think insertions of
search data should also have higher HTLs for this reason.

Ian.

_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

Reply via email to