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."
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.
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.
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 ?
Your router will throttle you, take your wallet and run.
So if this is the future...where's my jet pack?
I dont' think you quite understand that word you used there. Hulu/pandora are the OPPOSITE of multicast.
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.
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...
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.
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?
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.
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.
Slipping shoelaces ?
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!
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.
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.
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.
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.
have you read the Moderation Guidelines Addendum?
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..