It the user not the client

[MICK]

When I look at the peer list in my utorrent client and see all the bitcommet users. I look to see if they are giving me data. If bitcommet is so bad why is it that I am receiving data from them .You know can just as easy cap the upload rate in utorrent It is my oppinion that it is the user not the client that makes a torrent go bad.

[idle.newbie]

did you ever notice the Reqs with "1 | 0" or "2 | 0", and waiting for a loooong time for nothing, 90+% from BitComet or BitSpirit peers. why?

and always got a K flag from BitSpirit peers when seeding. why?

user? how they did it?

[Ultima]

@MICK: I've received data at a constant 400KiB/s+ from a single BitComet user. But that doesn't mean BitComet's a fair client all of a sudden. The fact remains that it has bad tendencies. Lately, RnySmile has been improving his act... a bit... but it's still an unfair client, and from what I last remember, its slot control was busted, so you can thin the upload speed for each upload slot to less than 1KiB/s, and it wouldn't care. At that rate, what's the point of even uploading to the peer?

[MICK]

No I realy do not notice all the specific stats. It just I read that peaple are banning peers becouse of the client they use. That why I switch to utorrent. I use to use the very first client but for some reason it was getting ban at some web sites. No problem with utorrent, I love this client. It just I do not understand why anyone what to ban a peer becouse of the client they use. It seems that you can cheat just as easy with utorrent.

[Ultima]

Yeah, it's possible to cheat with ANY client, but at it's not built into µTorrent. Can't say the same for BitComet, really.

[TheBear]

@MICK

Maybe you should spend a bit of time watching the traffic in the swarm.

It's quite educational in how some clients act all on their own.

After a while, you can even learn to pick out the fake clients.

[Kazuaki Shimazaki]

Sometimes, BitComet can be very idiotic - it doesn't even do what is best for its user. Here's one of my typical victim experiences:

A bunch of BitCometers on a weak (Chinese) torrent. Between them, they have the whole file and more. But nobody shares. Nobody even grabs. Not at any appreciable rate anyway. So everyone's ETA shows something like 3 weeks and 2 days (2GB class torrent here).

The most extreme case is that for some reason, a single guy at 40% had that one piece that 5 other peers not counting me needed. Incidentally, all of us are at 99.9% and has all the pieces that 40% guy would need. All he needs to do is give us that ONE piece and we can all finish. Alternatively, the guy can pile on requests to any of us and let us fill him up to 99.9% before he forks over the last piece. Neither happens. Instead, nobody shares, so we were stuck for 36 hours before somehow the last piece transferred.

[Switeck]

Ultima said, "its slot control was busted, so you can thin the upload speed for each upload slot to less than 1KiB/s, and it wouldn't care."

Were it only a little less than 1 KB/sec that wouldn't be so bad. I've seen download speeds from BitComet clients of 0.05 KB/sec and less. This virtually guarentees a VERY high wasted/duplicate data if lots of people are doing it.

There seems to be some plugins or hacks (or "special" settings that few people know about) for BitComet that make it very evil. I've linked to a couple posts where ONE BitComet was able to download alot faster than everyone else -- and without uploading much to anyone in return.

[Ultima]

Well, yeah, that's what I was trying to get at... I guess I should've spelled it out more clearly to ward of any possible confusion

[Dark Shroud]

BC doesn't take plug-ins. There are hacked clients floating about. But it just comes down to adjusting the settings. And most of the time deleteding the tracker announce url. Which is why clients shouldn't allow the editing of trackers on .torrent files with the private flag.

[Game90]

you can block tracker connections using a 3rd party software anyway, so its not much of a use.

[Dark Shroud]

The average BitComet users can't even configure the client without help. So how would they use third party software like a firewall to block the tracker. Not that it would do any good if the .torrent was marked private when it was made. Because the other cheater trick with BC is pasting "DHT Network" into the tracker list, after deleteing the real one, because now BC will delete that and try to restore the real URL. I've deleted the url in µTorrent 1.6 and it worked. It's funny how something simple can be so evil.

[emtec666]

The average BitComet users can't even configure the client without help.

Same can be said for other clients like uTorrent.

And I agree on the topic starter, it's the user not the client

I get good/bad speeds from uTorrent users just as much as BitComet or any other client

For instance: 1 (BitComet) peer in the 213.113-114 range can outweigh 40 in the 24.xxx range

Sweden vs. (smalltown?) USA or 10 Mbit vs. 256 Kbits

(I have spent a little too much time watching peer lists hehe)

[z9999]

I would submit that there may be more to this than just the user or the client software. I spend an enormous amount of time watching torrents run, and I have not yet been able to to determine that any one client leeches more than another. I currently have 3 torrents running that BitComet clients are providing more data then uTorrent clients, and at other times this changes, and seeds/peers running uTorrent clients are not performing any better for me than any others. Occasionally I do notice a particular peer that seems to ask and receive data from me and my requests from the same peer are unfilled but it could be any client including uTorrent. It also appears that I get much better transfer rates from peers/seeds who are geographically closer to me. I wouldn't want the client software to eliminate my ability to connect with a peer running any other client without my permission. Some of my close friends run, and like, clients such as BitComet, BitLord, and others that may be considered leechers, but we usually are able to exchange with each other and the problems we encounter are not so much due to the client we are running as they are to the problems of having a reliable connection between us. The primary problems we have found to be in the BitTorrent protocol and I have yet to find the proper place to comment on it. Obviously it is not on any of the forums here. I continue to use uTorrent primarily as it consumes less system resources, but also use Azureus as it provides me some means of control which enables me to work around some of the problems encountered and gives me a little more useful information in order to do so. If any one client ever provides a solution to the problems I deem most important I will make that my primary client. Currently I remain with uTorrent primarily because of its size and and system load, and the fact that it performs no worse, nor no better than any other client I have used. I might add that I recently tried to seed a torrent for a couple of days that had 2 peers, both showing 99.9% complete and was unable after 2 days to complete either one of them. One peer was running uTorrent 1600 and the other Azureus 2.4.02, and me uTorrent 1600. So is this a client problem or just a connectivity problem. I might also add that I live in a third world country so this may have a large bearing on the problems I, and some of my friends encounter.

[Switeck]

Lots of ISPs, even ones not in 3rd world countries, throttle very low or block any uploads going to ips outside the ISP ip ranges or outside the country.

Anytime I see a client stuck at 99.9%...I think they're using a D-Link router in DMZ "gaming" mode which corrupts packets...so they never get a perfect copy of what's being sent. D-Link is very popular, so this alone makes the stuck at 99.9% problem quite common.

[z9999]

Switeck: Yes, I'm aware and familiar with throttling. Initially I purchased a what was a small business internet connection (512/128kbps), and found that during normal business day hours of I downloaded in excess of 100mB in a 1 hour period my maximum DL speed during the next hour was reduced to about modem speed, around 8kBps, and if during that period I maintained a high DL amount I was unable to send or receive for a period of 1 or more hours. Several complaints to my ISP had a repairman come and replace my equipment, but I noticed he also changed some IP addresses associated with my connection. I retained my fixed IP and when done I have been able to maintain a connection around the clock but no longer am cut off. I do notice that my speed is limited still at times and my ISP informs me that ALL users encounter some form of throttling at times of high traffic. Some months of observation have shown me that at times I appear to be throttled, it may only be to a certain geographic area and I can connect to another geographic area at near full speed. Additionally I have noticed that corrupted data increases whenever any throttling appears to be occurring, and this often affects all the data received, as pieces are not completed by individual peers but often a result of several peers contribution. In that both good and bad senders are noted for having contributed to a bad piece of data, often the good senders are banned prior to the bad sender, leaving only the bad senders and a very low DL to make things worse. I have seen all the peers and seeds who have sent over 50mB's of data banned quickly,leaving only those who have sent a mB or less. Moving a torrent to another client and having made note of the IP addresses that had been used I can sometimes manage to manually select the seeds/peers allowed to exist while running a torrent and successfully allow the torrent to run with little or no bad data (Hash fails) occurring, and then later un-ban all those previously banned and find that they are no longer involved in bad data. This is an intensive operation requiring constant attention to a process that should, in my not-so-humble opinion, require little or no observation.

As a last comment, I dislike personally feeling I am not giving back what I am receiving and having a 512/128kbps connection it is obvious that I can DL faster than I can UL. Essentially my DL is 4 times my UL which would appear that for every hour of DL I would require 4 hours of UL. That would be nice if it held true, but sometimes I run torrents with no peers and many seeds so I have to make up the difference elsewhere. Another problem is, and is currently occurring, with hash fails on a 3gB torrent I have accumulated over 800mB's of bad data and at present have acquired only 707mB of good data meaning I will have to UL over 2 times what I have received to maintain my ratio as no consideration is given by the tracker nor the client software as to the data being good or bad, just that it has been received.

I usually set my seeding to accomplish 101% and stop, and as I watch nearly constantly I immediately view a torrent to see the availability and if it is not greater than 1 I set the percent for that particular torrent to a greater number that should assure the creation of a new seed from the existing peers, or if only one peer I set the percent high enough to assure that peer can complete. It would be nice if I could set seeding to continue until achieving 101% and continue to seed if the availability was less than 2, 2.5, or some number that would assure me I wasn't leaving a torrent in a state that the remaining peers could no longer complete.

I'm am probably what I noticed in a response to another forum question related to giving uTorrent users the ability to have some control over the process, just one of the "Idiots" who doesn't understand. And although I don't understand some things about the process, it is not because I don't want to or haven't tried to, but more so because the facts are not always easy to find. Again, in my opinion, results is my primary objective, and ideally I always attempt to produce good results both for me and for the others working with me. Possibly I am the only user who experiences the problems I have encountered, so it may be a moot point to expect any changes which might alleviate them. I do, however, attempt to point out my findings and experiences in hopes that those who are in the process of improving the protocol might have thoughts on methods of generating code changes which might alleviate problems that I, and possibly a few others find devastating.

I could go into further details of some shortcomings that contribute to the problem, that appear to be common to all clients, but I feel they would be better placed in a forum related to the Bit Torrent protocol instead, should such a forum exist.

Thanks, and sorry for the wordiness.

[Switeck]

This is the chat forum, you can say it here and not worry about it being moved.

[z9999]

Switeck: Thank you. I will try and organize my thoughts and observations and create a new subject here. My intent, as always, is not to create an arguement but to gain new knowledge and info related to how bit torrent works and what if anything could be improved, in hopes that those who code the clients might take advantage of any useful ideas.