2012年4月14日土曜日

websocketについて再度やってみる。その5(大量のメッセージをおくったときの挙動)

先にred5用のwebSocketプラグインを書いておりましたが、欠陥をみつけました。

内容は
・複数のメッセージをいっきにおくるとおかしくなる。
・長いメッセージを送るとおかしくなる。
の2点です。

まず前者から。
1つ目。javascriptで次のようなコードをかいてみます。
var ws = new WebSocket("ws://localhost:8080/");
ws.send("a");
ws.send("b");

するとサーバーに送られるメッセージは
たとえばhybi00の場合は
0x00 0x61 0xFF 0x00 0x62 0xFF
というパケットが一気に飛んできます。

僕としては
0x00 0x61 0xFFと0x00 0x62 0xFFが別にとんできてほしかった・・・

現状webSocketプラグインに書いてあるプログラムでは、始めの0x00からみつけた0xFFまでしか調査しないので、後者の命令が無視されてしまうという欠点がありました。
rfc6455でも同様です。

前者は単純な問題なので、さくっと直せる予定です。


さて、後者の方ですがこちらは長いメッセージを送ると発生します。こちらは厄介です。
ws.send("[めっちゃ長い文章(略)]");

さてこれがどうなるか・・・です。

まずhybi00の場合
パケットは次のような感じでおくられてきます。
第1パケット 0x00 データバイト〜
第2パケット データバイト続き〜
第nパケット データバイト続き〜 0xFF

なのでパケットデータをすべて連結して取得しないと正しいデータにならないみたいです。

続いてrfc6455の場合
こちらは、そもそも定義されているのですが・・・
そうはならないみたいです。
定義の仕方によると
0x81 ・・・・

0x01 ・・・・
0x01 ・・・・
と、違うデータがある度に分割されて送信されるとおもっていましたが・・・

実際はこうなりました。
0x81 全体の文字列の長さ データバイト〜
データバイト〜
データバイト〜
という形みたいです。

メッセージとしてうけとるデータが必ずしもパケットの先頭にならないという・・・
なんなんですか・・・この仕様は・・・という形になっていました。

今回のhybi00の動作はsafariでrfc6455の動作の確認はchromeのみ確認済みとなります。
両方ともiMac上での話です。

ではでは〜

0 件のコメント:

コメントを投稿