Socket.io: アップグレード後の原因不明の切断「トランスポート終了」

0.9.1は、ハートビートが時期尚早の切断をトリガーするバグを導入した可能性があります。
私はそれを調べています、そして明日は0.9.2になるかもしれません

同上。 MacのChromeとFF、同じマシンのクライアントとサーバーで切断/再接続が繰り返されるのを確認します。
readmeのsocket.ioの例から簡単にわかりますが、デフォルト設定は変更されていません。

同じ問題があります...ソケットが切断された直後に、新しいソケットがインスタンス化されたことにも気づきました。

私の回避策は、クローズタイムアウトを手動で設定することでした。

io.configure( function() {
    io.set('close timeout', 60*60*24); // 24h time out
});

私もこの問題を抱えていました。 回避策を提供してくれたsteffenwtに感謝します。

はい、私にもこのエラーがあります。 私は数日前にsocket.ioを学び始めましたが、最初は何か間違ったことをしていると思いました。

0.9.0へのダウングレードは機能します。

関連するかどうかはわかりませんが、ソケットは1つおきのハートビートで閉じられます。 だからこのようになります

heartbeat2 gets sent and recieved all fine
heartbeat3 gets sens but never gets recieved
disconnect

ここにログイン：

   debug - emitting heartbeat for client 18615332192056708826
   debug - websocket writing 2::
   debug - set heartbeat timeout for client 18615332192056708826
   info  - transport end
   debug - set close timeout for client 18615332192056708826
   debug - cleared close timeout for client 18615332192056708826
   debug - cleared heartbeat timeout for client 18615332192056708826
   debug - discarding transport

私も問題があります。

0.91-1を使用します。

試してみましたが、問題があります。

io.configure（function（）{
io.set（ 'close timeout'、60_60_24）; // 24時間タイムアウト
}）;

ここで同じ問題

0.9.0にダウングレードしましたか？ NPMで最新のマークを付けました

ここで同じ問題が0.9.1-1で発生し、ちょうど0.9.0にダウングレードされ、問題は解消されました。

回避策として、クライアントからいくつかのキープアライブを送信し、たとえば20秒間、サーバーからそれらにすぐに応答することができます。

クライアント：setInterval（function（）{socket.emit（ "keep-alive"、null）}、20 * 1000）;
サーバー：socket.on（ 'keep-alive'、function（data）{socket.emit（ 'keep-alive'、null）;}）;

FWIW：別のサーバーからクライアントにサービスを提供していて、クライアントコードが0.9.0にダウングレードされていない場合でも、問題が発生します。

'socket.io'を0.9.0にダウングレードしましたが、それでも問題が発生しました。 次に、socket.io-clientを0.9.0にダウングレードしましたが、切断されません。

また、私が試した失敗したトランスポートは、Webソケットとxhrポーリングです。

この問題は解決されるべきですよね？

私も同じ問題を抱えてる。 しかし、私はhaproxyを持っているからだと気づきました。

私の問題はここにあります：

frontend all 0.0.0.0:80
    default_backend www_backend
    acl is_websocket path_beg /socket.io
    acl is_websocket hdr(Upgrade) -i WebSocket
    acl is_websocket hdr_beg(Host) -i ws
    timeout client 1000

「timeoutclient1000」の行にあります（問題があるかどうかを確認するために1秒に変更しましたが、問題がありました...）。

だから今、私はWebSocketバックエンドに対してのみそれを変更する方法があるかどうかを探しています。

私はこれが誰かを助けることを願っています：+1：

参考までに、xhr-pollingと0.9.14で、この問題もまだ発生しています。 25秒ごとに強制的に切断されます。 ログは上記と同じです。

また、これが0.9.14サーバーと0.9クライアントで発生していることを確認できます。 25秒ごとに切断されるわけではありませんが、断続的に切断されます。 私はそれを呼び出しstream.emit（ 'end'）;にトレースしました。 node.jsの_stream_readable.jsにあります。 バッファ内のEOFを読み取った結果だと思います。

@citosidなぜhaproxyクライアントのタイムアウトがこれを引き起こすのでしょうか？

0.9.16で起こっています。 BoarKと同じです

socket.ioサポートは無効ですか？

@joefaron死ぬ前にサポートが必要です。 つまり、Socket.IOのサポートは完全ではなく、存在しなかっただけです。

Socket.io 0.9.16の同じ問題-接続が約25秒ごとにドロップし、同時に「トランスポートの破棄」を示すログが表示されます。

0.8.6にダウングレードすると、基本的にすべてが修正されました。
websocketへのバックアップとしてxhr-pollingの代わりにjsonp-polling ..は遠いようです
より安定した。

10:16の日、2014年1月26日には、アランにおい[email protected] ：

Socket.io0.9.16の同じ問題-接続が約25ごとにドロップするのを確認する
秒と「トランスポートの破棄」を同時に示すログ。

—
このメールに直接返信するか、Gi tHubhttps：//github.com/LearnBoost/socket.io/issues/777#issuecomment-33325205で表示してください
。

こんにちは@joefaron 、あなたの助けを応援します。

私は今晩さまざまな設定オプションで少し遊んでいて、明日それをさらに調べますが、問題はハートビートチェックが失敗することであることが確認できます。 これらのチェックは、ユーザーへの接続が引き続き必要であり、何らかの理由で切断を送信せずにユーザーが離れていないことを確認するために実施されます。

FirefoxとChromeの現在の安定したビルド（32.0.1700.76 m）の両方でこのバグを再現することができました。

最初は、ハートビートを完全に無効にしようとしましたが、アプリケーションでは実際には必要ありませんでした。これは次のように実行できます（現在のドキュメントによると、これを試したところ、すべてのトランスポートメソッドが削除されたようで、常に終了しました。クラッシュして再起動します）。
io.set('heartbeats', false);

これが失敗したので、私の次の試みは、app.js内で以下を使用して実行できるハートビート要求間のタイムアウトを増やすことでした。
io.set('heartbeat timeout', 99999); // 99999 being the time between requests in seconds - Default is 25, please choose your value as applicable for your applications

クライアントの切断を気にしないので、これは私たちのアプリケーションにとっては扱いになりましたが、これはあなたの環境では実行可能なオプションではないかもしれません。

それが役立つ場合に備えて、この問題を抱えている他の人にとって、私の環境は次のとおりです。
NodeJS: v0.10.24 Socket.io: v0.9.16 Centos 6.5

これは本当に緊急/重大な問題だと思います。 なぜまだ解決されていないのですか？ この号のスレッドが始まってから2年が経過しました。

私もこの問題を経験しています：

NodeJS: v0.10.24
Socket.io: v0.9.16

d-oliveros：0.8.6にダウングレードすることを強くお勧めします。 私はこれを持っていません
問題..そして私は最新のビルドが近い将来修正されるとは思わない。

午前八時55分PMに土、2014年2月15日には、D-オリベ[email protected] ：

これは本当に緊急/重大な問題だと思います。 なぜそうではなかったのですか
まだ解決しましたか？ この号のスレッドが始まってから2年が経過しました。

私もこの問題を経験しています：

NodeJS：v0.10.24
Socket.io：v0.9.16

このメールに直接返信するか、Gi tHubhttps：//github.com/LearnBoost/socket.io/issues/777#issuecomment-35177466で表示してください
。

新しいmaster試してください。この問題はなくなりました。

この問題の修正を含む0.9.17リリースはありますか？

@fgnass 1.0.0-pre再現できますか？

@guilleはこれまでのところよさそうです！ また発生した場合はお知らせします。

こんにちは@guilleこの修正を0.9.16に導入する方法はありますか？ 十分に確立された本番環境でnode.js / socket.ioを使用しているというだけで、プラットフォームのあらゆる側面のプレリリースバージョンを使用することを正当化するのに苦労します。 0.9.16のパッチを実行できる場合、または1.0.0が（非常に）近い将来にリリースされる予定の場合は、これがはるかに望ましいでしょう。

@eggysplatの+1

@ aran112000 heartbeat timeout回避策に感謝します。 v0.9.16で動作します。

実際、私はこの問題を抱えた理由を見つけました。 非常に恥ずかしいことですが、実際にはそのバグのあるv0.9.0を使用していたのに、v0.9.16を使用していると思いました。 これは、v0.9.2でhttps://github.com/LearnBoost/socket.io/commit/57a0b2406004e46ec34729392ee289191a4f78e7およびhttps://github.com/LearnBoost/socket.io/commit/df5f23d3091df3bbf296ae952609dfbbc7be28c3によって修正されました

v0.9.0の場合のように、 heartbeat intervalがheartbeat timeoutより大きくならないようにしてください。

他の人に気付かれるように投稿を編集する：

Macで問題をテストすることを決定するまで、数時間のバグ追跡を無駄にしました。 Windows 8のアンチウイルスも接続をブロックし、物事をドロップさせていたようです。 それをアンインストールした後、すべてが正常に動作します。

関連する投稿は実際にはここにありますが、見つけるのは非常に困難です。
https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software

私はsocket.ioの初心者で、2日以上かかりました。 データの送受信後、クライアントは切断して再接続するため、socket.idの値が変更されます

socket.io:client client close with reason transport close +39s
socket.io:socket closing socket - reason transport close +44s
.
.
.
socket.io:namespace adding socket to nsp / +4.1m
socket.io:socket socket connected - writing packet +1s

最後に、コールバック内に例外があることがわかりました。そのため、socket.ioはシステムからサイレントに切断して再接続します。

socket.on('someEvent', function(){
    var a = null;
    a.b; //You won't be aware of this error, this error is suppressed and won't be shown on console. 
         //Moreover, it disconnects and reconnects
})

このコメントも参照してください

そのため、サイレントにエラーをキャッチし、コンソールに何も表示されません。 なぜそれは私に通知することさえせずにエラーを抑制し、切断/再接続するのですか？

1.3.5エラーはまだあります

それは...ですか？

はい、問題はまだ1.3.5に存在します...

問題はまだ存在します

はい、問題はまだ1.3.5で発生しています。修正してください

@citosidが指摘しているように、これはhaproxyクライアントのタイムアウトの問題だと思います。 WebSocketバックエンドのhaproxyクライアントタイムアウトを増やすと、この問題は修正されるはずです。

同じ問題がありますが、haproxyを使用していません。 これが機能していた最後のバージョンを知っている人はいますか？

さて、私はまた、問題が私たちのシステムで100％修正されていないという報告を受けています。 面白いことに、haproxyの「timeoutclient 1」を1秒に設定することで問題を確実に再現でき、フロントエンドでバグを経験できました。

これに促されて、「タイムアウトクライアント」をより多くの数に増やし、socket.ioキープアライブ/ハートビートに接続を更新するのに十分な時間がかかるため、問題がなくなると考えました。 この仮定はおそらく間違っているので、もっと多くのことを見つけたら、皆さんに投稿し続けます。

私はこれをstackoverflowの投稿に投稿しましたが、一部の人にとってはこれで解決する可能性があります。
「HackTimer.jsとccapture.jsはどちらもwindow.setTimeoutをカスタム関数に置き換えているようです。HackTimer.jsは他のJavaScriptの前に実行すれば問題なく動作するようです。ccapture.jsの場合は、それが正しいことを確認してください。最初のスクリプトとして実行します。そのため、SocketIOは最初にブラウザのネイティブsetTimeoutを使用します。その後、カスタムsetTimeoutによって吹き飛ばされ、現在実行中のタイマーが中断されます。」

コードを検索して、ライブラリの1つがコードを置き換えているかどうかを確認します。

ag 'window.setTimeout\s*='

コンソールでテストして、setTimeoutが変更されているかどうかを確認することもできます。

/native/.test(window.setTimeout) // returns true for the native function and false for a custom one

このバグはまだ存在しますか？ マスターバージョンにアップグレードしましたが、トランスポートの終了通知により、モバイルデバイスは約2分で切断されます。

これは、socket.io 1>から離れて、socket.io0.9.17を維持するためのものでした。 しかし、今、私は再試行しています。サーバーにピンポンを手動で設定して、サーバーを存続させ、19分後に切断します。間隔は35秒ごとです。

socket.io 0.9.17を実行した場合、この問題は発生しません。ただし、廃止されているため、これ以上使用したくありません。 どんな助けでも、これはモバイルデバイスのブラウザで起こります。

@utan再現手順は？

こんにちは@rauchg 、

お返事をありがとうございます..

1）socket.io1.4.0をインストールします
2）nginxconfigをプロキシに設定します

                        proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $host;
                proxy_http_version 1.1;
                proxy_pass http://io_nodes;

3）socket.io 1.4.0 / 2015-11-28を使用してクライアントを設定します
4）モバイルデバイスに接続します。
5）モバイルブラウザをアプリに接続したままにしてから、電話をアイドル状態のままにします。

次にログ;

  engine:polling compressing +0ms
  engine:socket executing batch send callback +1ms
PuTTY  engine intercepting request for path "/socket.io/" +95ms
  engine handling "GET" http request "/socket.io/?EIO=3&transport=polling&t=L8YVUt6&sid=DJNvvkhmCQew_3vGAAAB" +0ms
  engine setting new request for existing client +0ms
  engine:polling setting request +0ms
  engine:socket transport error +6s
  engine:polling closing +2ms
  engine:polling transport writable - closing right away +0ms
  engine:polling writing "�1" +0ms
  socket.io:client client close with reason transport error +0ms
  socket.io:socket closing socket - reason transport error +0ms

34分後に切断されます。

ポーリングを使用している場合は、このエラーログが表示されます。

 engine:socket executing batch send callback +1ms
PuTTY  engine intercepting request for path "/socket.io/" +106ms
  engine handling "GET" http request "/socket.io/?EIO=3&transport=polling&t=L8YXgi6&sid=skadf3It4qBRi0S0AAAC" +1ms
  engine setting new request for existing client +0ms
  engine:polling setting request +0ms
  engine:socket transport error +3s
  engine:polling closing +0ms
  engine:polling transport writable - closing right away +0ms
  engine:polling writing "�1" +0ms
  socket.io:client client close with reason transport error +1ms
  socket.io:socket closing socket - reason transport error +2ms
  engine intercepting request for path "/socket.io/" +373ms
  engine handling "POST" http request "/socket.io/?EIO=3&transport=polling&t=L8YXhdB&sid=skadf3It4qBRi0S0AAAC" +0ms

それで@rauchgはそれを閉じましたか？

本当にあなたがすべきだとは思わない。

私はしませんでした。

@rauchg 、
では、これは今のsocket.ioの正常な動作ですか？ ユーザーがプラグインされておらず、アイドル状態の場合、モバイルデバイスのユーザーを切断するWSプロトコルに何か変更がありましたか？

私はこの問題で頭を壁にぶつけていますが、アップグレードを完了できません..そして新しいsocket.ioでコードをリファクタリングします...
私のサーバーUbuntu10.10
Nginxバージョン：Nginx / 1.8.0
ノードv0.10.31 // 4.0にアップグレードしても同じです。

httpsとNginxプロキシsocket.ioを使用します。

他の誰かが同じ問題を抱えていますか、それとも私だけですか？

私もそうかもしれないと思います。しかし、私のケースを特定するのは非常に難しいです。 私はsocket.ioでsails.jsを使用しています。

ubuntu 14.04
ノードv5.3.0
npm v 3.3.12
帆。 [email protected]
socket.io@~1.4.3

私のクライアントはsocket.io-clientとsails.io.jsの組み合わせです。

var socketIOClient = require('socket.io-client');
var sailsIOClient = require('sails.io.js');
var io = sailsIOClient(socketIOClient);
io.socket.on('connect', function(data){....})

したがって、最初の接続は永久に続きます...しかし、このクライアントへの.emit（）または.broadcast（）の後、サーバーは約25秒から1分後にクライアントをダンプします。クライアントは切断の通知を受け取りません。 。 まだ接続されていると思います。

非常にイライラします。

同様の問題が発生していますが、安全なソケット（wsの代わりにwss）を使用している場合に限ります。 wsを使用するとすべてが正常に機能しますが、wssを使用すると、接続がランダムな時間（〜15分）で散発的に切断されます。 ファイアウォールもプロキシもありません。

ありがとう@ andrin-n-dream私のものはSSLにも関係していると思います。 クライアントとしてWindowsマシンを使用し、サーバーとしてubuntu vm（同じマシン）を使用しています。 ブリッジネットワークアダプタ。 一般的なネットワーク接続で問題が発生したことはありません。

nginxSSLまたはsails.jsSSLターミネーションのどちらを使用するかに関係なく、SSLで発生します。

NAVER - http://www.naver.com/

[email protected]さんに送られたメール

受信者が会員様のメールを受信遮断しました。

私は永遠にデバッグしましたが、SSLの別の解決策を見つけることができませんでしたが、手動で再接続しました。 engine.ioが私のためにこれを行い、トランスポートが閉じられたときに再試行するのであれば素晴らしいでしょう。

これに対する解決策はありますか？ 私はまったく同じ問題を抱えています。 数秒後、サーバーからデバッグログにハートビートタイムアウトが表示されますが、クライアントはまだ接続されていると見なします。

他の差し迫った問題のために、私は自分の環境をアップグレードしました、そしてこれは今バックバーナーにあります。 ノード6.5.0が違いを生むかどうかを確認するとよいでしょう。 Sails.jsはいくつかのパッケージを更新し、これらの低レベル関数の使用を変更しました...

大量のレガシーC ++を移行しているので、今はこれに再び飛び込む時間がありません。 多分今年の後半か1月。

これは2.0.3でもまだ発生しています...
https://github.com/socketio/socket.io/issues/3025

回避策がないと、クライアントの25％でこの問題が発生するため、socket.ioは基本的に使用できません。

io.set（ 'ハートビートタイムアウト'、99999）;

@ Aaron1011これはサーバー側またはクライアントコードを意味しますか？ サーバー側の場合、クライアント側で何かを変更する必要がありますか？

試した：
io.set（ 'ハートビートタイムアウト'、99999）;
サーバー側で、socket.io v2.0.3を使用して問題を修正しませんでした。 次に0.8.6にダウングレードしてみます。

それは確かに巨大なウサギの穴であるため、0.8.6にダウングレードできませんでした。 すべての構文が変更され、0.8.6で見つけることができるドキュメントがないため、それは失われた原因です。 この問題が解決することを期待して、アプリを古いバージョンにダウングレードするように書き直したくはありません。

誰かがv2.03のアイデア/修正を持っていますか？ 私が試したこと：

• pingIntervalを9999999に設定します
• pingTimeoutを99999999に設定します
• キープアライブとしてメッセージを自動的に送信します。 1秒ごとにメッセージを送信しますが、それでもランダムに切断されます。
• ファイアウォールを無効にしました
• XHRポーリングのオン/オフを試してみました
• ポートをランダムなものから80に変更しました

私はそれがコーディングエラーではないことを確信していますが、それが他では起こらないので、PC特有です。 ネットワークアダプタと関係があるかもしれません。

@forgeableSun Primusに基づいてurアプリを作成する必要があります。私は、アプリをprimusでリファクタリングし、現在、socketJsを使用しています。

他のプロジェクトをサポートします。他のリアルタイムプロジェクトを使用するために他のコードを変更する必要はありません。

よろしく。

@utanやって

npm install browserchannel --save

var primus = new Primus（server、{transformer： 'browserchannel'}）;

https://github.com/primus/primus/blob/master/README.md#supported -real-time-frameworks

希望が役立ちます。

ブラウザチャネルはsocket.ioと何の関係がありますか？

これは、別のフレームワークに切り替える方法の単なる例です。

あなたが例を求めたように..

大丈夫ですが、socket.ioはサポートされているリアルタイムフレームワークの1つとしてもリストされていません。 APIを切り替えるのは1行のコードだけではありません。例を挙げずに、ドキュメントがそれをどのように宣伝できるかわかりません。

聞いてください、socket.ioは> = 1の後でバグがあり、奇妙な切断があります。primusを使用することを提案しているので、別のフレームワークに切り替えることができます。

そのため、例を挙げました。もちろん、primusを使用するにはコードをリファクタリングする必要があります。その後、さまざまなフレームワークを自由に試して、どれが最適かを確認するか、壊れた場合は別のフレームワークを使用します。

よろしく

@utanなるほど、アプリ全体がそのフレームワーク（アダプターなど）で記述された、あるフレームワークから別のフレームワークに切り替えるためのトランスフォーマーだと思っていました。 しかし実際には、アプリ全体がprimusで記述されたフレームワークにシームレスに切り替えるためのトランスフォーマーです。

確かに、あなたは私の頭を上げました..私は違いを知るのにそれほど熟練していません、私たちが同じことについて話していると思っていました..

よろしく。

私のサーバーログ：
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」
クライアントを切断します。 切断の理由：「トランスポートクローズ」

大規模な書き換えを伴うws（https://github.com/websockets/ws）に切り替えましたが、クライアント側でネイティブのWebSocketブラウザーオブジェクトを使用するようになり、すべてが完全に機能します。 もう問題はありません。 とても長いsocket.io！

10〜30分後にランダムに切断されていました。 私のホスティングサービスは、Apache共有サーバー上でPassengerを使用してNodeJSを実行していることを思い出しました。 私はそれを本当に理解していませんが、基本的にこの種の統合ではWebSocketに問題があることを意味します。 トランスポートを設定してテストしています：['polling']のみ、ローカルホストではトランスポート：['websockets'、 'polling']を使用してエラーやドロップアウトなしで実行しています。 これまでのところ、30分後には良好です...