Quote:
The best way to share partial files is to use tree hashes. This
approach actually provides a greater confidence than the current full
file hash because the client could confirm segments of the file. The
current full file hash can only confirm that the file is the desired
file after it has been fully downloaded. If there is an error there
is no way to tell were it is and the full file must be discarded.
|
I don't think that's really necessary. I mean, you can be quite sure a client doesn't lie about the complete file hash. And I believe the tcp protocol is realiable enough, to be sure the transmitted data is correct. - Maybe run some tests sharing partial files with complete file hashes to see if you really need the tree hash...
Quote:
[...]
The current proposed
solution to the problem is to do a second hash of the file without
the portion containing the meta data. This is very file type specific
and offers little additional benefit when compared with the tree hash, which would offer the benefits of true swarming, partial file sharing,
and the ability to share nearly identical files.
|
I don't believe the ability to share nearly identical files is critical, especially not for small files like mp3s. - For the bigger files, it might be nice, - but edonkey - not having that ability - works fine, too.
Quote:
[...]
2 Protocol Definition
2.1 Tiger Tree Hash
A Tiger Tree hash MUST be generated for each file shared by the client calculated by applying the Tiger hash to 1024-byte blocks of a stream, then combining the interim values through a binary hash tree.
Clients MUST NOT share partial files that have not had a Tiger Tree Hash value calculated.
|
Why not? Clients with tree hashes don't have to swarm from partial files without tiger tree hash...
Quote:
[...]
3.1 Queries and Replies
Queries by clients that can handle Partial File Share MUST indicate this in the query (GGEP?).
All replies of partial files MUST indicate the ranges available and any X-Alternate-Locations for any parts of the file.
|
The X-Alternate-Location was for HTTP connections only, I thought...
Quote:
|
Clients SHOULD NOT display partial file results to the user UNLESS the location of a full file is found or the ranges returned cover the range of the full file.
|
Clients should not return partial file results to queries at all, if the query didn't include a hash. (reduces query traffic and serves the same purpose)
Quote:
[...]
3.3 Uploading Partial Files
A client with a complete file SHOULD randomly upload ranges of the file. If ranges of the file are requested then the client SHOULD randomly choose which ranges to supply first. The intention is to propagate the whole file across the network as rapidly as possible. Clients MAY use X-Alternate-Locations to decide which ranges are rarest and preferentially upload those ranges.
|
That's some kind optimization I wouldn't put into the protocol.
Quote:
3.4 Sharing Partial Files
Clients that are capable of sharing partial files MUST share partial files by default. Client MAY allow users to inactivate the sharing of partial files.
|
I wouldn't put that into the protocol either.
I'm just curious. - Maybe maybe some people who are interested could try out sharing partial files with hashes of the complete file. I'm certainly going to test it with limewire 2.5 (once the huge code is implemented).
And that's how I would do it: Remote clients return queryreplies of partial files if the file is requested by hash. The local client try's establishing a HTTP1.1 connection to them and requests the ranges of the files it needs.
The remote client (if no other error occurs) answers with a 206 (Partial Content) if it has got a subsection of the requested range and with a 416 (Requested range not satisfiable) if the remote client doesn't.
Then the downloading is done and everybody is happy.
The main advantage I see with this way of handling partial uploads is that it's easy to code, relatively secure (do we need absolute security?). Less changes to the protocol and it has mosts of the benefits your proposal has.
I'd rather try using the hammer I have at home before I go buy a bigger one.