namillum
Version:
Bubble Protocol SDK
36 lines (25 loc) • 1.76 kB
Markdown
id: core-messaging-limits
title: Messaging Limits
keywords:
- core
- messaging
- limits
description: Core protocol design - messaging limits.
The volume and size of peer-to-peer communication for a Zilliqa node is controlled by several factors at different parts of the stack.
## Message Size
- `MIN_READ_WATERMARK_IN_BYTES`: The minimum number of bytes read from the socket before we act on the data. It is basically the `lowmark` parameter required by the libevent function `bufferevent_setwatermark`.
- `MAX_READ_WATERMARK_IN_BYTES`: The maximum number of bytes read from the socket before we stop accepting further input. It is basically the `highmark` parameter required by the libevent function `bufferevent_setwatermark`.
- `MAX_GOSSIP_MSG_SIZE_IN_BYTES`: The maximum size of a socket message with start byte = `START_BYTE_GOSSIP`. If a message reaches this size, the sender is blacklisted.
## Message Count
- `MAXSENDMESSAGE`: The number of active threads for the outgoing message pool.
- `MAXRECVMESSAGE`: The number of active threads for the incoming message pool.
- `SENDQUEUE_SIZE`: The maximum size of the outgoing message queue (before transfer to the outgoing pool), beyond which any further messages are dropped.
- `MSGQUEUE_SIZE`: The maximum size of the incoming message queue (before transfer to the incoming pool), beyond which any further messages are dropped.
## Sending Frequency
- `MAXRETRYCONN`: The maximum number of socket connection attempts to perform for sending messages to a peer.
- `PUMPMESSAGE_MILLISECONDS`: The maximum wait time (minimum being 1 ms) before re-attempting socket connection.
## Active Connections
- `MAX_PEER_CONNECTION`: The maximum number of active connections to a specific peer.