#33897: Remove buffering from WebRTCPeer -------------------------------------+-------------------------- Reporter: dcf | Owner: dcf Type: enhancement | Status: assigned Priority: Medium | Milestone: Component: Circumvention/Snowflake | Version: Severity: Normal | Resolution: Keywords: turbotunnel | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: -------------------------------------+--------------------------
Comment (by dcf): It's not enough to simply remove the buffer and drop `Write`s that occur before the data channel is established. That's because not every `Write` represents a turbotunnel packet that will be retransmitted if lost—specifically the [https://gitweb.torproject.org/pluggable- transports/snowflake.git/tree/client/lib/snowflake.go?id=6c2e3adc41c2c6d1ed794adac019a5a6eb069536#n46 magic token and ClientID] are transmitted first, notionally outside the turbotunnel layer, and can't be dropped. My plan for this ticket is to refactor `WebRTCPeer` so that `NewWebRTCPeer` never returns a partially connected object—it always gives you back something with a connected data channel that is ready to directly translate `c.Write` into `c.transport.Send`. How it works now is you get an object whose internal `transport` field (representing the data channel) is initially `nil`, and only becomes non-`nil` asynchronously some time later, while you're using it. I think this design will allow for the removal of some locks and other internal state, for overall simpler code. But it's going to take a little hack-and-slash refactoring. I've already filed #33982 and #33984 for some changes that suggested themselves while I was rewriting things. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33897#comment:1> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs