Commit Graph

7 Commits

Author SHA1 Message Date
DatCaptainHorse
e4676b5049 feat(neshub): decide the bitrate from what the receiver actually got
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>
2026-09-19 01:27:16 +03:00
DatCaptainHorse
57abdb9663 feat(protocol): a box is told what it may spend on video, and the receiver can say what it got
Three additions, all of them plumbing for a bitrate that something
actually decides.

`BootDescriptor` gains `VideoLimits`. It rides the boot document rather
than a kernel command line because `nesinit` handles `Boot` by mounting
and *then* bringing the stack up, so the value is in hand before `neshub`
is spawned -- no parsing, no window where the service is running without
its configuration. It is on the descriptor rather than a launch because
its consumer is a service that comes up with the box; geometry went the
other way for the same reason, its consumer being started per launch.

`bitrate_kbps` is an `Option` and the distinction is load-bearing.
"Nobody said" is not zero and is not unlimited, and a reader that
conflates the first with the last reproduces the bug exactly: every
session offered 10 Mbps because no number had ever been chosen and the
encoder's own default stood in for one. `neshub` now says which it got,
and falls back to something modest rather than to whatever it finds.

Note what `deny_unknown_fields` means here, since it is deliberate: a
host that sends `video` to a guest too old to know the field is refused
rather than quietly served. That is the right direction to fail -- the
alternative is a box that boots, streams, and ignores its ceiling -- and
it means the guest image is rebuilt before a host starts sending one.

`MSG_RECEIVER_REPORT` carries what a second looked like from the far
end: goodput actually released to the decoder, frames released,
incomplete and never-arrived, and the receiver's own RTT. The hub cannot
work any of this out for itself. Its own view was measured saying the
path was healthy while almost nothing was arriving, and one reason is
structural -- `send_datagram` evicts the oldest queued datagrams and
returns `Ok`, so the send side has no backpressure signal at all.

`MSG_CONTROL_MODE` says who is choosing the bitrate. Manual exists
because it is how this class of bug gets found: the original report said
the bitrate had already been lowered, and the only way anyone
established otherwise was by setting one by hand and watching the
picture come back.

Both decoders refuse what they cannot read rather than guessing.
`loss()` returns `None` for a second that accounted for no frames at
all, because a second with nothing sent and a second with nothing
arriving are indistinguishable from there, and answering either 0% or
100% would tell a controller something nobody knows.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-19 01:20:25 +03:00
Kristian Ollikainen
6811c93d51 feat: nescapture capture improvements and drive mounts (#337)
Co-authored-by: DatCaptainHorse <DatCaptainHorse@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-09-18 22:58:22 +03:00
Wanjohi
f74de9beb8 fix(nesinit): do not mount over the share tree, and check who serves an address
Four findings from review, all of them real.

The relay's directory was mounted on the tree a session's shares live in. A
fresh tmpfs there hides every directory the image prepared underneath it: the
install, the user state, the work directory, and the mount point the log share
is attached to from fstab. A box would have come up with a socket and without
any of the places its workload looks for its files, and the exact-path check
could not notice, because what fstab mounts is a directory inside that tree
rather than the tree itself. It moves to /run, which is where a runtime socket
belongs, is a tmpfs already, and has nothing else mounted inside it.

It was also owned by this process and closed to everyone else, which stopped
the workload traversing it to reach the relay at all. The directory is now
readable and searchable, and still writable by nothing but this process, which
is what makes the socket in it unreplaceable; the socket itself is what the
workload is allowed to connect to. The permission belongs on the socket rather
than on the path.

The address served to a reader was built once at startup and served forever, so
a reader that polls for a better one could only ever get the first. An endpoint
does not know all of its own addresses when it binds: the first is the one that
works on the same network and fails from anywhere else. It is now rebuilt per
read, which is what makes polling for it worth doing.

And the address was taken from whoever held a path in a directory the workload
can write. Workload code could unlink the socket a service was listening on,
bind its own, and every read afterwards would hand the client an address of its
choosing -- a session given to somebody else rather than a session that fails.
The peer's credentials are now checked before a byte is read, from the kernel
rather than from anything the peer says about itself, and an address served by
the workload's own user is refused and said loudly.

That check is only worth something while the workload has a user of its own, so
the image grows one. Two users, and they must stay two: one runs the services
that ship in the image, the other is who a workload runs as. Sharing one does
not weaken the check, it makes every session fail it.

A workload running as root is every user at once and cannot be told apart from
anything; the check stands down there and says so at boot instead, because
refusing root would refuse whatever legitimately serves the address as well.

Also bumps tinyvec by a patch release. It does not build on this toolchain --
`vec` resolves to the module and not the macro -- which made every crate that
depends on an endpoint, including this one, unbuildable. Pre-existing and
nothing to do with this change; the lockfile said the same version before it.
2026-09-06 18:20:30 +03:00
DatCaptainHorse
84c97156f8 fix: ticket formatting 2026-08-31 17:31:23 +03:00
DatCaptainHorse
d9cdf60039 fix: wrong neshub version, formatting 2026-08-31 17:24:00 +03:00
Wanjohi
3c574af2ea feat(neshub): open the media hub
The component nescapture, neswire and nescope all talk to, and the only
thing in the guest that speaks to the client. It muxes their frames into
one iroh QUIC endpoint and fans input back.

Renamed from nestri-guest-hub, which named a location rather than a job.

Four files came across unchanged -- session.rs, ipc_listener.rs,
ticket.rs, screenshot.rs. Between them they mention Steam zero times, and
they import only nesprotocol's open modules; the control feature carrying
LaunchIntent and SteamIdentity is used exclusively by the three files that
are staying closed. The two clusters shared a main.rs and nothing else, so
there was no untangling to do -- only a cut.

main.rs loses --proton, --steamclient-so, --root and the game uid/gid,
and no longer ends by handing the process to a controller. It runs until
it is stopped. Deciding when the box is finished belongs to nesinit.

The ticket used to leave via that controller, so it needed a new way out:
neshub now serves it on a socket and nesinit dials for it. Listening
rather than dialling matches every other socket here and means no startup
ordering to get wrong.

Three tests, where there were none -- the ticket crosses a process
boundary as text now, so a round trip that drops a field would otherwise
be found by whoever cannot connect.
2026-08-26 18:54:09 +03:00