I have to warn you though, the server-side WebRTC libraries are not very mature
yet. I advise you to do thorough research before building your game.
I have to warn you though, the server-side WebRTC libraries are not very mature
yet. I advise you to do thorough research before building your game.
http://grokbase.com/t/gg/golang-nuts/161wbn1vf0/go-nuts-nati...
There are two bindings for Go built on top of the WebRTC code at webrtc.org:
https://github.com/keroserene/go-webrtc https://github.com/fd/webrtc
By the way, I work on the WebRTC team at Google, and I don't think it would be that hard to write a data channel server in Go. Here's how you should do it.
1. Get an "SDP offer" from the client. Parse it mainly to get the DTLS fingerprint. You may also choose to get the SCTP max message size.
2. Open a UDP socket. Listen for incoming STUN binding requests and send back binding responses:
You can see how the WebRTC client code constructs requests here: https://cs.chromium.org/chromium/src/third_party/webrtc/p2p/...
You can see how the WebRTC client code processes responses here: https://cs.chromium.org/chromium/src/third_party/webrtc/p2p/...
Or you can read the RFC (warning: not light reading): https://tools.ietf.org/html/rfc5245
3. Once a valid STUN binding request is received, listen for DTLS packets and hand those over to BoringSSL. Also listen to when BoringSSL wants to send a packet and send those out on the UDP socket back to the client.
You can see how the WebRTC client code passes DTLS packets down to BoringSSL here: https://cs.chromium.org/chromium/src/third_party/webrtc/base...
You can see how the WebRTC client code gets packets to send from BoringSSL here: https://cs.chromium.org/chromium/src/third_party/webrtc/base...
4. Once BoringSSL finishes the DTLS handshake and is processing incoming SCTP packets, listen for those and hand those over to usrsctplib. Also listen to packets usrsctplib wants to send and hand those over to DTLS to send.
You can see how the WebRTC client code reads decrypted packets from BoringSSL here: https://cs.chromium.org/chromium/src/third_party/webrtc/base...
And how it passes them down to usrsctplib here: https://cs.chromium.org/chromium/src/third_party/webrtc/medi...
You can see how the WebRTC client code gets packets to send from usrsctplib here: https://cs.chromium.org/chromium/src/third_party/webrtc/medi...
And how it passes them to BoringSSL here: https://cs.chromium.org/chromium/src/third_party/webrtc/base...
5. Process data channel messages from usrsctplib and send data channel message through usrsctplib. Note that you can ignore the whole "OPEN message" protocol if you call PeerConnection.createDataChannel with the "negotiated: true" option on the WebRTC client side. You can specify the SID you want to use for the data channel as well.
You can see how the WebRTC client code passes messages to usrsctplib here: https://cs.chromium.org/chromium/src/third_party/webrtc/medi...
And how it receives them: https://cs.chromium.org/chromium/src/third_party/webrtc/medi... https://cs.chromium.org/chromium/src/third_party/webrtc/medi...
6. Serialize an "SDP answer" message which basically just hands back the same looking blob of text, but with a different DTLS fingerprint (the one for the certificate of the server). It also must have two random strings: the ICE username fragment (ufrag) and ICE password (pwd). If you pass that answer to the WebRTC client, all the ICE, DTLS, and SCTP work should happen and after around 6 round trips on the network, you should incoming and outgoing messages.
Ok, that probably sounds like a lot, but most of the work is done by BoringSSL and usrsctplib. The bulk of the Go code would be implementing the STUN messages and gluing everything together. Good luck to whoever tries :).