Stuffer

[DrS]

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 only purpose of those 2 screenshots was to show the client IDs of 2 clients I'd block with the stuffer.

Right before the shots "Some client I'd like to block with a stuffer:"

screenshot1 - subscript "BitComet 0.56, a broken client"

screenshot2 - subscript "A hacked client"

I didn't mention speed anywhere, so how you got the impression the speed of those random torrents has anything to do with it is a mystery to me.

FYI I edited it to 0 != 1 (false is not true), apperently while you were writing, doesn't change much though

[redbert]

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

thats the only remark from you sofar that is correct

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 only thing it shows is a broken client and a hacked client that we want to block

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.

even after reading it 10 times I dont understand what your trying to say.

the only difference between slow and fast uploading is the time it takes to upload a file, in the end, the amount of wasted megs, or gigs in my case, is the same.

and with that

/me ignores boo from now on

[boo]

Anyway' date=' 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.[/quote']

The only purpose of those 2 screenshots was to show the client IDs of 2 clients I'd block with the stuffer.

I guess I read it to quickly, I read this from your post and then skipped the line saying that you want to block those to clients =

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.

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

thats the only remark from you sofar that is correct

no' date=' if you think about what I said, I aint wrong with th rest either

Anyway' date=' 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.[/quote']

????

the only thing it shows is a broken client and a hacked client that we want to block

ya, I know, read my comment on under the quote of DrS post.

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' date='

if so then this feature is only fore those with slow upload speed.[/quote']

even after reading it 10 times I dont understand what your trying to say.

the only difference between slow and fast uploading is the time it takes to upload a file, in the end, the amount of wasted megs, or gigs in my case, is the same.

and with that

/me ignores boo from now on

*sigh*, you misunderstood what I said, but it doesn't matter now (read the comment under the quote of DrS post).

You're going to ingore me because you couldn't understand what I tried to say +

I made one mistake in one post, ok...

[chaosblade]

Righty ho, Take this post lightly.

Im really, really in terms with you about BitComet playing dirty, about hacked and faulty clients being used around.

I am, however, totally, completely, utterly against any form of client-side bans, aside from hash-fail bans. I dont think every client on the swarm playing around with it banning whoever it deems helpful or not. Also, its stupidishly easy to fake the client ID and user agent for some clients, especially those with source-code available, making this completely useless to begin with.

[Firon]

oh my god quote hell WAY TOO MANY QUOTES IN THIS THREAD

[1c3d0g]

/me hopes Silverfire won't see this thread...

[Firon]

I'd trim them down but I can't be arsed, silverfire's likely to just lock it

[redbert]

@ firon , you're right, it makes reading a bit difficult, but i'd like to know what the devs think before locking it.

@1c3d0g , if thats all you have to contribute , dont post.

@chaosblade , thats like saying I know that stealing is wrong, but since so many do it, fighting it is useless.

1. Not every client in the swarm will use the stuffer, until now, only az has this, and only a few (uploaders mostly) use it. I used it with az while superseeding and I had no problems maxing out my ul speed. What clients do with the pieces after i sent them, I dont care. I just dont want to send pieces to clients that cheat.

2. How many do know how to fake a client id or use a hacked client ? And what is the chance they join a swarm you are superseeding ?

Most of the bitcomet users (and all other broken clients) dont have a clue about cheating, they dont want to, but the client makes them.

Oh, before you ask how I know that, I'm admin on a big site (if 500k users is big)

@Firon, look, without quotes

[chaosblade]

Rather "I know stealing is bad, But the 10,000 bullies out there will keep doing it no matter what"

[Klaus_1250]

@chaosblade , thats like saying I know that stealing is wrong, but since so many do it, fighting it is useless.

People don't steal without a reason. In general, people tend to do or try The Right Thing. If so many people are stealing, that usually points that something is wrong within a system.

[bleh]

If I could, I'd use the three strikes system that the US has regarding crimes:

First bad ratio> record IP

Second bad ratio> mark ip as "suspect"

Third bad ratio: KICKBAN FOR LIFE

But, that doesn't really help me, since there's a shitload of client spoofing going on, not to mention that there's too many users with dynamic ips to keep track of.

So really, all we can do is leave it up to the tracker owners to sort this out, after all.. security begins with the uploader...

[DrS]

Cheaters are not bound by the rules -the BitTorrent Protocol Specification- they break. That's why saying the protocol takes care of them simply is not true.

There is no third party software to block peers by client. If you still didn't get it, we're not talking about banning IPs here.

@ Klaus_1250, "In general, people tend to do or try The Right Thing". jeez, that's just so naive. Without rules people will do what's in their best interest without much concern for others, especially when set in a highly anonymous environment like the internet, or even more specificly, a bittorrent swarm. (That's economics 101; externalities)

@ chaosblade, "the 10,000 bullies out there will keep doing it no matter what" ie "there are so many cheaters, one person with a stuffer won't help much, so I'm against it being implemented". Just because you lack the motivation to do something about cheaters, others shouldn't be given the opportunity? Aside from being mistaken about the effectiveness of a stuffer, that's so egocentric. Who are you to make that decision for others?

@ bleh, why depend on others, why not do something yourself to solve the problem? When do you expect public trackers to block cheating clients? Saying it's up to the tracker admins is ridiculous. The main reason for private trackers to ban certain clients (those that don't honor private flags) is to keep their community private, ie a security issue. Banning clients for not reporting stats properly or cheating other peers is a secondary objective.

Most people use public trackers. Public trackers are unlikely to ever block a client as they inherently don't care about leachers, cheaters, or ratios to begin with, so cheaters can do as they please. The only way to deal with them there is to do it yourself, with your client, with a stuffer.

Even if you wouldn't use it, you'd benefit from others blocking cheaters, resource drains, with a stuffer as that would increase the swarm's efficiency, and thus your download speed.

I'd like a word from ludde or vurlix on this. Unlike manual peer banning, which can easily be used to cheat and be harmfull to the swarm, banning peers en masse by client ID cannot be used to cheat. Not distinguising between the two (déjà vu) is a mistake, a shortcoming.

[Firon]

http://forum.utorrent.com/viewtopic.php?pid=3938#p3938

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.

granted, vurlix is no longer part of µTorrent.

I wish every tracker would ban BitComet though (private ones are in the process of doing so). Unfortunately on public ones it won't happen, so a client ban would probably cause you more trouble than it's worth, at least as a leecher (seeders are another matter).

[DrS]

BitComet getting banned at some* private sites only effects their users. Some sites only ban version 0.59/0.60 which only solves the private flag issue, not the real problem, its cheating nature. The vast majority of bittorrent users will not notice any chance at all.

Having a stuffer would benefit uploaders the most as superseeding would be more efficient. But a stuffer would also be usefull if you're only leeching. Whether your download speed improves is something else. It likely won't change much, if any, but it could either go up or down. However, the more people would use a stuffer to block resource drains like BitComet, the higher the chance your download speed improves. Needless to say, whatever private trackers do, a stuffer is usefull and should thus be implemented (,optional, disabled by default, with wildcards and ranges in the filter).

* Scene Torrents, Midnight Torrents, TorrenIt, BitMeTV, Oink, Wild-Bytes, PhoenixTorrents, to name a few.

PS Is vurlix just not working on the OS X port anymore, as stated in the FAQ, or is he off the project all thogether?

[bleh]

Well, my point was: what prevents a bitcomet user from spoofing his client ID today? if you wanna cheat, you're gonna cheat real good right? (ie, having a hacked bitcomet spoofer client)

So, you can't really detect a spoofing peer today, thus the real big cheaters are still going to slip past the security of your stuffer program.

[idle.newbie]

saw many sites with packages BC hacked+ad removed+limit removed version+BT Enging bundle, and many aricles "how to download 800+KBs" got the best click rate in P.R.China, they DON'T care ratios or trojs or warez or ANYTHING.

99.9% of clients are BitComet/Fake BitComet/hacked BitComet here for most of the time. 50+% of peers' IP unresolve, 50+% of peers connect you with 1+ connections.

[Firon]

Vurlix is off the project altogether, he's making his own client now.

I say that it's not as useful when leeching because BitComet peers may unfortunately make up most of the swarm, or even be the only seeders (it happens a lot)

[DrS]

@ bleh, I got your point alright, it's pretty fatalistic, like saying "I'm not locking my front door/car, someone who wants to break in, will get in anyway." Spoofing your client ID isn't hard, but you have to take initiative to do so. Most BitComet (official builds) users won't notice they got blocked untill many people block them, so no incentive to spoof. If you don't think a stuffer will work, don't use it, I think it will work, definitely when being the initial seeder, so I will use it.

@ idle.newbie, "99.9% of clients are BitComet/Fake BitComet/hacked BitComet here for most of the time". That's not at all the case with the swarms I'm in, time for you to look for better sources.

@ Firon, so vurlix is out, it would be nice to get a word from ludde on this then. Using a stuffer won't always be as effective, it depends on the situation. Whether you'll use the stuffer is up to the you. As for BitComets making up for most of the swarm, see my comment to bleh. Additionally, when I upload I'd also block BitComet when they make up 90% of the swarm. Though for them, good for the remaining peers in the swarm.

[Firon]

Like I said before, I generally think it's more useful when seeding (why upload to a leecher client after all). Oh, and detecting BitComet/BitSpirit spoofs, so far, is quite easy. (µT does, "Fake BitComet")

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

[DrS]

What causes this ambivalence?

[smellyhippy]

DrS You seem to be using the "I'm not locking my front door/car, someone who wants to break in, will get in anyway.", style argument alot. Thats a pretty bad simile and doesn't really describe what would happen very well.

It makes the assumption that no bad will come of this, it portray's your solution as a simple and one sided one, ludde impliments this and things will get better.

What about the bad side effects?

Banning by Client ID wont work so you'd have to create some sort of detection mechanisim, this is time intenisve and may not work for long, so you get a little result for a lot of effort and false positives could be an issue.

As others have said what about when the BitComet clients are the only ones seeding? Just because some people use a client in a bad way doesn't mean everyone does. Just because you would rather shoot yourself in the foot doesn't mean we all would.

I agree that if everyone suddenly banned BitComet then the users would have to move, but if µTorrent acts alone then it's more likely µTorrent will die rather than BitComet.

This feature isn't the answer and IMHO shouldn't be implimented.

[DrS]

Yeah, I know, many quotes, they serve my argument though. It's like dissecting a corpse, messy but someone gotta do it and you need to be precise.

smellyhippy, in case you misread me, that wasn't my argument. It's my translation of one of the (two) arguments used by opposers to this feature. Klaus_1250, chaosblade, bleh, all recycle the same argument -paraphrased- "a stuffer won't be very effective as many cheaters would simply spoof their client ID". Not using a preventive feature just because people will try to bypass it is so fatalistic. Why not get rid of jails as well, as many inmates would just try to bust out? (A bad analogy maybe, poor style even, as long as it gets the point across I'm fine with it.)

It makes the assumption that no bad will come of this, it portray's your solution as a simple and one sided one, ludde impliments this and things will get better.

That's right, it's misleadingly simple (for the easily mislead). It will work (see my previous posts) and therefor should be implemented. Untill someone, that includes you, shows me all the bads things it would cause, I stand by that.

What about the bad side effects?

I was just saying.. just scary

Banning by Client ID wont work so you'd have to create some sort of detection mechanisim, this is time intenisve and may not work for long, so you get a little result for a lot of effort and false positives could be an issue.

"Banning by Client ID wont work so ..." Excuse me, that's it, no explaination to why it would fail? Come on, if that's all you can do.. (In case you meant because instead of so I apologize, my engrish aint that good.)

"you'd have to create some sort of detection mechanisim" for what, client IDs? µTorrent already identifies client IDs, including hacked ones, that won't be something new.

"this is time intenisve and may not work for long, so you get a little result for a lot of effort" ? Yeah, adding a few strings to a filter and ticking a "enable stuffer" box is a LOT of work.. If you're that lazy, why even post in this thread?

"and false positives could be an issue." If you lack the mental capacity to properly add a few strings to a filter, just don't bother. If you mean ludde might produce a bug-ridden feature, you've got less fate in him than I do.

As others have said what about when the BitComet clients are the only ones seeding? Just because some people use a client in a bad way doesn't mean everyone does.

All BitComet users cheat, period. It doesn't matter if they don't actively cheat or even don't know they cheat, they all passively cheat as BitComet is programmed to cheat. If they'd notice decreasing download speeds because people would block them with a stuffer, though luck, shouldn't use a cheating client then.

Just because you would rather shoot yourself in the foot doesn't mean we all would.

Hey, I'm not forcing you to use it. If you're that worried about your download speed, don't use it then. It's optional, remember? Tough luck if you don't like that argument, if you want a client without any optional features you won't use, use Mainline.

I agree that if everyone suddenly banned BitComet then the users would have to move

Well, like Firon you also agree that banning clients like BitComet is a good thing, exactly the thing you could easily do with a stuffer.

, but if µTorrent acts alone then it's more likely µTorrent will die rather than BitComet.

Yeah, Azureus really took a hit when a stuffer became available... What an ignorant thing to say, you don't even know what you're talking about. If you did, you'd know Azureus already has a stuffer. Seems like you didn't bother to read the actual feature request as I mentioned Azureus' stuffer in the opening comment of this thread.

This feature isn't the answer and IMHO shouldn't be implimented.

Untill you come with a better way to deal with cheaters on public sites, a stuffer would be most effective and should thus be implemented.

You didn't supply a single reason for not implementing it. Simply saying "it's bad" is just a hollow phrase. I don't mind you not using it and don't mind you not wanting it being implemented either, but please, use some good arguments.

[emtec666]

Well, speaking as an uploader, I don't really need an equivalent like Azureus' Stuffer (I have used it in the past)

Give me kick & ban IP option also because some ISP's like mine prioritize traffic within their own network meaning when I'm uploading a single leecher -within my ISP's network- sometimes can drain up to 80% of UL bandwidth, not very efficient. Resorting to super-seeding is not really an option because on medium (1 Mbit) to fast (10 Mbit and up) connections this is inefficient (drop backs in speed to 20-50%).

So I usually don't kick & ban IP's: I just open up more upload slots to spread he pieces more. But for the situation mentioned above it would be very handy.

Anyway it's already a good client, IMO a Kick & Ban IP function + Azureus DHT compatibility will make it the best around

[foxyshadis]

emtec, if you have a high-end router (or a reflashed linksys one) you can also do your own QOS so that people on your ISP's network are de-prioritized.

[DrS]

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...