[slyck article]BitComet Banned From Growing Number of Private Trackers

[chaosblade]

Well, At least it seems to be SOME sort of response from RnySmile (Or is it?).

[sixshot]

I take it you didn't read my thread? The means by which I suggest to 'ignore' BitComet would in fact do nothing most of the time, at worst BitComet gets a lower priority than clients that follow the BitTorrent protocol more closely. But in the LONG run, it makes BitComet harder to use as a "hit-and-run" BT client and helps ensure that torrents stay seeded longer.

Because the 'ignoring' is done by behavior instead of client version, BitComet could be fixed and not get 'ignored'...without any changes need to be made in µTorrent. Plus, any other clients or hacks that tried to do the same would also get 'ignored'.

When the word 'ignore' is used, the first thing that comes to mind is the act of not acknowledging BC clients at all, rather than throttling BC clients which would have been the better term to use instead. It's a misinterpretation.

I did eventually read the thread though... still would be ideal but in essence bad. Do note that P2P and BitTorrent is a muchly "unregulated" network. Leechers will be around. And that's something you cannot avoid. Trying to fix a problem caused by a problematic client is only creating more headaches in the long run. At this point in time, coding in such a throttling feature would mean additional checks and that can increase the exe size and possibly memory usage. I'm fine right now using it "as is"... and as it stands now, we're letting the Priv.Tracker Admins handle the filtering work. Public tracker is about as 'free-for-all' as it can get. Might as well let it be that way for those who are leechers.

I have to disagree with you there. When one client consistently outperforms another, I would suggest that you try and fix the problem first of all if you really like that client (ie. µT), but if there is a legitimate problem with the client, I would definitely go for another one.

However, most people that complain about speeds and just go to another torrent client are not putting in the effort to fix the problem. Having said that, µT's default settings need a little work, IMO, since a lot of people seem to be having problems - maybe my suggestion here would be helpful.

But I find it baffling that hardly any one of these people who complain about speeds would bother to fix it or make any attempt to tweak the settings to their liking. The numerous complaints I have reviewed over at the FileList forums seem to indicate that they only gave uTorrent or any other client a "10 minute shot" at impressing them. I have seen numerous posts proclaiming that 'uTorrent sucks' and the like... yet I don't even know if they either A) haven't used it extensively enough or have used it long enough to come to that conclusion. And as most unfortunate as it may seem, the impression I get from reading their replies and their angry posts has me leaning towards 'A'. I may not have uTorrent optimized to be absolutely blazing to maximize every bit provided by my ISP, but I sure am not going to complain if I get 150Kbytes/s compared to 400Kbytes/s. Main thing I convey is... "What's the rush?"

Well, At least it seems to be SOME sort of response from RnySmile (Or is it?).

*cue R.E.M.'s "It's the end of the world as we know it"* As if that guy/they ever make any response.

[Switeck]

I take it you didn't read my thread? The means by which I suggest to 'ignore' BitComet would in fact do nothing most of the time' date=' at worst BitComet gets a lower priority than clients that follow the BitTorrent protocol more closely. But in the LONG run, it makes BitComet harder to use as a "hit-and-run" BT client and helps ensure that torrents stay seeded longer.[/quote']

When the word 'ignore' is used, the first thing that comes to mind is the act of not acknowledging BC clients at all, rather than throttling BC clients which would have been the better term to use instead. It's a misinterpretation.

I did eventually read the thread though... still would be ideal but in essence bad. Do note that P2P and BitTorrent is a muchly "unregulated" network. Leechers will be around. And that's something you cannot avoid. Trying to fix a problem caused by a problematic client is only creating more headaches in the long run. At this point in time, coding in such a throttling feature would mean additional checks and that can increase the exe size and possibly memory usage. I'm fine right now using it "as is"... and as it stands now, we're letting the Priv.Tracker Admins handle the filtering work. Public tracker is about as 'free-for-all' as it can get. Might as well let it be that way for those who are leechers.

I couldn't think of a good title at the time. But ignore is slightly different in meaning than ban. Some things just don't translate well. I was just looking for a good sound-bite at that moment.

True, the throttling might be extra, unneccessary, and unwieldy code to add to µTorrent. BTW, special throttling can already be done in another case -- there's a check box under seeding priority that reads:

"Seeding tasks have a higher priority than downloading tasks"

Also, uploading at (slightly?) reduced speeds to BitComet clients would also mean they'd likely upload LESS back to you, as per the BitTorrent protocol specs on 'tit-for-tat'. But if your upload bandwidth was sent to other clients (if available), the chances of getting faster downloads from them would be considerably more...all other things considered equal.

Still, dealing with the disconnect/reconnect issues is neccessary. Even having to delete and create entries for hostile clients (that deliberately disconnect and reconnect) is a lot of churn that could cause the connection database to balloon in memory useage or risk data overwrites or buffer overruns.

[splintax]

EVEN with contention, a low-priority still gets bandwidth...just not 90+% of it like BitComet often does!

Yep, so you're still allocating BC less bandwidth and implementing an extension to the BT protocol that is unfair in my eyes. Two wrongs don't make a right.

A funny note to this, is that people who comments to this news on slyck says its Bram Cohen's fault why BitComet's DHT doesn't work properly

Hah, what? Where do people get these ideas? :S

The rollback of BitComet does nothing for the millions? of copies of .60 that are already out there.

I presume something is being done about this - are they being automatically downgraded?

When the word 'ignore' is used, the first thing that comes to mind is the act of not acknowledging BC clients at all, rather than throttling BC clients which would have been the better term to use instead.

Exactly. "Throttle" is definitely a better word.

I couldn't think of a good title at the time. But ignore is slightly different in meaning than ban. Some things just don't translate well. I was just looking for a good sound-bite at that moment.

Ban is an even worse word. Ignore = banned for the session. Banned = banned permanently. At least that's the way I see it.

I may not have uTorrent optimized to be absolutely blazing to maximize every bit provided by my ISP, but I sure am not going to complain if I get 150Kbytes/s compared to 400Kbytes/s. Main thing I convey is... "What's the rush?"

I think that you are in the minority if you don't mind getting less than half of what you could be getting speed-wise. People pay money to get faster connections. Personally I'm happy with 150KB/s as opposed to 400KB/s, but why suffer with the slower speeds when you can get faster speeds just by installing another client?

[sixshot]

I may not have uTorrent optimized to be absolutely blazing to maximize every bit provided by my ISP, but I sure am not going to complain if I get 150Kbytes/s compared to 400Kbytes/s. Main thing I convey is... "What's the rush?"

I think that you are in the minority if you don't mind getting less than half of what you could be getting speed-wise. People pay money to get faster connections. Personally I'm happy with 150KB/s as opposed to 400KB/s, but why suffer with the slower speeds when you can get faster speeds just by installing another client?

Because installing another client is trying to avoid a problem. To me, speed is Priority 3 whereas Stability and Usability is Priority 1 and 2 respectively. I have no problem with speeds so I don't bother much with it. If they wish to exploit their "phat pipe", that'll be up to them. But many ought to work with the program and optimize it somewhat so that they can get to know it... not simply try it and throw it away in a 5 minute period. All softwares have certain little things that bugs us. And I simply just work with it and try to adapt.

[BlackLion]

Because installing another client is trying to avoid a problem. To me, speed is Priority 3 whereas Stability and Usability is Priority 1 and 2 respectively. I have no problem with speeds so I don't bother much with it. If they wish to exploit their "phat pipe", that'll be up to them. But many ought to work with the program and optimize it somewhat so that they can get to know it... not simply try it and throw it away in a 5 minute period. All softwares have certain little things that bugs us. And I simply just work with it and try to adapt.

Thank you for posting this. You are a man(?) after my own heart in this matter. All softwares are quirky, we just adjust to them or throw them away.