Huggybaby Posted April 13, 2008 Report Posted April 13, 2008 How do torrent clients differ when connecting to the swarm?1) I'm wondering, since I exclusively use µTorrent and can't compare, if different clients end up connecting to the swarm differently. Not initially, of course, but after a reasonable amount of time, say, 15 minutes.2) And more specifically, do clients preferentially connect to the same client?For example, would an Azureus user see more Azureus peers overall, compared to a µTorrent user, and vice versa?This would make sense because Azureus, as I understand it, supports a different version of DHT than µTorrent.3) And, aside from that honest difference, if it still exists, are there any clients that use different (less honest?) connection methods, and, if so, how do the "normal" clients deal with it?Thanks!
Ultima Posted April 13, 2008 Report Posted April 13, 2008 1) Well, connecting to a swarm does imply only the initial connections, since you're only connecting to the swarm when you're not in the swarm in the first place. If you're asking about how different clients communicate with other peers... well, sure there are probably some differences, but overall, I wouldn't expect things to be too different.2) Fair clients wouldn't do this, no. It's somewhat dumb to prefer only your own client anyhow -- not all fast peers use the same client as you. Azureus using a different DHT than µTorrent doesn't really mean it's preferring its own peers. It simply means that its pool of potential peers to connect to is largely Azureus. Regardless, though, there is (AFAIK) a mainline DHT plugin available for Azureus now, so that's probably less of a problem.3) Less honest connection methods?
Huggybaby Posted April 13, 2008 Author Report Posted April 13, 2008 3) Yes, there have been certain clients banned from certain trackers for not playing fair, I don't know the specifics and I think those clients have been fixed.
Firon Posted April 13, 2008 Report Posted April 13, 2008 BitComet (and its derivatives) act unfairly. No, they haven't been fixed, and they never will be.Different things are done by different clients to deal with its behavior. In BitTornado's case, it banned BitComet clients outright.
Dark Shroud Posted April 16, 2008 Report Posted April 16, 2008 "BitComet (and its derivatives) act unfairly. No, they haven't been fixed, and they never will be."That's quite a bit of a stretch in a number of ways. Especially since the original complaint was that BitComet did not share it's encryption and that gave favor to other BC clients. Now BC uses the standard encryptions."Different things are done by different clients to deal with its behavior. In BitTornado's case, it banned BitComet clients outright."Except Shadow has yet to actually release a version that does ban BitComet.
jewelisheaven Posted April 16, 2008 Report Posted April 16, 2008 BitComet thread http://forum.utorrent.com/viewtopic.php?id=34911Azureus thread http://forum.utorrent.com/viewtopic.php?id=34548Ultima covered your main points... In theory there is no difference in connecting to a swarm. The experienced differences are usually due to the disparate DHT swarms (for non-functional trackers) OR the default retry connect times between clients.... I.E. when firewalled I find I connect to BitLord and BitComet peers first from a functional tracker because they have UDP hold punching.
Firon Posted April 16, 2008 Report Posted April 16, 2008 it's quite well known what bitcomet does. and it's not just the encryption.spend 5 minutes and research if you don't know.the padding files and abuse of seeders is enough to ban the client together. I bet if we blocked BitComet by default, a new version would suddenly come out that fakes what it is.
Switeck Posted April 16, 2008 Report Posted April 16, 2008 Just a reminder...BitComet is EVIL!http://forum.utorrent.com/viewtopic.php?id=29348&p=1
Dark Shroud Posted April 25, 2008 Report Posted April 25, 2008 It took me a little while to get back to this. Anyway here is a nice paper explaining that most of the accusations against BitComet are false. http://www.zeropaid.com/news/8945/STUDY:+'Examining+the+Myths+and+Facts+Concerning+BitComet+Behavior'The padding issue is really a disagreement and has been set to off by default.
DreadWingKnight Posted April 25, 2008 Report Posted April 25, 2008 From the article:self-describedThis tells me that as good as he may or may not be, he is NOT a certified network expert. For the network protocol (unchokes, connection attempts, other protocol issues) I would want to see packet captures of all the tests before I believe that "report".No report has succeeded in refuting the "spying" effect.
jewelisheaven Posted April 25, 2008 Report Posted April 25, 2008 Yep the reviewer posts here... 2 guesses what nickname he's got on this forum I don't see any mention of "pad file to piece boundary" except in the initial .85 implementation post @ http://blog.bitcomet.com/category/30938/1/2/?type=detail so I can't attest to its default state. The main objection I have is that because of the "simple" checkbox for what's really a pain in the tookus (exponentially as # of files increases)...means more data to download. Was this option changed from default on to default off?Regarding BitComet trying to be "more fair"... An interesting development I just found was this user-created patch to stop masking as "BitTorrent/3.4.2" user-agent... apparently what all the "other" naughty clients do. Since this is not for peers but trackers, perhaps it will spread more until the release of BitComet with its own user-agent string (There should be a new 1.01 release any day now from previous 1/mo. releases.)PLEASE NOTE: I have not used BitComet or this patch, I provide information about it so you can decide and verify you have an official release.MD5 of said patch follows and information can be found @ http://blog.bitcomet.com/post/19767/e54193e76cea4f77591f9a2b655fe9f5 *UniBitComPatchBuild170308.rar43a4706ef17bff4d98ca1b50524c39aa *UniBitComPatchBuild190308.rar440c12bf4d342555ad463311dd75e325 *UniBitComPatchBuild240308.rarThe most recent (v 1.2) archive is locked, 463 KB (475,075 bytes) in size, and includes GetUBCPUpdate.exe UniBitComPatch.exe and patchreadme.txt.
Dark Shroud Posted August 9, 2008 Report Posted August 9, 2008 Just an updates since this thread seems to contain a lot of data/complaints.BitComet v1.02 2008.6.3 Release Notes: Tue Jun 3rd Core Bugfix: error occurs when connect to certain trackers: "Tracker Reture Zero Length Response" Core Bugfix: EVENT_COMPLETE should be sent to tacker only when all files in BT task downloaded, not only selectedBitComet v1.03 2008.7.17 Release Notes: Thurs July 17th GUI Improved: new advanced option: User-agent sent to HTTP tracker Core Improved: remove NAT Traversal via UDP, to improve TCP transfer efficiency
DreadWingKnight Posted August 9, 2008 Report Posted August 9, 2008 1.03 = autofail on the gui improvement.
Dark Shroud Posted August 10, 2008 Report Posted August 10, 2008 "1.03 = autofail on the gui improvement"Would you care to elaborate?
DreadWingKnight Posted August 10, 2008 Report Posted August 10, 2008 Any client that allows you to customize what it claims to be has something to hide.
The8472 Posted August 10, 2008 Report Posted August 10, 2008 Any client that allows you to customize what it claims to be has something to hide.Not necessarily. Some private tracker admins are also very unreasonable about their policies and their banning strategies are close to arbitrary. Offering a user to change the client signature would make sense to get around such arbitrary bans. Though yes... in bitcomet's sense i'd say they are justified.Though that's more of a design flaw in private trackers, since they rely on user-reported data in the first place.
thelittlefire Posted August 10, 2008 Report Posted August 10, 2008 Bitcomet took out NAT transversal... one of the proposed additional features for 1.9
Dark Shroud Posted August 11, 2008 Report Posted August 11, 2008 Any client that allows you to customize what it claims to be has something to hide.Originally I was glad that BitComet now reports it's self correctly for everyong. But I decided to test to see if this could actually mask the client. The one private tracker I go to that bans BitComet (AsianDVDclub.org) can still detect that it's BitComet.Not necessarily. Some private tracker admins are also very unreasonable about their policies and their banning strategies are close to arbitrary. Offering a user to change the client signature would make sense to get around such arbitrary bans. Though yes... in bitcomet's sense I'd say they are justified.Not to mention the users who block clients as well without thinking of the consequences of such actions.Bitcomet took out NAT transversal... one of the proposed additional features for 1.9Well if µTorrent releases it's own NAT Traversal then maybe BitComet will switch to that versions as it did with encryption.
Ultima Posted August 11, 2008 Report Posted August 11, 2008 Not to mention the users who block clients as well without thinking of the consequences of such actions.Indeed, which is why we oppose/reject manual ban requests Many trackers go by more than just user agent. Some have been known to go as far as analyzing annouce patterns/behaviors.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.