e4676b5049
The controller itself, as a pure thing with no I/O, so the decisions can be tested away from a connection. It is driven by the receiver's report rather than by this end's view of the path, because this end's view was measured being wrong when it mattered most: 182 ms round trip, zero QUIC packet loss, and a client watching arrivals fall from 1776 to 239 datagrams a second. Some of that is structural -- `send_datagram` evicts the oldest queued datagrams and returns `Ok`, so a sender overrunning a path is told nothing at all. Round-trip time and congestion window remain as a fallback for when the far end has gone quiet, and nothing else. Backing off anchors on measured goodput rather than on a fraction of what was being asked for, which is what makes it quick: at 10 Mbps into a 3 Mbps path the next target is under what actually arrived, so one step does what twenty multiplicative decreases would. The test that matters reproduces the reported failure -- 10 Mbps offered, no frame completing at all -- and requires it corrected within five seconds. Belief and actuation are separate, and that is not tidiness. Folding them together stalls the climb: the step up is a fraction of the ceiling, so past half the ceiling every step falls under the deadband, and a target that only moved when it actuated could never accumulate past that point. The tests caught it. Belief moves every second; saying so is rationed. The first decision is always stated even when nothing changed, because the encoder started at whatever its environment gave it and this end cannot know that matches. Standing down is explicit in three cases: a person set the bitrate by hand, the encoder is under constant quality and has no bitrate to decide, or nothing has been heard and nothing can be seen -- and that last one decays rather than holds, since holding a high target on no evidence is precisely how the original failure sustained itself. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
neshub
One connection out of the box.
Everything inside the guest that produces or consumes a stream talks to neshub over a Unix socket. neshub muxes it all into a single iroh QUIC endpoint and fans client input back the other way. A client dials that endpoint with a ticket and gets video, audio, cursor and stats on it.
The sockets
| socket | default | direction | carries |
|---|---|---|---|
--video-ipc |
/tmp/nestri-video.sock |
nescapture → neshub | encoded video frames |
--audio-ipc |
/tmp/nestri-audio.sock |
neswire → neshub | Opus packets |
--input-ipc |
/tmp/nestri-input.sock |
neshub ↔ nescope | input out, cursor and stats back |
--stats-ipc |
/tmp/nestri-stats.sock |
nescapture → neshub | encoder stats |
--screenshot-ipc |
/tmp/nestri-screenshot.sock |
neshub → nescope | a picture of the screen, on request |
--ticket-ipc |
/tmp/nestri-ticket.sock |
neshub → nesinit | the ticket, once |
| — | /tmp/nescapture-cmd.sock |
neshub → nescapture | IDR requests, encode settings |
neshub is the listener on every one of them and the other side dials in. That is deliberate: it removes the startup ordering problem entirely, since a producer that is not running yet simply has not connected yet.
The ticket
nestri:<base64 of {endpoint_addr, stream_name}>
Generated once per boot, when the endpoint binds. It is served on a socket
rather than printed because stdout here is a log file inside a virtual machine
and the person who needs it is outside one — nesinit reads it and carries it
to the host.
What it does not do
neshub does not start the payload, know its name, or decide when the box is
finished — nesinit owns all three, and shuts the VM down around this process.
The same neshub binary serves a game, a desktop, or anything else that draws to
nescope, because it never learns which one it is looking at.
Running it
cargo run --bin neshub # every socket at its default
cargo run --bin neshub -- --relay none # direct connections only
RUST_LOG=neshub=debug cargo run --bin neshub