If you're looking to do "pure" P2P in the browser, we're not there yet as we cannot accept incoming connections without something in between right now.
This isn't a limitation of PeerJS or event WebRTC. This is a limitation imposed by IPv4 implementations that include NAT and PAT. These services in the middle are there to create tunnels as a mutually available broker for all concerned end points. Even after the connection is established additional third party services are still required for authentication, identity management (trust/certificates/keys), and possibly codec resolution.
If all parties were IPv6 first they would still need the secondary services mentioned above, but they could likely broker a direct peer-to-peer connection without a separate service provider.
It very much is a limitation of WebRTC. Real sockets perform better than webrtc since they can attempt NAT traversal or talk to the CPE to perform port forwarding, something that you can't do from a browser. Otherwise p2p filesharing wouldn't work. You may not get perfect connectivity this way since not all NATs can be bypassed but on the other hand webrtc does not work at all without signalling.
Sockets, TCP sockets, are TCP packets in a stream of a given format. TCP is layer 4. IP is layer 3. Other socket protocols are layer 7 or an implementation of UDP.
That being said there is no bypassing of NAT, but you can tunnel through it provided an open connection from within the network. For example HTTP cannot connect to a computer inside a NAT network but it can send a response to a request from inside that network.
Most P2P services make use of a central server to connect users no differently from instant messaging, and thus these services are generally considered a backdoor into a network. BitTorrent is different because it makes use of two protocols doing different things simultaneously.
The approaches don't always work, but often are sufficient for consumer grade routers.
> For example HTTP cannot connect to a computer inside a NAT network but it can send a response to a request from inside that network.
Well yeah, that's HTTP. It's a client-server protocol. There is no coordination in connection setup. And it's TCP. It's not designed to do the necessary gymnastics to establish incoming connections through a NAT. So HTTP being HTTP is not an argument for NAT traversal being impossible.
a) it's much easier with UDP where you can multiplex incoming and outgoing traffic over a single socket and it'll work for any remote peer as long as your UDP NAT uses EIMs.
If you do your homework you quickly find out that a signaling server is required (it’s written into the WebRTC spec itself) and that STUN/TURN is needed for NAT traversal. You should use your common sense and not want to lean on public shared offerings of either of those IMO, and the PeerJS docs do call this out
Right, it’s called a signaling server, which is mainly what PeerJS seems to be. You need a method of connecting peers through the signaling server, they decided on generating uuids that are shared out of band or through a peer discovery api. You can do this pretty much however you want, the spec doesn’t clarify at all by design.
No affiliation with them, but we've had decent success with Twilio hosting our STUN/TURN (https://www.twilio.com/stun-turn). We still host the signaling server ourselves since it has negligible bandwidth/cpu requirements.
Yeah, and a bunch of other caveats, hence my ask to look into the specific technologies to understand more how it works, and why it works the way it works.
And while it's true that you don't strictly need a server for signalling, most people would expect a library called PeerJS to work P2P over the internet, without requirements to have a speaker/microphone and also without having to be within speaker/microphone range.
WebRTC is complicated, it can be frustrating to get into!
If you have a chance take a look at https://webrtcforthecurious.com it is a CC0/Free book I am writing. Would love your opinion and if it helped at all. I also try and write https://github.com/pion/webrtc in a way that others can learn from it. I put all the specific tech in different repos so people can see the big picture.
Yes, one huge challenge of P2P over the internet is piercing the NAT veil of ignorance. WebRTC hides this complexity, but I found it highly informative to read about how NAT traversal works even if I'll never touch this mess in my line of work -> https://tailscale.com/blog/how-nat-traversal-works/
Reliable NAT traversal is what propelled Skype to fame and billions back in the day, and was later codified by the VoIP folks at the IETF into STUN/ICE and TURN. WebRTC is basically a VoIP client with JS API built into the browser.
While it does go down from time to time and can't be relied on for a serious product, I've had a couple fun projects using that server for nearly 5 years now, without having to touch anything.
It's still great that they provide this service. I'm curious if anyone else is hosting a slightly more reliable public server as alternative.
When you say "we're not yet there" what do you think would be the best step forward? Currently you need a server in the middle because your home router isn't opened up to the public internet. Would that be the answer? Opening up your routers to the internet?
I don't see one myself; at the very least, you need a signalling server. Under ipv6, there is less NATing involved, but you're still going to have problems with firewalls.
That's where the signaling comes in, the "caller" generates an "offer" and this has to be relayed to the other end(s). from there, the clients take that and generate an answer that links the two.... the offer / answers include all of the ip info the machine can generate, but on a nat network that's really just only as far as your local gateway, your ipv6 addresses, etc...
you need a STUN server to add in the parts that would include your external ip... that's really all stun does is some service further up the network to give a more reachable address..
Tested this a couple of years ago and Chrome prevented WebRTC connections from ever establishing if you're not connected to internet proper (it was doing some lookup to a Google domain before trying to actually create the WebRTC connection, even if I had nothing to do with Google, and stopped the attempt if it couldn't connect). Might have changed by now.
That might have been Google's STUN server? If this was required at one time this is now fixed! getUserMedia requires a secure domain (HTTPS or localhost) so LAN only video calls are kind of a PITA.
You can easily do DataChannel only. For dev work I have a signaling server on a Class C address. Just for testing interop on Safari with my Linux box running signaling and WebRTC agent.
If memory serves me right it's a security issue, webrtc only allows connections when proper ssl certs exist on the initial brokered handshake, so you would only be able to do this if your lan has some sort of self signed ssl root cert and the cert placed in each machines authoritative cert stash.
WebRTC doesn't use any public CA certificates to my knowledge. DTLS-SRTP uses self-signed certificates on both sides, with the certificate hashes or key fingerprints being included in the SDP signalling messages.
Maybe you're thinking of the "secure origin" requirement? (The page hosting the JS needs to be a "trusted context", i.e. no file:// and no http://)
You need at the very least, a mechanism to exchange ice candidates, data on which ip/port/protocol are available on each peer.
So if u had a web server on that lan, yes. Otherwise u need a mechanism like QR codes or sneaker net a floppy disk with the details to the other peers.
This is the assumption I had as well last time I tried it, but it's not like that, at least last time I tried it a couple of years ago. Might have changed by now.
If you're looking to do "pure" P2P in the browser, we're not there yet as we cannot accept incoming connections without something in between right now.