High UDP packet rate overhead / many STUN binding requests / many UDP sockets

[T-X]

The mtgatool-desktop application seems to generate a lot of very small UDP packets. After 15 hours of uptime I'm seeing:

• Packet Rate: 150pkts/s
• Bitrate: 80kbit/s
• Per Packet Size: 62 bytes for IPv4, 82 bytes for IPv6
• Type: STUN Binding Request

Furthermore it seems this is one STUN binding request per STUN server (two for IPv4, one for IPv6) and for each UDP socket mtgatool-desktop opens, with a 10 seconds interval.

Next it seems that this number of open UDP ports increases linearly over time? After 45min of uptime I'm seeing ~800 open UDP sockets from mtgatool-desktop according to netstat on Linux. Which results in this management overhead increasing linearly over time?

So I'm wondering is there maybe some socket cleanup bug?

[T-X]

Actually it's only increasing linearly during the first 3000 seconds / 50 minutes. After that the STUN traffic stays constant, and the number of UDP ports used by mtgatool-desktop stays at ~1000:

Captured via Wireshark, filtered for "udp.dstport == 19302 or udp.dstport == 3478".

[Manwe-777]

Thats great tooling for capturing the UDP connections, thank you! this should help me monitor this leak thats been haunting me.
Basically what you are seeing is the WebRTC connections, we make a lot of tries to stay connected to peers, but those eventually drop or are simply unused, so aparentyl they are not being cleared out correctly.
Also this is why you are seeing only one peer using TCP, thats my server, the only one annoucning itself trough TCP at the moment. Webrtc goes beyond NATs but is has this issue of not being very good at multiple connections, and TCP has the NAT issues where, if you do not holepunch or port forward, you cant connect. I decided I do not want to holepunch with the client, especially if I want to make this browser-compatible.

People who want to host their own servers are welcome though, they will just need to port forward to host and clients will be able to find them trough torrent trackers, so it is as decentralized as it could be, since no one can really tamper user's data.

[Manwe-777]

#50