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
max-connections is used to set the maximum amount of concurrent connections that the switch accepts.
Currently, it is also being used to set the max-relay-peers, here.
This allows the waku node to always have room for other protocols.
However, this is not something that happens in the other way around. This means that other protocols can fill the number of max-connections, disabling the ability of relaying messages for the waku node.
Details
Given the following scenario, in the following order:
Setup a bootstrap only node.
Setup a filter relay node with max-connections=5
Setup 5 filter client nodes, connected to the filter relay node. This will cap the number of connections.
Setup another filter relay node, and connect them to the bootstrap node.
If we inject messages to the nodes in point 4, the node in point 1 will not be able to receive them, as it will not connect to those nodes due to the maximum number of connections reached.
Acceptance criteria
In the same way that a node has always 20% connections for other protocols, should also have at least d_low connections reserved for relay as well.
If not, there can happen a lot of bad situations that might be complex to find the root of the issue.
If by any chance a relay node has disconnections to other relay nodes and has less than d_low relay connections, and in the meantime new filter client nodes are connected, unless those clients are disconnected again, the node will stop relaying messages.
This can be checked because it will start logging that there are not enough peers to publish, but if it loses connections to ALL other relay nodes, it will not log anything, and it will stop receiving messages.
The text was updated successfully, but these errors were encountered:
Background
max-connections
is used to set the maximum amount of concurrent connections that the switch accepts.Currently, it is also being used to set the
max-relay-peers
, here.This allows the waku node to always have room for other protocols.
However, this is not something that happens in the other way around. This means that other protocols can fill the number of
max-connections
, disabling the ability of relaying messages for the waku node.Details
Given the following scenario, in the following order:
max-connections=5
If we inject messages to the nodes in point 4, the node in point 1 will not be able to receive them, as it will not connect to those nodes due to the maximum number of connections reached.
Acceptance criteria
In the same way that a node has always 20% connections for other protocols, should also have at least
d_low
connections reserved for relay as well.If not, there can happen a lot of bad situations that might be complex to find the root of the issue.
If by any chance a relay node has disconnections to other relay nodes and has less than
d_low
relay connections, and in the meantime new filter client nodes are connected, unless those clients are disconnected again, the node will stop relaying messages.This can be checked because it will start logging that there are not enough peers to publish, but if it loses connections to ALL other relay nodes, it will not log anything, and it will stop receiving messages.
The text was updated successfully, but these errors were encountered: