Re: [Blocks-development] Life Signs

[Michael S. Jr. <m...@ms...>]

Forgive me for inventing or misusing terms, but...

I call a 'namespace' some system of naming that points you to something.  A
postal address is a namespace on the set of all physical locations of
houses, businesses, etc.

In this case, I want to point out that the route to a block is a necessary
part of the namespace -- otherwise, no single node of the network knows how
to find a certain block ID on some other node of the network.

Or to put it another way...block ID's are not sufficient to find and
download the block.  You need to know where to download the block from.

Just as we've all used the phone book to look up an address...you don't
always need every part of the namespace to find what you need.  It should be
possible to use some kind of 'index service' to correlate file blocks with
the routes needed -- and it might even be possible to disclose parts of the
information to different parts of the network, so no single node or part of
the network knows everything it needs to know to map the network.

But this is a question of network design.  It is of course possible to
design a network in any of several different ways:  with gnutella-like
broadcast searches, with blocks-like broadcast file adverts, with central
index servers, etc.  We picked one design, and we know there are several
other designs available.

But if you remove the routes from the file or block information
namespace...what search or broadcast service do you plan to add in its
place?  What are the security, performance, or scalability factors in
whatever you add?  How do they compare with the same factors in what we
already have?

I am *not* a network design person, in this way.  Most of my cool ideas
start once you already have a working network.  You probably know more than
me about this anyway...but I thought my viewpoints might help structure the
discussion a bit.  :)

--Spence
bl...@ms...


----- Original Message -----
From: "Tod D. Ihde" <to...@je...>
To: <blo...@li...>
Sent: Monday, May 14, 2001 4:19 PM
Subject: Re: [Blocks-development] Life Signs


> On Sun, May 13, 2001 at 10:52:34AM +0000, Blat Froop wrote:
> > >From: "Tod D. Ihde" <to...@je...>
> > >To: blo...@li...
> > >Subject: Re: [Blocks-development] Life Signs
> > >Date: Sat, 12 May 2001 21:50:46 -0500
> > >
> > >
> > >Why should a node advertise a file? Why not just have the node
advertise
> > >that it can GET to a file? The node _requesting_ a file can start the
> > >request on all nodes, and choose the fastest-responding node to get the
> > >file
> > >from (and shut down the others). This allows the client to choose where
it
> > >gets the file from (to a degree, each node in the chain would be
choosing
> > >the fastest next-hop), and eliminates the "this node is
storing/inserting
> > >this file/block" problem, because you are only advertising that you
_know_
> > >about a file and can get to it, not its route. Each node would only
know
> > >that it's neighbor knows how to get to a block/file, not what its
neightbor
> > >actually has in it's cache.
> >
> > IMHO... Blocks needs route information because its a relay
> > network rather than a direct P2P network. The issue of
> > 'the fastest route' has come up several times before,
> > and I think its generally agreed that using the
> > length of the route to work this out isnt very sensible.
> > I think the only real way of working out the fastest
> > route would be to do something akin to what GoZilla!
> > does... test multiple routes and measure average speed,
> > then choose the best one. Allowing multiple simultaneous
> > downloads would be a feature of an advanced GUI rather
> > than an inherent Blocks feature.
> >
> > Its interesting revisiting these issues :-)
> >
> > ttfn
> >
> > PG.
>
>  I know I'm going to sound like a nag, but... (I'm going to anyway! Whee!)
>
> Because it's a relay network, it shouldn't need to know complete routes.
> Because it's meant to be as secure & anonymous as possible it shouldn't
know
> complete routes. Because it's not a direct P2P network (system), it
doesn't
> need to know complete routes. each server in the chain would know the next
> server in the chain to a particular destination, but no server would know
> anythin about a server 2 hops away (unless it had also connected to that
> server as well).
>
> You yourself state that using length of route for a speed indicator is not
> that good, so why bother with knowing the route?
>
> The worst that can happen, IMHO, is blocks propigating to multiple
servers -
> which I don't really see as a problem.
>
> I just wish you'd at least consider releasing a version (test, of course)
> with this option, if only to see if its feasable (hey, I believe freenet
> uses this method, actually).
>
>  Thanks,
>   Tod.
>
>
> --
>
>  * All opinions expressed herein belong to Me. Tod D. Ihde. So there. *
>   *  HTTP://toon.jesus-crispie.com/   HTTP://www.jesus-crispie.com/  *
>    *      The average, healthy, well-adjusted adult gets up at      *
>     *      seven-thirty in the morning feeling just terrible.      *
>      *                              -- Jean Kerr                  *
>
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/lists/listinfo/blocks-development