James Tucker
3c0508fa28
Make link queue writes nonblocking: gVisor can generate replies on the reader needed to drain the queue. A full queue drops only the rejected packet and reports ErrNoBufferSpace, which gVisor counts and TCP handles by arming its retransmit timer. UDP sockets do not see the error unless IP_RECVERR is set, matching Linux. Count WireGuard-bound drops as reason="queue_full" in tailscaled_outbound_dropped_packets_total, and per-queue drops in debug and client metrics. Add Wrapper.TryInjectOutbound for best-effort replies generated while processing packets (TSMP rejects and pongs, conn25 rejects, fake-mode echo replies), so those paths drop instead of stalling behind the injection queue's reader. Its drops are also counted as queue_full. Make outbound injection waits cancellable and close link queues before abort-generated replies. Stop the WireGuard injection pump on ErrClosed. Release injected packets still queued at Close, outside closeOnce to allow reentrant release callbacks; a sender whose send races with Close releases the packet itself. Release temporary capture buffers. Copy injected payload views directly into the WireGuard slab, avoiding an intermediate allocation and copy. Test queue saturation, multiqueue progress, cancellation, concurrent shutdown, reference ownership, fragmented payloads, and GSO. Performance versus the parent commit, on a 4-core Xeon 6975P-C: inject+read 64B / 1280B 245ns / 479ns -> 187ns / 195ns, 0 allocs 4 injectors, 1 reader 843ns -> 451ns 64KiB GSO inject+split 10.9us -> 4.4us, 64KiB/op -> 0 link queue write+read 81.4ns -> 81.5ns tsnet TCP, 1 / 8 streams 448 / 580 MB/s -> 492 / 674 MB/s BenchmarkTCPQueueBottleneck shows that dropping on full queues keeps throughput at the bottleneck rate (117 MB/s at 100k packets/s, as with blocking writes), at the cost of more retransmits with many streams. Fixes #21631 Updates #21638 Updates #21632 Updates #21639 Signed-off-by: James Tucker <james@tailscale.com>
tsconnect
The tsconnect command builds and serves the static site that is generated for the Tailscale Connect JS/WASM client.
Development
To start the development server:
./tool/go run ./cmd/tsconnect dev
The site is served at http://localhost:9090/. JavaScript, CSS and Go wasm package changes can be picked up with a browser reload. Server-side Go changes require the server to be stopped and restarted. In development mode the state the Tailscale client state is stored in sessionStorage and will thus survive page reloads (but not the tab being closed).
Deployment
To build the static assets necessary for serving, run:
./tool/go run ./cmd/tsconnect build
To serve them, run:
./tool/go run ./cmd/tsconnect serve
By default the build output is placed in the dist/ directory and embedded in the binary, but this can be controlled by the -distdir flag. The -addr flag controls the interface and port that the serve listens on.
Library / NPM Package
The client is also available as an NPM package. To build it, run:
./tool/go run ./cmd/tsconnect build-pkg
That places the output in the pkg/ directory, which may then be uploaded to a package registry (or installed from the file path directly).
To do two-sided development (on both the NPM package and code that uses it), run:
./tool/go run ./cmd/tsconnect dev-pkg
This serves the module at http://localhost:9090/pkg/pkg.js and the generated wasm file at http://localhost:9090/pkg/main.wasm. The two files can be used as drop-in replacements for normal imports of the NPM module.