導入

Наза компания 技術を学ぶ 従来のデスクトップ アプリケーションを Web に移植するためのソリューションを提供します。 C++ コンパイラ 歓声 WebAssembly と JavaScript の組み合わせを生成し、両方を提供します。 単純なブラウザ操作、そして高性能。

その応用例として、マルチプレイヤー ゲームを Web に移植することを決定し、 Teeworlds。 Teeworlds は、小規模ながら活発なプレイヤー コミュニティ (私も!) を持つマルチプレイヤー XNUMXD レトロ ゲームです。ダウンロードされるリソースと CPU および GPU の要件の両方の点で小規模であり、理想的な候補です。

Teeworlds ブラウザで実行する

このプロジェクトを使用して実験することにしました ネットワーク コードを Web に移植するための一般的なソリューション。これは通常、次の方法で行われます。

• XMLHttpリクエスト/フェッチネットワーク部分が HTTP リクエストのみで構成されている場合、または
• WebSocketを.

どちらのソリューションもサーバー側でサーバー コンポーネントをホストする必要があり、どちらのソリューションもトランスポート プロトコルとして使用することはできません。 UDP。これは、プロトコル パケットの配信と順序を保証するため、ビデオ会議ソフトウェアやゲームなどのリアルタイム アプリケーションにとって重要です。 TCP 低遅延の妨げになる可能性があります。

XNUMX 番目の方法は、ブラウザからネットワークを使用することです。 WebRTC.

RTCデータチャネル 信頼できる送信と信頼できない送信の両方をサポートし (後者の場合は、可能な限りトランスポート プロトコルとして UDP を使用しようとします)、リモート サーバーとブラウザ間の両方で使用できます。 これは、サーバー コンポーネントを含むアプリケーション全体をブラウザに移植できることを意味します。

ただし、これにはさらなる問題が伴います。XNUMX つの WebRTC ピアが通信するには、接続するために比較的複雑なハンドシェイクを実行する必要があり、これにはいくつかのサードパーティ エンティティ (シグナリング サーバーと XNUMX つ以上のサーバー) が必要です。 スタン/順番).

理想的には、WebRTC を内部的に使用しながら、接続を確立する必要のない UDP ソケット インターフェイスにできるだけ近いネットワーク API を作成したいと考えています。

これにより、複雑な詳細をアプリケーション コードに公開することなく、WebRTC を活用できるようになります (プロジェクトではできるだけ変更を少なくしたかったのです)。

最小 WebRTC

WebRTC は、オーディオ、ビデオ、および任意のデータのピアツーピア送信を提供する、ブラウザーで使用できる API のセットです。

ピア間の接続は、ICE と呼ばれるメカニズムを通じて STUN サーバーや TURN サーバーを使用して (片側または両側に NAT がある場合でも) 確立されます。ピアは、SDP プロトコルのオファーとアンサーを介して ICE 情報とチャネル パラメーターを交換します。

おお！一度にいくつの略語を使用できますか?これらの用語の意味を簡単に説明しましょう。

• NAT用のセッショントラバーサルユーティリティ (スタン) — NAT をバイパスし、ホストと直接データを交換するためのペア (IP、ポート) を取得するためのプロトコル。彼がタスクをなんとか完了できれば、ピアは独立して相互にデータを交換できます。
• NAT 周囲のリレーを使用したトラバーサル (順番) は NAT トラバーサルにも使用されますが、両方のピアから見えるプロキシを介してデータを転送することによってこれを実装します。遅延が追加され、STUN よりも実装コストが高くなります (通信セッション全体に適用されるため) が、場合によってはこれが唯一のオプションになります。
• インタラクティブ接続の確立 (ICE) ピアを直接接続することで得られる情報と、任意の数の STUN および TURN サーバーから受信した情報に基づいて、XNUMX つのピアを接続する最適な方法を選択するために使用されます。
• セッション記述プロトコル (SDP) 接続チャネル パラメータを記述するための形式です。たとえば、ICE 候補、マルチメディア コーデック (オーディオ/ビデオ チャネルの場合) などです。一方のピアが SDP オファーを送信し、もう一方のピアが SDP アンサーで応答します。 . .この後、チャネルが作成されます。

このような接続を作成するには、ピアは STUN サーバーと TURN サーバーから受信した情報を収集し、それを相互に交換する必要があります。

問題は、直接通信する機能がまだないことです。そのため、このデータを交換するには帯域外メカニズム、つまりシグナリング サーバーが存在する必要があります。

シグナリング サーバーは、(下の図に示すように) ハンドシェイク フェーズでピア間でデータを転送することだけが仕事であるため、非常に単純になります。

簡略化された WebRTC ハンドシェイク シーケンス図

Teeworlds ネットワーク モデルの概要

Teeworlds のネットワーク アーキテクチャは非常にシンプルです。

• クライアント コンポーネントとサーバー コンポーネントは XNUMX つの異なるプログラムです。
• クライアントは、複数のサーバーの XNUMX つに接続してゲームに参加します。各サーバーは一度に XNUMX つのゲームのみをホストします。
• ゲーム内のすべてのデータ転送はサーバー経由で行われます。
• 特別なマスター サーバーは、ゲーム クライアントに表示されるすべてのパブリック サーバーのリストを収集するために使用されます。

データ交換に WebRTC を使用することで、ゲームのサーバー コンポーネントをクライアントが存在するブラウザに転送できます。これは私たちに素晴らしい機会を与えてくれます...

サーバーを取り除く

サーバー ロジックがないことには素晴らしい利点があります。アプリケーション全体を静的コンテンツとして Github Pages または Cloudflare の背後にある独自のハードウェアにデプロイできるため、無料で高速ダウンロードと高い稼働時間を確保できます。実際、私たちはそれらを忘れることができ、運が良ければゲームが人気になれば、インフラストラクチャを最新化する必要はありません。

ただし、システムが動作するには、引き続き外部アーキテクチャを使用する必要があります。

• XNUMX つ以上の STUN サーバー: いくつかの無料オプションから選択できます。
• 少なくとも 2 つの TURN サーバー: ここには無料のオプションはないため、独自にセットアップするか、サービス料金を支払うかのいずれかになります。幸いなことに、ほとんどの場合、接続は STUN サーバー経由で確立できます (そして真の pXNUMXp を提供します) が、フォールバック オプションとして TURN が必要です。
• シグナリング サーバー: 他の XNUMX つの側面とは異なり、シグナリングは標準化されていません。シグナリング サーバーが実際に何を担当するかは、アプリケーションによって多少異なります。この例では、接続を確立する前に少量のデータを交換する必要があります。
• Teeworlds マスター サーバー: 他のサーバーがその存在を宣伝したり、クライアントがパブリック サーバーを検索したりするために使用されます。これは必須ではありませんが (クライアントはいつでも知っているサーバーに手動で接続できます)、プレイヤーがランダムな人々とゲームに参加できるようにするためにあれば便利です。

私たちは Google の無料 STUN サーバーを使用することに決め、自分たちで XNUMX 台の TURN サーバーをデプロイしました。

最後の XNUMX つのポイントに使用したのは、 ファイアベース:

• Teeworlds マスター サーバーは、各アクティブ サーバーの情報 (名前、IP、マップ、モードなど) を含むオブジェクトのリストとして非常に簡単に実装されます。サーバーは独自のオブジェクトを公開および更新し、クライアントはリスト全体を取得してプレーヤーに表示します。また、ホームページにリストを HTML として表示するので、プレーヤーはサーバーをクリックするだけで、直接ゲームに移動できます。
• シグナリングは、次のセクションで説明するソケットの実装と密接に関連しています。

ゲーム内およびホームページ上のサーバーのリスト

ソケットの実装

必要な変更の数を最小限に抑えるために、可能な限り Posix UDP ソケットに近い API を作成したいと考えています。

また、ネットワーク上での最も単純なデータ交換に必要な最小限の機能も実装したいと考えています。

たとえば、実際のルーティングは必要ありません。すべてのピアは、特定の Firebase データベース インスタンスに関連付けられた同じ「仮想 LAN」上にあります。

したがって、一意の IP アドレスは必要ありません。ピアを一意に識別するには、一意の Firebase キー値（ドメイン名と同様）で十分であり、各ピアは、変換する必要がある各キーに「偽の」IP アドレスをローカルに割り当てます。これにより、簡単ではないタスクであるグローバル IP アドレスの割り当てが完全に不要になります。

実装する必要がある最小限の API は次のとおりです。

// Create and destroy a socket
int socket();
int close(int fd);
// Bind a socket to a port, and publish it on Firebase
int bind(int fd, AddrInfo* addr);
// Send a packet. This lazily create a WebRTC connection to the 
// peer when necessary
int sendto(int fd, uint8_t* buf, int len, const AddrInfo* addr);
// Receive the packets destined to this socket
int recvfrom(int fd, uint8_t* buf, int len, AddrInfo* addr);
// Be notified when new packets arrived
int recvCallback(Callback cb);
// Obtain a local ip address for this peer key
uint32_t resolve(client::String* key);
// Get the peer key for this ip
String* reverseResolve(uint32_t addr);
// Get the local peer key
String* local_key();
// Initialize the library with the given Firebase database and 
// WebRTc connection options
void init(client::FirebaseConfig* fb, client::RTCConfiguration* ice);

API はシンプルで Posix Sockets API に似ていますが、いくつかの重要な違いがあります。 コールバックのログ記録、ローカル IP の割り当て、遅延接続.

コールバックの登録

元のプログラムがノンブロッキング I/O を使用している場合でも、Web ブラウザーで実行するにはコードをリファクタリングする必要があります。

その理由は、ブラウザーのイベント ループがプログラム (JavaScript または WebAssembly) から隠蔽されているためです。

ネイティブ環境では次のようなコードを書くことができます

while(running) {
  select(...); // wait for I/O events
  while(true) {
    int r = readfrom(...); // try to read
    if (r < 0 && errno == EWOULDBLOCK) // no more data available
      break;
    ...
  }
  ...
}

イベント ループが隠されている場合は、次のようなものに変える必要があります。

auto cb = []() { // this will be called when new data is available
  while(true) {
    int r = readfrom(...); // try to read
    if (r < 0 && errno == EWOULDBLOCK) // no more data available
      break;
    ...
  }
  ...
};
recvCallback(cb); // register the callback

ローカルIPの割り当て

「ネットワーク」のノード ID は IP アドレスではなく、Firebase キーです (次のような文字列です: -LmEC50PYZLCiCP-vqde ).

これは、IP の割り当てとその一意性の確認 (およびクライアントの切断後に破棄する) のメカニズムが必要ないため便利ですが、多くの場合、ピアを数値で識別する必要があります。

これはまさに関数が使用される目的です。 resolve и reverseResolve: アプリケーションは何らかの方法で (ユーザー入力またはマスターサーバー経由で) キーの文字列値を受け取り、それを内部使用のために IP アドレスに変換できます。 API の残りの部分も、簡素化のために文字列の代わりにこの値を受け取ります。

これは DNS ルックアップに似ていますが、クライアント上でローカルに実行されます。

つまり、異なるクライアント間で IP アドレスを共有することはできず、何らかのグローバル識別子が必要な場合は、別の方法で生成する必要があります。

遅延接続

UDP には接続は必要ありませんが、これまで見てきたように、WebRTC では XNUMX つのピア間でデータの転送を開始する前に、長い接続プロセスが必要です。

同じレベルの抽象化を提供したい場合は、(sendto/recvfrom 事前接続のない任意のピアとの接続）の場合、API 内で「遅延」（遅延）接続を実行する必要があります。

これは、UDP を使用する場合の「サーバー」と「クライアント」間の通常の通信中に何が起こるか、そして私たちのライブラリが行うべきことです。

• サーバー呼び出し bind()指定されたポートでパケットを受信したいことをオペレーティング システムに伝えます。

代わりに、サーバー キーの下で開いているポートを Firebase に公開し、そのサブツリーでイベントをリッスンします。

• サーバー呼び出し recvfrom()、このポート上の任意のホストからのパケットを受け入れます。

この例では、このポートに送信されたパケットの受信キューをチェックする必要があります。

各ポートには独自のキューがあり、送信元ポートと宛先ポートを WebRTC データグラムの先頭に追加して、新しいパケットが到着したときにどのキューに転送するかを把握できるようにします。

この呼び出しはノンブロッキングであるため、パケットがない場合は、単純に -1 を返して設定します。 errno=EWOULDBLOCK.

• クライアントは何らかの外部手段でサーバーの IP とポートを受け取り、呼び出します。 sendto()。これにより内部呼び出しも行われます。 bind()したがって、その後の recvfrom() 明示的にバインドを実行せずに応答を受け取ります。

この場合、クライアントは外部から文字列キーを受け取り、関数を使用します。 resolve() IPアドレスを取得します。

この時点で、XNUMX つのピアがまだ相互に接続されていない場合は、WebRTC ハンドシェイクを開始します。同じピアの異なるポートへの接続は、同じ WebRTC DataChannel を使用します。

間接的な施術も行っております bind()サーバーが次回再接続できるようにするため sendto() 何らかの理由で閉店した場合に備えて。

クライアントが Firebase のサーバー ポート情報に SDP オファーを書き込むと、サーバーはクライアントの接続を通知され、サーバーはそこに応答を返します。

以下の図は、ソケット スキームのメッセージ フローの例と、クライアントからサーバーへの最初のメッセージの送信を示しています。

クライアントとサーバー間の接続フェーズの完全な図

まとめ

ここまで読んだ方は、おそらく理論が実際に動作する様子を見ることに興味があるでしょう。ゲームは以下でプレイできます teeworlds.leaningtech.com、 それを試してみてください！

同僚同士の親善試合

ネットワーク ライブラリ コードは次の場所から無料で入手できます。 githubの。私たちのチャンネルでの会話に参加してください グリッド!

出所： habr.com