e2e reliablility for data channel #1546
Conversation
cnderrauber
commented
Jun 11, 2025
cnderrauber
commented
- Resend reliable message from last sequence received by server after connection resumed
- Report last received reliable message from other participants on resuming
* Resend reliable message from last sequence received by server after connection resumed * Report last received reliable message from other participants on resuming
🦋 Changeset detectedLatest commit: e8eeb92 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
size-limit report 📦
|
| // make sure we do have a data connection | ||
| await this.ensurePublisherConnected(kind); | ||
|
|
||
| if (kind === DataPacket_Kind.RELIABLE) { |
There was a problem hiding this comment.
hmm, thinking this.ensurePublisherConnection might race for parallel sendDataPacket s so I'm not sure if it's guaranteed to respect invocation order.
There was a problem hiding this comment.
There is no await between increase sequence and dc.Send so the messages in the wire are in order and we can guaranteed the message has been received in the order which is sent. The sendxxx methods are async so I think the developer needs to wait for the first call completed before the next call if the message order is matter?
There was a problem hiding this comment.
yeah, that's right.
I just wonder what happens to our buffer logic here if the message order doesn't match the sequence number.
We simply pop and don't really look at the actual sequence number order in the buffer, right?
There was a problem hiding this comment.
No, the message order in the buffer should be same as the sequence number. I assume the message will be in order since there is no async statements between increase the number and push to buffer, is it wrong in the typescript?
There was a problem hiding this comment.
got it, yeah, I think your assumption is correct!
Ports basic concepts from livekit/client-sdk-js#1546 The differences are mostly syntactic, due to how backpressure is handled via events in Swift. Thus, I decided to separate `SendBuffer` that's tightly coupled to RTC and `RetryBuffer` with slightly different semantics.
