"ipfs stats dht" doesn't work with Routing.Type=custom

[MichaelMure]

Checklist

• This is a bug report, not a question. Ask questions on discuss.ipfs.io.
• I have searched on the issue tracker for my bug.
• I am running the latest kubo version or have an issue updating.

Installation method

built from source

Version

ipfs version 0.17.0

Config

...

  "Routing": {
    "Methods": {
      "find-peers": {
        "RouterName": "ParallelHelper"
      },
      "find-providers": {
        "RouterName": "ParallelHelper"
      },
      "get-ipns": {
        "RouterName": "ParallelHelper"
      },
      "provide": {
        "RouterName": "WanDHT"
      },
      "put-ipns": {
        "RouterName": "ParallelHelper"
      }
    },
    "Routers": {
      "CidContact": {
        "Parameters": {
          "Endpoint": "https://cid.contact/reframe"
        },
        "Type": "reframe"
      },
      "ParallelHelper": {
        "Parameters": {
          "Routers": [
            {
              "IgnoreErrors": true,
              "RouterName": "CidContact",
              "Timeout": "3s"
            },
            {
              "ExecuteAfter": "2s",
              "IgnoreErrors": false,
              "RouterName": "WanDHT",
              "Timeout": "5m"
            }
          ]
        },
        "Type": "parallel"
      },
      "WanDHT": {
        "Parameters": {
          "AcceleratedDHTClient": true,
          "Mode": "dhtserver",
          "PublicIPNetwork": true
        },
        "Type": "dht"
      }
    },
    "Type": "custom"
  },

...

Description

When using custom routing, for example using the config detailed in the v0.16 release notes, the ipfs stats dht command return Error: routing service is not a DHT, even though there is a DHT in there.

I understand the relative complexity of searching for a DHT in a custom routing pipeline and the possible edge cases, but it would be nice if that command would work in the (very common) case where there is exactly one DHT. Not only DHT stats are obviously useful, but my understanding is that it's also the only way to figure out if the accelerated DHT is ready to publish.

[lidel]

This is a problem because Kubo 0.18 will use Routing.Type=auto by default (#9475) and ipfs stats dht is broken there as well.

Not a blocker for RC1, but we need to fix this before final release.

[ajnavarro]

I'm trying to find a solution to this problem.

Before, If we had activated DHT we were using dualDHT by default, so there are a lot of places where we are supposing that we have this DHT implementation, and querying WAN or LAN depending on the case.

With the new routing modular system, we can have from 0 to N DHTs, and we cannot know if it is WAN or LAN.

These are the commands on the need of having a DHT instance instead of a Router:

• https://github.com/ipfs/kubo/blob/master/core/commands/stat_dht.go#L51: here we are executing stats for all of the DHTs, or we can specify one from the command line.
• https://github.com/ipfs/kubo/blob/master/core/commands/dht.go#L121: Only querying peers from WAN if it is active. If not, only query LAN.

Proposed solution

• When composing the final Router from configuration, also return map[string]routing.Router with all the routers in use.
• On DHT stats, instead of using lan, wanserver or wan as parameters to filter DHT stats, use the specified router name from the configuration. If that routing system is a valid DHT (IpfsDHT, dualDHT, or FullRTDHT) then return the stats.
• On DHT query command, go through all routers and query the ones implementing GetClosestPeers method. Join all the results in one.

@lidel WDYT?

[lidel]

@ajnavarro sgtm.

If this makes things easier, for Kubo 0.18 we only need to fix stats for the default behavior, which is Routing.Type=auto (runs the same DHT setup as old dht, WAN+LAN). We can address custom routers later.

[ajnavarro]

@lidel Sounds good. I'll focus on fixing the problem with the default config first, and tackle the general problem after.

[ajnavarro]

@lidel this is needed to be able to get DHT routers from the parallel router: libp2p/go-libp2p-routing-helpers#68

[BigLep]

2023-01-12 update as I understand it: #9538 addresses the default case so we can unblock #9417 . We won't close the issue until we have fixes for non-default configuration.

[guseggert]

This is a larger problem than just ipfs stats dht, it also affects ipfs dht query and any other code that requires a Kademlia DHT specifically (and not just a content router). The same root cause is behind #9682.

We should refactor and simplify here, part of the reason this happened is because the wiring is very complex due to fx and interface abuse.