[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] GNUnet SVN HEAD FTBS?

From: Christian Grothoff
Subject: Re: [GNUnet-developers] GNUnet SVN HEAD FTBS?
Date: Sun, 10 Feb 2008 21:16:32 -0700
User-agent: KMail/1.9.7

On Sunday 10 February 2008, Milan wrote:
> Nils Durner wrote:
> > Sorry we didn't announce this earlier - see
> >
> OK, no problem with that, and I'm happy nice improvements are ongoing.
> I'll wait until everything is finished - could you just post an email or
> a message on drupal?


> Talking about search results, I've been wondering for a while whether
> there wasn't a problem with the current way they are managed. After
> being connected continuously for a few hours and having (I guess) quite
> a good trust from other peers, I still get very few results for common
> queries (application/gnunet-directory, audio/mpeg, application/ogg,
> video/x-msvideo, image/jpeg and so on), even when I'm connected to about
> 8 peers. I can remember there were more results at 0.7.0 times. Now,
> apart from mine, I only see about 10 results per query.
> Could it be that the algorithm handling queries and results is too
> restrictive? I remember debates  before 0.7 about avoiding "false"
> results that did not correspond to available files anymore: is it
> possible that the fix has gone too far?

This is certainly why we got fewer results, but getting bogus results is not 
really the goal here ;-).  The current issue that I am trying to fix is more 
fundamental: previously, a peer could respond to a (repeated) query for the 
same keyword with the same response millions of times, essentially not 
contributing anything (but getting rewards in terms of trust).  Databases 
spewing out always the same first result to a query matching possibly 
thousands of entries made this kind of behavior the norm.

The code in SVN changes the query format to include a bloomfilter which 
*excludes* certain responses. In essence, the query is extended to 
specifically exclude responses that the client has already seen.  That way, 
other peers have an incentive (and are forced to) produce *diverse* result 

That's the main change describing the essence of how the new code will 
hopefully increase the number of search results.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]