Stuffer

[emtec666]

emtec666, I wouldn't mind a kickban feature, also known as manual peer banning, either, but you have to admit that's easily abused (therefor not likely to be implemented). That's not at all the case with a stuffer. If you wouldn't need a stuffer, that's all fine, but keep the thread on topic please, this isn't a request for manual peer banning.

PS Firon, you didn't elaborate on your ambivalence yet...

Why is it easily abused?

If that would have been the case the developers of one of the "leading" clients in the BT world (Azureus of course) dropped that feature for sure.

G3/Rufus, Bitcomet and XBT if I'm not mistaken also have that option.

A Stuffer bans on client base, which is more "unfair" that a manual Kick & Ban option which only works on IP base (and even then only per session).

Anyway, it's my experience after uploading 100's of torrents on fairly limited bandwith a Kick & Ban IP option can be useful.

Now I'll leave you to your Stuff(er)

[DrS]

emtec666, manual peer banning can be very useful, but's also easily abused:

join a big (public) swarm, kickban all leechers and slow seeds, that's all there is to it.

Don't let the choices developers of other "leading" clients fool you. Most software developers don't only want a good product, they also want many customers/users. The latter can conflict with the former. BitComet is the number 1 leaching client, always has been. Its developers clearly prefer the latter to the former. If I recall correctly, Rufus is based on G3 and at least one has a build in client spoofer, thus it's a cheating client. Only going by the polularity of a feature isn't a sound measure of its quality.

Client ID based banning isn't "unfair" at all. Exactly because you won't be able to pick individuals to ban, it can't be abused, unlike the banning of indivual peers/IPs. All users of cheating clients cheat, whether they know it or not, they do. No point being discriminate towards cheaters, block 'em all.

If you won't discuss the actual feature request, I don't mind you leaving. You're free not to of course, but focus on the stuffer please.

[SledgeDG]

Well I have used stuffer on Az ever since it was available and it never hurt me

I still seeded 200 to 1000% (depending on several circumstances of course) so it never really hurt the swarm either.

After seeing how DrS nicely disected all the counter arguments...I just don't get why ppl are so reluctant to admit it, that the ability to ban bad clients is not a bad thing per se.

And if there is a swarm with all BC clients and I am strict with my actions...well...I guess that swarm is not for me then

Big deal...whom am I "hurting" there but me.

Is it just me or this whole thing here running in circles?

As a solution for myself I revert to Az if I happen to encounter a really bad swarm..I just rather wouldn't have to

-DG

[bleh]

Okey, to shut you up DrS, here I give you proof that users of ALL clients are cheating, and that it's not limited to bitcomet only:

http://www.00de.de/archive/peer-to-peer-f-200.html

Yes, there are threads in there that mention that azureus has plugins that enable you to cheat,

which means that you'd also want to ban every azureus user? (and if every client proves to be modable and thus suspeciptile to cheating, would you want to ban those aswell?)

This proves without the shadow of a doubt, that my "fatalistic" views aren't fatalistic at all, there has to be a better method implemented than just this simple one.

Also, to add some more meat onto my argument, here's a list of fake mods for clients:

http://www.00de.de/archive/public-leecher-mods-f-195.html

Pretty scary isn't it? all it took was one lil google.

[DrS]

Nice try, you failed though.

There's a big difference between using some plugin/addon/mod/hacked client and using an official build leach client like BitComet. The official builds of BitComet are programmed to cheat other peers. That qualifies a ban of all BitComets. The official builds of Azureus, Mainline, µTorrent and a few more aren't build to cheat. Why would I block those?

You already give up before the get-go, that's fatalistic.

[bleh]

Then I give up.

[Switeck]

How about instead of a blanket-ban of BitComet by µTorrent...

µTorrent engages in a little tit-for-tat?

What I mean is for the bandwidth priority (High, Normal, Low) TO BitComet clients to always be 1 setting lower than to everyone else.

If free upload bandwidth is available, always give them that bandwidth in full.

But if not, they get uploads from µTorrent at a reduced rate.

Better to feed leechers the leftovers (throttle them) than throw the leftovers away (ban them) -- otherwise the leechers will just use more evil tools which might be harder to fight.

My main concern is this might violate the BitTorrent protocol.

Still, if what I've read about BitComet deliberately misreporting upload and download amounts also applies to other clients in a torrent, then it means they likely get the "lion's share" of the bandwidth from seeders...who have no means of verifying that BitComet is in fact reporting correct values.

(Others have said that using super-seed as a seeder still often takes >200% of the torrent's size to create other seeds due to BitComet's cheating-by-default.)

Also, BitComet's disconnect-and-reconnect tactic to get more bandwidth via optimistic unchoke (meant for new arrivals to have something to share) than is fair. Sadly, Azereus is reported to do this too. As a longtime beta-tester of more than 1 file-sharing program, I remember the importance of maintaining connections and not automatically droping working connections...just on the assumption that better connections are out there. Such automatically-generated churn is BAD for trackers and peers alike.

I think the disconnect and reconnect strategy can only be fought using retention of information about disconnected peers in a torrent. (yep, bloat for µTorrent -- though it might fall nicely under the DHT part in coding.) This would IMO not be a violation of the BitTorrent protocol, although it might be if such information was taken cross-torrent for ips found on multiple torrents.

In hostile discussions on P2P networks, it was generally agreed that instead of banning hostiles it was better to maintain a connection with them and then...ignore them! ...By using as little bandwidth as possible and/or sending just enough to them to convince them that nothing's wrong. Otherwise the hostiles will hammer everyone till they meet their connection limits.

Sadly, this might not be a good thing for a hostile monitoring client. Better then to just block the connection in the first place. But that's what ip blocklists are for.

[DrS]

ok, so now there're 3 options to deal with cheaters/leachers on the client side.

# manual peer banning/IP banning

Useful, but easily abused, therefor not going to be implemented.

# a stuffer

Useful when superseeding, period.

When leeching, it will lower availability of potential resources. I'm not too worried about this possible negative effect on download speed: It's not much an issue on swarms with a decent amount of peers, lets say over 20. And I'm not in a rush anyway. If it adds a few hours to my download time, I don't mind. Obviously some people are in rush, therefor it should be optional. This is not in vioalation with the BitTorrent protocol; there already is a limit to the peers the client will connect to simultaniously.

# automatic lower bandwidth allocation for set client IDs.

This should be optional, configurable and off by default. You shouldn't force people to use it. I'm not too concerned about not following the BitTorrent protocol as this, like adding DHT, would be an improvement to it, under certain conditions.

@ Switeck, it's not a bad idea and worthy of being discussed, but I've seen way too many feature request get bogged down because of the introduction of other subjects, digressing from the actual request. So I suggest making a seperate request for it as it's just not the same as a stuffer. And just to be clear here, I mentioned BitComet as that is the most popular leach client, there are more like BitLord that I'd also block.

@ Firon, you still haven't elaborated on your ambivalence regarding a stuffer. i.e. What's your argumentation against the implementation of a stuffer(, other than the arguments used before as those were all proven invalid)? Or should your silence be explained as agreeing to the feature request? Either way, I'd like to know.

[Firon]

I just don't think it'll be that useful in most cases, and the fact that I consistently see the best seeders as bitcomet (in my Peers tab no less) almost makes me wonder as if there's some kind of legit BitComet build out there...

[DrS]

I'll start with BitComet. There are no legit BitComets out there. BitComet has been a leach client from the start. Of course if you for some reason don't want to block certain versions, that would be possible as the filter allows for wildcards and ranges, just like Azureus' stuffer. This argument wasn't used before, but it's just as invalid and not a reason to not implement a stuffer.

I'm ambivalent towards the inclusion of this option though.

ambivalence:

1. The coexistence of opposing attitudes or feelings, such as love and hate, toward a person, object, or idea.

2. Uncertainty or indecisiveness as to which course to follow.

I really have no idea why you would be ambivalent towards, i.e. have negative feelings for or have doubts about, this feature. You already agreed it would be a useful feature:

I generally think it's more useful when seeding (why upload to a leecher client after all).

that's exactly the same as

Having a stuffer would benefit uploaders the most as superseeding would be more efficient.

Why not implement a useful feature? Worried it would hurt your download speed, simply don't use it. Or even better, add an option to distinguish between (super)seeding and leeching. So you'd be able to only use it when seeding. Just add two checkboxes: "enable stuffer for seeding torrents" and "enable stuffer for downloading torrents" Would that do for you?

FYI If you say no, you contradict yourself.

[emtec666]

I'll start with BitComet. There are no legit BitComets out there. BitComet has been a leach client from the start.

FYI many uploaders with high speed lines (10 Mbit and up) use BitComet because it's the fastest client for those kinds of connections...also for uploading.

The good old cliche of "Guns don't kill peope, people do" applies to clients as well IMO.

Anyway to keep things on topic...I don't mind a Stuffer being added, if adding this option doesn't make the client "heavier" I see no reason why not to add it as an option. But I can also understand if the developers don't give it high priority.

[Firon]

I'm ambivalent because sometimes I like the stuffer, and sometimes I think it's better not to let users ban clients at all

I think this thread may have outlived its usefulness though, there don't seem to be any new ideas being presented and it's basically people bickering now. For now, I think I'll just start deleting posts.

Quit it Ic3d0g, just avoid this thread.

[DrS]

@ emtec666

Uploaders that use BitComet still use a client that is build to leach.

Killing with a gun (BitComet) is just much easier than with a knife (hacked client).

-back on topic-

Thank you, that's all I ask, judge the feature unbiased. If it's at least useful for some it's not trivial, and as it wouldn't make the client "heavier" it's not bloat (, just see previous posts to why not although I hope that won't be necessary). From there it's upto ludde to decide if or when this will be implemented.

-add.

@ Firon

OK, so sometimes you'd like to have a stuffer because it simply would be useful. But you also don't like people banning clients because that goes against the idea behind BitTorrent.

I can understand that. In a perfect world people would just seed back to 100%, no hit and runners, no cheaters, no leachers. Unfortunately that's just not the case. A stuffer is just a corrective device, necessary evil if you like. (The same reason private trackers exist, not to be exclusive, but just to force people to do what they should do.)

Everything that needed to be said has been said (many times over). A few hours ago I asked ludde to have a look at it and hopefully he finds some time to chime in. That's all I'm waiting for now...

/No need to keep at it with Ic3d0g, I already warned him about it.

FYI I was writing my reply and after submitting noticed your reply, that's why there's a reply to him.

[Firon]

I guess it's really up to ludde now, I'll pitch my support towards the addition of this feature.

[Switeck]

I think the stuffer may not be neccessary if my 2 ideas get implemented.

Those being:

1.User-optional de-priortize BitComet/BitLord/BitSpirit clients by 1 notch (from normal to low, typically)...under advanced settings of course. This would reduce your upload bandwidth to them, everything else held equal, to about 40-80% of what it was before. But if there's no one else but BitComet users, they'd get 100% of your upload bandwidth. By uploading first to BitTorrent clients that share more readily, even BitComet users could benefit from this -- as it would take more "hit-and-run" BitComet users to leave a torrent without seeds or a virtual copy across all the remaining peers. (which quite likely could be OTHER BitComet users!)

2.Manditory fix of the reconnecting peers handling. This bug was how they were achieving alot of their extra download speeds. µTorrent (and numerous other BitTorrent clients) was incorrectly treating these reconnecting peers as "newly connected peers" that deserved "a decent chance of getting a complete piece to upload". It was giving them a free upload slot over 3 times as often as everyone else combined when it did that. They should've been choked and snubbed (ie: ignored!) instead -- until they uploaded to you!

Both options are within the BitTorrent protocol spec's purpose and letter. (The second is following the spec exactly, the first is simply a download/upload 'end game' strategy just like 'super-seeding' is.)

[kurahashi]

I'm not sure about your client de-prioritize idea, but this reconnecting peers fix concept looks really great. I mean, I really can't see any cons for it. Please our dear author and maintainer, do consider it

[Switeck]

emtec666, I wouldn't mind a kickban feature, also known as manual peer banning, either, but you have to admit that's easily abused (therefor not likely to be implemented).

[...]

Client ID based banning isn't "unfair" at all. Exactly because you won't be able to pick individuals to ban, it can't be abused, unlike the banning of indivual peers/IPs.

Actually, manual peer banning is already possible using µTorrent. Add the ip to the ipfilter.dat text file, save it, and disable+reenable ipfilter option in advanced settings. You don't even have to restart µTorrent for the ip to get banned. However, it's not an impulse 'right click, ban' option.

[splintax]

yes, we know that, but it's too much of a hassle to be worthwhile for most

FYI many uploaders with high speed lines (10 Mbit and up) use BitComet because it's the fastest client for those kinds of connections...also for uploading.

i didn't know that - don't most fast uploaders use "seeding boxes" with torrentflux or something on them?

[Switeck]

yes, we know that, but it's too much of a hassle to be worthwhile for most

So the real question is not whether we want manual ip banning in µTorrent (as it already is...of sorts).

...But whether the average idiot can ban someone quickly and easily, because that's who will be using it the most.

[hofshi]

Rofl

[silverfire]

FYI many uploaders with high speed lines (10 Mbit and up) use BitComet because it's the fastest client for those kinds of connections...also for uploading.

That's not completely true. I know a lot of seeders on fast lines that use µTorrent. In fact, I converted someone who used to use BitComet for seeding to µTorrent yesterday.

[hdfreedom]

I'm new to this Forum, although I've been using uTorrent for a few months. I've been very aware of the problems that the BitComet client causes with swarms, and also it's cheating ways, and have perused many forum posts on this topic.

I'm a 53yo country raised man, and when I'm indecisive about what to do about a problem, I generally try to go back to my roots, and use common sense to decide.

I've read through this post, and the others related, thoroughly, and the one thing that seems to pop up in my mind, over and over again, is:

"Don't go to a gun fight with only a knife"

In other words, if the world was perfect, and we didn't have to deal with those that constantly try and find the short way, slick way, or cheating way to the end result, then we wouldn't be talking about whether or not a "Stuffer Plugin" would be needed or not. That's not the case here though. BitComet has gone over the line, and, I for one, would like to have the tools to combat them.

I like the uTorrent client because of it's small size, low resources use, and simplicity in design. I also respect the views of the author for not wanting to get into the "mud" with BitComet, but that really doesn't seem to be a reasonable stance to me at this point.

If you're standing in front of another person that has his finger on the button on a remote, that will set off a bomb, you don't offer him coffee. Maybe a bit overstated, but it conveys my point clearly.

I'd love to stay using the uTorrent client, but at this point, it just isn't feasible for me to give up being able to protect myself from cheaters, so I'll be going back to Azureus, that bloated client, that does give me those tools to protect myself. This is the biggest topic of discussion that I've read about in other forums about uTorrent; it's lack of being able to deal with the BitComet client. It's also the biggest reason that I see for users not wanting to change over to it.

I would sincerely hope that the author of uTorrent can see some sense in what I've tried to convey here. I can understand the moral dellima that has to be faced, but I, for one, don't see any other viable alternative, given the problem at this point in time.

Thanks for listening....

[Firon]

Here's something that was added to deal with BitComet (not perfect yet though) to an extent.

- Fix: Better detection if BitComet clients threw away my requests.

[1c3d0g]

I can certainly understand your frustrations hdfreedom, believe me, I also am having problems with a few BitVomit leechers...however it's wise for Ludde to stay out of this mess and concentrate on making a great client, and let the rest of us battle it out with the leechers. Once a developer takes a stance, there's no going back, and it can get ugly if BitVomit's developer(s) suddenly decides to play nice again - for whatever reason(s) that may be. :|

[hdfreedom]

That's fine and dandy, but in my opnion, uTorrent needs a full fledged plugin like the Stuffer for Azureus, to deal with this problem.

I've got 5 torrents going from various BT sites right now, and most of the connections to me are BitComet. They're getting their UL from me, and maxing it out, but only trickling an UL to me. I tried pretty much everything that has been suggested in these forums to fix the problem, but without a tool to do so, It's unfixable at this point in time.

My torrents start out with many different clinents connecting to me, but after awhile, it ends up just about only BitComet, Bitlord, and FakeBitComet clients connected, and there's nothing I can do about it, barring going through each torrent and banning each and every IP Address. Not gonna happen, just not feasible.

Like I said above, I understand the moral delima, and I too, after 53 years of living, would like to see things "perfect", but that's not gonna happen here. The authors of BitComet have a mindset that cheating is the only way to do things, and for every fix others do, they strive to find a way around. Staying infront of them is the only way to deal with them.

Done ranting. Thanks for the reply.