Discovery
←APIs - Query Parameters · Index↑ · Discovery - Registered Operation→
NMOS Discovery makes use of the DNS Service Discovery protocol as described in RFC 6763. DNS-SD specifies a mechanism for the use of Unicast or Multicast DNS for the purpose of identifying one or more endpoints on a network associated with a named service.
Three DNS-SD service types are defined by this specification:
- _nmos-node._tcp: A logical host which advertises a Node API.
- _nmos-register._tcp A logical host which advertises a Registration API.
- _nmos-query._tcp A logical host which advertises a Query API.
The following is an additional DNS-SD service type required to support older versions of the Registration API (v1.2 and below):
- _nmos-registration._tcp A logical host which advertises a Registration API.
Advertisements of the above types are accompanied by DNS TXT records as specified within the following specification pages.
Unicast vs. Multicast DNS-SD
Dependent on the architecture of a network, it may make sense to use one or both of unicast or multicast DNS for discovery. ‘Registered’ mode may support both of these cases, however ‘Peer to Peer’ mode only supports multicast operation. Nodes may optionally be configured to support just one of unicast or multicast service discovery, however it is recommended that both are used by default in order to make initial device configuration as configuration free as possible.
When performing a DNS-SD browse, clients should proceed as follows:
- Identify whether the client has been configured with DNS server addresses and a default search domain either manually or automatically via DHCP.
- If such configuration exists and the discovery mechanism is not explicitly set to mDNS, perform a unicast DNS browse for services of the required type via the search domain.
- If no unicast responses are received and the discovery mechanism is not explicitly set to unicast DNS, perform a multicast DNS browse for services of the required type in the ‘.local’ domain.
- Note that if a unicast response is received, multicast browsing should not be performed even if the unicast-discovered API is unresponsive.
- Where both unicast and multicast DNS are used, merge the results of the above operations into a single list.
- Sort the list of discovered services using the priority values associated with each record, and discard any advertisements which do not meet the Node’s requirements.
- The above list should be maintained via the methods defined by the DNS-SD specification.
Implementation Notes
It is expected that timeouts specified by DNS-SD and DNS specifications will be abided by when maintaining a cache, however clients may wish to temporarily mark particular advertisements as invalid where they have timed out or produced HTTP 5xx errors during API interactions. In the case of multicast DNS the re-query mechanism should be used, and is particularly important for servers which cannot unregister their mDNS announcements before going offline.
Due to the caching mechanisms present within mDNS implementations, if a service disappears from the network without cleanly removing its mDNS announcement, it will still be present in the caches of browsing systems until the defined expiry time (120 seconds to 75 minutes dependent on record type). When mDNS advertised data is found to be invalid (for example by performing an HTTP request to an advertised service API and seeing a timeout), the procedure defined in RFC 6762 section 10.2 should be followed. Additionally, RFC 6762 section 10.5 may be used to pre-empt these failures.
←APIs - Query Parameters · Index↑ · Discovery - Registered Operation→