[remote] max_records_per_principal (100000 by default): the clock holds the records of seq 0 up to
the bound of each principal but the host. When a record past it comes, the clock takes the
principal's records up to the bound, cuts it there (max_records_per_principal, by the cut path a
record out of order takes) and removes it (leave reason 2); the session goes on for everyone
else and verifies. The host agent reads the bound from GET /room and its gate cuts the principal
at the same record, so the two hold the same records. The host has no bound of its own: its
outcomes answer the others' inputs.
max_records stays as the safety net on the whole session and rises to 1000000, ten times the
bound per principal: a host and four controllers each at its bound hold 800000. The default per
principal: a two-hour session at ten input statements a second is 72000 records; a flood at the
policy's 120 events a second reaches the bound in about 14 minutes. remote-desktop §10 says a
service bounds per principal first, which bites first and why; the configuration docs say the
same.
tests/remote_room.rs: bob, a viewer, floods input statements the host refuses past a bound of
24; he is cut at seq 24 and removed by the clock and by the host, alice's input after the cut is
applied, the session's total is not reached, and the sessions the clock and the host hold verify
at both levels. gate::tests: a participant cut at its bound.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
0116674570