#Quake Engine code review : Network (2/4)
QuakeWorldのネットワークアーキテクチャは当時、画期的な画期的な革新と見なされていました。 すべてのネットワークゲームの後継者は同じアプローチを採用しました。 ここに詳細があります。
この記事は４つのセクションに分かれています
- Architecture section
- Network section（本記事）
- Prediction section
- Rendition section
#Network stack
Quakeの基本的なコミュニケーションユニットがコマンドです。 コマンドはプレーヤーの位置、方向、健康、損傷などを更新するために使用されます。
TCP / IPには、リアルタイムシミュレーション（フロー制御、信頼性、パケットシーケンシング）には都合が良いが、Quake World Engine（元のQuakeにあった）には使えません。FPSでは、ASAP（as soon as possible）で受信されない情報は再送信する価値がありません。 したがって、UDP / IPが選択され、信頼性とパケットシーケンスを実装するために、ネットワーク抽象化レイヤ "NetChannel"が作成されました。
OSIの観点から、NetChannelはUDPの上に非常にうまく座っています。
要約すると、エンジンは主にコマンドを扱います。 送信または受信が必要な場合は、タスクをnetchan.cのNetchan_TransmitメソッドとNetchan_Processメソッドに委譲します（これらのメソッドはクライアントとサーバーで同じです）。
#NetChannel Header
NetChannelヘッダーの構造は次のとおりです。
| Bit offset | Bits 0-15 | 16-31 |
|---|---|---|
| 0 | Sequence | Sequence |
| 32 | ACK Sequence | ACK Sequence |
| 64 | QPort | Commands |
| 94 | ... | ... |
シーケンスは、送信者によって初期化され、パケットが送信されるたびに1ずつインクリメントされるintです。 シーケンスの目的は複数ですが、最も重要なのは、受信者に失われた/重複した/順序付けられていないUDPパケットを認識させる方法を提供することです。 intの最強ビットはシーケンスの一部ではありませんが、ペイロード（コマンド）に信頼できるデータが含まれていることを示すフラグが付いています（詳細は後で説明します）。
ACK Sequenceもintであり、受信した最後のシーケンス番号と等しい。 これにより、NetChannelのもう一方の端で、パケットが失われたかどうかを確認できます。
QPortはNATルータのバグを回避するためにここにあります（このページの末尾にある続きを読んでください）。 この値は、クライアントの起動時に設定される乱数です。
コマンド：ペイロードです
#Reliable messages
信頼できないコマンドは、最後の発信シーケンス番号でマークされて送信されたUDPパケットにグループ化されます。彼らが迷子になった場合、送信者にとっては問題になりません。
信頼性の高いコマンドは別々に扱われますが、重要なのは、送信者と受信者の間で肯定応答されない信頼できるUDPパケットが1つしかないことを理解することです。
すべてのゲームループは、新しい信頼できるコマンドが生成された場合、
message_buf配列に追加されます（メッセージ変数を介してパイロットされます）（1）。
信頼できるコマンドのセットは、メッセージからreliable_bufアレイ（2）に移動されます。これは、reliable_bufが空の場合にのみ発生します（空でない場合、これは他のコマンドセットが先に送信され、まだ確認応答されていないことを意味します）。
最終的なUDPデータグラムが作成されます。NetChannelヘッダーが追加されます（3）。十分なスペースがある場合は、reliable_bufのコンテンツと信頼性の低いコマンドが追加されます。
受信側では、UDPメッセージが解析され、入ってくるシーケンス番号は（パケットが信頼できるデータを含むことを示すビットフラグと共に）発信シーケンスACK（4）に転送される。
次のメッセージを受信したとき：
信頼できるビットフラグがtrueに設定されている場合、UDPパケットはそれを受信者に送信します。 NetChannelはreliable_buf（5）をクリーンアップして、新しいコマンドセットを送信する準備ができています。
信頼できるビットフラグがfalseに設定されている場合、UDPはそれを受信者に送信しません。 NetChannelはreliable_bufの内容を再度送信しようとします。 新しいコマンドがmessage_bufに積み重なります。この配列がオーバーフローした場合、クライアントは破棄されます。
##Flow-Control
私が読むことができる限り、サーバ側でのみフロー制御があります。 クライアントは状態更新をできるだけ速く送信します。
サーバ上でアクティブな最初のフロー制御ルールは、データグラムがクライアントから受信された場合にのみデータグラムを送信することです。 制御フローの第2の形態は、クライアントがコンソール内のレートコマンドを介して設定できるパラメータである「choke」である。 これにより、サーバーは更新メッセージをスキップし、クライアントに送信されるデータの量を減らします。
##Important commands
コマンドにはバイトに格納されたタイプコードと、それに続くコマンドのペイロードがあります。 おそらく最も重要なのは、ゲームの状態（frame_t）に関する情報を与えるコマンドです。
- svc_packetentitiesとsvc_deltapackententities：ロケットトレイル、爆発、パーティクルなどのエンティティを更新する
- svc_playerinfo：プレーヤーの位置、最後のコマンドとコマンドの継続時間をmsec単位で更新する
##More on the qport
Qportはバグを回避する為にNetChannelヘッダーに追加されたものです。 Qport導入以前は、Quakeサーバーはその組み合わせ（リモートIP、リモートUDPポート）によってクライアントを識別しました。 ほとんどの場合、これはうまくいきましたが、特定のNATルータは、ポート変換（リモートUDPポート）のスキーマを散発的に変更できます。 UDPポートが信頼できない場合、John Carmack氏は彼の計画の1つで、（リモートIP、NetChannelヘッダーのQport）でクライアントを識別することに決めたと説明しました。 これにより、混乱が修正され、サーバはターゲットUDP応答ポートを即座に調整することができました。
##Latency calculation
Quakeエンジンは、最後に送信された64個のコマンド（frame_t配列：フレーム内）を送信時刻と共に格納します。これらのコマンドは、転送に使用されたシーケンス番号（outgoing_sequence）を介して直接アクセスできます。
frame = &cl.frames[cls.netchan.outgoing_sequence & UPDATE_MASK];
frame->senttime = realtime;
//Send packet to server
サーバからの肯定応答に応じて、コマンドが送信された時刻がシーケンスACKを介して取得されます。 レイテンシは次のように計算されます。
//Receive response from server
frame = &cl.frames[cls.netchan.incoming_acknowledged & UPDATE_MASK];
frame->receivedtime = realtime;
latency = frame->receivedtime - frame->senttime;
##Some elegant things
配列インデックスサイクリング
エンジンのネットワーク部分には、最後に受信した64個のUDPデータグラムが格納されます。 配列を循環する素朴なアプローチは、モジュロ演算子を使うことでした。
arrayIndex =（oldArrayIndex + 1）％64;
代わりに、新しい値は、UPDATE_MASKで "AND"バイナリ演算で計算され、UPDATE_MASKは64-1に等しくなります。
(2のべき乗の剰余を処理する場合、ビット単位AND演算を使用することができる。)
arrayIndex =（oldArrayIndex + 1）＆UPDATE_MASK;
実際のコードは実際には：
frame_t * newpacket; newpacket =＆frames [cls.netchan.incoming_sequence＆UPDATE_MASK];