Ian Clarke wrote:
> The idea is that you have a search query like "contains("hello") and
> contains("goodbye") or matches("fred")". On recieving a request for
> data matching this key, each plain-text key in the datastore is compared
> against the search and given a score between 0 and 1, 1 being a perfect
> match (fuzzy logic is used to determine this score). If any data gets a
> 1 then it is returned immediately. If not, the best score on the node
> is checked against one or more "best so far" scores transmitted with the
> search. If one of our local keys beats these scores then it is added to
> this list in the appropriate place. The request is then forwarded in
> the usual manner to the node corresponding to the highest scoring key.
> When the request times out or finds a perfect match it passes back along
> the path, bringing with it the list of "best-so-far" keys.
If we forward the request to the Datasource of the highest scoring key,
do we not end
up giving certain nodes a disproportionate amount of requests? (Those
caching keys close to "mp3" for example). In my proposal I suggested
forwarding the request to the node corresponding to an almost-perfect
match. The number of nodes in this category will be
greater than the number of nodes who are the Datasource of an exact
match, hence for any given keyword there will be more nodes serving the
same amount of requests, with a lower load on each. We should still
benefit from clustering well enough to provide enough matches.
>
> This way we get a yahoo or altavista-style search mechanism which will
> give us a nice list of closest/next closest keys.
>
I think if we get it right, we will have a system that beats existing
centralised search mechanism hands-down. Funnily enough, people could
insert metadata into Freenet that refers to web pages..
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
