Files
netris-nestri/crates
DatCaptainHorseandClaude Opus 5.5 809c37b355 feat(neshub): decide the video rate per frame from the path, not on thresholds
Hub side of nescore's 2026-10-16 video-rate spec.

nesprotocol: a per-frame feedback datagram (kind 3, client to hub on the
video connection) carrying bytes, fragments, send time, first-fragment
arrival, arrival spread and first-fragment queueing delay. The hub stats
breakdown gains measured capacity and delivered share.

neshub:
- rate.rs, a per-client path model. Capacity is measured from each
  frame's train dispersion. The bottleneck counts as busy when the next
  train lands no later than its first fragment's own serialisation after
  the last one, and as overloaded when, during a busy run, the first
  fragments' queue grows and more is sent than delivered. Overload drops
  the rate at once to drain at the rate the queue built, then settles at
  the measured share. Steps up go to the measured capacity, or the
  highest rate the path has proven quiet at for longer than its own
  longest gap between overloads at or below it. Silence holds at the
  last share. Tested against a modelled FIFO bottleneck: above the path,
  below it, CBR keyframes, a capacity drop and recovery, recurring cross
  traffic.
- control.rs: the slowest client's path decides, per frame as feedback
  arrives. Gone: the loss thresholds, back-off factor, climb fraction,
  deadband and queue thresholds. Ceiling, floor, manual and constant
  quality behave as before.
- congestion.rs: an endpoint congestion controller that holds nothing
  back (window above u32::MAX, where noq stops pacing), so frames leave
  as trains for the client to measure.

media-transport.md now says the hub turns transport pacing off, and why.

The client does not send feedback yet (nescore step 2). Until it does,
the rate stays where the session started.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-16 20:33:33 +03:00
..
2026-08-26 17:49:43 +03:00

crates/

Shared Rust: a library another crate in this repo depends on. A binary someone runs goes in apps/; shared JS/TS goes in packages/. The split is by what a thing is, not by what language it is written in — same rule on both sides of the repo.

Empty today. Components move here one at a time as they are opened.

Two rules

Every version is pinned in the root Cargo.toml. A member writes tokio.workspace = true and never a version, so two crates in this tree cannot disagree about a dependency.

Nothing here may depend on anything closed, or name it. This repo is public. A crate that needs a private component is in the wrong repo, and a comment explaining who calls this wants a category noun — "the caller", "a supervising agent" — rather than a name. The requirement is the interesting part; who currently satisfies it is not.