libutp, an open source implementation of µTP, has now been released

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

In addition to open sourcing the µTP code from µTorrent as libutp, work is underway to implement µTP into Rasterbar's libtorrent, which is used by clients like Deluge.

For those actually working with the libutp code, please file any issues with libutp at http://github.com/bittorrent/libutp/issues

What would you say be the main differences between this "open-source implementation" and uTorrent implementation ?

Maybe it's this rafi?Now I know why the uptake are so slow.I asked about libutp's possible inclusion for maybe the next Bitcomet beta on their feature request thread.Here's the response:-

It's not likely.

µtorrent could have and should have put this on SourceForge if they *really* intended to share it with anybody. Instead, they put it on very new and very tiny repository, GitHub.

GitHub charges for access if your product is not open-source, which means that almost every client except Vuze would have to pay for the privilege of seeing their so-called "open source" code. That was a really .... crap-headed ... thing for µtorrent to do, just a transparent maneuver to make their competition look like the guilty ones for not adopting something "open source", that nobody has a budget to pay for.

I don't know how µtorrent justifies this to itself, but it looks like Firon is getting kickbacks from GitHub, or maybe µtorrent secretly owns them.

Actually, you could do the most to advance this -- if you really want to advance it -- by screaming at µtorrent for this on their forum, and demanding that they put this on sourceforge, or that µtorrent pay for a GitHub subscription for any closed-source torrent client developer (almost all of them) who wants to access this. If they don't you'll know it was just theater to deceive you.

Open-source my aspirin.

kluelos,Support Team,Group:BitComet Tech Support

It kinda answered (a bit) as to my curiosity on why github was chosen instead of someplace like sourceforge which I had intended to post about here in the 1st place?Now while this might be perceived as a slightly misunderstood thing or some uncalled for allegations it still is troubling?So how about it Greg H?Wanna clarify this for us?

We can argue that maybe other closed source bittorrent clients out there should pay for access under the assumption that since they're technically competitors,they're getting a piece of a rival's code so it's only fair.But is it?As far as compatibility goes,is this even a logical thing to do to just make it easier only for true open source clients;libtorrent based Deluge or Halite and Vuze/Azureus?

And for the record I've checked out Deluge's dev forums and apparently it's being worked on libtorrent and placed here http://code.google.com/p/libtorrent/issues/detail?id=6 ..possibly the only meaningful,latest progression on libutp's adoption I've seen so far?

Any comment Firon?

Just curious..

Slow uptake? The thing was open-sourced a whopping six days ago. How -- or better yet, why -- do you expect every single client to have already picked it up?

As for kluelos's response... Unless he expects that BitComet has to host their project on GitHub to access source found on other GitHub repositories, then I don't see what his point is. There's a big freaking "Download Source" button at the top of the page if they cared to use the source. If they wanted to collaborate on the project, they don't have to pay because it's an open-source project. If they use source code from an open-source project found on GitHub, they don't have to put their own closed-source project on GitHub. And given libutp's license, they don't even have to open-source their own client if they want to use it. What source code hosting site BitTorrent chooses to host their open-source project on is absolutely irrelevant when the source license allows for free redistribution/reuse.

Quite honestly, it sounds to me like kluelos is making excuses more than anything else. No, I'm not saying BitComet is obligated to adopt uTP or use libutp, but if he's going to bother "explaining" why BitComet is unlikely to implement uTP support, then he's going to need to stop using GitHub as the scapegoat and try giving a real reason instead. And maybe stop playing the tinfoil hat and trolling game too while he's at it -- that'd be a nice bonus. Well, I guess I'm assuming here that he even cares to have people take his words seriously.

Honestly, kluelos needs a clue.

BSD licensed code IS open source, people don't need to pay for access.

kluelos is incorrect here, as has been stated. He should actually read about Github.

Github is a source code hosting service just like Sourceforge. Github does charge if you want to host your own private repository, or if you want to run a copy of Github on your servers. Sourceforge has a similar non-free version http://en.wikipedia.org/wiki/SourceForge_Enterprise_Edition . libutp, however, is open source so there is no cost for us to host it on Github or to anyone who would like to contribute. You do not need to pay anything to see, download, or fork the source code. It is right there: http://github.com/bittorrent/libutp

uTorrent is a closed source application, and is not hosted on Github in public or private form. Similarly if libutp was hosted on Sourceforge, uTorrent would not be required to host their either. BitComet is not required to pay or even have a free account on Github, just as no account is needed to download from Sourceforge. Github is just where I chose to host the project because I find it to be faster, easier to use, and less smothered in ads than Sourceforge.

Sourceforge is awful. That's why it's on Github.

And I don't know if kluelos is dumb or trying to spread FUD, but you don't need to pay to access github. Of course, anyone who spent about 5 seconds looking at our github page for libutb would have seen that.

I wasn't able to compile this in Visual Studio 2010. I had to add two stdlib.h includes and two const_cast:

diff -urN bittorrent-libutp-4e3f400.orig/utp.cpp bittorrent-libutp-4e3f400/utp.cpp
--- bittorrent-libutp-4e3f400.orig/utp.cpp    2010-05-27 13:03:22.000000000 +0200
+++ bittorrent-libutp-4e3f400/utp.cpp    2010-05-28 01:34:27.000000000 +0200
@@ -9,6 +9,7 @@
 #include <string.h>
 #include <errno.h>
 #include <limits.h> // for UINT_MAX
+#include <stdlib.h>

 #ifdef WIN32
 #include "win32_inet_ntop.h"
@@ -191,13 +192,13 @@
         const byte family = get_family();
         str i;
         if (family == AF_INET) {
-            inet_ntop(family, &_sin4, s, len);
+            inet_ntop(family, const_cast<uint32 *>(&_sin4), s, len);
             i = s;
             while (*++i) {}
         } else {
             i = s;
             *i++ = '[';
-            inet_ntop(family, &_in._in6addr, i, len-1);
+            inet_ntop(family, const_cast<in6_addr *>(&_in._in6addr), i, len-1);
             while (*++i) {}
             *i++ = ']';
         }
diff -urN bittorrent-libutp-4e3f400.orig/utp_utils.cpp bittorrent-libutp-4e3f400/utp_utils.cpp
--- bittorrent-libutp-4e3f400.orig/utp_utils.cpp    2010-05-27 13:03:22.000000000 +0200
+++ bittorrent-libutp-4e3f400/utp_utils.cpp    2010-05-28 01:32:00.000000000 +0200
@@ -2,6 +2,7 @@

 #include "utypes.h"
 #include <assert.h>
+#include <stdlib.h>

 #ifdef WIN32

I wasn't able to compile this in Visual Studio 2010. I had to add two stdlib.h includes and two const_cast:

I believe this fixed it:

http://github.com/bittorrent/libutp/commit/bc59ac7fd1fcf751e2c43e9aa28ee467efe95bbb

Can you confirm?

Also, in the future, please file issues with libutp on the issue tracker: http://github.com/bittorrent/libutp/issues

Hi, is it possible to port this utp to java? I want integrate it in my bittorrent client

regards gurkerl

Go nuts on it.

Nice

:cool::cool::cool::cool::cool:

We continue to be polish and optimize µTP

that's an odd statement, what difference does it make if you're Polish, and how exactly would you not continue to be?

re paying for github access, they are probably confused by the fact that one has to pay for private repos on github.