[Top][All Lists]
[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
- [Gzz] PEG: Attacking against GISP, Hermanni Hyytiälä, 2003/06/06
- Re: [Gzz] PEG: Attacking against GISP, Tuomas Lukka, 2003/06/06
- Re: [Gzz] PEG: Attacking against GISP, Hermanni Hyytiälä, 2003/06/06
- Re: [Gzz] PEG: Attacking against GISP, Tuomas Lukka, 2003/06/06
- Re: [Gzz] PEG: Attacking against GISP, Benja Fallenstein, 2003/06/07
- Re: [Gzz] PEG: Attacking against GISP, Hermanni Hyytiälä, 2003/06/09
- Re: [Gzz] PEG: Attacking against GISP, Benja Fallenstein, 2003/06/09
- Re: [Gzz] PEG: Attacking against GISP, Hermanni Hyytiälä, 2003/06/09
- Second post: Re: [Gzz] PEG: Attacking against GISP, Hermanni Hyytiälä, 2003/06/09
- Re: Second post: Re: [Gzz] PEG: Attacking against GISP,
Benja Fallenstein <=
- Re: Second post: Re: [Gzz] PEG: Attacking against GISP, Hermanni Hyytiälä, 2003/06/10