-
Notifications
You must be signed in to change notification settings - Fork 225
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
chore: fix connectedness #976
Conversation
Thanks @2color! Is there a way to test if We may want to reverse the fix on |
Not sure I understood the question @guillaumemichel But I presume that in some instances, we want to make this distinction in the context of Kubo. |
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.
If a host.Connect
is fine with a Limited connection then we should use the dial option network.WithAllowLimitedConn
. This works currently because of a go-libp2p bug. We should fix it right now so that it doesn't break silently in the future.
ctx = network.WithAllowLimitedConn(ctx, "dht-find-peer")
h.Connect(ctx, ...)
@@ -737,7 +737,7 @@ func (dht *IpfsDHT) FindLocal(ctx context.Context, id peer.ID) peer.AddrInfo { | |||
_, span := internal.StartSpan(ctx, "IpfsDHT.FindLocal", trace.WithAttributes(attribute.Stringer("PeerID", id))) | |||
defer span.End() | |||
|
|||
if dht.host.Network().Connectedness(id) == network.Connected { | |||
if HasValidConnectedness(dht.host, id) { |
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.
NIT:
dht.host.Network().Connectedness(p) != network.NotConnected
is simpler and reads better, I think.
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.
I was apprehensive about the double negation making it less readable and wanted to ensure it's future proof.
We can handle this in a different PR. Preferably before a release. |
Sorry, I meant: Is there a way to verify that Kubo is fine with In other words does Kubo need if connectedness == network.Connected || connectedness == network.Limited
(or connectedness != network.NotConnected) or if connectedness == network.Connected |
I'll let @lidel or @aschmahmann chime in regarding this, as I'm not familiar enough with the Kubo/Boxo codebase. |
Hope I'm answering the question here, if not ping and I'll try again 😅. In practice the libp2p protocols that kubo relies on (with the exception of the ping protocol I suppose) do not want to work over limited connections (e.g. bitswap, kad, p2p-forwarding, trustless-gateway over libp2p, etc.). However, those protocols should force the transport to upgrade when we call The main area (aside from ping) where I could see limited connections useful at the application layer (as opposed to internally to the libp2p transport layer for DCUtR, etc.) is related to Kademlia's
|
I have a couple of questions
|
It absolutely must or it breaks peer routing for NATed peers. NOTE:
|
Can you explain what you mean? In what situations are the two not synonymous? |
eca466c
to
7004c77
Compare
P2p circuit addresses can be used for non-transient connectivity as well. We don't run any non-transient relays, but users can always run/use their own. Truly transient connections will have |
This is what was bothering me. If these peers are not in the routing table, how do we actually find them? |
4667e81
to
5669815
Compare
Yep! It's all a giant hack. Hacks all the way down. |
(ideally we'd use actual peer records and keep them separate from the record table) |
@MarcoPolo @Stebalien fysa this did not end up in v0.26.0, see #980 |
Oh this PR didn’t target master. Thanks |
This PR builds on #974 and fixes a bug whereby
FindPeer
won't return results for peers behind NAT which only havep2p-circuit
multiaddrs.This fixes the regression starting from v0.34 of go-libp2p: