myip VS libjuice

Why not use protocols which are purposely designed to report mapped IP address like STUN? It's faster as UDP exchange is shorter than 3-way TCP handshake (or even TCP+TLS handshake).

Here is an implementation which uses parallel STUN queries to report address reliably as fast as possible: https://github.com/Snawoot/myip

For Windows; Try the myip binary

Try this client with public STUN servers; https://github.com/Snawoot/myip/releases/tag/v1.2.0 it has precompiled binaries for multiple platforms.

Addresses on the "far side" of a NAT aren't inherently visible to the host. The only way to find out is to reach out to an external service, and have that service report back what source IP address they see your request coming from. Usually people use a web API, but there might be other ways.

This kind of service is exactly what STUN servers are made for to be used alongside webrtc. There are a plethora of unauthenticated STUN servers around, and while there's still room for abuse, the protocol is a bit more lightweight than full-blown http requests, and faster, too!

I've dabbled with doing this on my own, but I've found `myip` to do the job nicely and without hassle:

https://github.com/Snawoot/myip

I had some auto-tests for VPN app which were relying on similar web-service to check own IP address. One day service become unavailable and autotests got broken. IIRC it was (https://canihazip.com/s)

I decided to solve this task in a fast and reliable fashion, so I made a tool which discovers own IP address using major public STUN servers: https://github.com/Snawoot/myip

Program issues parallel queries to public STUN servers to determine public IP address and returns result as soon as quorum of matching responses reached.

Works fast and reliable, especially compared to services requiring HTTPS:

  user@dt1:~> time curl https://api.ipify.org

For the client side, I've looked at https://github.com/paullouisageneau/libjuice, which looks promising. We want to to keep our server for the matchmaking, but then make additional use of a new server for the connectivity stage once players have agreed a game.

Nice, this looks like a simple and clear proof of concept!

In practice, the dependency on glib, which depends in glib, can become a practical problem for embedded devices.

That's actually why I developped libjuice [0] as the default ICE backend of libdatachannel [1].

[0] https://github.com/paullouisageneau/libjuice