Firstly, thanks for all the clarifications
This is wrong terminology. Peers are not connected “via WAN/LAN DHT”.
Yes, I agree. My mistake - I used the terminology very loosely.
Nodes open connections and DHT is a service that runs on top of those connections.
Nodes need to know which multiaddr to open connections to, right ?
Here’s my understanding - pls correct me if I’m wrong.
- Nodes open connections and DHT runs on top of those connections.
- Among other things, DHT provides the information of what nodes are in the network (Peer Records), so that we can connect to them.
This chicken-and-egg problem is solved by having bootstrap nodes (and also by Local Discovery via MDNS)
Whether those connections between peers are via LAN or WAN is something that ipfs swarm peers should tell (by looking at the IP).
Got it. Only in my case, the docker containers were running in a private network and had private ip addresses (172.17.0.2, 172.17.0.3, 172.17.0.4), so I could not tell anything by looking at the IP address. But I realize that that’s purely because of my test setup.
MDNS may have facilitated auto-discovery or LAN peers, but disabling it does not mean that those peers will never end up connected on the LAN interfaces, as they usually advertise and exchange those addresses too.
I’m slightly confused by the term “advertise”. Are you referring to this part - https://docs.ipfs.io/concepts/dht/#qualification
So even if I have MDNS disabled, when I connect to a peer (say the bootstrap node itself), will I also receive it’s LAN interface address?
But if the peer is a public machine (and is actually not part of my LAN), then this would be useless information right?
Is this why public ipfs nodes are recommended to run on server profile, so that they dont advertise their LAN interface address?
I would like to know why you want to disable LAN DHT though, as I cannot think of a good reason to do so.
One reason was curiosity
Another reason was because I was running a private IPFS (for testing some stuff), and was slightly shocked to see Container C connecting to Container A. I realized later yesterday that that won’t happen if Container C had a different swarm key, and that there is no need to disable MDNS for this. Tested this as well, and it worked like a charm.