skysocksc

Overview ¶

Package skysocksc cmd/skywire-cli/commands/proxy/loadtest.go c4-vis-cli

Package skysocksc cmd/skywire-cli/commands/proxy/log.go c4-vis-cli

Package skysocksc cmd/skywire-cli/commands/proxy/mux.go c4-vis-cli

Package skysocksc cmd/skywire-cli/commands/proxy/mux_adopt.go c4-vis-cli

`proxy mux adopt` — spend a STANDBY tunnel by moving its whole built route chain into an ACTIVE tunnel as one more packet-level mux leg, in place, with no setup-node dial.

The pool already holds warm tunnels for stream-level failover; this makes the same tunnel worth something to the multiplexer without re-dialing anything: both edges rewrite the chain's single consume rule, the descriptorless intermediate hops are untouched, and the standby tunnel's own group closes. See docs/design/leg-rehome.md.

Package skysocksc cmd/skywire-cli/commands/proxy/mux_auto.go c4-vis-cli

mux auto is the adaptive control loop — the "adaptive" leg of the observable -> manual -> adaptive arc. It reads the live mux info signals (per-leg latency) and steers a running proxy's legs toward a preset's intent, reusing the same RouteGroupMuxInfo read and RemoveMuxRoute / AddMuxRoute actuators that mux info and mux set proved.

This first increment is PRUNE-based: it converges the mux to the K lowest-latency legs per the preset (the primary route is always kept). Growing the set back to K — route-calc + mux add when legs are lost, for failover / demand-scaling — is the next increment (the latency signal + the AddMuxRoute path are already in place; only the route source needs wiring).

skywire cli proxy mux auto fastest --watch 5s    # keep the single best path
skywire cli proxy mux auto balanced --watch 5s   # keep a few low-latency legs
skywire cli proxy mux auto resilient --dry-run   # show the decision, don't act

Package skysocksc cmd/skywire-cli/commands/proxy/mux_events.go c4-vis-cli

Package skysocksc cmd/skywire-cli/commands/proxy/mux_forward.go c4-vis-cli

`proxy mux add --forward-only` — pin an added leg to the FORWARD (upload) direction, and `proxy mux negotiated` — what the two ends agreed on.

A forward-only leg (the router's appendRouteAsymmetric with addRev=false) adds upstream send capacity without enlarging the reverse/download set. It existed only as something the adaptive preset's rotation hook could emit under sustained upload saturation; this makes it an operator decision too.

The --forward-only flag is added to the existing `mux add` command and its Run is wrapped here rather than edited in place, so the default full-duplex path is byte-for-byte the one that was already there.

Package skysocksc cmd/skywire-cli/commands/proxy/mux_info.go c4-vis-cli

Package skysocksc cmd/skywire-cli/commands/proxy/mux_ops.go c4-vis-cli

Runtime mux reconfiguration commands. The visor exposes AddMuxRoute / RemoveMuxRoute / SetMuxMode RPCs already; these commands surface them so users can reconfigure an active proxy session without stopping and restarting.

Workflow:

skywire cli proxy mux info                          # see current legs
skywire cli route calc <peer-pk> --json | \
    skywire cli proxy mux add                       # add a leg over piped route
skywire cli proxy mux rm <tp-id>                    # drop a leg by first-hop tp
skywire cli proxy mux mode auto|equal               # change scheduler

mux add reads a {forward, reverse} hop list (JSON) from stdin or from --route <file>. The shape matches what 'cli route calc --json' emits, so the natural pipeline is calc | mux add. When stdin or the file holds an array of routes ('route calc --count N'), mux add uses the first; pre-filter with jq if you want a specific one. The visor refuses to attach a leg that starts on a transport already in the rg.

When the named app has multiple concurrent rg's (e.g. one per active SOCKS5 client connection on skysocks-client), use --rg <src-port> to pick which one. 'mux info' prints the src_port for every rg so you can copy it across.

Combined with 'mux info --watch' in a second terminal, this gives you the basic interactive loop for exploring mux behavior at runtime.

Package skysocksc cmd/skywire-cli/commands/proxy/mux_plot.go c4-vis-cli

Package skysocksc cmd/skywire-cli/commands/proxy/mux_set.go c4-vis-cli

mux set reconciles an active proxy session's mux legs to a target leg-set in one shot, instead of hand-driving mux add / mux rm. It's the static-mux primitive — "make the legs be exactly these" — and the actuation primitive the adaptive routing presets will drive (compute a target leg-set from the live mux info signals, then reconcile to it).

A leg's identity is its FIRST-HOP transport id (Forward[0].TpID, which is what mux info reports as a leg's transport_id and what mux rm takes). mux set diffs the target set against the current legs by that id:

• target legs not currently present -> AddMuxRoute
• with --prune: current legs not in the target -> RemoveMuxRoute

Add-only by default (safe + idempotent); --prune makes it an exact reconcile. NOTE: the proxy's PRIMARY route is itself a leg, so under --prune you must include it in the target or it will be removed.

The leg-set file is a JSON array of {forward, reverse} hop pairs — the same shape 'cli route calc --json' emits, concatenated:

skywire cli route calc <peer-pk> --count 3 --json > legs.json
skywire cli proxy mux set --legs legs.json            # ensure those 3 legs
skywire cli proxy mux set --legs legs.json --prune    # exactly those 3

Package skysocksc cmd/skywire-cli/commands/proxy/mux_telemetry.go c4-vis-cli

Package skysocksc cmd/skywire-cli/commands/proxy/mux_weights.go c4-vis-cli

`skywire cli proxy mux weights` — the operator's per-leg send-weight override on one route group.

The router has had WeightModeExplicit and SetExplicitWeights since the selector was written, with no way to reach either: the only caller was a routing-policy distribution, so an operator wanting "70% of the send on this leg" had to write a policy. This is the direct form.

Package skysocksc cmd/skywire-cli/commands/proxy/proxy.go c4-vis-cli

Package skysocksc cmd/skywire-cli/commands/proxy/root.go c4-vis-cli

Package skysocksc cmd/skywire-cli/commands/proxy/route_pin.go c4-app-proxy

Package skysocksc cmd/skywire-cli/commands/proxy/server.go c4-vis-cli

Package skysocksc cmd/skywire-cli/commands/proxy/settings.go

`proxy settings` — the live tuning knobs of a RUNNING skysocks-client.

Everything else that shapes a proxy app is either an argv flag (an app restart, which re-dials every tunnel: 30-70 s of settling before a measurement is valid) or a compile-time constant (a rebuild and a fleet deploy). This command is the third option: the visor holds a value set per app and the app pulls it on the keepalive tick it already runs, so a sweep costs one tick (tunnel.probe_interval, 5 s by default) and no redeploy.

Structurally this is `route settings` for the app side: the visor RPC pair is Get/SetAppSettings, and the knob catalog — names, kinds and compiled defaults — comes from pkg/skysocks/skysettings, which the app reads too.

skywire cli proxy settings                                  # the table
skywire cli proxy settings --json                           # machine-readable
skywire cli proxy settings chunk.max_bytes=8MiB pool.fill_interval=500ms
skywire cli proxy settings --reset tunnel.promote_margin    # one knob back
skywire cli proxy settings --reset                          # all of them

Package skysocksc cmd/skywire-cli/commands/proxy/testargs.go c4-vis-cli

Package skysocksc cmd/skywire-cli/commands/proxy/tree.go c4-vis-cli