Add support for very large calls/returns #6

New Issue

sergeych · 2025-03-07T02:38:05+03:00

sergeych commented

2025-03-07 02:38:05 +03:00

If the command/answer serialized data is above some reasonable limit, say. 256Kb, it should be splitted into special blocks, and be sent one by one, calling yield between sends, to allow concurrency on the channel, e.g., prevent one long data block to lock the whole channel.

This can't be done on the transport level though as it will inflate blocks in a subopttimal way, also, it will still lock the channel as transport device will get the single request/response monopolizing the channel. We can add more block types instead, like partial block m of n, be rebuilt on receiver and then processed like normal incoming block.

If the command/answer serialized data is above some reasonable limit, say. 256Kb, it should be splitted into special blocks, and be sent one by one, calling yield between sends, to allow concurrency on the channel, e.g., prevent one long data block to lock the whole channel. This can't be done on the transport level though as it will inflate blocks in a subopttimal way, also, it will still lock the channel as transport device will get the single request/response monopolizing the channel. We can add more block types instead, like partial block m of n, be rebuilt on receiver and then processed like normal incoming block.

sergeych added the

enhancement

label 2025-03-07 02:38:05 +03:00

sergeych self-assigned this 2025-03-07 02:38:05 +03:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: SergeychWorks/kiloparsec#6