On Mon, Jan 25, 2016 at 2:53 PM, Yawning Angel yawning@schwanenlied.me wrote:
What are your plans for getting https://github.com/keroserene/go-webrtc to build completely in a deterministic manner? The several hours isn't per platform right? (The "easy way" is not going to cut it for distribution).
Totally. Building native webrtc requires google's depot_tools, and `gclient sync` takes a long time (over an hour on my machine) because chromium. Per platform takes a few minutes.
The plan is to provide a build script which: - gclient syncs to some known & tested commit hash on a release branch. - Apply a patch to remove unnecessary video/audio webrtc media API stuff (only datachannels are needed for our use-case) This will also greatly reduce the archive size. - Build the archive we need using a custom gyp or ninja file. - Concat and copy the archive over for go-webrtc
Does that sound like a reasonable deterministic build?
What are your plans for actually getting the server side to scale well? Since you're using cgo you will run into Really Interesting behavior wrt OS threads as you try to increase concurrency.
Right now, the server side is the same websocket relay from flashproxy. Webrtc currently happens just between the client and browser proxy - this already yields all the benefits listed above (as we assume the volunteer proxy has no problem connecting to Tor)
However, it might be worth having webrtc on both sides. We already have prepared a webrtc server plugin, which the client plugin has successfully connected to directly. To use a snowflake proxy in between would require establishing two separate webrtc peerconnections per circuit. Maybe that's worth doing - but I'm not sure about the plan there, if we do decide to go that route.
Best, ~s