[Top][All Lists]
[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