Network map and resource catalogue¶
In the admin UI, Meshwork brings together a map of the network nodes (as a list and as a graph) and a shared catalogue of the occupied network resources. All of it is updated automatically and gathers across the domain the information that would otherwise have to be collected from every server by hand.
Network map¶
The map shows the network’s composition — one row per known node, including the one you are viewing it from. Nodes check connectivity with each other roughly every 5 seconds, and the picture refreshes on its own. If Meshwork is not configured, the list is empty.
What a node’s row shows:
Node name and the address of its admin panel.
This node — the row of the node on which you are viewing the map; it is marked “this node” and is always shown as alive.
Link type — permanent (a node from the explicit list of neighbours) or auto-discovered (found automatically through a shared domain).
State — “Alive” or “Dead”. If there are no confirmations from a node for about 15 seconds, it is marked as dead. A neighbour’s restart is detected automatically, so a brief flicker of state right after it is normal. The went-silent alert for the node comes later, after a minute, and after a deliberate stop or restart of the node only if it has not come back within 5 minutes (Alert code catalogue). A dead node stays on the map for a week from the last contact, and its went-silent alert holds for that whole time: a node that has fallen over must be distinguishable from a node that never existed. It is removed sooner by the “Forget node” action (Nodes); a permanent neighbour is then struck from the configured list as well (Neighbours and secrets).
Last contact — when the last successful connection occurred.
Uptime — the time since the node was started. The node reports the moment of the start itself, not a counter, so the value grows continuously and is reset only by a restart. The moment of the start goes by the clock of the node itself, while the age is counted by the clock of the workstation: when an impossible value comes out of them, the uptime is not displayed (Nodes).
Domain — the node’s domain or domains. A super-node has several, and the node is additionally marked as
super.NAT — an indication that address translation was detected on the path to the node.
Some of the information the map gathers indirectly. It is not set out in the row, but it explains what is visible on the map:
Relay. The information about a node’s availability and NAT may arrive not from the node itself but through a neighbour. This is how, for example, nodes behind NAT that this node cannot reach directly get onto the map: they are shown on a par with the rest, although there is no direct link with them. As soon as a direct link is established, it takes priority over the relayed information. Likewise, a super-node shows the nodes of its additional domains, except the neighbours from its list: it keeps no direct link with them.
Failed authentication. An auto-discovered neighbour may be reachable directly and yet fail the authenticity check. Usually this means that the nodes communicate over public addresses while there is no node in the domain with HTTPS enabled through which the nodes verify each other’s authenticity (see Requirements and reachability). What is not working is the direct link; the node itself may remain alive via relay. On a local network (nodes on private IP addresses) this does not happen.
Shared resource catalogue¶
A separate admin panel screen shows a distributed catalogue of occupied network resources — the UDP, RTP, Pro-MPEG COP3/RTP+FEC (SMPTE 2022-1/2), RIST, PS1 and SRT inputs and outputs running on the nodes of the domain. This is a domain-wide list of occupied addresses and ports; it is used to pick a free resource and see where each stream is already in use.
What goes into the catalogue:
a UDP, RTP, Pro-MPEG or RIST output — always, with both multicast and unicast. The exception is a unicast UDP, RTP or Pro-MPEG output to the loopback address or to the node’s own address. Such an entry is visible only in the node’s own catalogue and is not passed on to other nodes;
a UDP, RTP, Pro-MPEG or RIST input — only when its address is a multicast group; a unicast input of these transports is not announced;
PS1 and SRT inputs and outputs — always (PS1 / SRT link type).
An endpoint excluded from publication by the Peer private field is not announced in any of these cases.
For each entry the catalogue shows the protocol and direction (input/output), the source node, the domain, the address/group/port, the VLAN, if needed the source for source-specific multicast, and a note.
The same catalogue can be used to find who else works with the address of a particular input or output: next to the address there is a “Show in library” button (Library — this feed).
Publication is controlled by two additional fields on the input/output itself. They are shown for the catalogue transports (UDP / RTP / Pro-MPEG / RIST / PS1 / SRT), and the names are given as in the interface: Peer note (meshwork library) — a public note for the catalogue (if it is empty, the entry’s ordinary note is used), and Peer private — exclusion of the entry from publication.
PS1 / SRT link type¶
Besides UDP / RTP / Pro-MPEG / RIST, the catalogue also includes PS1 and SRT connections. Such a connection has two sides: the calling one (dials out to a remote address) and the listening one (accepts the connection). For the calling side the catalogue shows the link type:
internal — the input/output is configured to connect as a domain member (domain autologin is enabled): it connects to another node of the network and confirms its membership in the domain;
external — there is no domain-member confirmation: this is an ordinary connection to an arbitrary endpoint. Even if a node of the network is located at the specified address, without domain autologin the link is considered external — the type reflects how the connection is configured, not whether the receiving side belongs to the network.
This is a hint mark: it does not affect the transmission itself but helps distinguish confirmed intra-domain links from external ones. For the listening sides and for the UDP / RTP family the type is not shown.