Max Connections Per Torrent

[yaluenliao]

I'm running BitComet 64-bit v1.32 and it seems to me that the option for setting the maximum connections per task is missing. Or else it's hidden very well somewhere in the options. Right now, afaik BitComet has a hardcoded max connection limit of 50 per task. How can I go about changing this value? Thanks.

[yaluenliao]

Ok I've found the bittorrent.max_connections_per_task setting in the advanced options. To quote the wiki though, the setting determines "Max connections per task. Here 0 equals unlimited. It's recommended to keep the default setting, for ordinary users." Instead of unlimited, it seems to default to 50. I'm guessing the wiki needs to be corrected.

[greywizard]

It may be so or not. That info in the wiki came from the development team. So unless they confirm otherwise we can't go ahead and change it off the top of our head.

Don't mistake though the default number of connections per task with the maximum number of connections per task. They're two different things and serve rather different purposes, obviously.

[yaluenliao]

As you say. To clarify, what I noticed is that while the default value in the bittorrent.max_connections_per_task setting is 0, which should mean a task has no cap on the number of connections it can have according to the wiki, the Statistics pane shows there is actually a limit of 50 per task. Also, the description for bittorrent.max_connections_per_task shown in Advanced Options says "Maximum number of connections per task (0 - auto)", suggesting that a value of 0 for the field actually tells BitComet to use a default cap, which seems to be 50.

[kluelos]

Well, yes, as far as that goes, though I take it to mean that BitComet should manage this number as it sees fit, adjusting it on the fly, but, yes, a maximum of 50. Extraordinary circumstances might make you want to increase that, though I'm not sure what those circumstances would be. Since this is effectively the number of piecemaps you're keeping track of, its easy to see why this should never be unlimited.

[greywizard]

The way I see it (which is congruent with what kluelos states above) is that when you set it to "unlimited" you hand the power to choose how many connections will be allowed to a task, to BitComet.

Because somebody HAS to decide how many connections will be allowed for a task.

The alternative, which may seem enticing at a first superficial view, would be that BitComet connected to every peer in the peer list for a task, simultaneously, and maintained all those connections if possible.

Even if this may seem a good idea I think in fact it would be a horrible one. A single task may have tens of thousands of peers at any time and I guess you can see that even for a single such task, the toll on CPU and memory resources at best wouldn't justify the benefits in any way and at worst it would bring a system to its knees very quickly.

Therefore a limit per task must be imposed.

Now, that could be dynamically modified during the task's lifespan or set static at the beginning at every session for each specific task, based on certain parameters (which seems to be the way BC works now).

These parameters could be system-related and/or swarm-related. I don't know exactly on which parameters BC relies to set this value for each task and/or if its a bug that for most tasks it seems to be displayed as set at 50 on the Statistics tab or if maybe most tasks/systems fall under a category for which this value is the most productive one.

Either way, my main point was that when you set it to "unlimited" it doesn't mean that BitComet should have a connection with every peer in each swarm for every running task, but you rather entrust BC with the power to choose what's best for you, the way the board of directors entrust the CEO of a company with almost unlimited powers to do what he "knows to be best" for the good of the company.