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
title: 'net/peerset: Optimize substream opening duration for `SetReservedPeers`'
2
+
doc:
3
+
- audience: Node Dev
4
+
description: |-
5
+
While triaging the Versi-net, I've discovered that the connection between collators and validators sometimes takes less than 20ms, while at other times it takes more than 500ms.
6
+
7
+
In both cases, the validators are already connected to a different protocol. Therefore, opening and negotiating substreams must be almost instant.
8
+
9
+
The slot timer of the peerset artificially introduces the delay:
10
+
- The `SetReservedPeers` is received by the peerset. At this step, the peerset propagated the `closedSubstream` to signal that it wants to disconnect previously reserved peers.
11
+
- At the next slot allocation timer tick (after 1s), the newly added reserved peers are requested to be connected
12
+
13
+
This can introduce an artificial delay of up to 1s, which is unnecessary.
14
+
15
+
To mitigate this behavior, this PR:
16
+
- Transforms the ` enum PeersetNotificationCommand` into a structure. Effectively, the peerset can specify directly to close some substreams and open other substreams
17
+
- Upon receiving the `SetReservedPeers` command, peers are moved into the `Opening` state and the request is propagated to the litep2p to open substreams.
18
+
- The behavior of the slot allocation timer remains identical. This is needed to capture the following edge cases:
19
+
- The reserved peer of the `SetReservedPeers` is not disconnected, but backoff / pending closing.
20
+
- The reserved peer is banned
21
+
22
+
cc @paritytech/networking
23
+
24
+
Detected during versi-net triaging of elastic scaling: https://github.com/paritytech/polkadot-sdk/issues/10310#issuecomment-3543395157
0 commit comments