Chocobo1
commented
6 years ago Already posted here: https://github.com/bittorrent/bittorrent.org/issues/78
Closed rybazeza closed 6 years ago
Chocobo1
commented
6 years ago Already posted here: https://github.com/bittorrent/bittorrent.org/issues/78
Hi, as I'm a programmer myself using torrent softwares for years but new to the torrent protocols (excuse me if I used wrong terminology)..
Problem statement: One thing I really noticed is how fragmented and redundant torrent swarms have become. Similar file exists in multiple different torrent and seeding one torrent doesn't help another torrent although they have the same file. This leads to the inevitable death of a swarm when seeders eventually leave.
Current solutions: One solution implemented is swarm merging which users can downloads similar files from different torrent swarms. But this I feel is very clunky and hackish as you'll have to find another torrent with exactly the same file (how to be certain it's the same file? The file could be the same but different name and vice versa) then download it separately.
Another solution is from bitcomet, which from my experience is wonderful but have it's caveats. Once file is downloaded, the file hash is uploaded to their server (the negative) so if another user downloading the same file based on it's hash, the server sends the user to be used as seed. It's done automatically but the protocol is proprietary and no information is released for that.
Proposed solution: So what I proposed is using/include file hash using/extending/"creating a separate" DHT to find seeders or peers based on file hash. The current system uses infohash of torrent files to search for peers which in my opinion is pretty outdated and needs updating. Each file hash can easily be included in the torrent file.
Preemptive arguments;
Privacy Some will argue it will publish to much info on what we're downloading but if privacy is concerned, DHT should not be used anyway. Others can still know what you're downloading based on the infohash.
Heavy traffic It'll be heavier than infohash DHT since publishing individual file hash is more.than single infohash. Yes it will, but current technology have advanced since the time DHT is first introduced and the average Internet speed has increased and become cheaper so why not?
Closing statement: Torrent scene has become very redundant as many files are placed in different torrents and seeded separately leading to rapid deaths of old torrents. In dead torrents, file can still be found elsewhere in another seeded torrents and this solution gives it a second chance to live. Regarding the downsides of my proposed solution, those who have slow connection can opt out, disabling it similar to DHT, but the up side can reduce redundancy in the torrent swarms.
Sorry if this is inappropriately posted here but it's something in my head a long time and needed to share it. I can go out make a new client with this new protocol myself but it's pointless if there's no wide user base or big client names adopting it.
Thanks for reading :)