Seeing uTP peers when connected via SOCKS5 proxy

[vktr]

libtorrent version (or branch): v2.0.6 (e9bbf16bdd899f42aef0f0c2b1f214de2c15ac92) platform/architecture: linux amd64

I'm running libtorrent with a SOCKS5 proxy and I'm still seeing uTP peers. Is this expected? Here's a timeline of peers.

As expected, almost all peers are SOCKS5 but there's a few that still reports as uTP.

Edit These values are projected from the session stats, namely peer_num_tcp_peers, peer_num_utp_peers and peer_num_socks5_peers.

[vktr]

Enabling UDP traffic to the SOCKS5 proxy makes libtorrent discover more uTP peers.

I assume the uTP connections are via the SOCKS5 proxy since there are iptables rules set up to deny traffic which is not destined for the proxy.

[AllSeeingEyeTolledEweSew]

May I ask how you're getting stats into grafana? That setup looks great.

[vktr]

I expose a simple /metrics endpoint with Boost.Beast and use Prometheus to pull metrics. The metrics are simply the session stats metrics from libtorrent formatted for Prometheus (ie. key <space> value).

In practice it's a bit more involved. A JSONRPC method defined here, https://github.com/picotorrent/server/blob/feature/pika/src/rpc/sessionstats.cpp, which is called from a metrics exporter plugin here, https://github.com/picotorrent/pika-plugin-metrics/blob/main/main.go#L20.

Hope that helps 😄 Feel free to ask if anything is unclear!

I have all gauges and counters in Grafana for querying.

[arvidn]

those gauges aren't very well documented. socks5 peers refers to normal SOCKS5-TCP tunnels. uTP peers actually use the same socket type regardless of whether they go through SOCKS5 or not. The SOCKS5 proxy operates on the UDP socket directly, which is the layer below uTP. So, uTP means both normal uTP or uTP over SOCKS5. Presumably all via the proxy when you have that set up though.

those uTP connections seems pretty short lived though, so I suspect that they may be connection attempts that time out.

[arvidn]

(patches are welcome!)

[vktr]

I see! If patching, how would you want the gauges to work? Separate num_socks5_tcp_peers and num_socks5_utp_peers? And then keep the non-socks5 gauges for actual non-socks5 connections?

[arvidn]

it might make sense to separate the utp counters for socks5 peers. Things to consider:

1. It's not backwards compatible, and would need to go into master and to be documented in the upgrade document
2. When socks5 is enabled, all uTP peers are socks5 peers. So the utp and socks5_utp counters would always be mutually exclusive. One of them would always be zero.
3. Since this separation is pretty simple, it's not obvious that it belongs in libtorrent. The current counters more closely map to the implementation
4. renaming socks5_peers to tcp_socks5_peers could be done in a backward compatible way, by introducing an alias

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.