UL limit at 0 kB/s stalls all transfers completely

[dawod]

I’ve noticed that (unlike in all previous versions) in 1.40b1 Transmission doesn’t connect to any peers or trackers when the maximum upload is set to zero.

This is quite annoying when downloading torrents from a private tracker without wanting to seed. (e.g. when using an external seedbox to keep the ratio up).

This lengthy braindump is a safeguard against a period six months from now when some other freakish special case pops up. :)

Closing this ticket for now, but as I say, the code is experimental. If problems persist, feel free to reopen this ticket.

[charles]

I don't see any way to reconcile this with ticket #617 and am leaning towards closing this as wontfix'. A large number of people have requested that Transmission never go above its bandwidth limits, and acquiescing to #1429 would by definition cause that to happen. In Vuze and uTorrent, setting the value to 0' means "unlimited" rather than "zero".

Something needs to change before 1.40 goes final, because setting upload or download to zero in 1.40b1 yields pretty unhelpful behavior. We should either

1. back out all the new speed limiting code
2. allow protocol messages, but not piece data, to go through when limits are in place
3. make `1' the lowest setting for the up/down limits
4. make it user-configurable whether speed limits work by piece data or raw data

My feelings on these choices:

1. is a step backward wrt #617. there are clearly a lot of people who want Transmission to respect the speed limits they set.
2. sort of works if we've set the upload speed to zero, but not if we've set download speed to zero -- if piece data is the next in the incoming message pipeline, there's no way to skip past it to the incoming protocol messages.
3. this isn't likely to make anybody happy, but is probably the best choice if you take into consideration (a) consistency and (b) Transmission being a "good citizen"
4. really doesn't solve anything; it just forces the users -- who probably don't know or care about piece data vs raw data -- to have to make the choice for us. It also adds more code to an already-complicated subject.

For those reasons, my vote is option 3, but I'd like to second and third opinions on this.

[livings124]

I think 2 might be a good idea, and would most match how people expect the app to behave.

[charles]

in r7064 I've added -- experimentally -- a modified version of 2:

In the special case of upload set to 0, libT will pretend the torrent's upload rate to unlimited, but choke all the peers and stop responding to piece requests.

In the special case of download set to 0, libT will pretend the torrent's download rate is unlimited, but tell peers that it's not interested in their pieces, and stop requesting any.

In both special cases, there will be a short inital period where any pending requests work their way through the pipeline. But IMO this is just a minor, transient problem.

This handling of the '0' case is actually better than in 1.34 and earlier, since those versions didn't bother changing the "interested" and "choked" states.