ネットワークの一部であるリバースエンジニアリング「Cossacks 3」：ローカルサーバーを作成します

最近、同僚との会話の中で、 RTSジャンルのさまざまなゲームについて議論しましたが、3番目の「コサック」のリリースがなぜ過ぎ去ったのか疑問に思いました。 数分後、1つの検索クエリを思い出しました-非常に粗雑な初期リリースに加えて、この古典的な戦略の生まれ変わりは、公式サーバーへの永続的な接続なしのマルチプレイヤーゲームの不可能性によって区別されました。 さまざまな新鮮さのフォーラムで「LANを追加」するというプレイヤーからの多数の要求は、変更に待つ価値がないことを示唆しています。

まあ、山がモハメッドに行かなければ...

TL; DR：サーバー、使用方法、およびソースコードはGitHubで入手できます 。

最初のステップ

プロトコルの一般的な構造を理解するには、ゲームクライアントと公式サーバーの間で盗聴される最初の4つのパケットで十分です。 だから私たちは持っています：

• 通常のTCP / IPの上に構築されたネットワークプロトコル
• 暗号化または難読化なし
• 番号が最も低いものから最も高いものへと順番に送信される。

パケットヘッダーは常に正確に14バイトで、ペイロードサイズ（1）、コマンドコード（2）、およびパケットアドレス指定用の2つのプレーヤー識別子（3.4）が含まれています。 簡単な例を挙げましょう-ゲームロビーでのプライベートチャットメッセージ：



また、行の前にはその長さがあります（5）。 特定のコマンドコードに応じて、データ形式が異なり、行のサイズが1、2、または4バイトで示されることは注目に値します。

新しいゲームルームの作成に関する公開通知を検討してください。



ヘッダーもサイズ、コマンド、および送信者（1,2,3）で始まりますが、受信者識別子がありません（4）。 このメッセージでは、「全員に送信」を意味しますが、他のチームにとっては「自分の部屋の全員に」を意味する場合もあります。 最初の行（5）には、名前、パスワード、およびゲームのタイプとルームの作成者（ホスト）のクライアントのバージョンに関する情報が含まれています。 値を区切るには、タブ文字\ tが使用されます。これは09hです。 次に、部屋に関する情報が記載された行（6）が続きます。これは、部屋をリストに表示するために必要です。 ステータス、ライブプレイヤーの数、コンピューターの対戦相手、クローズされたスロット、さらに2つの値が含まれます。 ここでは、縦線がセパレータの役割を果たします。 その後に、それぞれ4バイトの2つの定数（以下、タイプIntの数と呼びます）が続き、次に、部屋の作成者のコンピューターのホスト名を含む行（7）が続きます。


それでは、もっと興味深い点に移りましょう。

翻訳の難しさ

最初に、 TCPの&&データ フィルターを使用してWiresharkのパケットを分析し、 ACKのような「空の」パケットが目の前で点滅しないようにしました。 ある時点で、横向きになったことが判明しました。DCERPCプロトコルパケットの TCPペイロードが05h 00hバイトで始まるパケットをWiresharkが誤って受け入れることが判明しました。 特に、これは、部屋に入ったプレーヤーに関する通知を含むパケットに影響しました。 常にヘッダーの後に正確に5バイトが含まれます。 これにより、WiresharkはTCP負荷をDataではなく[Malformed Packet：DCERPC]としてマークし、パケットを非表示にします。



この場合、正しいのは新しいtcp.payloadフィルターを使用することです。 Wiresharkがこの負荷をどのように解釈するかに関係なく、ペイロードを持つすべてのTCPパケットを表示します。

シリアル化の進化

ネットワークプロトコルを逆にすると、優先順位の異なるさまざまな人がさまざまなタイミングでそれに取り組んだことは明らかでした。 変数を渡す3種類の行を区別できます。

• コンパクトな弦
  行の長さは1バイトで示され、行には変数の名前が含まれ、フィールドは垂直バーで区切られます： ps=1337|pw=42|pg=12
• 中間線
  行の長さは2バイトで示され（以下、タイプShortの 数と呼ばれます）、値はタブで区切られ、名前はありません： "MyRoom"\t"secret"\t0AFFE
• 寛大な弦
  特殊な文字列。実際には、変数名とそのand値が交互になった文字列の配列です。 1次元形式の一種の連想配列 。 その中の各行（長さ！）の長さは、 Int型の数で示されます。 この形式の詳細な説明は、サーバーのソースコードのコメントに記載されています。
  
  例

  
  行の長さを示す数字は、赤、 黄色の区切り記号でマークされています。
  

最後の例は、部屋の作成者がゲームを離れるときに、ホストの役割をプレーヤーの1人に移すことを規制するパッケージから取られています。 私が理解しているように、この機能はゲームのリリース後にさらに開発されました。 明らかに、データ転送効率の問題は、元のエンジンでネットワークプロトコルを作成するときほど深刻ではありませんでした。

ずさんなバッファー

多くのパケットの終わりで、ペイロードは4つまたは6つのゼロバイトで終わります。 ただし、特定のパッケージ（特に、コマンドコード0xc8および0x19dを使用 ）では、データが予期せずポップアップすることがあります。 これらのパッケージの1つで、ロビーチャットのメッセージの1つの断片を見つけるまで、それらがどこから来て、なぜ必要なのかを理解できませんでした。

どうやら、公式サーバーは、送信前に応答パケットが書き込まれるバッファーを常にゼロにするとは限らず、残りのバイトは終了バイトで失われる可能性があります。 幸いなことに、ゲームクライアント自体では、これはエラーにつながりません。 しかし、それでも開発のペースと品質管理のレベルについて何かを述べています。

あまり知らない-より強力なサーバー

...または「 悪いほど良い 」。 使用されているプロトコルに関する非常に多くの知識を得た後、ソースコードの量は増えなくなり、溶け始めました。 インターフェイスは簡素化され、サーバーが保存を強制されたデータ（たとえば、ロビーの状態を新しい到着に転送する）が分析されなくなり、文字列として保存され始めました。 パケットの各バイトの発信元と宛先を知る必要はありません。 リダイレクト先と方法を理解するだけです。

サーバーは、他のクライアントから以前に受信したデータでほとんどの要求に応答するか、特別なパッケージを使用して目的のクライアントを呼び出し、要求者に応答をリダイレクトします。 可能な場合は、オプションの文字列を省略し、nullバイトに置き換えました。 まず第一に、これはプレイヤーのレーティング、ポイント数、および勝利に関するデータに関係します。

場合によっては、幅広すぎるパケットリレーがクライアント側のエラーを生成することさえありました。 特に、コマンドコード0x1b3と0x1b4 の要求と応答のペアでこれに気付き、プレーヤーのポイントとクライアントのシステムに関する情報を複製しています。

並ぶ

私にとって特に難しかったのは、ゲームの起動と同期の側面でした。 ブート時にパケットリレーを処理したので、ゲーム中にすべてのクライアントが0x4b0コマンドコードでパケットを送信することに気付きました。 この場合、ルームの作成者の番号は識別子の1つのフィールドにあり、2番目のフィールドは空です。 しかし、論理的にアプローチし、これを「クライアントは指定された部屋の全員である」と理解すると、ゲームは同期しなくなります。

代わりに、サーバー自体がパケットのソースを監視し、ホストか通常のプレーヤーかを確認する必要があります。 前者の場合、パケットは、ホスト自体を除くルーム内のすべてのプレイヤーに送信されます。 後者自体では、ホストのみに送信されます。 同時に、どうやらゲームチームとのパッケージが何が起こっているかのキューに追加され、その後、ホストから既に送り返されますが、ゲームの他のすべてのイベントのコンテキストで。 これにより、すべてのプレーヤーで同じ実行順序が保証されます。 ホストは、イベントの数やその他すべてに関係なく、プレーヤーからのアクションのみで、ゲームパッケージを一定のタクトで絶えず送信します。

ところで、ゲーム中にホストを変更すると、注文が失われる可能性があることを示す警告が表示されます-古いホストが切断する前にそれらを一般キューに追加できなかった場合 、新しいホストはこれらのコマンドを見つける方法がありません。

初歩的なLAN

世論に反して、クライアントにはローカルネットワークでの完全なゲームに必要な機能がまだあります。 ネットワークトラフィックを分析すると、多くのTCPパケットの中で、ルームの作成者がUDPを介してプレーヤーの数とルームのステータスに関する通知も送信していることに気付きました。

さらに、クライアントを分解するときに、例外が発生してエラーテキストを表示するときに呼び出される関数に遭遇しました。 彼女の呼び出しを歩いて、彼女に送信されたテキストを分析すると、例外が発生するプロシージャの実際の名前を判別できます。 結果に少し驚いた、私は弦で遊んだ、

2つの選択肢があります。開発者がそのようなユーモアを持っているか、マルチプレイヤーゲームに接続されているすべてのものに略語LANを普遍的に使用していました。

C ++、Asioおよび無傷の脚

最初にクロスプラットフォームサーバーを作成し、ネットワークプログラミングの知識を広げることを目標に設定したため、実装にC ++言語とAsioライブラリを選択しました。 後者により、非同期性とより単純なコードを支持して、マルチスレッドと関連するデータアクセス機能を放棄することもできました。 基礎として、私はライブラリー・リポジトリーの例の1つのソース・コードを取りました。

私にとって開発の最も興味深い側面は、パケットの非同期送信中のデータバッファの可用性の問題でした。 同時に、割り当ての数を最小限に抑え、メモリ内のデータをコピーしようとしました。 すべてに加えて、サーバーには、パケットを受信するためのかなり大きなバッファが必要です。 ゲームの開始前にマップデータを送信するときのTCPペイロードのサイズは800キロバイトを超えることがあります。

その結果、次のようにパッケージの読み取り、作成、送信のプロセスを実装しました。

1. 新しいクライアントが接続すると、サーバーは、 std :: vector <unsigned char>タイプの十分に大きい（1 MiB）バッファー（ 以降 、Bufferと呼びます ）を含むSessionクラスのオブジェクトを作成します。
2. 非同期読み取り操作が完了した後、このアドレスはこのバッファーにメインパケット処理機能に転送されます。 次の読み取り操作は、この関数の完了後にのみ開始され、処理時間のバッファ内のデータの安全性を保証します。
3. 処理の開始時に、 Packetクラスのオブジェクトが作成されます。これは、データの読み取りとシリアル化のためのインターフェイスを提供します。 これにより、サーバーの応答はすべてセッションオブジェクトの同じバッファに書き込まれ、パケットの送信者に割り当てられます。
4. パッケージに対するすべての操作が完了すると、send関数はstd :: make_shared <Buffer>を使用してバッファーを割り当てます。 同時に、応答パケットの正確なサイズを考慮して、 セッション内の同じバッファーの反復子がバッファーコンストラクターに渡されます（記録中にパケットがこれを監視します）。 つまり 1回の操作で、最初にパケットとポインターの制御ブロックに十分なメモリを（ 一度に ）割り当ててから、送信すべき大きなバッファーから正確にバイト数をコピーします。
5. 新しいバッファは、タイプstd :: shared_ptr <Buffer> （ 以降 BufPtrと呼ぶ ）の受信ポインタを使用して、パケットの送信先となるすべてのクライアントのSessionオブジェクトに渡されます。 そこで、タイプstd :: deque <BufPtr>のローカルキューに配置されます。 いずれかのクライアントのキューにあるインデックスの各コピーは、参照カウンターを増やします。 この後、パケット処理は終了し、最初のセッションバッファは次のパケットを受信する準備が整います。
6. パケットの非同期記録（送信）操作が完了すると、ポインターは宛先クライアントのローカルセッションキューから削除され、参照カウンターが下がります。 パケットがキューに入っていたすべてのクライアントに送信されるとすぐに、カウンターはゼロにリセットされ、スマートポインターはそれ自体でメモリを解放します。

どのように判断しても、ラムダ式、さまざまなコンテナ、C ++標準へのスマートポインタの追加により、このようなシステムの設計の複雑さが大幅に軽減されました。 サーバーを作成するときに、片足は撃たれませんでした。

シャッタースピードテスト

サーバーでの作業を終了し、基本的な機能をテストした後、長い時間をかけてホストが通過した後、サーバーの安定性と同期を確認することにしました。 これを行うために、ローカルネットワーク上に3人のプレーヤーと5つの複雑なAIを備えた部屋を作成しました。 テストでは、マップサイズ、デポジット数、人口、および非攻撃時間に関する最大パラメーターを選択しました。 ゲームを開始し、数分後にタスクマネージャーのホストコンピューターでゲームプロセスを停止して、予期しないシャットダウンをシミュレートしました。 その後、残りの2人のクライアントは、一晩中放置されました。

経験豊富なプレイヤーは、おそらく次に何が起こったかをすでに推測しているでしょう。 つまり、サーバーはテストに合格しましたが、 クライアントは合格しませんでした。 翌日、画面には約8時間フリーズするゲームタイマーと、いくつかのエラーメッセージが表示され、その中にはおなじみの 「メモリ不足」がありました。 すべてが論理的であり、残りの2つのAIはマップを半分に分割し、数千の軍隊と戦った。 ゲームプロセスは約3.5 GBのRAMを使用し、32ビットの境界に達しました 。 サーバーは、11 MBのRAMで引き続き実行されました。

おわりに

公式サーバーのブラックボックスをコピーするプロセスに興味があることを願っています。 また、ゲームの開発者がプレイヤーに同情し、最終的にローカルネットワークでマルチジャックゲームの可能性を追加することを願っています。 ところで、最後の議論は、 最近の出来事を考慮して、新しい色でいちゃつきました。

サーバーのリバースまたはソースコードに関する質問や提案がある場合は、コメントを歓迎します 。 じゃあね！