Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MetadataMode - bep52 #663

Merged
merged 4 commits into from
Jul 17, 2024
Merged

MetadataMode - bep52 #663

merged 4 commits into from
Jul 17, 2024

Conversation

alanmcgovern
Copy link
Owner

Fixed several bugs around requesting piece hashes for BEP52 torrents. Such as:

  • Correct handling for requesting piece hashes when the piece layer is not an exact power of 2 in length.
  • Correct handling of torrents which consist of files small enough to fit inside 1 piece.
  • Correct handling of torrents containing duplicate files (which have the same underlying hash!)
  • Improved logging for debugging purposes

A long time ago I made an assumption that, like elsewhere in the spec,
the final request for piecehashes would be truncated if it extended
beyond the end of the hashes. How wrong I was.

After validating against libtorrent 2.x (using qbittorrent) I confirmed
this doens't happen, and fixed up the impl to no longer truncate the
last message, but to full it with padding hashes instead.

The internal datastructure is still sparse though - it doesn't create
a buffer to hold all the padding hashes.
If no file is logner than 1 piece, then we don't need any piece hashes,
and can create the 'HashesV2' object immediately. The file can be fully
validated using just the root hash.
@alanmcgovern alanmcgovern merged commit b73b9ed into master Jul 17, 2024
@alanmcgovern alanmcgovern deleted the metadata-bep52 branch July 17, 2024 06:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant