Anti leech settings

[sharayde]

At the moment the advanced setting bittorrent.anti_leech_min_byte (almb) can be set to a value between 1 and 10000. You set a time period with the advanced setting bittorrent.anti_leech_stable_sec (alss). For a task which is still downloading, if a peer does not download almb bytes within alss seconds, it will be disconnected.

The point I wish to make is that I don't think I have ever seen a smaller initial data download from a peer of less than 16k bytes. It looks to me as if this setting could either just be removed and see if the downloaded bytes is non-zero in the alloted time, or perhaps set it as the number of kilobytes downloaded.

I appreciate that this setting may relate to data transfer other than that shown in the task but it just seems to me that setting it to any value, with the current 10000 limit, will not make any difference to most tasks.

[kluelos]

I don't think it ever did.

[sharayde]

Where a torrent has a lot of peers it would be nice to be able to set this so that you can automatically disconnect peers that have a very slow upload speed. I might use it if I could say something like ' Disconnect all peers if they are connected for over an hour but have not given me more than 1Mb' or something similar.

[kluelos]

I believe that a human simply cannot manage network connections effectively, and should not try.

Connection X hasn't uploaded anything to you for quite a while. However, he's the fastest connection you have. He's just choked you right now, but when he does send, he sends blazingly fast. You won't know that, taking a static and momentary picture of your swarm right now. Blocking him would be a big mistake.

[greywizard]

if a peer does not download almb bytes within alss seconds, it will be disconnected.

Actually, it looks like you got the meaning of this option, backwards.

What it does is, it checks whether the peer sent towards you that minimum amount of data in the set period.

A leech is a peer who doesn't give, just takes (we're talking here about modified clients who won't upload or about clients who were capped to virtually null upload speed).

So, in order to prevent such a thing, if a connected peer didn't upload to you the minimum described by almb in the time specified by alss, then it's disconnected.

[sharayde]

Should have said 'if a peer does not download to me' to make it clear.

As far as manual management of peers goes, I just want to avoid having a peer connected for an hour and only giving me 16k of data when there are hundreds of other peers out there that aren't getting connected who might give me more.

And in any case, it isn't a question of blocking him, he just gets disconnected and has every chance of connecting again. It's not the same as banning an IP for a fixed period.

[kluelos]

You're connected to hundreds of peers most of the time, but you're actually transferring to/from a maximum of 8 of them at a given moment. Being connected to a slower peer doesn't hurt you. You're just "aware of his status", by being connected. You want to be connected to a lot, so you can try to pick the best of them and hope they pick you too.

[greywizard]

I kinda agree that it may be a good idea to increase the max limit for that option, so that one can tweak it further up and see what results they get. Perhaps, even the default value could be reconsidered, given the fact that the average speeds are a couple of orders of magnitude bigger than a few years ago.

But I'm not so sure about enforcing a lower limit bigger than now.

It's true, that apparently most clients trade blocks about 16KB in size, so, at a first glance, it would stand to reason that this should be the minimum size the client should check upon, in the alloted time.

But I'm not sure if this approach wouldn't miss some particular situations.

Take a case when your LAN and/or the network of your ISP is congested. As we well know the average MTU of the Internet is below 1500 bytes therefore a 16KB block will be divided in several IP packets. Let's say that your RWIN TCP value is 63712 bytes; this means that even more than one blocks would have to be received in order for TCP process to be able to fill the window. In times of congestion, not all of the packets may reach your PC, so your PC will have to wait to fill the TCP receive window before being able to acknowledge all the TCP segments in the window and send them in bulk to the upper application layer. Your client may not even have a single complete block received from that peer, but that may not be the remote peer's fault if network congestion downstream caused it.

So, as long as at least some data arrives, this is a pretty good sign that the peer is probably not a leech, and you CANNOT know for sure due to which reason you received a low amount of data.

OTOH I think you may mistake this option with the peer selection algorithm that BitComet uses to select and keep the best peers.

I can't speak for the team, as I don't exactly know how the guts of BC work but I think that the AL (anti-leech) algorithm and the peer selection algorithm are distinct or at least they are distinct parts of one more complex algorithm.

That is more or less verified by the fact that if there are many available peers BC will connect to several of them, keep the best of them and then by rotation try to connect to others, until it will have tried most or all of them and established which are the "best of the best" that will kinda match its speed and that will want to keep a steady connection with it.

You can check that by watching the Peers tab and expanding the bt_connecting and bt_disconnect categories. This is the "good peer selection algorithm", the part which deals with getting the best possible peers.

When, there are lots of good peers I don't even think that the AL algorithm gets to do that much active work, because most of the peers that are unchoking you, will send you data way above the thresholds of AL. Even then though, the AL algorithm may have to keep an eye on the peers gotten through optimistic unchoking, though.

But when there aren't lots of peers, or not many that have good upload speed or that have much of the torrent data, then you may be connected to several peers which will not send you much data (be it that they don't have any pieces you want, or that they have a small upload bandwidth spread too thin or whatever). For instance, one of those cases when the overall download speed you get for a torrent is constantly below 10-15KB/s, but it's steady and it doesn't stall.

I guess here it is where AL comes in place and tries to get the "best among the worst" or to put it more correctly to "keep the really bad ones out".

When there is nothing much to choose from, setting such high values (as you speak of) would only grind the torrent to a halt and hurt you.

If you check the Peers tab, occasionally you will see the peers with red icons ("bad peers") which are the ones who sent too much bad/corrupted data. Those are really banned for a certain period of time.

I don't know if those disconnected by AL algorithm also get banned for any period or just disconnected, but as you can see, there are several distinct layers in how BC treats peers, connects and disconnects from them.

Again, this is my take, I don't speak for the team but it sort of stands to logic. From empirical observation, BC always seems to manage to find the best peers in the swarm (that will want to "talk" to it, that is) and thus the AL algorithm doesn't seem to be the only thing which is employed in selecting peers. In fact AL is not employed at all in "selecting" peers it only "de-selects" the bad ones, but it's something else that "chooses" the best ones.

That is because, from the way it's constructed the AL algorithm seems to be establishing only the "lower acceptable limit", whereas BC would still need a different algorithm that will focus on getting the best peers possible, from the remaining existent pool, in order to explain its current behavior, because AL doesn't have any provisions for choosing good peers it only has means of eliminating the really bad ones.

Meaning, that while BC has AL which says: "this is the minimum and if you don't have it you don't get into the club" it also has another algorithm which says: "OK, let's see who are the best peers and let's constantly select and try to get them". The second one, runs the "better peers chase", so to speak, and is the second part of the equation, in my opinion. That is the real "meat" of the peer selection algorithm, as far as good speeds are concerned.

Thus setting a very high "lower" limit for the AL algorithm, would mean that you're trying to make the AL routine perform the job of the other one but I'm not sure that it would be a wise choice.