blocks-development Mailing List for Blocks (Page 13)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I'll try to leave a blocks server up at:  67.165.192.244:9089

Otay... That being the case, I'll set something up on my backup server, if
it has the space (I purposely built it using the oldest, most decrepid
hardware I could find, just to prove I could). If it won't go, I'll pop a
different HD into it, which will bring us to 3 pernenant servers.

Aloha!
 Tod.

On Thu, May 24, 2001 at 06:32:23PM +0000, Blat Froop wrote:
> >Also, I've noticed that after ~ 1 week or so of uptime, my blocks server no
> >longer has connections to anyone else. Is there code to re-establish
> >connections when they all die? When I re-started, it reconnected to 
> >mspencer
> >right away.
> 
> Yup, it should be able to reconnect. It should try every hours
> or two if I remember correctly (unless it has other connections).
> 
> Blocknets really require a minimum or 3 servers in order to
> work for long periods of time. Hopefully when I get my replacement
> mobo and get my Linux box running we can link all 3 servers
> semi-permanently.
> 
> ttfn
> 
> PG.
> 
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
> 

-- 

 * 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                  *

>Also, I've noticed that after ~ 1 week or so of uptime, my blocks server no
>longer has connections to anyone else. Is there code to re-establish
>connections when they all die? When I re-started, it reconnected to 
>mspencer
>right away.

Yup, it should be able to reconnect. It should try every hours
or two if I remember correctly (unless it has other connections).

Blocknets really require a minimum or 3 servers in order to
work for long periods of time. Hopefully when I get my replacement
mobo and get my Linux box running we can link all 3 servers
semi-permanently.

ttfn

PG.

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Coolio. 

Been busy lately, no time to respond. :(

Also, I've noticed that after ~ 1 week or so of uptime, my blocks server no
longer has connections to anyone else. Is there code to re-establish
connections when they all die? When I re-started, it reconnected to mspencer
right away.

Toodles!
   Tod.

On Tue, May 15, 2001 at 04:48:35PM -0400, Luke Hankins wrote:
> FYI, I understand your idea about getting rid of explicit routes.  Haven't
> had time to mull it over, but it makes sense.
> 
> -Luke

-- 

 * 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                  *

[snip snip]
>I want to remove the routes and replace them with "next-hop-to" routes.

>Let us pretend that my current BLOCKS server has a route table that looks
>like this (for some file.zip):
>
>  file.zip        A H E P
>
>This means that my server can get file.zip by sending a request to server 
>A, which sends its request to server H, which sends its request to server 
>E,which sends its request to server P. (Am I correct? I thought this was 
>how it worked).

Yep, you got it.

However, the blocks server is only interested in two things...
the immediately adjacent host to route to, and the length of
the current route.

so, file.zip AHEP => file.zip node=A hops=4

Now, we do need to have a list of routing tokens so that
node A knows where to send the request to once the local
node has sent it to A, but this doesnt mean we need to
leak information about the actual route.

Nodes are free to write any token they want that identifies
an immediate node. The current Blocks implmentation uses
A,B,C,... this and A always maps to node0, B=>node1, etc, but it
doesnt have to be that way.

If the server used a more complex way of creating a
token to node mapping this could ensure routing information
was not leaked for statistical analysis. For instance,
we could encrypt the token with a secret server key and
the advert ID (each advert has a unique 128bit ID).

This creates a problem with the advert database though. When
a node disconnects form a server the server broadcasts a
disconnection notice to all connected nodes, which then
rebroadcast the notice throughout the blocknet. The routing
information from this disconnection notice is used to
exclude newly invalidated routes from searches... for instance...

If we have a local list fo adverts that says...

file.zip AHEP
file.zip AHC
file.zip BDEF
file.zip AHL

if node H breaks connection with node A, then this server will
receive a message which says 'disconnect route AH'. The next
search for file.zip will return only...

file.zip BDEF

we cant do this if we dont have constant routing tokens.

If we dropped this requirement we can get complete routing
anonimity at the expense of a lot of broken downloads. Of
course we could move to a searching rather than advertising
model, or send messages to validate search results, but these
would increase traffic considerably.

Good point for discussio tho. Any ideas?

ttfn

PG.

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

On Mon, May 14, 2001 at 09:25:00PM -0500, Michael Spencer Jr. wrote:
> Forgive me for inventing or misusing terms, but...

No problem, I do it all the time. :) Part of the job, you know...

> 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.

Ok.

> 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.

So far, I can follow you, but I only partially agree.

> 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.

1st part correct, 2nd part is assumption.

> 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.

Unfortunately, there aren't too may ways to index that don't break
anonymity. :(

> 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.

And I think the design you picked is a pretty good one. (It's what I would
have done, with the excetpion of the modification I'm proposing).

> 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?

Here's as good a place as any to explain, I guess...

I want to remove the routes and replace them with "next-hop-to" routes.

example:

Let us pretend that my current BLOCKS server has a route table that looks 
like this (for some file.zip):

 file.zip        A H E P

This means that my server can get file.zip by sending a request to server A,
which sends its request to server H, which sends its request to server E,
which sends its request to server P. (Am I correct? I thought this was how
it worked).

Now, with what I propose, my BLOCKS server would have this as a route table:

 file.zip	A

Which means that server A knows how to get to the next hop to file.zip

Server A may have this:

 file.zip	C P

Which means that both servers C and P know how to get to file.zip

Server C may have this:

 file.zip	<in cache>

and server P may have this:

 file.zip	A C

So server C would send the file to server A, which would send the file to my
server. Server P would have a route loop, making access slow, so it would
not get to participate in this transaction (probably).

See what I'm trying to say? Rather than a full route, which can (in some
cases) compromise anonymity, only have a "next hop" route, which doesn't. It
isn't as fast, there can be (potential) problems with route loops (I say
potential because by checking speed of response they shouldn't be an issue),
but it should work. That is what I'd like to see. (It would also allow a
server to re-advertise files in its cache to new clients, because it only
has to advert that it knows how to get to the file, not that it HAS the
file).

> 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.  :)

Nor am I, by any stretch of the imagination. I probably don't, I just like
to play with filesharing / distributed network systems, and Blocks & Freenet
are the 2 most interesting to me.

(BTW: I looked at ed2k - no Linux client, no docs on how to interface w/ a
server, and no working nodes. Ugh. not too impressed. Interesting idea,
though).

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

 Tod.

ps.
 Thanks for listening. I'm probably talking out of my nether region, but
thanks!
-- 

 * 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                  *

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

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                  *

Oops, forgot to mention that - I have it default to mspencer.net:8017.
All should be well.

I even uploaded some stuff (Check out the LoveHina video if it made it -
very funny!)

Sounds like a plan, then. (3-server setup). I'm kind of lucky because I work
with/for an ISP so I get my bandwidth for free. :)

 Tod.

On Sun, May 13, 2001 at 10:58:09AM +0000, Blat Froop wrote:
> >ps.
> >I have set up a blocks server at jesus-crispie.com:8017. Its been set to 
> >launch on boot, 1 GB cache (until I get another HD, which will be at least 
> >1-2 more months). It'll be permenant as long as blocks is in use.
> 
> point it at Michael's server... mspencer.net:8017
> 
> At some point soon I'll have my own Linux server up and
> running... Im building the box now but somethings up
> with the mobo. Once I get it going I'll point it at
> mspencer.net:8017 as well and we should have a 3way
> Blocks network which is a good minimal configuration
> for an expandable network.
> 
> ttfn
> 
> PG.
> 
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
> 

-- 

 * 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                  *

>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.

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Amazing what one email message can do. :)

 Tod.

ps.
 I have set up a blocks server at jesus-crispie.com:8017. Its been set to
launch on boot, 1 GB cache (until I get another HD, which will be at least
1-2 more months). It'll be permenant as long as blocks is in use.

On Sat, May 12, 2001 at 07:34:15PM +0000, Blat Froop wrote:
> >From: Luke Hankins <lu...@et...>
> >To: Blat Froop <pet...@ho...>
> >CC: blo...@li...
> >Subject: Re: [Blocks-development] Life Signs
> >Date: Sat, 12 May 2001 14:15:10 -0400
> >
> > > * If you disconnect and reconnect to a Blocks server it
> > > will only send you adverts for files that are available
> > > remotely, not for files it has within its own disk cache.
> > > This is to prevent scanners traversing the Blocks
> > > network and examining the files stored in each node.
> > > This means that the only way snoopers can associate a
> > > file with a particular Blocks server IP is to be directly
> > > connected to that server at the point the file was
> > > uploaded or cached.
> >
> >I _think_ that this problem can be solved by simply never advertising to 
> >your neighbors that you have a block.  Instead, make up a few "loopback 
> >links" that point back to yourself and then use them to pad out messages to 
> >at least 3 hops.
> >
> >This would prevent people who were directly connected to you from finding 
> >out what you've got in your cache.  (I think.  I haven't had time to check 
> >it out, but I think there would be a way for someone to connect to you with 
> >three different clients and compare what routes you were advertising to get 
> >more info.)
> >
> >It's a simple concept, but hard to explain without pictures.  Should I draw 
> >some?
> 
> I think Ive got the idea (tell me if i dont).
> 
> I think the same effect could be achieved by simply
> prefixing a small number (0,1 or 2) bogus routing
> chars to the route when readvertising locally cached
> files. Since Blocks servers will reply
> out of cache if they have the block, the request
> should never be sent to the bogus routes unless the
> block fell out of cache. It might make invalidating
> bogus routes more difficult tho.
> 
> ttfn
> 
> PG.
> 
> PS Good to see the list coming back to life :-)
> 
> 
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
> 
> 
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/lists/listinfo/blocks-development

-- 

 * 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                  *

I still like the idea of only adverting that you know about a block, or
rather, that you know a route to a block. The node requesting never needs to
know where the block is coming from, it can choose whichever node responds
1st to get successive blocks from.

 Tod.

On Sat, May 12, 2001 at 02:15:10PM -0400, Luke Hankins wrote:
> > * If you disconnect and reconnect to a Blocks server it
> > will only send you adverts for files that are available
> > remotely, not for files it has within its own disk cache.
> > This is to prevent scanners traversing the Blocks
> > network and examining the files stored in each node.
> > This means that the only way snoopers can associate a
> > file with a particular Blocks server IP is to be directly
> > connected to that server at the point the file was
> > uploaded or cached.
> 
> I _think_ that this problem can be solved by simply never advertising
> to your neighbors that you have a block.  Instead, make up a few 
> "loopback links" that point back to yourself and then use them to
> pad out messages to at least 3 hops.
> 
> This would prevent people who were directly connected to you from 
> finding out what you've got in your cache.  (I think.  I haven't had time
> to check it out, but I think there would be a way for someone to connect 
> to you with three different clients and compare what routes you were
> advertising to get more info.)
> 
> It's a simple concept, but hard to explain without pictures.  Should 
> I draw some?
> 
> -Luke
> 
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/lists/listinfo/blocks-development

-- 

 * 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                  *

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.

 Tod.

On Sat, May 12, 2001 at 04:01:27PM +0000, Blat Froop wrote:
> 
> Assume computers are called A,B and C. Here is what I
> think should happen...
> 
> 1) A requests file from C via B
> 2) File is transferred from C via B to A in blocks.
>    B and A both cache all blocks as they arrive.
> 3) When B receives the end of file it generates an
>    advert which it sends to A and C
> 4) When A receives the end of file it generates an
>    advert with it sends to B and C
> 
> So, sitting at A, you should have the choice of downloading
> from B, C, C via B, or B via C.
> 
> However, something to bear in mind.
> 
> * Blocks may choose to ignore adverts with routes longer
> or equal to the length of the current shortest route if
> the route contains a sub-route to the same file. This is
> to avoid the combinatorial explosion of possible routes
> introduces by a large meshed network of nodes. So, in
> short you may not see C via B in the example if the
> file was already available from B.
>
> * When Blocks receives a message requesting it to route
> a request for a data block from some remote server it
> first checks its local cache for that block. If it finds
> it it sends it back immediately. Therefore even though
> you might think you are requesting from C via B, B may
> choose it intercept the request and return the data
> immediately. Blocks should have checked the immediate
> local disk cache from the initial requestor, but I think
> that was a 'feature' I never really got around to fixing.
> 
> * If you disconnect and reconnect to a Blocks server it
> will only send you adverts for files that are available
> remotely, not for files it has within its own disk cache.
> This is to prevent scanners traversing the Blocks
> network and examining the files stored in each node.
> This means that the only way snoopers can associate a
> file with a particular Blocks server IP is to be directly
> connected to that server at the point the file was
> uploaded or cached.
> 
> ttfn
> 
> PG.
> 

-- 

 * 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                  *

Well, my users are, umm.. Mostly 2600 subscriber-types. Most of them are
somewhat technically inclined, if not crypto-inclined/aware. They're alreay
suing the freenet server, which is nice, and I wanted to give at least one
other alternative (and Gnutella just sucks bandwidth - there's no way I'll
run a server)

Security is a good thing, convenience is something I can live without. (I've
already received a letter from my upstream's legal department about a user
distributing DeCSS, so anonymity/security is nice - I don't like getting
letters like that).

I'm loading the fs page now, I'll attempt to digest it tonight.

I'll also check eDonkey, as well. Hope they support Linux! :)

I like the "communities" idea, but that creates new problesms - how do you
find new "communities"? Are all communities available from the central
server(s), and you just choose the one(s) you want?

I hate seeing good code (well, functional, which, in my book, means good - I
haven't lokoed at the code, as I said) die.
  Tod.

On Sat, May 12, 2001 at 08:58:25AM -0500, Michael Spencer Jr. wrote:
> Sorry I didn't see this discussion -- I rebooted mspencer.net...even
> remembered to restart the Blocks server...but I forgot to start fetchmail
> again!  :(
> 
> If you're actually looking to support users with a filesharing service, I
> wouldn't recommend Blocks.  IMHO, Blocks has too much security for the
> average user -- and security and convenience are a tradeoff.  Most users
> won't be OK with the lack of convenience.  Blocks was never really designed
> to be a popular filesharing system.
> 
> As for Blocks2, I've been keeping a 'filesharing concepts' page for the past
> month or so, and forgot to tell this list about it.  http://mspencer.net/fs
> I haven't updated in a few weeks...(note to self...write more in that page
> once I send this message).  Basically my intent is to borrow ideas from all
> of the other successful filesharing programs, mesh the useful ideas
> together...once we mesh the ideas together, figure out what extra ideas are
> necessary to 'fill the gaps'...and then finalize the design.
> 
> As far as large file transport, eDonkey2k (http://www.edonkey2000.org) is
> also great for this.  (I have a 40 GB hard disk I've filled up twice over
> with unlicensed anime thanks to eDonkey2000.)  It's a Napster-like also, but
> the server executable is freely available.  No source is available for any
> of this, sadly.  Some people have a problem with the interface...servers are
> sometimes hard to find...and the program certainly takes a long time to MD4
> hash all the files in the directories you share.  I tried to raise awareness
> of deliberate hash collision attacks, where an attacker could chill the
> trading of a certain movie or popular file by creating and sharing file
> blocks that match the original file's MD4 hash.  MD4, MD5, and RIPE-MD160
> aren't too different in protection against random data corruption, but
> against deliberate collision attacks, an attack against MD4 seems to take
> about 1 minute;  10 hours for MD5;  10 years for RIPE-MD160.  They aren't
> interested in changing to a stronger hash until they start seeing
> abuse...but I argue...would you ever really see the abuse?
> 
> I've matured that web of trust concept:  I believe in 'communities' now --
> since that's most likely what will form from a web of trust if you leave
> society on its own.  Communities have standards, members,
> non-members...certain standards of behavior or resource contribution can be
> required by different communities.  With this, anime traders won't have
> their pipes and caches filled up with porn...porn traders won't have their
> resources filled up with mp3's...etc.
> 
> And I'm fantasizing about this really attractive GUI:  the system will
> support multiple 'security levels', where security level will be tied
> directly to the experience of the user.  Basic security gives you a very
> Napster-like interface...and not much more protection than a Napster network
> client already gets.  Intermediate security requires that the user think
> about their resources and connections in more detail, and allows them to
> manage the flow of information to trusted and untrusted parties a bit
> better...and the interface reflects this, and enables some of the network
> features that aren't obvious to Napster veterans.  Advanced security allows
> a technical user to completely bulletproof their filesharing activity, but
> requires careful attention and control -- so the interface emphasis should
> be on reducing the apparent complexity with reporting and some task-oriented
> interfaces to go along with the concept-oriented interfaces that came with
> Intermediate.
> 
> That is...Advanced is for the security nuts like us...Basic is for the
> Napster refugees...and Intermediate is for the people who are exploring and
> using some of the extra network, community, and security features.
> 
> A friend and I were playing with 'rediscovering' Blocks the other day.  I
> ran two nodes on different (LAN-connected) machines, and he ran one over the
> internet.  I shared a file on one machine, connected my second client to the
> network...saw the file readvertised from his machine, and downloaded it.
> (Yes, the file went out over my internet connection from one machine,
> through his, and back in my internet connection to my other machine.)  When
> the file was finished, though, to my surprise I found that neither my second
> node nor his remote node were advertising the file.  Also, when I told my
> desktop machine to restart downloading the same file from the same advert
> again, it went back out over the network to download the file instead of
> saving it to disk immediately from cache.
> 
> Weren't these some of the design behaviors intended for Blocks:  automatic
> caching and re-sharing of blocks?  That caching is the only way someone can
> realistically say that a completely peer-to-peer file distribution service
> is efficient -- if everybody along the route is making a copy of the data,
> and everybody along the route is reasonably guaranteed to be 'interested' in
> the file.
> 
> It's great to hear that the list is still alive.
> 
> --Spence
> bl...@ms...

-- 

 * 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                  *

Ahh. Yes, finding time is a hassle, even here. (I got hooked on CS 3 months
ago, so I know how _that_ goes, as well. :)

I guess I missed the word "prototype" in there. My bad. :(

I haven't looked at the code, primarily because I suck at C(++). I just
liked it because it worked fairly well, and was pretty quick. (At least,
IIRC).

I shall check out snake. (No, I suck rocks at math, as well. Theory I'm good
with, but I fail with hard numbers.)

 Thankee Sai.
   Tod.

On Wed, May 09, 2001 at 05:01:32PM +0000, Blat Froop wrote:
> Blocks was discontinued primarily because I ran out
> of freetime. I work on Wall St and things can get
> pretty busy here from time to time, not to mention
> I started playing Counterstrike :-) Also, Blocks
> reached a point where it had demonstrated just about
> everything that I set out to show...
> 
> * Encrypted anonymous file transfer is feasible.
> * Packet relay networks are feasible and not too slow.
> * Broadcasting queries to everyone is not always
>   necessary and broadcast adverts (and therefore
>   instant and totally anonymous searches) are feasible.
> * Distribution of large files (>100Mb) is practicable
>   in a P2P network. To my knowledge Blocks is the
>   only P2P network which addresses this.
> 
> Competing with Napster/GNUtella/Bearshare/etc was
> not one of the original objectives, and there would
> be little academic interest in continuing with the
> current code base. If Blocks were to be continued I
> would suggest that Blocks2 consist of seperate client
> and server components so that custom clients could
> be built in a GNUtella fashion and perhaps integrate
> some of Michaels ideas about Webs-Of-Trust.
> 
> Michael is still flying the Blocks flag at
> http://www.mspencer.net/blocks where you can
> find the binaries and the full source code,
> and I think he's still running a public server
> as well.
> 
> If you are mathematically inclined you might like
> to check out SNAKE as well which, at one point,
> I was considering integrating with Blocks as an
> authentication mechanism.
> http://www.mspencer.net/snake
> 
> ttfn
> 
> PG.
> 

-- 

 * 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                  *

>From: Luke Hankins <lu...@et...>
>To: Blat Froop <pet...@ho...>
>CC: blo...@li...
>Subject: Re: [Blocks-development] Life Signs
>Date: Sat, 12 May 2001 14:15:10 -0400
>
> > * If you disconnect and reconnect to a Blocks server it
> > will only send you adverts for files that are available
> > remotely, not for files it has within its own disk cache.
> > This is to prevent scanners traversing the Blocks
> > network and examining the files stored in each node.
> > This means that the only way snoopers can associate a
> > file with a particular Blocks server IP is to be directly
> > connected to that server at the point the file was
> > uploaded or cached.
>
>I _think_ that this problem can be solved by simply never advertising to 
>your neighbors that you have a block.  Instead, make up a few "loopback 
>links" that point back to yourself and then use them to pad out messages to 
>at least 3 hops.
>
>This would prevent people who were directly connected to you from finding 
>out what you've got in your cache.  (I think.  I haven't had time to check 
>it out, but I think there would be a way for someone to connect to you with 
>three different clients and compare what routes you were advertising to get 
>more info.)
>
>It's a simple concept, but hard to explain without pictures.  Should I draw 
>some?

I think Ive got the idea (tell me if i dont).

I think the same effect could be achieved by simply
prefixing a small number (0,1 or 2) bogus routing
chars to the route when readvertising locally cached
files. Since Blocks servers will reply
out of cache if they have the block, the request
should never be sent to the bogus routes unless the
block fell out of cache. It might make invalidating
bogus routes more difficult tho.

ttfn

PG.

PS Good to see the list coming back to life :-)

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

> * If you disconnect and reconnect to a Blocks server it
> will only send you adverts for files that are available
> remotely, not for files it has within its own disk cache.
> This is to prevent scanners traversing the Blocks
> network and examining the files stored in each node.
> This means that the only way snoopers can associate a
> file with a particular Blocks server IP is to be directly
> connected to that server at the point the file was
> uploaded or cached.

I _think_ that this problem can be solved by simply never advertising
to your neighbors that you have a block.  Instead, make up a few 
"loopback links" that point back to yourself and then use them to
pad out messages to at least 3 hops.

This would prevent people who were directly connected to you from 
finding out what you've got in your cache.  (I think.  I haven't had time
to check it out, but I think there would be a way for someone to connect 
to you with three different clients and compare what routes you were
advertising to get more info.)

It's a simple concept, but hard to explain without pictures.  Should 
I draw some?

-Luke

>A friend and I were playing with 'rediscovering' Blocks the other day.  I 
>ran two nodes on different (LAN-connected)
>machines, and he ran one over the internet.  I shared a file on one 
>machine, connected my second client to the network...
>saw the file readvertised from his machine, and downloaded it.
>(Yes, the file went out over my internet connection from one machine, 
>through his, and back in my internet connection to my other machine.)  When 
>the file was finished, though, to my surprise I found that neither my 
>second node nor his remote node were advertising the file.  Also, when I 
>told my
>desktop machine to restart downloading the same file from the same advert 
>again, it went back out over the network to download the file instead of 
>saving it to disk immediately from cache.
>
>Weren't these some of the design behaviors intended for Blocks:  automatic 
>caching and re-sharing of blocks?  That caching is the only way someone can 
>realistically say that a completely peer-to-peer file distribution service 
>is efficient -- if everybody along the route is making a copy of the data, 
>and everybody along the route is reasonably guaranteed to be 'interested' 
>in the file.
>

Assume computers are called A,B and C. Here is what I
think should happen...

1) A requests file from C via B
2) File is transferred from C via B to A in blocks.
   B and A both cache all blocks as they arrive.
3) When B receives the end of file it generates an
   advert which it sends to A and C
4) When A receives the end of file it generates an
   advert with it sends to B and C

So, sitting at A, you should have the choice of downloading
from B, C, C via B, or B via C.

However, something to bear in mind.

* Blocks may choose to ignore adverts with routes longer
or equal to the length of the current shortest route if
the route contains a sub-route to the same file. This is
to avoid the combinatorial explosion of possible routes
introduces by a large meshed network of nodes. So, in
short you may not see C via B in the example if the
file was already available from B.

* When Blocks receives a message requesting it to route
a request for a data block from some remote server it
first checks its local cache for that block. If it finds
it it sends it back immediately. Therefore even though
you might think you are requesting from C via B, B may
choose it intercept the request and return the data
immediately. Blocks should have checked the immediate
local disk cache from the initial requestor, but I think
that was a 'feature' I never really got around to fixing.

* If you disconnect and reconnect to a Blocks server it
will only send you adverts for files that are available
remotely, not for files it has within its own disk cache.
This is to prevent scanners traversing the Blocks
network and examining the files stored in each node.
This means that the only way snoopers can associate a
file with a particular Blocks server IP is to be directly
connected to that server at the point the file was
uploaded or cached.

ttfn

PG.

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Sorry I didn't see this discussion -- I rebooted mspencer.net...even
remembered to restart the Blocks server...but I forgot to start fetchmail
again!  :(

If you're actually looking to support users with a filesharing service, I
wouldn't recommend Blocks.  IMHO, Blocks has too much security for the
average user -- and security and convenience are a tradeoff.  Most users
won't be OK with the lack of convenience.  Blocks was never really designed
to be a popular filesharing system.

As for Blocks2, I've been keeping a 'filesharing concepts' page for the past
month or so, and forgot to tell this list about it.  http://mspencer.net/fs
I haven't updated in a few weeks...(note to self...write more in that page
once I send this message).  Basically my intent is to borrow ideas from all
of the other successful filesharing programs, mesh the useful ideas
together...once we mesh the ideas together, figure out what extra ideas are
necessary to 'fill the gaps'...and then finalize the design.

As far as large file transport, eDonkey2k (http://www.edonkey2000.org) is
also great for this.  (I have a 40 GB hard disk I've filled up twice over
with unlicensed anime thanks to eDonkey2000.)  It's a Napster-like also, but
the server executable is freely available.  No source is available for any
of this, sadly.  Some people have a problem with the interface...servers are
sometimes hard to find...and the program certainly takes a long time to MD4
hash all the files in the directories you share.  I tried to raise awareness
of deliberate hash collision attacks, where an attacker could chill the
trading of a certain movie or popular file by creating and sharing file
blocks that match the original file's MD4 hash.  MD4, MD5, and RIPE-MD160
aren't too different in protection against random data corruption, but
against deliberate collision attacks, an attack against MD4 seems to take
about 1 minute;  10 hours for MD5;  10 years for RIPE-MD160.  They aren't
interested in changing to a stronger hash until they start seeing
abuse...but I argue...would you ever really see the abuse?

I've matured that web of trust concept:  I believe in 'communities' now --
since that's most likely what will form from a web of trust if you leave
society on its own.  Communities have standards, members,
non-members...certain standards of behavior or resource contribution can be
required by different communities.  With this, anime traders won't have
their pipes and caches filled up with porn...porn traders won't have their
resources filled up with mp3's...etc.

And I'm fantasizing about this really attractive GUI:  the system will
support multiple 'security levels', where security level will be tied
directly to the experience of the user.  Basic security gives you a very
Napster-like interface...and not much more protection than a Napster network
client already gets.  Intermediate security requires that the user think
about their resources and connections in more detail, and allows them to
manage the flow of information to trusted and untrusted parties a bit
better...and the interface reflects this, and enables some of the network
features that aren't obvious to Napster veterans.  Advanced security allows
a technical user to completely bulletproof their filesharing activity, but
requires careful attention and control -- so the interface emphasis should
be on reducing the apparent complexity with reporting and some task-oriented
interfaces to go along with the concept-oriented interfaces that came with
Intermediate.

That is...Advanced is for the security nuts like us...Basic is for the
Napster refugees...and Intermediate is for the people who are exploring and
using some of the extra network, community, and security features.

A friend and I were playing with 'rediscovering' Blocks the other day.  I
ran two nodes on different (LAN-connected) machines, and he ran one over the
internet.  I shared a file on one machine, connected my second client to the
network...saw the file readvertised from his machine, and downloaded it.
(Yes, the file went out over my internet connection from one machine,
through his, and back in my internet connection to my other machine.)  When
the file was finished, though, to my surprise I found that neither my second
node nor his remote node were advertising the file.  Also, when I told my
desktop machine to restart downloading the same file from the same advert
again, it went back out over the network to download the file instead of
saving it to disk immediately from cache.

Weren't these some of the design behaviors intended for Blocks:  automatic
caching and re-sharing of blocks?  That caching is the only way someone can
realistically say that a completely peer-to-peer file distribution service
is efficient -- if everybody along the route is making a copy of the data,
and everybody along the route is reasonably guaranteed to be 'interested' in
the file.

It's great to hear that the list is still alive.

--Spence
bl...@ms...
----- Original Message -----
From: "Blat Froop" <pet...@ho...>
To: <to...@je...>; <blo...@li...>
Sent: Wednesday, May 09, 2001 5:01 PM
Subject: Re: [Blocks-development] Life Signs

> Blocks was discontinued primarily because I ran out
> of freetime. I work on Wall St and things can get
> pretty busy here from time to time, not to mention
> I started playing Counterstrike :-) Also, Blocks
> reached a point where it had demonstrated just about
> everything that I set out to show...
>
> * Encrypted anonymous file transfer is feasible.
> * Packet relay networks are feasible and not too slow.
> * Broadcasting queries to everyone is not always
>   necessary and broadcast adverts (and therefore
>   instant and totally anonymous searches) are feasible.
> * Distribution of large files (>100Mb) is practicable
>   in a P2P network. To my knowledge Blocks is the
>   only P2P network which addresses this.
>
> Competing with Napster/GNUtella/Bearshare/etc was
> not one of the original objectives, and there would
> be little academic interest in continuing with the
> current code base. If Blocks were to be continued I
> would suggest that Blocks2 consist of seperate client
> and server components so that custom clients could
> be built in a GNUtella fashion and perhaps integrate
> some of Michaels ideas about Webs-Of-Trust.
>
> Michael is still flying the Blocks flag at
> http://www.mspencer.net/blocks where you can
> find the binaries and the full source code,
> and I think he's still running a public server
> as well.
>
> If you are mathematically inclined you might like
> to check out SNAKE as well which, at one point,
> I was considering integrating with Blocks as an
> authentication mechanism.
> http://www.mspencer.net/snake
>
> ttfn
>
> PG.
>
>
> >From: "Tod D. Ihde" <to...@je...>
> >To: blo...@li...
> >Subject: Re: [Blocks-development] Life Signs
> >Date: Wed, 9 May 2001 10:45:09 -0500
> >
> >Well, that's not good! :(
> >
> >Is/was the source code GPL'ed? Do you know where I could get my grubby
> >little hands on it?
> >
> >It was an interesting project, and one of the 1st I saw that would work
> >cross-platform (Well, Linux & Windows, but that's better than most).
> >
> >Was there a reason why it was discontinued?
> >
> >  Tod.
> >
> >
> >On Mon, May 07, 2001 at 02:33:49AM +0000, Blat Froop wrote:
> > > Hey Tod,
> > >
> > > alas Blocks is no more. Michael is still running a blocks
> > > node at mspenecer.net but the project is no longer in
> > > development. I think itwas an interesting [rpject tho,
> > > and certainly demonstrated that anonymous P2P file
> > > sharing is a definte possibility for the future.
> > >
> > > ttfn
> > >
> > > PG.
> > >
> >
> >--
> >
> >  * 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
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
>
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/lists/listinfo/blocks-development

Blocks was discontinued primarily because I ran out
of freetime. I work on Wall St and things can get
pretty busy here from time to time, not to mention
I started playing Counterstrike :-) Also, Blocks
reached a point where it had demonstrated just about
everything that I set out to show...

* Encrypted anonymous file transfer is feasible.
* Packet relay networks are feasible and not too slow.
* Broadcasting queries to everyone is not always
  necessary and broadcast adverts (and therefore
  instant and totally anonymous searches) are feasible.
* Distribution of large files (>100Mb) is practicable
  in a P2P network. To my knowledge Blocks is the
  only P2P network which addresses this.

Competing with Napster/GNUtella/Bearshare/etc was
not one of the original objectives, and there would
be little academic interest in continuing with the
current code base. If Blocks were to be continued I
would suggest that Blocks2 consist of seperate client
and server components so that custom clients could
be built in a GNUtella fashion and perhaps integrate
some of Michaels ideas about Webs-Of-Trust.

Michael is still flying the Blocks flag at
http://www.mspencer.net/blocks where you can
find the binaries and the full source code,
and I think he's still running a public server
as well.

If you are mathematically inclined you might like
to check out SNAKE as well which, at one point,
I was considering integrating with Blocks as an
authentication mechanism.
http://www.mspencer.net/snake

ttfn

PG.

>From: "Tod D. Ihde" <to...@je...>
>To: blo...@li...
>Subject: Re: [Blocks-development] Life Signs
>Date: Wed, 9 May 2001 10:45:09 -0500
>
>Well, that's not good! :(
>
>Is/was the source code GPL'ed? Do you know where I could get my grubby
>little hands on it?
>
>It was an interesting project, and one of the 1st I saw that would work
>cross-platform (Well, Linux & Windows, but that's better than most).
>
>Was there a reason why it was discontinued?
>
>  Tod.
>
>
>On Mon, May 07, 2001 at 02:33:49AM +0000, Blat Froop wrote:
> > Hey Tod,
> >
> > alas Blocks is no more. Michael is still running a blocks
> > node at mspenecer.net but the project is no longer in
> > development. I think itwas an interesting [rpject tho,
> > and certainly demonstrated that anonymous P2P file
> > sharing is a definte possibility for the future.
> >
> > ttfn
> >
> > PG.
> >
>
>--
>
>  * 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

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Well, that's not good! :(

Is/was the source code GPL'ed? Do you know where I could get my grubby
little hands on it?

It was an interesting project, and one of the 1st I saw that would work
cross-platform (Well, Linux & Windows, but that's better than most).

Was there a reason why it was discontinued?

 Tod.

On Mon, May 07, 2001 at 02:33:49AM +0000, Blat Froop wrote:
> Hey Tod,
> 
> alas Blocks is no more. Michael is still running a blocks
> node at mspenecer.net but the project is no longer in
> development. I think itwas an interesting [rpject tho,
> and certainly demonstrated that anonymous P2P file
> sharing is a definte possibility for the future.
> 
> ttfn
> 
> PG.
> 

-- 

 * 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                  *

>  
>  Message: 1
>  Date: Sun, 6 May 2001 19:43:21 -0500
>  From: "Tod D. Ihde" <to...@je...>
>  To: Blocks Development List <blo...@li...>
>  Organization: WarmerByTheLake.com
>  Subject: [Blocks-development] Life Signs
>  
>  Is "Blocks" still a living entity?
>  
>  I used to run it ~ a year ago, V0.15 (Still have the code), but have been
>  unable to get V0.17 from sourceforge since then.
>  
>  As it stands, I've switched to running a Freenet server for my users, but
>  I'd like to run Blocks alongside if it's still a viable option.
>  
>  Anyone?
>  
>    Tod.

Maybe if we all use Blocks someone else will pickup the code :) My friend
and I use Blocks for swapping files all the time because he doesn't use irc
or icq.  I have both the source and the windows gui for 0.17 let me know and
I will email them to you if you want em.

_______________________________________________________
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/

Hey Tod,

alas Blocks is no more. Michael is still running a blocks
node at mspenecer.net but the project is no longer in
development. I think itwas an interesting [rpject tho,
and certainly demonstrated that anonymous P2P file
sharing is a definte possibility for the future.

ttfn

PG.

>From: "Tod D. Ihde" <to...@je...>
>To: Blocks Development List <blo...@li...>
>Subject: [Blocks-development] Life Signs
>Date: Sun, 6 May 2001 19:43:21 -0500
>
>Is "Blocks" still a living entity?
>
>I used to run it ~ a year ago, V0.15 (Still have the code), but have been
>unable to get V0.17 from sourceforge since then.
>
>As it stands, I've switched to running a Freenet server for my users, but
>I'd like to run Blocks alongside if it's still a viable option.
>
>Anyone?
>
>   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

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Is "Blocks" still a living entity?

I used to run it ~ a year ago, V0.15 (Still have the code), but have been
unable to get V0.17 from sourceforge since then.

As it stands, I've switched to running a Freenet server for my users, but
I'd like to run Blocks alongside if it's still a viable option.

Anyone?

  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                  *

In designing the future Blocks network, piling crazy idea upon crazy idea,
perhaps it's useful to take a step back and reflect upon the twelve basic
network truths.  This list was originally from RFC 1925, by Ross Callon.

   (1)  It Has To Work.

   (2)  No matter how hard you push and no matter what the priority,
        you can't increase the speed of light.

        (2a) (corollary). No matter how hard you try, you can't make a
             baby in much less than 9 months. Trying to speed this up
             *might* make it slower, but it won't make it happen any
             quicker.

   (3)  With sufficient thrust, pigs fly just fine. However, this is
        not necessarily a good idea. It is hard to be sure where they
        are going to land, and it could be dangerous sitting under them
        as they fly overhead.

   (4)  Some things in life can never be fully appreciated nor
        understood unless experienced firsthand. Some things in
        networking can never be fully understood by someone who neither
        builds commercial networking equipment nor runs an operational
        network.

   (5)  It is always possible to agglutinate multiple separate problems
        into a single complex interdependent solution. In most cases
        this is a bad idea.

   (6)  It is easier to move a problem around (for example, by moving
        the problem to a different part of the overall network
        architecture) than it is to solve it.

        (6a) (corollary). It is always possible to add another level of
             indirection.

   (7)  It is always something

        (7a) (corollary). Good, Fast, Cheap: Pick any two (you can't
            have all three).

   (8)  It is more complicated than you think.

   (9)  For all resources, whatever it is, you need more.

       (9a) (corollary) Every networking problem always takes longer to
            solve than it seems like it should.

   (10) One size never fits all.

   (11) Every old idea will be proposed again with a different name and
        a different presentation, regardless of whether it works.

        (11a) (corollary). See rule 6a.

   (12) In protocol design, perfection has been reached not when there
        is nothing left to add, but when there is nothing left to take
        away.

2000	Jan	Feb	Mar	Apr	May	Jun	Jul (26)	Aug (104)	Sep (19)	Oct (7)	Nov	Dec
2001	Jan (5)	Feb	Mar (19)	Apr	May (23)	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec (4)
2002	Jan	Feb (2)	Mar (5)	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov (4)	Dec
2003	Jan	Feb	Mar	Apr (1)	May (1)	Jun (3)	Jul	Aug	Sep (1)	Oct	Nov	Dec
2004	Jan (4)	Feb (1)	Mar (1)	Apr	May (2)	Jun (2)	Jul	Aug	Sep (1)	Oct (8)	Nov (1)	Dec
2005	Jan	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec
2006	Jan (1)	Feb (2)	Mar (1)	Apr	May	Jun (1)	Jul	Aug (1)	Sep (2)	Oct (4)	Nov (4)	Dec (47)
2007	Jan (19)	Feb (4)	Mar (3)	Apr (3)	May	Jun (18)	Jul (25)	Aug (6)	Sep (11)	Oct (3)	Nov (7)	Dec (4)
2008	Jan (3)	Feb (5)	Mar (28)	Apr (26)	May (15)	Jun (8)	Jul (23)	Aug (5)	Sep (8)	Oct (5)	Nov (1)	Dec
2009	Jan (5)	Feb (5)	Mar (11)	Apr (29)	May (32)	Jun (18)	Jul (35)	Aug	Sep	Oct (3)	Nov (9)	Dec (8)
2010	Jan (3)	Feb (1)	Mar (14)	Apr	May (1)	Jun (10)	Jul (13)	Aug (15)	Sep (13)	Oct	Nov (1)	Dec (4)
2011	Jan (4)	Feb (3)	Mar (1)	Apr (6)	May (1)	Jun (8)	Jul (3)	Aug (4)	Sep (1)	Oct (2)	Nov (1)	Dec
2012	Jan	Feb (2)	Mar (1)	Apr (1)	May (3)	Jun (5)	Jul (6)	Aug (6)	Sep (6)	Oct (1)	Nov	Dec (1)
2013	Jan (2)	Feb	Mar (1)	Apr (13)	May (5)	Jun (4)	Jul (1)	Aug (1)	Sep	Oct	Nov	Dec
2015	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec

blocks-development Mailing List for Blocks (Page 13)

blocks-development — Main mailing list for Blocks