クライアントにHTML5/JavaScriptを使用し、おそらくサーバーソフトウェアにJavaを使用して、小さなリアルタイムマルチプレイヤーゲームを構築することに興味があります。
WebSocketsを少し調べましたが、WebSocketsが実際に何であるかについて誤解していたようです。私は当初、WebSocketをJavaScriptの処理方法TCPソケット、Javaおよび他の言語で使用されているように、しかし、ハンドシェイクプロセス全体を実行する必要があり、各送信には多くのHTTPオーバーヘッドが含まれます(その場合、Ajaxに対する利点は一見しただけでは刺激的ではありません)。
関連するトピックで、この目的(JavaScriptのリアルタイムマルチプレイヤーゲーム)のためのWebSocketsに代わるより良い代替手段はありますか?
WebSocketは、Webブラウザで実行されるリアルタイムのマルチプレイヤーゲームに最適なソリューションです。コメントで指摘されているように、HTTP接続がアップグレードされる最初のハンドシェイクがありますが、接続が確立されると、WebSocketsはサーバーとクライアント間の双方向通信のための最小遅延接続メカニズムを提供します。
これをご覧になることをお勧めします: https://www.youtube.com/watch?v=_t28OPQlZK4&feature=youtu.be
見て:
唯一の生のTCPソリューションは、ある種のTCPClientオブジェクトをサポートするプラグインを使用することです。WebSocketsを試してみることをお勧めします。
多くのオプションを見つけることができます こちら 。ページ内でWebSocketを検索するだけです。
WebRTC もご覧ください。ゲームの目的と、サーバーがゲームの状態を管理する必要があるかどうかに応じて、この技術をピアツーピア通信に使用できます。プレイヤーをグループに入れるためのソリューションが必要になる場合があります-その場合、WebSocketsは最速/最高のソリューションです。
最近(2017年)リアルタイムマルチプレイヤーをネットワーク化するための最良のツールがWebSocketsであるかどうかはわかりません。 WebRTC は、はるかに高いパフォーマンスの可能性を提供する新しいテクノロジーです。また、最近では、次のライブラリのおかげでWebRTCも使いやすくなっています。
あるいは、ネットワーク実装の実際の詳細を省きたい場合で、より高レベルのマルチプレイヤーインターフェイスを提供するライブラリを探している場合は、 Lance.gg を見てください。 (免責事項:私は貢献者の一人です)。
マルチプレイヤーゲームでは、サーバーが世界の状態の定期的なスナップショットをクライアントに送信する必要があります。ブラウザーのHTML/jsアプリケーションのコンテキストでは、ポーリング、websocket、またはブラウザー機能を拡張するための独自のプラグインを作成するという選択肢はほとんどありません。
[〜#〜] bosh [〜#〜] や Bayeux などのHTTPポーリングは洗練されていますが、ネットワークのオーバーヘッドと待ち時間が発生します。 websocketは、それらの制限を克服するように設計されており、確実に応答性が向上しています。
cometd や socket io などのライブラリは、トランスポートの抽象化を提供し、ブラウザの互換性の問題を解決します。さらに、基礎となるトランスポートを切り替えて、努力なしでパフォーマンスを比較できます。
Socket.ioを使用して マルチプレイヤーアーケードゲーム をコーディングし、通常はWebソケットで2ミリ秒、LANでxhrポーリングで約30ミリ秒の遅延を測定しました。マルチプレイヤーゲームには十分です。
クライアントとサーバー間でコードを共有できるようにするために、 nodejs およびsocket.ioを確認することをお勧めします。また、[]。
基本的に、この記事の執筆時点では3つのオプションがあります。
WebSockets
WebSocketsは、既に説明したように、TCPソケットのJavascript実装ではなく、TCPを使用する軽量のメッセージングプロトコルです。ただし、最初のハンドシェイクを超えて、HTTPヘッダーは渡されません。接続が確立されると、データは最小限のオーバーヘッドで自由に渡されます。
ロングポーリング
簡単に言えば、ロングポーリングでは、クライアントがHTTPリクエストで定期的に新しい情報をサーバーにポーリングします。毎回非常に多くの新しいHTTPヘッダーを送信するため、これはCPUと帯域幅の点で非常に高価です。これは本質的に古いブラウザに関しては唯一のオプションであり、 Socket.io などのライブラリはこれらの場合のフォールバックとしてロングポーリングを使用します。
WebRTC
すでに言及したことに加えて、WebRTCはUDPを介した通信を可能にします。 UDPは、(TCPに比べて)オーバーヘッドが低く、遅延が少なく、ノンブロッキングであるため、非Webベース環境のマルチプレイヤーゲームで長い間使用されてきました。
TCPは、各パケットが到着することを保証し(壊滅的なネットワーク障害のために保存します)、常に送信された順序で到着することを保証します。これは、スコアの登録、ヒット、チャットなどの重要な情報に最適です。
一方、UDPにはそのような保証はありません。パケットは任意の順序で到着することも、まったく到着しないこともあります。これは、高頻度で送信される重要度の低いデータに関して、プレーヤーの位置や入力など、できるだけ早く到着する必要がある場合に実際に役立ちます。理由は、TCP転送中に1つのパケットが遅延すると、ストリームがブロックされ、ゲーム状態の更新に大きなギャップが生じるためです。UDPを使用すると、到着が遅い(またはすべて)、そしてあなたが受け取る次の1つを続けて、プレーヤーのためのよりスムーズな体験を作成します。
この記事の執筆時点では、おそらくWebSocketが最善の策でしょう。ただし、WebRTCの採用は急速に拡大しており、ゲームを終了するまでには実際に望ましい場合があるため、検討する必要があります。
ゲームにJavaScriptを使用する予定がある場合(そのまま)、WebSocketが最適です。また、古いバージョンのInternet Explorerをサポートする場合は、Microsoftが開発したSignal Rシステムについて考えてください。彼らは内部でWebSocketを使用していますが、いくつかのフォールバックオプションもあります...そのため、プロトコルは利用可能な最善のソリューションを使用します。