3 ms·

There's an old school tutorial here: https://secure.emergencevector.com/tutorial/ https://secure.emergencevector.com/tutorial/ If you can't figure out how to

There's an old school tutorial here: https://secure.emergencevector.com/tutorial/ https://secure.emergencevector.com/tutorial/ If you can't figure out how to make it into Hyperspace, you are officially a weakly interacting massive particle! :D Everything is client-server, client wins, except for one thing. (Left as an exercise.) WebRTC is only there as a substitute for UDP.

crucio 9y ago
Ahh nice, sounds like a good setup. Did you use an open source library for the server side part of WebRTC? I'm super interested in having a play with a good implementation if you have any tips..
- stcredzero 9y ago
  I used some variation of node-electron. Here is the top of the node server file: var wrtc = require('electron-webrtc')({ headless: true }); var SimplePeer = require('simple-peer'); var requestify = require('requestify'); var dgram = require('dgram'); The Go server uses UDP to talk to one of the 4 node server processes, which are running instances of Chromium under xvfb under tmux. There's a lot of code load overhead for the 4 processes, in terms of a lot of Chromium loaded but not running, but EC2 servers are RAM heavy, so not an issue. I haven't looked into exploiting the new true headless mode in Chrome yet, which should simplify things a lot. I'm also thinking of doing a full port to Go for WebRTC. That's a lot of stuff, however.
  - crucio 9y ago
    Ahh interesting, thank you for that. That's an interesting point re headless mode in Chrome (and Firefox now I guess!). It's a shame there's not an easier way though yet..
AlexMax 9y ago
> WebRTC is only there as a substitute for UDP. I knew that this was possible in theory, but my experience with messing around with the available serverside WebRTC libraries gave off a similar first impression to the one you mention in your blog, namely immature libraries. Looking forward to your blog post on your experiences with Datachannel.
stcredzero 9y ago
Everything is client-server, client wins, except for one thing. I had the polarity reversed. It's actually client-server, server wins.

crucio 9y ago

Ahh nice, sounds like a good setup. Did you use an open source library for the server side part of WebRTC? I'm super interested in having a play with a good implementation if you have any tips..

stcredzero 9y ago
I used some variation of node-electron. Here is the top of the node server file: var wrtc = require('electron-webrtc')({ headless: true }); var SimplePeer = require('simple-peer'); var requestify = require('requestify'); var dgram = require('dgram'); The Go server uses UDP to talk to one of the 4 node server processes, which are running instances of Chromium under xvfb under tmux. There's a lot of code load overhead for the 4 processes, in terms of a lot of Chromium loaded but not running, but EC2 servers are RAM heavy, so not an issue. I haven't looked into exploiting the new true headless mode in Chrome yet, which should simplify things a lot. I'm also thinking of doing a full port to Go for WebRTC. That's a lot of stuff, however.
- crucio 9y ago
  Ahh interesting, thank you for that. That's an interesting point re headless mode in Chrome (and Firefox now I guess!). It's a shame there's not an easier way though yet..

AlexMax 9y ago

> WebRTC is only there as a substitute for UDP. I knew that this was possible in theory, but my experience with messing around with the available serverside WebRTC libraries gave off a similar first impression to the one you mention in your blog, namely immature libraries. Looking forward to your blog post on your experiences with Datachannel.

stcredzero 9y ago

Everything is client-server, client wins, except for one thing. I had the polarity reversed. It's actually client-server, server wins.