The client implementations provide command-line tools for establishing outbound connections to the relay server using different transport protocols. These clients create local HTTP listeners that tunnel traffic through TCP, QUIC (via quic-go), or QUIC (via net-quic) transports to the relay server.
For information about the relay server that these clients connect to, see Relay Server Deployment. For details about the transport layer mechanisms used by these clients, see Protocol Upgraders.
The client application supports three protocol variants:
| Protocol | Command | Status | Transport Library |
|---|---|---|---|
| TCP | tcp | Stable | github.com/webteleport/webteleport/transport/tcp |
| QUIC (quic-go) | quic-go | Stable | github.com/webteleport/webteleport/transport/quic-go |
| QUIC (net-quic) | net-quic | Experimental | github.com/webteleport/webteleport/transport/net-quic |
Each client implementation follows the same pattern: establish a listener using the protocol-specific transport library, then serve HTTP traffic through it. The listener automatically handles the connection establishment and tunneling protocol with the relay server.
Sources: cmd/client/main.go1-39
The client application uses a multicall runner architecture that dispatches to protocol-specific handlers based on the command name. This pattern, implemented via github.com/btwiuse/multicall, allows a single binary to support multiple sub-commands.
Sources: cmd/client/main.go1-39
The cmdRun variable defines the mapping from command names to handler functions:
The multicall.RunnerFunc signature accepts a string slice of arguments and returns an error. Each protocol handler extracts connection parameters from these arguments using the arg0() helper function, which provides fallback defaults if no arguments are supplied.
Sources: cmd/client/main.go11-22
The arg0() function provides sensible defaults for each protocol:
127.0.0.1:8081/test?asdf=1127.0.0.1:8082/test-quic-go?asdf=1127.0.0.1:8083/test-net-quic?asdf=1Sources: cmd/client/main.go11-16 cmd/client/tcp.go12 cmd/client/quic-go.go12 cmd/client/net-quic.go13
The client supports two QUIC implementations with similar interfaces but different underlying libraries.
The RunQuicGo() function establishes a QUIC listener using the github.com/webteleport/webteleport/transport/quic-go library:
Implementation Details:
| Aspect | Value |
|---|---|
| Transport Library | github.com/webteleport/webteleport/transport/quic-go |
| Default Address | 127.0.0.1:8082/test-quic-go?asdf=1 |
| Context | context.Background() |
| HTTP Handler | nil (DefaultServeMux) |
| Status | Stable |
The listener address includes a path component (/test-quic-go) and query parameters (?asdf=1) that are used by the relay server for session identification and routing.
Sources: cmd/client/quic-go.go1-20
The RunNetQuic() function uses the experimental github.com/webteleport/webteleport/transport/net-quic library, which wraps golang.org/x/net/quic:
Implementation Details:
| Aspect | Value |
|---|---|
| Transport Library | github.com/webteleport/webteleport/transport/net-quic |
| Default Address | 127.0.0.1:8083/test-net-quic?asdf=1 |
| Context | context.Background() |
| HTTP Handler | nil (DefaultServeMux) |
| Status | Not working yet (per code comment) |
The net-quic implementation is experimental and currently non-functional. It uses port 8083 by default to avoid conflicts with the stable quic-go implementation.
Sources: cmd/client/net-quic.go1-21
While the client implementations themselves are simple wrappers, the underlying transport libraries have different configurations when used in the relay server:
| Configuration | quic-go | net-quic |
|---|---|---|
| Max Streams | 1 << 60 (MaxIncomingStreams) | 1 << 60 (MaxBidiRemoteStreams) |
| Datagrams | Enabled | N/A |
| Config Type | *quic.Config | *quic.Config |
| TLS Config | Shared (TLSConfig) | Shared (TLSConfig) |
Sources: cmd/relay/quic-go.go11-16 cmd/relay/net-quic.go12-21
The RunTcp() function provides the simplest client implementation using standard TCP connections:
Implementation Details:
| Aspect | Value |
|---|---|
| Transport Library | github.com/webteleport/webteleport/transport/tcp |
| Default Address | 127.0.0.1:8081/test?asdf=1 |
| Context | context.Background() |
| HTTP Handler | nil (DefaultServeMux) |
| Protocol | TCP with webteleport tunneling |
The TCP client creates a listener that appears as a standard net.Listener but actually tunnels all traffic through a TCP connection to the relay server. The address string includes both connection parameters and routing information (path and query string) used by the relay server.
Sources: cmd/client/tcp.go1-20
Sources: cmd/client/tcp.go11-19
All three client implementations follow a consistent pattern:
Each client implementation contains approximately 20 lines of code with identical structure:
context, log, net/httpfunc RunXxx(args []string) errorarg0(args, defaultAddress)transport.Listen(context.Background(), address)defer ln.Close()log.Println("Listening on", ln.Addr()...)http.Serve(ln, nil)This consistency makes the codebase easy to understand and maintain. Each protocol-specific complexity is encapsulated within the respective transport library (see Protocol Upgraders for server-side details).
Sources: cmd/client/tcp.go1-20 cmd/client/quic-go.go1-20 cmd/client/net-quic.go1-21
All client address strings follow the same URL-like format:
<host>:<port>/<path>?<query>
Components:
127.0.0.1:8081)/test, /test-quic-go)?asdf=1)The path and query components are transmitted to the relay server during the connection handshake and used for session allocation and routing (see Store and Session Management).
Sources: cmd/client/tcp.go12 cmd/client/quic-go.go12 cmd/client/net-quic.go13
Sources: cmd/client/main.go32-38
Refresh this wiki