Multicam seams: source peer on inbound messages, per-peer frame acks - #199
Closed
darioalessandro wants to merge 1 commit into
Closed
Multicam seams: source peer on inbound messages, per-peer frame acks#199darioalessandro wants to merge 1 commit into
darioalessandro wants to merge 1 commit into
Conversation
Two behavior-preserving cuts that the multicam director needs (PR1): - MultipeerServiceDelegate.didReceiveMessage now carries the source peer. The 1:1 SessionCoordinator ignores it (its single link makes the source unambiguous); a multicam controller will route responses by it. - sendMessage/sendOrGoToScanning accept an explicit peer list (nil = all connected, unchanged), and the monitor's frame ack now addresses only the camera whose frame was consumed — with several cameras, a broadcast ack would advance every camera's credit window on one camera's frame. Single-cam behavior is identical (one connected peer makes both forms the same). New test proves the ack targets only the sending peer with two peers connected; full suite green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
📊 Test Coverage Report✅ 633/645 tests passed · ⏭️ 12 skipped
🎥 Capture & session core
📁 Full report — 88 files
Generated from |
Member
Author
|
Consolidated into the single feature PR per Dario's request: #203 (branch kept, not deleted). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR1 of the multicam plan (stacked on #198). Behavior-preserving:
MultipeerServiceDelegate.didReceiveMessage(_:from:)— inbound messages carry their source peer. The 1:1SessionCoordinatordeliberately ignores it; the upcoming multicam controller demuxes responses by it.sendMessage/sendOrGoToScanningtake an optional explicit peer list (nil = all connected, unchanged).RequestFrame) now addresses only the camera whose frame was consumed. With one peer this is identical to the old broadcast; with N cameras a broadcast ack would let every camera send on one camera's consumed credit.New test: with two connected peers, each frame's ack targets exactly its source. Full suite green.
🤖 Generated with Claude Code