Rename websocketconn.WebSocketConn to websocketconn.Conn, and
websocketconn.NewWebSocketConn to websocketconn.New
Following the guidelines at
https://blog.golang.org/package-names#TOC_3%2e
Proxies now include information about what type they are when they poll
for client offers. The broker saves this information along with
snowflake ids and outputs it on the /debug page.
Switch to containing all communication between the proxy and the broker
in the HTTP response body. This will make things easier if we ever use
something other than HTTP communicate between different actors in the
snowflake system.
Other changes to the protocol are as follows:
- requests are accompanied by a version number so the broker can be
backwards compatable if desired in the future
- all responses are 200 OK unless the request was badly formatted
The API is very similar, differences were mostly due to:
- closing peer connections and datachannels (no destroy/delete methods)
- different way to set datachannel/peer connection callbacks
- differences in whether functions take pointers or values
- no serialize/deserialize functions in the API
MaxBytesReader is only documented for server side reads, so we're using
a local limitedRead function instead that uses an io.LimitedReader.
Declared limits in a commented constant
This is related to the proxy-go deadlock bug #25688. If a client doesn't
do anything with the SDP answer, a token will get lost. Added a timeout
after a minute that checks the PeerConnection state and destroys the
peer connection and returns a token if did not yet succeed
This is a fix for the proxy-go deadlock bug (ticket #25688). The
assumption that OnIceComplete is always followed by a successful
connection where OnDataChannel has been called turns out not to occur in
practice. OnICEComplete looks like it is being deprecated in other
libraries anyway, so it's safer to just remove it.
https://bugs.torproject.org/25344
5s matches DEFAULT_BROKER_POLL_INTERVAL in the JavaScript proxy.
This is set up so as long as the actual HTTPS requests take less time
than pollInterval, there will a steady one poll per pollInterval. If the
HTTPS requests take longer than that, there will be no delay between
polls.
This prohibits some nonsense like "./proxy-go -capacity -550", which
otherwise results in a panic like:
INFO: configuration.go:174: Created Configuration at &{[{[stun:stun.l.google.com:19302] }] All Balanced }
panic: makechan: size out of range
math/rand always uses a deterministic seed. The sequence of session IDs
was therefore always the same:
Uv38ByGCZU8WP18PmmIdcg
lWbHTRDYaB0NhtHpHgAWeQ
...
Multiple copies of this program would have had session ID collisions. I
don't know what the consequences of that would be.
