-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Remove race between ID, Push & Delta #907
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Partial review. I'm going to allocate some time tomorrow to do a more thorough review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I was not expecting something this clean for a problem this gnarly.
❤️
p2p/protocol/identify/id.go
Outdated
@@ -63,6 +59,15 @@ func init() { | |||
// transientTTL is a short ttl for invalidated previously connected addrs | |||
const transientTTL = 10 * time.Second | |||
|
|||
type addPeerHandlerReq struct { | |||
s network.Stream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having to send this stream is unfortunate but I see why we're doing it.
What if, instead of preparing/recording the entire message inside the loop, we just recorded our protocols/addresses? Then, we'd change the populateMessage
signature to take the set of protocols/addresses that should be sent.
As is, we may end up sending the peer the wrong observed address (we'll send them the address observed on the initial connection).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Stebalien I do understand the intuition behind not wanting to send streams to channels but can you explain with a bit more detail why we wouldn't to pass streams across channels.
I am making the change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Streams on channels is fine. The issue is really:
- The identify loop doesn't actually care about the stream, we're handling the response outside of the loop. Really, we're just sending the stream so we can pull off the remote address so we can initialize an identify message that we're not even sending from the loop.
- The observed address will always be the addressed observed during the first identify request until we finally disconnect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Stebalien I see what you mean. Have made the change.
@Stebalien Have addresses your review comments with some counter questions. Please take a look when you can ! |
Hey @Stebalien Have made all the changes. This PR is ready for one last look. Please take a look when you can ! |
be84156
to
b964c9f
Compare
(rebased) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested changes in #922 but otherwise LGTM.
This PR was merged and released, but it points to a commit of go-libp2p-blankhost instead of a release: |
Looks like it wasn't released, so we have time to fix this on master. @aarshkshah1992? |
For #823 & #903 .
Blankhost PR at libp2p/go-libp2p-blankhost#42.