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上での話です。

ではでは〜

2012年4月12日木曜日

websocketについて再度やってみる。その5

jsdo.itにwebSocketを利用したチャットプログラムをぱぱっとおいてあります。
http://jsdo.it/poepoemix/rVsV こんな感じ

んで、本日1日webSocketの挙動、特に3Gではどうなるだの、裏で起動しておくとどうなるだのといったことを調べたのでブログに残しておきます。

利用したのは、手持ちのiPhone4S端末。キャリアはAUです。

まずは3Gの動作について。
・特に問題ありませんでした。3GでもそのままwebSocketはつながるし、問題なくデータのやり取りができました。
・Wifi環境から3G環境に切り替わったときにどうなるかは不明です。

続いてバックグラウンド実行等の話。
・普通にsafariでwebSocketに接続したまま、他のアプリをつかったり、他のタブにいっても、接続が落ちることはありませんでした。
この状態の場合は、webSocketはつながったまま通信をしているようですがjavascript自体は動作せず。バッファがたまっていくみたいな印象でした。
そしてページにもどってきたら、いままでのデータがいっきに吐き出されるといった感じ
このバッファがたまりすぎると、戻ったときにページのリロードがはしってしまうようです。

・続いてスリープ状態にした場合。この場合はwebSocketはいったん切れるみたいです。

最期に、ずっと接続したまま放置したらどうなるか・・・
Safari系はnight build以外では、hybi00で動作するみたいです。
このモードでは、pingについての記述がありません。なので、接続はidle状態になるものと思われます。
僕のつくったRed5のWebSocketプラグインでは、通信がまったくない場合は切断されるようになっているので、ほっとくといつの間にか接続がおちるみたいです。

回避したい場合は、intervalあたりをつかって一定時間ごとに適当なダミーメッセージを送る必要があるとおもいます。
なお、この切れる動作ですが、oncloseのイベントを監視しているのですが、イベントが走らずにきれることがあるみたいです。裏にまわっていて、jsが動作しなかった?疑惑がありますが・・・

rfc6455の方ではpingとpongが定義されているので、ブラウザが勝手に通信してくれるかもしれませんね。調査はしていませんけど・・・

以上、今日調べた結果です。

2012年4月10日火曜日

websocketについて再度やってみる。その4

jsdo.itにwebSocketをつかってテキストチャットをするプログラムをかいてみました。

http://jsdo.it/poepoemix/rVsV

で、やってみてわかったのですが、safari用のhybi00のwebSocketのハンドシェイクが、まだまちがっていたみたいですね。

githubのソースコードかえておきました。

Handshakeの応答データにSec-WebSocket-Locationというのがあるのですが、この応答値と、接続に利用する接続が一致しないと、接続できないのですが、httpでいうところのクエリーの区切り文字が混入して食い違うみたいでした・・・

さっそく直して動作確認しました。

red5で書いてあるから、jsdo.itとwonderFlでデータを共有なんてことしたら、面白いかなw

2012年4月4日水曜日

websocketについて再度やってみる。その3

いろいろいじった結果、red5用のプラグインという形で動作するようになりました。
https://github.com/taktod/webSocketForRed5/tree/master/doc

いつものとおり動作デモも作成してみたので、よかったらためしてみてください。
http://websocket.org/echo.html
このサイトにいく。
ws://49.212.39.17:8080/testにつなぐ。
つながったら適当なメッセージを送る。
同じパスに接続を増やしていくと、同じパス同士メッセージデータを共有できる。
いまのところ、接続元の確認等は、やってません。

これでFlashとWebSocketで同じ内容を共有したりもできるかな。
では、あとは、Webアプリつくってみようかでjqmobiのプログラムで組んでみよう。