[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.
> Anyway, enough of my obsession du jour. Back to the proper BT
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
Yahoo! Groups Links
<*> To visit your group on the web, go to:
<*> To unsubscribe from this group, send an email to:
BitTorrent-unsubscribe at yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
More information about the BitTorrent