search

LimeChain / Fruzhin

Java implementation of the Polkadot Host
Apache License 2.0
29 stars 0 forks source link

Improve peer finding #354

Open vikinatora opened 3 months ago

vikinatora commented 3 months ago
vikinatora commented 3 months ago

Please check out #79 as well.

David-Petrov commented 2 months ago

Please check out #79 as well.

Issue has been diagnosed, but not fixed as it's not that high priority. Read the comment here.

Ensure we can keep a two digit number of peers connected and synching at all times.

That's a rather bigger task as understanding the entire abstract idea of peer finding with the Kademlia protocol and then distinguishing implementational boundaries (i.e. what Nabu provides in terms of "Kademlia" implementation and what's left up to us as users to decide and implement?; where does the abstraction of "Kademlia" as a lower level protocol end and where do Polkadot business decisions on top of that begin?) takes time to get into. I've not reached any major revelations as to how our peer finding can be "improved" yet as I've struggled to even isolate a minimal definition of "finding a peer" and "connection to a peer", albeit attempting to define a test case or at least an isolated environment (understand: what are even the minimum requirements to "be connected to a peer" so that a peer is happy and doesn't drop the connection... in terms of the polkadot network's needs?).

On a side note, whilst digging into our fork of Nabu I stumbled upon this seemingly unused boolean flag. The intention behind it was initially (a long time ago) to satisfy the intent: we want our node to be a client (not a server) peer (terms in the context of the Kademlia protocol). However, I suspect jvm-libp2p already handles that based on whether you're an initiator or receiver at the end of a P2PChannel (reason: This doc comment + use case within Nabu)... Either this or there is missing logic on our side (either in Nabu or in Fruzhin) to implement this role diversification. For comparison, this is how the equivalent in GO handles this. I'm not sure, but this is a sidetrack nonetheless.

Work can be picked up on this branch.

Useful reference materials:

  1. The abstract libp2p spec: https://github.com/libp2p/specs/blob/master/kad-dht/README.md#libp2p-kademlia-dht-specification
  2. The JVM implementation we're using (transitively through Nabu): https://github.com/libp2p/jvm-libp2p/tree/9fd77410345f72bb1c327ef8d09a9f3ed41d15be
  3. The exact current source of Nabu used in Fruzhin can be found implementation("com.github.LimeChain:nabu:16c6586");
  4. The Kademlia whitepaper (extremely useful for grasping the abstract overall concepts behind the protocol). Keep in mind that each implementation has its variations; on top of that, the Polkadot spec introduces some slight variations on top of Kademlia, so this whitepaper is not a 1:1 description of our exact use case within Fruzhin.