[BitTorrent] Re: bt2 protocol features

Olaf van der Spek OvdSpek at LIACS.NL
Thu Jun 10 11:54:16 EDT 2004


Stephen Thomas wrote:

> --- In BitTorrent at yahoogroups.com, Elliott Mitchell <ehem at m...> wrote:
> 
>>Until that time do you object to this remaining an idea to
>>_try_ to put in place?
> 
> 
> Personally I think the idea of retrieving blocks by their hash codes
> is quite beautiful (I was throwing this idea around in here a month or
> two ago, but my vast ignorance of things IP cost it all credibility).
> 
> It occurred to me several years ago that it ought to be possible to
> construct an entire file system on top of that idea; that such a file
> system would end up being absolutely content-addressable, and
> therefore location-insensitive; and that that would be a Good Thing. 
> Mind you, I was in the grip of psychosis at the time, so it probably
> needs to be thought about carefully by more people.

So if you edited for example a configuration file, it's name would 
change and you'd have to edit the symlink to link to the new name?
That doesn't sound very nice to me.

> Olaf, your point about large blocks needing fewer hashes is well
> taken; but is the difference between transferring 102% of the data and
> 101% really such a big deal?  I think not, especially having seen

41 mb for a 4 gb torrent with 16 kb blocks. But it's avoidable overhead 
and I'd like to avoid as much as possible.
And it'd also require a map to map from block hash to block index and 
that'd require already 5 mb for only the hashes.

> upwards of 130% with BT on my slow dialup link due to redundant piece
> requests getting cancelled too late.
> 
> There is no need for "all-the-way-to-the-root" stepwise Merkle
> verification at any point, because each block is immediately
> verifiable against the hash it was retrieved with.
> 
> A directory, in this scheme, is simply a dictionary file in some
> convenient format that maps human-readable names and metadata to "true
> name" hashes.  Directories could therefore be stored and retrieved
> exactly like files.
> 
> To limit upstream bandwidth, all an ISP would need would be the
> block-retrieval engine and a big fat cache; no file-assembly logic at
> all.  So a proxy would be simpler than a client, wouldn't need BGP

> feeds or whatever, and would have plausible deniability for
> responsibility for content.
> 
> Other interesting possibilities follow from allowing all nodes, rather
> than just the last leaf node in a file, to be only part-full. 
> Judiciously used, this could let patched files share substantial
> storage with their unpatched cousins, or ISO packagings share storage
> (and, of course, retrieval shareability) with the files they contain.

Certainly interesting.
> 
> Anyway, enough of my obsession du jour.  Back to the proper BT
> discussion.
> 
> Cheers
> S



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/dkFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
     BitTorrent-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/
 



More information about the BitTorrent mailing list