Commentsブラウザからの入力文字列を受信するその(1)で作ったサーバは、ハンドシェイクが終わった後、接続を維持します。ブラウザ側もエラーや終了以外でサーバとの接続を切りません。お互いに、どちらが先にでも、自由にデータを送り合える状態となったわけです。それでは、本当にちゃんとお互いにデータがやり取りできるのか、確認してみます。実験として、先ほどのサーバにエコー機能をつけてみましょう。エコーとは、こだまのことで、キーボードで打ったものがそのまま返ってきて画面に反映される仕組みのことです。待てよ、それじゃあブラウザからデータを送信して、サーバから応答をもらうHTTP通信と、やってることが同じじゃないかと思うかも知れません。その通りなんですが、今回は、WebSocketの通信経路を使うことに意味があるので、つまりエコーができれば、その延長線上でプッシュもできるってことで、理解してください。ブラウザからデータを送る仕組みですが、ブラウザにはWebSocketを利用する仕組みがすでに実装されていますから、サーバほど大変ではありません。今回の実験用に以下のようなHTMLファイルを使います。テキストボックスに文字を入力して、「入力」ボタンを押すと、ws.send()が実行されて、サーバへ文字列が送信されます。この文字列データはフレームヘッダが付加されて、以下のような形でサーバに送られます。+---------------------------------------------------------------+ブラウザから入力された文字列を取り出すには、このフレームを分解していかなくてはいけません。各フレームにどんなデータが入っているのか、確認してみましょう。先頭bitにFIN、予約1~3の4bitが取られています。ここは通常、FINのみ1、他は0となっていて、特に予約bitに1を立てるのはNGのようです。少なくとも受信時にここを見る必要はありませんので、無視します。次のopcodeは、送信されたデータの種類です。データの種類には、textやbinaryといったものがあります。今回はテキストボックスに入力された文字列を送っているので、opcodeはtextを表す’1’が入っています。maskは、送信データがマスキング(暗号化)されているかどうかを示すフラグです。ブラウザからの送信データは暗号化されるので、ここは’1’が入っています。payload_lenは、送信データ本体(入力文字列)の長さです。7bitしかないので、127までしか表現できませんが、では127byteまでのデータ長しか送れないのかと言うと、そうではありません。length”を使用するようになります。この場合、payload_len自体の値は127になります。length”を使用しますが、その大きさは16bitにとどまります。この時のpayload_len自体の値は、126です。少なくとも想定上は、最大では64bitの整数値で表現できるだけのデータ長を扱うつもりのようです。FFFFとなり、10進数だと、最大で8,191ペタバイトとなります。書くと、やりすぎだろうとも思うのですが、そうは言っても32bitではたかだか2GBが限界ですし、64bitは時代の流れの上では必然なのかも知れませんね。データ長領域が終わると、maskキーが4byte格納されている領域があります。maskキーとは、送信データを暗号化するために使用されるビット列で、maskフラグが’1’の場合のみ存在します。これはいわゆるバーナム暗号と思われ、暗号化された送信データは、このmaskキーとXORを取ることで復号できます。ここまでで、フレームヘッダは終わりで、以降が入力文字列本体です。maskフラグが’1’の場合はここに対して復号化処理を行い、maskされていない場合は、そのまま入力文字列として扱います。以下、送信されてきたフレームデータから、入力文字列を取り出す処理です。※今回はテストなので、データ長が64bitの場合は上位32bitをバッサリ切り捨てて32bit変数に押し込んでます。コメントをキャンセルメールアドレスが公開されることはありません。InkThemes.。