gzz-dev
[Top][All Lists]
Advanced

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

Re: Second post: Re: [Gzz] PEG: Attacking against GISP


From: Hermanni Hyytiälä
Subject: Re: Second post: Re: [Gzz] PEG: Attacking against GISP
Date: 10 Jun 2003 12:52:15 +0300

On Mon, 2003-06-09 at 17:37, Benja Fallenstein wrote:
> > 
> > public void insertGInfo(GInfo newInfo){
> ...
> >         int index = datahouse.indexOf(newInfo);
> >         if(index == -1){
> >             datahouse.add(newInfo);
> >         }else{
> >             GInfo info = (GInfo)datahouse.get(index);
> >             if(newInfo.isNewerThan(info)){
> >                 // update
> >                 info.update(newInfo);
> >             }
> >         }
> ...
> 
> The *intent* of the above might be to have only one value associated 
> with one key; I'm not sure about that. However, I cannot see how this 
> can be its effect, given the passing GISP tests and our use of GISP.
> 
> It is a bit hard to trace how GInfo.equals() works, but I think that it 
> probably thinks two GInfos are equal only if the values as well as the 
> keys in a key/value mapping are equal. I.e., the above will only update 
> an entry if *both* the key and the value are equal.

Today I (with the aid of Tuomas) looked GISP's source code more
carefully and noticed that GISP *does* support multiple values per key;
GInfo.equals() was implemented in a way that I didn't realize at first
how the method actually works with ArrayList.indexOf(): what matters
with the GInfo.equals() is that both the key and value for a given
object have to be equal when compared to "this" object's key and value
(as you cite above).

However, it's interesting to realize that there are no words in the DHT
literature about that DHT can be *open*, i.e., in the case a "hash
collision", hash table's single bucket stores multiple entries (like
Java's hash table).



-Hermanni






reply via email to

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