Serene Han authored 9 years ago and Arlo Breault committed 8 years ago

webRTCConn close as part of its reset, instead of depending on external deferred close after receiving reset channel, allows valid disconnections even before use

This is the relay that reports using the transport name "snowflake".
https://bugs.torproject.org/18627

Serene Han authored 9 years ago and Arlo Breault committed 9 years ago

replace webrtcRemote with webrtcRemotes map & indexing, client multiplexing remotes confirmed working (#31)

Change the transport name to "snowflake" and don't report the remote
client address to the ExtORPort.

Patch server.go to refer to out-of-tree websocket library.

From commit ea3ee6b5cf035a9465c02b4a2b38882c9c6a7050 in
https://git.torproject.org/pluggable-transports/websocket.git

To make room for the WebSocket server we're actually going to use as a
primary server. Move server-webrtc docs to server-webrtc/README.md.

That's only for very very old Firefox. Even for flash proxy it was only
relevant for a short time.

defer conn.Close for simplicity and remove unnecessary goroutines, improve error handling (close #12)

 * This will induce the tor client to establish a new SocksConn,
   which in turn will dial a new WebRTC connection.

   To be improved upon.

 * Part of #12

 Noticed a long delay after the window closed before the datachannel
 timed out.

 2016/03/18 13:53:16 Traffic Bytes (in|out): 202576 | 8087
 2016/03/18 13:58:10 WebRTC: DataChannel.OnClose [remotely]

retry client offers immediately instead of reset, combine sendOffer and receiveAnswer into exchangeSDP