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: Benja Fallenstein
Subject: Re: Second post: Re: [Gzz] PEG: Attacking against GISP
Date: Mon, 09 Jun 2003 16:37:14 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030527 Debian/1.3.1-2

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





reply via email to

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