JavaScript、AJAX、ソケット、Flash / ActionScript-AJAXアプリケーションでのデータ転送の問題の調査

どういうわけか最近、私は積極的に自分のスキルを向上させ始め、新しいテクノロジーに精通するだけでなく、あまり知りません。 たとえば、私はすでに多かれ少なかれJavaをマスターしています。つまり、ネットワークサービスに従事しています。 また、ActionScript 3の使用を開始しましたが、AJAXアプリケーションでのFlashコンポーネントの適用可能性に関する私の意見は変わりません。最大の利点が得られる場合に使用する必要がありますが、ユーザーインターフェイスなどの「バインディング」全体は標準を使用して行うことができますテクノロジー。 AJAXアプリケーションを開発する場合、開発者はサーバーとのデータ交換の問題を解決するのに十分な選択肢があります。 基本的に、サーバーとの通信は...

• ほとんどのアプリケーションは通常のWebページであるため、ページの形成のための初期データを受け取ると、これは通常Webサーバーによって行われます。 このために、PHPなどのアプリケーションサーバーを接続できます。つまり、ページは静的でも動的でもかまいません。
• 仕事用のデータを受信する-たとえば、アプリケーションが既にそれ自体をダウンロードし、グラフィック、スタイル、コードを含む必要なすべてのものをダウンロードしている場合、たとえばメールクライアントに表示される文字のリストなどのデータが要求されています。 ExtJSのアプリケーション（ただし、どのフレームワークも適しています）の場合、データは通常JSONまたはXMLの形式でダウンロードされ、直接コードロードはあまり使用されません（つまり、リクエストに応じて、サーバーはJavaScriptコードを含むHTMLコードを生成し、オプションで、 JSONデータ）。 ちなみに、このアプローチは私でも多くの場合に使用されます。非常に便利です。たとえば、タブ（タブ）を持つインターフェイスがある場合、最初の呼び出し時に各タブのコードを生成し、必要に応じて更新することもできます訪問。 たとえば、これは私のすべての内部情報ブロックがこの方法で形成された私の最後のゲームプロジェクトの基礎でした。
• アプリケーションとサーバー間の定期的なデータ交換（双方向）。 たとえば、これらはユーザーからのコマンドとサーバーによる処理の結果です。 これには常にインターフェイスのオーバーロードが必要というわけではなく、同じ画面内でデータとコマンドのストリームを選択しても、その状態は変わりません。 ここでは、非表示の要素に直接コードを読み込むことができます。 これはまさにそのゲームプロジェクトで私がやったことです-リクエストが定期的にサーバーに送信され、特別なDOM要素が割り当てられました。 、素材はまだ関連しているため、他のバージョンに切り替えてもコンポーネントの変更は最小限です。

このかなり単純な分類に加えて、別のそのような質問を提起したいと思います。 実際、サーバーとの通信のために、JavaScriptで利用可能な最低レベルに、HTTPプロトコルを介して文字列データのみを送信するように適合されたXMLHTTPRequestオブジェクトと、実装の詳細を隠す複数のバインディング、ラッパー、およびアドオンがあります。特定のニーズに合わせて特定のインターフェイスを提供します。 たとえば、同じExtJSで、これに基づいてすべての対話オプションが構築されます-Ext.UpdateとExt.data.Proxyの両方ですが、後者の場合、それほど単純ではありません。 開発者は、XMLHTTPRequestの制限を長い間実現していました（開発経験があれば、どんな制限が関係しているかを知っていると思います）。 クロスドメインの制限を克服するために、ScriptTagProxyなどがあります。 しかし、ブラウザ、HTML、およびJavaScriptの機能のみに基づいて、かなり優れた、安定した、そして最も重要な、生産的で普遍的な通信システムを実装することは依然として非常に困難です。

この問題は、WebSocketが提供されるHTML5仕様 （つまり、通常のJavaScriptを使用してサーバーへのソケット接続の機能を自由に制御できる機能）で根本的に解決を待っています。 しかし、いつそれはまだ...

そして今、そのような機会が必要です！ はい、XMLHTTPRequestを介したアクセスを独自のプロトコルで置き換える（正確に置き換えるのではなく、補足する）ことができます。サーバーシステム用のソケットAPI標準を使用して、文字列データと従来のテキストデータの両方を転送します。

主な違いは、伝送チャネルの連続性とその双方向性です。 つまり、従来の方法で、実際に毎回新しいリクエストを初期化し、接続の確立に時間を費やしている場合（そしてHTTPの場合、Keep-Aliveプロパティには微妙な違いがありますが、全体像にはほとんど影響しません）。 また、各ブラウザの同時リクエストの数は制限されています。 また、多くのアプリケーションでは、開始後に通信チャネルを確立し、常に開いたままにしておく必要があります。 ここで、JavaScriptでネットワークソケットを実装するためのモジュールが役立ちます。

これまで、このようなモジュールを実装するためのいくつかのオプションがあり、最も一般的なものが2つあります。

• JavaFXアプリケーションまたはJavaアプレットを使用します。これらは、インターフェイスを介してJavaScriptモジュールと対話します（Webページに埋め込まれるように設計された各テクノロジーには、それがあります）。
• Flash、 外部インターフェイスを介した通信、不可視のFlashオブジェクトの埋め込み。

技術的に多くの点でJava / JavaFXを介した対話の方法はより強力に見えますが、ネットワークアプリケーションロジックを部分的にクライアント側のアプレットに転送するなど、はるかに多くの可能性がありますが、依然として多くの困難があります。 ただし、初期化に時間がかかるなど、多くの困難がありますが、新しいJavaアプレットアーキテクチャでは無効になっているようです。また、セキュリティおよびクロスドメインポリシーの難しさもあります（ただし、このようなモジュールは潜在的なセキュリティホールであるため、あらゆるテクノロジで使用されています） ところで、情報を収集する過程で、Javaオプションはポリシーファイルを必要としないという事実の説明に出くわしましたが、アプリケーションのjarファイルにはデジタル署名が必要であり、さらに、接続を秘密に初期化することもできません-ユーザーからの確認が必要です。 どちらのテクノロジーでも、バイナリデータとテキストの両方を送信するためのバイナリソケットを実装できますが、これは最近のバージョンでFlashに登場したため、9未満（実際は8ですが、確かではありません）は機能しない可能性があります。

一般的な用語では、タスクは次のとおりです。サーバーへの永続的な接続を実装するためのコンポーネントが必要ですが、直接のTCP / IPまたはUDP接続を使用してHTTPプロトコルを取り除き、任意のホストとポートに接続することもできます さらに、独自のプロトコルを実装し、任意のデータをテキスト形式とバイナリデータの両方で転送でき、接続が一定でなければなりません。つまり、初期化後、ソケットはプログラムまたはサーバーが強制的に閉じるまで、またはページをリロードします。 さて、通常の要件は、接続の確立と維持の最小リソース消費、クロスプラットフォームおよびブラウザ間の互換性、オブジェクトインターフェイス、すべての重要なイベントを管理およびインターセプトする能力です。

私の意見では、Flashの束、ソケット接続を実装するActionScriptの小さなモジュール、および接続を制御してデータを送受信するJavaScriptのラッパーは、これらの条件を完全に満たします。 Flash 9以降では、XMLSocketに加えて、より高度な汎用性とFlash Playerの9番目のバージョン（および現在は10 th）。

もう1つ注意すること-リモートホストとの通信では、特にフラッシュドライブのロード元と同じホストではない場合、また、1024を超えるポートを使用する場合（ここでは間違っている可能性があります、誰かが対象にいる場合は正しい）、このホストには、アクセスポリシーを説明するcrossdomain.xmlファイルがあります（ トピックに関する良い記事 ）。 接続先のホストではなく、接続先のホストに注意してください！ ポリシーファイルは、ポート80または別の843でアクセスできる必要があります。別のポートを提供する独自のソケットサーバーしかない場合、ここで特定の問題が発生する可能性があります。これらのポートをリッスンして追加して、やり直してください。

このようなコンポーネントを自分で作成する必要がありますか？ 原則として、必要な機能が具体的でFlash / ActionScriptをよく知っている場合、そのようなモジュールの作成には数時間かかり、インタラクション用のJavaScriptラッパーの作成とデバッグには同じ量がかかります。 しかし、見てみる価値はありますか、おそらく既製のソリューションがありますか？ しかし、彼らはそうです。

• Cometdesktopは、 Webソケットの実装を使用したExtJSだけに基づいたWebデスクトップ全体の実装です（そこにはExtJSのコンポーネントもあります）が、ネットワークサブシステムはそこで勉強するのに十分興味深いですが、それでも複雑な製品です。少し適しています。
• Cumhurchatは、PHP上のサーバーとネットワークフラッシュモジュールに基づいてチャットを実装するためのアプリケーションですが、これまでのところ、開発者は発表を超えていません。 なんて残念。
• GWTテクノロジーのさまざまなオプション、特にサーバー側の優れた研究も検討されています。 互換性と実装の難しさを学ぶために、理論的な部分だけを読むと便利です。
• jssockets-これはまさに私たちが必要とするものです。 非常に単純なプロジェクトであるAPIは、いくつかの関数とイベントで構成され（結局、相互作用は非同期です）、接続の確立、文字列データの書き込みと読み取り、および接続の管理を行うことができます。 最小限のドキュメントが提案されており、コードはSVNから取得する必要があり、フラッシュモジュールは手動でコンパイルする必要があります。 だから私はもっと開発したものが欲しい...
• jSocketは、Flashソケットベースのネットワーク通信を今日実装するための最良のコンポーネントです！ FlashからJavaScriptへのソケット用の完全なインターフェースを提供するため、私はそれを最高と呼ぶことを恐れません。あらゆるタイプのデータ（文字列、バイト、整数、浮動小数点数、オブジェクトさえ）を読み書きするための関数、すべてのイベントの通知、モジュールを任意のアプリケーションに埋め込みます。 ライブラリの機能は、多くの独立した接続のサポートです-新しいソケットを無期限に作成でき、ライブラリはサービス配列を保持し、各ソケットは一意です（idで識別されますが、すべてが同じSWFファイルを介して実装されます）。 jQueryを使用しますが、ソースコードを見ると、ライブラリに依存するコードには数行しか含まれていないため、必要に応じて別のフレームワークで書き直すことができます。

jSocketには真実があります。1つのニュアンスです。ライブラリはまだアルファバージョンの段階にありますが、完全に動作しますが、1.0リリースバージョンはすでに計画されています。 利用できないアセンブルバージョンを取得するのが最善ですが、 SVNリポジトリに移動してそこからソースを取得します 。 残念ながら、作者は、アルファはAPIのアクセス可能な説明と1つの例を除いて、保証とヘルプを意味しないため、立場を取りました（GTalkで彼をノックしましたが、それが答えでした）。 ところで、必要な場合、SVNにはjSocketとペアリングできる最も単純なJavaネットワークサーバーがあります。 たとえば、 xSocketフレームワーク（Java NIOフレームワーク）に基づいて独自に実装し、クライアント部分でjQueryアダプターと一緒にExtJSを使用しました。この構成では、ライブラリは問題なく機能しました。 APIは非常にシンプルで、機能を説明するページが1つしかないため、サンプルはライブラリの一般的なアプリケーションをカバーしています。したがって、この資料で十分に理解できます。今後、ガイドを作成してみます。独自のプロトコルを作成できるように、サーバー側で何かする必要があります行ベースの交換。

そして、この研究の結果は簡単です。 深刻なAJAXアプリケーションの場合、データを要求し、一定の更新を必要とするクライアントアーキテクチャに複数のポイントがある場合、またはそれらの頻度が比較的小さい場合、XMLHTTPRequest（またはサードパーティフレームワークで利用可能なアドオン）を介した複数の接続のオプションがボトルネックになる可能性があります。

例は次のとおりです。オンラインゲームでは、せいぜい、定期的に動作するデータ更新の要求が3つしかありませんでした。パフォーマンスの問題を回避するために、更新時間間隔を文字通り手動で設定して更新速度を犠牲にする必要がありました（チャットの場合はメッセージのリストを更新するのに3秒かかりましたが、オンラインのリストの場合は7秒、定期的なハートビートリクエスト、プレーヤーのステータスの更新、その他のデータの受信が15秒ごとに行われました ND）。 それでも、このようなスキームは、特にリクエストを生成するユーザーアクションによって重畳される場合、最良の方法では機能しません。

したがって、高速応答とデータ処理が必要な場合は、ソケット接続と特別なサーバーを使用する可能性を真剣に検討する価値があります。

サーバーに関しては、これまでの最良のオプションはJavaサーバーです。PHPはセッションの性質上、すべての利点をほぼ完全に排除し、正しく設計されたJavaサーバーは数千の同時接続を処理できるためです。 このパスに興味がある場合は、 Google Codeの腸内にある別のプロジェクト-GFSサーバー-FlashおよびFlexクライアント用のオープンソースソケットサーバーをご覧ください。 オープンゲームプラットフォームを作成するプロジェクトの一環として、すぐに独自のサーバー（ JBoss Nettyフレームワークに基づくJava）の実装、およびjSocketに基づく単純化されたバージョンのクライアントスクリプトを投稿しますが、サードパーティのライブラリを必要とせずにExtJSを使用するように書き直します。このバンドルの上にあるプロトコルオプションの1つを共有します。