--- title: Network map and resource catalog url: https://doc2.pstreamer.tv/en/manual/meshwork/map.html lang: en product: Perfect Streamer version: 2.0.2.362 --- # Network map and resource catalog 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 peers) 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 peer’s restart is detected automatically, so a brief flicker of state right after it restarts is normal. 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](../webui/meshwork.md#webui-fleet-nodes)); a permanent peer is then struck from the configured list as well ([Peers and secrets](setup.md#meshwork-peers)). - **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](../webui/meshwork.md#webui-fleet-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. Part of the information the map gathers indirectly, and it is not set out in the row, but it is worth knowing about — 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. - **Failed authentication.** An auto-discovered peer 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](setup.md#meshwork-requirements)). 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 catalog A separate admin panel screen shows a distributed catalog of occupied network resources — all UDP / RTP / Pro-MPEG / RIST inputs and outputs running on the domain’s nodes. This is a domain-wide list of occupied addresses and ports; it is convenient for picking a free resource and seeing where each stream is already in use. For each entry the catalog 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 also answers the reverse question — 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](../webui/streams.md#webui-stream-library-feed)). Publication is controlled by two additional fields on the input/output itself (they are shown only for the transports that appear in the catalog — UDP / RTP / Pro-MPEG / RIST / PS1 / SRT; the names are as in the interface): Peer note (meshwork library) — a public note for the catalog (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 catalog also includes [PS1](../planning/index.md#planning-ps1) and [SRT](../planning/index.md#planning-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 catalog shows the link type: - **internal** — the input/output is configured to connect as a domain member (domain auto-login 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 auto-login 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.