Quake 3 ソースコードレビュー: ネットワークモデル (2012)

ネットワークモデル

• Quake 3のネットワークモデルはエンジンの中でも最も洗練された部分であり、高速な環境では最初の送信で受信されなかった情報を再送する価値はないことを強調している。
• UDP/IPを使用し、TCP/IPの信頼性ある転送は遅延を引き起こすため使用しない。
• ネットワークスタックは、事前共有鍵を使った暗号化と、事前計算されたハフマン鍵を使った圧縮という、相互排他的な2つの層へと拡張される。
• サーバー側では、UDPデータグラムのサイズを最小化しつつ、UDPの信頼性不足を補うシステムが際立っている。

アーキテクチャ

• クライアント側はシンプルで、各フレームごとにサーバーへコマンドを送信し、ゲーム状態の更新を受け取る。
• サーバーはマスターゲーム状態を各クライアントへ配信する必要があり、UDPパケット損失を考慮しなければならない。
• 主な要素は3つある。マスターゲーム状態、クライアントのコマンドをNetchannel経由で送信すること、そして直近32個のゲーム状態を循環配列に保存するスナップショットである。

スナップショットシステム

• サーバーはクライアントへ更新を送信する際、常にマスターゲーム状態をクライアントの次の履歴スロットにコピーし、ほかのスナップショットと比較する。
• 有効なスナップショットがない場合は「ダミースナップショット」を使って完全な更新を生成する。
• クライアントが以前の更新を受信したことを確認すると、差分更新のみが送信される。
• パケットが失われた場合でも同じプロセスに従い、以前に受信されなかった情報と新しい情報を単一のメッセージとして送信する。

メモリ耐性とC

• Quake3はイントロスペクションなしでスナップショットを比較し、各フィールド位置は配列とプリプロセッサディレクティブによって事前に構成される。
• netField_t構造体を使ってフィールドの位置とサイズを定義し、それによって差分をネットワーク越しに送信する。

事前分割

• NetChannelモジュールはメッセージを1400バイトのチャンクに分割して送信し、これによってルーターによるパケットのフラグメンテーションを防ぐ。
• ルーターのフラグメンテーションは、ネットワークに入る際にパケットをブロックし、ネットワークを出る際にはすべての断片を待つ必要があるため、コストが高い。

信頼性のあるメッセージと信頼性のないメッセージ

• スナップショットシステムは、ネットワーク上で失われたUDPデータグラムを補償するが、一部のメッセージやコマンドは必ず配信されなければならない。
• こうした保証はNetChannelを通じて抽象化される。

[GN⁺]

Hacker Newsのコメント

• この記事はとても興味深く、前の記事も同様だった。だが今の仕事は退屈で、趣味のプロジェクトに回すエネルギーが残っていない。
• 「Isochronous」という用語はFireWireが登場したときに初めて耳にし、UDP使用の正当性を説明する文脈で言及されていた。現在ではUSB/Thunderbolt仕様の重要な一部になっている。
• シリーズ最初の記事へのリンク: https://fabiensanglard.net/quake3/index.php
• 遅延予測と補正の仕組みが興味深く、複雑な運用変換（OT）は使っていない。こちらのほうが単純で、共有状態には共同編集ドキュメントではなく独立した真実の源泉が必要であり、開発が速く、性能も高い。
• 元のQ3AクライアントのネットワークコードはLANではうまく動いていたが、遠隔プレイでは遅延に敏感だった。Quake Liveの興味深い変更点の1つは、遠隔プレイ向けに更新されたネットワークコードだった。インターネット接続全体も時間とともに改善された。
• サイトはHN Hug of Deathを食らっているようだ: <接続がタイムアウトしました>
• 土曜の朝、マテ茶をゆっくり飲みながら読むのに良い記事だ。人生のささやかな楽しみだ。
• Q: リアルタイムゲームプロトコルへの現代的なアプローチを学べる資料はあるだろうか?
• おそらくスナップショットID番号もクライアントに送信され、確認されているのだろう?
• 万全なオープンソースのミドルウェアは今でも存在するのだろうか?