WebRTC, TURN, DTLS are all the acronyms I could find.
https://www.raspberrypi.com/news/raspberry-pi-connect/
Tries mDNS/WAN then STUN then fallsback on TURN
https://forums.raspberrypi.com/viewtopic.php?p=2221244
https://www.raspberrypi.com/news/raspberry-pi-connect/
What happens under the hood?
I asked Paul Mucur, who runs web development at Raspberry Pi, to explain how the underlying technology works:
When you use Raspberry Pi Connect from a web browser to connect to your Raspberry Pi device, we establish a secure peer-to-peer connection between the two using WebRTC: the same real-time communication technology that underpins the in-browser clients for Zoom, Slack, Microsoft Teams, and Google Meet.
Our “rpi-connect” daemon for Raspberry Pi OS is responsible for listening out for new screen sharing sessions from the Raspberry Pi Connect website, and negotiating the best possible (i.e. lowest latency) connection between the in-browser VNC client and a VNC server running on your device. In general, once a connection is established, no traffic need pass through our servers.
If for any reason it is not possible to establish a direct connection between your browser and Raspberry Pi device, rpi-connect and your browser may instead opt to securely relay traffic through our servers, encrypting it with DTLS.
Peer-to-peer and relayed connections
At the moment, the Raspberry Pi Connect service has just a single relay (TURN) server, located in the UK. This means that if rpi-connect chooses to relay traffic, the latency can be quite high. Hovering over the padlock icon in your browser while connected will reveal whether your connection is being relayed or not, so you can tell whether changes to your networking setup might improve connectivity.
Tries mDNS/WAN then STUN then fallsback on TURN
https://forums.raspberrypi.com/viewtopic.php?p=2221244
When your device advertised its addresses, these included a full digest of connectable endpoints - local direct, local mDNS, WAN via STUN and TURN. When your browser advertised its addresses, however, due to browser security models it was not able to advertise local 'direct' addresses.
And so you wind up with a mixed-mode connection: The browser could see the device's local-direct address, so connected to that without going through another server. As expected. The device failed to utilise the mDNS address (most likely failing to resolve the supplied name), apparently then failed to STUN, and fell back to TURN.
Statistics: Posted by bensimmo — Mon Jul 01, 2024 8:03 am