Network Ports and Activity
Networking is a very important part of any Disguise system. Servers need to be in constant communication with each other and also with third-party software and hardware products. A well-configured network can save time and money on-site. To help our users configure their networks more effectively to run Disguise systems, here we will provide a general overview of how Designer and other Disguise systems communicate both internally and externally over a network.
Designer internal communication
Multiple computers running the same project on the same network are referred to as “In Session”. While in session, these servers are in constant network communication with each other. To facilitate this network communication we use both TCP and UDP transport layer protocols.
Disguise systems primarily rely on TCP (Transmission Control Protocol) for most d3Net communications. TCP ensures reliable, ordered, and error-checked delivery of data between applications running on hosts communicating over an IP network. This protocol is well-suited for the majority of d3Net functionality, where data integrity is crucial.
For timing-critical operations Disguise systems employ UDP (User Datagram Protocol). UDP is low latency and lower overhead compared to TCP. In Disguise systems UDP is used for:
- QTP (Quantized Time Protocol) messages in non-genlocked sessions (port 7542 and 7543)
- VSync messages in genlocked sessions (port 7968)
- Network time sync between machines (port 7892)
Quality of Service (QoS) Recommendation
In a managed network environment, it’s highly recommended to assign a high Quality of Service (QoS) priority to the UDP sync messages that Designer relies upon. This ensures that these critical timing packets are given preferential treatment in the network, minimizing latency and jitter. By prioritizing these sync messages, you can maintain tight synchronization between Disguise machines, which is essential for seamless multi-machine playback and output.
Tracking Systems and UDP
Tracking systems, which provide real-time positional data for objects or performers in a live environment, typically use UDP for data transmission. This choice is made for similar reasons as our sync packets:
- Low latency: UDP’s lightweight nature allows for faster data transmission, crucial for real-time tracking.
- High frequency updates: Tracking systems often send updates many times per second, making UDP’s lower overhead beneficial.
- Tolerance for packet loss: In tracking scenarios, getting the most recent data quickly is often more important than ensuring every packet arrives.
Given the critical nature of tracking data in many Disguise workflows, it’s recommended to treat these UDP packets with the same high priority as our sync messages in your network configuration. This means:
- Assigning high QoS priority to the UDP ports used by your tracking system.
- Ensuring minimal network hops between the tracking system and Disguise machines.
- Monitoring and minimizing network congestion on the paths used by tracking data.
By prioritizing tracking system UDP traffic alongside Disguise sync messages, you can ensure the most responsive and accurate real-time tracking integration in your projects.
Network Ports and Activity
Below is a list of ports that Designer uses and a description of the activity we expect over that port.
| Port | Protocol | Application | Description |
|---|---|---|---|
| 80 | TCP | d3nginx.exe | Web server, used for API commands (default, user configurable) |
| 873 | TCP | d3.exe | Used by rsync process spawned by Designer for project file synchronization between machines |
| 4809 | UDP | d3.exe | CITP service discovery |
| 5568 | UDP | d3.exe | sACN (streaming ACN) |
| 5670 | UDP Broadcast | Any d3Net application including RenderStream clients | Used by Designer for discovering new machines when joining a network |
| 6454 | UDP | d3.exe | Art-Net |
| 7400 | UDP | d3.exe | OSC output (default, user configurable) |
| 7401 | UDP | d3.exe | OSC input (default, user configurable) |
| 7542 | UDP Broadcast | d3.exe | Used for QTP (Quantized Time Protocol) messages |
| 7543 | UDP Broadcast | d3.exe | Used for QTP (Quantized Time Protocol) messages |
| 7968 | UDP Broadcast | d3.exe | Used for VSync messages in genlocked sessions |
| 8888 | UDP Local | d3.exe | Used by Designer and spawned process for local communication with project file synchronization process |
| 8889 | UDP Local | d3.exe | Used by Designer and spawned process for local communication with project file synchronization process |
| 9864 | TCP | d3.exe | Telnet JSON machine control (default, user configurable) |
| 9993 | TCP | rsync.exe | rsync daemon for project file synchronization (default, user configurable) |
| 49152-65535 | TCP | d3.exe and other d3Net applications such as RenderStream clients | Used for d3Net functionality, dynamically negotiated and allocated |
| 50500 | UDP | RenderStream clients | Used for high bandwidth, uncompressed RenderStream video streams |
| 50501 | UDP | RenderStream clients | Used for compressed RenderStream video streams |
| 54321 | TCP | d3.exe | Remote transport controls (default, user configurable) |
| 60668 | TCP | d3.exe | CITP, spawns additional TCP connections on ports declared by connected CITP devices |
In addition to the above, vendor specific protocols (such as tracking systems, matrix drivers, etc) may use additional ports. Disguise provides user configurable port numbers where possible and allowed by the protocol / SDK.
NDI
NDI is a network transport protocol for streaming video over the network. You can read more about it on the official website here. Designer supports capturing NDI streams as video inputs.
If you’re using NDI for video inputs, their SDK uses a variety of ports. See NDI Port usage for more information.
Genlock and network time synchronisation
Starting in Designer version r28.0 Designer will broadcast and receive UDP messages over several different ports to maintain session-wide output synchronisation. Below is a summary of this behaviour:
- In non-genlocked sessions: QTP messages are broadcast from the director on port 7542 and 7543.
- In fully genlocked sessions: VSync messages are broadcast from the director on port 7968.
- In partially genlocked sessions: Both QTP (from director) and VSync (from first genlocked machine) messages are broadcast.
- To minimize network traffic, it’s recommended to genlock all machines in the session.
- On larger networks, each machine should specify a specific network adapter in d3Manager rather than “Any” to avoid unnecessary broadcasts.