Slashdot Mirror


uTorrent To Build In Transfer-Throttling Ability

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."

187 comments

  1. god-fucking-awful summary by Anonymous Coward · · Score: 0, Informative

    Ugh. TFA is all about Torrent (or uTorrent if Slashdot can't print a mu).

    1. Re:god-fucking-awful summary by vintagepc · · Score: 1

      No it cant. I definitely typed (mu)Torrent when submitting. I just typed another here: -->-- Slashdot UTF=broken, but we knew that already.

      --
      Evolution - Est. 4500000000 B.C. Don't piss in the gene pool.
    2. Re:god-fucking-awful summary by Anonymous Coward · · Score: 0

      Well, it's a little confused, but the facts are about as correct as one would expect..... Presumably uTorrent is the first client to take advantage of the new protocol.

      Sounds like a useful feature -- our upload bandwidth is limited to 128kb/s by our ISP, so any vaguely reasonable torrent upload rate will make web browsing basically impossible. I wonder if this function will work under Wine..... IIRC, the 'Auto upload speed' function in uTorrent does not...

    3. Re:god-fucking-awful summary by FlyingBishop · · Score: 0, Offtopic

      uTorrent has always had very fine control over how much bandwidth you used, per-torrent and overall.

      All this does is move the throttling the ISPs used to do for no reason to the user's computer to do for no reason. It's a myth that BitTorrent causes a lot of strain on networks - it's multicast streaming like Hulu and Pandora that really do a number on their networks.

      But Hulu and Pandora aren't used to download illegal things (never mind MediaFire, Rapidshare, surfthechannel and their brethren handling illegal multicast quite well.)

      Oh wait - that's how everyone pirates stuff since they started cracking down on p2p.

    4. Re:god-fucking-awful summary by norpy · · Score: 4, Informative

      I dont' think you quite understand that word you used there. Hulu/pandora are the OPPOSITE of multicast.

    5. Re:god-fucking-awful summary by Anonymous Coward · · Score: 4, Informative

      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.

    6. Re:god-fucking-awful summary by Anonymous Coward · · Score: 0

      You've never run an ISP before, have you?

    7. Re:god-fucking-awful summary by Anonymous Coward · · Score: 1, Insightful

      Since you are off topic, I'll jump off with you. Having worked for a few ISP's I can tell you it is practically criminal how over sold the capacity was at every single one I've witnessed. I understand it is profitable to oversell your product but the extent that it is done has obviously caused more problems for some ISP's than it has for others.

    8. Re:god-fucking-awful summary by Anonymous Coward · · Score: 0

      That being said, instead of bitching about network congestion like Comcast does, I would upgrade my network to keep up with the demand.

      And that's probably why you don't own an ISP anymore. Money doesn't grow on trees, and anyone who spends money on upgrading goes bankrupt because you either run out of money directly or indirectly from loss of customers when your service price strays too far above the rest of the pack who bitch instead of upgrading and therefore have less expenses than you do.

    9. Re:god-fucking-awful summary by kdemetter · · Score: 1

      No , you just need a good balance between making profit and upgrading.
      Simply put : use a set portion of your profit to upgrade your network. This is difficult at the start , but it pays off after some time.

    10. Re:god-fucking-awful summary by FlyingBishop · · Score: 1

      I obviously misspoke, and meant unicast. But the point remains, there's no reason to put required throttling in the client, and streaming is a bigger drain than p2p.

    11. Re:god-fucking-awful summary by xiong.chiamiov · · Score: 1

      But Hulu and Pandora aren't used to download illegal things (never mind MediaFire, Rapidshare, surfthechannel and their brethren handling illegal multicast quite well.) Oh wait - that's how everyone pirates stuff since they started cracking down on p2p.

      Well, I don't know about you, but those of us who know what we're doing tend to use irc xdcc bots and fservs over file hosting sites.

  2. reason 1 down. reason 2 in que. by pha7boy · · Score: 4, Insightful

    I'm sure ISPs such as Comcast will find another reason to suggest they need in interfere with network management. just give them a little bit of time to put their heads together with the guys at RIAA.

    --
    -- All this knowledge is giving me a raging brainer.
    1. Re:reason 1 down. reason 2 in que. by Anonymous Coward · · Score: 0

      Dude, the guys from ISPs such as Comcast _ARE_ the RIAA! (for all intents and purposes)

    2. Re:reason 1 down. reason 2 in que. by nate11000 · · Score: 5, Insightful

      This probably isn't so much for avoiding the eye of your ISP as it is for personal network management. I know I don't want bittorrent interfering with my internet usage, particularly when my wife is at the computer. Not having a router that can prioritize my internet traffic, this is a welcome feature to avoid either slow-downs or having someone else turn off my downloads so they can use the internet.

    3. Re:reason 1 down. reason 2 in que. by Anonymous Coward · · Score: 0

      They won't. They'll just say the way it is implemented in v2.0 is still wrong and not many clients really use it. See? They don't even need to come up with anything new!

    4. Re:reason 1 down. reason 2 in que. by arbiter1 · · Score: 1

      They will, it will give them another reason NOT to upgrade their networks like they should of 3 years ago

    5. Re:reason 1 down. reason 2 in que. by wizardforce · · Score: 4, Insightful

      I fear that you're right. With our luck, ACTA will probably kill net neutrality stone dead with provisions allowing for perhaps even mandating throttling by ISPs to protect various corporate interests regarding copyright law. The FCC's position on net neutrality supports this view strongly. Allowing for exceptions where activity is deemed illegal.

      --
      Sigs are too short to say anything truly profound so read the above post instead.
    6. Re:reason 1 down. reason 2 in que. by Firehed · · Score: 2, Interesting

      I don't think this protocol will replace QoS on your local network - more likely, it will intelligently select peers based off of external network (Internet) factors

      --
      How are sites slashdotted when nobody reads TFAs?
    7. Re:reason 1 down. reason 2 in que. by interkin3tic · · Score: 4, Insightful

      I'm sure ISPs such as Comcast will find another reason to suggest they need in interfere with network management. just give them a little bit of time to put their heads together with the guys at RIAA.

      Really? I for one am certain that they will continue with the exact same rhetoric. It's a good scapegoat for them, and they don't have a problem with overlooking facts to avoid spending money.

      Comcast: "No, we don't need to spend money to relieve congestion, the slowdown is all caused by bittorrent. We need to regulate it."
      Us: "No it isn't, bittorrent isn't causing the problem, it's now self-regulating. The problem is on your end."
      Comcast: "The slowdown is all caused by illegal bittorrent transfers! We need to regulate it!
      Us: "No, see, here's a breakdown of traffic..."
      Comcast" "THE SLOWDOWN IS ALL CAUSED BY ILLEGAL BITTORRENT TERRORISM! WE NEED TO REGULATE IT!"

    8. Re:reason 1 down. reason 2 in que. by sopssa · · Score: 1

      It will improve the local internet connection, which is the parents problem as well (since the torrent client is slowing down the other internet usage). Torrent client will analyze how much latency grows and tries to optimize that.

      But I'm more unsure about how exactly will this improve ISP's network. They do not have global latency problems because of torrenting but only bandwidth capability problems, and torrent clients have no way to know if bandwidth usage at the ISP level is too much (or where it is).

    9. Re:reason 1 down. reason 2 in que. by Anonymous Coward · · Score: 0

      If it doesn't cost them money I'm pretty sure they really won't give a damn.

    10. Re:reason 1 down. reason 2 in que. by adolf · · Score: 1

      It looks like a good method to manage one's upload speed in order to keep local latency low for other purposes. However, I also don't think it'll help at the ISP level at all -- the tubes are just too big for my paltry 1-megabit upstream to make any measurable difference in the latency on them.

      What would, however, make a big difference (and I've been saying it for years): Geographically-aware peering.

      It's obviously more efficient on the network if you download something from someone a 4 hops away, than if you download something from someone who is 8 hops out. Further, it's more efficient to download from someone in the same locality -- assuming the routes are sane -- than it is from someone on another continent.

      So do both, and try to balance it out. Prefer peers which are closer (both network-wise and map-wise), and everyone (including, ultimately, the customer) saves money.

      I know that IP geolocation services are sometimes flaky, but it doesn't even need to be anywhere near perfect since currently, BitTorrent implementations don't bother with any of this at all. Even a half-assed solution seems likely to make the whole thing a lot cheaper to route.

    11. Re:reason 1 down. reason 2 in que. by L4t3r4lu5 · · Score: 0, Redundant

      Your conversation is a little too long. Here's the more accurate one.

      ISP Tech Support; "Hello, thanks for calling. If you're a user of BitTorrent, please press 1 now. If not, please press 2."
      Us: 1
      ISP TS: You are a dirty pirate. We're disconnecting your service for alleged copyright infringement and sending you an invoice for the remainder of your contract, payable within 30 days or we'll ruin your credit record. *click*

      --
      Finally had enough. Come see us over at https://soylentnews.org/
    12. Re:reason 1 down. reason 2 in que. by nstrom · · Score: 1

      Closer makes no difference, effective transfer speed does (which BT already prioritizes peers based upon). I can get much better download rates from the guy in Finland with a 100mbit connection then I can from the guy across town on my same cable ISP with an already saturated 384kbps upload.

    13. Re:reason 1 down. reason 2 in que. by GrumblyStuff · · Score: 1

      I hearby copyright and/or trademark the word "Bitterrorism".

    14. Re:reason 1 down. reason 2 in que. by Anonymous Coward · · Score: 0

      I hearby copyright and/or trademark the word "Bitterrorism".

      "BitterTorrenting" v. Feeding off the bitterness of strangers.

    15. Re:reason 1 down. reason 2 in que. by adolf · · Score: 1

      You're ignoring cost. All that international bandwidth costs more money, at the end of the day, than more localized bandwidth would. You, the customer, bear the brunt of these expenses in the forms of increased subscription fees and the ongoing war against P2P.

  3. Yeah But... by vintagepc · · Score: 1

    How much do you want to bet ISPs will suddenly have numerous other non-bandwith reasons to justify traffic shaping practices? :-)

    --
    Evolution - Est. 4500000000 B.C. Don't piss in the gene pool.
  4. Throttling ... by Anonymous Coward · · Score: 0

    the first post! boooyaaa

    1. Re:Throttling ... by Anonymous Coward · · Score: 0

      If you had been using the traffic shaping version of BitTorrent your post might not have lagged.

    2. Re:Throttling ... by Anonymous Coward · · Score: 0

      ROFL!!!

  5. TCP regulating congestion by buchner.johannes · · Score: 1

    shouldn't TCP do that by itself?

    Anyway, I consider this is a good thing, it'll probably increase goodput (less outdated, duplicate packets, preferring "closer" networks).

    --
    NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    1. Re:TCP regulating congestion by Anonymous Coward · · Score: 5, Interesting

      shouldn't TCP do that by itself?

      Anyway, I consider this is a good thing, it'll probably increase goodput (less outdated, duplicate packets, preferring "closer" networks).

      This is probably aimed at average BItTorrent users, i.e. they're on Windows. I highly doubt Windows has the wide variety of TCP congestion management protocols that are available in the Linux kernel. If I am wrong about that, please correct me as I had a really hard time confirming this for certain. It's not exactly a "common support question" that you can easily Google for, or maybe your Google-fu is stronger than mine. I think Windows uses an implementation of Reno and that's it. Hence, the need to build these features into the clients.

      Then there's the issue that to a TCP congestion protocol, all traffic is likely to be equal in its eyes. It won't know that torrent traffic should receive lower priority whenever it conflicts with something else, VOIP apparently being the classic example. For that you need actual QoS. So the client itself will now measure latency to help determine this.

      Also, I doubt this will eliminate an ISP's excuses for throttling traffic. In terms of bandwidth saturation and network capacity, I highly doubt your ISP really cares whether your BitTorrent client is fully saturating your upstream by itself, or whether it uses only the bandwidth that something else doesn't need. In either case, you'd be maxing out your upstream pipe which is what they might concern themselves about.

    2. Re:TCP regulating congestion by timeOday · · Score: 4, Informative

      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).

    3. Re:TCP regulating congestion by causality · · Score: 2, Interesting

      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).

      I have heard the claim that the reason why ToS/QoS flags are not widely honored is that Windows, by default, sets the highest priority for ALL traffic with no regard for what kind of traffic it is. As I don't run Windows, I have to say I honestly don't know whether this is so. Can anyone affirm or deny this claim?

      --
      It is a miracle that curiosity survives formal education. - Einstein
    4. Re:TCP regulating congestion by Anonymous Coward · · Score: 0

      not windows per se, but each apps and its dog.....

    5. Re:TCP regulating congestion by Don+Negro · · Score: 5, Informative

      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.

      --

      Don Negro
      Perl 6 will give you the big knob. -- Larry Wall

    6. Re:TCP regulating congestion by Anonymous Coward · · Score: 1, Insightful

      Nope, just some average Linux user bullshit as usual. Windows sets ToS as regular traffic by default, of course.

    7. Re:TCP regulating congestion by amiga500 · · Score: 1

      TCP does effectively limit throughput by means of the Sliding Window Protocol. Packet loss will decrease the size of the sliding window, but on a congested network, the window will be slow to increase. What TCP doesn't offer is different Quality of Service. uTP attempts to run TCP at a lower priority than existing TCP traffic. Allowing Skype or YouTube to run at a higher priority is advantageous to the users of those services.

    8. Re:TCP regulating congestion by BikeHelmet · · Score: 1

      TCP Vegas?

      I remember reading how AT&T's iPhone "zero-packet-loss" was causing network congestion and 8-second ping times.

    9. Re:TCP regulating congestion by AHuxley · · Score: 2, Informative

      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?

      --
      Domestic spying is now "Benign Information Gathering"
    10. Re:TCP regulating congestion by Anonymous Coward · · Score: 0

      The problem with Windows' congestion control and QoS is the same as with Linux: it's nigh impossible to set up for ordinary users.

    11. Re:TCP regulating congestion by Wesley+Felter · · Score: 1

      Yes, uTP is like Vegas but it actually works on Windows.

    12. Re:TCP regulating congestion by _KiTA_ · · Score: 1

      shouldn't TCP do that by itself?

      Anyway, I consider this is a good thing, it'll probably increase goodput (less outdated, duplicate packets, preferring "closer" networks).

      It would, if Bittorrent et all weren't designed to break TCP's regulating. By default uTorrent starts up with like 800 max connections at a time. The TCPIP spec was never really designed to handle this kind of shotgun flooding. The Bittorrent spec is designed to not care about fragmentation, QoS, et all. It is designed to break through college dorm QoS throttling, which is why this kinda discussion is kinda amusing.

    13. Re:TCP regulating congestion by Jarik_Tentsu · · Score: 1

      Yeah, it is a big problem. Especially since we've got a very basic router with no type of throttling or priority features.

      Generally when downloading a torrent from certain trackers and large amounts of peers, the whole internet pretty much goes down for every other person in the house. Or goes to dial-up rates. Drives my Dad nuts.

      It wouldn't be a problem if I had a proper router, but with this feature, it should help if it works well. =)

      ~Jarik

    14. Re:TCP regulating congestion by complete+loony · · Score: 1

      Just to be slightly more pedantic that the other responses. Bittorrent uses heaps of TCP streams, each of which can start pushing their current window size worth of packets when they receive an ACK packet from their peer. Assuming no other limits in the torrent client, this can easily flood your OS and router / ADSL / Cable modem's transmit buffers.

      uTorrent and probably every other torrent client already needs to have complete control over the transmission speed of every TCP stream so it can impose a sane limit and avoid adding to the latency of your internet connection. And since TCP was being more of a hindrance anyway, the uTorrent team went off and designed a protocol based on sending individual UDP packets.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    15. Re:TCP regulating congestion by mgblst · · Score: 1

      Wrong. You are thinking of the earliest versions of TCP. There is a lot better congestion management controls in recent TCP implementation stacks (recent = 90s).

      What this does is regulate bit torrent traffic only. So while TCP will cut down all your traffic, this will cut down bit torrent at the first signs of danger, before it gets to TCP throttling.

    16. Re:TCP regulating congestion by advocate_one · · Score: 1

      Generally when downloading a torrent from certain trackers and large amounts of peers, the whole internet pretty much goes down for every other person in the house. Or goes to dial-up rates. Drives my Dad nuts.

      that's YOU not managing your bandwidth correctly... I use Vuze and always set my uplink to only 20-30kbps max.. and downlink to 250-500 kbps... never any congestion for the other computers sharing the router...

      --
      Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
    17. Re:TCP regulating congestion by gmack · · Score: 1

      The protocol changes will probably not help you if your overflowing your router's NAT table. Try reducing your max peers, it's a trick I've used on some of the cheaper routers to avoid choking everything (including the bittorrent) Some Zyxel modems with custom telco firmware (thank you telefonica) require a max peers setting as low as 30.

    18. Re:TCP regulating congestion by Jesus_666 · · Score: 1

      IIRC, QoS needs to be installed separately, though. At least on pre-Vista versions.

      --
      USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
    19. Re:TCP regulating congestion by adolf · · Score: 1

      What is it with foreigners, and their various and sundry prose. For example: There is a clear trend for some of them to write a message which is primarily a statement, and to always end it with a question mark?

    20. Re:TCP regulating congestion by Anonymous Coward · · Score: 0

      I don't see why variety = quality. Additive increase - Multiplive decrease is a pretty simple technique and it works correctly. I think that if windows didn't throttle correctly the internet wouldn't work.

      I don't think the throttling is based on how saturated your upstream is. It probably based on how saturated your peer connection is, which is entirely different, and much more important. if you have a peer connection that is saturated, that means somewhere on the network you are over-loading a router-router connection, and that is bad for everyone. I would guess that the congestion control utorernt uses would try to give such peers a low priority, instead of using standard tcp throttling, which would overload the connection, then back off, then overload, back off, ect.

    21. Re:TCP regulating congestion by Anonymous Coward · · Score: 0

      What it is with clueless Americans who think that, every one else's native language exactly the same syntax as English have should?

    22. Re:TCP regulating congestion by Jarik_Tentsu · · Score: 1

      This happens regardless of speed. Just seems to happen on certain torrents for some reason.

      For instance, one torrent might be downloading at 200kB/s with 10kB/s upload without any issues. Another one might be at 60kB/s down and 10kB/s up and the rest of the net slows to a crawl.

    23. Re:TCP regulating congestion by ae1294 · · Score: 1

      This happens regardless of speed. Just seems to happen on certain torrents for some reason.
      For instance, one torrent might be downloading at 200kB/s with 10kB/s upload without any issues. Another one might be at 60kB/s down and 10kB/s up and the rest of the net slows to a crawl.

      As you said, you have a crappy router. Build a linux box for doing your NAT or change the settings in your torrent app. If you are using torrent over wireless you might find that things work much better if you plug your torrent box into the router instead (no encryption overhead, etc, etc). Other than that you need to reduce the total number of connections allowable in your torrent app. Some routers can't handle more than 200 to 300 connections at a time (total from all your computers). Also keep DHT turned off unless you need it because a tracker is down and you have no seeds. Same thing with peer exchange. (They both eat a lot of connections which will slow down a cheap router)

      If you have more than one person who uses torrent in your home you need to set each computer's torrent app to use a fraction of your total bandwidth and connections (which sucks). You can setup a Linux box to do QoS or flash your router with DD-WRT, tomato or some other third party firmware that has QoS.

      Be aware that those cheap routers you buy (Linksys, Netgear, etc) do not have the processing power to handle QoS on a big pipe. A 200Mhz ARM processor isn't going to handle a 10Mbit internet connection like a p3 1Ghz laptop with the broke screen you got off ebay for 50 bucks.

      The bottom like is the problem you are having is easy to correct, reduce the max settings on; up/down bandwidth usage, total number of connections, and divide by the number of computers that use torrent then subtract 10% or so for safety.

      Also most torrent app's have a scheduler as well so you can set your torrents to use more bandwidth when your dad isn't on the computer and your connection isn't running slow because all your neighbors are downloading porn after work.

      Testing is easy. Download a .torrent file for a linux distro like ubuntu which will have 3000 seeds and 6000 peers and then change the settings in your torrent app until you can browse the internet again. Don't forget that most connections get slower from 3pm til 10pm, test accordenly or learn QoS and latency checking methods.

    24. Re:TCP regulating congestion by Anonymous Coward · · Score: 0

      People seem to think QoS tags like ToS just magically work without special network setup. That isn't the case: if you don't have your own device on your own network specifically configured to honor QoS tags by prioritizing traffic according to a policy you set up, tags like ToS don't do anything. Your ISP rightfully ignores the tags, because they don't need their customers telling them how to manage their own networks.

      And no, Windows doesn't tag packets by default.

  6. But is it working? by wealthychef · · Score: 4, Insightful

    The summary says that the protocol is already out there, and "no major problems are reported." So how about "and congestion is being reduced, and here is how we know it?"

    --
    Currently hooked on AMP
    1. Re:But is it working? by angelbunny · · Score: 2, Interesting

      I've been using uTP for a couple of months now and I have to say it is excellent and is working for me quite well.

      However, since uTorrent is backwards compatible with the original TCP bit torrent protocol the second I start sending to a client that doesn't support uTP my ping jumps from 20 to 200 or i have to go back to manually limiting my upload rate. Regardless, uTP works.

    2. Re:But is it working? by Klaus_1250 · · Score: 1

      Major problems HAVE been reported, especially with people already using their own Traffic Shaping solutions. I've never gotten v2 to work properly. Uploading fluctuates and uses only half of my upstream on average. Even though 100% of the upstream is available without congestion issues. eMule otoh has absolutely no issues using 99% of my upstream bandwidth.

      --
      It only takes one man to change the Wisdom of the Crowd to Tyranny of the Masses.
    3. Re:But is it working? by Anonymous Coward · · Score: 0

      Or better yet, will this get AT&T to stop disconnecting me like clockwork every ten minutes even when I limit my down/up speed both to half what they could be?

    4. Re:But is it working? by Antiocheian · · Score: 1

      Are you using eMule's throttling option? (Upload Speed Sense in Extended options)

    5. Re:But is it working? by angelbunny · · Score: 1

      That is a hardware issue on your end either from a router or the modem itself. It is based on how many connections have been opened in a given amount of time (usually an hour) to a point where it crashes from a lack of ram.

      Do what I do, setup an old junk comp with a distro like pfsense to use as your router and then profit! :D

    6. Re:But is it working? by shadowturtle · · Score: 1

      This is the real issue with BT & slowdowns on most home routers, not bandwidth restrictions. The table that holds network address translations (NATs) doesn't have enough memory on these limited home consumer routers and thus fills up at an amazingly high rate. Putting a 3rd part firmware (e.g., DD-WRT) on a router is often one of the best ways to help prevent BT from crippling other users on the same shared Internet connection because it may give more memory to the NAT session table and also you can adjust the timeouts if you so choose.

    7. Re:But is it working? by Klaus_1250 · · Score: 1

      I'm using the Scarangel mod by Stulle, which has Maella bandwidth control + NAFC (network adapter feedback control). Plus, cFosSpeed trafficshaping which puts all packets of eMule.exe in the lowest class. Works like a charm, uses 99% of available bandwidth and I can still play EVE Online, login to servers with SSH or browse the web without lag.

      --
      It only takes one man to change the Wisdom of the Crowd to Tyranny of the Masses.
    8. Re:But is it working? by Antiocheian · · Score: 1

      So, it's a Torrent issue.

      Although the comparison is a bit unfair here because you are using the latest & greatest in bandwidth throttling which may not work in as broad an audience as Torrent's.

      I am using eMule too but NAFC isn't working well for me since we have a lot of systems on NAT and whenever there is internal FTP traffic the NAFC on the eMule client thinks the network is congested.

      The plain USS works OK though.

  7. Why? by Anonymous Coward · · Score: 1

    Why do articles always have to be referred to as "TFA," as in "The Fucking Article?" Why can't it just be "the article" most of the time?

    1. Re:Why? by vintagepc · · Score: 5, Funny

      Let me explain:
      a) That's "The Fine Article", you insensitive clod!
      b) You must be new here.
      c) In light of b) Articles=bad. Summaries=good.

      --
      Evolution - Est. 4500000000 B.C. Don't piss in the gene pool.
    2. Re:Why? by Anonymous Coward · · Score: 1, Funny

      Grandparent must be new here.

      He should Read The Fine Manual.

    3. Re:Why? by nate11000 · · Score: 1

      Why do articles always have to be referred to as "TFA," as in "The Fucking Article?" Why can't it just be "the article" most of the time?

      Let me explain:
      a) That's "The Fine Article", you insensitive clod!
      b) You must be new here.
      c) In light of b) Articles=bad. Summaries=good.

      or just
      a) "The Full Article"
      b) Like most acronyms, it's shorter than typing it out. How hard is that to understand?

    4. Re:Why? by Dunbal · · Score: 1

      Why can't it just be "the article" most of the time?

            Someone forgot to RTFM...

      --
      Seven puppies were harmed during the making of this post.
    5. Re:Why? by toppings · · Score: 1

      I have always read it as The Featured Article. Maybe I'm new here.

    6. Re:Why? by Mitchell314 · · Score: 1

      ?
      I've always read it as Today's | The Featured Article.

      --
      I read TFA and all I got was this lousy cookie
    7. Re:Why? by paragon1 · · Score: 1

      I always thought it was "Read the Fucking Article"; as in, RTFM (Read the Fucking Manual)

    8. Re:Why? by Anonymous Coward · · Score: 0

      Need a +1 Troll option.

  8. Linux client? by timeOday · · Score: 1

    In my experience, uTorrent only runs on Linux through Wine, and even then, only a few particular obsolete versions of uTorrent are Wine-compatible. Is there someway for me to run a uTorrent-2 client on Linux right now? I've wasted a lot of time trying to get bittorrent to play nice on my home network, to little avail.

    1. Re:Linux client? by vintagepc · · Score: 1
      --
      Evolution - Est. 4500000000 B.C. Don't piss in the gene pool.
    2. Re:Linux client? by trendzetter · · Score: 2, Informative

      I use deluge as a utorrent replacement

    3. Re:Linux client? by asdf7890 · · Score: 1

      Are there any particular features that you particularly want uTorrent for, or are you just wanting it because you are already familiar with it in a Winwos environment?

      There are a great many Linux native clients you could chose from and while many are text based (which might not be your cup of tea), such as the excellent rtorrent which I tend to use, there are quite a few that are GUI based, of which deluge seems very popular, or are GUI wrappers for working with text based clients (there are several such wrappers for the basic clients, and for recent rtorrent versions too.

      Some offer web-based interfaces too, which some find handy if they download to an external machine to reduce the impact on bandwidth quotas and traffic shaping that may be imposed by their ISP.

      See this page for a list of clients that you might want to look into.

    4. Re:Linux client? by timeOday · · Score: 1

      What is this story about? uTP, because it promises to reduce bittorrent interference with other apps on the network. From what I have gathered it is only offered by utorrent.

    5. Re:Linux client? by broeman · · Score: 1

      I started using deluge lately too, and it works great. I used to use Azureus (mainly for the plugins), but I always wanted memory handled better. Deluge is just as good as uTorrent IMHO.

      --

      (yes this can be compared with sex)
    6. Re:Linux client? by asdf7890 · · Score: 1

      What is this story about? uTP, because it promises to reduce bittorrent interference with other apps on the network. From what I have gathered it is only offered by utorrent.

      Ah sorry, I completely forgot the fact that rTorrent has become the "official" client since its purchase.

    7. Re:Linux client? by Anonymous Coward · · Score: 0

      DD-WRT router with OoS and KTorrent FTMFW

    8. Re:Linux client? by mirix · · Score: 1

      Me too. I've always thought of it as superior to utorrent. Never tried the windows port though, so I don't know how good it is.

      --
      Sent from my PDP-11
    9. Re:Linux client? by Anonymous Coward · · Score: 0

      Why should I fuck two midget Finnish women?

    10. Re:Linux client? by mister_playboy · · Score: 1

      FTMFW = For The MotherFucking WIn

      --
      Do what thou wilt shall be the whole of the Law ::: Love is the law, love under will
    11. Re:Linux client? by NorQue · · Score: 1

      uTorrent 1.8 works with Wine here and it already brings support for the uTP protocol, you just have to switch int on manually in the advanced settings. There any other reason you want to use 2? Because I wouldn't recommend that, as some private trackers don't allow using it yet.

      For 1.8.x, in advanced settings, set bt.transp_disposition to:

      0: attempt only TCP
      1: attempt both TCP and uTP, drop TCP if uTP is successful
      2: attempt uTP if supported, TCP otherwise
      3: attempt only uTP

    12. Re:Linux client? by thejynxed · · Score: 1

      The last time I used the Windows port, it sucked balls. Memory leaks out the ass, and the client completely ignored any bandwidth settings you made in the options panel. Not to mention corrupt torrent downloads after it was finished because it didn't properly discard/check file chunks.

      --
      @Mindless Drivel: 100% of Twitter posts ever Tweeted.
    13. Re:Linux client? by timeOday · · Score: 1

      Have you noticed whether uTP works as advertized - does it interfere with other apps less?

    14. Re:Linux client? by Hatta · · Score: 1

      If you have linux, you can set up QoS yourself. Or you can just set rTorrent to use 5 or 10 K/s less than your max upstream, and it should work fine.

      --
      Give me Classic Slashdot or give me death!
    15. Re:Linux client? by rdnetto · · Score: 1

      I've tried it, but it just didn't feel as responsive as uTorrent, although I did like the daemon/client design. uTorrent seemed to have faster transfer speeds as well.

      --
      Most human behaviour can be explained in terms of identity.
    16. Re:Linux client? by asdf7890 · · Score: 1

      Reply to self to correct error: I of course meant uTorrent in the above, not rTorrent.

  9. LAN performance also? by mleugh · · Score: 2, Interesting

    Is this likely to improve LAN performance when using bittorrent on a shared internet connection also?

    --
    /u2404
    1. Re:LAN performance also? by Torrance · · Score: 1

      Based on my reading of the article, it will detect congestion at any point along the route. If you have several computers behind a NAT router all sharing the same internet connection, and one of those computers is using this new BT protocol, it'll detect if it's congesting the gateway and reduce its speed.

      So, yes, it'll improve the network performance of any non-BT apps on any of the other computers in your local network.

    2. Re:LAN performance also? by wolrahnaes · · Score: 1

      Unless your LAN is slower than your WAN (remember that wireless never achieves its advertised rate) there should be no way BitTorrent is slowing down your LAN.

      Basically unless you have FiOS or similar and are using 802.11 to access it, something is wrong with your LAN if torrents break it.

      --
      I used to get high on life, but I developed a tolerance. Now I need something stronger.
  10. Sweet! by i-like-burritos · · Score: 5, Funny
    Now when I illegaly download the newest DVD screeners, I can do it with a clear conscience knowing that I'm not congesting the network!

    Seriously though, this is a good thing. I don't know why the story is tagged "your rights online"

    1. Re:Sweet! by Anonymous Coward · · Score: 0

      Now when I illegaly download the newest DVD screeners, I can do it with a clear conscience knowing that I'm not congesting the network!

      Seriously though, this is a good thing. I don't know why the story is tagged "your rights online"

      Read some of the previous posts. It's related to the ISPs claiming that Bittorrent is a bandwidth hog so they need to do traffic shaping. This protocol change is the same as saying "no, you don't need QoS, we'll do it ourselves. We'll make things more efficient too!"

    2. Re:Sweet! by Thantik · · Score: 1

      Actually quite the opposite. The change is just to lower bandwidth so uTorrent uses a more 'extra bandwidth only' approach, so YOUR other activities aren't interrupted. They could care less for the ISP.

    3. Re:Sweet! by AHuxley · · Score: 1

      Yes your non BT networking is really smooth, the pipe up is still maxed out the second your other non BT use is over.
      You paid for that up bandwidth, use it :)

      --
      Domestic spying is now "Benign Information Gathering"
    4. Re:Sweet! by jellyfrog · · Score: 1

      Actually quite the opposite. The change is just to lower bandwidth so uTorrent uses a more 'extra bandwidth only' approach, so YOUR other activities aren't interrupted. They could care less for the ISP.

      Yeah, they could design the protocol so that it simultaneously hacks into the ISP's servers and increases the bandwidth allocated to the user, changes the passwords and replaces all of the CEO's important documents with pictures of kittens. Take that, ISP!

  11. Clients already do this by bug1 · · Score: 2, Interesting

    AFAIK most bittorent clients throttle connections already, some automatically like vuze, others like transmission only manually.

    Or am i missing the point ?

    1. Re:Clients already do this by Biogenesis · · Score: 1

      I didn't RTFA, but from the summary it would seem that each client has its own method for throttling. What they want to to is build a throttling algorithm into the BT protocol, hence standardizing the procedure. I guess this would make client coding easier, as the throttling would be achieved with a call to a BT library rather than a client coder having to write/find throttling code themselves.

    2. Re:Clients already do this by PhrostyMcByte · · Score: 4, Informative

      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.

    3. Re:Clients already do this by angelbunny · · Score: 1

      Yes but what happens if your network speed is dynamic?

      For example, if you've got a 10megabit/s upload coming to your home but the line is saturated so at times it might bounce down to 6megabit/s for a minute or even in heavy load could go below 5megabit/s. How do you limit your upload speed to not kill your net when your upload speed is variable? Try limiting it to 5megabit/s and you'll be find but only using half of your max connection when it is available. Try limiting it to 8megabit/s and you're fine 90% of the time but still not utilizing everything properly. Also, QoS doesn't work properly because the speed is being limited via the cable modem so that isn't an option either. And finally, the auto upload max features on most bt clients have a delay so if your upload spikes down to 5megabit/s from 10 for 5 seconds your ping will jump up regardless.

      uTP only utilizes what is available and does an extremely good job so if your 10megabit/s connection spikes down to 2megabit/s for half a second your ping will not even jump up for that. Currently using uTP my upload rate is bouncing all over the place in a crazy fashion yet my net is not being hit at all. It is kinda like those stop lights on freeway on ramps to keep to many vehicles from entering the freeway at once. The effect works really well in my particular case.

    4. Re:Clients already do this by BikeHelmet · · Score: 1

      You can throttle on your end, and your end only.

      If you had say... Cable, and all your neighbours were active too, then this would make your speed drop. Your torrents choke their webpage browsing and youtube streaming, but with congestion control, it doesn't choke them as much. Is it perfect? Nope. Will it affect you negatively? Not really. I'd happily download 20% slower for 80ms ping instead of 2000ms. (and yes, it can get that bad when networks opt for low or no packet loss.)

      When there is no congestion, it has no effect, so most of the time you won't even notice it.

    5. Re:Clients already do this by Bengie · · Score: 1

      The difference is most other clients will throttle to best give *your* connection low latency. uTorrent is facing the other end of the problem. If a hop between you and the seeder is getting congested, uToerrent will throttle down as to help not overload that hop, Even if your connection is fine. The problem with P2P is that it eats up a very large portion of available bandwidth. If an ISP as a whole is getting bogged down, the downloaders will back off and try not to overload that ISP/Hop.

    6. Re:Clients already do this by mrbene · · Score: 1

      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

      This would show that the lag had increased (from n to n+200ms), but it would not be possible to solve directly for n. You'd need additional back and forth (in the vein of NTP) to establish a baseline value for n.

      Mind you, if you don't trust the network to be consistent, (or expect it to take longer in one direction than another) NTP doesn't work as well.

    7. Re:Clients already do this by Anonymous Coward · · Score: 0

      It doesn't need the absolute time value, only the relative time between each packet. As long as the receiver trusts the timestamps from the sender it can figure out the time difference between packet A to B being sent and them being received.

      Trusting the sender may not be a great idea, but I don't think it's exploitable to any benefit; it would just overload the pipe and normal TCP/UDP backoff procedure would kick in, which is the current norm.

    8. Re:Clients already do this by complete+loony · · Score: 1

      Sounds like the perfect solution to me. You don't need to know the actual latency. Instead as you increase your transmission speed an extra delay is added that your peer can tell you about, so you back off and speed up again with rules similar to TCP to try and stay near the sweet spot of your available bandwidth.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    9. Re:Clients already do this by Anonymous Coward · · Score: 0

      Congratulations on noticing that this is *not* TCP, but a UDP issue. However, you still fail: reset is inapplicable to UDP. You can drop a UDP packet so it never gets there, but reset is meaningless as UDP is sessionless.

      The problem with dropping UDP packets is that they still consumed the bandwidth getting to the point where they were dropped. Still, better than nothing for those with a need to apply traffic shaping rules. I don't live in my parents basement and am responsible where I work for traffic flow. You better believe we apply traffic shaping (sadly, only through dropped packets) and this has, in practice, greatly helped even out the bandwidth usage. P2P is, IMO, evil. The *only* people it is good for are the distributors -- it is far less efficient than any other file sharing protocol (that is, it consumes significantly more bandwidth to transfer the same number of bytes in a file), all the connections impose a significant burden on routing (many home/personal routers -- such as sold to consumers for use on cable -- roll over and then the user blames their ISP), and is predominately used to support copyright infringing activities.

      While I don't care so much for the last (I'd just as soon copyright and related imaginary property laws were abolished), it removes the moral high ground the proponents and defenders of P2P often try to take.

  12. We don't need more acronyms by Anonymous Coward · · Score: 0

    The problem is that we already have huge amounts of acronyms and they are confusing enough by themselves. We shouldn't add more when we don't need those.

    RTFM is an old, well known acronym. RTFA and RTFS can directly be led from it and TFA from those. Changing the pattern to just TA wouldn't win anything but it would add a new acronym when there is no need for such. (A quick google search showed that it means, among other things, Tera Ampere, Technical Assistance, Terminal Adapter... TFA has a lot less other meanings.)

  13. Next: ISPs develop automatic throttling... by Interoperable · · Score: 1

    Your router will throttle you, take your wallet and run.

    --
    So if this is the future...where's my jet pack?
  14. not the bandwidth it's the number of connections by Anonymous Coward · · Score: 0

    The problems are not with the bandwidth usage but with the shear number of connections being opened, if enough connections are there it can act like a DDoS.

  15. Intra-ISP by Anonymous Coward · · Score: 0

    Are any clients other than Azureus using tech which finds other people nearby, which tends to reduce traffic outside an ISP?

  16. Excellent idea by InsurrctionConsltant · · Score: 1

    Assuming the summary isn't completely wrong, this is an excellent idea. In the UK we are under severe threat of a draconian three-strikes law. This is without question due to the behind-the-scenes lobbying of the record and movie industries. And also, of course, the general attitude of compliance of the government towards those interests at the expense of the original, liberal copyright law that benefits culture and the public.

    Convincing the ISPs that the filtering/monitoring requirements of the draconian-copyright brigade are worse than having to deal with P2P traffic may be the only hope.

    Reference: TalkTalk will resist net piracy plans

    1. Re:Excellent idea by DrXym · · Score: 1
      Assuming the summary isn't completely wrong, this is an excellent idea. In the UK we are under severe threat of a draconian three-strikes law.

      In the long term, such laws are probably a good thing. They'll just advance the state of the art in p2p so that crypto, packet shaping, anonymous routing etc. becomes the default. Of course it won't prevent the RIAA sniffing traffic and attempting to make inferences but it will be much harder for them to prove their case.

  17. Much bigger issue with uTorrent still unsolved by bertok · · Score: 3, Interesting

    There's a much bigger issue with uTorrent that the developers seem to refuse to solve, or even acknowledge.

    In essence, uTorrent connects to clients randomly, and makes no attempt to prioritize "nearby" clients. This may not be a huge issue for Americans, but everywhere else, you know, like the rest of the fucking planet, this is hugely inefficient, for both the end users, and most importantly, ISPs. This is why they're throttling bittorrent: because it tends to make connections to peers outside the ISP's internal network, which costs ISPs money. In Australia for example, international bandwidth is extremely limited and very expensive, but local bandwidth, even between ISPs, is essentially unlimited, high-speed, and often free or 'unmetered'.

    What do you think is going to be faster: connecting to your neighbour through at the same fucking router, or some kid's home PC in Kazakhstan over 35 hops away? Even connections from here to America have to go through thousands of miles of fiber optic cable over an ocean.

    Note that some other clients like Azureus have already implemented weighted peer choices, where peers with similar IP addresses are preferred over other peers. It's not hard. Heck, it's a trivial change to make, as no changes need to be made to the protocol itself. A reasonably competent programmer could implement this in an hour: simply take the user's own IP address, and then sort the IPs of potential peers by the number of prefix bits in common, then do a random selection from that list, weighted towards the best-matching end. How hard is that?

    The arrogance of the uTorrent devs is simply staggering. They're a group of developers who could, with an hours effort, reduce international bandwidth usage by double-digit percentages and improve torrent download speeds by an order of magnitude, but they just... don't.

    1. Re:Much bigger issue with uTorrent still unsolved by Anonymous Coward · · Score: 0

      I read your post and, at first, entirely agreed with it. However, what if the devs deliberately want to keep this problem amidst to perpetuate a reason for ISPs to finally upgrade their infrastructure before further optimizing how the protocol works?

      If you take away reasons for them to upgrade, you're hurting their incentive to be pushed into doing it. Just a thought, despite being slightly paranoid...

    2. Re:Much bigger issue with uTorrent still unsolved by Anonymous Coward · · Score: 2, Interesting

      Prefix bits do not indicate location. 2 Class C's can be a long way from each other geographically. Even if the entire Internet was broken down into Class C spaces, and you prioritised addresses in your Class C, I don't think you would see many hits. I mean, there may be 50k people on the torrent, but how many of them are in the same neighbourhood as you?

      That's why the Vuze plugin uses a IP->location mapping database.

    3. Re:Much bigger issue with uTorrent still unsolved by dkf · · Score: 1

      I read your post and, at first, entirely agreed with it. However, what if the devs deliberately want to keep this problem amidst to perpetuate a reason for ISPs to finally upgrade their infrastructure before further optimizing how the protocol works?

      That's quite a retarded suggestion. Upgrading the link with the bottleneck requires a lot of investment (putting a new intercontinental fiber-optic line in isn't the same as digging up a few streets) so the ISPs are quite right to try to put it off as long as they can. It's not underinvestment, it's trying to make the existing investment work for its living properly. And the thing is... it does work for most since most people's network access is sporadic. It's the bulk downloaders that are the problem from the ISP's perspective, and the bulk uploaders too (since most people have asymmetric connections). Now, if the bittorrent users would switch to business-grade connections (i.e., ones that have balanced bandwidth at faster than modem speeds) then they'd be much less of a problem for everyone. But they won't, because they're cheap scum. (Well, a few might be non-scum, but they are definitely still cheap.)

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    4. Re:Much bigger issue with uTorrent still unsolved by Aladrin · · Score: 4, Insightful

      THEIR arrogance is astounding? How about yours? They are working FOR FREE. You are merely complaining. Get your hands dirty and start doing some work yourself.

      You can suggest things all you want, but once you start insulting someone for their free work, you've crossed a line. Nobody is forced to use their client. There are dozens of decent clients and probably hundreds of open source ones.

      As for their choices, they will work on what's more important to them, I'm sure. Since they don't need this 'local' feature, they haven't got much incentive to actually work on it.

      --
      "If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
    5. Re:Much bigger issue with uTorrent still unsolved by c0d3g33k · · Score: 1

      Keeping traffic completely local would make it much easier to snag a bunch of file sharers in a massive "three strikes and you're out" campaign, don't you think? Since mere use of torrent software seems to be associated with illicit activity in the minds of the ignorant (ie. the authoRIAAties), I'm not sure that "I was just downloading the latest Ubuntu ISO" would be enough to avoid being threatened by the ISP. Lots of local inter-ISP torrent traffic might also cause them to alert local law enforcement to take a closer look. This could increase one's risk significantly, particularly if any 'infringing' content is ever shared (by an occasional, less enlightened, user of the connect, for example). Seems safer to not have to worry about local/non-local bandwidth, to be honest. Might be smarter to prefer connections that are as non-local and non-concentrated as possible. It's not always just about data transfer speed and bandwidth saving - there are other factors to consider.

    6. Re:Much bigger issue with uTorrent still unsolved by evilviper · · Score: 5, Insightful

      In Australia for example, international bandwidth is extremely limited and very expensive, but local bandwidth, even between ISPs, is essentially unlimited, high-speed, and often free or 'unmetered'.

      No bittorrent client picks one peer, and downloads everything from them... Instead, it connects to a large number of peers, and downloads from all of them.

      If you can download from your neighbor 100X faster than you can download from someone across the planet... good. You'll get 100 chunks from your neighbor, for every 1 you get from the foreign country. No programming required.

      What do you think is going to be faster: connecting to your neighbour through at the same fucking router, or some kid's home PC in Kazakhstan over 35 hops away?

      There's ample opportunity for either to be equally fast. Crossing an ocean increase latency, but if the link isn't horribly oversubscribed, can provided speeds faster than you can handle. So, your neighbor might have 100 other people requesting the same torrent as you, for the same reasons, while the kid in Kazakhstan may have a great internet connection, which is barely being utilized, and this while international traffic is down. This is not international calling... you don't save money by not fully utilizing that transoceanic link.

      Also, ISPs brought this on themselves. I've long advocated ISPs allowing unlimited speeds between subscribers, and only limiting the uplink speeds to whatever you've subscribed, but they almost never do. If they did, see above... any peer-to-peer protocol would naturally download almost everything from local sources, without any added intelligence on its part. You wouldn't have to write it in to every single app.

      A reasonably competent programmer could implement this in an hour

      You could implement it easily, if you're willing to restrict yourself to neighboring network addresses in lieu of all else. If you want some fancy weighting to decide how important locality is versus absolute speed, completeness, etc. then you're talking about a major project.

      Besides that... A good network admin could do the job in an hour as well, with no need to rewrite any of the applications.

      They're a group of developers who could, with an hours effort, reduce international bandwidth usage by double-digit percentages and improve torrent download speeds by an order of magnitude, but they just... don't.

      That's baseless and utterly ridiculous.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    7. Re:Much bigger issue with uTorrent still unsolved by bertok · · Score: 4, Insightful

      THEIR arrogance is astounding? How about yours? They are working FOR FREE. You are merely complaining. Get your hands dirty and start doing some work yourself.

      You can suggest things all you want, but once you start insulting someone for their free work, you've crossed a line. Nobody is forced to use their client. There are dozens of decent clients and probably hundreds of open source ones.

      As for their choices, they will work on what's more important to them, I'm sure. Since they don't need this 'local' feature, they haven't got much incentive to actually work on it.

      First of all, they're not working for 'free', uTorrent is owned by BitTorrent Inc, a for-profit company. Initially it was free, but it's now developed by a corporation. Those devs are salaried employees.

      More importantly, uTorrent depends on and uses infrastructure that is not free, by any stretch of the imagination. International links are $billions expensive.

      So by your logic, just because a user can download their client for free, it gives Bittorent Inc carte blanche to do anything at all they want, including shit all over the internet infrastructure?

      How the fuck does it make sense for a company who's product uses something like 30% of the total internet bandwidth to not make an hours worth of effort to minimize their impact on said infrastructure? Their product in its present state is so harmful that ISPs are buying millions of dollars worth of equipment to throttle it, and with good reason.

      Read up on the Tragedy of the Commons and get a clue.

      Compare their behavior to the largely free, open, and volunteer efforts of the dedicated people who worked on the early Internet protocols like DNS and NNTP. These were systems designed to scale, use bandwidth efficiently, and 'play nice'.

      What happened since then? Why is it acceptable now to design a protocol that is maximally inefficient? Why would anyone support this kind of behavior?

    8. Re:Much bigger issue with uTorrent still unsolved by bertok · · Score: 2, Insightful

      Prefix bits do not indicate location. 2 Class C's can be a long way from each other geographically. Even if the entire Internet was broken down into Class C spaces, and you prioritised addresses in your Class C, I don't think you would see many hits. I mean, there may be 50k people on the torrent, but how many of them are in the same neighbourhood as you?

      That's why the Vuze plugin uses a IP->location mapping database.

      True, but it's still better than random. Many countries were allocated IP blocks from large ranges. Most of Australia's IP addresses start with prefixes around 200-something, for example. Similarly, most ISPs have large blocks allocated to them like /8 ranges or the like. Some ISPs are big enough that torrent users could have 10 or more connections to peers in the same ISP for reasonably common files like TV shows, and only need 1 or 2 to the outside world.

      Still, you're correct, adding even a simple country database would help a lot. There's easily obtainable databases of "AS" numbers that map IP ranges to organizations and/or countries, and embedding that into the client would also be a fairly simple exercise.

    9. Re:Much bigger issue with uTorrent still unsolved by bertok · · Score: 2, Insightful

      Keeping traffic completely local would make it much easier to snag a bunch of file sharers in a massive "three strikes and you're out" campaign, don't you think? Since mere use of torrent software seems to be associated with illicit activity in the minds of the ignorant (ie. the authoRIAAties), I'm not sure that "I was just downloading the latest Ubuntu ISO" would be enough to avoid being threatened by the ISP. Lots of local inter-ISP torrent traffic might also cause them to alert local law enforcement to take a closer look. This could increase one's risk significantly, particularly if any 'infringing' content is ever shared (by an occasional, less enlightened, user of the connect, for example). Seems safer to not have to worry about local/non-local bandwidth, to be honest. Might be smarter to prefer connections that are as non-local and non-concentrated as possible. It's not always just about data transfer speed and bandwidth saving - there are other factors to consider.

      [citation needed]

      Keep in mind that in large part, the motivation of ISPs for monitoring or throttling bittorrent is not concerns over copyright violations, but the impact to their bottom line. All ISPs have three classes of links: Internal, peered, and external. They have a strong preference to maximize the utilization of the former over the latter, as internal links are effectively free and often underutilized, while external links are often very expensive and overloaded.

      If torrent traffic utilized internal connections much more than external connections, ISPs wouldn't be financially motivated to monitor at all, because monitoring equipment is expensive. Right now, monitoring and throttling is worth it, because bittorrent tends to use external links the majority of the time.

      In effect, improving efficiency would improve security.

    10. Re:Much bigger issue with uTorrent still unsolved by Anonymous Coward · · Score: 0

      I agree, I see other peers on the same ISP as me and others on another ISP which the ISP are also based in the same city as me and yet it doesn't connect to them.

      Coding a way so you can manually prioritise that peer or domain would be easy to do.

    11. Re:Much bigger issue with uTorrent still unsolved by Anonymous Coward · · Score: 0

      Why would anyone support this kind of behavior?

      Because I do not want to make to job of MAFIAA any easier.

    12. Re:Much bigger issue with uTorrent still unsolved by Anonymous Coward · · Score: 1, Interesting

      This has been a problem since day one. Since dial up to BBS's. However, this is also the same reason we have 8Mb/s-100Mb/s connections today. I was considered a heavy user back in the day when I wanted to send some digital pictures to a friend many states away. Dialup wasn't alway 64k, and was never 64k up. I had 300bps initially. It took a very long time to send digital pictures, though not as long as the post.

      That was once considered abuse. Now no one cares that I have a lot of digital pictures I send. The ISPs don't care, and MySpace and Facebook make it free to share these with family.

      Once it was floppy disks, then CDs, today it is the sharing of DVDs. It will not end, and it will drive the increase in total bandwidth. ISPs should be able to prioritize this traffic. The current encryption and obfuscation used by many P2P clients means the only way to detect it is by detecting SSL on ports other than 443 which have invalid certificates. This makes difficult to control unless you have quality equipment. Bittorrent is much easier to control. The developers are helping with prioritization which is a good thing. More needs to be done. I do the QoS for a "free" campus type hot spot with 100Mb/s of Internet connection and lots of users. We pay based on usage. When someone kicks in a big P2P session, it is very noticeable. Should I kick him off, or QoS him, or pay thousands of dollars a month extra to let him do "free" P2P? QoSing that P2P Ubuntu up/download seems to me to be the right thing to do.

      At home, using DD-WRT I'm able to prioritize things. I can have a Mozy backup going full speed now without it affecting my Netflix or Hulu. Before I did QoS, the Mozy upload would cause major problems with these services due to up link congestion.
       

    13. Re:Much bigger issue with uTorrent still unsolved by bertok · · Score: 0, Troll

      Why would anyone support this kind of behavior?

      Because I do not want to make to job of MAFIAA any easier.

      You do realise that the RIAA and the MPAA represent Recording Artists and Movie Producers, respectively, right?

      Neither group are ISPs. Neither invest billions into internet infrastructure.

      If peer-to-peer users would just play nice and use the ISP infrastructure efficiently, then maybe the ISPs wouldn't be so inclined to side with the content producers.

      You might even find that if digital content distribution is done right, then the ISPs might start to push for laws similar to the "copyright tax" on writeable media to allow their users to legally download content.

    14. Re:Much bigger issue with uTorrent still unsolved by JackSpratts · · Score: 1

      holey moley. the percentage of bits devoted to file sharing is dropping fast. urgent media company/isp press releases notwithstanding, total bandwidth consumed by peer-to-peer file sharing is now under 20%. this includes all protocols. bittorrent will of course be less. the precipitous share decline has caused at least one observer (sandvine's dave caputo) to comment that "peer-to-peer is yesterday's internet story." all the more startling coming from that outfit, a company whose controversial history suggests a vested interest in obscuring such trends.

      btw, you're right that utorrent doesn't pay for the bandwidth but wrong about who does. those billions in infrastructure mods are underwritten by me, and every other consumer employing the app, and these days the isps we subscribe to aren't terribly worried about bt, if they ever really were. they're much too concerned about streaming video.

      - js.

    15. Re:Much bigger issue with uTorrent still unsolved by bertok · · Score: 1, Insightful

      Your post is precisely what is wrong: It's all about what you get out of an individual download.

      Not everything in the world is about directly maximizing YOUR OWN PERSONAL BENEFIT. More importantly, you can actually improve your own personal speeds by cooperating. Read up on the Tragedy of the Commons. If many players all blindly try to maximize their personal utilization of a common resource, they all suffer as an aggregate.

      This is particularly true of peer-to-peer protocols, which are ideally placed to utilize otherwise wasted local bandwidth. I've read papers that show that an efficiently designed P2P protocol can actually maximize the return on investment of a switched network, a feat that essentially no other type of protocol can achieve, largely because a well designed P2P protocol can minimize the amount of data flowing through inter-network or international links.

    16. Re:Much bigger issue with uTorrent still unsolved by bertok · · Score: 2, Insightful

      I agree, I see other peers on the same ISP as me and others on another ISP which the ISP are also based in the same city as me and yet it doesn't connect to them.

      Coding a way so you can manually prioritise that peer or domain would be easy to do.

      I see this all the time too. It shits me to no end that I could be connecting to users with 10Mbit uplinks in the same city, but uTorrent blindly connects to peers in places like Hungary which is almost precisely the furthest possible distance from me.

    17. Re:Much bigger issue with uTorrent still unsolved by evilviper · · Score: 2, Interesting

      Your post is precisely what is wrong: It's all about what you get out of an individual download.

      You have utterly and totally failed to understand the content of my reply. I suggest you try again.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    18. Re:Much bigger issue with uTorrent still unsolved by maj1k · · Score: 1

      would you care to provide links to these papers? i'm sure you've read quite a few that back this up otherwise you wouldn't be arguing this position.

    19. Re:Much bigger issue with uTorrent still unsolved by crossmr · · Score: 1

      you say it doesn't, but I say it does
      on private tackers I'm routinely shunned, even as the initial seed as soon as other seeds become available that are very likely geographically closer.

      Almost every torrent I've added to private trackers shows a consistent max up speed until someone else hits seed and then my up basically stops. Fine when I'm the initial seed, terrible if I'm just jumping on a random torrent since 95% of the people out there won't take anything from me. I've seen plenty of people on the same trackers making the same complaint. utorrent is making decisions about that somehow already.

    20. Re:Much bigger issue with uTorrent still unsolved by Splintax · · Score: 1

      There's easily obtainable databases of "AS" numbers that map IP ranges to organizations and/or countries, and embedding that into the client would also be a fairly simple exercise.

      In fact, Torrent already has this feature: if you look at the 'Peers' tab, it'll try to work out what country each peer comes from and display an appropriate flag just to the left of the IP. All that's needed is an option to allow the user to prioritize connections to peers from the same country.

    21. Re:Much bigger issue with uTorrent still unsolved by cerberusss · · Score: 1

      A reasonably competent programmer could implement this in an hour

      I don't agree or disagree with the rest of your statement, but these kinds of statements really bother me.

      A reasonably competent plummer could fix my sink in an hour. I'm not counting the time he has to drive to me, the time it takes to fetch repair parts, the time it takes to talk with me, the time it takes to write me a bill, and the time to get me to pay said bill because I store bills in a drawer that gets opened every month or three.

      Do I need to explain to you that your pet bug does not take an hour to implement? But instead will probably take a week?

      --
      8 of 13 people found this answer helpful. Did you?
    22. Re:Much bigger issue with uTorrent still unsolved by cbraescu1 · · Score: 1

      but uTorrent blindly connects to peers in places like Hungary which is almost precisely the furthest possible distance from me

      What about Albania, you insensitive clod...

      --
      Catalin Braescu
      Ofaly.com
    23. Re:Much bigger issue with uTorrent still unsolved by stephanruby · · Score: 1

      There's a much bigger issue with uTorrent that the developers seem to refuse to solve, or even acknowledge.

      This issue has been fixed since version 1.7x.

      One of the features that I've been anxiously awaiting is the "Local Peer Discovery" feature in uTorrent 1.7x. Basically, it uses a multicast to discover bittorrent clients that are active on your local network. It can determine if they are seeding or leeching a torrent that you're interested in. If it's available on the network, it will try to use it as a peer, and download it at massive speeds.

      [...]

      I can think of a couple of really great uses for this. The first is a scenario that I run into at work occasionally. I'll try to download a video or file that a co-worker wants to see as well. Instead of competing for bandwidth, we can now both download it at the same time, and share the pieces quickly and automatically.

      The other great use that I'm really excited about is LAN parties. For those of you that don't know, a common LAN party problem is that everyone wants to get a copy of a game off of one computer. Everyone tries to copy it at one time, effectively rendering the network and the hard drive useless. The current solution is to copy it to some computers, and then have people get it from the copies. It works, but it's manual, and it's not fun.

      ...

      You can also do it this other way if you want.

      enable peer.resolve_country

      And then, there is always PeerGuardian if you're looking for something else still.

    24. Re:Much bigger issue with uTorrent still unsolved by Anonymous Coward · · Score: 0

      Sure, but GP has a point: giving preference to local peers does enable non-ISP organizations (i.e. RIAA, BREIN, MPAA et al.) to set up a couple of nodes in any given ISP they want to target and have a bunch of nice, easy, within-their-jurisdiction targets contact them directly instead of having to scrape torrent announcements for IPs (which, for some trackers, can be spoofed/poisoned with false IPs, allowing plausible deniability). Also, have into account that traffic that occurs between "end-user ISPs" is what actually drives peering agreements between those ISPs; if no one uses anything besides local P2P and youtube/facebook/google, "end-user ISPs" have no incentive to peer with any networks other than CDN and webhosting ISPs.

      tl;dr: although you do have a point, assigning preference to local peers is not without disadvantages.

    25. Re:Much bigger issue with uTorrent still unsolved by bertok · · Score: 1

      would you care to provide links to these papers? i'm sure you've read quite a few that back this up otherwise you wouldn't be arguing this position.

      I only have vague memories of reading some related stuff a while back (I'm not exactly keeping tabs of this stuff for research or anything), but I remember that there was a Slashdot post a while back about this paper from Microsoft Research:

      Network Coding for Large Scale Content Distribution
      http://research.microsoft.com/pubs/67246/tr-2004-80.pdf

      It basically says that there's an even more efficient form of P2P, where the blocks are optimally encoded using something akin to a huge "RAID 5" type parity algorithm, so that every peer can help every other peer, immediately. From what I gather, this doesn't quite work in practice, not just because of the computational requirements, but because this algorithm has issues with untrusted peers -- users can only validate complete files, or something like that. The Slashdot post where it was mentioned had some good discussion and links to P2P design and issues, and I believe one or two developers who've worked on well-known P2P systems chimed in with some good points. One guy mentioned that the reconstitution algorithm thrashes the disk, for example.

      From the reading I've done, it looks like traditional P2P (random block exchange) is surprisingly good, as long as the peers are chosen well. I actually studied some P2P protocols at work as a potential method for distributing files to an enterprise with thousands of sites, but I couldn't find any at the time that could be embedded into a larger systems as a module and could make intelligent peer choices. Most of the ones I tried kept chewing up WAN bandwidth instead of preferring local LAN bandwidth. Note that uTorrent does detect peers on the same subnet, but not adjacent subnets.

      I can't find the link any more, but I remember that there was a paper recently that proved mathematically that certain types of data transfer mechanisms like client-server can never utilize more than a certain percentage of the total theoretical bandwidth of a network like the internet, but P2P does a lot better, and P2P with network coding is basically optimal, or close to it, but still not 100%.

    26. Re:Much bigger issue with uTorrent still unsolved by bertok · · Score: 1

      Also just found another one, but this is a bit heavy on the maths:

      Network information flow - R Ahlswede, N Cai, SYR Li, RW Yeung, 2000
      http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.89.4568&rep=rep1&type=pdf

      I think this was the original paper that pointed out that it's possible to exceed the naive "optimal broadcast" efficiency of a single source on a switched network, by allowing intermediate nodes to perform some computation.

      Mind you, this is only tangentially related to current P2P systems, but it's still interesting.

    27. Re:Much bigger issue with uTorrent still unsolved by Inda · · Score: 1

      If ISPs want to keep their traffic local they should own a large server with massive storage for their users. Maybe have a file retention of 10 days to keep the size down. Maybe sell extra retention time to users who want it. Imagine the download speeds when connected to your ISP, who might only be 5 hops away! Imagine not having to upload anything either!

      If only ISPs bought into this model, we'd all be sorted.

      I'm surprised no universities have experimented with something like this already.

      (I know the first rule, I know it used to happen like this, I know ISPs are stupid as mud)

      --
      This post contains benzene, nitrosamines, formaldehyde and hydrogen cyanide.
    28. Re:Much bigger issue with uTorrent still unsolved by daid303 · · Score: 1

      Local peer discovery only finds peers on my local network, not on near networks.

    29. Re:Much bigger issue with uTorrent still unsolved by mahadiga · · Score: 1

      And source code of uTorrent is NOT open.

      --
      I'd like to buy homeland for our 10 million people. http://twitter.com/mahadiga
    30. Re:Much bigger issue with uTorrent still unsolved by BForrester · · Score: 1

      Azureus has the Ono Plugin that you might want to try. It uses CDN redirection information to identify and give connection priority to geographically nearby peers. I haven't heard of any similar efforts for other clients.

      http://azureus.sourceforge.net/plugin_details.php?plugin=ono

    31. Re:Much bigger issue with uTorrent still unsolved by Hatta · · Score: 2, Insightful

      Get your hands dirty and start doing some work yourself.

      Sure, where can I get the uTorrent source code so I can add this feature?

      --
      Give me Classic Slashdot or give me death!
    32. Re:Much bigger issue with uTorrent still unsolved by Anonymous Coward · · Score: 0

      I dont know, i dont seem to have any problems connecting to bittorrens on remote island countries. Then again, if everyone had 26 MBps up/down, like I do, well, there wouldnt be much of an issue....

    33. Re:Much bigger issue with uTorrent still unsolved by Anonymous Coward · · Score: 0

      Write an extension for a FOSS client, or quit whining.

      > This may not be a huge issue for Americans

      Right, because it isn't 35 hops when Americans connect to some PC in Kazakhstan. I have no idea why you think this doesn't happen often, because it does.

      You dare to accuse others of arrogance? Re-read your post, and then get over yourself.

    34. Re:Much bigger issue with uTorrent still unsolved by Aladrin · · Score: 1

      My mistake, it's no longer open source. It is still free, though, and your demands don't mean jack.

      And what gives them the right to do whatever they want is that it's THEIR PROTOCOL. You are perfectly free to invent your own, more efficient protocol. And if it really -is- better, people -will- switch to it. Why? Because people are impatient and want their files as quickly as they can get them.

      As for 'maximally inefficient', it is anything but. Most clients implement algorithms to determine the fastest way to get the data. That will usually mean that staying within your own country is best since that will get you the best speeds. That's actually pretty close to what you're looking for, anyhow, isn't it?

      Now, even if BT, Inc implemented a protocol that chose in-country peers first, the majority of the clients out there are going to futz around with it until they get the best speed again. The new protocol isn't going to do jack.

      --
      "If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
    35. Re:Much bigger issue with uTorrent still unsolved by Anonymous Coward · · Score: 0

      My mistake, it's no longer open source.

      Another mistake, albeit a lesser one. You see, it was never open source. Ever.

      You really should check your facts better. It makes it much easier to take whatever else you write seriously. As it is now, I really don't know what to think about anything you write, at all. I'm assuming that you want to be read, here. If you don't, then carry on as you are.

    36. Re:Much bigger issue with uTorrent still unsolved by bill_mcgonigle · · Score: 1

      In essence, uTorrent connects to clients randomly, and makes no attempt to prioritize "nearby" clients.

      You might be interested in this thread I started on the topic in '05 - it covers some pros and cons. My intent at the time was to avoid the whole problem we wound up with at Comcast (that took the FCC to fix). Somebody mentioned to me once that there was a problem with traceroute on Windows, not sure if that's really true.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    37. Re:Much bigger issue with uTorrent still unsolved by stephanruby · · Score: 1

      Local peer discovery only finds peers on my local network, not on near networks.

      Agreed, but I was responding to one of his hypothetical hyperbolic scenarios: "connecting to your neighbour through at the same fucking router". The problem is definitely not as bad as the parent originally made it sound.

      In any case, it does sound like my second suggested solution would work for his case, flipping the peer.resolve_country variable to true. Granted, he would have to flip that flag, and come back the next day to make sure all his torrents have an Australian peer. If a torrent he really wanted didn't have an Australian peer, then he would have to manually set that flag back to false. It's a pain, but it's definitely doable.

    38. Re:Much bigger issue with uTorrent still unsolved by stephanruby · · Score: 1

      A reasonably competent programmer could implement this in an hour: simply take the user's own IP address, and then sort the IPs of potential peers by the number of prefix bits in common, then do a random selection from that list, weighted towards the best-matching end.

      It sounds like this scheme would wreak havoc on the stats kept by private trackers, definitely not a one hour job.

    39. Re:Much bigger issue with uTorrent still unsolved by Anonymous Coward · · Score: 0

      So by your logic, just because a user can download their client for free, it gives Bittorent Inc carte blanche to do anything at all they want...

      Bittorrent Inc isn't doing anything. Users are doing it. They're just providing the tools.

  18. ISPs don't give a crap by 7-Vodka · · Score: 2, Interesting

    Furthermore, the revision is designed to eliminate the need for ISPs to deal with problems caused by excessive BitTorrent traffic on their networks

    How wrong this is. ISPs don't give a crap about this and it's never going to work.

    1. They don't give a crap because the real reason they throttle is because they don't want you using your bandwidth. You know the bandwidth you actually paid for. Whether you are supposedly clogging up their pipe or not is not the point. The point is that you are using more bandwidth than another user and they could kick your ass and sell their internets to 1000 old ladies instead.

    2. It's never going to work because of (1) and because the problem it's trying to solve was never a problem for the ISP it was always a problem for the end user anyway. You think that the ISPs have big download pipes and small upload limits like you do? They don't. Their shit is equilateral. You can stop clogging your tiny upload allocation as much as you want, it's never going to affect the ISP. They never had an UP shortage because they have equal up/down bandwith and provide you with tiny up limits. It may help the end user, but only if it's already better than existing solutions, which if you already know what your ISP castrates your up bandwidth to, it's not.

    --

    Liberty.

  19. Proximity Favored Connections by JakFrost · · Score: 2, Interesting

    Ono Plug-In

    You're absolutely right about how badly implemented the random client connection protocol is for BitTorrent clients. There is a project and a plug-in called Ono for Vuze (formely Azureus) BitTorrent clients. I used it before to resolve this problem but I found that the non-stop creation of many ping.exe threads to analyze latency was causing some slow-downs on my own system and additional upstream congestion on my upstream limited broadband pipe.

    I am still surprised that a better protocol for proximity favored peer connections wasn't developed for BitTorrent and other P2P systems to maximize performance by connecting to peers on the same or close-by networks. I have a feeling that with the huge increases in demand for content there will be a need for optimized connection protocols once we start demanding more than the capacity that we have.

    Netmask Flaws

    One solution that is simple to implement is the one that you mentioned for netmask calculations but I fear that this is solution won't work reliability since the way that network ranges are created and managed internally by large broadband ISPs is unpredictable and neighboring ranges are owned by different ISPs or are in other countries. Plus netmask information doesn't tell you anything about closest neighbors to connect to once you exhaust the connections in your own netmask.

    Routing Table Solution

    I think that the best solution would be one based on information in the routing protocols that the routers have but since this information is not available to the individual clients the applications have no way of looking at the overall routing structure to determine exactly who the closest and best neighbors. are based on latency, bandwidth, cost, and hop count information.

    If there was a way for the application to query the router for a partial list of the routing table (e.g. 5 or 10-hops) and then prioritize the peer addresses from the tracker according to the routing table based an algorithm that takes bandwidth up-and-down, latency, cost, and hop count into account we would have an optimal solution to the order of connections for peers.

    Latency and Hop Count Not Enough

    The problem is that the routers won't share the routing table information with the clients. The solution becomes the one like Ono plug-in in that the client has to ping and/or trace route to the peer addresses to determine optimal choices based only on latency and hop count without knowing anything about bi-directional bandwidth availability or cost associated. Without the bandwidth info the whole thing falls apart because latency isn't enough to determine maximum throughput and there is no practical way of doing a bandwidth check bi-directionally in a meaningful way between peers without taking up a lot of time and bandwidth in the process itself.

    Upstream Throttling (Not Choking)

    Hopefully, this new uTP protocol will at least give us a benefit and improvement on the upstream bandwidth side by auto-throttling the upstream to prevent choking the connection.

    If only the clients could peek at the routing tables of our routers...

    1. Re:Proximity Favored Connections by bertok · · Score: 1

      It doesn't have to be reliable, it just has to be better than "totally random". Even a very bad peer selection policy would be a HUGE improvement over what they have now.

    2. Re:Proximity Favored Connections by Anonymous Coward · · Score: 0

      wut?

      Netmask Flaws - I guess you are talking about cidr? Not really sure. You say netmask which implies that you may actually be talking about a broadcast domain; but the rest of your comment speaks to an allocation. eg: If your ISP has a /8 then you will not be using 255.0.0.0 for your netmask - and if you are then run away from them as quickly as possible.

      Routing Table Solution/Latency and Hop Count Not Enough - This _IS_ published data. This information is in BGP and you may query many different databases (route-views, bgplay, et al). If your ISP does not have a looking glass then you should stir the waters until you find a clueful network engineer that can hook you up. You may find remote nodes that are within 5 hops by simply looking at the TTL, which is very very simple math.
       
      - And, ohhh, come on now. Companies like Internap, and others, have products that do this for policy based routing. These network appliances, such as the FCP, send out hundreds of thousands of packets per second. I do not think that you really want to be doing this. :)

      Just mirror the Routing Registries at a central site, create a sqlite database and distribute daily via some sort of distributed method(heh) for a very broad policy, pad on TTL, pad on latency(adjusting over time), attempt to pad on ptr rr(lower metric), do the hokey pokey...

      Oh, well, hell.

    3. Re:Proximity Favored Connections by bytta · · Score: 1

      How about adding "favorite netmasks", where you can (manually) give extra priority to some netmasks that you know are near you (by looking at the country flags in bittorrent, random guessing, or by downloading lists off the intertubes). Wouldn't that solve 99% of your problem?

    4. Re:Proximity Favored Connections by emarock · · Score: 1

      I am still surprised that a better protocol for proximity favored peer connections wasn't developed for BitTorrent and other P2P systems to maximize performance by connecting to peers on the same or close-by networks.

      It is actually being developed, in the IETF ALTO working group. And BitTorrent Inc. is actually an active contributor of the current draft.

  20. route around the problem by Tumbleweed · · Score: 2, Insightful

    Get a seedbox. :)

    1. Re:route around the problem by mister_playboy · · Score: 1

      You're still gonna need a torrent client to run on that seedbox.

      --
      Do what thou wilt shall be the whole of the Law ::: Love is the law, love under will
  21. TcpAckFrequency allows more traffic by u64 · · Score: 1

    Slightly Offtopic. But here's how to get smoother and faster
    traffic. So that Upload distrupt Download far less.

    [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\parameters]
    "TcpAckFrequency"=dword:9

    dword:d also works. But above that things probably becomes too smooth.

    Compare the 'Before' and 'After' real-world download speeds.
    Especially how online gaming and interactive things behave.

    Linux dont seem to have this tweak. Right?

    1. Re:TcpAckFrequency allows more traffic by Slashcrap · · Score: 0, Flamebait

      [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\parameters]
      "TcpAckFrequency"=dword:9

      Linux dont seem to have this tweak. Right?

      You are unbelievably fucking stupid.

      Now, please explain in detail exactly how the tweak you are suggesting works, and include enough information on the various TCP congestion avoidance algorithms to make it clear that you know what you're talking about. You absolute fucking twat.

  22. This is not new by Anonymous Coward · · Score: 0

    Azureus has been doing this for years. There are actually three built-in methods (only one of which I find effective).

  23. Already been done... by Anonymous Coward · · Score: 0

    Azureus aka Vuze has had this in for a long time now. Why is it such big news?

  24. Anyone else see 60 Minutes tonight? by Luke+has+no+name · · Score: 1

    What a crock. Objectively biased, and subjectively a crock of shit.

    http://www.veoh.com/collection/CBS-60-Minutes/watch/v19306351MbfMTNw4

    Watch starting at 4:25:

    "Gee whiz technology called Bit - torrent"

    This shows who is influencing the discussion on piracy, and how the movie industry is trying to demonize it by that woman Leslie Stall acting shocked and appalled at everything "He brought his CHILDREN to the theatre while committing this crime?" [taping a movie at the theatre]. Comparing pirates to drug dealers, child sex freaks, etc. The one credit the report has is that it mentioned that Bittorrent clients are legal. Also, some director guy admitted that the only thing that can be done in the fight against piracy is to slow it down; it's not a winnable war for the movie industry.

    Just thought it was a really shitty show that deserved mentioning. Andy Rooney was spot on in his article, though.

    1. Re:Anyone else see 60 Minutes tonight? by Anonymous Coward · · Score: 0

      Funny, I thought most Slashdotters were against counterfeiters getting rich off of copyrighted material. Anyway, I watched it and it seemed like a pretty good program. Then again, pirates are self-centered scumbags, so I'm not surprised you are unhappy with them presenting the facts.

    2. Re:Anyone else see 60 Minutes tonight? by awall222 · · Score: 1

      Thought the demonstration of BT was interesting (at ~5:00): "...and you're downloading the movie right now?" "that's right" "the bits moving away...are pieces we have and are sharing with someone else." So CBS was participating in the very activity their program was out to show is illegal...interesting.

    3. Re:Anyone else see 60 Minutes tonight? by Luke+has+no+name · · Score: 1

      No, AC, it is not the facts I'm unhappy to see. It is the comically pathetic journalistic bias and melodrama the report had. Might as well have been an infomercial for the MPAA.

  25. I always wondered.... by Wescotte · · Score: 1

    If services like Hulu/Netflix could effectively use multicast.. Say they made users wait up to 60 seconds or so.. In that time it would generate a list of users attempting to view the same content. Once a certain threshold of X users is hit (or 60 seconds is up) it begins streaming the content.

    Chances are on a popular service there will be a significant amount of people attempting to view the same thing at relatively the same time. This way you can at least reduce some of the bandwidth.

    Anyone else heard of any services working like this? Or do they actually do this now? I've never really used Hulu or really any streaming services. I'd use Netflix's but they don't offer linux support yet..

    1. Re:I always wondered.... by Anonymous Coward · · Score: 0

      Anyone else heard of any services working like this?

      Proxy?

  26. Proposed solution by Erik+Corry · · Score: 1

    I agree that this is a huge problem with BitTorrent. The calls for the preservation of net neutrality should go hand in hand with efforts to fix the one protocol that is causing most pain for ISPs. BitTorrent is 'efficient' from the point of view of the person hosting (seeding) the content. That's great, especially if the hoster isn't making any money from hosting (perhaps because they don't own the rights!). But from the point of view of the ISPs bittorrent is horrendously inefficient, sending the same file fragments across expensive undersea connections again and again.

    I think any solution is going to involve the ISPs proving some way for the Bittorrent client to judge the proximity (in terms of $$) of a peer. Since the ISP controls your DNS that could be as simple as downloading an XML file from a server with a fixed name. Eg http://network-config/proximity-ipv4.xml

    It could be implemented in clients now. If it was enabled by default I think ISPs would soon start providing the info. There's money involved after all. It would probably improve download speeds too!

    1. Re:Proposed solution by bertok · · Score: 1

      It wouldn't even require the cooperation of ISPs.

      As the AC post just above yours pointed out, it's fairly simple to scrape this information from a wide variety of sources. It would be sufficient for someone to update a simple table once every few months. Even if it was baked into the uTorrent executable, it would get updated reasonably often along with the regular point releases.

      Keep in mind also that most P2P clients represent a large set of distributed cooperating applications that could analyze and monitor the internet from "their perspective" and exchange routing efficiency data.

      Perfection is not only not required, but not useful, because some randomness is still required to ensure that the P2P mesh is robust in the face of a partial failure somewhere.

    2. Re:Proposed solution by Erik+Corry · · Score: 1

      The relevant information is the cost to the ISP. It's using that information that will help protect network neutrality. You can't scrape that from anywhere. What the torrent client does with that information is then the next issue. I can see that introducing an element of randomness may be useful.

      Note that my suggesting is very simple to implement and costs nothing at run time (one failed or succeeded http request). If it turns out that the ISPs don't implement their side of it then that a) gives you an argument against them in the net neutrality debate and b) doesn't stop you going crazy with the heuristics.

    3. Re:Proposed solution by bertok · · Score: 1

      I assure you that I can maintain my grip on my sanity even in the face of the most advanced heuristics! 8)

  27. uTP's value is dubious. by Anonymous Coward · · Score: 0

    If you read the RFC-like document (http://www.bittorrent.org/beps/bep_0029.html) you'll see they're trying to implement their own TCP-like transport protocol over UDP. Why they will do a better job than TCP, or speed-limiting functionality in existing BT clients is unclear; they have no data nor have they published any technical papers for anyone to review.

    It's also not true that this is a new implementation of the BitTorrent protocol. TCP Vegas was a new implementation. This is a new protocol because it breaks compatibility.

    What's more, as broadband speeds and availability continue to grow, network management will only become more important. Consumers are increasing their bandwidth utilization, and ISP's will continue to react. BitTorrent is only the first symptom. Good network providers will continue to invest in tools for analyzing their network, whether or not they desire to shape it.

  28. Users don't need this protocol by raynet · · Score: 1

    I think it is somewhat pointless to throttle the speeds beyond your connection to the ISP. Usually (always?) your upload bandwidth is the limiting factor. Azureus has had a autospeed plugin for ages that monitors your latency and adjusts the upload speed based on that. It is responsive enough to detect when you are watching streaming video etc and lower the upload speed when needed. And just to spite the ISP I usually make Azureus (not rTorrent) to open 4000+ connections and run 10-100 torrents simultaneously just to make sure I get to use all my bandwidth I pay for :)

    --
    - Raynet --> .
  29. It's on their TODO list... by bytta · · Score: 1

    As claimed by an admin in the forums a similar feature (manually marking some peers/IP ranges as local) is on the todo, but it's been pushed back repeatedly.

  30. Already solved. See: BitTyrant. by Civil_Disobedient · · Score: 1

    BitTyrant does something like this. Essentially it prioritizes connections to peers that have the best response rates.

    In essence, uTorrent connects to clients randomly, and makes no attempt to prioritize "nearby" clients.

    The problem isn't simply proximity. If, for example, Kazakhstan upgraded their capacity and you really could get better transfer speeds than, say, your neighbor next door, well then they should be prioritized.

  31. Watch Dollhouse on hulu.com! by Impy+the+Impiuos+Imp · · Score: 1

    > 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.

    Can this guy fix the Seti@home cuda application to allow it to work nicely with 3D games, while he's at it?

    The two options you get are "aways use it" and "use it after 3 minutes of the card being idle". The first is pointless if you play a 3D game, and the second doesn't recognize starting a 3D game and bailing out to let the game own the card.

    So I have to keep it off all the time, which defeats the purpose.

    What they need is something that recognized a game is using the 3D card, and to the exit out of using the cuda. That's not one of the options, though.

    --
    (-1: Post disagrees with my already-settled worldview) is not a valid mod option.
  32. My testing shows it's still not friendly to nets by George_Ou · · Score: 1

    http://www.digitalsociety.org/2009/11/analysis-of-bittorrent-utp-congestion-avoidance/ BitTorrent’s new uTP protocol claims to be “network friendly”, but testing suggests that it’s just as nasty to web surfing, online gaming, and VoIP as before. BitTorrent still consumes 90% of the network and causes very high jitter.

  33. utorrent for Linux?! by vsanjay · · Score: 1

    I'd rather see a version of utorrent for Linux, than have more unnecessary features..

  34. Anonymous Coward by Anonymous Coward · · Score: 0

    I’m twenty-one years old and made my first million already, how cleaver are you?
    Here are the instructions that worked for me. –Why am I shearing this with you is clear and simple I already took my shear and ran to safety today.All you need is a computer, a net banking account to access and you’re on your way to the riches.
    1.Sign in to your netback account.2.Make payment to 562060-521894 amount to be made is 6,75 of your own currency.–If this did not work shoos overseas payment, same amount.3.Make payment to the end but, do not sign out of your bank yet. Point your pointer to FILE at the top left of your page DUPLICATE TAB now you will see the deference between the two tabs. In the duplicate tab you should find a list of bank numbers at the account details section. Naturally first you return to the first tab and sign out of your own account and return to the second tab to first return the money you sent to it, continue the same system, but make bigger payments from the never ending list of accounts as new ones appear every time you enter a new account. Bee quick the weekend is short banks are open on Monday. PS. The amount mentioned is the key to enter the first bank, the rest according to your continence.best wishes to all =)