#25592 closed defect (worksforme)

Consider webrtc<-->webrtc vs webrtc<-->websocket for the browser proxy

Reported by: arlolra Owned by:
Priority: Medium Milestone:
Component: Circumvention/Snowflake Version:
Severity: Normal Keywords:
Cc: dcf, arlolra Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


webrtc <-->websocket is the current situation, which works.
webrtc <--> webrtc would take a bit more work.

Quoting @Yawning,

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.


Yes, that does complicate the potential of using a second WebRTC connection to the relay...

The benefit of WebRTC on both sides should be performance / latency, whereas right now the websocket connection to the relay is most likely bottlenecking the first WebRTC data channel from the client.

But maybe it's actually not, at least significantly. It's quite possible the typical latency of the network is already most of what the user experiences compared to the websocket relay, in which case the benefit of the 2nd WebRTC would be negligible with respect to the effort of making it happen.... maybe we need to measure this (I haven't found any obvious latency numbers on metrics.torproject.org), or we could just decide not to bother and close this.

Migrated from https://github.com/keroserene/snowflake/issues/8

Child Tickets

Change History (2)

comment:1 Changed 14 months ago by dcf

In my opinion, WebSocket wins for simplicity and robustness. I don't know why WebRTC would have higher performance either (but I haven't tried it). Even WebRTC has to do a DTLS handshake, you still have overhead there.

With a WebSocket bridge, the issue of Cgo and threads doesn't come up. We only use Cgo on the client, which doesn't have to scale very much. The proxies are running in browsers, no Cgo there. (proxy-go is another story, but that's orthogonal to the protocol used for the proxy–bridge link.) And the WebSocket bridge is essentially just an HTTPS server, like meek-server, which scales pretty well.

comment:2 Changed 14 months ago by arlolra

Resolution: worksforme
Status: newclosed

Agreed, let's decline.

Note: See TracTickets for help on using tickets.