Re: [Blocks-development] Life Signs

[Blat F. <pet...@ho...>]

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