Hostname for iOS

[geesen]

Is it possible to add a resolved hostname of the service into the watch callback?

So that I would be possible to build an URL like "http://"+service.host+":"+service.port (e.g. to get http://myserver.local:8080) instead of looking up the right IP from the addresses array.

If I'm right, there should already the right thing, which could be passed into the service object of the callback:
https://developer.apple.com/reference/foundation/netservice/1413300-hostname
However, I'm not (yet) familiar with swift/objective-c, so I could not implement it myself :(
Android has this already in the property "service.server", but iOS not.

Background story:
the server, which publishes the service, has IPv6 & IPv4 and sometimes the zeroconf plugin only receives the IPv6 address (sometime only IPv4 and sometime both). Since I use the IP for opening an InAppBrowser and the InAppBrowser cannot handle URLs with IPv6 addresses, I cannot connect to the server. Therefore, a hostname would be working - regardless of the type of IP and the underlaying network type (v6 or v4). Furthermore, Apple has also a new requirement that forces the usage of IPv6, so it would be better to use the hostname and let the local DNS resolving the IP address instead of using the IP directly.

[becvert]

Hi @geesen
I agree with you.
I'll normalize the service object between Android and iOS in the next version.
Next version should include #14 and #15. Just give me a couple of weeks.
Thanks

[NeoLSN]

@becvert I've done something about #14 and #15, also include this issue (but only Android side). Can you help me to check this?

[becvert]

FYI,
Android has an issue with resolving hostnames on the local domain
I confirmed that myself 😧

[NeoLSN]

Is RxDnssd have the same problem?

[becvert]

That issue with Android has nothing to do JmDNS or Apple's Dnssd.
It's just that you can't use the hostname afterwards on the local domain from a Android device.

[NeoLSN]

Oh, I see.
I didn't recognize that issue on my projects maybe because I don't use that feature a lot.
Thanks for letting me know that.

[becvert]

done

[becvert]

from @bugnano

that is that Android does not resolve the IP addresses on the .local domain, which means that you cannot use the service.hostname variable to connect to the remote device (although it would be sooooo convenient).

This bug (that hasn't been fixed for 6 years!!!) needs a work-around, that can be implemented in this plugin, but that work-around needs some thinking beforehand:

• We use zeroconf in order to make a service visible to the internal wi-fi network (As of now, the IP addresses that are published, are all the IP addresses bound to the device [e.g. both the wifi address and the cellular network address], or only the IP addresses bound to the wifi interface?)
• Once we know that only the wifi IP addresses are published, which one of the addresses should be used? (I presume that if only the wifi addresses are published, it's not important which one is used, but if all the addresses are published, how do I know which one is the wifi address?)
• Apple complicates (simplifies?) things, that is that it requires that apps must work on an ipv6-only network (as far as I know, there is no concept of subnet or local address in ipv6, so it's even more complicated to know which one of the ipv6 addresses to use).

I have no idea on how to implement such address resolver.

[becvert]

@bugnano
I doubt that there is an easy workaround for the 'bug'.
For now we're pretty much stuck with ipv4.
It's probably not a big issue for sometime again.

1 - This plugin registers services on all available interfaces (except loopback addresses).
I don't know what are the implications on cellular interfaces.
Do they support multicast? Are .local. dns domain requests routed over them?

2 - There is no easy way either to determine which interfaces/addresses are Wifi (Ethernet seems to work on ios devices too) and which are cellular.