Does size piece have to be uniform within a torrent?

[hermanm]

I ask this because, I occasionally see posts about 99.9% and have experienced the same myself when re-seeding other torrents. If the size piece can change within a torrent, it seems the boundary pieces could have their own size piece. I was thinking file hashing was a good idea but it wouldn't scale very well if you had a single 50GB file you wanted to hash! But if pieces could be re-sized on current boundary pieces, it seems that would avoid the 99.9% issues...

[DreadWingKnight]

All pieces except the final piece are uniform in size.

When a piece crosses the boundary of a file, the remaining bytes of the piece are found in the next file. This continues until the end of the piece or the final byte of the torrent. Whichever comes first.

[jewelisheaven]

Additionally 99.9% issues are unrelated to anything having to do with piecesize.

BitComet decided to implement this very idea. It adds up to n-1 bytes PER FILE where n is the piecesize... needless to say with alot of files more overhead is required. ADDED to the fact one NEEDS to download these files to be a seeder on the torrent. Supposedly BitComet users don't... and if this is the case it's an especially rude behaviour.

This is covered @ http://forum.utorrent.com/viewtopic.php?id=36808

[hermanm]

> All pieces except the final piece are uniform in size.

Right. So, Bittorrent can have pieces that are smaller in size so file boundaries are not crossed?

> Additionally 99.9% issues are unrelated to anything having to do with piecesize.

I would disagree with that statement. When seeding someone else's torrent, boundary piece hash will fail because the other torrent's piece hash do not completely match up with mine. There may be other reasons 99.9% issues occur, like you say, but I'm talking specifically about piece hash failures.

[DreadWingKnight]

Piece sizes currently have only one real practical restriction. Being a multiple of 16384. Cross-file pieces are basically unavoidable in the wild.

Piece boundary differences don't cause hashfail problems like that unless you're missing a file or one of the files is actually different.

[Switeck]

"Bittorrent can have pieces that are smaller in size so file boundaries are not crossed?"

My understanding of the BitTorrent protocol is that only the LAST piece of a torrent can be any size other than maximum.

BitComet's 0-padding to fill piece gaps between files is a kludge at best...and hostile at worst, as typically only the latest BitComet clients can parse such torrents correctly.

[jewelisheaven]

That the pieces are all the same size is specified in the protocol... that's what that "piece length" key in the info dictionary of the torrent is for. Trying to come up with something akin to BitComet's implementation of "pad files to piece boundaries" would only discourage users from using whatever client it's implemented in... at least for torrenting.

[hermanm]

Not trying to discourage use of a specific client. Just interested in exploring ways to hash files in a scalable manner that are not multiples of 16384 bytes.

[DreadWingKnight]

Not possible within the scope of the bittorrent protocol.