[tor-bugs] #33897 [Circumvention/Snowflake]: Remove buffering from WebRTCPeer

[Tor Bug Tracker & Wiki]

#33897: Remove buffering from WebRTCPeer
-------------------------------------+------------------------------
 Reporter:  dcf                      |          Owner:  dcf
     Type:  enhancement              |         Status:  needs_review
 Priority:  Medium                   |      Milestone:
Component:  Circumvention/Snowflake  |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:  turbotunnel              |  Actual Points:
Parent ID:                           |         Points:
 Reviewer:  cohosh                   |        Sponsor:
-------------------------------------+------------------------------

Comment (by cohosh):

 Cool! I like how much this simplifies the client-side code.

 The code looks good. My only comment is:
 - `broker.Negotiate()` can still return a `nil` answer and we're no longer
 checking for that [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/client/lib/webrtc.go#n268 like we used to].
 At first glance, it looks like it '''shouldn't''' return a nil answer and
 a non-nil error, but `util.DeserializeSessionDescription`
 [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/common/util/util.go#n21 can return a nil
 value] without an error attached to it which would cause problems.

  So we should either modify `util.DeserializeSessionDescription` to return
 errors and always error if the answer is non-nil, or we should add a nil
 answer check before passing it to the pion library function
 `SetRemoteDescription`. I don't want to assume that they've written this
 function to not seg fault on us. We could also check for a nil answer in
 `Negotiate()` too.

 > I think we can set DataChannelTimeout to a lower value, to quickly
 dispose of that cannot be connected to, while still being conservative in
 discarding once-working proxies. I'm testing a browser now with
 DataChannelTimeout set to 5 seconds.
 This is great. We can also change the data channel timeout on the proxy
 side to match the client side once we've settled on a value that works for
 us.

 This should help ease the pain of clients with restrictive NATs. If we can
 shorted the time it takes for the client to realize it has an incompatible
 proxy, we can recover more quickly (hopefully).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33897#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online