In ut_holepunch how can a relaying peer be connected at all to the target peer?

Question

In the context of liubtorrent's ut_holepunch lets assume that:

• initiating peer local endpoint is 1.2.3.4:6881 and the mapped address is 5.6.7.8:5881 now when the peer announce to the tracker the tracker will save 5.6.7.8:6881 since 6881 is the port that the peer announced but it's not the real world facing port.

• target peer local endpoint is 9.10.11.12:6882 and the mapped address is 13.14.15.16:5882 now when the peer announce to the tracker the tracker will save 13.14.15.16:6882 since 6882 is the port that the peer announced but it's not the real world facing port.

bep0055 states this:

The initiating peer sends a rendezvous message to the relaying peer, containing the endpoint (IP address and port) of the target peer. If the relaying peer is connected to the target peer, and the target peer supports this extension, the relaying peer sends a connect message to both the initiating peer and the target peer, each containing the endpoint of the other. Upon receiving the connect message, each peer initiates a uTP [2] connection to the other peer.

so when the initiating peer sends a rendezvous message to some relaying peer then the relaying peer has to be connected to the target peer for it to work, but if the tracker has the wrong target peer port, then no relaying peer will be connected at all to that peer

Answer 1

You should send the message to a relaying peer that already is connected to the target peer. Which one fits can be figured out by searching through the peer lists from PEX (BEP 11)

A tracker isn't involved in the process.