Repository navigation
Switch IPCChannel to raw unix socket transport - #1132
creativecbr wants to merge 3 commits into
Conversation
Replace the Network.framework IPC path with a POSIX UNIX domain socket implementation while keeping the same message framing and public behavior. Also align observability and style with the SDK: add concise [IPC] logs at listen/connect/close boundaries and keep comments minimal.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
@pblazej @hiroshihorie @xianshijing-lk I made the necessary improvements to the first version and refactored it slightly, while trying to keep the changes as atomic as possible. This is a very important change for us, as some devices were not able to start screen sharing at all. Regression tests were performed on physical devices:
|
|
Hey @creativecbr thank you for a detailed report and PR, I think we need to be a little conservative about essentially reverting to #100 - by understanding the root cause first. I added more specific logs in this branch, it would be great to check them before the next pass: |
|
Hey @pblazej ! That issue was difficult to investigate because my first attempt, with the additional logging enabled, was successful, the connection was established and streaming started correctly. As far as I know, no functional changes were introduced apart from the extra logs, which made the result unexpected and left me without a clear direction for further analysis. However, all subsequent attempts on the same device failed. The room connection was established successfully, but the stream itself never started. To provide the full context, I have attached logs from both scenarios: |
The reporter's failing run showed no IPC problem: the host rejected the auto-publish with "Participant does not have permission to publish", so no listener was ever created and the extension retried against a stale socket file until the user stopped the broadcast. - Check for a room and publisher before permissions in _publish. A disconnected room resets the local participant to default permissions (canPublish false), so a publish while disconnected reported a permission error instead of the missing publisher - Stop the broadcast when the automatic publish fails, instead of leaving the extension running with nothing to connect to - Describe every LiveKitErrorType case; insufficientPermissions and deviceAccessDenied fell through to "Unknown". Drop the default so new cases need a description - Log local participant permission changes at .info Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
Thanks @creativecbr, the failing run is actually |
|
It seems that it works! @pblazej I made three attempts and I can confirm 3/3 passes. :) 3_attempt.txt Logs here. |
In every successful run the host's listener comes up about 6 s after the screen share publish begins, and the publish completes right after, so startCapture itself (or the whole process) is stalled for that long. Log with the call-site uptime at startCapture entry, after the main-actor hop for the screen bounds, and when the receiver task starts; the SDK logger writes on a utility queue, so its own timestamps can lag. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
Great, thanks @creativecbr - these runs all start from a fresh connect though, while the failing one was a second broadcast in the same app session, could you repeat that flow (start → stop → start, without relaunching) on the latest |
|
Okay, but.... :D We have a very simple scenario. After connecting to the room, we automatically start broadcasting. When the connection is about to end, we stop the broadcast and immediately leave the room. There is no possibility of stopping the broadcast and starting it again within the same connection. Could there be some retry mechanism involved that is a black box from our perspective? |
|
@creativecbr I extracted (small) non-logging changes into the above PR - should do the job 🙆♂️ |
- Check for a room and publisher before permissions in _publish; a disconnected room resets the local participant to default permissions, so publishing while disconnected reported a permission error - Stop the broadcast when the automatic screen share publish fails, instead of leaving the extension retrying against a stale socket - Skip the automatic publish in a disconnected room, so a stale Room cannot stop another room's working broadcast - Treat NWListener .waiting as transient rather than fatal - Fix the IPC reconnect delay, which UInt64(0.1) truncated to zero - Copy the shared NWParameters before setting requiredLocalEndpoint, so concurrent listeners stop binding each other's socket paths - Describe every LiveKitErrorType case; insufficientPermissions and deviceAccessDenied printed as "Unknown" Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Thanks a lot, so we are waiting for those changes in release. |
|
Closing in favor of #1142 |
When the automatic screen share publish failed, the broadcast extension kept retrying against a socket with no listener, so the broadcast came up without frames. - **Publish:** `_publish` checked permissions before the publisher, and a disconnected room resets the local participant's permissions, so it failed as `Unknown(Participant does not have permission to publish)`; it now checks the publisher first, stops the broadcast on failure, and every `LiveKitErrorType` has a description. - **IPC:** the listener treats `.waiting` as transient, reconnects every 100 ms instead of busy-looping (`UInt64(0.1)` truncated the delay to zero), and copies the shared `NWParameters` so concurrent listeners stop binding each other's paths, which also de-flakes `IPCChannelTests`. - **Capturer:** stopping before the extension connects now cancels the waiting listener instead of leaking the capturer, and a second active broadcast capturer (e.g. two connected rooms) logs a warning, since only one of them can receive the broadcast. Network.framework is not the cause: the `SO_NECP_LISTENUUID` warnings also appear in successful runs. Fixes: #1132 --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2 participants
Replaces the Network.framework IPC transport in IPCChannel with a raw UNIX domain stream socket implementation (socket/bind/listen/accept/connect) while preserving LiveKit’s existing IPC framing and public behavior.
On some iOS/iPadOS devices, the current NWListener/NWConnection path for UNIX-socket IPC fails during listener setup with NECP path evaluation errors (observed as SO_NECP_LISTENUUID failed [22: Invalid argument]). In that failure mode, the broadcast extension and host app do not complete IPC handshake, and ReplayKit publishing can come up without frame flow.
What changes in this PR:
Scope and non-goals:
Regression/testing status:
Manual regression verification completed on:
In both environments, IPC handshake and screen-share flow are stable, and the issue is no longer reproducible.
Compile/build sanity also passes for the updated path.