ネットワークポートとアクティビティ
ネットワークは、あらゆる Disguise システムの非常に重要な部分です。サーバーは互いに、またサードパーティのソフトウェアやハードウェア製品とも常に通信する必要があります。適切に構成されたネットワークは、現場での時間とコストを節約できます。ユーザーが Disguise システムを実行するためにネットワークをより効果的に構成できるよう、ここでは Designer やその他の Disguise システムが、ネットワーク上で内部的および外部的にどのように通信するかの一般的な概要を説明します。
Designer の内部通信
Section titled “Designer の内部通信”同じネットワーク上で同じプロジェクトを実行している複数のコンピューターは「In Session」と呼ばれます。セッション中、これらのサーバーは互いに常にネットワーク通信を行います。このネットワーク通信を実現するために、TCP と UDP の両方のトランスポート層プロトコルを使います。
Disguise システムは、ほとんどの d3Net 通信に主に TCP（Transmission Control Protocol）を使います。TCP は、IP ネットワーク上で通信するホスト上のアプリケーション間で、信頼性が高く、順序付けられ、エラーチェックされたデータ配信を保証します。このプロトコルは、データの整合性が重要な d3Net の大部分の機能に適しています。
タイミングが重要な操作には、Disguise システムは UDP（User Datagram Protocol）を使います。UDP は TCP に比べて低レイテンシでオーバーヘッドが小さいものです。Disguise システムでは、UDP は次の用途で使われます:
- 非 Genlock セッションでの QTP（Quantized Time Protocol）メッセージ（ポート 7542 と 7543）
- Genlock セッションでの VSync メッセージ（ポート 7968）
- マシン間のネットワーク時刻同期（ポート 7892）
Quality of Service (QoS) の推奨
Section titled “Quality of Service (QoS) の推奨”管理されたネットワーク環境では、Designer が依存する UDP 同期メッセージに高い Quality of Service（QoS）優先度を割り当てることを強く推奨します。これにより、これらの重要なタイミングパケットがネットワークで優先的に扱われ、レイテンシとジッターが最小化されます。これらの同期メッセージを優先することで、Disguise マシン間の緊密な同期を維持でき、シームレスなマルチマシン再生と出力に不可欠です。
トラッキングシステムと UDP
Section titled “トラッキングシステムと UDP”ライブ環境でオブジェクトやパフォーマーのリアルタイムの位置データを提供するトラッキングシステムは、通常 UDP をデータ伝送に使います。この選択は、同期パケットと同様の理由で行われます:
- 低レイテンシ: UDP の軽量な性質により、リアルタイムトラッキングに重要な、より高速なデータ伝送が可能になります。
- 高頻度更新: トラッキングシステムは多くの場合、毎秒何度も更新を送るため、UDP の低オーバーヘッドが有益です。
- パケット損失への耐性: トラッキングのシナリオでは、すべてのパケットの到着を保証するよりも、最新のデータを素早く取得することの方が重要なことが多いです。
多くの Disguise ワークフローでトラッキングデータが重要な性質を持つことを踏まえ、これらの UDP パケットを同期メッセージと同じ高い優先度で扱うことを推奨します。つまり:
- トラッキングシステムが使う UDP ポートに高い QoS 優先度を割り当てる。
- トラッキングシステムと Disguise マシン間のネットワークホップを最小限にする。
- トラッキングデータが使うパスのネットワーク輻輳を監視・最小化する。
トラッキングシステムの UDP トラフィックを Disguise 同期メッセージと並んで優先することで、プロジェクトで最も応答性が高く正確なリアルタイムトラッキング統合を確保できます。
OmniCal network usage
Section titled “OmniCal network usage”Disguise OmniCal システムは、GigEVision ストリーミング専用の別の分離されたネットワーク上で、Director（または Solo）サーバーとマシンビジョンカメラ間のローカルネットワーク通信を必要とします。また、Designer プロセスと当社のカメラキャプチャアプリケーション VimbaCamServer 間の内部サーバー通信に 3 つのポートを使います。これらのポートは、OmniCal が使用中、つまり Director でいずれかの OmniCal ウィンドウが開いている場合にのみアクティブになります。
詳しくは OmniCal Networking Guide をご覧ください。
ネットワークポートとアクティビティ
Section titled “ネットワークポートとアクティビティ”以下は、Designer が使うポートと、そのポート上で予想されるアクティビティの説明の一覧です。
| ポート | プロトコル | アプリケーション | 説明 |
|---|---|---|---|
| 80 | TCP | d3nginx.exe | Web サーバー。API コマンドに使用（デフォルト、ユーザー設定可能） |
| 873 | TCP | d3.exe | マシン間のプロジェクトファイル同期のために Designer が生成する rsync プロセスが使用 |
| 3207 | HTTP | d3.exe / nmos-node.exe | Designer が NMOS ノードにディスプレイ更新を送るために使用 |
| 3212 | HTTP | nmos-node.exe | NMOS Node Query API |
| 3215 | HTTP | nmos-node.exe | NMOS Connection API |
| 3216 | HTTP | nmos-node.exe | NMOS Events API |
| 3217 | HTTP | nmos-node.exe | NMOS Events WS API |
| 3218 | HTTP | nmos-node.exe | NMOS Control API |
| 3219 | HTTP | nmos-node.exe | NMOS Channel Mapping API |
| 4809 | UDP | d3.exe | CITP サービス検出 |
| 5568 | UDP | d3.exe | sACN（streaming ACN） |
| 5670 | UDP Broadcast | RenderStream クライアントを含むすべての d3Net アプリケーション | ネットワーク参加時に新しいマシンを検出するために Designer が使用 |
| 6454 | UDP | d3.exe | Art-Net |
| 7400 | UDP | d3.exe | OSC 出力（デフォルト、ユーザー設定可能） |
| 7401 | UDP | d3.exe | OSC 入力（デフォルト、ユーザー設定可能） |
| 7542 | UDP Broadcast | d3.exe | QTP（Quantized Time Protocol）メッセージに使用 |
| 7543 | UDP Broadcast | d3.exe | QTP（Quantized Time Protocol）メッセージに使用 |
| 7892 | UDP Broadcast | d3.exe | マシン間のネットワーク時刻同期 |
| 7968 | UDP Broadcast | d3.exe | Genlock セッションでの VSync メッセージに使用 |
| 8888 | UDP Local | d3.exe | Designer と生成プロセスがプロジェクトファイル同期プロセスとローカル通信するために使用 |
| 8889 | UDP Local | d3.exe | Designer と生成プロセスがプロジェクトファイル同期プロセスとローカル通信するために使用 |
| 9001 | UDP Local | d3.exe | Designer と生成された VimbaCamServer.exe プロセスがローカルの OmniCal 検出（OSC）に使用 |
| 9864 | TCP | d3.exe | Telnet JSON マシン制御（デフォルト、ユーザー設定可能） |
| 9993 | TCP | rsync.exe | プロジェクトファイル同期用の rsync デーモン（デフォルト、ユーザー設定可能） |
| 10101 | UDP Local | d3.exe | Designer と生成された VimbaCamServer.exe プロセスがローカルの OmniCal 検出（OSC）に使用 |
| 10101 | TCP Local | d3.exe | Designer と生成された VimbaCamServer.exe プロセスがローカルの OmniCal 通信に使用 |
| 10102 | TCP Local | d3.exe | Designer と生成された VimbaCamServer.exe プロセスがローカルの OmniCal 通信に使用 |
| 10741 | HTTP | nmos-node.exe | NMOS System API |
| 49152-65535 | TCP | d3.exe や RenderStream クライアントなどの他の d3Net アプリケーション | d3Net 機能に使用。動的にネゴシエート・割り当て |
| 50500 | UDP | RenderStream クライアント | 高帯域幅・非圧縮の RenderStream ビデオストリームに使用 |
| 50501 | UDP | RenderStream クライアント | 圧縮された RenderStream ビデオストリームに使用 |
| 54321 | TCP | d3.exe | リモートトランスポート制御（デフォルト、ユーザー設定可能） |
| 60668 | TCP | d3.exe | CITP。接続された CITP デバイスが宣言したポートで追加の TCP 接続を生成 |
上記に加えて、ベンダー固有のプロトコル（トラッキングシステム、マトリックスドライバーなど）が追加のポートを使うことがあります。Disguise は、可能でプロトコル／SDK が許可する場合、ユーザー設定可能なポート番号を提供します。
DNS-SD
Section titled “DNS-SD”r30.4 以降の Designer インスタンスは DNS-SD 検出をサポートします。これにより、ホスト名やポート番号を事前に知らなくても、ネットワーク上の Designer インスタンスを検出して接続できます。これには Service API と Session API の両方へのアクセスが含まれます。Discovery API について詳しくは、開発者向けドキュメント をご覧ください。
NDI® は、ネットワーク上でビデオをストリーミングするためのネットワークトランスポートプロトコルです。詳しくは公式の NDI® ウェブサイト をご覧ください。Designer は NDI® ストリームをビデオ入力としてキャプチャすることをサポートします。
NDI® をビデオ入力に使う場合、その SDK はさまざまなポートを使います。詳しくは NDI® のポート使用 をご覧ください。
Genlock とネットワーク時刻同期
Section titled “Genlock とネットワーク時刻同期”Designer バージョン r28.0 から、Designer はセッション全体の出力同期を維持するために、いくつかの異なるポートで UDP メッセージをブロードキャスト・受信します。以下はこの動作の概要です:
- 非 Genlock セッションでは: QTP メッセージが Director からポート 7542 と 7543 でブロードキャストされます。
- 完全に Genlock されたセッションでは: VSync メッセージが Director からポート 7968 でブロードキャストされます。
- 部分的に Genlock されたセッションでは: QTP（Director から）と VSync（最初の Genlock マシンから）の両方のメッセージがブロードキャストされます。
- ネットワークトラフィックを最小化するため、セッション内のすべてのマシンを Genlock することを推奨します。
- 大規模なネットワークでは、不要なブロードキャストを避けるため、各マシンは「Any」ではなく d3Manager で特定のネットワークアダプターを指定すべきです。