Age | Commit message (Collapse) | Author |
|
* Related: #40354
|
|
|
|
|
|
shelikhoo/dev-udp-performance-rebased branch
https://gitlab.torproject.org/shelikhoo/snowflake/-/commits/9dce28cfc2093490473432ffecd9abaab7ebdbdb
|
|
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/154#note_2919109
Still ignoring the io.ErrShortBuffer at the callers, which retains
current behavior.
|
|
Instead of unconditionally allocating its own.
|
|
When the orport-srcaddr option is set, we bind to a source IP address
before dialing the ORPort/ExtORPort. tor similarly binds to a source IP
address when OutboundBindAddress is set in torrc. Since tor 0.4.7.13,
tor sets IP_BIND_ADDRESS_NO_PORT, and because problems arise when some
programs use IP_BIND_ADDRESS_NO_PORT and some do not, we also have to
start using IP_BIND_ADDRESS_NO_PORT when we upgrade tor
(tpo/anti-censorship/pluggable-transports/snowflake#40270).
Related: tpo/anti-censorship/pluggable-transports/snowflake#40198
|
|
Related: tpo/anti-censorship/team#86
|
|
|
|
|
|
This is meant to reduce overall allocations. See past discussion at
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40260#note_2885524 ff.
|
|
This error return was lost in 11f0846264d4033e7a7dc7824febb6ad7140762f;
i.e. !31.
Fixes #40043.
|
|
|
|
Replaces the hardcoded numKCPInstances.
|
|
To distribute CPU load.
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40200
|
|
|
|
By forwarding the method to the inner smux.Stream. This is to prevent
io.Copy in the top-level proxy function from allocating a buffer per
client.
The smux.Stream WriteTo method returns io.EOF on success, contrary to
the contract of io.Copy that says it should return nil. Ignore io.EOF in
the proxy loop to avoid a log message.
/anti-censorship/pluggable-transports/snowflake/-/issues/40177
|
|
Recent increases in usage have exhausted the capacity of the map.
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40173
|
|
|
|
From now on, there will be a file at common/version/version.go that includes current version number.
|
|
The option controls what source address to use when dialing the
(Ext)ORPort. Using a source address other than 127.0.0.1, or a range of
addresses, can help with localhost ephemeral port exhaustion.
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40198
|
|
To save memory, we want to more aggressively close stale connections.
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40175
|
|
|
|
Fixes a bug where an uninitialized channel causes a panic when closed
(#40099).
|
|
Due to a bug (#40098), legacy oneshot connections have not worked for
awhile. Connections without the turbotunnel token would cause the server
to crash. This fixes that bug by removing support altogether and simply
closes the connection.
|
|
See also:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40084
|
|
This is an amendment of https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/30
|
|
|
|
|
|
|
|
|
|
This should increase the maximum amount of inflight data and hopefully
the performance of Snowflake, especially for clients geographically
distant from proxies and the server.
|
|
|
|
Refactor out a separate handleStream function and ensure that all
connections are closed and the references are out of scope.
|
|
This fixes a stats collection bug where we were converting client
addresses between a string and net.Addr using the clientAddr function
multiple times, resulting in an empty string for all addresses.
|
|
Introduce a waitgroup and done channel to ensure that both the read and
write gorouting for turbotunnel connections terminate when the
connection is closed.
|
|
|
|
Snowflake copies data between the OR connection and the KCP stream,
meaning that in most cases the copy loops will only terminate once the
OR connection times out. In this case the OR connection is already
closed and so calls to CloseRead and CloseWrite will generate errors.
|
|
These errors are triggered in three places when the OR connection times
out. They don't tell us anything useful and are filling up our logs.
|
|
|
|
The difficulty here is that the whole point of turbotunnel sessions is
that they are not necessarily tied to a single WebSocket connection, nor
even a single client IP address. We use a heuristic: whenever a
WebSocket connection starts that has a new ClientID, we store a mapping
from that ClientID to the IP address attached to the WebSocket
connection in a lookup table. Later, when enough packets have arrived to
establish a turbotunnel session, we recover the ClientID associated with
the session (which kcp-go has stored in the RemoteAddr field), and look
it up in the table to get an IP address. We introduce a new data type,
clientIDMap, to store the clientID-to-IP mapping during the short time
between when a WebSocket connection starts and handleSession receives a
fully fledged KCP session.
|
|
The client opts into turbotunnel mode by sending a magic token at the
beginning of each WebSocket connection (before sending even the
ClientID). The token is just a random byte string I generated. The
server peeks at the token and, if it matches, uses turbotunnel mode.
Otherwise, it unreads the token and continues in the old
one-session-per-WebSocket mode.
|
|
|
|
Some proxies currently send ?client_ip=0.0.0.0 because of an error in
how they attempt to grep the address from the client's SDP. That's
inflating our "%d/%d connections had client_ip" logs. Instead, treat
these cases as if the IP address were absent.
https://bugs.torproject.org/33157
https://bugs.torproject.org/33385
|
|
|
|
|
|
This makes the return type satisfy the io.ReadWriteCloser interface
directly.
|
|
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
|
|
Only once, not again on every call to initServer.
|
|
This was the only case out of the three not to show it.
|