Jump to content

BitComet cheats, so µTorrent should IGNORE it!


Switeck

Recommended Posts

  • Replies 146
  • Created
  • Last Reply

Even if you're disconnecting from them after finding out they're BitComet clients, there's a problem -- you'll be forced to constantly disconnect from BitComet clients!

BitComet clients already are VERY agressive in trying to connect to lots of ips on a torrent. That's causing major problems as things are now. Now imagine lots of clients connect to it briefly and then disconnect from it. The BitComet clients will then go into a "frenzy" trying to find ips to connect to. On weaker trackers, it wouldn't be pretty.

Even connecting but completely ignoring them (ie: not passing any BitTorrent protocol data) wouldn't work. BitComet would go into fits trying to repeatedly reconnect and handshake. After all, your connection replied once -- so it should again.

The connection has to be made, pass all the usual data, but ignore hostile activity. And it also has to abide by the BitTorrent protocol while doing it.

Link to comment
Share on other sites

  • 8 months later...
  • 1 year later...

Old news? Again, resurrection with nothing new is.. bleh. People have every right to have their choice of client. Some want small low resource usage and choose uT. Others like plugins, and choose Azureus. Many like everything "in one package" and choose BitComet or other clients.

That evaluation has yet to be discounted through other research, so why not?

Link to comment
Share on other sites

  • 3 months later...

Why don't we compile a list of IP's that use bitcomet and add them to our ipfilter list. No need for new features. Just cut them off completely.

This could be done in a new thread purely for the purpose.

Anyone interested in blocking Comet should have the knowledge required to change their ipfilter settings and/or read how to do it.

BnC

Link to comment
Share on other sites

While I realise a MAC address can be spoofed, how much effort are the BC users going to put in to get at your pieces? Surely they cannot dynamically change their MAC/IP every 10 minutes just to get around this. BC surely wont be able to incorporate a feature of their own to get around that (it would need to know how to access all networking cards to change their MAC addresses)?

Maybe im just talking s**t, I usually do.

bnC

Link to comment
Share on other sites

Some software allows for spoofing, some network cards let you do it from there own settings, so it isn't too hard. I have some older networking cards that are capable of this, and my router can spoof its MAC as well. Changing my routers MAC should also cause it to be assigned a different IP address :/

Link to comment
Share on other sites

Even if you could, it'd probably be a bad idea to blanket-block all BitComet clients. Sooner or later, it will be ONLY a BitComet client sharing the missing pieces on a torrent that you want.

But just because banning it is probably overkill...doesn't mean you should run BitComet yourself.

...Because BitComet is evil:

http://forum.utorrent.com/viewtopic.php?id=29348

Link to comment
Share on other sites

Would it be possible to use the "send have to seed" thing to determine if a newly connected peer is in fact entitled to the 3x more likely to receive mode? Surely a "New" peer would be one with no pieces.

If so you would have to wait for the foreign client to send such information and the setting in uTorrent would need to mandatory.

If after requesting the list of pieces the foreign client refuses, simply assume they have pieces and throw them into the "not new" pile. At the same time, if the foreign client somehow produces a falsified "null" list make some way of determining this and again put the peer in "not new" list.

Just an idea

BnC

Link to comment
Share on other sites

Send have to seed is toggleable in uTorrent, but many clients simply don't report period. It takes a LOOONG time to get their have/relevance (right click in Peers tab, select Relevance to see how much the OTHER peer has which you don't) updated.

As far as more information being stored... it can't be much more, the RAM usage between 1.6 and 1.8 is only like 12%

Link to comment
Share on other sites

Ok but then (if it wouldnt damage the swarm too much) always offer piece number 1. If it is refused then the user has pieces ;) (put them in "not new" list), then after piece number 1 is sent offer second piece by rarest first (standard protocol).

You would follow the 3x more likely to receive in the first instance with piece #1, and the second piece only sent out if piece #1 was accepted. I realise that then all clients would have piece number 1 but in a large file this shouldn't make a huge difference. All clients want piece number 1 (unless "dont download" is enabled, but you could make uTorrent download #1 regardless), and only up to 4MiB potentially wasted!

Just another idea!

BnC

Link to comment
Share on other sites

  • 2 years later...

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...