Despite how awesome WebRTC is, every time I see it my mind instantly goes to whether I understand STUN/TURN enough. They're part of the overall concept of ICE (Interactive Connection Establishment)[0], and STUN is a protocol for negotiated direct peer-to-peer connections[1] whereas TURN[2] is a relay mode that is used when a direct connection cannot be achieved for either side.
When I saw the claim "without the need of a third party", it didn't fit with my knowledge of WebRTC so I went spelunking through the code and found that they do indeed use a STUN server[3], in particular google's "stun.l.google.com:19302".
Just want to point out to those who might be relatively new to WebRTC, p2p mechanisms, etc -- it is surprisingly hard for two computers to talk to each other over the wide internet, even in this day and age. Even if you're behind the same router things aren't necessarily straight forward.
[EDIT] - Also note that in the case of TURN, it is up to the application layer to encrypt communications[4].
> it is surprisingly hard for two computers to talk to each other over the wide internet, even in this day and age
Only if both are behind NAT without forwarded ports and even then you can just use services like this[1] if you want to send files/data and it's super easy.
> Even if you're behind the same router things aren't necessarily straight forward.
There's no TURN server specified, and I'm not 100% sure whether the one that's specified there (Google's) does both (so if STUN didn't work, would it fail or attempt TURN?).
It can be useful if your transmitting data between two different clients on two different networks. In this case, you don't need to open ports on your firewall nor change your network configuration :)
I actually did such kind of experiment recently [0]. As a bonus, the users do not have to copy/paste the SDP data manually - instead it is transmitted through sound!
Yup, it can be done! Actually, it's one of my next objectives for it. I started to write a front-end client, with WebAssembly.
It's not fully working yet, but you can take a look at it here:
https://github.com/Antonito/gfile/tree/master/_client/web
Heh can't tell you how many times I've used that python http server. Sure enough no matter the OS if Python is installed, it gives me the edge if I can access machines behind the same network.
croc currently doesn't do peer-to-peer with WebRTC, but I've actually been working on a branch that does. [1] Currently, croc uses a rendezvous server unless you happen to be on the same local network.
Thanks to Antonito (and their usage of MIT license) I'll fork their code into croc so it can do WebRTC with a secure PAKE channel.
I'm not a fan of Go. If anyone is interested in developing a Rust equivalent of this (all Rust with no C/C++ deps) I'm willing to pay for it, contact me at andrew.forsure@gmail.com (end result can be opensource)
As someone who is personally a great fan of Rust, I have to say that this is a very defective attitude.
If you're not writing it yourself (WebRTC is super simple, and this tool is basically the absolute bare-bone example of it—make a pipe and transfer something over it), why in the world would you care about what language it is written in beyond whether the language is safe, performant enough, and not a nightmare to execute on the target PC?
If you're not making it, you don't get to pick the tools. Paying just to get decide tools for other people also seems like a really weird thing to do.
> If you're not making it, you don't get to pick the tools. Paying just to get decide tools for other people also seems like a really weird thing to do.
I'm making it, I'm a dev (but focused on other projects). I want a specific solution that I can use from my projects. That's why I have technical requirements, not functional ones.
Transfer is done via DTLS, a protocol on top of UDP, so we have to deal with packet loss and retransmission, which itself is controlled by SCTP.
gfile uses pion/sctp[0] (via pion/webrtc[1]), and there has been some work going on to improve performances. :)
The performances used to be far worse, but with the recent improvements on pion/sctp, I felt gfile had become fast enough to be useful to some people.
It's not so much "hey mom I want that too", but that I've been looking for a similar solution, but written in a decent language that I can consume from my app.
When I saw the claim "without the need of a third party", it didn't fit with my knowledge of WebRTC so I went spelunking through the code and found that they do indeed use a STUN server[3], in particular google's "stun.l.google.com:19302".
Just want to point out to those who might be relatively new to WebRTC, p2p mechanisms, etc -- it is surprisingly hard for two computers to talk to each other over the wide internet, even in this day and age. Even if you're behind the same router things aren't necessarily straight forward.
[EDIT] - Also note that in the case of TURN, it is up to the application layer to encrypt communications[4].
[0]: https://en.wikipedia.org/wiki/Interactive_Connectivity_Estab...
[1]: https://en.wikipedia.org/wiki/STUN
[2]: https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_...
[3]: https://github.com/Antonito/gfile/blob/v0.1.0/internal/sessi...
[4]: https://stackoverflow.com/questions/23085335/is-webrtc-traff...