Open
Conversation
Both initiator and responder now time out if reads and/or writes are blocked for 30 seconds (default negotiation timeout). Introduces two tests to validate the new behaviour. Fixes #47.
vyzo
approved these changes
Nov 1, 2019
Member
Author
|
This fails CI because of libp2p/go-libp2p#736. |
Stebalien
reviewed
Nov 2, 2019
Member
Stebalien
left a comment
Stebalien
left a comment
There was a problem hiding this comment.
Note: IMO, the real issue is libp2p/go-libp2p#738.
(although canceling here as well is probably a good idea anyways)
| } | ||
| if err2 != nil { | ||
| return err2 | ||
| if clearFn, err := setDeadline(rwc); err != nil { |
Member
There was a problem hiding this comment.
So, many connections implement net.Conn (and SetDeadline) but don't actually implement it (and instead return an error). This is why we do things like https://github.com/libp2p/go-libp2p-transport-upgrader/blob/0d4065ec7151149beef41f3a8b1fbf6978ed12dc/upgrader.go#L111-L132.
Member
There was a problem hiding this comment.
Note: we could detect and handle os.ErrNoDeadline.
| "time" | ||
| ) | ||
|
|
||
| // NegotiationTimeout is the maximum time a protocol negotiation atempt is |
lidel
added a commit
to libp2p/go-libp2p
that referenced
this pull request
Jan 7, 2026
…t blocking streamWrapper.Close() can block indefinitely when the remote peer is slow or unresponsive during the multistream-select handshake completion. The lazy multistream protocol negotiation defers reading the handshake response until Close() is called. If the remote peer doesn't respond, the read blocks forever, causing goroutine leaks. This is particularly problematic for bitswap servers where taskWorkers can get stuck trying to close streams after sending blocks. The fix sets a read deadline (using DefaultNegotiationTimeout) before calling the multistream Close(), ensuring the operation will time out rather than block indefinitely. Related: multiformats/go-multistream#47 Related: multiformats/go-multistream#48
lidel
added a commit
to libp2p/go-libp2p
that referenced
this pull request
Jan 7, 2026
…t blocking streamWrapper.Close() can block indefinitely when the remote peer is slow or unresponsive during the multistream-select handshake completion. The lazy multistream protocol negotiation defers reading the handshake response until Close() is called. If the remote peer doesn't respond, the read blocks forever, causing goroutine leaks. This is particularly problematic for bitswap servers where taskWorkers can get stuck trying to close streams after sending blocks. The fix sets a read deadline (using DefaultNegotiationTimeout) before calling the multistream Close(), ensuring the operation will time out rather than block indefinitely. Related: multiformats/go-multistream#47 Related: multiformats/go-multistream#48
MarcoPolo
pushed a commit
to libp2p/go-libp2p
that referenced
this pull request
Jan 7, 2026
…t blocking streamWrapper.Close() can block indefinitely when the remote peer is slow or unresponsive during the multistream-select handshake completion. The lazy multistream protocol negotiation defers reading the handshake response until Close() is called. If the remote peer doesn't respond, the read blocks forever, causing goroutine leaks. This is particularly problematic for bitswap servers where taskWorkers can get stuck trying to close streams after sending blocks. The fix sets a read deadline (using DefaultNegotiationTimeout) before calling the multistream Close(), ensuring the operation will time out rather than block indefinitely. Related: multiformats/go-multistream#47 Related: multiformats/go-multistream#48
MarcoPolo
pushed a commit
to libp2p/go-libp2p
that referenced
this pull request
Jan 8, 2026
…t blocking streamWrapper.Close() can block indefinitely when the remote peer is slow or unresponsive during the multistream-select handshake completion. The lazy multistream protocol negotiation defers reading the handshake response until Close() is called. If the remote peer doesn't respond, the read blocks forever, causing goroutine leaks. This is particularly problematic for bitswap servers where taskWorkers can get stuck trying to close streams after sending blocks. The fix sets a read deadline (using DefaultNegotiationTimeout) before calling the multistream Close(), ensuring the operation will time out rather than block indefinitely. Related: multiformats/go-multistream#47 Related: multiformats/go-multistream#48
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Both initiator and responder now time out if reads and/or writes are blocked for 30 seconds (default negotiation timeout).
Introduces two tests to validate the new behaviour.
Fixes #47.
Addresses filecoin-project/lotus#518.