Open jbenet opened 1 year ago
I've renamed the issue to describe what's going on, but high level:
ipfs swarm connect
only guarantees that it will give you a connection to a given peer not what that connection will look like. This comes from the go-libp2p abstractions.Trying to debug a speed issue in a transfer between two nodes, locally connected in wifi
You could take one of the nodes (e.g. the dialing node), disable QUIC on the node https://github.com/ipfs/kubo/blob/master/docs/config.md#swarmtransportsnetwork and then reboot it. If the nodes do not find each other over mDNS you could then do ipfs swarm connect
to establish a connection.
Note: there are a variety of tools that use similar components as kubo under the hood that can help you exercise your kubo node. https://github.com/ipfs-shipyard/vole is one of these that I tend to use for poking at individual nodes for testing purposes which while not as end-to-end as using kubo as described above is easier and doesn't require the debugging tools to all get bundled into kubo.
ipfs swarm connect
is a low level command for forming a connection to a peer.host.Connect
functionality https://github.com/libp2p/go-libp2p/blob/fa153c58dd24ffc6f97e4dfe1f40a7ce05e4a6af/core/host/host.go#L40-L45Connect
(which is the only exposed go-libp2p connection function which takes a multiaddr instead of a peerID) is Connect ensures there is a connection between this host and the peer with given peer.ID
it does not guarantee that a new connection will be formed to the given peer or what addresses it will use.ipfs swarm connect
for some period of time where that information is deemed "fresh enough"Given this the more appropriate CLI UX here would probably have been ipfs swarm connect <peerID> --multiaddr-hints=<addr1>,<addr2>,...
. However, it doesn't seem worth a breaking change for that. It does seem worth clarifying the text on ipfs swarm connect
though.
Unless there becomes a way within go-libp2p to dial a specific multiaddr there's nothing to be done here. However, it's not obvious what the correct user contract for this would be in go-libp2p or in kubo. I will open an issue there linking here shortly and if you have any UX recommendations for some of the issue below it would be great to hear them.
If the idea was for ipfs swarm connect <multiaddr>
to only work with the given multiaddr to enable testing as you've done you could also end up in any number of ways in which this could backfire due to misunderstanding the abstractions involved.
Some examples:
ipfs swarm connect <tcp-multiaddr>
to connect to Bob, but already has a QUIC connection to Bob, what's supposed to happen? Does this kill the QUIC connection, what if it's in use? It could add the connection to the QUIC one but then the libp2p implementation gets to choose which connection to send streams on, so we're back to the above problem.
ipfs swarm disconnect
followed by connect
exposes a race condition.
Checklist
Installation method
ipfs-update or dist.ipfs.tech
Version
Config
Description
Trying to debug a speed issue in a transfer between two nodes, locally connected in wifi (one
0.20.0
, one0.19.0
). I tried disconnecting fromquic
to isolate, and reconnect w/ tcp. But no, kubo disregards the user commands and insists on using quic. Disregarding clear user commands and intent is not a feature -- it is a bug.