Re: [Gzz] hemppah's research problems document

[Tuomas Lukka]

On Fri, Dec 13, 2002 at 04:40:03PM +0200, address@hidden wrote:
> First, thank your for your comments. Altough this document is far from 
> complete,
>  comments are very appreciated :).
> 
> Please look my comments below...
> 
> Quoting "B. Fallenstein" <address@hidden>:
> 
> > > Please notice: in this section + = pro, - = con
> > 
> > Probably this'll make diffs to that section hard to read...
> > 
> > > 1.1. Distributed Hash Tables (DHT)
> > 
> > ...
> > 
> > > -own resources are mapped into the network
> > 
> > I still don't see this as a problem. You should have an explanation if 
> > you do... :)
> 
> Yes, you are right. This not a *problem*, rather a subjective opinion (in our
> scenario). In fact, I discussed about this with Tuomas today we agreed (in 
> our 
> scenario), that it's a very important thing that a user has *authority to
> decide*, whether to publish data or not (mirroring etc). Tuomas, do you want 
> to
> give comments on this ?

No, this is still somewhat missing the point.

Ok, I want to say I want all RFCs to always be on my machine so that if I go out
with the laptop I have them there.

Some systems, such as DHTs cannot let other people use this "mirror" because
the files are not in the location the DHT would place them in.

So if we think about a 5GB / 100MB split between my mirrored data / DHT area 
(which is quite reasonable), most of the potential capacity in the network
is not getting used!


> > > 1.3. Flooding Broadcast Networks (FBN)
> > ...
> > > -not fast routing (in fact, there is no upper limit, because there are
> > multiple simultaneous
> > > breadh-first searches in the network)
> > 
> > I don't understand this (why there is no upper limit). I would've 
> > thought that there's usually an upper limit of O(n^2)-- if all nodes 
> > know each other, and thus every node forwards the request to every other 
> > node (where it is cancelled, because a node will not process the same 
> > lookup twice).
> 
> I have to check this. Yesterday while writing this document, I didn't find the
> article, where authors said that there is "no limit". Have to check...

Hemppah: you *HAVE* to be more critical about the sources; including a statement
like that without really knowing what it's saying...

> > 
> > > 2.1.2. Objectives
> 
> > 
> > > -algorithm will find the specific Storm block as quicly as possible (and
> > return it to the user) based
> > > on the the block's ID
> > > -simple pseudo thinking: "based on block ID, find the specific block fast
> > and return it."
> > 
> > You're missing a step here:
> > 1. Find the block
> > 2. *Download the block*
> > 3. Return the block
> > 
> > Maybe you want to leave it out of the pseudo thinking, but it's quite 
> > essential to the point above that :-)
> 
> Yes, I left it intention away. AFAIK, thesis' focus is how a specific data can
> be located as fast as possible, if exists in the network.

? 

Located *and* downloaded.

More like "obtained".

> > > 2.2.3. Existing approaches and this specific research problem
> > > 
> > > -First, *all* blocks (with the specific urn-5 name) have to checked and
> > analysed 
> > > -In this case (urn-5), there is no benefit from the block's ID at all 
> > > (DHT,
> > SWN)
> > 
> > What do you mean by this? I don't understand at all.
> 
> I may have understood this all wrong, but if we want all blocks associated 
> with
> a specific urn-5, we have to check all blocks (since from this point of view,
> urn-5 and block IDs are independent from each other: urn-5 names has no
> information about the blocks which may associated with the specific urn -5 
> ??) ?

Yes, except of course that all nodes will keep indices of their blocks' urn-5
associations. Also, one of the aspects of this research question is whether you 
can
also use non-local indices!

> > > 2.2.4. Open questions:
> > > -in this case, is it sensible to maintain two different key-value mappings
> > key-value based systems (DHT, SWN) ?
> > >   -one fore block IDs
> > >   -one for urn-5 names, which are associated with block IDs
> > >   -is this approach too difficult to maintain ?
> > 
> > Why would one want to? I don't see any benefits.
> 
> This is based on my preasumption below. If we know all the block's associated
> with a given urn-5, we can find the block(s) more efficiently.

Indeed. See above. Would not be too difficult and possibly very desirable.

        Tuomas