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.
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.
https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API#...
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.
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.
There are several.
https://en.wikipedia.org/wiki/NAT_traversal
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.
You do not strictly need a server for signaling in some controlled environment cases (e.g. you can do signaling over sound for closeby peers).
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.
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.
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.
(I believe some ISPs may have another level of address translation on their side too...)
The signalling server is different; it proxies metadata between peers like "today, my IP is X" or "I'd like to start a call"
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..
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 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.
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.
So if you are sharing the same LAN, it does not need internet.
This is because the large IP address space make routing efficient, without the use of NAT.