Reputation: 6633
First I just understood that it won't be a pure p2p feature, it's not a socket at all, for security and DDOS purposes.
But I'm having a hard time figuring the stuff like offer, answer, SDP, ICE, STUN, etc. Seems like quite a lot of abstraction and requirement.
Does it mean it will always be required to have a website centralizing IP addresses ?
Will it make implementing DHT difficult ?
I thought it would have been some sort of socket equivalent, but it seems it's very much different and more complex.
Upvotes: 2
Views: 659
Reputation: 3489
You still need some central server to establish connection between peers.
The server should provide some signaling transport - it could be websockets, google appengine channel, or some hand-maded stuff. Clients will use this transport for communication with the server before they able establish p2p connection.
Also, you need some STUN-server to support NAT-traversal functionality - for those clients who works behind NAT (i.e. a home/office network router). You can install your own STUN server using some open source implementation. Or you can use Google's STUN server.
Actually, all this information is valid for WebRTC in general, but it is applicable to RTCDataChannel in particular.
Here you can found good example of how to use DataChannel: https://github.com/muaz-khan/WebRTC-Experiment/tree/master/DataChannel
Here you can found my example of Video chat using Erlang and Websockets for signaling protocol: https://github.com/fycth/webrtcexample
Upvotes: 2