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."
Ugh. TFA is all about Torrent (or uTorrent if Slashdot can't print a mu).
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.
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.
the first post! boooyaaa
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.
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
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?
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.
Is this likely to improve LAN performance when using bittorrent on a shared internet connection also?
/u2404
Seriously though, this is a good thing. I don't know why the story is tagged "your rights online"
AFAIK most bittorent clients throttle connections already, some automatically like vuze, others like transmission only manually.
Or am i missing the point ?
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.)
Your router will throttle you, take your wallet and run.
So if this is the future...where's my jet pack?
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.
Are any clients other than Azureus using tech which finds other people nearby, which tends to reduce traffic outside an ISP?
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
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.
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.
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...
Get a seedbox. :)
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?
Azureus has been doing this for years. There are actually three built-in methods (only one of which I find effective).
Azureus aka Vuze has had this in for a long time now. Why is it such big news?
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.
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..
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!
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.
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 --> .
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.
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.
> 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.
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.
I'd rather see a version of utorrent for Linux, than have more unnecessary features..
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 =)