Migrate callbacks of new mdns responder to functional

[devyte]

Basic Infos

• This issue complies with the issue POLICY doc.
• I have read the documentation at readthedocs and the issue is not addressed there.
• I have tested that the issue is present in current master branch (aka latest git).
• I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• I have filled out all fields below.

Platform

• Hardware: [All
• Core Version: latest git today
• Development Env: All
• Operating System: All

Settings in IDE

• Module: All

Problem Description

The new MDNSResponder implementation written by @LaborEtArs allows for setting up some user callbacks. This is currently implemented in the classic C way with specific function signatures. It would be more flexible to allow std::function, lambdas, and general functors.

MCVE Sketch

See new MDNS examples.

[devyte]

@hreintke given your great past work in similar areas, could I ask for your help with this? There is no hurry.

[hreintke]

@devyte OK, I will look into this

[hreintke]

@devyte @LaborEtArs
Started working on this by first getting the mDNS_ServiceMonitor.ino example to work.

I think there is an error in the MDNSProbeResultCallback function.

The

      else {
        // Change hostname, use '-' as divider between base name and index
        if (MDNSResponder::indexDomain(pcHostDomain, "-", 0)) {
        	Serial.printf("insert - %s",pcHostDomain);
          p_pMDNSResponder->setHostname(pcHostDomain);
        } else {
          Serial.println("MDNSProbeResultCallback: FAILED to update hostname!");
        }

is now on :

if (!bHostDomainConfirmed) {

But it should be on

if (true == p_bProbeResult) {

[LaborEtArs]

Unfortunately you’re absolutely right. In fact, the mDNS_Clock example has got the same error...

[devyte]

So both the clock and servicemonitor examples have the same mistake?
Are we talking about this condition?

[hreintke]

Yes, That is the one.
If you want, I can make a PR for it.

The update for the functional option is very simple. Only the typedefs neeed change.
Need to make decent examples for using it. When finished that I will PR that also.
Will come on short notice.

[devyte]

@hreintke yes to the PR please!

[hreintke]

@devyte See #5563

[hreintke]

@devyte @LaborEtArs
I am not experienced in the mDNS area, so the issue below can be because of that but I have the following behavior.

I have trouble getting the LEAnMDS working steady, so I decided to compare legacy and lea using the mDNS_Web_Server.ino example.
Used the using MDNSResponder options from ESP8266nDNS.h to switch between both.
Confirmed by serial print that i am using them.

I test by submitting esp8266.local in chrome browser.
When using legacy, it works ok, also for longer periods.
When using LEA it works at the start, but after a short while I see the message "resolving host" and then getting the "This site cannot be reached" error.

Is there a chance that this is caused by the LEA implementation itself ?
Would it be possible that you do the same test ?