marten-seemann
commented
1 year ago It sounds like there are 2 issues here:
- Peers having no protocols.
NewStreamfailing.
Regarding (1), I suspect that this is due to the cleanup logic, although I can't see any bug. When a peer disconnects (i.e. when all of the (potentially multiple) connection we had with a peer are gone), we clean up the protocol list from the peer store after a short period. You can find the logic here: https://github.com/libp2p/go-libp2p/blob/fc1c9f5d4e7aef936847ffa8915a8eaffb34eba2/p2p/host/pstoremanager/pstoremanager.go#L81.
The bug here is pretty obvious, we call RemovePeer even if the peer has connected back to us in the mean time. This will leave the peer list of addresses permanently empty, at least until the next Identify event happens (which doesn't happen frequently in practice, depending on your application).
Regarding (2), you're probably running into this error: https://github.com/libp2p/go-libp2p/blob/fc1c9f5d4e7aef936847ffa8915a8eaffb34eba2/p2p/host/basic/basic_host.go#L696 I'm not sure why that happens, the peer should have completed the multistream protocol negotiation.
juligasa
aschmahmann
burdiyan
sukunrt
In our network, we identify peers talking
hypermediaprotocol by checking if that protocol is present in the list of protocols when connecting to a peer. We get the list of protocols by doing<caller>.Peerstore().GetProtocols(<called_pid>)(we could be usingFirstSupportedProtocolbut for the sake of this issue, getting all supported protocols is best) after connecting with a peer on the network. The usual response is like:[/ipfs/lan/kad/1.0.0 /hypermedia/0.2.0 /ipfs/bitswap /ipfs/bitswap/1.0.0 /ipfs/bitswap/1.1.0 /ipfs/bitswap/1.2.0 /ipfs/id/push/1.0.0 /ipfs/id/1.0.0 /ipfs/ping/1.0.0 /libp2p/circuit/relay/0.2.0/stop]However, some peers report no protocols at all[](as if we were issuingRemoveProtocols) and the only way to make them work properly again is either restarting the called node or restarting the caller node. Note that while they are in this protocolless state, any subsequent calls toNewStream()will fail (with the errorfailed to negotiate protocol: context deadline exceeded), which is the real blocker in our case. After restarting the caller, a new random set of peers will face the same issue. In unitary tests, this seems to work. Any idea on what's going on?Version Information