-
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
fix: return the best _acceptable_ conn in NewStream #1604
Conversation
Otherwise, we can return, e.g., a transient connection that can't actually be used.
Not sure I understand the swarm code correctly. Let's assume we only have a transient conn to a peer. We will therefore call go-libp2p/p2p/net/swarm/swarm.go Lines 354 to 369 in 8840285
go-libp2p/p2p/net/swarm/swarm_dial.go Lines 251 to 264 in 8840285
Does that mean we'll end up with two transient connections now? |
Ah.... ok, this is all broken. |
If we have a transient connection, don't want to use a transient connection, and haven't specified "force direct dial", fail the dial.
Ok, it's "fixed". Horribly broken, but at least it's correct. |
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.
It's a bit confusing that we have two different concepts of "transient" connections in go-libp2p. Transient as in a limited connection over a relay and transient as in a connection that hasn't been upgraded yet and doesn't have a peerid associated with it yet.
|
||
forceDirect, _ := network.GetForceDirectDial(ctx) | ||
if forceDirect && !isDirectConn(conn) { | ||
return nil, nil |
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.
What happens here? We may have a transient connection but we'll try to dial again?
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.
Yes. We need to do that for hole-punching.
Otherwise, we can return, e.g., a transient connection that can't actually be used.
I noticed bitswap was trying to use transient connections, which shouldn't be possible. To really fix this issue, we'd also need to fix #1603 as well, but that's harder.