Throttle Max Connected Peers when Downloading Task is complete

[josh53188]

While seeding, if not initially, I believe it would be a great feature to have the option to reduce max connected peers to perhaps 2x the number of upload slots(or better yet, a selectable field). This would allow lower settings for "Global maximum number of connections" and allow for a greater number of connected peers when downloading. I believe this would result in higher cpu usage and result in more hammering of clients to get into those slots, but it should provide for higher speed downloads when "Global maximum number of connections" is set to a lower number and should result in a lighter load for our routers.

[Switeck]

When a torrent finishes downloading, it immediately drops all connected seeds. However, it doesn't seem to go into an aggressive mode to connect to more peers. So there doesn't seem to be a major cpu spike because of it. I've seen my other torrents gain a few connections so they take a bigger chunk of my global connection max at that time.

There does seem to be different connection rates used by µTorrent depending on whether a torrent is just started downloading, just started seeding, or has been downloading or seeding for hours. If a torrent approaches or reaches max connections, there does seem to be a drop-off of connection attempts...as there SHOULD be.

I've seen this with TCP view from www.sysinternals.com ...HOWEVER I cannot tell with TCP view whether µTorrent "knows" whether to be more or less aggressive with a torrent if it cannot seem to make many connections relative the numbers reported by the tracker. I have seen torrents with 0 of 20 peers connected while seeding, but I don't know if that's due to the tracker reporting "ghost" (long-gone) peers and misreporting seeds as peers -- or lots of firewalled peers.

Once you are seeding, marginal torrents with lots of firewalled ips cannot be hammered for connections, because you cannot connect to any of them (you have to wait for them to connect to you, and they often drop connection really quick for no apparent reason). Worse, the few connections you CAN make are likely unfirewalled seeds...so those connections get dropped immediately too. It causes considerable connection churn cycling through dead ips, unstable connection ips, and connecting then dropping seed ips.

After many hours running, most of my connections are on my incoming port -- made by someone connecting to me. This is good because I am unfirewalled. But if I was firewalled, µTorrent would have to be pretty aggressive to maintain even a fraction as many connections.

[josh53188]

Yeah I don't think it is aggressive about remotely connecting to peers once it's seeding, but that the remotely initiated connections still continue and are unabashed by the status of the torrent. So that there are just as many connectable peers whether you are leeching or seeding and I would like to see only a handful of peers connected to me when I am seeding since both the peers and myself do not benefit from being connected if I only have a few upload slots. I prefer to dedicate speed to a few peers rather than spread out low speed to several peers which will increase cpu overhead, increase the wear and tear on my hard drive, and hurt my connection overall.

I don't like having to stop/start large torrents simply due to concurrent connection overhead. I try to keep seeding as much as I can, especially on near dead torrents, but the system in place almost forces you to dedicate your bandwidth and peer connections to only a few.... unless you have untypical hardware and an untypical internet service.

Naturally, however, it would make sense to connect to a good number of peers and spread the data out to as many as possible if initially or super seeding. I don't mind micro-managing torrents and I don't expect the client to be all-knowing, but I would like to be able to select the minimum/maximum peers and such for every torrent. Being able to set bandwidth allocation is great, especially if you could combine that with connected peers and upload slot throttling.

Perhaps it is a feature that has already been thought about, but maybe not included due to the ability of abuse. I just think that it would help torrent dispersal more than it would hurt it.

[DreadWingKnight]

It is not possible to control the number of connections that come in from outside.

You can't really control another system's settings or behavior.

Micromanaging seems like a good idea at first, but after a few torrents you realise that it's not as effective as you think.

[Switeck]

I think trackers can be told you've already reached max connections so as not to hand your ip out for awhile. If not, they should -- as any large torrent with 1,000+ seeds+peers is going to resemble a DDoS attack.

Having a max connections per seeding torrent isn't an unreasonable new feature. It's really in line with some of the other seed-specific features.

An extension of this same idea is when your connection goes into Scheduler 'reduced speed' mode. You're still keeping the same connection rate, half-open connections, total connections, connections per torrent, and even upload slots. So if each upload slot was getting 3 KB/sec before, it might be getting 1 KB/sec or less when Scheduler kicks in.

[josh53188]

"It is not possible to control the number of connections that come in from outside.

You can't really control another system's settings or behavior."

It is impossible to control connection attempts, but it certainly is possible to throttle whether the local client decides to negotiatiate a connection to the remote client.

I've never needed to use scheduler, but even with a quality QoS router; I still have to limit my uploads to about 50% of max instead of the usual 85-95% of max for VoIP.

[DreadWingKnight]

Here's the thing about connection attempt control on a single-port client:

The client can't know what torrent the attempt is for until the handshake.

Throttling won't help you.

[josh53188]

"Here's the thing about connection attempt control on a single-port client:

The client can't know what torrent the attempt is for until the handshake."

Although I didn't know that before, that still doesn't affect what I want... I don't think. Once it's determined which torrent the remote client is after, they can then be denied a connection to the local client or simply dropped if the value for ie "max connections for seeding task torrent" is already at maximum for it.

[Switeck]

If for any reason global connections have been reached or only 1 torrent is running and max connections have been reached...I don't see why ANY incoming connection should get past a very short "I'm busy" reply.

[josh53188]

"If for any reason global connections have been reached or only 1 torrent is running and max connections have been reached...I don't see why ANY incoming connection should get past a very short "I'm busy" reply."

I agree, but that's why I feel that individual torrents should be able to have connected peers reduced instead of a global setting for all torrents. This way you are able to reduce the overall global if you can reduce a few torrents individually.

[Switeck]

...just like individual upload+download speed and upload slots.