gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] Same Key - different content


From: Christian Grothoff
Subject: Re: [GNUnet-developers] Same Key - different content
Date: Fri, 19 Jun 2009 17:41:58 -0600
User-agent: KMail/1.11.2 (Linux/2.6.27-14-generic; KDE/4.2.2; i686; ; )

On Friday 19 June 2009 04:02:06 pm leo stone wrote:
> I have yet another question. This is more in regard to the file system.
>
> From what i've read it is not clear to me what happens
> if different content is inserted under the same keyword.
>
> How does gnunet handle this situation if it encounters a key that exists
> already? Does it just update?
> Or does it store two entries under the same hash.

Stores two entries.

> If i was to insert something with the keys "gnunet" and "network"
> and later something with "apache" and "network".
>
> what happens for the "network" entry? what would a search for "network"
> yield?
> would it return both entries or just one?

Both.

> how about returning replies to such requests, return all results, gaining
> trust multiple times for just one request?

First responder gains trust, rest goes home empty-handed (but they don't know 
that).

> this couldn't really work since there are routing entries in between that
> get removed after the first reply.

No, peers mark them as "removable" if they are short on space (and reset 
trust-to-be-earned to zero), but they don't entirely remove the entry 
immediately.

> or just returning the freshest entry? well as i say i lost it a bit here.

No, if a particular peer has multiple, one or more randomly-selected entries 
are returned.

> Anyway to this, are there already plans or ideas to allow for better
> search capabilities?
> Exact key words and you'll never find what you are after ....

Yes, doing approximate searches would be very nice, but given that we like to 
keep our search terms private and essentially only transmit a hash of the 
search term, this would be really hard (but nice).  Good line of research for 
those working on hash functions...

Best,

Christian




reply via email to

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