• 3 Posts
  • 30 Comments
Joined 1 year ago
cake
Cake day: July 2nd, 2023

help-circle







  • Cross swarms by v2 feature is not implemented yet in any client I know, yes, the latest versions of BiglyBT support Swarm Merging by v2 hash, but Swarm Discoveries is other thing.

    As far as I know biglybt Swarm Discoveries work by matching size of files, but even in this case it takes a lot of time (millions of torrents) to crawl DHT network.

    To implement something like this clients would announce file hash list DHT, which would come up as a big load on network itself. Better option would be giving this load to trackers, but there's no standard for this yet, announcing something like: info_hash -> [file_hash1, file_hash2...]

    would need another connection method, could be a http POST request.

    Biggest question here is the trackers willing to take this load.

    P.S.

    Did you name your torrent "testing cross swarms"? :D











  • We just created (1 hour ago) a pull request to the TorrentPier (public tracker engine which Rutracker and many other trackers use). It took 2-3 hours.

    Only hybrid torrents allowed currently (torrents containing both v1 and v2 inside)

    Ready abilities:

    • Show file hashes in file list
    • Show v2 hash inside magnet links
    • Removed displaying paddings (.pad folder) and counting their sizes.

    Tomorrow's pull request may contain:

    • Showing file names, hashes and sizes in a table for search indexers to index (any seo advices?)
    • Answer to v2 hash announces
    • Some styling corrections

    Do you have any other ideas? Please comment.

    TorrentPier is the first tracker engine which will release with BitTorrent v2!



  • No, not yet, this question was probably posted by me. I'm one of the provocators to switch to the new protocol.

    The thing is the most tracker admins are:

    1. Too lazy to implement it.
    2. Have too little information about its benefits.
    3. Only heard downfalls associated by compatibility problems, which were exxagerated by people who don't like to update their software.

    I even created a tool called tmrr. Which allows you to extract, compare and calculate file hashes (BTMR hash precisely — BitTorrent Merkle Root, hence it differs from a regular sha256) name for BitTorrent v2 compatible .torrents.

    Which already shows some advantages of use of the protocol in user environment, like finding same torrents contents with different names, reviving dead torrents, preserving historical Internet artifacts' hashes.

    The final feature I'm going to release is the ability to download torrents without duplicates (first time in the history of BitTorrent), saving time, storage and bandwidth. Imagine downloading site, page dumps, libraries, video/photo archives and other uncategorized materials without duplicate files.

    Easily finding how much user storage specific game and its developers wasted due to ineffective coding.

    This feature is ready, but there are some problems in libtorrent (library that qBittorrent uses), which should be fixed by the next release (this year probably) to make it work.

    Hope this will get attention from users and accelerate the switch.


  • No it doesn't, its resource demands are miserable, so don't worry about it, just let it run in the side.

    Bandwidth concerns only should be applied if you have a limited tariff.

    The reason why torrenting is so successful, is due to its resource minimalism and ability of current hdd/ssd drives to last long.

    Due to only read operations being made, which is a fraction of tear of what write operations are doing.

    I have a personal HDD drive (still alive and functioning after 14 years of constant use), started agile torrenting not a while ago (even while I had 2Mbps ADSL connection), already passed TB threshold, and it's still healthy.