Socket.io: Socket.io mit Ping-Timeout nach dem Zufallsprinzip trennen

Haben Sie versucht, auf ausgegebene Fehlerereignisse zu hören?
Hier ist ein Stack-Overflow-Artikel, der eine Liste häufiger Ereignisse enthält, die vom Socket ausgegeben werden.

http://stackoverflow.com/questions/24224287/list-of-socket-io-events

Ich habe das gleiche Problem hast du das herausbekommen?

@jitendrapawar kannst du dich konsequent reproduzieren?

Nein, es kommt nicht wiederholt vor, es wird nach dem Zufallsprinzip mit Ping getrennt
Auszeit.

Am 10. Januar 2017, 19:50 Uhr, "Damien Arrachequesne" [email protected]
schrieb:

@jitendrapawar https://github.com/jitendrapawar kannst du das ?
konsequent reproduzieren?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/socketio/socket.io/issues/2769#issuecomment-271586816 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ANP7JpiqxkTpZlc5CsayjIZf9GAqURLiks5rQ5OsgaJpZM4K9hrg
.

• Senden Sie Binärdaten? (https://github.com/socketio/socket.io/issues/2666)
• Kommt es nach einer bestimmten Verzögerung zu einer Zeitüberschreitung (könnte Proxy-bezogen sein)?
• Hängt es mit einem bestimmten Browser zusammen?
• Verbinden sie sich nach dem Ping-Timeout wieder ordnungsgemäß?

Gleiches Problem hier. Es werden keine anderen Fehler ausgegeben. Scheint total zufällig zu sein.

Ich deaktiviere das Netzwerk und aktiviere es sofort. Ungefähr 1 Minute später erhält der Server ein 'Ping-Timeout'-Problem.

  pingInterval: 25000,
  pingTimeout: 60000,

Autor sagte das: a client may have to wait up to pingTimeout + pingInterval ms before getting a disconnect event.
aber ich habe festgestellt, während ich die Webseite mit F5 drücke, bekomme ich ein neues socket.id , bin ich getrennt??Ich aktualisiere meine Seite weniger als 1s
Ich kann nicht finden, wie es funktioniert

Ich bin auch gerade auf dieses Problem gestoßen. Unsere App läuft seit über einem Jahr ohne diese Unterbrechungen, aber jetzt treten zufällige Unterbrechungen auf. Beim Debuggen ist der Grund für die Trennung ein "Ping-Timeout" und Clients scheinen keine Probleme beim erneuten Verbinden zu haben.

Das einzige, was ich bisher möglicherweise eingrenzen kann, ist eine neue Version von Google Chrome. Chrome 63 scheint keine Probleme zu haben, aber Benutzer von 64 haben die Verbindungsabbrüche und ich habe keine Ahnung warum

Ich stehe vor genau dem gleichen Problem und verwende Chrome 63 @jstelz. Hat jemand das Problem oder eine Lösung gefunden?

Das kann mit https://github.com/socketio/engine.io/issues/312#issuecomment -274367814 verlinkt sein.

@darrachequesne In meinem Fall hängt es definitiv mit dem Problem der clientseitigen Timer zusammen, die in Hintergrund-Tabs gedrosselt werden (zumindest in Chrome, ich habe es noch nicht in anderen Browsern getestet).
Ich sehe die gleichen Symptome wie oben von den anderen erwähnt und es ist sehr einfach zu reproduzieren. Ich muss nur meine Web-App starten, sicherstellen, dass sie eine Verbindung herstellt, und eine weitere Registerkarte öffnen, um die Ausführung meiner App im Hintergrund zu erzwingen. Schließlich werden die Timer von Chrome gedrosselt, was zu Ping-Timeouts führt, was letztendlich dazu führt, dass der Server meine App trennt, da er denkt, dass die App nicht mehr lebt.
Es gibt eine Möglichkeit, diese Drosselung in Chrome zu deaktivieren => https://www.tenforums.com/tutorials/80233-enable-disable-google-chrome-background-tab-throttling-windows.html
Aber das ist nicht perfekt und manchmal auch nicht anwendbar. Wahrscheinlich wäre die einzig gute Lösung, was auch in primus lib gemacht wurde: um die Richtung von Ping/Pong-Nachrichten umzukehren (https://github.com/primus/primus/pull/534)
Dies scheint jedoch eine ziemlich große Umgestaltung in engine.io zu sein, die sowohl die Server- als auch die Client-Bibliotheken betrifft ...

@sirudog Nun , das ist eine ziemlich große Veränderung! Ich denke aber das müssen wir machen...

Ich habe dieses Problem mit einem Spiel, an dem ich arbeite.

Wenn ich den Server auf setze
pingInterval: 1000, pingTimeout: 500
Mein Client sendet ungefähr jede Sekunde ein Ping-Timeout und verbindet sich erneut.

Wenn ich den Server auf setze
pingInterval: 500, pingTimeout: 1000
Ich erhalte keine Zeitüberschreitungen, aber der Server erkennt nie eine Trennung.

Für alle, die zufällige Zeitüberschreitungen erleiden, versuchen Sie, die Standardeinstellung von engine.io "Transport-Upgrade-Zeitüberschreitung" (upgradeTimeout) zu ändern.

Nach dem erneuten Verbinden und Empfangen einer großen Datenmenge schien der Socket nicht mehr zu reagieren, das Debuggen von engine.io zeigte keine Fehler, sondern nur der Socket, der versuchte, den Transport jedes Mal zu aktualisieren, wenn der Client erneut eine Verbindung herstellte.

Beispielserver:

// index.js
import io from 'socket.io';
import expressApp from './express/expressApp'; // express server
import socket from './socket/socket';

const port = 4000;
expressApp.set('port', process.env.Port || port);

const server = expressApp.listen(port, 'localhost');

const socketIo = io(server, {
  upgradeTimeout: 30000 // default value is 10000ms, try changing it to 20k or more
});

socket(socketIo);

// socket.js
export default socketIo =>
  socketIo.on('connection', socket => {
  //...return large amount of data
  }
}

Hier kannst du mehr über engine.io lesen:
https://github.com/socketio/engine.io

Hi

Für alle, die zufällige Zeitüberschreitungen erleiden, versuchen Sie, die Standardeinstellung von engine.io "Transport-Upgrade-Zeitüberschreitung" (upgradeTimeout) zu ändern.

Nach dem erneuten Verbinden und Empfangen einer großen Datenmenge schien der Socket nicht mehr zu reagieren, das Debuggen von engine.io zeigte keine Fehler, sondern nur der Socket, der versuchte, den Transport jedes Mal zu aktualisieren, wenn der Client erneut eine Verbindung herstellte.

Beispielserver:

// index.js
import io from 'socket.io';
import expressApp from './express/expressApp'; // express server
import socket from './socket/socket';

const port = 4000;
expressApp.set('port', process.env.Port || port);

const server = expressApp.listen(port, 'localhost');

const socketIo = io(server, {
  upgradeTimeout: 30000 // default value is 10000ms, try changing it to 20k or more
});

socket(socketIo);

// socket.js
export default socketIo =>
  socketIo.on('connection', socket => {
  //...return large amount of data
  }
}

Hier kannst du mehr über engine.io lesen:
https://github.com/socketio/engine.io

Hi,

Ich habe es versucht, aber immer noch viele Verbindungsabbrüche:

15:10:57,270 urbanGUI INFO verbunden
15:10:57,549 urbanGUI INFO Client getrennt: 6830bd090575426f9c53dec108702e04
15:10:59,70 urbanGUI INFO verbunden
15:10:59,342 urbanGUI INFO Client getrennt: e2eb60d8a2aa445f94a17b6c6fc00e34
15:11:00,770 urbanGUI INFO verbunden
15:11:01,41 urbanGUI INFO Client getrennt: 62b2619d3b3a4c05aa9cfa0ad3df9524
15:11:02,655 urbanGUI INFO verbunden
15:11:02,940 urbanGUI INFO Client getrennt: a421da49b04c46f38c1ae8c08b14e5db
15:11:04,153 urbanGUI INFO verbunden
15:11:04,421 urbanGUI INFO Client getrennt: b935f53d393c42488411e2b6c3e5961a
15:11:05,359 urbanGUI INFO verbunden
15:11:05,630 urbanGUI INFO Client getrennt: ee8a42bb8b0e4bc8b9e813dd808c1dc3
15:11:07,232 urbanGUI INFO verbunden
15:11:07,513 urbanGUI INFO Client getrennt: 5c9804841d0a438e87536977c222c630
15:11:08,703 urbanGUI INFO verbunden
15:11:08,981 urbanGUI INFO Client getrennt: a5dfcc72eb5c4445b09fb28153220961
15:11:10,601 urbanGUI INFO verbunden
15:11:10,893 urbanGUI INFO Client getrennt: 394e409a10fa41a8aa7e7c747b4ea606
15:11:12,87 urbanGUI INFO verbunden
15:11:12,360 urbanGUI INFO Client getrennt: e83bacd1338d4306b8eaccc9597f7a0b
15:11:13,384 urbanGUI INFO verbunden
15:11:13,661 urbanGUI INFO Client getrennt: 52cf363b5d26431a8b9b6459551aedcd
15:11:14.389 urbanGUI INFO verbunden
15:11:14,664 urbanGUI INFO Client getrennt: f254c71fbd374cac9bd3d4161e53456f
15:11:15,995 urbanGUI INFO verbunden
15:11:16,275 urbanGUI INFO Client getrennt: ec7d67d7b4a04019b3496dcf40e0d41a
15:11:17,709 urbanGUI INFO verbunden
15:11:17,992 urbanGUI INFO Client getrennt: 68a9ea7e54f34cc3be9f9395b19943b7
15:11:18,720 urbanGUI INFO verbunden
15:11:19,1 urbanGUI INFO Client getrennt: e17cdcf179d9482dbf4f6befc2e0db47
15:11:19.808 urbanGUI INFO verbunden
15:11:20,91 urbanGUI INFO Client getrennt: 8f262794c9fc40bb90aa37f9fe20db80
15:11:21,430 urbanGUI INFO verbunden
15:11:21,705 urbanGUI INFO Client getrennt: 2769a86f041c422ea7806ce11177b88f
15:11:23,95 urbanGUI INFO verbunden
15:11:23,368 urbanGUI INFO Client getrennt: 3306fd1f321740e1a80d005291e1a801
15:11:24,662 urbanGUI INFO verbunden
15:11:24,943 urbanGUI INFO Client getrennt: ac6afdc9952440fc8d4846548adc50f2
15:11:25,774 urbanGUI INFO verbunden
15:11:26,58 urbanGUI INFO Client getrennt: 5b270718206d49aeba597361bbff8be2
15:11:27,673 urbanGUI INFO verbunden
15:11:27,952 urbanGUI INFO Client getrennt: ce9bba31d7494d19800c24cd68aedb2c
15:11:29.477 urbanGUI INFO verbunden
15:11:29,753 urbanGUI INFO Client getrennt: a29d9cd1903c422f9606a801e4685c2c
15:11:30.684 urbanGUI INFO Client getrennt: 48924b51684e46008558c7577c1f6269
15:11:31,59 urbanGUI INFO verbunden
15:11:31.325 urbanGUI INFO Client getrennt: f2e6c04f38a94617bb6ac8a331cde224
15:11:32,858 urbanGUI INFO verbunden
15:11:33,141 urbanGUI INFO Client getrennt: 139db6786631476ea1561b669a0b2431
15:11:34,558 urbanGUI INFO verbunden
15:11:34,844 urbanGUI INFO Client getrennt: 83940d8f836e48a5918e14794e19c0c8
15:11:35,547 urbanGUI INFO verbunden
15:11:35.815 urbanGUI INFO Client getrennt: 5f85ca0cc1254b74b19d41f5c321ac8a
15:11:37,316 urbanGUI INFO verbunden
15:11:37.593 urbanGUI INFO Client getrennt: 7554f2dd4fd54bad9b95300c1b0998ca
15:11:39,195 urbanGUI INFO verbunden
15:11:39,476 urbanGUI INFO Client getrennt: 8fead9b5e8e148e9956778b7a91e875b
15:11:40,481 urbanGUI INFO verbunden
15:11:40,767 urbanGUI INFO Client getrennt: 2579464ed45b418491bda2fc60b8bcc6
15:11:41,488 urbanGUI INFO verbunden
15:11:41,761 urbanGUI INFO Client getrennt: b8b25fec44584b288d12c297b21c72bd
15:11:42,686 urbanGUI INFO verbunden
15:11:42.966 urbanGUI INFO Client getrennt: 0f780d9ebc294e47bf3f5184c38c8836
15:11:44,388 urbanGUI INFO verbunden
15:11:44,668 urbanGUI INFO Client getrennt: 14999c3f00314bb285bbde4501e3cecb
15:11:45.581 urbanGUI INFO verbunden
15:11:45,849 urbanGUI INFO Client getrennt: ada765125a374b7fbb4174d7d97bb901
15:11:47,95 urbanGUI INFO verbunden
15:11:48,328 urbanGUI INFO verbunden
15:11:48,602 urbanGUI INFO verbundener Raum: 6e2f8d8f-d835-478b-12a3-70ba109603a1
15:12:15,248 urbanGUI INFO verbunden
15:12:15,523 urbanGUI INFO beigetretener Raum: 6e2f8d8f-d835-478b-12a3-70ba109603a1
15:12:41.806 urbanGUI INFO verbunden
15:12:42,77 urbanGUI INFO Client getrennt: 1bfd592fe1274c4db14d37ee6e144726
15:12:43,582 urbanGUI INFO verbunden
15:12:43,855 urbanGUI INFO Client getrennt: 63a0a6abdb3240f598af9e5947520362
15:12:44,988 urbanGUI INFO verbunden
15:12:45,256 urbanGUI INFO Client getrennt: 930e46874fdd48888e6f2abac0e7f066

@kllr
Ändern Sie Ihr Trennereignis, um den Grund anzuzeigen:

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

Eine andere Sache, die Sie versuchen können, ist, das Transport-Upgrade fallen zu lassen

const socketIo = io(server, {
  transports: ['websocket'],
  allowUpgrades: false
});

Ich habe das gleiche Problem mit socket.io 2.2. Es bremst nach einiger Zeit zufällig und beginnt sich wieder zu verbinden. Fehler ist ping timeout .

Gibt es eine Möglichkeit, sicherzustellen, dass die Verbindung stabil ist und niemals bricht? Myabe irgendein Browser oder so ähnlich?

Hi,
Das gleiche Problem hier, ich benutze socket.io 2.2.0, hat jemand eine Lösung dafür?

Grüße

Das gleiche Problem tritt bei mir auf, ich bin auf socket.io 2.2.0 , und wenn auf meiner Website ein Client ein Bild in base64 an den Server sendet und das Bild groß ist, führt dies dazu, dass der Bildsender-Client einen Ping-Zeitüberschreitungsfehler erhält und trennt den Client. Bitte lassen Sie es uns wissen, wenn jemand eine Lösung gefunden hat.

Können Sie es versuchen, indem Sie das pingTimeout höher als das pingInterval einstellen, wie hier vorgeschlagen:
https://github.com/socketio/socket.io/issues/3259#issuecomment -474523271

Server:

const socket = io(server, {
  pingTimeout: 30000
  // ...other props
});

Klient:

const socket = io(`${config.server}`, {
    pingTimeout: 30000
    // ...other props
  });

Das Standard-PingInterval ist 25000ms.
Wenn das immer noch nicht funktioniert, versuchen Sie es nur mit Websocket:

transports: ['websocket'],
allowUpgrades: false,
pingTimeout: 30000

Es gibt ein undokumentiertes (?) problematisches Verhalten in Bezug auf Zeitüberschreitungen: Wenn der Server große Pakete sendet, deren Übertragung länger dauert als das Zeitüberschreitungsintervall, führt dies zu Zeitüberschreitungen und Verbindungsabbrüchen. Die einzige Möglichkeit, dies zu beheben, besteht darin, sicherzustellen, dass Sie nur relativ kleine Pakete senden. Dies ist ein Problem, da Sie Ihrer Serverlogik (zu) viel Aufmerksamkeit schenken müssen, damit die Daten immer innerhalb der Grenzen liegen - und - da die Verbindungsgeschwindigkeit ein unbekannter Faktor ist, ist es schwierig, dies vollständig zu beheben.

Ich würde vorschlagen, die Timeout-Logik leicht anzupassen, um dies zu umgehen.

Noch ein paar Infos zu meinen Problemen.
Jetzt sende ich kleinere Pakete, jetzt wird die Verbindung beim Hochladen von Bildern nicht unterbrochen, aber es werden zufällig Ping-Timeout-Fehler ausgegeben.

@IIaakso, was sind die empfohlenen Ping-Timeout-Einstellungen, meine r diese ab sofort:

Mein Client js:

Meine Servereinstellungen:

immer noch das gleiche Problem auf "socket.io": "2.2.0",
"socket.io-client": "2.2.0",

socket.io- client:socket schließen (ping timeout) +22s

Gleiches Problem wie bei @FaizanZahid . Es wird nur zufällig mit Ping-Timeout getrennt ...

Gleiches Problem und mein Setup unterscheidet sich wirklich nicht von Ihrem (forceNew: true, da es der wichtigste Teil imo ist)

Ich aktualisiere von einem antiken socket.io 1.x mit Knoten 6.x-Setup auf socket.io 2.2 und Knoten 12.x, sowohl auf den sendenden als auch auf den empfangenden Servern des Tests.

Vor dem Upgrade konnte ich ungefähr 12k gleichzeitige Verbindungen vom Quellserver (auf dem der Client ausgeführt wird) zum Zielserver (auf dem der IO-Server ausgeführt wird) starten.

Die offensichtlichen Systemgrenzen, Firewall-Grenzen usw. wurden vor dem Update überprüft und angepasst, sodass sowohl "sendende" als auch "empfangende" Server kein Grund für Probleme oder Einschränkungen sein sollten.

Aber nach dem Upgrade auf socket.io 2.2 erhalte ich zufällige Ping-Timeouts, wenn ich etwa 2,5k gleichzeitige Verbindungen starte ...

*Bearbeiten: In meiner Test-App werden keine Daten übertragen, es liegt also kein Problem mit der Datenlänge oder dem Inhaltstyp vor. die Clients verbinden sich nur mit dem Server, der eine benutzerdefinierte Authentifizierung für die Clients durchführt, und wenn die Authentifizierung erfolgreich ist, warten die Clients auf ein Serverereignis.

Daher wäre jeder Einblick in eine mögliche Ursache sehr dankbar ;)

Aus den Tests, die ich an meinem Setup (FreeBSD 11.2, Knoten 12.3.x) durchgeführt habe, sind hier die Ergebnisse, die ich beobachten und replizieren kann:

socket.io-Client-Version | socket.io-Version | Ergebnis
2.2 | 2.2 | zufällige Ping-Timeouts nach ca. 2000 Verbindungen
1.3.5 | 2.2 | funktioniert perfekt mit 4500 gleichzeitigen Verbindungen
2.2 | 1.3.5 | kann nicht verbinden
1.3.5 | 1.3.5 | funktioniert perfekt mit 4500 gleichzeitigen Verbindungen

Das Problem scheint also im Client-Abschnitt von socket-io-client 2.2 oder zumindest im 2.x-Client-Zweig zu liegen ...

Irgendeine Lösung dafür?? In meinem Fall ist es kein Problem mit der Anzahl der Verbindungen, es wird einfach nach einigen Stunden Inaktivität mit einem Ping-Timeout-Fehler nach dem Zufallsprinzip getrennt ...

Ich habe ein ähnliches Problem, ist der Grund bekannt?

Ich habe ein gleiches Problem. Ich denke, es ist ein wirklich seltsames Thema für mich.

Ich verwende Socket.io in meiner React Native App. auf IOS funktioniert es. Aber auf Android wird die Verbindung nach 30 ms getrennt. Hier ist das Protokoll:

  engine:ws closing +30s
  socket.io:client client close with reason ping timeout +30s
  socket.io:socket closing socket - reason ping timeout +30s
  socket.io-parser encoding packet {"type":2,"data":["disUser",0],"nsp":"/"} +30s
  socket.io-parser encoded {"type":2,"data":["disUser",0],"nsp":"/"} as 2["disUser",0] +0ms
user disconnected: dxYGo3l7Dab-1qBfAAAA
reason: ping timeout

"socket.io": "^2.2.0"
"socket.io-client": "^2.2.0"

Wie kann ich es auf meiner Android-Seite beheben?

@berksafran Ich Problem. Könnten Sie mir bitte

Nun, leider konnte ich dieses Problem nicht beheben, aber ich habe gesehen, dass dieses Problem erst im Entwicklungsprozess ist. Wenn Sie Ihre Anwendung freigeben und es mit react-native run-android --variant=release versuchen, funktioniert Ihr socket.io-Server ordnungsgemäß.

Die andere Lösung, die ich gefunden habe, besteht darin, Ihren Socket.io-Server auf einen beliebigen Cloud-Server hochzuladen. (heroku, digitalocean etc.) Nach dem Hochladen sollten Sie Ihre Verbindungsadresse auf die URL des Cloud-Servers setzen. Ich habe es probiert und jetzt funktioniert es.

Bei Fragen kannst du mir hier schreiben.

Viel Glück.

Findet jemand die Lösung? Aktualisiert: Ich habe nach der Bereitstellung meiner App getestet, es funktioniert.

Hallo allerseits,
Ich entwickle eine App mit socket.io.
Als Client verwende ich socket.io-client 2.3.0
Für Server verwende ich socket.io Version 2.3.0

Mein Server wird auf Heroku gehostet. Und ich stehe vor diesen zufälligen Ping-Timeouts. Die Ping-Timeouts treten noch häufiger auf, wenn ich meine App auf dem Handy öffne. Irgendeine Lösung, die ich versuchen kann? Vielen Dank

@sukalyansen123 Bei meinem Debugging vor langer Zeit habe ich festgestellt, dass der Transport nicht aktualisiert werden kann und das

const socketIo = io(server, {
  transports: ['websocket'],
  allowUpgrades: false
});

@sukalyansen123 - Ich hatte ein ähnliches Problem und für mich schien das explizite Festlegen der Standard-Timeouts zu helfen.

SERVERSEITE:

VOR:
let io = require('socket.io')(server, { transports: ['websocket'], allowUpgrades: false });

NACH:
`
let io = require('socket.io')(Server,
{
Transporte: ['websocket'],
erlaubenUpgrades: false,
pingInterval: 25000, // Standard - 25000
pingTimeout: 60000, // Standard - 60000

});
`

Vielen Dank. Ich habe es versucht, aber es hilft immer noch nicht. Jetzt kommt es wieder auf mobilen Steckdosen zu Verbindungsabbrüchen, manchmal aufgrund von Ping-Timeout und manchmal aufgrund von Transportschließungen. Ich bin mir nicht sicher, ob dies an einer Unterbrechung der Internetverbindung liegt, aber wie soll ich damit umgehen?

So sieht meine Clientseite aus, wenn dies hilft - ich verbinde nur über das Websocket-Protokoll
`
this.socket = io(serverURL,
{
Transporte: ['websocket'],
autoConnect: wahr

        });

`
Hoffentlich hilft das

So sieht meine Clientseite aus, wenn dies hilft - ich verbinde nur über das Websocket-Protokoll
`
this.socket = io(serverURL,
{
Transporte: ['websocket'],
autoConnect: wahr

        });

`
Hoffentlich hilft das

Danke noch einmal. Ich wollte auch wissen, wie Sie das Ereignis "disconnect" von der Clientseite aus handhaben.

So sieht meine Clientseite aus, wenn dies hilft - ich verbinde nur über das Websocket-Protokoll
`
this.socket = io(serverURL,
{
Transporte: ['websocket'],
autoConnect: wahr

        });

`
Hoffentlich hilft das

Dies scheint ein wenig zu helfen. Im Moment werden jedoch Sockets getrennt, wenn sie bei geschlossenem Transport einige Zeit im Leerlauf gehalten werden. Wäre das Senden von Heartbeats in regelmäßigen Zeitabständen eine gute Lösung?

ich habe das gleiche problem. aber ich benutze Socket für mein Online-Spiel.
Ich teste etwas und ich habe festgestellt, dass beim Ping-Timeout angezeigt wird!
Der Grund ist, wenn der Client (Benutzertelefon) im Ruhezustand ist oder mein Spiel beendet, wird der Server die Verbindung trennen.
aber ich habe keine Lösung gefunden, um es zu beheben! noch.

Versuchen Sie diesen Code auf der Serverseite

var fs = require('fs');
var pkey = fs.readFileSync('/etc/ssl/private/ssl.key'); //Replace the path of your SSL key
var pcert = fs.readFileSync('/etc/ssl/certs/ssl.crt');//Replace the path of your SSL cert
var options = {
  key: pkey,
  cert: pcert
};

var app = require('https').createServer(options);

var io = require('socket.io')(app, {'pingTimeout': 180000, 'pingInterval': 25000});

Hier ist pingInterval wichtig. Halten Sie es niedrig. Ich habe verschiedene Werte ausprobiert und festgestellt, dass 25 Sekunden gut sind, um den Socket weiter pingen zu lassen, bevor er eine Zeitüberschreitung erhält. Das Hauptproblem besteht darin, wenn innerhalb von 60 Sekunden kein Ping / Pong vorhanden ist, wird die Verbindung getrennt und versucht, die Verbindung automatisch erneut herzustellen. Außerdem fand ich pingTimeout auf der Serverseite und Timeout und Clientseite nicht in der Lage, den Socket in 60 Sekunden zu trennen. Es passiert aufgrund der neuesten Chrome-Version 83.*

Wie oben vorgeschlagen, werden wir den Ping/Pong-Mechanismus in Socket.IO v3 rückgängig machen: https://github.com/socketio/engine.io-protocol#difference -between-v3-and-v4

Ich habe auch angefangen, mit dem gleichen Problem konfrontiert zu werden. Ich verwende die Version socket.io Version 2.0.4 und habe das Problem ping timeout , nachdem ich Sockets mit mehreren Knoten mit socket.io-redis implementiert habe. Aber es funktioniert ganz gut mit einem einzelnen Knoten ohne Redis. Kann mir jemand mit einem möglichen Grund dazu helfen?

Unser Projekt hat den Knoten gerade auf v12 aktualisiert. Nach diesem Update bekommen wir auch die Trennung wegen Ping-Timeout :| Hier ist eine Liste der Zeiten, in denen die Verbindungsabbrüche aufgetreten sind:

11:06:59
11:08:19 +80s
11:10:39 +140s
11:14:39 +240s
11:15:59 +80s
11:20:59 +300s
11:22:19 +80s
11:23:19 +60s
11:24:39 +80s
11:28:59 +260s

Unsere Einstellungen:
Auszeit: 30s
Intervall: 20s
Wiederverbindungsverzögerung: 10s

Hey! hatte das gleiche problem. Socket.io-Versionen 2.3.0 (gleiche Versionen auf Client und Server).
Mein Problem war mit dem Server. Nachdem ich überprüft habe, wie lange es dauert, bis der Server die über den Socket gesendete Antwort vorbereitet, habe ich nach 2 Tagen Graben das Problem gefunden. Es war eine Methode, bei der die Ausführungszeit linear anstieg, und als die Ausführung begann, 1 s zu dauern, konnte der Server einfach nicht auf den Ping des Clients antworten und dann gab der Client einen Verbindungsabbau und einen erneuten Verbindungsversuch aus, und von hier aus du kennst den Rest.
Zusammenfassend möchte ich sagen, dass es sich nicht um ein socket.io-Problem handelt, sondern meistens um ein Serverproblem.
Hoffe das hilft.

Das Abgleichen der Versionen für Server und Client löst für mich das Problem. Ich habe mit V 3.0.4 & 2.3.0 getestet