Stuffer

I request an option to filter and kickban certain peers/clients automatically, like Azureus' stuffer. This would be an optional configurable feature, disabled by default.

A search for 'stuffer' came up with http://forum.utorrent.com/viewtopic.php?id=635

I've created a new request as that thread went off topic. (It became a discussion on DHT.)

From the above mentioned thread:

As for client banning, we believe it's the tracker admin's job to take care of it and not µTorrent's. We try not to discriminate.

If the same logic were applied, µTorrent's torrent creator would not have an option to add the private flag.

If a tracker admin wants to ban certain clients, that's her/his choice. I'd like to have that choice as well.

Certain clients, like BitComet, don't respect all private flags and, more importantly, don't follow the bittorrent protocol properly, and by doing so trick peers into sending them more data, slow down swarms, and waste uploader's bandwidth.

I want to be able to easily block such clients. One could of course block individual peers with other software, but that is much more time consuming, and thus far less efficient.

I'm sure many will disagree, and that's fine, but at least be courteous enough to back your opinion with valid arguements. good luck.

[Brought from the other thread... -Firon]

I'm fully aware my request is provocative to some people as so many threads have shown so well. That whoever, shouldn't be a reason for closing it. Whoever closed it pulled the trigger too soon. The argument mentioned in other threads regarding peer banning;

1. "harmfull to the swarm",

2. "the bittorrent protocol takes care of it",

3. "there's other software to do that"

are invalid when used against my request, the stuffer, which isn't the same.

1. Invalid; people who try to leech don't need this feature, they do it regardless. The bittorrent protocol, although at large based on a tit for tat basis, doesn't prevent leeching from and cheating other peers.

2. Invalid; clients that violate the bittorent protocol, like BitComet #, are not affected as they don't play by the rules to begin with.

3. Invalid; sure, one could manualy add IPs to the block list of firewalls and peerguardian and alike, but not as efficiently were it a µTorrent feauture, let alone blocking connections based on client IDs.

#

BitComet "respects" it's own private=1 flag but ignores Azureus' and uTorrent's, which both inteligently do it the same way.

So, no client out there can make a torrent that is private for both uTorrent/Azureus and BitComet.

Also, the reason BitComet's is different is because it puts the flag *outside* the info dictionarywhich means it's not included in the info_hash which means that anyone can easily remove it and not effect the torrent info_hash and so make what was previously a private torrent, public again, i.e. a big waste of time.

As for the sloppy protocol implementation, clients are not supposed to send out packets late. If they do, the clients that receive them will more than likely just dump the packet because by the time it finally gets the packet it was promised, it will likely have, following the guidelines in the specifications, given up waiting and just requested and likely received the same packet from another peer.

But, the BitComet clients still claims it as a transfered packet and the receiving client, assuming it is not a BitComet client will also count the wasted packet as a transfered packet.

So, BitComet clients can end up sending a whole lot of shit that doesn't do anyone any good and yet take credit for it.

Beyond that, I won't get into BitComet hammering other clients even after being refused a connection or all the other ways BitComet gives the impression to the user that it is a fast client when all it is doing is wasting time and bandwidth.

I'd like a stuffer like feature. This would allow me to block leecher clients like BitComet effeciently.

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

another thread about banning.

BitComet "respects" it's own private=1 flag but ignores Azureus' and uTorrent's, which both inteligently do it the same way.

Do you have actual proof of that? I don't like BitComet either, but that's a totally unfounded claim.

* For a torrent maker:

Make the torrent file under Only accept peers from tracker (No DHT or Peer Exchange) read Torrent Maker for more infomation. This option will add a private tag in torrent file, and is the same meaning as SecureTorrent in Azureus (http://azureus.aelitis.com/wiki/index.php/SecureTorrents).

To prove at least this part, make a proper private torrent with BitComet, and put it on megaupload.com or something so I can view it myself in a hex editor.

To prove the other part, screenshots of BitComet with private torrents made by Azureus/µTorrent. And with a REAL BitComet build, not a patched/hacked one.

I don't really understand why I have to prove cheating and broken clients exist and are used. That's a well known fact. But lets have a go anyway.

From http://wiki.bitcomet.com/help/SecureTorrent :

This option will add a private tag in torrent file, and is the same meaning as SecureTorrent in Azureus

"The same meaning" isn't necessarily "the same implementation".

As requested, I made some torrents with BitComet 0.60 and µTorrent 1.2.2, had someone extract the torrent-tree for me, rarred the lot and uploaded it: downloadable at http://server3.uploadit.org/files/DrSutorrent-torrents2.rar.jpg (use a download manager and rename to .rar).

Does BitComet put the private flag in the correct place? Looks like at least version 0.60 does, I don't know about older versions.

Does BitComet respect private torrents made with Azureus/µTorrent? For the average user it looks like it does, but...

From the BitComet forum

http://www.p2pforums.com/viewtopic.php?t=17540 September 2005

just info (parts are applicable to previous versions of Bitcomet, BitLord, BitSpirit)

1.

210.***.***.*** - - [24/Sep/2005:21:38:14 +0200] "GET /tracker/announce.php?info_hash=%5D%E8%BD...&peer_id=%2DBC0060%2D%5D...&port=49152&uploaded=973832192&downloaded=4689215488&left=0&numwant=200&compact=1&no_peer_id=1&key=9578&event=completed HTTP/1.0" 200 959 "-" "BitTorrent/3.4.2"
210.***.***.*** - - [24/Sep/2005:21:48:15 +0200] "GET /tracker/announce.php?info_hash=%5D%E8%BD...&peer_id=%2DBC0060%2D%5D...&port=49152&uploaded=973848576&downloaded=4689215488&left=0&numwant=200&compact=1&no_peer_id=1&key=9578 HTTP/1.0" 200 958 "-" "BitTorrent/3.4.2"
210.***.***.*** - - [24/Sep/2005:21:58:15 +0200] "GET /tracker/announce.php?info_hash=%5D%E8%BD...&peer_id=%2DBC0060%2D%5D...&port=49152&uploaded=973848576&downloaded=4689215488&left=0&numwant=200&compact=1&no_peer_id=1&key=9578 HTTP/1.0" 200 959 "-" "BitTorrent/3.4.2"
210.***.***.*** - - [24/Sep/2005:22:08:16 +0200] "GET /tracker/announce.php?info_hash=%5D%E8%BD...&peer_id=%2DBC0060%2D%5D...&port=49152&uploaded=973848576&downloaded=4689215488&left=0&numwant=200&compact=1&no_peer_id=1&key=9578 HTTP/1.0" 200 959 "-" "BitTorrent/3.4.2"
210.***.***.*** - - [24/Sep/2005:22:28:10 +0200] "GET /tracker/announce.php?info_hash=%5D%E8%BD...&peer_id=%2DBC0060%2D%5D...&port=49152&uploaded=973848576&downloaded=4689215488&left=0&numwant=200&compact=1&no_peer_id=1&key=9578 HTTP/1.0" 200 1025 "-" "BitTorrent/3.4.2"
210.***.***.*** - - [24/Sep/2005:22:46:23 +0200] "GET /tracker/announce.php?info_hash=%5D%E8%BD...&peer_id=%2DBC0060%2D%5D...&port=49152&uploaded=0&downloaded=0&left=2097152&numwant=200&compact=1&no_peer_id=1&key=9578 HTTP/1.0" 200 1091 "-" "BitTorrent/3.4.2"
210.***.***.*** - - [24/Sep/2005:22:51:25 +0200] "GET /tracker/announce.php?info_hash=%5D%E8%BD...&peer_id=%2DBC0060%2D%5D...&port=49152&uploaded=196608&downloaded=1998848&left=2097152&numwant=200&compact=1&no_peer_id=1&key=9578 HTTP/1.0" 200 1157 "-" "BitTorrent/3.4.2"
210.***.***.*** - - [24/Sep/2005:22:51:34 +0200] "GET /tracker/announce.php?info_hash=%5D%E8%BD...&peer_id=%2DBC0060%2D%5D...&port=49152&uploaded=212992&downloaded=2097152&left=0&numwant=200&compact=1&no_peer_id=1&key=9578&event=completed HTTP/1.0" 200 1157 "-" "BitTorrent/3.4.2"
210.***.***.*** - - [24/Sep/2005:23:01:34 +0200] "GET /tracker/announce.php?info_hash=%5D%E8%BD...&peer_id=%2DBC0060%2D%5D...&port=49152&uploaded=212992&downloaded=2097152&left=0&numwant=200&compact=1&no_peer_id=1&key=9578 HTTP/1.0" 200 1090 "-" "BitTorrent/3.4.2"

(log fragment has been edited to remove private information)

There is a clear evidence the Software does not follow BitTorrent Protocol Specification by reporting lesser amounts in downloaded and uploaded then has been reported earlier, as well as sending event=completed several times.

2. When ALL of the following take place:

- private flag is set inside info dictionary of .torrent file;

- private flag was returned in previous tracker response;

- "Add DHT Network as backup tracker" is unchecked;

- "Enable DHT network" is unchecked;

the Software enables use of DHT network and peers exchange when ANY of the following occur:

- tracker response timeouts;

- tracker response is invalid;

- tracker response consists of "failure reason";

- tracker does not respond in form of 40* error;

3. Despite private flag is set inside .torrent file, the Software caches current peers IPs and ports, using them after torrent Stop->Start sequence. Also, Software saves cached peers on persistent storage on exit, using them on restart.

4. The Software allows user to edit announce URL supplied by .torrent file with private flag set. As a result, user can intentionally screw up announce URL and enable DHT and peer exchange as described in [2].

5. When Software is launched with several torrents tracked by same server, it sends all requests at the same time in parallel, not sequentially. This behavior may cause synchronization problems with some tracker software, making incorrect calculation NN of peers for this user when processing event=started (specially when making port test).

6. When Software does not have DHT and peers exchange currently enabled, while operating on private tracker with private torrent, it DOES communicate via DHT with other peers who has DHT and peer exchange enabled.

Conclusion:

The Software is recommended for use on public trackers and in trackerless mode due to its immortal and reliable DHT and peers exchange features.

However, the Software is NOT recommended for use on private trackers, trackers with extra user identification enabled, and trackers which require statistics reported properly according BitTorrent Specification.

Lets continue..

http://www.p2pforums.com/viewtopic.php?t=17442 November 2005

Its a case of Bitcomet not honoring private flags in torrent. We have been doing some testing. ie we have a user downloading torrent xyz. The user is a leech so is banned on site and his passkey is scrambled. Bitcomet reports a tracker error then after a certain length of time dht kicks in even though it is disabled in client and the flags are added by the site when the torrent is downloaded. We have had no other problems with other clients in the same type of scenario.

It's because people have "Add DHT Network as backup tracker" enabled. This feature exists so if a tracker permanetly goes down BitComet kicks in the DHT so users can continue downloading/uploading. On one hand I hate this feature because it can be abused by leechers, but on the other hand I understand why it exists and agree that it is a useful feature to have. But to answer your question, no, as far as I know if the user has enabled that option there is no way for the tracker to stop DHT from enabling if the tracker becomes unresponsive. All BitComet is trying to do is help the users finish their transfer if the tracker goes offline

If bitcomet did honor the private torrent flag explicitly then we would allow it.

That seems to be the only course of action for now Hopefully that problem is remedied in future versions.

ie, BitComet has a feature "Add DHT as backup tracker" that will override its own DHT setting, even for private torrents, when a tracker is unresponsive. That's a serious bug, but peanuts compared to its bad behavior towards other peers.

BitComet intentionally lies to skew the tit-for-tat process in its favor. "Yes, but didn't it say right in the beginning "parts are applicable to previous versions of Bitcomet, BitLord, BitSpirit"?" Yeah, that's right. But that doesn't matter as previous versions are still available, and many people don't update their client anyway: http://download.bitcomet.com/achive/. If it was nonsense, a BitComet developper would have responded and refuted it. That didn't happen. BitComet cheats..

Superseeding is often so inefficient because of BitComets in the swarm. Any uploader using Azureus can tell you that blocking BitComet drastically improves the performance of superseeding. Clear indication of BitComets bad behavior.

Some client I'd like to block with a stuffer:

BitComet 0.56, a broken client

A hacked client

Even if future BitComet versions would play by the rules, the older versions will still be in use. Historically, bitcomet has been banned almost everywhere at some point; and it's still the favorite among cheaters.

BitComet isn't the only client that cheats. It's just the most populair. I'd like to be able to efficiently block all clients that don't follow the bittorrent specifications, be it official builds or hacked versions.

"This would be harmful to the swarm."

Really? Swarms would benefit from blocking cheating clients. The cheaters are the ones getting hurt.

"Yeah, but someone could block all clients except µTorrent."

Sure, but that would be pretty dumb as that would hurt him/her the most.

Any idea what the potential harm of the already implemented seeding rule is? "Seed While Ratio is: <= 1%" + "When Torrent has reached the seeding goal, limit the upload rate to 0 kB/s (= stop)" That's a cheater's wet dream.

If a feature with such a potential harmful effect is already implemented, don't tell me a stuffer could be so harmful to the swarm, it won't be implemented...

PS Firon, what happend to http://forum.utorrent.com/viewtopic.php?id=3166 (titled: Who closed my thread and why?) ?

I merged your post there with your first post here, since the thread wasn't necessary anymore.

BitComet pissed me off for a lot of other reasons (SO MANY THINGS it does wrong that just cause grief for all other clients, including how it makes torrents...) but I was always under the impression that it at least respected the private flag. Boy, was I wrong.

Anyway, I've done my own research too and also realized that BitComet doesn't respect the private flag. It always uses DHT if the tracker is unreachable (ie user is banned, or its down), even if you explicitly turn it off it STILL uses it, regardless of the existence of the private flag...

A lot of trackers realized this too and have started banning it (very recently) because of that. This knowledge actually wasn't that well known surprisingly, but it's spreading like wildfire now.

basically your proof wasn't necessary anymore but blah, yet another reason to add onto the list of why bitcomet sucks.

it also does a lot of cheating when you cap your upload to low amounts so you can get good speeds anyway...

some user was in here a few days ago bitching about ut going slow when he capped his upload to 3 KB/s. he said I'm going back to bitcomet, the leeching bastard.

So you now agree that having a stuffer would in fact be quite useful and beneficial to the swarm, and thus would be a good addition to µTorrent?

I'm against any form of banning user-agents by users. It won't help, as the banned clients will just fake their user-agent.

But more importantly, chances are that users will start to block any user-agent that don't upload (fast) enough or for any reason hold a grudge against. Let's be honest, a lot of users cannot handle the responsability of blocking or not blocking clients/user-agents. In the process, they will not only hurt themselves but also the entire swarm and will give µTorrent a bad name.

The only good sollution I can recommend that the are some default UA-filters build into µTorrent (which can optionally be turned on), for clients/UA that really do cause problems or when superseeding, some clients are skipped.

Did you actually take the time to read the thread?

A stuffer (client ID blocking) is not manual peer banning.

It wouldn't be possible to manually ban individual peers.

You either allow a client ID (the default), thus all peers using that client ID, or block it, thus all peers using that specific client ID.

Until µTorrent becomes much more common, this feature will only hurt peoples ability to download/upload things.

boo, how? It's optional, disabled by default.

µTorrent's popularity has nothing to do with it.

yes there is because azereus and bitcomet is the most common clients, so if you for example block bitcomet, you might have trouble to download on torrent with smaller swarms.

Or if you block bother azereus and bitcomet, you will only be able to download from mainline, ABC, µTorrent peers etc, which will defently make your speeds suffer, even on big swarms it will make your speeds suffer.

And you say users should be able to turn it on/off and its off by default,

then the feature loses its purpose.

Therefore, until µTorrent isn't an minority, this feature is just a bad feature.

boo, I'd like to be able to efficiently block all cheating clients. BitComet slows down swarms, that's a fact. It's one of the most popular clients because it cheats other peers, including you and me. Just read my previous posts, to read the proof for that. Large swarms are nice, but not if many clients in it efficiently cheat and suck up most of its recourses. If you, and preferably more people, would block those clients, the swarms efficiency would increase.

The fact that those clients are so popular only makes a feature to block them more wanted.

Any optional feature should have an on/off switch, wouldn't you say? Don't want to use it? Don't turn it on. Just like you have the choice to either use DHT, superseeding, scheduler, etc. or not.

Did you actually take the time to read the thread?

Yes, with USER-AGENT blocking, I refer to CLIENT-ID blocking.

Here is an example why this shouldn't be implemented. Say, this feature is included. People start blocking BitComet because of all the problems and BT-protocol violations you described. It is not very handy to block every single version / client id of BitComet, so they use something like BitComet/*. Now BitComet feels the pressure, and they change some code, and put out a new version, 0.61 for instance, which does work according to the BitTorrent Specs and also correctly implements DHT.

Now how many people, are, when such a new version would be released, going to change their stuffer plugin to allow the new version? And how long is it going to take for everyone to allow the new version?

Klaus_1250, that's not very logical.

First of all, you need to realize that because it would be optional and disabled by default, you can't use it untill you manually fill in the ID strings and turn it on. Most people simply won't use it.

The ID string includes a version number. So if the the filter allows for wildcards (*) and ranges, new bug free versions don't have to be blocked automatically.

For example:

blocking string range BitComet/001* - BitComet/0058 would allow BitComet 0.59 and later.

blocking string range BitComet/001* - BitComet/0060 would allow future (and hopefully non-cheating) BitComet versions.

blocking string Unknown* would only block the exotic and a few badly hacked clients.

You may wonder how efficient it will be then if most won't use it. Well, efficient enough for the people who use it as they won't waste bandwidth to cheating clients.

[typo edit]

I think it's a very useful feature (if the filter has wildcards and ranges like DrS mentioned)

Some users will always have a way to cheat. But against the not that tech-experienced leechers that don't know how to fake the userid it'll help a lot. And those users are the majority I assume. The easier it is to be able to cheat, the more people would use it (assuming they want to cheat).

And if people using the stuffer "forget" to allow new/better versions, they just hurt themselves when their download starts to slow down.

yes there is because azereus and bitcomet is the most common clients, so if you for example block bitcomet, you might have trouble to download on torrent with smaller swarms.

Or if you block bother azereus and bitcomet, you will only be able to download from mainline, ABC, µTorrent peers etc, which will defently make your speeds suffer, even on big swarms it will make your speeds suffer.

if all you care about is your download speed, dont use the stuffer.

if you care about cheating clients, use it

And you say users should be able to turn it on/off and its off by default,

then the feature loses its purpose.

i fail to see the logic in that.

I dont download that much, but I upload a lot. When I superseed, I dont want a peer downloading from me that cheats me in sending him pieces when he doesnt share them.

Using superseed with utorrent, I still have to upload 200% or more to get the file out, using az with the stuffer its ~130%, as it should be.

A stuffer option for superseeding only would be nice to start with.

Now BitComet feels the pressure, and they change some code, and put out a new version, 0.61 for instance, which does work according to the BitTorrent Specs and also correctly implements DHT.

now that would be nice wouldnt it ?

And you say users should be able to turn it on/off and its off by default' date='

then the feature loses its purpose.[/quote']

i fail to see the logic in that.

well, the feature is ultimately there to make people stop using bitcomet. Which it won't happen if just a few users are blocking it. People will most likely keep the feature turned off.

If that really the main and or only purpose, it will never get implemented.

boo, you're sadly mistaken. This feature is not intended to stop people from using BitComet. (Obviously, it would be a nice side effect if people would stop using leaching clients.) It is meant to efficiently prevent wasting bandwidth to leaching clients.

boo, you're sadly mistaken. This feature is not intended to stop people from using BitComet. (Obviously, it would be a nice side effect if people would stop using leaching clients.) It is meant to efficiently prevent wasting bandwidth to leaching clients.

no, I aint mistaken, because that would be the effect if everyone used, the ultimate result.

You are talking about the effect for the individual users (who for example tries not to get his/her upload raped by a bad client like bitcomet)

That makes no sense at all. If everyone would block cheating clients, the only who'd got hurt are the cheaters. How's that bad? You tell me.

I never said it was bad, I just said if not everyone uses it, it loses its ultimate result.

Which make this feature not so useful except if you have a slow upload speed.

.....because that would be the effect if everyone used, the ultimate result.

.....

a few posts up:

....People will most likely keep the feature turned off.....

If the purpose was to stop people using Bitcomet, it wouldnt be a feature you can turn of and on, it would have to be built in. Not only that, all clients would have to build it in.

The only purpose is to give UPLOADERS a tool to use their upload bw efficiently, 99% of the 'normal' users dont even know there is a problem with Bitcomet.

I bet that if Bitcomet users knew about the problem, some would change clients because they want to play fair.

edit:

Which make this feature not so useful except if you have a slow upload speed.

upload speed has nothing to do with this, its all about using it efficiently

if not everyone uses it, it loses its ultimate result.

huh? baffling logic

If A is true, than B is true

A If not everyone uses it,

then

B the full result, everyone using it, won't be achieved.

0 != 1, obviously

Which make this feature not so useful except if you have a slow upload speed.

What has a slow upload speed got to do with anything, it's about preventing waste, ie about efficiency.

Which make this feature not so useful except if you have a slow upload speed.

upload speed has nothing to do with this' date=' its all about using it efficiently[/quote']

to upload effectively means to upload as fast as possible without wasted data.

Anyway, I saw the screenshots Dsr posted that showed that the torrent used more upload speed than the total amount of speed that the peers downloaded from him.

The question is if the faster the upload is the more wasted date there is or

if its only a few kb/s no matter how fast the upload is,

if so then this feature is only fore those with slow upload speed.

if not everyone uses it' date=' it loses its ultimate result.[/quote']

huh? baffling logic

If A is true, than B is true

A If not everyone uses it,

then

B the full result, everyone using it, won't be achieved.

1 = 1, obviously

eh, wierd example. But by using your example (if I understand it correctly), I would say =

A = not everyone uses it/only a small amount of users uses it

B = full result, people stops using Bitcomet

If A is true, then B is false

If B is true, then A is false

Which means A != B