torrent icon indicating copy to clipboard operation
torrent copied to clipboard

Question: Are peers obtained via `x.pe` expected to be TCP-only?

Open pataquets opened this issue 2 years ago • 2 comments

I'm using magnet URIs embedding the x.pe field, which is supported since b020b8c2b6a65a4ed8ecc3e40d184a8a6e9aee6e. As I try to avoid TCP and use UDP/uTP as much as possible, I have the peer nodes here with the only port open 51413/udp, but with 51343/tcp closed (transmission-daemon running in a Docker container). Outside peers reach the node OK, via UDP/uTP and download from my node without problem. What I've observed is that peers provided via x.pe are not reachable unless TCP is open, so I assume that there is no attempt to reach them via UDP. Reading BEP9, there is no mention about TCP not UDP, so my question is: Is it expected for peers obtained via x.peto be tried on both TCP and UDP? Does it matter if they're obtained by other means (ie. PEX)?

pataquets avatar Aug 05 '22 04:08 pataquets

The x.pe addresses should be attempted on all diallers, and should result in a connection attempt in any that can interpret the address. That should be both uTP and TCP in default configurations.

It should be the same with PEX, albeit I think there's a flag for uTP/TCP there.

It's possible that x.pe addresses that you're seeing are just not accessible over uTP. If they're long lived static addresses that the link creator manages, that may be intentional.

anacrolix avatar Aug 08 '22 06:08 anacrolix

I'll check it better, but I'm mostly sure that both TCP and UDP were open, as I was controlling the x.pe peer. I guess I'll need to double check my tests and maybe I'll add some debugging messages. I'll post the results whatever they come (not anytime soon due to priorities, thou).

pataquets avatar Aug 21 '22 20:08 pataquets

Reopen if you have more information, cheers.

anacrolix avatar Feb 07 '23 22:02 anacrolix