I have been conducting this “experiment” of sorts, where I look at all the peers that I am connected to. Up to now only about 2% of all Azureus peers ever download or upload.
I have tried both direct connection and connection through a router, and Azureus peers seem not to want to share even if they are seeds. All other clients share nicely, except Azureus.
Is there any reason to this?
i.e. I am currently downloading a file where there are 27 seeds and 3 non-seeds. Out of those seeds about 23 are using Azureus and none is sharing anything. The other clients are ok.
This pisses me off because I limited the number of connections due to use of router. And since most of the connections are filled with inactive peers, i can’t download and others can’t upload from me because they can’t connect.
Would there be a way to have selective peer connection depending on their client or a connected-time/inactive-time ratio (if peer connected for more than 1 hour and peer is inactive then kick)?
Something like an SQL query inside BitComet: “SELECT * FROM Clients WHERE Client NOT LIKE ‘%Azureus%’;”
It is possible the users are excluding your bit comet.
Many users and trackers exclude version .59 and .60 for issues it has with dht.
If you are using one of these, I strongly suggest you upgrade.
As for excluding azureus, this would not be a good idea, the answer is in educating the users that bit comet isn’t a bad peer. As long as people continue to use these versions, it makes this job harder.
Many Azureus users use the “Stuffer” plug-in and block BitComet. If you’re lucky you get people like me who only block old versions using regEx commands like these:
Bit(Lord| Spirit)
This one will block all versions of BitLord & BitSpirit.
BitComet\s0.[0-6][\d]
This one I wrote a few weeks ago. It will block versions from 0.69 and older.
If the tracker is blocking BitComet as well, it will give you a tracker error meesage with a comment about BitComet benig blocked.
This is also why people need to update with BitComet. No versions older than 0.63 should be used.
I am using the latest version of BitComet, with DHT disabled, on a public tracker that doesn’t block Bitcomet.
After I manually banned some of the Azureus seeds that were just wasting my slots, the download went very smoothly with nice download and upload speeds.
Why would excluding inactive peers/seeds make BitComet a bad client?
After all, if a peer/seed that you are connected to does not upload/download anything for a long period of time, then that peer/seed is just wasting slots that could be used by others.
In a way I understand what you guys are saying. If you make BitComet have too many “nice”/restrictive features, then it will attract leachers, which in turn will get BitComet to be banned by everyone else.