Data track integration

[1egoman]

Integrates the data track managers (both incoming and outgoing) into the existing sdk Room and RemoteParticipant interfaces. Once this is merged, data tracks is fully implemented!

Interface - Publishing

const localDataTrack = await room.publishDataTrack({name: "data track name"});
await localDataTrack.tryPush(new Uint8Array(/* ... */));

// Once you are done with the local data track, it can be unpublished:
await localDataTrack.unpublish();

Interface - Subscribing

// There are two ways to get a remote data track, either a room event:
room.on(RoomEvent.RemoteDataTrackPublished, async (remoteDataTrack) => {
  // ...
});

// Or a new field on `RemoteParticipant`:
const remoteDataTrack = remoteParticipant.dataTracks.get("track name"); // Get a data track which has been published
const remoteDataTrack = await remoteParticipant.dataTracks.getDeferred("track name"); // Get a data track which _will_ be published shortly

// Either way, once you have a remoteDataTrack, you can subscribe:
const stream = await remoteDataTrack.subscribe(/* optional abort signal */);
for await (const frame of stream) {
  console.log(`Received bytes from ${remoteDataTrack.info.name}:`, frame.payload);
}

Todo:

• Decide on how to show the example app chart vs hexdump - show both? Just one? commit introducing chart.
• Add changeset

Resolves CLT-2582

[changeset-bot]

⚠️ No Changeset found

Latest commit: f63d21c

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

size-limit report 📦

Path	Size
dist/livekit-client.esm.mjs	94.89 KB (+9.4% 🔺)
dist/livekit-client.umd.js	103.7 KB (+6.61% 🔺)

[lukasIO]

a couple of nits that would be nice to address.

More generally and important: what happens currently when running this against older servers that don't have DataTrack support?

[lukasIO]

what's the intention behind this differentiation? Why not just drop them for lossy?

[1egoman]

That's what I originally was doing but this didn't work for large data track payloads - here is some more context as to why from some notes I wrote up:

• If the _data_tracks rtc data channel buffer was full, the existing logic would drop packets (what the lossy data channel currently does).
  • This doesn't work though for data track packets, because if the first n packets of a frame get enqueued but the last packet(s) get dropped because there isn't enough room in the rtc data channel buffer, the receiver only receives a partial set of packets which will never fully decode into a data track frame.
  • If packets aren't buffered like this, then it becomes impossible to send data track payloads > ~75k bytes (the e2e tests are checking this case)
  • Solution (commit): buffer data track packets instead of dropping them if the rtc data channel buffer is full

If there's some other way to handle this, I'm open to alternatives but what I did here was the most straightforward way I could think of.

[1egoman]

To provide context on this:

what happens currently when running this against older servers that don’t have DataTrack support?

After talking with @ladvoc , I can confirm that on the subscribing end the new messages are just dropped, and on the publishing end the failure would end up as a timeout error. So nothing breaks in a incredibly bad way here.

We decided that including a note in the publish function docstring and also maybe a small comment in the timeout error message would be good enough to guard against this - did this here.