Re: [tor-dev] Introducing Snowflake (webrtc pt)

[Serene <keroserene@xxxxxxxxxx>]

On Mon, Jan 25, 2016 at 2:53 PM, Yawning Angel <yawning@xxxxxxxxxxxxxxx> 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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev