Hi,
I'm the reporter of issue #108301
<http://www.openoffice.org/issues/show_bug.cgi?id=108301> and I've been
asked by cloph (sorry, don't know your real name) to bring this up on
this list.
First of all, for reference my initial post to ease the media switch:
as most of you probably know IPv6 is the upcoming successor of the current
internet protocol IPv4. I have recently started to look into the Bittorrent over
IPv6 situation (my summary is available at
http://www.birkenwald.de/dokuwiki/doku.php?id=projects:ipv6-bittorrent ).
Currently, while most Bittorrent clients are IPv6-capable most trackers are not.
This makes it very hard to impossible for clients to find IPv6 peers on their
own.
The Bittorrent Multitracker extensions, which are implemented in almost any
client known today (and still provide a full backup path for clients not
implementing it) allow multiple trackers to be specified for a torrent (but you
already know that, since you are using it). We have recently done this for the
conference recordings of 26c3 (a big german hacker conference) and had good
results. Therefor I'd like to ask you to put an IPv6-only tracker into the
multitracker list, if possible as an additional primary group. If there is a
need I would volunteer to run that (see the URL) and I also have a few very
high-speed seeders (>= 1Gbps) on native v6 that can help out to seed. But as
stated before, this would only be additional, not replacing the current ones.
and the answer by cloph:
1st of all: None of the tracker servers used as of today has an AAAA record,
thus adding ipv6 support on the main trackers won't be added soon. (if you can
reach the tracker only using IPv4, there's not much point in having it deal
IPv6)
The Bittorrent Multitracker extensions,
A note on that one: The OOo tracker network doesn't only use multitracker
enabled torrents, but the trackers OOo uses are as well linked with each other.
I.e. the tracker themselves exchange peer information, every tracker knows about
the whole swarm. It is not only "dumb" multitracker where the client picks
independent-of-each-other trackers where each tracker manages a completely
seperated swarm.
I'm not sure whether adding an additional, not tracker-link aware tracker would
be a good idea, as it would fragment the swarm. (i.e. I would perfer the ipv6
users take part in the ipv4 swarm instead) (swarm is relatively small
But please bring this to the dev@distribution.openoffice.org mailing list for
more input. Adding another tracker would just be a change in the php script on
http://borft.student.utwente.nl/~adrian/bt.php - and the OOo torrents are
available via rsync, so you could keep your tracker up-to-date with that.
But since neither of the main server is IPv6-capable, you would have to run the
corresponding seed as well.
Sum up: technically adding another tracker is not much of a deal, the question
is whether it is a good thing to do or not.
Regarding the multi-tracker extensions, cloph is absolutely right that
if you follow the standard to the letter adding a seperate IPv6 tracker
to the existing list could fragment the swarm.
BEP-12 <http://bittorrent.org/beps/bep_0012.html> has been designed with
clients in mind that would only connect to a single tracker at once. OOo
is currently using a style similar to the second example in the BEP for
loadsharing.
[['http://borft.student.utwente.nl:6969/announce',
'http://core-tracker.enlist-a-distro.net:9800/announce',
'http://core-tracker.depthstrike.com:9800/announce',
'http://clients-tracker.enlist-a-distro.net:9800/announce',
'http://clients-tracker.depthstrike.com:9800/announce',
'http://www.ooodev.org:6969/announce']]
Since a client would only connect to one of the trackers they have to
share information amongst each other (tracker-link), otherwise the
swarms would split.
Adding a dual-stacked or IPv6-only tracker to that tracker list is
indeed a bad idea, since a dual-stacked client might end up on the IPv6
tracker only handling IPv6 peers. This would cause the swarm to split.
What I'm proposing is adding an IPv6-only tracker as a second primary
group, much like the third example in the BEP. Something like this:
[['http://borft.student.utwente.nl:6969/announce',
'http://core-tracker.enlist-a-distro.net:9800/announce',
'http://core-tracker.depthstrike.com:9800/announce',
'http://clients-tracker.enlist-a-distro.net:9800/announce',
'http://clients-tracker.depthstrike.com:9800/announce',
'http://www.ooodev.org:6969/announce'],
['http://ipv6onlytracker:6969/announce']]
According to standard clients are supposed to try each of the trackers
in the first list (the official IPv4 trackers), and only if none of them
answer it should bother to try the second list (the IPv6-only tracker).
This would probably do no good for IPv6 at all, since the clients would
only try the tracker if all IPv4 trackers are down or unreachable. Which
is pretty unlikely unless you are in an IPv6-only environment.
But here is where the standard and reality deviate. Most Bittorrent
clients I have seen in the wild recently (µTorrent, Azureus/Vuze,
Transmission since 1.80, libtorrent (Rakshasa and Rasterbar)) just
connect to all primary groups simultaneously. In this case these clients
would connect to one of the v4-trackers in the first group _and_ to the
v6-tracker in the second group, effectively getting peers for both
address families.
Regarding seeding, I am in control of at least three systems in
different networks that could seed IPv6 with native 100++ Mbps. And I
know of at least five more ISP networking people with the same or better
capabilities that could do the same within hours if possible (we
IPv6-freaks are a big family and we want to see traffic :-) ). Regarding
the v6-tracker, the one I already run (see my initial bugreport) is
there and will not go away, so feel free to use it if you like, either
with my public DNS name or with an alias in any domain you wish.
What do you think about it?
Best Regards,
Bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@distribution.openoffice.org
For additional commands, e-mail: dev-h...@distribution.openoffice.org
