You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe what you want implemented
Options to consider:
Rate limiter - as these messages (the one-to-one Kadcast messaging) are secondary compared to Consensus messaging, they could be sent at 20 TPS - an config param. This should enable a node to queue messages in an internal queue instead of flooding UDP buffers
Increase udp_sender_buffer size at startup as Kadcast already does with udp_recv_buffer
Increase recovery rate in RaptorQ (the least preferable for now)
Any combination of the above.
Describe "Why" this is needed
In essence, we use RaptorQ to recover from dropped UDP messages in the outside network. We should not lose UDP messages on writing them onto local udp_sender_buffer.
As per finding in #1399 (comment), a strategy should be considered to avoid losing sent messages silently. At first, the issue from 1399 should be reproduced on Devnet. ,
Describe what you want implemented
Options to consider:
udp_sender_buffer
size at startup as Kadcast already does with udp_recv_bufferDescribe "Why" this is needed
In essence, we use RaptorQ to recover from dropped UDP messages in the outside network. We should not lose UDP messages on writing them onto local udp_sender_buffer.
As per finding in #1399 (comment), a strategy should be considered to avoid losing sent messages silently. At first, the issue from 1399 should be reproduced on Devnet. ,
Additional context
Issues:
The text was updated successfully, but these errors were encountered: