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
The transport service handler intent is to downgrade connections (leading to possibly closing them), if substreams where not open in a given timeframe:
Here we should match for Some(InnerTransportEvent::SubstreamOpened and move forward the timeout future.
With the current implementation, we downgrade connections at 5 seconds intervals.
Implications
We need to double-check if the protocol name matches the substream open protocol.
Further, InnerTransportEvent::SubstreamOpened needs to be extended with a connectionID because the TransportService holds up to 2 connections (primary and secondary). We should properly advance the timeout of the connection ID.
The text was updated successfully, but these errors were encountered:
…tions on substream inactivity (#260)
This PR advances the keep-alive timeout of the transport service.
Previously, the keep-alive timeout was triggered 5 seconds after the
connection was reported to the transport service regardless of substream
activity.
- (0secs) T0: connection established; keep-alive timeout set to 5seconds
in the future
- (4secs) T1: substream A, B, C opened
- (5secs) T2: keep-alive timeout triggered and the connection is
downgraded. T1 was not taken into account, otherwise, the keep-alive
timeout should be triggered at second 9 (T1 at 4 seconds + keepalive 5
seconds)
- (6secs) T3: substreams A, B, C closed -> connection closes
- (7secs) T4: cannot open new substreams even if we expected the
connection to be kept alive for longer
In this PR:
- `KeepAliveTracker` structure to forward the keep-alive timeout of
connections.
- Connection ID is forwarded to `SubstreamOpened` events to identify
properly substream Ids. This is needed because the `ConnectionContext`
contains up to two connections (primary and secondary)
### Testing Done
- test to ensure keepalive downgrades the connection after 5 seconds
- test to ensure keepalive is forwarded on substream activity
- test to ensure a downgraded connection with dropped substreams is
closed
Closes#253.
---------
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Co-authored-by: Dmitry Markin <dmitry@markin.tech>
Context
The transport service handler intent is to downgrade connections (leading to possibly closing them), if substreams where not open in a given timeframe:
litep2p/src/protocol/transport_service.rs
Lines 126 to 130 in d50ec10
When a connection is established, the timeout is properly tracked:
litep2p/src/protocol/transport_service.rs
Lines 213 to 216 in d50ec10
When the timeout expires, the connection is downgraded:
litep2p/src/protocol/transport_service.rs
Lines 414 to 427 in d50ec10
Issue
Opening of substreams are not taken into account for downgrading connections:
litep2p/src/protocol/transport_service.rs
Line 410 in d50ec10
Here we should match for
Some(InnerTransportEvent::SubstreamOpened
and move forward the timeout future.With the current implementation, we downgrade connections at 5 seconds intervals.
Implications
We need to double-check if the protocol name matches the substream open protocol.
Further,
InnerTransportEvent::SubstreamOpened
needs to be extended with aconnectionID
because theTransportService
holds up to 2 connections (primary and secondary). We should properly advance the timeout of the connection ID.The text was updated successfully, but these errors were encountered: