ping

Overview ¶

Package clivisor cmd/skywire-cli/commands/visor/ping/bandwidth.go c4-vis-cli

Package ping cmd/skywire-cli/commands/visor/ping/mux_bandwidth.go c4-vis-cli CLI consumer for the StreamMuxBandwidth gRPC RPC.

Operator-visible: `cli visor ping mux-bw <pk>` runs the multiplexed-route bandwidth test against a single peer.

Default stdout: human-readable rows + a final summary with avg / peak throughput, RTT distribution stats (when --probe-rtt is set), and the termination reason — the queueing-delay measurement reads off the summary table directly, no jq needed.

--json: emit NDJSON instead. Same envelope shape as ping tree-stream, so treeprobe-style harnesses can consume either.

--output FILE: NDJSON tee independent of stdout mode.

Run shapes (the operator's hypothesis matrix):

# Baseline — single route, no min_hops (picks direct if available)
cli visor ping mux-bw <pk> --duration 30s

# Single non-direct path — forces at least one intermediate
cli visor ping mux-bw <pk> --duration 30s --min-hops 2

# N parallel routes excluding direct — the operator's hypothesis
# call: should sum to MORE bandwidth than direct
cli visor ping mux-bw <pk> --duration 30s --routes 4 --min-hops 2

# Queueing-delay measurement: bandwidth + concurrent RTT probe
cli visor ping mux-bw <pk> --duration 30s --probe-rtt

Package ping cmd/skywire-cli/commands/visor/ping/mux_bandwidth_tui.go c4-vis-cli Interactive TUI consumer of the StreamMuxBandwidth gRPC RPC.

Operator-visible: `cli visor ping mux-bw-tui <pk>` runs the same multiplexed-route bandwidth test as `mux-bw` but presents it as a live dashboard instead of NDJSON: per-route status row, throughput sparkline, RTT-probe sparkline (when --probe-rtt is set), and a scrollable events log.

Identical flags to `mux-bw`; the only difference is rendering. Both subcommands ride the same server-side RPC handler, so a change at the server lands in both.

Package clivisorping cmd/skywire-cli/commands/visor/ping/mux_bandwidth_tui_impl.go c5-cli-visor

The screen of `visor ping mux-bw-tui`; the command spec stays in mux_bandwidth_tui.go.

Package ping cmd/skywire-cli/commands/visor/ping/ping.go c4-vis-cli

Package ping cmd/skywire-cli/commands/visor/ping/root.go c4-vis-cli

Package ping cmd/skywire-cli/commands/visor/ping/streamview.go c4-vis-cli

The screen shared by `ping tree` and `mux-bw-tui`: fixed ANSI lines on top, a scrolling body fed by a gRPC stream, and a key hint. It is drawn with progkit, so in websh the body is also selectable HTML text.

Package ping cmd/skywire-cli/commands/visor/ping/tree.go c4-vis-cli interactive TUI for `cli visor ping tree`.

History: this command used to host a ~2300-line client-side BFS + concurrency-limited ping orchestrator + state machine. That code had several structural problems on visors with hundreds of transports: default concurrency=2 capped throughput at ~4 pings/ minute (so level 1 of a 500-transport visor took >2 hours and level 2 never started), the renderer hid pending entries (making progress invisible), and the TUI's /dev/tty requirement made the tool undriveable from CI or coding agents.

#2732 moved the BFS server-side as the StreamPingTree gRPC RPC. This file now consumes that stream and renders it with the same TUI shape — header, stats line, scrollable tree viewport, footer — that operators were already familiar with.

The NDJSON-driven sibling lives in tree_stream.go (`cli visor ping tree-stream`); it feeds the same events to stdout for treeprobe + CI consumers. Both subcommands ride the same server-side BFS implementation, so a fix at the server lands in both.

Package ping cmd/skywire-cli/commands/visor/ping/tree_stream.go c4-vis-cli thin gRPC client for the StreamPingTree RPC. The visor does the BFS server-side and pushes PingTreeEvents over the stream; this command renders each event either as a human-readable row (default) or as one NDJSON object per stdout line (--json).

Default output is built for direct human consumption — including a final aggregation table (avg/p50/p99/jitter grouped by hop count) so the latency-vs-hops measurement Synth asked about doesn't need a follow-up jq pipeline.

--json switches to the NDJSON wire format consumed by external harnesses + coding agents:

{"ts":"<RFC3339Nano>","type":"<event>","data":{...}}

`data` is the marshaled oneof payload with proto's snake_case field names preserved. NDJSON consumers can `jq -c .` to filter or stream-decode into the wire types via protojson.

Package clivisorping cmd/skywire-cli/commands/visor/ping/tree_tui.go c5-cli-visor

The screen of `visor ping tree`; the command spec stays in tree.go.