Reputation: 14490
Here's my current issue: I've been browsing multiple WebRTC resources, looking through Google experiments and likewise Mozilla ones too, but I have yet to find a simple explanation of how to do this. I'm also having trouble understanding the basic architecture of WebRTC.
What I would like to do is construct a peer-to-peer overlay, wherein each node is a browser. Each of these nodes would accept all incoming connections, and be able to connect to others using their IP address. They would communicate only over a DataChannel. Unlike many of the examples I have been reading, I would not like to rely on any server for signalling, only those necessary for subverting NAT (like STUN servers).
Could anyone explain how this might be achieved? I've been reading the resources on the WebRTC Experiments site and I need to do something with offers or something, but I'm not quite understanding.
Upvotes: 3
Views: 1501
Reputation: 1816
How you address nodes in WebRTC is totally up to you, the implementor, because signalling is - deliberately - left out of the specification. So if you'd like to address the nodes in your overlay by their IP addresses, go ahead. But I think you slightly misunderstood how connection establishment in WebRTC works, so let me dive a bit deeper:
WebRTC connection establishment is accomplished by exchanging SDP messages (http://en.wikipedia.org/wiki/Session_Description_Protocol). If you want one browser to establish a PeerConnection to another browser, you'll have to find a way to send the SDP message (generated via RTCPeerConnection#createOffer) to the other browser. There's no way to just open a UDP connection to that browser (or ICE wouldn't work).
So for a node to join the overlay network you'll have to have a central point (let's call it server) or another channel (have a look at https://github.com/cjb/serverless-webrtc/ for "server-less" WebRTC) for connection establishment. As soon as all your nodes are connected to each other via RTCPeerConnections (e.g. as a chain) you can use those connections for further connection establishment (i.e. transfer SDP offers/answers through these connections).
Back to addressing nodes via IP address: This is not a good idea because sometimes you don't even know the address (e.g. when STUN and esp. TURN come into play).
Edit to answer question in comment:
Instead of the IP address you could use sth. like a UUID (http://en.wikipedia.org/wiki/UUID). Also, you could as well use sth. like the user's e-mail address if all your users are authenticated in some way. But keep in mind that the matter of authenticating peers is still not fully specified by IETF/W3C and implementations don't exist, yet.
Upvotes: 1