Implement new MDNS spec

[Stebalien]

That is, libp2p/specs#80. We'll need to:

1. Use https://github.com/miekg/dns to handle parsing/formatting DNS records.
2. See https://github.com/grandcat/zeroconf/blob/85eadb44205c14827ae7cbb129bc7eed4488dd25/connection.go#L38-L97 for how to listen for multicast packets. However, we'll need to use https://github.com/libp2p/go-reuseport/blob/b72b23b78b80078df1a7991f6ca39942cb8cc5e1/interface.go#L47-L49 to fix multiple MDNS applications.

Unfortunately, none of the existing golang mdns solutions work for us as:

1. They all have race conditions.
2. None of them use reuseport.
3. All of them are very DNS-SD focused and go through a lot of effort to make sure we get things like A and AAAA records.
4. We need to use the system's mDNS responder when possible, as running multiple mDNS responders on the same machine is pretty broken.

We could try to patch these however, we'll likely end up with something better if we just write something ourselves.

[kpp]

They all have race conditions.

I can fix data races. This is not a big deal. See whyrusleeping/mdns#5. Also I discovered hashicorp/mdns#66 , so we can merge these two and get a data race free implementation.

[Stebalien]

@kpp that would be awesome. We'd still want to switch to a new library for the other reasons but having a race-free go-ipfs would be nice.

[kpp]

I wrote to hashicorp/mdns, let's see if they still want to maintain the lib.
hashicorp/mdns#75

[ravenlandpush]

Please fix this, this 'bug' is encountered in situations even when there is a single IPFS daemon running on port 4001 with no other daemon sharing it.

Although restarting go-ipfs resolves the error, it stands to reason if port 4001 is seen as 'filtered' or if ipfs-go is capable of detecting that it cannot bind to the port, it should take some action like reforking itself so that it is bound, instead of just sit their polling the error for eternity doing nothing.'

I could write something to fix this by logging to a file with nohup or something but , much like ipfs pin jobs, this is not a 'solution' to the cause, it's a patch to the problem. What is the best proposition to fix this at present?

Surely there is better approach, or a way to fix this, its fairly critical is it not? If some ipfs servers are likely literally sitting offline unbeknownst of this issue or what it means. Is there not a failsafe way to ensure that port gets re-used in ipfs configuration?

Best wishes,
Adam

[Stebalien]

(copying my reply from the go-ipfs issue)

This issue will not prevent your daemon from listening on port 4001. It will only prevent mdns from working properly.

[ravenlandpush]

Well maybe I am mistaken, but, really this issue seems to coincide very coincidentally at the very least with the TCP port becoming unavailable. Gateway seems to continue working on port 8081. but port 4001 was unreachable , filtered, unable to be dialed to. It's not firewalld.

Maybe this is caused by some other bug that cause strange loss of port binding. Would hitting the file security limits for the user cause IPFS tcp ports to misbehave? In any case maybe this not right place to report it, but I thought the bug was related, perhaps, I am wrong. Presumably too many open file is causing the port to become unbound?

[Stebalien]

Please open a new issue.