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

[Benja Fallenstein]

Hermanni Hyytiälä wrote:
> On Mon, 2003-06-09 at 14:04, Benja Fallenstein wrote:
>
> > Hermanni Hyytiälä wrote:
> >
> > > On Sat, 2003-06-07 at 21:26, Benja Fallenstein wrote:
> > >
> > >
> > > > Hermanni Hyytiälä wrote:
> > > >
> > > >
> > > > > On Fri, 2003-06-06 at 14:06, Tuomas Lukka wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > > - A hostile (or faulty) peer(s) stores lot of dummy key-value-pairs with
> > > > > > > a certain key
> > > > > >
> > > > > > Does GISP allow several values per key?
> > > > >
> > > > > Like DSHT ? No.
> > > >
> > > > No, like a normal DHT, so that a lookup returns all values associated 
> > > > with a key. Yes, it does; we use it all the time.
> > >
> > > Sorry, I don't understand your answer completely :).
> > >
> > > I understood Tuomas' question like "Does GISP support frequent fetches
> > > and frequent *stores* of the same hash table key" (like DSHT supports),
> > > not like "Only one value can be stored under a key at any given time in
> > > regular DHTs. Thus, frequent retrievals but only one *store* is
> > > supported. Does GISP support this ?"
> >
> > The point was simply whether different values can, at the same time, be 
> > associated with the same key. The answer is yes.
>
>
>
> After a brief discussion with Tuomas, I decided to look GISP's source
> code and found this:

-- snip --

> So it seems that GISP *replaces* the value for a
> given key (updates time/date values) rather than appends the value
> (e.g., to the end of a list) associated to a given key.
>
> Given this, the answer is still no.

So how can you explain away the fact that we have tests proving the 
contrary?

    org/nongnu/storm/modules/gispmap/GispP2PMap.test

which inherits from

    org/nongnu/storm/impl/p2p/P2PMap.meta

And the fact that Storm uses this and has worked fine so far, of course.

> Then GISPXML.java (which is used, e.g., with the simulator and UDP-imp):
>
> public void insert(String key, String str, long ttl){
...
>         GInfo info = new GInfo(GHash.fromKey(key), ele,
>                                getCurrentTime() + ttl, infoComparator);
>         insertGInfo(info);
> }
>
> - -
>
> GInfoManagerMemory.java:
>
> 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.

Actually that sounds like a more sensible rationale: If both the key and 
the value are equal, it will update the timestamp on the key/value pair. 
However, I'm not sure this is correct either; I don't understand the 
source well enough. :-(

- Benja