µTP goes open source
p2pnet view Open Source | P2P:- BitTorrent has open sourced its new uTorrent protocol, now in public beta.
It’s “aimed at maximising network throughput while minimising network congestion, providing a better overall experience for both ISPs and end users”, says H-Online, going on,”Additionally, uTP is said to work well within home networks, preventing one system using BitTorrent from consuming the whole network.”
Blogs BT’s Simon Morris >>>
µTP is an upgraded lightweight BitTorrent protocol, introduced in v2 of our popular µTorrent client, that makes efficient use of bandwidth while reducing network problems. For the past several months we have been polishing our implementation of µTP in µTorrent, resulting in several minor upgrades of the client as we figure out how to make it perform optimally under an incredibly wide range of scenarios.
Today, we are announcing that we have created an open source implementation of the protocol in the hope of extending its adoption within the BitTorrent ecosystem and possibly beyond. This code has been posted here on Github, a popular collaborative software development environment, so that others may get the benefits from this technology as well as contribute back to the code on an ongoing basis.
We have spent a significant amount of time and resources on µTP because we believe that it can yield significant results for both consumers and network operators. If you are just now joining the µTP conversation, you may visit to some of our earlier blog posts on the topic. In short:
- µTP maximizes network throughput while minimizing network congestion by rapidly detecting congestion and slowing itself down when the network is overloaded. The result is faster downloads for users with lower network impact for both users and ISPs;
- µTP is user-friendly within a home network, so one computer using BitTorrent will not consume the whole network;
- µTP is an open protocol which has been publicly disclosed and submitted for review in standards-making bodies (learn more about standardization of µTP on bittorrent.org and at the Internet Engineering Task Force (IETF) at the LEDBAT working group);
We continue to be polish and optimize µTP, but we’re very encouraged by the results that we have seen so far. We believe that open sourcing our implementation is a critical next step in ensuring adoption, compatibility and the best experience for all BitTorrent users.
Download it at at GitHub
H-Online – BitTorrent Inc. open sources new P2P protocol, May 26, 2010
Blog – µTP Open Source Implementation, May 21, 2010
Use free p2pnet newsfeeds for your site. It`s really easy!
Subscribe to p2pnet.net | | rss feed: http://p2pnet.net/p2p.rss | | Mobile – http://p2pnet.net/index-wml.php
Net access blocked by government restrictions? Use Psiphon from the Citizen Lab at the University of Toronto. Go here for details.
June 1st, 2010 at 4:07 pm
UTP is total crap. It is an attempt at implementing a TCP stack on top of UDP. It started as a closed, flawed protocol, designed without ANY input from outside the uTorrent organization.
It was meant to solve two problems. The first problem was that people weren’t configuring their upload bandwidth cap correctly and hence choking their downloads. UTP uses a delay timing hack to attempt to fix this, which does work in some situations, while in others it makes things worse. The other problem was users that don’t have a reachable incoming TCP port, and UTP tries to fix this in conjunction with another extension, ut_holepunch. This extra extension is currently undocumented, although my company has done some reverse engineering and we decided to not implement it because of some potentially serious security issues that I won’t go into here. Regardless, without holepunching, there is no reason to implement UTP in other clients because the upstream bandwidth throttling problems are easily solved with automatic ping-based throttling, which I believe is already implemented in Vuze and Tixati and possibly a few others.
June 1st, 2010 at 10:11 pm
@ Reader’s Write: its a shame you have such a negative attitude about uTP. I’d like to respond to your main points:
“uTP was initially rolled out as a closed protocol”: it is a tough pill to swallow in many of the more passionately open-source circles, but the reality is that we chose pragmatism over purism. Instead of waiting 10 or 20 years to standardize the *perfect* approach and roll out at the OS kernel level, we chose to just get on with it as we were in the very unusual position of being able to get this technology to scale without the need for other launch partners. The result is that we have a deployment at scale (probably well over 50 million terminals communicating with uTP) and now we’ve opened up everything for discussion and optimization. We welcome constructive criticism in the interests of making uTP better for everyone, but if all you have is “you should have implemented this in the TCP stack” then we might say “we respectfully differ”.
“uTP uses a delay timing hack”: I can’t understand why you think what we have is a hack, unless of course you class any type of app-level custom networking protocol as a hack. Just like Skype, most all VoiP apps and most networked games, we implemented something ourselves rather than relying on broken TCP behavior. If this is a “hack” then I guess many of the internet’s most popular applications also employ “hacks” – go figure…
ut_holepunch is not documented: this is true – not by design but mainly as no-one yet asked us to document it, and it hasn’t yet come to the front of our priority queue (actually the PEX protocol on which ut_holepunch relies) is also not documented although many people have reverse-engineered it and implemented it themselves)
“ut_holepunch has serious security issues” – of course this is very troubling contention if its true – we’ve gone to great lengths to make sure it does not open up security issues and we can not think of anything troubling. But in the interest of not being too overconfident, if you do have information that could prove us wrong then we’d be *very* interested to hear about it – you can reach me via simon AT bittorrent dot com
“upstream bandwidth throttling problems are easily solved with automatic ping-based throttling”: this looks a bit strange in relation to your claim that uTP delay measurement is a “hack” – we have looked into this method of throttling in quite some depth and are absolutely convinced that it flat_out_doesn’t_work – the main problem is that its too hard to discern between a congested connection and one that is just slow – even looking at latency in conjunction with jitter as an indication of congestion is quite imperfect and leads to far more problem cases than we find with uTP.
To be clear, uTP is still maturing and there are still edge cases we are learning about and fixing – we still have a journey to make it fit well everywhere, but we’re confident that we’re much further along than some people give us credit for.
June 2nd, 2010 at 2:39 pm
” This extra extension is currently undocumented, although my company has done some reverse engineering and we decided to not implement it because of some potentially serious security issues that I won’t go into here. ”
Probably because you are full of shit. There really is no reason to not go into it here, is there ?
Or is your argument so thin that it can’t survive scrutiny ?
June 3rd, 2010 at 1:55 am
“- µTP maximizes network throughput while minimizing network congestion by rapidly detecting congestion and slowing itself down when the network is overloaded. The result is faster downloads for users with lower network impact for both users and ISPs”
How does this result in faster downloads when the entire point is to “throttle” or slow down BitTorrent transfers?
I can see where this would help if a user had their upload bandwidth set too high and it was choking off their downloads, however… If all the people that you’re downloading from are also using this, then your download speed will depend on how much their upload bandwidth gets throttled. If they decide to start viewing videos on YouTube, your download speed is going to go down the crapper.
I don’t see how something designed to slow down transfers can result in faster downloads.
July 21st, 2010 at 10:42 pm
I’ve had many problems with it, including total loss of both downstream and upstream bandwidth. only disabling it has cured the problem, its a bandwidth hog with its quadruple sized overheads and over-throttling. Some major changes need to be made before any true advantage is gained.