2013-05-24 70 views
5

私のアプリケーションとしてJetty 7を使ってJetty Webソケットを使用しています。Webソケットの切断の理由がわかった

アプリケーションでは、Web Socketを介して1秒ごとにデータが連続的に流れています。また、アプリケーションの設計に従って、ソケットが4分間アイドル状態の場合、ソケットは切断されます。

私たちのアプリケーションでウェブソケット切断が発生しました。ウェブソケット切断理由の原因を調べることができません。これは、ソケットが4分間アイドル状態であるか、ネットワークレベルで何か起こったためです。すべての切断については、ロードバランサ、ファイアウォール--etc)

、桟橋内部理由コード1006(クローム)

として私は切断のための実際の理由が起こったのかを知ることができます教えてください?

ウェブソケットのトラフィックを監視する方法はありますか?

私は、ChromeデバッガーツールのWebsocketタブを使ってトラフィックを監視しようとしましたが、一度切断すると、その時点でWebsocketに存在するデータのクローズはありませんか?

このケースを処理する方法についてアイデアをお伝えください。これは、WebSocketを探す理由を調べる方法です。

答えて

4

1006は異常終了です。場合によっては、 "不完全なハンドシェイク応答"というメッセージでこれを取得します。 TCP MonまたはWiresharkを使用して、ソケットトラフィックを監視し、送信されているヘッダーを調べることができます。

また、サーバーが接続で大きなデータを受信するように設定されていない場合もこれを見てきました。 「接続が閉じられました、ステータス= 1006、理由= EOF」のようなものが表示されます。 Jettyは、サーバーが受信できるメッセージのサイズを制限します。このサイズより大きなメッセージを送信しようとすると、Jettyは接続を終了します。 ConnectionオブジェクトのsetMaxBinaryMessageSizeおよびsetMaxTextMessageSizeを使用して、接続のメッセージサイズ制限を増やすことができます。 http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/websocket/WebSocket.Connection.html

これが役に立ちます。

+0

1006はローカル側のクローズコードです。任意のエンドポイントがWebSocket Closeコントロールフレームで送信してはならない(MUST NOT)。 [RFC-6455 Section 7.4.1](http://tools.ietf.org/html/rfc6455#section-7.4.1)を参照してください。 –

+0

私はクライアント側とサーバ側の接続で大規模なjetty-8クライアントからjetty-9サーバーへのデータメッセージ。サーバー上の最大メッセージサイズを増やすことで修正しました。 – Sanjeev

+0

Jetty 9サーバーは、そのシナリオではステータスコード1009(メッセージが大きすぎます)で応答します。 –

8

Jetty開発者は、WebSocketを使用するときにJetty 9にアップグレードすることを強く推奨します。

桟橋7とのWebSocketドラフトの8つの実装初期のバージョン(開示は、私は、突堤のコミッターだ)、およびお使いのブラウザに応じて、あなたはのWebSocketの大きく異なる動作を取得します。 (7および8は、で動作する桟橋)のWebSocketの事前最終支持体と

ブラウザ

  • サファリ5.xの(またはそれ以前)
  • オペラの12.x(またはそれ以前)
  • Opera Miniは(すべてのバージョン)
  • クロム13.x(またはそれ以前)
  • のFirefox 10.xの(またはそれ以前)
  • IE 9.xの(またはそれ以前)
  • Androidブラウザ(任意のバージョン)
  • ブラックベリーブラウザ(バージョン10以前。x)
  • 既存のShockwave/Flash WebSocketブリッジのいずれか。

Jetty 9以降、WebSocketのドラフト版のサポートはすべて、リリースされたRFC-6455仕様バージョンでの作業に限定されています。

あなたの1006クローズコードの問題。

これはlocal side only close status codeで、Chromeによって報告されています。 あなたのChromeのバージョンによっては、エラー1006の理由が数十の理由がある可能性があります。ほぼすべてが接続やプロトコルの問題に沸きます。

Jetty 7と8では、多くのタイムアウトとアイドルチェックがあります(コネクター、エンドポイントレイヤー、コネクションレイヤー、HTTPレイヤー、さらにWebSocketレイヤー)あなたの方法で取得することができ、厳しく、WebSocketクローズハンドシェイクを起こさずに接続を終了することができます。

これはJetty 9で解決されています。タイムアウト、ハンドシェイク、アイドル時間は2回あります。

問題がプロトコル関連の場合は、エラーコード1006異常/非クリーンターミネーション(ローカル側のみ)または1002プロトコル違反が表示されます。

この時点で、より良いプロトコル、タイムアウト、接続、終了、およびエラー通知でJetty 9にアップグレードすることができます。または、サーバー側のJetty 7/8ですべてのデバッグを有効にして、サーバー側で問題の原因を示すStackTraceが表示されることを期待してください。

関連する問題