Opened 13 years ago

Last modified 11 years ago

#3363 assigned Enhancement

MAX_CONNECTIONS_PER_SECOND should be replaced with a non-constant

Reported by: charles Owned by: charles
Priority: Normal Milestone: Sometime
Component: libtransmission Version: 2.00
Severity: Normal Keywords:


There is no one-size-fits-all best value for this constant. Vuze uses a sliding scale based on how many peers are missing to meet its max connections goal. libtransmission should do something similar.

Attachments (1)

3363_transmission.patch (10.5 KB) - added by phreek 11 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 13 years ago by User294

It may be desirable to make this option configurable by user. Reasons are:

  • In some crappy OSes like Windows there is half-open connection limit exists. This imposes certain limits on connections per seconds as well. While Windows is not a primary platform, truly cross-platform apps can't just disregard such issues as long as Transmission can (at least theoretically) run on such systems, too.
  • Some cheap and crappy routers running NAT can't handle lots of connections per seconds and connections per seconds are critical parameter for them. Just because it's a matter of connections tracking table size and time of connection tracking: some morons router vendors are using too small tables and some are setting connection tracking time a way too high, all this leads to a dozen of funny bugs in some routers behavior.
  • On high-bandwidth links low connections per second rate does may not allow to fully saturate link capacity, actually (because to send lots of data you need to have a lots of connections to many peers, this generally implies lots of connections per second as well).

As for me, I would prefer to have a control over this process in UI so I can choose my size depending on situation (like router abilities, channel speed and so on).

comment:2 Changed 13 years ago by charles

  • Milestone changed from 2.10 to Sometime
  • Status changed from new to assigned

Changed 11 years ago by phreek

comment:3 Changed 11 years ago by phreek

I am submitting a patch (tested on 2.61)

It allows the user to modify the MAX_CONNECTIONS_PER_SECOND value via a command line argument and saves it to settings.json

comment:4 Changed 11 years ago by x190

And I am hoping something like this gets implemented. I've been advocating something like this for ages and got soundly swatted down each time.

Being the swatee, it's rather mind-boggling, but not surprising, that the swatter, namely one, Charles O'Jordan, was the author of this ticket!

This patch could indeed be helpful for many users. phreek: For what situations have you found this functionality helpful?

comment:5 Changed 11 years ago by phreek

Specifically when im running transmission on a box with a gigE internet uplink. I find that using that patch or simply changing the #define for MAX_CONNECTIONS_PER_SECOND from 12 to something higher ( i tested 100 ) greatly increased the speed at which transmission found new peers and started downloading faster/sooner when adding new torrents.

Note: See TracTickets for help on using tickets.