When I configured the `bind_address` to `[::]:6969` to listen on both IPv4 and IPv6 addresses simultaneously, the tcp4 and udp4 in the HTTP API both showed 0

[devnakx]

When I configured the bind_address to [::]:6969 to listen on both IPv4 and IPv6 addresses simultaneously, the tcp4 and udp4 in the HTTP API both showed 0 and I am sure there are IPv4 requests coming in.

Alternatively, these addresses prefixed with ::ffff: should be counted in tcp4 or udp4, as they are actually requests made through IPv4 addresses.

Additionally, I feel that the current statistics in the HTTP API are not very detailed. I believe that the statistics provided in the bittorrent-tracker's HTTP API are much clearer. Like:


I think could consider incorporating similar into Torrust.

[josecelano]

Hi @devnakx thank your for sharing it!

When I configured the bind_address to [::]:6969 to listen on both IPv4 and IPv6 addresses simultaneously, the tcp4 and udp4 in the HTTP API both showed 0 and I am sure there are IPv4 requests coming in.

Alternatively, these addresses prefixed with ::ffff: should be counted in tcp4 or udp4, as they are actually requests made through IPv4 addresses.

I guess you have something like this in your configuration:

[[udp_trackers]]
bind_address = "[::]:6969"

[[http_trackers]]
bind_address = "[::]:7070"

We don't support directly Dual-Stack Sockets in the application. I'm not an expert in this, so I'm not sure but I guess two sockets are actually being created, one of them bound to IPv4. The requests from IPv4 clients are captured by that socket and "redirected" to the IPv6 bound socket with the new IPv6 IP. For example, when you make an announce requests locally with the tracker client:

cd ./console/trackerclient/ && cargo run --bin udp_tracker_client announce udp://127.0.0.1:6969 9c38422213e30bff212b30c360d26f9a02136422

The debug log output is:

2025-03-10T16:08:44.994125Z DEBUG process_request:handle_packet{local_addr=[::]:6969 request_id="eea5bc69-4980-4efa-9103-6121708a80ea"}: torrust_udp_tracker_server::handlers: Handling Packets: RawRequest { payload: [0, 0, 4, 23, 39, 16, 25, 128, 0, 0, 0, 0, 203, 5, 94, 7], from: [::ffff:127.0.0.1]:56352 }

Although you can map the IPv4 IP to an IPv6, from our stats point of view it's only an IPv6 IP.

I guess we could include a new configuration option to increase ONLY the IPv4 counters when the IPv6 IP is prefixed with ::ffff:

Or do your think it should be the default behavior without adding any config option? @da2ce7 @devnakx

Additionally, I feel that the current statistics in the HTTP API are not very detailed. I believe that the statistics provided in the bittorrent-tracker's HTTP API are much clearer. Like: I think could consider incorporating similar into Torrust.

I think there are reasonable and easy to add. I think I can open a new sub-issue in the Overhaul Stats Events EPIC to include the new ones.

FYI, we are planning to get rid off the global metrics. That means the new metrics will be there but only per service (socket address).

[devnakx]

I am very pleased to receive your reply and I greatly appreciate your detailed response. I will continue to look forward to it!🥰

[josecelano]

Hi @devnakx, I've just merged one of the three features mentioned in this issue:

• Inactivity metrics
• Overhaul stats: Add the PeerClient and version as labels to metrics #1456
• Overhaul stats: Increase IPv4 stats for IPv6 IPs with the prefix ::ffff: #1375

curl -s "http://localhost:1212/api/v1/metrics?token=MyAccessToken&format=prometheus"

torrent_repository_peers_inactive_total{} 0
torrent_repository_torrents_inactive_total{} 0

torrent_repository_ is the package prefix.

They are only included in the new endpoint for now. However, I'm considering keeping the current /stats endpoint, which might be simpler for most users' needs. If we keep it, I will add these metrics too. I won't do it now because that could be a breaking change for some API clients.