Documentation
¶
Overview ¶
Package clidmsg cmd/skywire-cli/commands/dmsg/attach.go c4-vis-cli `skywire cli dmsg attach` — inspect and exercise a local visor's dmsg relay acceptor (pkg/visor/init_dmsg_relay_local.go).
Attaching is how a standalone dmsg process stops holding dmsg server sessions WITHOUT changing its key: it gets one session, to the visor beside it, over a unix socket, and its streams are forwarded over that visor's sessions and transports. This command is the two checks an operator needs before trusting that path:
skywire cli dmsg attach # what is on the other end of the socket? skywire cli dmsg attach --sk <key> # would MY key be admitted?
The first needs no identity at all — it reads the acceptor's hello and hangs up — which is deliberate: verifying a socket must not mint a key, and a deployment that has paid for hundreds of throwaway identities does not need another source of them.
The end-to-end path with real traffic is the --attach flag on the standalone tools: `skywire cli dmsg curl --attach <socket> dmsg://<pk>:80/...` fetches over the visor's sessions under the caller's own key.
Package clidmsg cmd/skywire-cli/commands/dmsg/cat.go c4-vis-cli `skywire cli dmsg cat` and `skywire cli dmsg cat listen` subcommands. Splice stdio with a remote peer over either dmsg or the skywire router.
Client form : `cli dmsg cat <pk>:<port>` — opens a stream, copies
stdin → stream and stream → stdout, exits when either side EOFs.
Listen form : `cli dmsg cat listen <port>` — accepts one inbound
stream (after a whitelist check), then splices stdio. One-shot by design; multi-conn into the same stdout would interleave bytes meaninglessly.
The client form has a standalone-dmsg fallback so it works without a local visor; the listen form does not — listening requires the dmsgscp whitelist, which the visor owns.
Package clidmsg cmd/skywire-cli/commands/dmsg/chat.go c4-vis-cli dmsg-only chat. Run when the local visor is down (or absent) so operators can still reach a support channel.
The visor-app skychat (cmd/apps/skychat) uses the visor's identity and the visor's dmsg.Client — its main strength is sharing the same PK operators publish in service-discovery, but the cost is "if the visor is broken, skychat is broken too." This command sidesteps that: it stands up its OWN dmsg.Client with a separate secret key, listens on a dmsg port for inbound chat, and dials peers directly over dmsg for outbound. No visor RPC, no route-finder, no skynet.
Wire format mirrors the visor-app skychat post PR #2504:
[4-byte BE length][JSON envelope]
where the JSON shape is {"sender","message","ts","network"}. Two skywire dmsg chat instances can talk to each other; cross-talk with visor-app skychat works if the visor-app side is also on the post-#2504 framed protocol.
Why a TUI rather than send/listen subcommands like dmsgcurl: the expected use is interactive — an operator opens it, types a few messages back and forth with support, closes it. send/listen would force the operator to manage two terminal windows. Same reasoning as `skywire cli skychat chat`.
Package clidmsg cmd/skywire-cli/commands/dmsg/chat_tui.go c5-cli-dmsg
The screen of `cli dmsg chat`, drawn with progkit: the conversation, a line to type into, and the recipient to pick first when none was given. In websh the line is a real text field and the conversation selectable text.
Package clidmsg cmd/skywire-cli/commands/dmsg/connect_all.go c4-vis-cli
Package clidmsg cmd/skywire-cli/commands/dmsg/converge.go c4-vis-cli
Package clidmsg cmd/skywire-cli/commands/dmsg/curl.go c4-vis-cli
Package clidmsg cmd/skywire-cli/commands/dmsg/diag.go c4-vis-cli
Package clidmsg cmd/skywire-cli/commands/dmsg/iperf.go c4-vis-cli cli dmsg iperf <pk>:<port>` and `skywire cli dmsg iperf listen <port>` — bulk throughput measurement over a dmsg stream.
Client form : opens one stream, pumps zero-filled buffers from
memory (not /dev/zero, which adds a Go-fs read at every kernel boundary) for --duration, prints the final goodput along with periodic rolling samples.
Listen form : accepts one inbound stream, drains it into a
black-hole sink, prints the same shape of samples from the receive side. One-shot like dmsg cat listen.
Both sides emit lines on stderr at --interval cadence so an operator running `dmsg iperf <pk>:<port> --duration 30s --interval 1s` sees ~30 sample lines plus a final totals line, like classic iperf. The wire itself is just bytes — no length framing, no type tags, no envelope. Sender writes, receiver reads. That keeps the measurement as close to the raw transport as possible: any overhead in the printout is from go's runtime and the operator's kernel, not from the iperf shim.
Why a dedicated command vs. piping /dev/zero | dmsg cat:
- cat adds an extra goroutine pair and a stdin/stdout splice; iperf bypasses that for tighter byte accounting.
- cat's "exit when either side EOFs" semantics fight the time-bounded test pattern operators want for throughput.
- rolling-sample stderr lines + a totals line are conventional for throughput tools; you can't easily get that out of `cat`.
Standalone-dmsg only in this first cut: the client bootstraps its own dmsg.Client just like `dmsg cat` with --transport dmsg. A future patch can add a VisorIperf RPC for the auto/skynet paths once we've validated the standalone shape.
Package clidmsg cmd/skywire-cli/commands/dmsg/port_hits.go c4-vis-cli
Package clidmsg cmd/skywire-cli/commands/dmsg/probe.go c4-vis-cli
Package clidmsg cmd/skywire-cli/commands/dmsg/pty.go c4-vis-cli
Package clidmsg cmd/skywire-cli/commands/dmsg/root.go c4-vis-cli
Package clidmsg cmd/skywire-cli/commands/dmsg/scp.go c4-vis-cli `skywire cli dmsg scp` subcommand. Drives the dmsgscp client against either a peer's dmsgscp Host or the local visor's (loopback over its own dmsg PK).
Direction is inferred from which argument carries a `PK:` prefix. The PK is 66 hex chars — long enough that the regex can't false-match a normal filename.
Package clidmsg cmd/skywire-cli/commands/dmsg/sessions.go c4-vis-cli
Package clidmsg cmd/skywire-cli/commands/dmsg/smb.go c4-vis-cli
Registers the standalone (dmsg-only) SMTP→dmsg bridge as the `smb` subcommand of `skywire dmsg`, so a single skywire binary can launch it without requiring a separately-built top-level binary. The visor-side in-process bridge has its own control surface at `skywire cli mail`; this subcommand is for hosts that don't run a visor.
Package clidmsg cmd/skywire-cli/commands/dmsg/sub.go c4-vis-cli
Registers the standalone UDP→dmsg bridge as the `sub` subcommand of `skywire dmsg`, so a single skywire binary can launch it without requiring a separately-built top-level binary.
Index ¶
Constants ¶
This section is empty.
Variables ¶
var PtyCmd = &cobra.Command{
Use: "pty",
Short: "Interact with remote visors",
Long: "Commands for interacting with remote visors via dmsgpty",
}
PtyCmd is the command for dmsgpty functionality
var RootCmd = &cobra.Command{
Use: "dmsg",
Short: "Dmsg utilities",
Long: `Dmsg utilities.
These commands fall into three families:
this-visor dmsg client (needs a running visor on --rpc)
sessions list the dmsg servers each visor dmsg client is on
converge re-dial sessions onto their preferred carrier
connect-all open a session to every known server (one-shot)
set-sessions persist dmsg.sessions_count + connect-all
port-hits inbound hits to ports with no listener
diag runtime diagnostics (porter / reconnect)
standalone dmsg tools (bootstrap their own dmsg client; work with
no local visor — pass --sk for a stable identity, or --attach to
ride a local visor's sessions while keeping that identity)
attach inspect the local visor's dmsg relay acceptor
curl fetch data over dmsg (HTTP-over-dmsg)
cat splice stdio with a peer over dmsg or skynet
scp copy a file to/from a remote visor's dmsgscp host
iperf bulk throughput / RTT measurement over a stream
chat interactive 1:1 chat over dmsg
probe test a remote port's reachability
sub standalone UDP-over-dmsg bridge
smb standalone SMTP-over-dmsg bridge
Query the dmsg discovery itself with 'skywire cli mdisc'. Remote
visor terminals live under 'skywire cli pty' (formerly 'dmsg pty').`,
}
RootCmd is the command that contains sub-commands which use dmsg.
Functions ¶
This section is empty.
Types ¶
This section is empty.
Source Files