Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

transport-manager/part 2: Unknown secondary connections for multiple dials #242

Open
lexnv opened this issue Sep 9, 2024 · 1 comment
Open
Labels
bug Something isn't working

Comments

@lexnv
Copy link
Collaborator

lexnv commented Sep 9, 2024

Part two of: #172

Detected during triaging of: paritytech/polkadot-sdk#5609

    "2024-09-07 21:43:54.157  WARN tokio-runtime-worker litep2p::transport-manager: unknown connection opened as secondary connection, discarding peer=PeerId(\"12D3KooWGTnNXimfyieaZAeyRDvZLQpFF7Nr9a8bS3oN4yMPQExZ\") connection_id=ConnectionId(2347697) address=\"/ip4/212.224.112.221/tcp/49054/ws/p2p/12D3KooWGTnNXimfyieaZAeyRDvZLQpFF7Nr9a8bS3oN4yMPQExZ\" dial_record=AddressRecord { score: 100, address: \"/ip4/212.224.112.221/tcp/30333/p2p/12D3KooWGTnNXimfyieaZAeyRDvZLQpFF7Nr9a8bS3oN4yMPQExZ\", connection_id: Some(ConnectionId(2347695)) }",
    "2024-09-07 21:43:54.243  WARN tokio-runtime-worker litep2p::transport-manager: unknown connection opened as secondary connection, discarding peer=PeerId(\"12D3KooWGTnNXimfyieaZAeyRDvZLQpFF7Nr9a8bS3oN4yMPQExZ\") connection_id=ConnectionId(2347700) address=\"/ip4/212.224.112.221/tcp/49068/ws/p2p/12D3KooWGTnNXimfyieaZAeyRDvZLQpFF7Nr9a8bS3oN4yMPQExZ\" dial_record=AddressRecord { score: 100, address: \"/ip4/212.224.112.221/tcp/30333/p2p/12D3KooWGTnNXimfyieaZAeyRDvZLQpFF7Nr9a8bS3oN4yMPQExZ\", connection_id: Some(ConnectionId(2347695)) }",
    "2024-09-07 21:43:54.309  WARN tokio-runtime-worker litep2p::transport-manager: unknown connection opened as secondary connection, discarding peer=PeerId(\"12D3KooWGTnNXimfyieaZAeyRDvZLQpFF7Nr9a8bS3oN4yMPQExZ\") connection_id=ConnectionId(2347701) address=\"/ip4/212.224.112.221/tcp/49072/ws/p2p/12D3KooWGTnNXimfyieaZAeyRDvZLQpFF7Nr9a8bS3oN4yMPQExZ\" dial_record=AddressRecord { score: 100, address: \"/ip4/212.224.112.221/tcp/30333/p2p/12D3KooWGTnNXimfyieaZAeyRDvZLQpFF7Nr9a8bS3oN4yMPQExZ\", connection_id: Some(ConnectionId(2347695)) }",
    "2024-09-07 21:43:54.335  WARN tokio-runtime-worker litep2p::transport-manager: unknown connection opened as secondary connection, discarding peer=PeerId(\"12D3KooWGTnNXimfyieaZAeyRDvZLQpFF7Nr9a8bS3oN4yMPQExZ\") connection_id=ConnectionId(2347704) address=\"/ip4/212.224.112.221/tcp/49076/ws/p2p/12D3KooWGTnNXimfyieaZAeyRDvZLQpFF7Nr9a8bS3oN4yMPQExZ\" dial_record=AddressRecord { score: 100, address: \"/ip4/212.224.112.221/tcp/30333/p2p/12D3KooWGTnNXimfyieaZAeyRDvZLQpFF7Nr9a8bS3oN4yMPQExZ\", connection_id: Some(ConnectionId(2347695)) }",
    "2024-09-07 21:43:54.449  WARN tokio-runtime-worker litep2p::transport-manager: unknown connection opened as secondary connection, discarding peer=PeerId(\"12D3KooWGTnNXimfyieaZAeyRDvZLQpFF7Nr9a8bS3oN4yMPQExZ\") connection_id=ConnectionId(2347706) address=\"/ip4/212.224.112.221/tcp/49078/ws/p2p/12D3KooWGTnNXimfyieaZAeyRDvZLQpFF7Nr9a8bS3oN4yMPQExZ\" dial_record=AddressRecord { score: 100, address: \"/ip4/212.224.112.221/tcp/30333/p2p/12D3KooWGTnNXimfyieaZAeyRDvZLQpFF7Nr9a8bS3oN4yMPQExZ\", connection_id: Some(ConnectionId(2347695)) }",

When we dial multiple addresses of the same peer, we set the same connection ID for all addresses.
The first successful connection is kept around, while the other pending connections are canceled.

Some thoughts and possible root causes:

  • I suspect there might be a race between canceling dials and when dials are reported as successful, with the side effect of generating multiple warnings, of similar addresses with the same connection id. All warnings share the same ConnectionId(2347695).
  • There's also a change that we don't track canceled dials properly (I remember we did some changes around those here: Fix TCP, WebSocket, QUIC leaking connection IDs in reject() #198)
@lexnv lexnv added the bug Something isn't working label Sep 9, 2024
@lexnv
Copy link
Collaborator Author

lexnv commented Sep 9, 2024

The pending incoming connections are only going through the filter of the connection limits at the moment:

if self.on_pending_incoming_connection().is_ok() {
tracing::trace!(
target: LOG_TARGET,
?connection_id,
"accept pending incoming connection",
);
let _ = self
.transports
.get_mut(&transport)
.expect("transport to exist")
.accept_pending(connection_id);

We can improve this by rejecting incoming connections for peers with a primary and secondary connections.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant