クイックハックとして、「新しい接続を強制する」を使用できます：誤った構成

また、アプリケーションでこのバグを確認しました。
次は再現でした。 WebSocket接続のFFで、いくつかのエラーが発生しました。 その後、次々と3つの再接続イベントが生成されました。 この後、3つの新しい接続が確立され、ブラウザは1つではなく3つのメッセージを受信しました。

たぶん、再接続ロジックにいくつかのバグがありますか？ 1つではなく複数の再接続を生成する何か。

WebSocket（FF 3.6など）をサポートしていない古いブラウザーで、dom readyイベント（jQueryの "$（）"）でsocket.ioを初期化すると複数の接続が発生し、後のwindow.loadで初期化するという問題が発生しました。イベントはしません。 この特定の問題は一貫して再現可能であることがわかりました。 それがあなたが見ているものと同じであるかどうかはわかりませんが、症状は非常に似ています。

ここでも同じ問題。 問題は、サーバーが何らかの理由でクラッシュしてから電源が再びオンになった場合、再接続すると毎回n +1の応答が発生することです。 したがって、3つのサーバーがクラッシュしたとすると、各サーバーの送信で4つの応答が返されます。 ページを更新すると問題が解決します。 誰かがこれに対する解決策を見つけましたか[一時的であっても]

これは永続的な解決策ではないかもしれませんが、各イベントが個別にバインドされ、自動再接続で重複の問題が解決されたように見えるようにコードを再配置しました

me.socket.on('connect', function () {
});

me.socket.on('message', function(data) {

});

me.socket.on('disconnect', function() {

});

キャッチされたWiresharkダンプを介して1週間デバッグした後、私はなんとか理由を見つけてこのバグを再現することができました。

つまり、再接続ロジックは非常に壊れやすいものです。 これは、並行して実行できる多くのタイマーに依存し、複数の再接続につながります。 この行https://github.com/LearnBoost/socket.io-client/blob/master/lib/socket.js#L511がこのバグの主な理由です。

今完全に再現：

1. クライアントからサーバーに接続します。
2. 階乗を介してサーバーにスローコードを配置します（node.jsメインループを4〜8秒間中断する必要があります）。
   関数fibo（n）{
   if（n <2）は1を返します。
   fibo（n-2）+ fibo（n-1）;を返します。
   }
   それをauth-sectionに入れます。 これはハンドシェイクで呼び出す必要があります。
   io.set（ 'authorization'、function（data、accept）{
   console.info（ "Fibo ::" + fibo（41））;
   ノードコンソールで実験して、fibo（N）を見つける必要があります。
   メインループを4〜8秒間ブロックします。
3. ここで、サーバーを高速で再起動する必要があります。
   スローコードが接続に適用されます。
   ハンドシェイクされていないことをクライアントに通知する必要があります。
   そして今、それは再接続を試みます。
   コンソールでは、いくつかの再接続の試みが表示されます（「再接続/再接続」コールバックにログを記録した場合）。
   スローダウンハックの後、それは永遠に繰り返されます。

実生活では、これはサーバーの速度低下によって再現されました-少なくとも数秒間は応答してください。
これは、node.jsの負荷が高く、応答が遅れる場合があります。
または、一部のネットワークの速度低下もそのような動作につながる可能性があります。
サーバーの再起動後にも再現できます。

この行（socket.js、511）：
self.reconnectionTimer = setTimeout（maybeReconnect、self.reconnectionDelay）;

接続呼び出し後にイベントをスケジュールします。 また、接続応答が少なくとも1秒間遅延すると、接続応答がトリガーされ、新しい再接続がキューに入れられます。 2秒後、もう1つ追加されます。

私は修正を行いましたが、テストされておらず、あまりしっかりしていないように見えます。 主な問題-maybeReconnect関数に対してどのコールバック/タイマーを同時に実行できるかを推論する方法。
この行： https ：

Socket.ioクライアントは、ステートマシンを使用するようにリファクタリングされる場合、推論がはるかに簡単になる可能性があります。 現在、状態はさまざまなフラグ（接続、接続、再接続など）に分散しています。 そして、多くの機能で、「if（！self.reconnecting）」や他の多くのガードを見ました。
ステートマシンは、このロジックを単純化して、状態とイベントのセットを持つことができます。 また、タイマーはイベントを発生させるためにのみ使用できます。 このイベントが誤った状態に達した場合、ステートマシンはこのイベントを無視するだけで、気にする必要はありません。

JSに適したSTMは見つかりませんでしたが、RubyのSTMはJSに簡単に移植できます： https ：

この問題を修復するには、間違いなく+1します。 私はsocket.ioまたはsocket.io-clientを直接変更せずにこの問題の回避策を見つけようと取り組んできましたが、残念ながら、私が確実に思いついた唯一の方法は、再接続を無効にすることです。 これは間違いなく良い解決策ではありません。特にモバイルデバイスの使用が増えると、再接続は大きな要件になります。

これが開発者の優先リストにどのように含まれるかを誰かが知っていますか？

ああ。 この問題は問題から3rd-Edenに割り当てられているようです： https ：

クライアントの修正を行い、プルリクエストを送信しました。 0.8.4で正常に動作し、他のバージョンでも正常に動作します。 ただし、ハンドシェイクにAJAX（またはCORS）を使用するソース機能を無効にする必要があります。 詳細については、 https ：

そのような古い問題を復活させてすみません。 私はsocket.ioの最新バージョンを使用しています（または、少なくとも、npm install socket.ioを実行しました）。 この問題はまだ発生しています。socket.ioとnode.jsは全体として比較的新しいです。 また、最初の接続（一度にしか発生しなかった2つのうち）で読み取りエラーが発生することがあるという問題もありました。 私がクリスと言っているのが正しければ、あなたの修正はコミットされたので、もう起こらないはずですが、重要な要素を見逃さない限り、それでも起こりますか？

編集-

それはクリスフォークされたsocket.ioのようで、それを修正しましたが、修正は元のsocket.ioにコミットされていませんでしたか？

@JTallis @gdizと同じ問題があり、彼の提案はうまくいきました。 問題が類似している場合は、試してみて、どのように機能するかをお知らせください。

最新バージョンであると私が信じている0.9.16でもこの問題が発生しています。 gdizはこれを防ぐためにどのように回避しますか？ 完全には理解していませんでした。

omg ...アプリの何が問題になっているのか、接続が失われて更新された後にサーバーとクライアント間のメッセージが大量に重複する理由を理解するために数時間を費やしています...

0.9.16を使用してこの問題を確認できます

同じファイルnode.jsファイルで次のクライアントとサーバーのコードを使用して、二重接続イベントを自由に取得できます。

"use strict";
var server = require('socket.io');
var client = require('socket.io-client');

setTimeout(function () {
    var io = server.listen(8888);

    io.of('/chat').on('connection', function (socket) {
        console.log('Server: /chat connection');
    });

    io.sockets.on('connection', function (socket) {
        console.log('Server: connection');
    });
}, 2000);

var socketAddress = 'http://localhost:8888/chat';
var socket = client.connect(socketAddress);

socket.on('connect', function () {
    console.log("Client: connect");
});

socket.on('error', function () {
    console.log("Client: error");
    socket.socket.reconnect();
});

奇妙なことがいくつかあります。

1）URLから「/ chat」を削除して名前空間接続を通常の接続に変更すると、接続イベントは1つだけになります。

2）サーバーをすぐに起動し、setInterval時間をゼロに変更すると、初期接続エラーは発生せず、接続イベントは1つだけになります。

これに対する回避策または修正はありますか？

同じ問題を抱えています。 socket.ioサーバーが予期せず再起動した場合、クライアントは2回再接続するため、すべてのメッセージがクライアントによって2回処理されます。 本当にクライアント側で私のカウントを台無しにします。

1.0.0-pre2リリースでも同じ問題があります。 socket.ioを再起動すると、2つの「400BadRequest」があります。

今日はこれを調べます！

今日はこれを調べます！

詳細、ログ、画面が必要な場合は、遠慮なく！ 毎回ではありません。

2755行目の1.0.6のクライアントsocket.io.js：

Request.prototype.create = function（isBinary、supportsBinary）{
var xhr = this.xhr = new XMLHttpRequest（{agent：this.agent、xdomain：this.xd}）;
..。
}

設定するのは良い考えだと思います：
xhr.timeout = Manager._timeoutのインスタンス-10ミリ秒
このようにして、クライアント側で複数のクライアントソケットが作成されるのを防ぎます。
サーバー側では、複数のソケットがハートビートタイムアウトになります。

基本的なsocket.ioの「GettingStarted」の例（http://socket.io/get-started/chat/）には、このダブルソケット接続の問題があります。

次のいずれか（確率の昇順）では、単一のブラウザタブ接続からダブルソケット接続になります。
a）localhost：3000に接続すると、最初のブラウザタブ自体から
b）localhost：3000に接続すると、2番目のブラウザタブから
c）（localhost：3000）に接続する前に、ブラウザコンソールを開いたままにします

追加の所見：

 io.on('connection', function(socket){
    console.log('a user connected: ' + socket.id);
    socket.on('disconnect', function(){
       console.log('a user disconnected');
       console.log(socket.nickname + ' has disconnected from the chat.');
    });
});

1. socket.idつのブラウザタブリクエストから発生する2つの異なる
2. 「重複」ソケット接続は、「未定義がチャットから切断されました」というconsole.logを使用して、約1分で切断されます。
3. Express Generator 4.2（Morganを使用）を使用してから「GettingStarted」の例を実装すると、「良好な」ブラウザ接続により、「GET / 3041ms」などの1行のExpressログが生成されます。 ただし、この「ダブル」ソケット接続がある場合は常に、「GET / 3041ms」と「GET / 2003ms-386b」の2つのエクスプレスログがあります。

Mac、Chrome、Express 4.2、および最新のsocket.ioを使用しています。

2つのログの作成にはタイミングの違いがあります。 最初のログは、Chromeが「lo」を「 localhost：3000 」に自動完了したときに発生し、2番目のログはEnterボタンを押したときに発生します。

「Xusersconnected」コンソールログメッセージがあり、自分のブラウザが2つまたは3つのユーザー接続通知をトリガーしたときに非常に迷惑でした。

ここで、問題の解決策がconsole.log行をコメントアウトしたことを告白する必要があります。 しかし、皆さん、良い仕事を続けてください。

最新バージョンでもこの問題が発生します。 これに関する更新はありますか？

1.0でもこの問題が発生しています

全然再現できません。 誰かが完全な例を投稿できますか？

2時44分50秒AMレックスPechlerで金2014年11月14日には[email protected]
書きました：

1.0でもこの問題が発生しています

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/Automattic/socket.io/issues/474#issuecomment -62934229
。

明日、簡単な例を作成できるかどうかを確認します。

再現するかもしれません。 私はsocket.io1.3.5とexpress4.12.4を使用しています。

Expressアプリは127.0.0.1:3000にあり、ブラウザーを開いてIPアドレスを入力すると、socket.ioは1つのWebSocketのみを開きます。

abc.comなどのドメインがあり、127.0.0.1に転送します。 ブラウザでabc.comを開くと、index.htmlファイルに次の行があります。

<script>
        var socket = io('http://localhost:3000/mysql');

        socket.on('processlist', function (data){
            console.log(data);
        });
</script>

これにより、2つのWebSocketが開きます。

私はまだプロキシでnginxを試していません。 試してみたらすぐにお知らせします。

まだこの問題が発生しています。 私にとっては、サーバーの再起動時に発生しました-サーバーからの最初の接続イベントが発生したときにsocket.on（ 'message'）イベントハンドラーをアタッチしていました。クライアントが開いているときにサーバーが再起動した場合、そのイベントは複数回発生しました（より多くの時間クライアントがサーバーの再起動を待機していた時間が長くなりました）。

今のところ私の修正は、ソケットイベントのアタッチを「デバウンス」して、次のように最初のサーバー接続でのみ発生するようにすることです。

client.socketEventsAttached = false;

socket.on('connect',function(){
     if (!client.socketEventsAttached){
          attachSocketEvents();
     }
});

@gdizが提案したように、メッセージイベントリスナーをsocket.on（ 'connect'）リスナーの外に配置することもできます。 サーバーまたはクライアントの準備が整う前にソケットイベントが発生するという問題が発生しました。

@bbcollinsworthクライアントオブジェクトは何ですか？

新しいsocketioと基本的な例でまだこの問題が発生しています。

基本的な例に従って、まだこの問題が発生しています。

編集：正確に正しいかどうかはわかりませんが、修正を見つけました。 基本的に必要なのは使用することだけです

io.once('connection', ...)

の代わりに

io.on('connection', ...)

@brandonraphael （たとえば、https：//github.com/darrachequesne/socket.io-fiddleに基づいて）問題を再現する例を提供して、新しい問題を開いてください。

これがまだ発生していて、アプリで問題が発生している更新

これらはログです-
0 | APIサーバー| 接続済み!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! DKap3hUYFSpKBRr7AFgc 4351 2018-12-26 10:58:25
0 | APIサーバー| 接続済み!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! VS98DBFVTNF6ifzmAFgd 4351 2018-12-26 10:58:25

4351はユーザーIDであり、接続数もユーザー4351の場合の2のように静的ではありません。
別のログには、同じユーザーの6つの接続が同時に表示されます。

また、サーバー上のこれら2つのソケットIDを確認し、有効であることを示しています。 ただし、フロントエンドは、常に最初のソケットIDであるそのうちの1つのみをリッスンできます。

どんな助けでも本当に素晴らしいでしょう。
前もって感謝します。

基本的な例に従って、まだこの問題が発生しています。

編集：正確に正しいかどうかはわかりませんが、修正を見つけました。 基本的に必要なのは使用することだけです

io.once('connection', ...)

の代わりに

io.on('connection', ...)

これありがとう

クライアント側で使用されているバージョンを変更した後、問題は解決されました。 別の修正は、単一のソケットIDの代わりに部屋を使用することです。 すべてのソケットID自体が部屋であることがわかりました。変更されるのは、すべてのソケットIDをユーザールームに配置する新しい接続コードの部分だけでした。
ユーザースラッグがUser1であるとすると、部屋はUser1で作成され、スラッグUser1を介したすべての新しいソケット接続は部屋User1内に配置されました。

同じ問題を抱えていて、それは私を夢中にさせていました。 クライアントにもイベントリスナーを再登録していませんでした。 私のセットアップでは、socketioエンドポイントをホストするnodejsサーバーがあり、socketioクライアントとして機能する別のnodejsサーバーもあります。 秘訣は、クライアント側をWebSocketトランスポートに接続し、 forceNodeを使用すること

// client side
const socket = io('<url>', {
  transports: ['websocket'],
  forceNode: true,
});

私はこれと同じ問題を抱えていると思います。 私はチャットルームを構築していますが、誰かがその部屋に参加すると、「部屋に参加しました」というメッセージが部屋に表示されます。

すべてうまくいきますが、部屋を出てもう一度入ると、イントロメッセージが_2回_送信されます。 もう一度部屋を出て3回目に入ると、イントロメッセージが3回出されます。 _同じ_部屋へのすべての_再接続_は、重複したイントロメッセージになります。 ただし、_異なる_部屋に入ると、紹介メッセージが1回しか表示されません。

io.once('connection', ...)してもうまくいきませんでした。 実際、私のイベントはすべて機能しなくなりました。

「デバウンス」方式の使用も機能しませんでした。 繰り返しますが、私のイベントはどれも登録されていません。

最後に、 forceNode: trueオプションのクライアント側の使用も機能しませんでした。

サーバーとクライアントの両方で2.2.0を使用しています。 足りないものはありますか？

同じ問題について疑問に思っていましたが、最終的には、クライアントにonceのみを接続するように指示することが役に立ちました。

これがクライアントの私の設定です：

var socket = io.connect("http://localhost:3000/test", 
    { upgrade: false, transports: ['websocket'], reconnection: true, forceNew: false});
socket.once('connect', socketConn => {
    socket.on('message', data => {
        console.log(data);
    });
}); 

クライアントはconnectイベントに対してonceとして登録されるだけなので、クライアント内の他のイベントは1回登録されます。 これで、サーバーがクラッシュした場合、クライアントはサーバーへの再接続を試みるだけで、新しい接続を作成しようとはしません。 サーバーから応答を受け取るとすぐに、メッセージの処理を開始します。

したがって、 io.onceは、サーバー側ではなく、クライアント側で設定する必要があります。

クライアント2.1バージョンを使用しています。 開発環境でトリガーするのは非常に簡単です。 ノードサーバーが再起動するたびに（たとえばnodemonを使用して）、クライアントは常にいくつかの再接続イベントをトリガーし、さらに接続します。 しかし、根本的な原因を理解することはできません

クライアント2.1バージョンを使用しています。 開発環境でトリガーするのは非常に簡単です。 ノードサーバーが再起動するたびに（たとえばnodemonを使用して）、クライアントは常にいくつかの再接続イベントをトリガーし、さらに接続します。 しかし、根本的な原因を理解することはできません

私もnodemon自体を使用するのと同じ問題を抱えていました。 しかし、最終的には、 onceのみを接続するようにクライアントに指示することが役に立ちました。
上記の返信のコードを試してください。 それは私を助け、サーバーが再起動するたびに、クライアントは新しい接続を取得しています。

私の問題は単純でした

同じクライアント側のアプリを2つのタブで開いていました。 おっと

私も同じ問題を抱えていました。 しかし、私にとっては、クライアント側のハンドラーをsocket.on('connection', cb)コールバック関数内に誤って配置しました。

デモ用のスニペットは次のとおりです。

client.js（node.js内）

const client = require('socket.io-client');
const socket = client('my_endpoint', {
  transports: [ 'websockets' ]
});

socket.on('connect', () => {
  console.log('connected');
  socket.on('myEvent', (message) => {
    console.log(`message: ${message}`);
  });
});

切断と再接続が発生すると、 socket.on('connect', cb)再度呼び出され、 myEventハンドラーは同じ名前の2番目のハンドラーを登録します。 したがって、サーバーが再びmyEvent発行すると、同じメッセージの2つのコンソールログが作成されます。

解決するには、他のハンドラーをconnectハンドラーの外に配置する必要がありました。

const client = require('socket.io-client');
const socket = client('my_endpoint', {
  transports: [ 'websockets' ]
});

socket.on('connect', () => {
  console.log('connected');
});

socket.on('myEvent', (message) => {
  console.log(`message: ${message}`);
});

私の混乱は、サーバー側がsocket.onイベントをconnectイベント内に配置する方法をドキュメントが示していることに起因していると思います。 ドキュメントをもっと注意深く読んでいないのは私ですが、他の誰かが同じ間違いを犯した場合に備えて、これをここに置くと思いました。

また、node.jsでこの問題を具体的に見たとしても、これはブラウザーでも問題になると確信しています。