Expose RxBufferSize/TxBufferSize config properties, wire to ws-streaming - #15
Open
denise-opendaq wants to merge 1 commit into
Open
Expose RxBufferSize/TxBufferSize config properties, wire to ws-streaming#15denise-opendaq wants to merge 1 commit into
denise-opendaq wants to merge 1 commit into
Conversation
ws-streaming's wss::detail::peer previously always allocated its compiled-in default buffer sizes (32 MiB tx, 1 MiB rx) for every connection, with no way to override them from openDAQ - see the companion change on ws-streaming's configurable-buffer-sizes branch, which adds rx_buffer_size/tx_buffer_size parameters to connection, client, and server. Add RxBufferSize/TxBufferSize Int properties to both WsStreamingServer::createDefaultConfig() and WsStreaming::createDefaultConfig(), and thread them through to the wss::server/wss::client construction call in each. Also wire config through to WsStreaming's constructor and onCreateStreaming(), which previously received the config parameter but silently discarded it. Defaults are chosen per role rather than reusing the old shared 32 MiB value: a server's traffic is transmit-heavy (streaming samples out to clients) so it gets the larger TxBufferSize (4 MiB) and smaller RxBufferSize (1 MiB); a client's traffic is receive-heavy (mostly receiving sample data, sending only small subscribe/RPC requests) so it gets the opposite - RxBufferSize 4 MiB, TxBufferSize 1 MiB. Verified with a custom LD_PRELOAD allocation tracer against quick_start_empty connecting to quick_start_simulator over daq.lt://: total bytes allocated during the addDevice() call dropped from 44.7 MB to 15.5 MB, with the two buffer allocations now showing up at exactly 4194304 and 1048576 bytes as expected, and the connection still completing successfully (all signals available/subscribed as before).
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.
ws-streaming's wss::detail::peer previously always allocated its compiled-in default buffer sizes (32 MiB tx, 1 MiB rx) for every connection, with no way to override them from openDAQ - see the companion change on ws-streaming's configurable-buffer-sizes branch, which adds rx_buffer_size/tx_buffer_size parameters to connection, client, and server.
Add RxBufferSize/TxBufferSize Int properties to both WsStreamingServer::createDefaultConfig() and
WsStreaming::createDefaultConfig(), and thread them through to the wss::server/wss::client construction call in each. Also wire config through to WsStreaming's constructor and onCreateStreaming(), which previously received the config parameter but silently discarded it.
Defaults are chosen per role rather than reusing the old shared 32 MiB value: a server's traffic is transmit-heavy (streaming samples out to clients) so it gets the larger TxBufferSize (4 MiB) and smaller RxBufferSize (1 MiB); a client's traffic is receive-heavy (mostly receiving sample data, sending only small subscribe/RPC requests) so it gets the opposite - RxBufferSize 4 MiB, TxBufferSize 1 MiB.
Verified with a custom LD_PRELOAD allocation tracer against quick_start_empty connecting to quick_start_simulator over daq.lt://: total bytes allocated during the addDevice() call dropped from 44.7 MB to 15.5 MB, with the two buffer allocations now showing up at exactly 4194304 and 1048576 bytes as expected, and the connection still completing successfully (all signals available/subscribed as before).