Port data streams over to rust livekit-ffi version - #769
Draft
1egoman wants to merge 5 commits into
Draft
Conversation
…on based data streams implementation still exists
…otobufs Generated with protoc 25.1 + mypy-protobuf 3.6.0 (matching CI); data_stream_pb2 and room_pb2 are now reproducible from the pinned submodule, and ffi/data_track/ participant pick up the additive data-track schema messages.
Replaces the hand-rolled Python data streams (client-side header/chunk/trailer framing over SendStreamHeader/Chunk/TrailerRequest) with the FFI's native implementation (data streams v2: single-packet streams + deflate): - Writers open handle-based FFI streams (text/byte_stream_open/write/close); chunking, stream ids, and compression now happen in rust - send_text/send_file are one-shot FFI calls and gain a compress option - Incoming streams arrive via text/byte_stream_opened room events; readers consume per-handle reader events after a read_incremental request, and unhandled topics dispose the owned reader handle - New public API: StreamError (raised when a stream terminates abnormally, previously indistinguishable from clean EOS) and RoomOptions.data_stream/DataStreamOptions.max_payload_byte_length - Drops the use_legacy_client_implementation override, so data streams v2 support is advertised to other clients The consumer-facing API is unchanged. Behavior changes: read errors now raise StreamError, stream ids are rust-generated unless supplied, sender_identity is honored consistently (was ignored for chunks/trailers), and trailers of targeted streams are no longer broadcast room-wide.
Moves the submodule pin from the data-streams-v2 merge commit to the tagged v0.12.73 release, so download_ffi.py (which reads the version from the submodule's livekit-ffi/Cargo.toml) fetches an official prebuilt binary that includes data streams v2. The FFI protocol files are unchanged between the two commits, so the generated protobufs regenerate identically.
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.
(The python version of livekit/node-sdks#697)
Warning
The tests will not pass until a new
livekit-ffibuild is made incorporating the data stream v2 updates and the version is upgraded in here.Previously, the python sdk had its own data streams implementation. My understanding is there isn't really a good reason for this, and it's more of an artifact of history - the node/python sdks had data streams added first, and the rust implementation came later on.
With data streams v2, the rust implementation will both be quite a bit more stable and gain some new features that make it significantly more performant (single packet data streams and DEFLATE compression when it makes the payload smaller). This roughly doubles data stream throughput in local testing.
So, port the python sdk to use the rust sdk data streams v2 implementation, and completely remove the typescript implementation. This is being done via the already-existing
livekit-ffidata streams messages which the C++ and unity sdks use today.New behaviors worth being aware of
All of these are either data streams v2 related changes, or bug fixes.
1.
compressoptionWhen sending a data stream, there is a new
compressoption. Just like how this works on web / rust, this defaults totrue. is set tofalse, then compression will be disabled (useful if you know the data you are sending isn't compressible / you are doing your own compression, which is not uncommon in robotics use cases). For 95% of users, they should leave this set totrue.2. Max data stream size
In a rust data streams v2 pull request review comment, we decided that for security reasons it made sense to introduce a maximum data stream size as a DOS protection. This limit is by default
5gb- any data stream that is larger will now read up until that point, and if the stream keeps going, a "payload too large" error will be raised on the stream and exposed to a user on the subsequent.read()call.If a user is sending a large file, they can override this by setting a new
maxPayloadByteLengthoption on theroom.connectcall:3. Throwing data stream errors rather than exclusively logging them
The old node specific data streams implementation didn't properly surface errors to the caller which were encountered while reading the stream. As a prerequisite for exposing the error for item 2, I fixed this, but it means that now if a data stream were to fail, errors would get thrown when in the past they would get logged and dropped.
Todo