1 はじめに
このサーバー側フレームワークを見ると、非常に軽量で、コードは最小限ですが、サーバー側のコアが含まれているため、初心者がサーバー側フレームワークの機能を簡単に理解するのに役立ちます。
もちろん、最も重要なことは、著者によって書かれたインクリメンタル開発ドキュメントです。これは本当に優れています。
この記事では、このプロジェクトのソース コードについて詳しく説明するのではなく、著者のドキュメントとソース コードを直接参照してください. この記事では、主にこのフレームワークを使用して、tcp サーバーのコア機能を要約します.
2. TCP サービスのコア機能
2.1 接続の取り扱い
TCP サーバーがクライアントに機能を提供するには、まずクライアントとの接続を確立する必要があります。
ネットワーク プログラミングを学んだことのある人なら、教科書の最初のステップは、ソケット バインド リッスン コネクトなどの関数の使い方を教えることであることを知っています。
もちろん、これは最も基本的なシステムコールにすぎません.フレームワークとして、これらの機能をカプセル化し、接続を処理し、さまざまなクライアントを統一的に管理することは当然です.
zinx はすでにこの機能を実装しています。9、Zinx リンク管理
著者のチュートリアル ドキュメントでは、この記事はすでに非常に遅れています。著者が 1 行ずつコードを作成し、このフレームワークに徐々に追加しているためです。これが、初心者が最初にそれを行う方法を知ることができ、後でこれらの機能を追加する必要がある理由を著者が非常によく書いたと思う理由でもあります。
接続が確立されると、メッセージが処理されます。
2.2 メッセージの処理
つまり、サーバー側のプログラムとして、クライアントからのメッセージを受け取り、対応する処理を行い、応答が必要な場合はクライアントに応答メッセージを返します。
2.2.1 契約
そういうことなんですが、メッセージをどのように識別し、メッセージをどのように処理するかということについて、何らかの規定を作る必要があります。
たとえば、HTTP はアプリケーション層プロトコルであり、Web クライアントと外部サーバーが対話する方法を指定します。サーバーは 200 を返します。これは、OK が 404 を返すことを意味します。これは、ページが見つからなかったことを意味します。これは事実ではなく、単なる規制です。
選択した TCP サービスは、他のサービスによって定義されている HTTP プロトコルも使用できます。しかし、必要はありません。ネットワーク トラフィックを増加させるために、HTTP プロトコルには冗長性が多すぎます。
現時点では、簡略化されたプロトコルをカスタマイズできます。たとえば、最も単純なものも非常に一般的です。メッセージ全体をメッセージ ヘッダーとメッセージ ボディに分割し、メッセージ ヘッダーの長さを固定します. 1 バイト目はメッセージ ボディの長さを示し、2 バイト目はメッセージ タイプを示し、残りはメッセージ ボディです.
これが私たちが定義するプロトコルです。
多くの教科書でスティッキー パッケージの問題について説明されていますが、これは擬似的な問題だと思います。質問ではない別の質問。プロトコルが定義されている限り。そのような問題はありません。ただし、プロトコルが定義されていない場合。袋をくっつけるだけではありません。とにかく、この問題を気にする必要はありません。
2.2.2 シリアライズとデシリアライズ
プロトコルが定義されると、サーバーはネットワーク メッセージの解析方法を認識します。
例えば、メッセージが来たら、まずメッセージヘッダーの長さのデータを抽出し、メッセージ本文の長さを知ってから、メッセージ本文を読み取ります。
このとき、読み出されるデータはすべてバイナリであり、このバイナリ データをプログラムが認識できるデータに変換するのがデシリアライズです。
シリアル化と逆シリアル化を行う場合, 最初に元のメッセージのメッセージ形式を修正する必要があります. 現在より一般的なのは json と protobuf です. この 2 つの詳細については説明しません. ゲームのネットワーク通信では pbより一般的です。
バイナリ データを取得したら、Pb ツールを呼び出してデータを逆シリアル化し、理解できるコード構造 (クラス、オブジェクト) に変換できます。
その後、独自のビジネスロジックに従って処理され、処理後、再度このコネクションを使用し、処理結果をシリアル化して送信します。
2.2.3 ルーティング
ルーティングとは、受信したメッセージを識別することですが、具体的なメッセージは何ですか? これはビジネスレベルの概念です。たとえば、ゲーム サーバーの場合、これがログイン メッセージであると区別できますか? それとも終了メッセージ？異なるメッセージを受信した場合はどうすればよいですか?
簡単に言うとスイッチ構造です。このメッセージ タイプは送信メッセージに含まれます。次に、メッセージ タイプを切り替えます。異なるケースは異なる方法で処理されます。コーディングの経験が少しある人なら誰でもこれを知っています。これは拡大にはつながらない、コラボレーションなどにはつながらない。ケースを抽象化する必要があります。それをルートとして定義するだけです。
ルートは特定のメッセージを処理します。たとえば、ログイン メッセージのルーティング プロセスを作成します。終了メッセージの別のルーティング プロセスを記述します。すべてのルートはマップに保存されます。
メッセージを受信すると、メッセージの種類に応じて処理のために異なるルートを取り出します。これがフレームワークの機能であり、ビジネス開発者は別のルートを記述するだけで済みます。詳細については、このフレームワークのソース コードおよび作成者のドキュメントを参照してください。6、Zinx マルチルーティングモード
3. znixのいくつかのデザイン
他の機能に関しては、それらはすべて将来のサーバーの拡張またはパフォーマンスの向上のために設計されています。
たとえば、このフレームワークで使用されるワーカー モードと接続属性。
Worker は、実際には一種のコルーチン プールです。
接続属性は、この接続に関する補足情報です。ゲームサーバーとして使用する場合、クライアントはサーバーとの TCP ロング接続を確立します。サーバーは、この接続を ID (ユーザー ID) で識別して、この接続がこのユーザーに属していることを識別できます。
使用は何ですか？たとえば、プレーヤーがオフラインの場合、接続が切断され、サーバーはこのリンクを介してオフラインのユーザーを認識し、オフライン処理を実行できます。
4. まとめ
TCP サーバーのフレームワークを考えてみると、中心的な機能は接続とメッセージの処理で、他は今のところ覚えていないので、後で追加します。