[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] Re: Available overlays PEG
From: |
hemppah |
Subject: |
Re: [Gzz] Re: Available overlays PEG |
Date: |
Mon, 4 Aug 2003 09:57:36 +0300 |
User-agent: |
Internet Messaging Program (IMP) 3.1 |
Quoting Tuomas Lukka <address@hidden>:
> On Sat, Aug 02, 2003 at 11:24:55AM +0200, Benja Fallenstein wrote:
> > Tuomas Lukka wrote:
> > >>OpenGL is different because it implements a completely different
> > >>interface than AWT offering different capabilities &c. This is more like
>
> > >>deciding in Kaffe which implementation of AWT (X-based? QT-based?
> > >>win32-based?) is default.
> > >
> > >And tapestry provides DOLR, not DHT. Thus it *is* analogous.
> >
> > We'll use it to implement exactly the same functions as before, which
> > includes using a DHT layer built on top of it. If we couldn't do that,
> > we probably couldn't use Tapestry.
>
> Ok. But I still see it as a part of architecture -- probably just
> because we define architecture differently ;)
Despite Tapestry "implementes" DOLR, Tapestry's API is identical to DHT for
application. For example, with Tapestry 2.0, there comes a file sharing
application (Interweave) similar to Kazaa. Specifically,
tapestry2/src/ostore/tapestry/interweave/Interweave.java (a Interweave peer)
performs key/value (i.e. lookup/retrieval) operations as follows,
1) By publishing local shared directory's meta data, i.e., file names, last
modified date, file size, data type and keyword using SHA-1 hashing function.
2) For each SHA-1 produced key, Tapestry routes the (key, publisher) touple to
the closest peer (root peer) in a network with a publishing path.
3) To search a data, say based on a filename, Interweave peer hashes a filename
and starts looking a value for the key: in each hop, Tapestry comes closer to
the closest peer (root) in a network. Once the root peer is found, it returns a
pointer to the search originator and retrieves the file from the original
publisher.
(Isn't this quite close to key-value operation, right? ;))
For Storm, this process *does* provide key/value operations: for each block in a
local pool, we could publish blocks ID along additional meta data. Then, when
looking up storm blocks, we starts query with a block ID and wait Tapestry to
finish the lookup process (and of course, we don't need hash data anymore since
Storm has done it already). Therefore, I still see that we could use Tapestry.
I *strongly* recommend reading the this paper for more detailed information
about Tapestry's routing &c (especially page 4):
http://www.cs.berkeley.edu/~ravenben/publications/pdf/tapestry_jsac.pdf
-Hermanni
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
- [Gzz] Re: Available overlays PEG, Hermanni Hyytiälä, 2003/08/01
- Re: [Gzz] Re: Available overlays PEG, Tuomas Lukka, 2003/08/02
- Re: [Gzz] Re: Available overlays PEG, Benja Fallenstein, 2003/08/02
- Re: [Gzz] Re: Available overlays PEG, Tuomas Lukka, 2003/08/02
- Re: [Gzz] Re: Available overlays PEG, Benja Fallenstein, 2003/08/02
- Re: [Gzz] Re: Available overlays PEG, Tuomas Lukka, 2003/08/02
- Re: [Gzz] Re: Available overlays PEG,
hemppah <=
- Re: [Gzz] Re: Available overlays PEG, Tuomas Lukka, 2003/08/04
- Re: [Gzz] Re: Available overlays PEG, hemppah, 2003/08/04