Cometbird/Firefox Extension to control bandwidth

[The UnUsual Suspect]

I think many users could find this extremely useful.

A CometBird/FireFox extension that will actively throttle back the max bandwidth settings of BitComet ONLY when the user is actively browsing.

Example:

BitComet max bandwith settings: (random nummbers for example)

upload limit: 1000kB/s

download limit: 2000kB/s

A user begins opening web pages with a supported browser that has the extension installed and bitcomet is temporarily restricted to...

upload limit: 800kB/s

download limit: 1600kB/s

Then after the browser is idle for more then 90seconds, the limit reverts to prior settings.

If implemented (and used) properly, this could allow bitcomet to gracefully "step back" and allow the browser to have more of the much needed bandwidth.

However, this extension should never install as default. A user will need to understand what it does for it to be adjusted and used properly, and something like this should only be used by a user that understands it. Perhaps offering it as a separate download will prevent it's misuse, or at very least having it only install by specific request of user (no "silent install" like browser integration does)

[kluelos]

I thought this might work better as a "downshift" selection from the mouseover menu, but as a manual choice, very much like the "Suspend all Active Tasks" option works now.

[zerojinn]

@ TUUS This suggestion sounds great and humanized. Somtimes I have to stop all the tasks to open a website first.

I will forward it to the development team.

@kluelos There might be several methods to realize this. Your opinion will be taken into consideration. :)

[greywizard]

He, he... TUUS, for the values you indicated in your post, there definitely shouldn't be any problem for the user to browse even by leaving the settings on default.

What I mean is that in the earlier days (3-4 years ago), when the average "high speed" Internet connection was 1-4Mb/s, well the difference between the "left" 20% of upload bandwidth between a 512Kb line and a 2-4MB line wasn't that much as they all had around 128-512kb/s upload speed.

But nowadays, there are way faster connections out there, and the simple 20% formula is starting to be quite inaccurate.

Sure, it will still keep you on the safe side, but let's face it, even for my 25/3.5Mb/s connection which is not "top of the class" these days, 20% of the upload bandwidth will mean 700kb/s upload bandwidth available for the rest of applications, which is enough for 20 simultaneous browsers to send their requests and still run another BitTorrent client along with them.

My point is that the higher you go on download/upload speed plans the higher the available bandwidth provided by the 20% will be, in a logarithmic-like, not in a linear fashion.

So while this will address part of the issue for the users which have slower connections these days it won't have any noticeable impact for those with faster ones.

Nonetheless, even on fast connections you can find yourself "stalled" at times by BitTorrent and thus we come back to the second most important reason why you can encounter serious slowdowns while using a BitTorrent client, which is the clogging of the NAT table in your home router. BitComet (and most of the other BitTorrent clients) sends and receives A LOT of packets on UDP and quite often to lots of different IPs.

And apparently that number increases with the speed of your connection (i.e the speed at which your tasks run). On my older 4Mb connection the highest numbers of simultaneous "connections" I could usually see in my firewall was around 800+, whereas with my new connections I've witnessed it go to as high as 2000+.

And that wouldn't be a problem at all, if the traffic would happen among a handful of IPs, but very often this happens with lots of different IPs which leads to your NAT table filling up pretty quickly.

When that happens from one model to the next, routers handle it differently. The worst ones crash or freeze, the better ones just drop new connection attempts until an entry in the table times out and is being freed. So, in the best of cases you will experience the same thing as if your whole bandwidth was being used by BT protocol.

As you may remember I've been nagging the team a while ago, to implement a feature which will monitor the number of IPs which BC tries to contact on UDP, within a defined amount of time, by constructing and maintaining a table similar to the one used by the router, where UDP sockets would be entered when first used and then timed out (if not used anymore). That was meant to give the user the means to limit the number of different outgoing UDP sockets per minute and keep in line the number of entries which BC creates in the NAT table.

The team went instead with the choice of limiting the raw number of UDP packets per second (it obviously was the easier choice). Unfortunately there is no way to tell how many new UDP sockets BitComet will open in each different minute, therefore it's kind of hard to decide upon a right value to use here.

There are 2 different situations:

A. When BC "talks" with lots of different IPs (on UDP) in a very short time, limiting the number of raw UDP datagrams to something lower (let's say 10/s) will help address the issue of flooding the NAT table of the router with entries;

B. When BC may "talk" with roughly the same IPs (on UDP) for let's say 5-10 minutes, the limit you set on the raw no. of UDP packets may actually hinder the communication between your client and those peers, needlessly, as BC doesn't create anymore entries in the NAT table anyway but still can only send a limited no. of UDP packets towards the same IP.

As you can see the current solution, while offering some degree of control over the problem it makes BC shoot itself in the leg quite often, since the pattern of communicating on UDP is quite dynamic.

That's why is hard to come up with a "right" value to use here, for any connection line/ISP speed plan of your choice.

Therefore, my final point is that if the extension you propose would include both a speed throttling mechanism, as you mentioned, and a mechanism to keep the NAT table occupied to less than 100% at all times, only then it will address the slowdown issues that many users may encounter quite often.

Of course, nobody jumps to speak about how much work it may take to create something like this. :) :P

[The UnUsual Suspect]

Yes, I realize high bandwidth users won't need this as much, but I can also tell you that the faster you download, the more free upload bandwidth you need. I too initially thought I could get by with only 10% reserved bandwidth, but soon realized that when all 90% was used for upload (close to 2000kB/s on my connection), that it caused problems. This is actually quite rare, but the problem vanished when I reverted back to 80%, and being that I rarely upload at full ability at this setting, there would be little benefit if I increased it, and a confirmed disadvantage.

Also, the numbers I quoted were just random to make sure my English was translated correctly.