Jump to content

Ways in which uTP handles congestion


Recommended Posts

I have already posted in general, but after almost 3 days of no response I thought I'd give you guys a shot, so if just one kind person could please give any possible insight into this, that would be much appreciated. :)

If I remember correctly, it was with the introduction of uTorrent 2.0, in around October 2009, that uTP was introduced to self-throttle mainly upload traffic but also download traffic under 'congested' conditions to help other applications using the internet as well as to help ISPs so they have less (or no more) need to throttle bittorrent traffic.

There was also some reaction to the new version as it meant that utorrent favoured it's own client to others, prioritising them accordingly, although this seemed to be a bit exaggerated.

My main question is, does uTorrent employ any other ISP-friendly techniques, such as prioritising upload traffic to IP addresses closest to the user (so, giving users who live close to me/in my country priority upload traffic over users who are living far away) so that ISPs have less international traffic to deal with?

(And if this feature exists, if someone could please tell me which version it was implemented in, that would be much appreciated.)

Another question I have is, does uTorrent use ping response time to gauge how congested a network/connection is (and then decides to limit either upload or download or both..)?

And, can this feature be turned off?

And lastly, assuming I can't turn it off, did this throttle-when-congested feature start with version 2.0? as in, if I use v1.9, this feature won't exist.

Thank you in advance for your time. :)

Link to comment
Share on other sites

It does not prioritize nearby users, either through ping or by GeoIP or any method.

There is one exception in the BEP22 feature, where uT can auto-discover and ISP-provided retracker to find "local" peers on that torrent.

It also does not use ping to measure congestion, not in the normal sense. uTP itself uses round-trip time in a way, but only as a relative metric, since it just figures out the base delay for that connection and detects congestion if the RTT rises a certain amount above that base delay.

The feature existed before 2.0, but needed an advanced option to turn on.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...