chore: capping mechanism for relay and service connections #3184
Conversation
|
You can find the image built from this PR at Built from c926c9d |
darshankabariya
changed the title
darshankabariya
force-pushed
the
capping_mechanism
branch
from
2e420e4 to
fa97a4f
Compare
darshankabariya
requested review from
gabrielmer,
Ivansete-status,
NagyZoltanPeter and
SionoiS
| @@ -993,6 +999,24 @@ proc new*( | |||
| # Leave by default 20% of connections for service peers | |||
| maxRelayPeersValue = maxConnections - (maxConnections div 5) | |||
|
|
|||
| var maxServicePeersValue = 0 | |||
| var d_low = 4 | |||
There was a problem hiding this comment.
I think we shouldn't hardcode this and take it directly from WakuRelay
| # relay has higher priority then service peers | ||
| else: | ||
| maxServicePeersValue = | ||
| max(maxConnections - maxRelayPeersValue, maxConnections div 5) |
There was a problem hiding this comment.
what's the logic of this line? Why the maxConnections div 5?
There was a problem hiding this comment.
My logic is to reserve 20% for service peers if the user does not provide maxService, as we discuss in nwaku pm we need to change whole logic
There was a problem hiding this comment.
The PR doesn't compile snif snif :s
Re-thinking about this, I suggest doing the following:
We need to keep maxConnections config param because this needs to be passed to the nim-libp2p-Switch object.
On the other hand, I would only add an additional parameter, named protoConnWeights , a.k.a. proto-conn-weights, with the following logic:
If proto-conn-weights is not passed, then we apply the internal limits of 70% for relay, and the other 30% is evenly distributed for other protocols.
If proto-conn-weights=relay:80;services:20, we apply the internal limits of 80% for relay, and the other 20% is evenly distributed for other protocols.
We need to make sure the relay limit is bigger than DHigh ( we can create a
public Constant in waku_relay/protocol.nim )
nwaku/waku/waku_relay/protocol.nim
Line 73 in 09f05fe
wdyt @NagyZoltanPeter , @gabrielmer , @darshankabariya ?
| @@ -993,6 +995,20 @@ proc new*( | |||
| # Leave by default 20% of connections for service peers | |||
| maxRelayPeersValue = maxConnections - (maxConnections div 5) | |||
|
|
|||
| var maxServicePeersValue = 0 | |||
| var d_low = 4 | |||
There was a problem hiding this comment.
We will need to use the d_low value extracted from waku_relay. Perhaps defining a const in waku_relay and use that value
My bad, I pushed the code without a local build. I’ll update this PR until we finalize it. |
At the moment, we have parameters like Instead, I believe users generally don’t think in terms of absolute numbers for services and relays. From a psychological perspective, they might find it more intuitive to think in percentages—e.g., 80% for services, 20% for relays. My suggestion is to simplify this structure. We should keep If users don’t provide this percentage, we could default to a ratio, as Ivan suggested. I believe this would simplify the experience while maintaining flexibility. |
|
I like your idea! IMO I feel we still need hardcoded minimum still so that you can't, by mistake brick your node. |
|
Same opinion here, having 2 params, a maximum and a ratio to know how many to allocate for each should make things simple yet customizable :) |
This PR prevents nodes from becoming isolated from the network by implementing a capping mechanism for service and relay peers. This ensures there is always room available for relay peers at any given time.
close #3163