I'm the guy that made Agar.io, Diep.io and a few smaller games. I analyzed the possibility of using WebRTC in my games several times so far, but it seems that right now, it's still hard to use in a server-client architecture. You need to bring this [1] behemoth and all of its dependencies to your project dependencies on the server side, even though you only care about a tiny bit of it (unreliable data channels). It's unlikely that people will start using it until there is an easy stripped-down version that only deals with data channels.
Hi, I'm a member of the WebRTC team at Google, and I wrote a lot of the data channel and network code that's part of that behemoth.
I'm glad you got this to work :). I've always hoped someone would do exactly what you've done (use the data channel code on a server to do low-latency client<->server communication).
We're aware of the difficulty and are actively working on making it easier to work with just he components you need for data channels (ICE, DTLS, and SCTP). It might take a while, but it's one of our goals.
Haha, whoa, I feel like I've spotted a celebrity! I mentor a kid here in rural Missouri and he and his friends play agar and diep. I don't know how they found them way out here, but they did and they love them (especially diep).
Anyway, I've been idly thinking of ways to try to kindle an interest in programming in the guy, since he's very smart and seems to like computers. I played Cookie Clicker with him, and then showed him how to "hack" it from the console by playing with the JS a little bit (it's all local).
But since he loves diep so much I think that would really give him motivation to learn more if he could fiddle with things in that game somehow. But I realize it's harder given that it's a client/server model. I don't suppose you have any ideas of things we could try? Is there a client-only mode where we can fiddle in the console? Or is the server code open source so I could run it locally or something?
Oh, ha, and something that's been killing me... why's it called "diep"?
Care to share a bit about technical side of agar.io? I've played it a bit (yeah right, a bit..) and I've been wondering how did you manage to make it so smooth without also introducing conflicts between clients (I mean e.g. on my side B ate A but somebody else sees C eating A). There is lag sometimes but I've never encountered "glitching" where position calculated locally would have to be visibly adjusted to what came from the server.
Also if it's not a secret what backend did you use to handle so many concurrent connections and how many were you able to keep per box?
How much of a gap is remaining until stripped-down data channels libraries like librtcdcpp (C++) [0] and librtcdc (Python) [1] could be suitable for production? Is anyone here using one of these in production today?
I think calling WebRTC a behemoth is a bit of an understatement. Excuse my sharp-tongued criticism, since I understand a lot of hard work has gone into it, but WebRTC has no regard for interoperability. As of now, it is nothing more to me than a VPN deanonymizing exploit.
WebRTC leaks true IP addresses unless it is outright disabled in [supported] browsers. It is a huge annoyance, and I would be hard-pressed to view it as more than a gimmick that complicates the already messy landscape of web development.
Do you adapt the amount of data sent based on the bandwidth? If so, how?
To me the best way to do this involve knowing how often the TCP socket is doing retransmissions, which is an information typically not available at the WebSocket level.
We've been using WebRTC Datachannels for multiplayer gaming in the browser in our game editor Construct 2 (www.scirra.com) for a couple of years now. Generally they work great! However the main problem we have is switching tab suspends the game, which if you're acting as the host, freezes the game for everybody. This is really inconvenient. There ought to be some way to exempt tabs with WebRTC connections from being suspended. I filed a bug for it here: https://bugs.chromium.org/p/chromium/issues/detail?id=676036
Wait can you do a pop out window? That way it's always open and can't have multiple tabs. The main tab can control the pop out to kill the data channel ...
When I started development WebRTC wasn't very well supported, now I am considering using a hybrid. I already use two websockets, one for binary state snapshots and the other for JSON important updates like entity creation and chat. It would be interesting to implement WebRTC to my servers just for the state snapshots.
I've been using https://github.com/keroserene/go-webrtc for a couple of prototypes, it's not pure-Go but bindings against the C++ implementation but it works (what little of it that is exposed).
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:
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.
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.
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.
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 :).
Not until server-side implementations exist. Depending on the physical location and amount of data being replicated, you'll need the flexibility to move master-game simulation logic from dedicated server to shared client. WebRTC works great if you're doing p2p among browsers, which severely limits the kinds of multiplayer experiences you can create.
I love WebRTC and think it's great. I studied and read all related RFCs and tried implementing a stack in JavaScript for Node.js. Got stuck on DTLS, then switched jobs.
I do think WebRTC is "the future," but we don't seem to be moving AT ALL towards that future. Having multiple implementations would move the needle. Otherwise, there was this big leap forward when it was developed and added to browsers, but not much since.
I think WebRTC is secure by default and everything is supposed to be encrypted and served over https...Chrome for example doesn't allow unsecure usage of the API's. See this for more: http://webrtc-security.github.io
In terms of plain and direct security holes in WebRTC, there is an extended attack surface. But your browser has this enabled anyway, no matter what you as an application developer or end user do.
In terms of security properties delivered to the application/end user, there are security and privacy advantages in end-to-end communication instead of involving servers. But it all depends on your use case and threat model.
Just read the docs. WebRTC data channels are SCTP which is built on DTLS (datagram transport layer security) which uses the identical algorithm as TLS for encrypting traffic. It's as secure as TLS is, and hopefully you're using 1.2 or so.
WebRTC Datachannels are awesome, I've always thought they could be leveraged for efficient peer to peer gaming but this is definitely interesting as well.
Getting started with webrtc datachannels is easy and you can even have your server in Python Flask, but keep in mind you'll have to handle multiple concurrent connections.
The data channel seems like one of the most under-utilized features for WebRTC. On our platform we've seen a handful of companies develop RT games and applications. Nice to see people developing applications other than AV applications.
Going to also shamelessly promote our webrtc platform www.temasys.io It has very strong support for data channel, and socket messaging.
Note that signaling for WebRTC is still recommended to be sent over HTTPS! Signaling (before the p2p connection is fully negotiated) can be eavesdropped if not done properly.
WebRTC is a technology. It is not an application, and cannot replace applications.
In the cases of some of those applications, it could conceivably be used to implement future versions of those applications -- but that certainly doesn't equate to "killing" them.
[+] [-] Matheus28|9 years ago|reply
[1] https://chromium.googlesource.com/external/webrtc
[+] [-] pthatcherg|9 years ago|reply
I'm glad you got this to work :). I've always hoped someone would do exactly what you've done (use the data channel code on a server to do low-latency client<->server communication).
We're aware of the difficulty and are actively working on making it easier to work with just he components you need for data channels (ICE, DTLS, and SCTP). It might take a while, but it's one of our goals.
[+] [-] losvedir|9 years ago|reply
Anyway, I've been idly thinking of ways to try to kindle an interest in programming in the guy, since he's very smart and seems to like computers. I played Cookie Clicker with him, and then showed him how to "hack" it from the console by playing with the JS a little bit (it's all local).
But since he loves diep so much I think that would really give him motivation to learn more if he could fiddle with things in that game somehow. But I realize it's harder given that it's a client/server model. I don't suppose you have any ideas of things we could try? Is there a client-only mode where we can fiddle in the console? Or is the server code open source so I could run it locally or something?
Oh, ha, and something that's been killing me... why's it called "diep"?
[+] [-] comboy|9 years ago|reply
Also if it's not a secret what backend did you use to handle so many concurrent connections and how many were you able to keep per box?
[+] [-] gkop|9 years ago|reply
[0] https://github.com/chadnickbok/librtcdcpp
[1] https://github.com/xhs/librtcdc
[+] [-] TerselyCogent|9 years ago|reply
WebRTC leaks true IP addresses unless it is outright disabled in [supported] browsers. It is a huge annoyance, and I would be hard-pressed to view it as more than a gimmick that complicates the already messy landscape of web development.
[+] [-] gafferongames|9 years ago|reply
[+] [-] getkey|9 years ago|reply
To me the best way to do this involve knowing how often the TCP socket is doing retransmissions, which is an information typically not available at the WebSocket level.
[+] [-] bcjordan|9 years ago|reply
[+] [-] hellbanner|9 years ago|reply
OT question.. how much $ do you make on those?
[+] [-] Jimmy24|9 years ago|reply
[deleted]
[+] [-] Jimmy24|9 years ago|reply
[+] [-] AshleysBrain|9 years ago|reply
[+] [-] est|9 years ago|reply
[+] [-] taf2|9 years ago|reply
[+] [-] rayboy1995|9 years ago|reply
When I started development WebRTC wasn't very well supported, now I am considering using a hybrid. I already use two websockets, one for binary state snapshots and the other for JSON important updates like entity creation and chat. It would be interesting to implement WebRTC to my servers just for the state snapshots.
[+] [-] azurelogic|9 years ago|reply
[+] [-] DrJones1098|9 years ago|reply
[+] [-] latenightcoding|9 years ago|reply
[+] [-] mfukar|9 years ago|reply
[+] [-] bratsche|9 years ago|reply
[+] [-] pthatcherg|9 years ago|reply
[+] [-] shurcooL|9 years ago|reply
[+] [-] shazow|9 years ago|reply
[+] [-] pthatcherg|9 years ago|reply
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 :).
[+] [-] ndesaulniers|9 years ago|reply
I love WebRTC and think it's great. I studied and read all related RFCs and tried implementing a stack in JavaScript for Node.js. Got stuck on DTLS, then switched jobs.
I do think WebRTC is "the future," but we don't seem to be moving AT ALL towards that future. Having multiple implementations would move the needle. Otherwise, there was this big leap forward when it was developed and added to browsers, but not much since.
[+] [-] SCdF|9 years ago|reply
How much does this sort of thing (and the hardware / capability it's running on) change in 20 years? I wonder if it's worth revisiting.
[1] https://www.isoc.org/INET97/proceedings/F3/F3_1.HTM
[+] [-] k__|9 years ago|reply
I like the idea of P2P and UDP for better latency.
But how dangerous is this?
[+] [-] jaypaulynice|9 years ago|reply
[+] [-] man5quid|9 years ago|reply
A great series for you to read.
tl;dr
Udp is good. client to client sessions are terrible over the internet.
[+] [-] fulafel|9 years ago|reply
In terms of plain and direct security holes in WebRTC, there is an extended attack surface. But your browser has this enabled anyway, no matter what you as an application developer or end user do.
In terms of security properties delivered to the application/end user, there are security and privacy advantages in end-to-end communication instead of involving servers. But it all depends on your use case and threat model.
[+] [-] banachtarski|9 years ago|reply
[+] [-] flamedoge|9 years ago|reply
[+] [-] omginternets|9 years ago|reply
[+] [-] browseatwork|9 years ago|reply
I don't think WebRTC is ready yet for games, too much complexity on the server side.
Instead, he's using websockets for his web game.
Disclosure: we work for a WebRTC company.
[+] [-] suhith|9 years ago|reply
Getting started with webrtc datachannels is easy and you can even have your server in Python Flask, but keep in mind you'll have to handle multiple concurrent connections.
Here's a simple file sharing demo I made a while ago https://github.com/suhithr/CampFile
[+] [-] yeldarb|9 years ago|reply
[+] [-] kosinus|9 years ago|reply
Safari currently lacks support everywhere.
http://caniuse.com/#feat=rtcpeerconnection
[+] [-] sherwinsim|9 years ago|reply
Going to also shamelessly promote our webrtc platform www.temasys.io It has very strong support for data channel, and socket messaging.
[+] [-] ceejay|9 years ago|reply
Not sure status of this standard, or plans for adoption. As long as proper steps are taken to allow for secure implementations I'm all for it.
[+] [-] vvanders|9 years ago|reply
Is that still the case or do the guarantee a non-blocking protocol?
[+] [-] nitwit005|9 years ago|reply
[+] [-] ARCarr|9 years ago|reply
Depends what kind of game you're making.
[+] [-] TD-Linux|9 years ago|reply
[+] [-] bullen|9 years ago|reply
[+] [-] hardwaresofton|9 years ago|reply
[+] [-] fredliu|9 years ago|reply
Does anybody have any experience using WebRTC out of the browser context? E.g. using Android's webRTC lib without using a browser?
[+] [-] bluetwo|9 years ago|reply
[+] [-] duskwuff|9 years ago|reply
WebRTC is a technology. It is not an application, and cannot replace applications.
In the cases of some of those applications, it could conceivably be used to implement future versions of those applications -- but that certainly doesn't equate to "killing" them.
[+] [-] trevyn|9 years ago|reply