Re: [Blocks-development] Life Signs

[Tod D. I. <to...@je...>]

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                  *