Date
1 - 3 of 3
mDNS in the new CP firmware
|
Dale Ghent
Ah! I never noticed the magnifying glass. It never really registered as a place that would show the hostnames it found. Modally, I guess I expected them to be listed in a combox UI widget for the Hostname/IP field.
toggle quoted message
Show quoted text
The service discovery portion should be easy to implement. You should define a unique name for your protocol and publish SRV records for it, for both UDP and TCP, as well as a record for the HTTP service. This would let you change ports and whatnot independently of any client having to keep track of that specific knowledge. Either way, this is far far better than trying to locate CPs by ping sweeping the subnet, and mDNS can be reflected across subnets as well, so the discovery can extend beyond them if the site does that. On Jul 25, 2022, at 16:47, Mike Hanson <mikeh@...> wrote: |
|
|
|
Mike Hanson
Hi Dale,
Thanks for noticing. FWIW, APCC can "find" CP4s and CP5's. See below. If UDP or TCP is checked, you can click the magnifying glass, which will perform auto-discovery. A List of reachable AP hosts will be displayed, click on the one you want, and click "Select". There's a checkbox to tell it to use the IP address. Leaving this unchecked will make it use the hostname. There are updates to the CP4 and CP5 manuals that will described this in more detail. Admittedly, auto-discovery is not the same as service discovery. For example, APCC needs to know the port numbers. However, it accomplishes a similar purpose for the usage domain you describe. Cheers, Mike  |
|
|
|
Dale Ghent
I just noticed in the P02-13 release notes[1] that the mDNS responder feature of the embedded OS is now put into use. This is great. Kudos to Mike Hanson, I would guess?
mDNS refers to multicast DNS and is a way for systems to announce a hostname (and optional services) to the local network. An app running on another system on the network can issue an mDNS request. If something on the network matches the hostname that is being requested, its IP address. This precludes the need to run your own DNS server or mess with maintaining a hostname database. It makes finding a host by name more automagic, so you don't have to hunt for a device's IP address manually. This can be used with APCC to connect to a CP4/5, via wifi or ethernet, without having to keep track of the IP address that's assigned to the CP in question. If you're using DHCP on your local network, this will track the change, so you don't need to hunt down and update the IP address if DHCP were to give it a different one, say after a router reboot or somesuch. I've attached a graphic on how to configure this. mDNS is part of a modern networking concept called Zeroconf, which is a combination of mDNS and something related called DNS-SD, the "SD" meaning "service discovery." What would be *really* cool is if the CP4/5 OS could also register a DNS-SD service for its TCP and UDP server. APCC in turn can do a single mDNS query to find those advertisements and present a list of those respond. A single CP on the network would yield one response and APCC could just automatically connect to it. But if you have multiple A-P mounts with multiple CPs on your network, it can present a list of the hostnames that responded and the user can choose which one they want. This is the same type of setup that lets devices find services on your local network at home. Got Sonos speakers? The Sonos app on your phone finds them the same way - by doing a service discovery query. It's one of the ways your computer can find a networked printer (or one shared by another computer) and so on. It's pretty ubiquitous in IoT things today. |
|
|
