reli4ble Posted June 23, 2015 Share Posted June 23, 2015 hello everyone bitcomet is great software but when it comes to private trackers most of them doesn't support it cause if you didn't select full files in the torrent when download finish bitcomet register the torrent as 100% completed even if you deselected some files please fix this issue in the next release Link to comment Share on other sites More sharing options...
The UnUsual Suspect Posted June 24, 2015 Share Posted June 24, 2015 Bitcomet is 100% compliant with bittorrent protocol on private trackers, even more so than most other clients. The claims and rumors to the contrary have been investigated and discussed ad-nauseum and none of the claims have been substantiated. There is no valid reason to not allow bitcomet on any private tracker, those that don't allow it do so out of ignorance. Link to comment Share on other sites More sharing options...
reli4ble Posted June 24, 2015 Author Share Posted June 24, 2015 you can test it open private torrent and disable all files inside it put it on fake seed go to tracker you will find yourself seeding even if no file is downloaded Link to comment Share on other sites More sharing options...
cassie Posted June 26, 2015 Share Posted June 26, 2015 Did you know that you could be banned from private trackers for abusing the file select options? I wouldn't take that chance, if I were you... The person that made the original torrent, put a lot of time and dedication into making it and sharing it with others... not many will be appreciative of their hard work being "sliced and diced" by someone else. Link to comment Share on other sites More sharing options...
The UnUsual Suspect Posted June 27, 2015 Share Posted June 27, 2015 Regarding the "session complete" message, this was never intended by the protocol to be used as any checksum to identify who has or hasn't fully downloaded the entire contents of the torrent and for a tracker to assume that is making an assumption that isn't supported by the protocols specifications. The protocol states it's to be used when a peer is finished downloading, nothing more, nothing less, and if I recall correctly it's not even a required part of the protocol. Also not all private trackers do this and the ones that do should have taken into account the way all popular clients behave and coded their tracker to work with them rather than unilaterally changing the definition of what a signal means and complaining when all the existing clients don't adapt to meet their unique idea of what they should do. The Shadow made the same mistake and embarrassed himself when he developed his superseed technology without realizing that some clients prefer to disconnect from non active peers to reduce load on routers. He then made another false assumption that the disconnect was followed by an immediate reconnect in order to gain an optimistic unchoke and was again mistaken when it was proven that BitComet waits far too long before any reconnect attempts for it to gain any advantage. All of this was proven in the Rob Topolski paper, and independent expert who proved that all these claims were false. The Shadow further embarrassed himself when he claimed that BitComet purposefully started doing this to abuse his unique technology and it was later proven that bitcomet behaved the same way long before he developed his technology. I do admire The Shadow for his contribution to the bittorrent community by developing superseed, however it's of very little use today. Back when most internet connections had gross data transfer limits it was useful for the original uploader to only have to upload about 110% of a torrent before other seeders appeared rather than about 150%+ without superseed, but with modern isp connections being fast and unlimited it really doesn't matter and you can fully seed a torrent much faster without using superseed, but nonetheless bitcomet did add the option to our client years ago to satisfy those who wanted the option and since it was the only weak point that was identified in the topolski paper. Regarding disabling files in a torrent, Cassie is correct, if you disable all the files within the torrent it could appear that you are cheating by some anti leech mods that trackers use, but again their system of detection is also attributing reasons for the complete command that wasn't written into the protocol. It's also an inefficient method of downloading if you disable files. Many trackers put large packs in "free leech" and people abuse that by only downloading part of the torrent which is available in other torrents that aren't free leech and they do this to avoid the need to upload and are doing so at the cost of other peers who are connecting to you expecting you to be downloading and sharing the entire torrent yet you only have few pieces to offer and they are usually the most common in the swarm. Being a tracker admin myself I find members that do this to be a festering sore on the community. It's alright if it's done now and then if there is a rare item in the pack that isn't available elsewhere, but to do it as a habit will usually result in a warning and eventual ban. I'm also sorry for the late reply. I have debated these facts for almost a decade with torrent trackers worldwide many of whom I have enlightened and who now allow bitcomet, while others remain in ignorance and I'm neither eager or willing to open another debate on this issue because I am short on help here in the forum and what little time I have available I will use to help members, not repeat facts that are available online from the many debates that I have been involved in for so many years. By the way, if you want an experiment you can do yourself to demonstrate how BitComet is more protocol compliant than most (if not all) other clients, then try this. Make two or more identical torrents to upload to two or more private trackers. They have to be 100% identical and have the exact same infohash. When you open the second to seed in any client it will recognize that the torrent already exists since they have the same infohash and will combine both (2 or more) trackers into the same torrent. Every client we tested then uploaded to all trackers and assuming you uploaded 10gb to tracker A and 20gb to tracker B, all the other clients then reported a total of 30gb to both trackers. This will flag you as a ratio cheat and could get you banned from both trackers. Some trackers have used custom scripts to reauthor every torrent uploaded and changing them enough to be sure they each have a unique infohash, but unless the tracker has a sysop or coders who are very talented, they will upload the torrent unaltered and this condition will exist. BitComet on the otherhand is the only client that I'm aware of that won't do this. When using a private torrent with multiple trackers in BitComet it will only connect to one tracker at a time and if trackers are switched it will clear the peer list so that no peer upload from Tracker A peers is reported to Tracker B and vice versa. I reported my findings to uTorrent, but they didn't seem interested in developing a solution. It seemed like they felt that was something they would let the trackers and peers worry about. They did have a point since it is a situation that can be avoided by putting a unique file in each torrent even if it's just a text file with the trackers name which would be enough to assure a unique infohash, but nonetheless it is unique proof that BitComet was the only tracker we could find that fully complied with private tracker protocol in this regard. It's been a couple years since our testing and development so it's possible others have adopted our solution, but if so, none have made us aware of it so I believe we are still unique in this regard. The change was listed in the release notes, you'd have to search through the notes to find which version it first was implemented but I think it was somewhere between 105 and 115 versions. ps. If your private tracker admin has any questions he can contact me and if you're interested in reading the topolski paper you can find it linked in our independent reviews section at bitcomet.com. Link to comment Share on other sites More sharing options...
reli4ble Posted June 27, 2015 Author Share Posted June 27, 2015 (edited) i don't disable files in torrent but even if not bitcomet doesn't send you as a leecher it reports you as a seeder even if you just disabled all files without downloading a thing and this is the only reason why most of private trackers banned bitcomet and they prefer that silly utorrent over it lol Edited June 27, 2015 by reli4ble (see edit history) Link to comment Share on other sites More sharing options...
The UnUsual Suspect Posted June 27, 2015 Share Posted June 27, 2015 Actually there have been a long list of things they claimed bitcomet has done wrong, but all are false. Disabling all the files is an abusive thing to do and the only reason their tracker sees it as a seeder is because they mistakenly attribute the signal to imply all the files were downloaded. The proper way to do it is make sure the total downloaded matches the size of the torrent. You can't expect all clients to behave in a way contrary to the protocol specifications simply because their favorite client does it that way and my test will provide evidence that their favorite client can be used to cheat where bitcomet cannot unless they have made modifications to assure all their torrents have unique infohash compared to torrents with identical content on other trackers. I suggest you read the topolski paper and you might also be interested in a press release that I wrote a few years back with the help of the rest of our forum staff that can be found here Link to comment Share on other sites More sharing options...
reli4ble Posted June 29, 2015 Author Share Posted June 29, 2015 thanks i will read interview but just try to make developers aim to that disable files problem Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now