同僚、ようこそ。 私の考えとプロジェクトの実施のいくつかの側面を公開討論に持ち込みたいです。 Websocketsはおそらくハックされたトピックですが、Andrii Sergiienkoによる「WebRTCクックブック」に刺激を受けました。これは、ストリーミングデータを管理するためのシグナリングサービスとしてWebsocketsテクノロジーを使用しています。
純粋な形式では、Websocketsプロトコルにはデータを多重化できるものは含まれていません。 Websocketsサービスは、異なるプロジェクトの多くのクライアントを同時に接続できます。 だから、さまざまなプラットフォーム、サービス、サイトなどに完全に活用されたアプローチが欲しい
上記の本には例が付属しています。 それらの1つは、JavaでのWebsocketsサービスの実装であり、データはチャットルーム番号によって多重化されます。 部屋番号（または名前）は、アプリケーションプログラマによって割り当てられます。 これを明確な欠点としてすぐに指摘したくありません。 すべて同じですが、これはトレーニングプロジェクトです。 私のプロジェクトでは、次の要件を設定したとしか言えません。
- 独立したプロジェクトに1つのメッセージ配信サービスを使用する機能があります。
- グループメッセージングと特定のアプリケーション接続を介したデータ配信の両方を行うため。
- 1つのIPアドレスからの接続数を制御する機能に影響します。
このようなサービスのデータ暗号化と信頼性に関する質問は、おそらくまだ提起されていない可能性があります。 すべて同じですが、これは別のサブジェクト領域からのビットです。
では、何が提案され、何が実装されていますか？ 次の図は、このようなサービススキームを提案しています。
図は、次の対話参加者を示しています。
- ネットワーク上のイベントのさまざまなソース。
- ソースからこれらのイベントを受信、蓄積、処理するHTTPサーバー。
- Websocketsサービス。情報消費者へのオンライン通知に使用されます。 このサービス自体に加えて、さまざまなプロジェクトから構造化された情報をブロードキャストする「your」HTTPサーバーとの統合も必要です。
- これらは実際にはクライアントであり、さまざまなソースからの処理された情報の受信者です1。
サービスとのメッセージング用にデータを何らかの形で整理するために、JSON形式を選択することをお勧めします。 この選択は、JSON文字列、さまざまなライブラリ、およびさまざまなプラットフォームへの移植性を簡単に操作できるためです。
{ "WSCI_TYPE" : "WSCI_REG", "WSCI_ID" : "bqOPfKmKCPV … zJS2LqtFang" }
WSCI_TYPE-受信したメッセージのタイプ。 この場合、WSCI_REGは、これが接続識別子またはトークンがWSCI_IDパラメーターを介して送信される登録メッセージであることを意味します。 アプリケーションは、このキーをサービスの他のユーザーと「共有」します。 キーは、データベースまたはさまざまなサービスの他のユーザーの共有リストに書き込むことができます。 同様の動作原理がGoogleから借用されたことに注意します。 GCMサービス（
Google Clouds Messaging ）があります。
次のメッセージタイプはWSCI_DATAです。 実際のユーザーデータを転送します。 次のようになります。
{ "WSCI_TYPE" : "WSCI_DATA", "WSCI_DATA" : “ ” }
別のタイプのメッセージは、ユーザーサーバー（2）とWebSocketsサービス（3）の間で送信されます。形式は次のとおりです。
{ "WSCI_ARRAY" : [ ( )], "WSCI_DATA" : " " }
例：
{ “WSCI_ARRAY”:[“d97I.....r2Oo”, “o7yz....tIu7”], “WSCI_DATA”:”This is your data” }
WSCI_ARRAY配列には、接続識別子（トークン）のリストが含まれています。 PHPでは、このようなメッセージの形成は次のとおりです。
$testJSON = array( 'WSCI_ARRAY'=>array( "d97I....r2Oo", "o7yz....MtIu7" ), WSCI_DATA'=>'This is a data for service.' );
サイトからWebsocketsサービスにデータを転送するには、次のリストで表されるクラスを使用できます。
define('WSCI_SERVICE', "http://95.47.161.69/wsci.php"); class WsciCurl { function __construct(){} function __destruct(){}
次のテキストは、ユーザーデータのサービスへの転送を示しています。
require_once('wsci_curl.php'); $wsci_array = array( "d97ICUblJKsOBH2YmWJqf0WU8Z9IaMemutFNLH8adFuFkXKmAe0ze3zlptSr2Oo", "o7yzZjIp1tcoaREUBG8h4XObLTbTykMk2zSFSJ2TFEA5qV0a4Vt1g0Hno3MtIu7" ); $wsci_data = 'This is a data for service.'; $wsci = new WsciCurl(); $wsci->SendDataToWSCI($wsci_array, $wsci_data);
$ wsci_array配列には、データの送信先となる接続トークンが含まれています。
クライアント側のイベントハンドラーの例（4）として、次のJavaScriptコードフラグメントを提案できます。
var wsUrl = "ws://95.47.161.69:12080";
次にノード（3）を検討し、ここで何が起こっているかを分析します。 リスト1に注目すると、wsci.phpモジュールがこのサービスへのエントリーポイントであり、ユーザーデータを受信するように設計されていることがわかります（明確にするために、HTTP経由で受信されます）。 モジュールのテキストは次のとおりです。
<?php define('WSCI_SERVER', "127.0.0.1"); define('WSCI_PORT', 12080); require_once('wsci_client.php'); ini_set('display_errors', 1); error_reporting(E_ALL);
リスト3.ユーザーデータをWebソケットサービスに変換するモジュールWebsocketsサービスで何をどのように行うべきかを検討してください。 まず、顧客とのやり取りのプロトコルを決定する必要があります。 私は間違っているかもしれませんが、現在確立されている標準はRFC_6455です。 第二に、最小レベルのサービス機能。 サービスは次の一連の機能を実行する必要があるようです（これが実装されています）。
- クライアントとの接続、1つのIPアドレスからの量の制御による接続のリストのサポート。
- キー（トークン、識別子）で必要な接続を検索し、この接続にユーザーデータをプッシュします。
- 「ハング」接続を検索して閉じます。
- 顧客からのデータの受信は、リスト1に示され、実装されている仕様に従う必要があります。
- クライアントデータの解析では、トークンのリスト（配列WSCI_ARRAY）とデータ自体（ノードWSCI_DATA）を取得します。
サービスの直接実装開発とデバッグの前に、既製のソリューションの検索と分析、および独自の目的での使用の可能性に関する研究が行われました。 たとえば、JavaScriptでの実装の完全にエキゾチックなバージョンがありました。 良い例は、エコー制御がプログラムされたPHP実装です。 Javaには、既製の良い例がたくさんあります。 Apacheに統合されるWebsocketsモジュールのバリアントがあります。 しかし、単純な方法を探していないため、C ++の開発オプションが選択されました。 デバッグは難しく、面倒で、面倒ですが、それでもこのオプションは次の理由で選択されました。
- アプリケーションの速度。 同じアルゴリズムを使用すると、たとえばJavaアプリケーションよりもブートモジュールの動作が約40倍速くなります（これは私の評価ではありません）。 多数の化合物を処理するにはパフォーマンスが重要です。
- 並列ソフトウェアデータ処理スレッドを使用する機能。
実装におけるいくつかの問題と困難アプリケーションを設計するときは、常に生活の現実を考慮し、環境の制限、機器のパフォーマンス、オペレーティングシステムの機能、通信チャネルの帯域幅などを考慮する必要があります。 だから、VDSでのホスティングを考慮に入れた接続の最大数について、皆さんの意見を聞きたいと思います。 現時点では、サービスの負荷は最小限であり、100の位置が接続の配列に割り当てられています。 サービスは、たとえば10,000接続で正常に機能しますか？ 誰もがそのような経験を持っていますか？
これで、接続のキー（トークン）のサイズが決まりました。 私の知る限り、GoogleのGCMサービスのトークン長は256バイトです。 問題は、これはどの程度正当化されるのかということです このような長いキーは冗長ですか？ 実際、多数の接続では、キーによる特定の接続の検索に時間がかかる場合があります。 繰り返しますが、これらのオブジェクトをキーでソートします。 念のため、キーサイズは64バイトです。
サービスの要件のリストに追加できるもう1つのポイントは、アプリケーションをデーモンとして実装し、オペレーティングシステムを自動ロードするように設定することです。 これにより、サービスの全体的な信頼性が向上し、後続の操作中にボトルネックを特定できます。
見込み「クラウド」を作成できます。 もちろん、経済面では、IT業界の「モンスター」と競合することは現実的ではありません。 原則として実装の可能性を考慮しただけです。
実装例以下は、サービスの簡単な使用の例と説明です。そして、これはプロトタイプのビデオチャットです。
Androidの実装オプションもあります。