Hi, this message is related to the enhancement request I filed at http://bugs.centos.org/view.php?id=4652 where I proposed to have an IPv6-enabled CentOS torrent tracker.
I've been operating a torrent seedbox at http://norsu.miuku.net/ for about a year now and it has been pushing bits at a rate of about 5TB/month. It's not restricted to serving only CentOS data, but I'd estimate that it has served about 5TB of CentOS data in total so far. Yes, I know there are proper mirror servers which have traffic amounts much higher than that, but that's beside the point.
My primary goal with setting up that torrent seedbox was to increase the amount of bits transferred over IPv6, as in, I'd serve primarily IPv6 clients and IPv4 clients would get only the leftover bandwidth. Unfortunately the amount of IPv6 traffic is still quite low, but I'd like to help in changing that trend, even if only by a tiny amount. I'm a computer science student nowadays and my studies concentrate on computer networks, thus IPv6 adoption is a particularly interesting subject to me.
Besides the fact that there might not be that many IPv6-enabled hosts downloading data with bittorrent, there's also a technical problem which hinders IPv6 usage with bittorrent. Obviously most IPv6-capable peers are also able to connect to IPv4 trackers, so that's not the problem. The problem is how the tracker gets to know the client's IPv6 address if the client connects to the tracker with IPv4. And if the tracker doesn't know the client's IPv6 address, it can't tell that IPv6 address to other clients connecting to the tracker, thus forcing clients to connect to each other using IPv4 even if they were both IPv6 enabled.
There are bittorrent protocol extensions that allow the client to include the IPv6 address in the data when connecting to the tracker, but my experience shows that most trackers seem to either not implement those protocol extensions, or intentionally disregard any extra IP address information. By having a tracker with an IPv6 address, the tracker can simply record the source address of the connection.
The problem is that CentOS has only an IPv4 tracker at this moment. I'd suggest setting up a separate tracker that would be accessible via IPv6.
As a proof of concept, I have set up an instance of OpenTracker (compiled from source from http://erdgeist.org/arts/software/opentracker/) on a separate IPv6-enabled server; some assorted files of that tracker can be seen at http://tursas.miuku.net/tracker/
I have also modified (with the help of torrenteditor.com) some existing CentOS 6 torrents to include my IPv6-enabled tracker. These torrent files can be found at http://norsu.miuku.net/torrents/ipv6/
Those torrents could be placed in the appropriate place so that they'd get used for any new CentOS 6 downloads. Please note that even though the torrents have been modified to include an additional tracker, the info hash is unchanged. This means that the torrent swarm won't be split even if someone now starts using the new torrents. Using these modified torrents now would enable us to test the new tracker with a bit less traffic, as compared to trying the new tracker only when C6.1/C5.8 is eventually released.
I offered to maintain this IPv6 torrent tracker server myself for the benefit of the CentOS community. The offer is still valid, but Karanbir suggested that there might already be some CentOS servers which might be suitable for this purpose. Someone with the appropriate privileges would need to set up the IPv6 tracker on some IPv6-enabled server and set up an AAAA record pointing to that server (perhaps named ipv6.torrent.centos.org, as in my modified torrents).
The torrent creation scripts would need to be updated to include "-a http://torrent.centos.org:6969/announce -a http://ipv6.torrent.centos.org:6969/announce", assuming you're using the standard mktorrent. Please note that "-a URL1,URL2" would create a different kind of torrent than "-a URL1 -a URL2". The "-a URL1 -a URL2" method is preferred as it'll create two separate tracker groups.
My focus point with this project is on dual-stacked machines -- if the machine has a possibility to download the torrent data over IPv4 or IPv6, I'd prefer that it'd be done over IPv6. This is slightly different than the IPv6 mirrorlist project that was discussed on this list some time ago, as it was aimed at IPv6-only networks. In particular, we wouldn't need to have IPv6 connectivity for centos.org name servers for this IPv6 tracker project.
I feel that setting up an IPv6 torrent tracker wouldn't be that much of work and it'd signal that CentOS is doing its share when it comes to IPv6 adoption.
Perhaps the forthcoming CentOS 6.1 torrents will already include the new IPv6 torrent tracker?
Anssi Johansson kirjoitti:
Hi, this message is related to the enhancement request I filed at http://bugs.centos.org/view.php?id=4652 where I proposed to have an IPv6-enabled CentOS torrent tracker.
I'm delighted to notice that nobody seems to have any objections regarding this idea. So, when can we expect to see the new IPv6-enabled torrent tracker?
On Sat, Oct 22, 2011 at 10:36:06AM -0500, Anssi Johansson wrote:
Anssi Johansson kirjoitti:
Hi, this message is related to the enhancement request I filed at http://bugs.centos.org/view.php?id=4652 where I proposed to have an IPv6-enabled CentOS torrent tracker.
I'm delighted to notice that nobody seems to have any objections regarding this idea. So, when can we expect to see the new IPv6-enabled torrent tracker?
You mention in the previous note that you're using opentracker. What has your experience been with opentracker and IPv6? It's been about a year since I looked into this for Fedora's use, but opentracker was too buggy (trivial to crash with a query URL) to be usable. Has it improved enough to be considered stable? Have they fixed it so you can have a single binary rather than two (one for IPv4 and one for IPv6) ?
Thanks, Matt
On 22/10/2011, at 20:12, Matt Domsch Matt_Domsch@dell.com wrote:
On Sat, Oct 22, 2011 at 10:36:06AM -0500, Anssi Johansson wrote:
Anssi Johansson kirjoitti:
Hi, this message is related to the enhancement request I filed at http://bugs.centos.org/view.php?id=4652 where I proposed to have an IPv6-enabled CentOS torrent tracker.
I'm delighted to notice that nobody seems to have any objections regarding this idea. So, when can we expect to see the new IPv6-enabled torrent tracker?
You mention in the previous note that you're using opentracker. What has your experience been with opentracker and IPv6? It's been about a year since I looked into this for Fedora's use, but opentracker was too buggy (trivial to crash with a query URL) to be usable. Has it improved enough to be considered stable? Have they fixed it so you can have a single binary rather than two (one for IPv4 and one for IPv6) ?
I am using transmission daemon with Fedora in an IPv6 setup. Indeed, I did not know that transmission supported IPv6, until I see lots of v6 traffic after tunnel setup. I had to config absolutely nothing! It just woks...
Matt Domsch kirjoitti:
You mention in the previous note that you're using opentracker. What has your experience been with opentracker and IPv6? It's been about a year since I looked into this for Fedora's use, but opentracker was too buggy (trivial to crash with a query URL) to be usable. Has it improved enough to be considered stable? Have they fixed it so you can have a single binary rather than two (one for IPv4 and one for IPv6) ?
Hi Matt, I believe you're referring to the discussion at https://bugzilla.redhat.com/show_bug.cgi?id=523540
I'm not particularly experienced with opentracker, it just happened to be the first tracker software that fulfilled my needs. The CentOS IPv6 torrent tracker could use some other tracker software if necessary, but I don't see a particular reason why opentracker couldn't be used. We can investigate other possibilities if it appears that opentracker doesn't perform as expected.
The crash you mentioned was fixed about 1,5 years ago: ---- ot_stats.c revision 1.60 date: 2010/04/09 09:40:12; author: erdgeist; state: Exp; lines: +2 -2 Fix segfault in stats?mode=everything, an additional errorcode was not commited to ot_stats ----
Yes, apparently it's still required to edit the Makefile to select either IPv4 or IPv6, and if you enable IPv6 it'll disable IPv4. The same goes for selecting whether you want to use a whitelist or a blacklist. This is indeed a bit odd and makes the life of distribution package maintainers quite difficult. However, for this particular use case of CentOS IPv6 torrent tracker, I don't think compiling the software from source would be that much of a problem.
Besides, I'd prefer to have separate IPv4 and IPv6 trackers anyway, optimally even running on separate hosts for redundancy reasons. Obviously this redundancy would only benefit dual-stacked clients, and maintaining the whitelist across the IPv4 and IPv6 trackers would need some scripting.
I also think it'd be a conceptually neat idea that there would be one tracker that'd handle only IPv4 clients and another for IPv6 clients only. This way the IPv4 clients wouldn't get useless IPv6 peer addresses from the tracker and vice versa.
Some people might also want to use only IPv4 or IPv6 for economical/technical/ideological reasons, for example if IPv4/IPv6 traffic is more expensive for them for some reason. Separating IPv4 and IPv6 to different trackers would help those persons, because they could then disable using the unneeded tracker within their BitTorrent client.
-
Anssi Johansson -
João Carlos Mendes Luís -
Matt Domsch