carlosgit2016
commented
1 month ago I think I was able to understand the problem.
When we add a torrent we connect to a tracker that will give us the IPs of other peers and we also join the swarm. One way to get more peers is to enable them to connect to you, also having more peers means that the tracker can prioritize my client and with more peers the chance to find missing pieces of the files to complete download.
I noticed that the qbittorrent client uses the first IP of the eth0 NIC that it finds, this is the IP of the pod when running inside the cluster, from my understanding this is the IP that is announced to the tracker as well. In summary I don't think is gonna work, in comparison to my qbittorrent client that is running in my computer directly and using public ipv6 to announce to peers, on other hand the cluster installation is using a local IP and no online peers will be able to close a p2p connection with my cluster
I need a way to qbittorrent client running in the cluster announce my public IP to the tracker with the right port, and this port need to be routed to my cluster nodes, so I probably need some configuration in the router as well.
Listening ports in the cluster
tcp 0 0 172.16.93.21:30976 0.0.0.0:* LISTEN -
udp 0 0 172.16.93.21:30976 0.0.0.0:* -Local listening ports
udp UNCONN 0 0 172.17.0.1%docker0:34532 0.0.0.0:* users:(("qbittorrent",pid=141330,fd=29))
udp UNCONN 0 46592 192.168.1.6%wlan0:34532 0.0.0.0:* users:(("qbittorrent",pid=141330,fd=31))
udp UNCONN 0 0 127.0.0.1%lo:34532 0.0.0.0:* users:(("qbittorrent",pid=141330,fd=26))
udp UNCONN 0 0 [fe80::2c9a:f8ff:fe0b:6f00]%veth841369c:34532 [::]:* users:(("qbittorrent",pid=141330,fd=42))
udp UNCONN 0 0 [fe80::42:fff:fe22:2ebb]%docker0:34532 [::]:* users:(("qbittorrent",pid=141330,fd=40))
udp UNCONN 0 0 [fe80::e60d:36ff:fe77:fc9a]%wlan0:34532 [::]:* users:(("qbittorrent",pid=141330,fd=38))
udp UNCONN 0 0 [2804:4d98:153:5200:e60d:36ff:fe77:fc9a]%wlan0:34532 [::]:* users:(("qbittorrent",pid=141330,fd=36))
udp UNCONN 0 0 [::1]%lo:34532 [::]:* users:(("qbittorrent",pid=141330,fd=34))
tcp LISTEN 0 30 127.0.0.1%lo:34532 0.0.0.0:* users:(("qbittorrent",pid=141330,fd=24))
tcp LISTEN 0 30 192.168.1.6%wlan0:34532 0.0.0.0:* users:(("qbittorrent",pid=141330,fd=30))
tcp LISTEN 0 30 172.17.0.1%docker0:34532 0.0.0.0:* users:(("qbittorrent",pid=141330,fd=32))
tcp LISTEN 0 30 [fe80::2c9a:f8ff:fe0b:6f00]%veth841369c:34532 [::]:* users:(("qbittorrent",pid=141330,fd=41))
tcp LISTEN 0 30 [fe80::e60d:36ff:fe77:fc9a]%wlan0:34532 [::]:* users:(("qbittorrent",pid=141330,fd=37))
tcp LISTEN 0 30 [fe80::42:fff:fe22:2ebb]%docker0:34532 [::]:* users:(("qbittorrent",pid=141330,fd=39))
tcp LISTEN 0 30 [2804:4d98:153:5200:e60d:36ff:fe77:fc9a]%wlan0:34532 [::]:* users:(("qbittorrent",pid=141330,fd=35))
tcp LISTEN 0 30 [::1]%lo:34532 [::]:* users:(("qbittorrent",pid=141330,fd=28))
qBittorrent is doing something around 10KiB/s - 30 KiB/s in my local network with different torrents even if they have multiple seeders available. Testing qBittorrent outside the cluster shows that the network can delivery much more (something around ~1MiB/s).
In close inspections looks like it is having problems with P2P connections, only one or two from Canada are usually working while outside the cluster for the same torrents we have many connections from different countries.
I don't know what could be involved, When the client connect to the swarm it start downloading from 1/2 seeders maximum, but other connections seems to be denied or there is some sort of limitation. After some reading looks like to be more successful as part of the swarm, letchers also need to be able to connect to our client, the problem is that the know IP of qBitorrent pod to qBitorrent is not the same of the cluster nodes + nodePort.
Or maybe the problem is related to another thing.