Review from Thomas Eizinger

[Wiezzel]

No description provided.

[thomaseizinger]

Thanks! I'll try to answer questions regarding my comments, just tag me!

[Wiezzel]

@thomaseizinger
I've added a bunch of follow-up questions/comments.

I also have one extra question that I'm struggling with: I have observed that quite often the DHT lookups for peers fail, but when I try to look up the same peerID by running libp2p-lookup, it succeeds. What could be the reason??

[thomaseizinger]

I also have one extra question that I'm struggling with: I have observed that quite often the DHT lookups for peers fail, but when I try to look up the same peerID by running libp2p-lookup, it succeeds. What could be the reason??

Is this in your own DHT or in the IPFS one? Like I commented, I would strongly recommend moving off the IPFS DHT. There are proposals for making it universally useful but until then, it would be better to create your own DHT.

[Wiezzel]

@thomaseizinger

Is this in your own DHT or in the IPFS one? Like I commented, I would strongly recommend moving off the IPFS DHT. There are proposals for making it universally useful but until then, it would be better to create your own DHT.

Our network is isolated, so I believe it works as our own DHT, despite using the same protocol ID string.

[thomaseizinger]

@thomaseizinger

Is this in your own DHT or in the IPFS one? Like I commented, I would strongly recommend moving off the IPFS DHT. There are proposals for making it universally useful but until then, it would be better to create your own DHT.

Our network is isolated, so I believe it works as our own DHT, despite using the same protocol ID string.

Any logs on the nodes where the lookup fails?

[Wiezzel]

@thomaseizinger

Is this in your own DHT or in the IPFS one? Like I commented, I would strongly recommend moving off the IPFS DHT. There are proposals for making it universally useful but until then, it would be better to create your own DHT.

Our network is isolated, so I believe it works as our own DHT, despite using the same protocol ID string.

Any logs on the nodes where the lookup fails?

Well, I just get the Peer 12D3Koo... not found from this line. But I can run it with debug-level logs from libp2p_kad to see more. I was also thinking it might be related to libp2p/rust-libp2p#5270. 🤔

[Wiezzel]

@thomaseizinger One more architecture question:
Let's say I want to implement a behaviour that works like request-response, but it waits until the node address is known before making the dial attempt. I would include kademlia inside and start a lookup if there are no known address of a peer. But what if I'd like to have multiple instances of this behaviour (for different message protocols)? How to do this without having multiple kademlia instances? Could this behaviour communicate with kademlia using swarm events somehow? Or should I use a shared reference or a channel to pass calls to kademlia? What would be the cleanest solution in your opinion?

EDIT: Or maybe I shouldn't even use multiple request-response behaviours, but a single one with multiple protocols supported? Though the downside of this approach seems to be that all protocols would need to share the same response and return and response type, so I cannot have a separate enum per each protocol.

[thomaseizinger]

@thomaseizinger One more architecture question: Let's say I want to implement a behaviour that works like request-response, but it waits until the node address is known before making the dial attempt. I would include kademlia inside and start a lookup if there are no known address of a peer. But what if I'd like to have multiple instances of this behaviour (for different message protocols)? How to do this without having multiple kademlia instances? Could this behaviour communicate with kademlia using swarm events somehow? Or should I use a shared reference or a channel to pass calls to kademlia? What would be the cleanest solution in your opinion?

EDIT: Or maybe I shouldn't even use multiple request-response behaviours, but a single one with multiple protocols supported? Though the downside of this approach seems to be that all protocols would need to share the same response and return and response type, so I cannot have a separate enum per each protocol.

I wouldn't move kademlia inside. Instead I would:

• Make a wrapping behaviour that:
  • first tries to send the message (which will attempt a dial and use all addresses that we know)
  • if it fails, queue the message and emit an event that we need to search for a peer
  • sends the message once the connection is established
  • has a timeout if a msg is queued for too long
• use that event in the eventloop to trigger a kademlia lookup
• Dial every node you find with kademlia

The result will be that a regardless of how the connection will be established, queued messages are always sent and your behaviour is independent of the discovery mechanism.

Does that work for you?

[Wiezzel]

@thomaseizinger

Does that work for you?

Yeah, thank you.