Discovery: Peer-to-Peer Operation
←Discovery - Registered Operation · Index↑ · Behaviour→
This document describes usage of NMOS APIs for discovery in cases where where a distributed registry is not available, such as small ad-hoc installations.
Note that the peer-to-peer discovery mechanism depends upon mDNS which is not intended to operate over IP routed boundaries (ie. between network subnets). As such it is recommended that for most use cases, in particular fixed installations and those requiring high levels of resilience, the registered discovery mechanism is used.
Pre-Requisites
The following pre-requisites are optional aspects of the Node API implementation which must be in place to permit peer-to-peer discovery.
- All Nodes advertise their presence via mDNS when configured in peer-to-peer mode
- In the absence of a network registry, all Nodes additionally advertise a series of mDNS TXT records indicating the validity of their API resources
Both of the above are properties of the Node API and require no additional implementation steps.
DNS-SD Advertisement
Node APIs MAY produce an mDNS advertisement of the type _nmos-node._tcp in order to support peer-to-peer operation. This SHOULD NOT be advertised when a Registration API is present on the network, or when peer-to-peer operation is disabled.
The IP address and port of the Node API MUST be identified via the DNS-SD advertisement, with the full HTTP path then being resolved via the standard NMOS API path documentation.
Multiple DNS-SD advertisements for the same API are permitted where the API is exposed via multiple ports and/or protocols.
Node mDNS announcements are discouraged from v1.3+ except for when using peer to peer mode as they generate unnecessary network traffic. Where a Node supports multiple versions including v1.2 or below it is still required to produce this mDNS advertisement in order to comply with earlier specification versions.
DNS-SD TXT records
api_proto
The DNS-SD advertisement MUST be accompanied by a TXT record of name ‘api_proto’ with a value of either ‘http’ or ‘https’ (lower-case) dependent on the protocol in use by the Node API web server.
api_ver
The DNS-SD advertisement MUST be accompanied by a TXT record of name ‘api_ver’. The value of this TXT record is a comma separated list of API versions supported by the server. For example: ‘v1.0,v1.1,v2.0’. There should be no whitespace between commas, and versions should be listed in ascending order.
api_auth
The DNS-SD advertisement MUST be accompanied by a TXT record of name ‘api_auth’ with a value of either ‘true’ or ‘false’ dependent on whether authorization is required in order to interact with the Node API or not.
ver_
When a Node is operating in peer-to-peer mode it MUST additionally advertise the following mDNS TXT records as part of its Node advertisement. If a Node is successfully registered with a Registration API it MUST withdraw advertisements of these TXT records. There is no requirement to register these TXT records with a unicast DNS service.
| TXT Record Name | Corresponding Node API Resource |
|---|---|
| ver_slf | self |
| ver_src | sources |
| ver_flw | flows |
| ver_dvc | devices |
| ver_snd | senders |
| ver_rcv | receivers |
The value of each of the above should be an unsigned 8-bit integer initialised to ‘0’. This integer MUST be incremented and mDNS TXT record updated whenever a change is made to the corresponding HTTP API resource on the Node. The integer must wrap back to a value of ‘0’ after reaching a maximum value of ‘255’ (MAX_UINT8_T).
For example, the ‘ver_src’ TXT record must be created when the Node first advertises itself via mDNS. If the data held within the HTTP resource for /sources is added to, removed from or edited, then the ‘ver_src’ text record must be modified (value incremented).
Client Interaction Procedure
The following scenario describes a peer-to-peer discovery in which a Node features an onboard control interface (for example a display with an input source menu).
- Node comes online
- Node scans for an active Query API on the network (type ‘_nmos-query._tcp’)
- Given no active Query API, Node scans mDNS for other Nodes (type ‘_nmos-node._tcp’)
- Using the returned list of Nodes, the requesting Node may request data from remote Node API resources as required in order to populate a control interface. This may be as simple as requesting the ‘/senders’ resource.
- The Node continues to monitor for changes to Node advertisements via mDNS. When Node API resources are changed, the TXT records associated with each Node will be updated to indicate which API resource(s) have been updated (see Node API specification)
- The Node SHOULD not re-poll remote Nodes on a timer in order to gather data about updated API resources
- The Node can perform connection management tasks automatically without user intervention provided they only affect that Node’s operation. This includes but is not limited to automatically routing video from a discovered Sender to a display’s Receiver
If a Query API becomes available on the network during peer-to-peer operation, the Node modifies its behaviour in one of the following two ways:
- The Node’s control interface switches to communicating with the network Query API rather than polling Nodes directly
- The Node’s control interface exposed to the user is disabled (if Query API interactions are not supported)
Recommendations for Dual-Mode Operation
To allow both peer-to-peer operation and operation using a distributed Query API, it is recommended that:
- When collecting data from other Nodes in peer-to-peer mode, Nodes should populate an interface which replicates the structure of a Query API, but restricted to access from localhost only, with no Query API mDNS advertisement.
- When a network Query API becomes available, the localhost-based Query API may proxy requests through to the network Query API in order to provide a transparent transition to the client interface.