dusk-blockchain
dusk-blockchain copied to clipboard
Mitigate pressure on socket send buffer
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 https://github.com/dusk-network/dusk-blockchain/issues/1399#issuecomment-1139681405, 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:
- https://github.com/dusk-network/dusk-blockchain/issues/1399
- https://github.com/dusk-network/dusk-blockchain/issues/1380