Improve peer connection handling #526
Conversation
|
Thank you for submitting this PR!
Getting other community members to do a review would be great help too on complex PRs (you can ask in the chats/forums). If you are unsure about something, just leave us a comment.
We currently aim to provide initial feedback/triaging within two business days. Please keep an eye on any labelling actions, as these will indicate priorities and status of your contribution. |
|
Hey @Jorropo, I ported this change over. |
| bsnet.cancel() | ||
| } | ||
|
|
||
| func (bsnet *impl) peerUpdatedSubscription(ctx context.Context, sub event.Subscription) { |
There was a problem hiding this comment.
This will race with the "old" version of notifications. Instead, we need to:
- Drop the old version (the net notifiee).
- Subscribe to
EvtPeerConnectednessChangedto get connectivity changes. - We care about "disconnected" events, but ignore "connected" events. Instead, rely on "protocol changed" and "identify" notifications to tell you that the peer supports bitswap (but check this with @Jorropo).
There was a problem hiding this comment.
Ah, but once you do this, you also have to move the existing connection walk to the top of this function. That is, you need to:
- Subscribe to connect/disconnect events.
- Process all existing connections.
- Start processing the events.
Failure modes:
- If you do 2 before 1, you could miss new connections.
- If you do 3 concurrent with 2, you could process a connect/disconnect event in step-3, then re-add the peer in the step-2 loop.
If you do them in order (1,2,3), you may end up processing a "connect" event for a disconnected peer in step 3, but then you'll process the disconnect event.
You could additionally check the peer's "connectedness" before updating a peer's status, but I don't think that is necessary.
There was a problem hiding this comment.
Hm. Although, I think we need to ask libp2p for all connections to the peer to make sure that we have a non-transient one. I wonder if that'll cause any issues? I assume we'll re-identify when we create a new connection... That'll require some testing.
Ideally libp2p would let us filter protocols by connection type, but that's a larger change.
Thoughts @Jorropo? @aschmahmann?
|
I've filed two related libp2p issues:
|
Codecov ReportAttention: Patch coverage is
@@ Coverage Diff @@
## main #526 +/- ##
==========================================
- Coverage 65.56% 65.48% -0.08%
==========================================
Files 207 204 -3
Lines 25597 25588 -9
==========================================
- Hits 16782 16756 -26
- Misses 7336 7351 +15
- Partials 1479 1481 +2
|
|
I believe libp2p/go-libp2p#2696 should unblock this from the libp2p side. |
|
@Jorropo any chance you can take a look and provide any remaining feedback? |
This PR was originaly submitted to ipfs/go-bitswap#590
Currently, the bitswap network only adds peers to its client/server peer lists that connected after the network has started. This means the network must be started before enabling the libp2p listeners, otherwise some peers may connect too early and never be added to the network.
To address this, this PR updates the bitswap network's
Start()method to first, listen for new peer connection events, and then iterate through all peers and add any that support the bitswap protocols. The issue and solution were originally described by @Stebalien in #83.