cultmesh-rs: send the capped frame's answer reliably and end the session once it is acknowledged #48

Merged

libby merged 2 commits from libby/rs-capped-answer-reliable into main 2026-11-08 11:21:28 +00:00

Conversation 1 Commits 2 Files changed 2 +256 -12

libby commented 2026-11-08 11:04:23 +00:00

Member

Copy link

Follow-up capped-answer-delivery-ts-rs-cs, Rust; Python is fe73795d, TS is #47. The capped (8th) unreadable frame or refused delete was answered unreliable and unordered with the goodbye at once, so a lost datagram left the peer without the answer. Now it is queued like any response (reliable, ordered) and resent by maintain until the peer acknowledges it; the session then ends with the goodbye (end_answered_sessions, run from maintain and at the end of poll_once), or after a 2 s grace. Frames behind the capped one are not served meanwhile. If the reliable queue cannot take the answer, the session ends at once with the unreliable refusal, as before.

Rust keeps its rule that a refusal acknowledges nothing: the answer, its resends and the poll that carried the capped frame zero their ack fields (Python acks the capped frame; not changed here).

Not merged: it changes how the refused-delete / unreadable cap delivers its refusal, next to the write-authority path. Decisions and refusal contents are unchanged. For Heimdall.

Tests: three new (raw UDP peer: a lost answer is resent, acknowledges nothing, and the goodbye waits for its ack; an unacknowledged answer ends after the grace, not before; nothing behind the cap is served) and the two existing cap tests now drive the server through the goodbye. 11 hand mutants under prlimit as=4GiB cpu=300 (grace 0, grace 60 s, end without ack wait, end on ack only, end on deadline only, resend ack not zeroed, answer ack not zeroed, trailing ack sent, serve behind the cap, answer unreliable, no end check at poll tail): all killed (one survived until the trailing-ack assertion was added). cargo test -j1 under ulimit -v 8GB: all pass.

🤖 Generated with Claude Code

Follow-up `capped-answer-delivery-ts-rs-cs`, Rust; Python is fe73795d, TS is #47. The capped (8th) unreadable frame or refused delete was answered unreliable and unordered with the goodbye at once, so a lost datagram left the peer without the answer. Now it is queued like any response (reliable, ordered) and resent by `maintain` until the peer acknowledges it; the session then ends with the goodbye (`end_answered_sessions`, run from `maintain` and at the end of `poll_once`), or after a 2 s grace. Frames behind the capped one are not served meanwhile. If the reliable queue cannot take the answer, the session ends at once with the unreliable refusal, as before. Rust keeps its rule that a refusal acknowledges nothing: the answer, its resends and the poll that carried the capped frame zero their ack fields (Python acks the capped frame; not changed here). **Not merged:** it changes how the refused-delete / unreadable cap delivers its refusal, next to the write-authority path. Decisions and refusal contents are unchanged. For Heimdall. Tests: three new (raw UDP peer: a lost answer is resent, acknowledges nothing, and the goodbye waits for its ack; an unacknowledged answer ends after the grace, not before; nothing behind the cap is served) and the two existing cap tests now drive the server through the goodbye. 11 hand mutants under prlimit as=4GiB cpu=300 (grace 0, grace 60 s, end without ack wait, end on ack only, end on deadline only, resend ack not zeroed, answer ack not zeroed, trailing ack sent, serve behind the cap, answer unreliable, no end check at poll tail): all killed (one survived until the trailing-ack assertion was added). cargo test -j1 under ulimit -v 8GB: all pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

libby added 1 commit 2026-11-08 11:04:23 +00:00

cultmesh-rs: send the capped frame's answer reliably and end the session once it is acknowledged ... 03141bc93b

The capped (8th) refusal went out unreliable and unordered with the goodbye at once, so a
lost datagram left the peer without it. It is now queued like any response and resent until
the peer acknowledges it; the session ends then (or after a 2 s grace) and serves nothing
after the capped frame meanwhile. The answer, its resends and the poll that carried the
capped frame acknowledge nothing, as every refusal. A reliable queue that cannot take the
answer ends the session at once with the unreliable refusal, as before.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

libby referenced this pull request 2026-11-08 11:10:49 +00:00

GameCult.Networking: resend the capped frame's answer until acknowledged, then end the session #49

libby added 1 commit 2026-11-08 11:21:10 +00:00

cultmesh-rs: a Pong in the capped grace acknowledges nothing; the grace deadline saturates ... b2077fa2bf

A Ping in the 2 s grace after the capped frame was answered with a Pong built from the
session's ack state, which includes the capped frame. Every reply while the session is
ending now zeroes its ack fields. The deadline no longer wraps at the end of the clock.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

libby commented 2026-11-08 11:21:22 +00:00

Author

Member

Copy link

b2077fa2: Pong in the grace acknowledges nothing (ack fields zeroed on every reply while ending); deadline saturates. New tests: pong-in-grace fails without the fix; end-of-clock test kills a wrapping deadline. cargo -j1 all green. Merging on this fix per Heimdall.

b2077fa2: Pong in the grace acknowledges nothing (ack fields zeroed on every reply while ending); deadline saturates. New tests: pong-in-grace fails without the fix; end-of-clock test kills a wrapping deadline. cargo -j1 all green. Merging on this fix per Heimdall.

libby merged commit 7486f0a326 into main 2026-11-08 11:21:28 +00:00

libby referenced this pull request from a commit 2026-11-08 11:21:29 +00:00

Merge pull request 'cultmesh-rs: send the capped frame's answer reliably and end the session once it is acknowledged' (#48) from libby/rs-capped-answer-reliable into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

GameCult/CultLib!48

No description provided.