Improved Performance in go-libp2p-kad-dht: New Feature Reduces PUT/Provide Latencies to <1s

[dennis-tra]

Hi 4everland Devs,

This is Dennis from Protocol Labs. I wanted to inform you about an exciting update regarding the go-libp2p-kad-dht implementation, which I believe you are currently using. As part of our continuous efforts to enhance performance, we have introduced a new experimental feature that significantly improves the PUT/Provide latencies.

Previously, the DHT's PUT performance was known to be rather sluggish, often taking more than 10 seconds or even minutes. However, with the latest release of go-libp2p-kad-dht >v0.23.0, we have introduced a feature called "Optimistic Provide." This feature has demonstrated great results, bringing the latencies down to less than 1 second in the 50th percentile and less than 1.4 seconds in the 90th percentile.

While I'm unaware of the specific requirements of your use case or whether the previous latencies posed any challenges for you, I wanted to ensure that you are aware of this improvement.

If you have any questions or would like more information about this new feature, please don't hesitate to reach out.

Cheers,
Dennis

[tichen-ben]

very good

[cachalots]

Hi @dennis-tra, We have noticed that dht has affected our performance, We have been trying to use the index provider recently
https://github.com/ipni/index-provider
https://github.com/ipni/storetheindex
but after testing, it does not integrate well with Kubo itself, We will try to introduce "Optimal Provide".

[dennis-tra]

Hi @cachalots, great that you want to try this new Optimistic Provide approach! Let me know how that goes and what your experiences are.

If you have the time, I'd love to know more information about how the DHT has affected your performance and why the indexers don't integrate well with Kubo

[cachalots]

Hi @dennis-tra,
I tested it at the beginning of this month, and at that time, cid. contact did not support index provider's /routing/v1/providers/{cid} routing access, only supported storetheindex's /cid/{cid} routing access, which caused Kubo's HTTP FindProviders to always fail. I just tried to access it and it has already been supported.
https://github.com/ipfs/kubo/blob/92f651fda94970043a3e1272de491756c0f42a5e/core/node/libp2p/routingopt.go#L34
I flipped through the Kubo code and found that endpoints cannot be passed through configuration in the default code, so I modified the defaultHTTPRouters to point to the endpoints in our index provider, After testing, I found that the index provider did not implement the FindProviders API.
https://github.com/ipni/index-provider/blob/72cfffcf8c6fbe59ed073352f109b24f067cd950/delegatedrouting/listener.go#L266

1. The cid.contact does not provide the FindProviders API (it is now available).
2. Kubo cannot configure HTTP provider endpoints.
3. The index provider does not implement the FindProviders API.
4. After the index provider is published, it seems that cid.contact will not be included either.

[masih]

@cachalots

cid.contact has supported /routing/v1/providers from the early inception of IPFS HTTP delegated routing. It works through a load balancing service. You should be able to test this yourself , e.g.:

$ curl -s https://cid.contact/routing/v1/providers/bafkreid2afmtbcfjioljdxwxd5zccg3d5dpr76zaksqfhuyff5oebw4osi | jq
{
  "Providers": [
    {
      "Protocol": "transport-bitswap",
      "Schema": "bitswap",
      "ID": "QmQzqxhK82kAmKvARFZSkUVS6fo9sySaiogAnx5EnZ6ZmC",
      "Addrs": [
        "/dns4/elastic.dag.house/tcp/443/wss"
      ],
      "Metadata": "gBI="
    },
    {
      "Protocol": "unknown",
      "Schema": "unknown",
      "ID": "QmUA9D3H7HeCYsirB3KmPSvZh3dNXMZas6Lwgr4fv1HTTp",
      "Addrs": [
        "/dns4/dag.w3s.link/tcp/443/https"
      ]
    }
  ]
}

The above covers lookup through cid.contact. As for providing records to it, have you tried this?

[cachalots]

@masih Of course, I modified the code of Kubo and passed my httpRouter to ProvideRouter for testing. From the index provider log, it can be seen that the index provider received my provide request and published it a few minutes later.

From my understanding of index provider, it is to publish records to other nodes through a scheduled task to the /indexer/ingest/mainnet topic of libp2p pubub. But every once in a while after publishing, I go to cid.contact to request that the cid I have published is still 404 not found, and cid.contact doesn't seem to listen to the topic to include my published cid

[masih]

• For Gossipsub announcements to work, there needs to be a connection between your node and cid.contact libp2p instance.
• Alternatively you can use HTTP publisher directly to cid.contact, which should pick up notifications typically in order of seconds.

Folks are happy to help debug this. Ping us at #ipni on FileCoin Slack.

[cachalots]

• For Gossipsub announcements to work, there needs to be a connection between your node and cid.contact libp2p instance.
• Alternatively you can use HTTP publisher directly to cid.contact, which should pick up notifications typically in order of seconds.

Folks are happy to help debug this. Ping us at #ipni on FileCoin Slack.

Thanks, when we refocus on this part, I will go to Slack for help.

[cachalots]

@masih Hello, I don't have a email related to Filecoin Slack. Can you send me an invitation?

[masih]

Have you tried https://filecoin.io/slack ?