Opened 12 years ago

Closed 12 years ago

#2502 closed Enhancement (fixed)

Announce own IPv6 address to peers

Reported by: jch Owned by: charles
Priority: Normal Milestone: 1.80
Component: libtransmission Version: 1.75
Severity: Normal Keywords: IPv6
Cc:

Description

LTEP allows a peer to announce its IPv6 address to its IPv4 peers, and vice-versa. This is extremely useful when a peer has NATed IPv4, but is reachable over IPv6, and there is no tracker support for IPv6.

The first part of the patch simply announces our IPv6 address in the LTEP handshake. The effect of this is dramatic: testing this on a host with NATed IPv4 and good IPv6, I'm finding that with some swarms, about half of my download comes from incoming IPv6 µTorrent peers.

The second part of the patch is more difficult to quantify. Whenever a peer announces an alternate address, we store it in a special type of peer_atom, which has the effect of propagating the address through PEX. I'm unable to quantify this part, since most of the swarms I'm seeing are dominated by uTorrent (which already does the right thing).

Charles, I very warmly recommend committing this -- it's a small patch, and the improvement is dramatic in some cases.

--Juliusz

Attachments (2)

self-ipv6-address.patch (10.2 KB) - added by jch 12 years ago.
self-ipv6-address-rev-2.patch (9.0 KB) - added by charles 12 years ago.
I'd like you to proofread/evaluate this revision before I commit it. (1) make some of the new functions in net.c private (2) use the existing tr_peerMgrAddPex() mechanism for adding the ipv4 and ipv6 addresses we find during the LTEP handshake

Download all attachments as: .zip

Change History (10)

Changed 12 years ago by jch

comment:1 Changed 12 years ago by charles

  • Milestone changed from None Set to 1.80

comment:2 Changed 12 years ago by jch

By the way, Charles, in its current form this patch depends on #2508. I can easily modify it to work around #2508, so let me know if you decide that fixing the latter is too difficult.

Changed 12 years ago by charles

I'd like you to proofread/evaluate this revision before I commit it. (1) make some of the new functions in net.c private (2) use the existing tr_peerMgrAddPex() mechanism for adding the ipv4 and ipv6 addresses we find during the LTEP handshake

comment:3 Changed 12 years ago by jch

(1) make some of the new functions in net.c private

Hmm, please make globalIPv6 public, I want to use it from announcer.c. (Perhaps it should be moved somewhere else?)

(2) use the existing tr_peerMgrAddPex() mechanism

Indeed, that's much cleaner.

--Juliusz

comment:4 Changed 12 years ago by charles

  • Status changed from new to assigned

Applied in r9499, with a currently-private globalIPv6, but feel free to make it public when you're ready to use it in announcer.c; I have no objections to that.

Generally I try to tie things down with const/private, and then loosen those restraints only when it's needed. :)

comment:5 Changed 12 years ago by charles

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:6 Changed 12 years ago by jch

The second part of this patch has been broken by r9532 (#2575). (Not complaining, #2575 is more important than this ticket, just noting.)

I don't see a good solution; I fear that we must rework the way we deal with incoming "ipv6=" messages.

--Juliusz

P.S. Not reopening, since apparently I'm no longer allowed to reopen a ticket.

comment:7 Changed 12 years ago by livings124

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:8 Changed 12 years ago by jch

  • Resolution set to fixed
  • Status changed from reopened to closed

The reason I reopened this bug is that since we're now only PEX-ing around connected peers, we no longer propagate the alternate addresses, or at least not until we connect to them.

The alternative would be to either advertise alt addresses whenever we are connected to the primary atom, or to store the alt address in an extra field of the original atom rather than a new atom. The downside is that we'd be advertising addresses we haven't actually checked.

Whatever. The labour/benefit ratio, as Charles likes to say, is rather large. Closing.

--Juliusz

Note: See TracTickets for help on using tickets.