Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
The Internet Media Networking IT Your Rights Online

uTorrent To Build In Transfer-Throttling Ability 187

vintagepc writes "TorrentFreak reports that a redesign of the popular BitTorrent client uTorrent allows clients to detect network congestion and automatically adjust the transfer rates, eliminating the interference with other Internet-enabled applications' traffic. In theory, the protocol senses congestion based on the time it takes for a packet to reach its destination, and by intelligent adjustments, should reduce network traffic without causing a major impact on download speeds and times. As said by Simon Morris (from TFA), 'The throttling that matters most is actually not so much the download but rather the upload – as bandwidth is normally much lower UP than DOWN, the up-link will almost always get congested before the down-link does.' Furthermore, the revision is designed to eliminate the need for ISPs to deal with problems caused by excessive BitTorrent traffic on their networks, thereby saving them money and support costs. Apparently, the v2.0b client using this protocol is already being used widely, and no major problems have been reported."
This discussion has been archived. No new comments can be posted.

uTorrent To Build In Transfer-Throttling Ability

Comments Filter:
  • by Anonymous Coward on Sunday November 01, 2009 @05:57PM (#29944706)
    Ugh. TFA is all about Torrent (or uTorrent if Slashdot can't print a mu).
  • by timeOday ( 582209 ) on Sunday November 01, 2009 @06:11PM (#29944826)
    Bittorrent spawns a huge number of connections. If the OS (or ISP) gives equal bandwidth to each TCP stream, your connection to youtube gets about as much as each one of your 25 bitorrent connections, which destroys the streaming video, voip, or even normal web surfing. I would LOVE it if this provides a solution. (I would be even happier if ToS flags were widely honored, but that has never happened, so I don't know why it would happen now).
  • Re:Linux client? (Score:2, Informative)

    by trendzetter ( 777091 ) on Sunday November 01, 2009 @06:22PM (#29944906) Homepage Journal
    I use deluge as a utorrent replacement
  • by Don Negro ( 1069 ) * on Sunday November 01, 2009 @06:36PM (#29945030)

    Short answer, No. TCP doesn't back off until packets are lost. uTP looks for latency increases which happen before packet loss (and therefore, before TCP congestion control kicks in) and throttles itself preemptively. Put another way, TCP treats all senders as having an equal right to bandwidth. uTP doesn't want to assert an equal right to bandwidth, it wants to send and receive in the unused portion of the available connection.

  • by PhrostyMcByte ( 589271 ) <phrosty@gmail.com> on Sunday November 01, 2009 @07:24PM (#29945364) Homepage

    Most clients have you set a fixed upload speed. Some try to do this automatically, while most have you set it manually. This isn't perfect - if you set it to use 80% of your upload, and you are using more than 20%, things will get slow. If you use less than 20%, you'll have some amount idle and being wasted. Some rely on something like monitoring ping to some specific service.. if ping is higher, throttle back. If ping is low, increase speed. Again this isn't perfect because it relies on a single host and route to determine your speed.

    uTorrent's new protocol requires no action from the user, no automatic bandwidth tests, and no outside service. It is designed to always use the optimal speed, while never interfering with foreground tasks.

    It has been a while since I read it, and when I read it I was very very tired, but my understanding is that it tags each packet with a high-precision send time. So if we have two packets, A and B, A will sent at 100ms and B will be sent at 300ms. So you know they were sent 200ms apart. The _receiver_ then notices that he receives them 400ms apart, so there is 200ms of lag which means it should be throttled back. It tries to keep the amount of lag 50ms. Again, I could be completely wrong :D

    Since it is based on UDP and not TCP, it also solves the problem of Comcast sending fake RST packets to make each client think they wanted to disconnect from eachother.

  • by norpy ( 1277318 ) on Sunday November 01, 2009 @07:46PM (#29945522)
    I dont' think you quite understand that word you used there. Hulu/pandora are the OPPOSITE of multicast.
  • by Anonymous Coward on Sunday November 01, 2009 @07:48PM (#29945528)

    You have no clue what multicast is, do you? Please stop using that word until you get a fucking clue about what it is.

    Hulu and Pandora are NOT multicast. If they were, it would put less of a strain on their networks.

    I've owned an ISP and I can tell you, P2P applications like BT put a BIG strain on the network. You saying its a myth doesn't make it so. Just shows that your an idiot who talks out of his ass.

    That being said, instead of bitching about network congestion like Comcast does, I would upgrade my network to keep up with the demand. I got a lot of customers that way. Long-term, its the better strategy.

  • by AHuxley ( 892839 ) on Sunday November 01, 2009 @08:28PM (#29945754) Journal
    Think of it as Apples Grand Central Dispatch for your network.
    If you have the bandwidth and nothing else is requesting it, your torrents will fly.
    Want to watch youtube HD on your low end consumer grade adsl, your torrents will slow and overall networking will still seem responsive.
    When done viewing, BT will reclaim the bandwidth.
    BT is not just aware of your hard coded BT app max settings, but also your OS networking demands and can adjust?

Thus spake the master programmer: "Time for you to leave." -- Geoffrey James, "The Tao of Programming"

Working...