Socket.io: Warum verwendet socket.io parallel die Websocket-Verbindung und das xhr-Polling?

• "XHR Polling" ist keine Verbindung, es kann mehr als eine Verbindung verwenden.
• Die Websocket- und Polling-Transporte werden noch nicht gleichzeitig initialisiert. Genau das macht engine.io und das wird socket.io bald tun, sobald es implementiert ist. Lesen Sie hier mehr und vielleicht überdenken Sie das Etikett "dumm".

Wenn Sie auf eine Situation stoßen, in der socket.io 0.9 gleichzeitig zwei offene Transporte hat, wäre dies ein Fehler, und weitere Informationen zur Reproduktion wären wünschenswert.

"XHR Polling" ist keine Verbindung, es kann mehr als eine Verbindung verwenden.

Ja, aber weil das Polling auf der gleichen URL funktioniert, funktionieren alle Anfragen. Ich gehe davon aus, dass es einen emulieren sollte.

Wenn Sie auf eine Situation stoßen, in der socket.io 0.9 gleichzeitig zwei offene Transporte hat, wäre dies ein Fehler, und weitere Informationen zur Reproduktion wären wünschenswert.

Ich bin mir nicht sicher, ob wir dasselbe meinen, aber: Chromium zeigt mir eine offene Websocket-Verbindung an und sendet zusätzlich Polling-Anfragen an socket.io.
Das "dumme" bedeutet jetzt, dass ich den Vorteil einer brauchbaren Websocket-Verbindung und -Abfrage nicht verfolgen kann.
Sollte nicht die Websocket-Anbindung alleine ausreichen und xhr Polling nur als Fallback verwendet werden?

Korrigiert mich, wenn ich etwas übersehen habe

@bodokaiser hat die Websocket-Verbindung tatsächlich funktioniert oder fällt sie auf Abfragen zurück?

Denken Sie daran, der Handshake ist normales HTTP

Chrome Zeigt mir an, dass die Websocket-Verbindung aussteht. Es gibt keine Fehlermeldung. Ich gehe davon aus, dass das ws funktioniert. Wie kann ich trotzdem prüfen, ob socket.io zurückfällt?

Ja, am Handschlag liegt es definitiv nicht. Ich sehe in Chrome und in der Node-Konsole, wie eine Get-Anfrage alle 2000 ms wiederholt wird.

Würde Ihnen die Node.js-Protokollierung helfen?

Grüße

Überprüfen Sie die Frames, die in der ws-Verbindung ausgetauscht wurden (ich glaube, das hat nur Chrome). Wenn keine Daten angezeigt werden, hat es nicht funktioniert.

Yep scheint Rückhalt zu sein:

  debug - client authorized
   info  - handshake authorized yUEmr7drZfmWzWHdEZcp
GET /socket.io/1/?t=1344799805756 200 3ms
   debug - setting request GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815866
   debug - setting poll timeout
   debug - client authorized for 
   debug - clearing poll timeout
   debug - xhr-polling writing 1::
   debug - set close timeout for client yUEmr7drZfmWzWHdEZcp
GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815866 200 1ms
   debug - xhr-polling received data packet 5:::{"name":"hello","args":["world"]}
POST /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815871 200 1ms
   debug - setting request GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815872
   debug - setting poll timeout
   debug - discarding transport
   debug - cleared close timeout for client yUEmr7drZfmWzWHdEZcp
   debug - clearing poll timeout
   debug - xhr-polling writing 8::
   debug - set close timeout for client T9eCOR7gCe3pLNtiEZco
   debug - xhr-polling closed due to exceeded duration
GET /socket.io/1/xhr-polling/T9eCOR7gCe3pLNtiEZco?t=1344799800945 200 20002ms
   debug - clearing poll timeout
   debug - xhr-polling writing 8::
   debug - set close timeout for client yUEmr7drZfmWzWHdEZcp
   debug - xhr-polling closed due to exceeded duration

@guille könnten Sie mir sagen, warum es zurückfällt?

Welchen Browser verwendest du?

Chroms 21 für Mac OSX

Ich sehe das gleiche Problem auch unter Chrome 21/Windows 21.0.1180.79 m - es gibt eine JSONP-Abfrageverbindung (die erfolgreich zu sein scheint) mit einer gleichzeitigen WebSocket-Verbindung, die nie eine Verbindung herstellt - sie befindet sich immer im Status "Ausstehend". Die gleiche Version von Chrome auf dem Mac scheint in Ordnung zu sein.

Dies scheint nicht Firewall- oder Antivirus-bezogen zu sein, alle Tests laufen auf websocketstest.org und websocket.org/echo.html.

Ich verwende socket.io 0.9, aber es scheint auch in der neuesten Version vorhanden zu sein.

@guille Dieses Problem scheint auch ziemlich einfach zu reproduzieren. Ich habe gerade eine Site besucht, die den WebSocket-Transport von socket.io verwendet:

http://beta.blaggart.com

Beachten Sie, dass der Status der WS-Verbindung zumindest in Chrome 21 unter Windows immer "Ausstehend" ist.

Versuchen Sie es mit socket.io master ?

Habe gerade Master probiert und ich habe das gleiche Problem. Denke, dass dieses Problem auch ein Betrug von #998 sein könnte.

Außerdem hat die in #998 beschriebene Problemumgehung für mich funktioniert, um eine Verbindung herzustellen - Websockets deaktivieren und nur xhr- und jsonp-Polling verwenden.

Ist das wirklich ein Chrome-Bug?

bei einem Test unter www.websocket.org/echo.html

Komisch ist, dass, wenn ich "secure WebSocket (TLS)" auf derselben Website verwende, Websocket funktioniert.

genau das gleiche Verhalten für Chrome und Firefox.. sehr seltsam..

Server:

socket.on('loginout',function(){
    socket.emit('loginout',{uname:socket.name});
});

socket.on('login',function(data){
socket.emit('l_msg',{uname:data.uname,score:data.score,type:true});
});

Drucken:
Info: Handshake autorisiert 11012331592122282453
Debug: Einstellungsanforderung GET /socket.io/1/xhr-polling/11012331592122282453?t=1353485202761
Debug: Einstellen des Poll-Timeouts
Debug: Client autorisiert für
Debug: Abfragezeitüberschreitung löschen
Debug: xhr-Polling-Schreiben 1::
Debug: Zeitüberschreitung beim Schließen für Client festlegen 11012331592122282453
debug: xhr-polling empfangenes datenpaket 20,5:::{"name":"count"} 22,5:::{"name":"history"} 23,5:::{"name ":"Benutzerliste"}
Debug: Einstellungsanforderung GET /socket.io/1/xhr-polling/11012331592122282453?t=1353485202792
Debug: Einstellen des Poll-Timeouts
Debug: Transport verwerfen
Debug: Zeitüberschreitung beim Schließen für Client 11012331592122282453 gelöscht
Debug: Abfragezeitüberschreitung löschen
Debug: xhr-Polling-Schreiben 8::
Debug: Zeitüberschreitung beim Schließen für Client 1896586469607627233 festlegen
Debug: xhr-Polling wegen Zeitüberschreitung geschlossen
debug: xhr-polling empfangenes Datenpaket 5 :::{"name":"login","args":[{"uname":"gjjn","pwd":"3f01728152a0225ff9806c401ffdbe77"}]}
Debug: Abfragezeitüberschreitung löschen
debug: xhr-polling Writing 5 :::{"name":"l_msg","args":[{"uname":"gjjn","type":true,"head":" http://42.121. 14.234/undefiniert "}]}
Debug: Zeitüberschreitung beim Schließen für Client festlegen 11012331592122282453
debug: xhr-polling empfangenes Datenpaket 5 :::{"name":"loginout"}
debug: Websocket Writing 5 :::{"name":"l_msg","args":[{"uname":"gregergre","type":true,"head":" http://42.121.14.234/ undefiniert "}]}
Debug: Heartbeat für Client ausgeben 5207531891749391108
Debug: Websocket-Schreiben 2::
Debug: Heartbeat-Timeout für Client setzen 5207531891749391108
Debug: Heartbeat-Paket erhalten
Debug: Heartbeat-Timeout für Client 5207531891749391108 gelöscht
Debug: Heartbeat-Intervall für Client einstellen 5207531891749391108
debug: Websocket-Schreiben 5 :::{"name":"loginout","args":[{}]}

Das xhr-polling hat das Datenpaket 5:::{"name":"loginout"} empfangen.
Aber kein Ergebnis.

Dasselbe hier. Ich habe den gleichen Code verwendet, aber er funktioniert unter Chrome MacOS, aber nicht unter Chrome Windows

wie man reproduziert - https://gist.github.com/jonnsl/5021596

+1, bitte beheben Sie dieses Problem.. @LearnBoost

Auch wenn ich das sehe, sehe ich auf meiner Seite eine Websocket-Verbindung und eine wiederholte XHR-Anfrage, die an den SOCKET.io-Server gesendet wird

Scheint, als hätte eine Websocket-Verbindung zum Erfolg geführt, aber ich sehe eine XHR-Anfrage

Request URL:ws://localhost:5000/socket.io/?EIO=2&transport=websocket&sid=XcMblHoZ0x97QRn_AAAE
Request Method:GET
Status Code:101 Switching Protocols
Request Headers CAUTION: Provisional headers are shown.
Cache-Control:no-cache
Connection:Upgrade
Cookie:io=XcMblHoZ0x97QRn_AAAE
Host:localhost:5000
Origin:http://localhost:3000
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits, x-webkit-deflate-frame
Sec-WebSocket-Key:EZixwYoUHpFFpgrEOqiS+w==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Query String Parametersview sourceview URL encoded
EIO:2
transport:websocket
sid:XcMblHoZ0x97QRn_AAAE
Response Headers
Connection:Upgrade
Sec-WebSocket-Accept:WHsiBZoW9stmULt+YX8wmNK1wx8=
Upgrade:websocket

So sehen die Websocket-Frames aus
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

Und die lange Abfrageanfrage

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot%202014-07-09%2011.15.47.png

Ich laufe auf Google Chrome 35.0.1916.153

und die Socket-Ausgabeversion ist [email protected]

Ich habe das gleiche Problem. Irgendwelche Updates? Verwenden von SocketIO 1.0.6

Die erste Anfrage ist immer XHR, dann _upgrade_ wir auf WebSocket (wenn wir können). Die nachfolgende Abfrage wird abgebrochen (in einigen Fällen kann es zu einem zusätzlichen Abfragezyklus kommen, jedoch nie mehr als 1)

@guille Was ich überprüft habe, sehe ich eine wiederholte XHR-Abfrage, auch wenn die Websocket-Verbindung erfolgreich hergestellt wurde

Hallo,

Was ist die Lösung, um dieses Problem zu beheben?

@rohittailor : Ich

    <script src="/socket.io/socket.io.js"></script>
    <script>
        var socket = io.connect({transports: ['websocket']});
    </script>

und soweit so gut. Es vermeidet die XHR-Verbindung vollständig.

Dies löste auch mein Problem, Websocket funktionierte gut, ABER es gab auch eine schmutzige XHR-Abfrage. Danke @gonzalodiaz

Ich würde wirklich gerne ein Szenario sehen, in dem es erfolgreich auf WS aktualisiert wird, aber die XHR-Abfragezyklen im Web Inspector auf unbestimmte Zeit fortgesetzt werden!

(eine Demo, ein Video, ein animiertes Gif, alles funktioniert)

Ich kann Ihnen morgen einen Demozugang zu meiner Website geben, die in der MS Azure Cloud gehostet wird. Können Sie uns Ihre Test-URL und weitere Details zum Hosting von socket.io nennen?

@guille Wie wäre es damit

So sehen die Websocket-Frames aus
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

Und die lange Abfrageanfrage

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot%202014-07-09%2011.15.47.png

Gehen die auf unbestimmte Zeit weiter? Gibt es doppelte Frames im
Antworten? Könntest du das entsprechende Serverlog mit DEBUG=* posten und die
Browserprotokoll mit localStorage.debug='*' wenn diese Situation eintritt?

—
Guillermo Rauch – @rauchg https://twitter.com/rauchg

Am Dienstag, 14. Oktober 2014 um 22:59 Uhr, Viren Negi [email protected]
schrieb:

@guille https://github.com/guille Wie wäre es damit

So sehen die Websocket-Frames aus

https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

Und die lange Abfrageanfrage

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot%202014-07-09%2011.15.47.png

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/Automattic/socket.io/issues/991#issuecomment -59161273
.

@guille Ich sehe die xhr-Antwort auf unbestimmte Zeit wiederholen.

Ich bin mir nicht sicher, wie hilfreich ich sein kann, aber ich stelle fest, dass ich nur eine Verbindung zu einem Web-Socket herstellen kann, wenn es sicher ist. Gab es in letzter Zeit einige Sicherheitsänderungen, die einen Header (wie CORS) erfordern, um unsichere WebSocket-Verbindungen zuzulassen?

WebSockets hat vor einem Monat bei mir funktioniert, jetzt funktioniert es nur noch für wss://-Verbindungen.
Chrome 38.0.2125.104 - Windows 8.1.1

Bearbeiten: Diese Ergebnisse könnten tatsächlich ein Problem mit http://www.websocket.org/echo.html sein
Ich konnte nicht woanders testen

Der Erfolg der WS-Verbindung hängt wirklich von den Netzwerk- / Serverfähigkeiten ab. SSL garantiert, dass nichts sie brechen kann, bevor die Daten entschlüsselt sind (nachfolgende Proxys / Load Balancer können sie jedoch immer noch brechen).

Mir ist aufgefallen, dass es sich tatsächlich um einen Fehler im Code handelt, es hat nicht einmal die WS-Verbindung abgefragt, ich habe eine Änderung vorgenommen und dann hat es funktioniert. Wenn ich mich erinnere, schaue ich mir heute Abend die geänderte Quelle an.

Aber wenn es für alle anderen funktioniert, könnte es etwas anderes sein, das mit meinem Setup nicht stimmt, aber es versuchte nicht, eine Verbindung herzustellen, weil es dachte, dass WS nicht verfügbar war, ohne es zu versuchen, und änderte ein && in ein || behoben.

Ich möchte mehr hören!

Immer noch ein (kleines) Problem, der Client macht immer Poll-Requests, anstatt andere Transporte zu versuchen. ich muss angeben

{transports: ['websocket']}

Damit es funktioniert, sollte der Kunde aber alle Transporte ausprobieren, um den guten zu finden, oder?

Dieses Thema war der Grund, warum ich bereits 2012/13 angefangen habe, an einem eigenen "reinen" Web-Socket- Paket zu arbeiten .

Wurde dieses Problem gelöst? Ich sehe etwas Ähnliches, aber bevor ich anfange, tief zu graben, wollte ich eine schnelle Suche durchführen ... Kommentare?

Der Code hat sich seit meinem letzten Kommentar zu diesem Problem ein wenig geändert. Es ist unwahrscheinlich, dass es sich um denselben Fehler handelt. Ich kann die Zeile nicht finden, von der ich vermutete, dass sie das Problem beim letzten Mal verursacht hat. Das heißt nicht, dass es fest ist.

Mein socket.io-Code wird derzeit von einem bug engine.io-client blockiert, daher habe ich io seit ein paar Monaten nicht mehr verwendet, kann also nicht mit Sicherheit sagen, ob dies immer noch ein Problem ist.

@nevercast Ihr Kommentar zur Funktionsweise von wss, aber ws war in meinem Fall nicht ganz richtig. Danke für den Hinweis, ich suche seit über einer Woche nach diesem Problem. Habe festgestellt, dass irgendwie eine ws-Verbindung in meinem Netzwerk blockiert wurde, aber wss funktionierte einwandfrei.

Diese Website ist großartig: http://websocketstest.com/ Sie sagt Ihnen, welche Ports Websockets in einem bestimmten Netzwerk ausführen können. Empfehlen Sie dies zu überprüfen, bevor Sie sich zu sehr auf das Debuggen von Websockets einlassen.

Ich habe ein Problem mit Socket io, bin mir aber nicht sicher, wo ich falsch liege.

Das obige Bild zeigt, dass es in der lokalen Umgebung gut funktioniert, aber das folgende Bild wird beim Versuch in einer AWS-Umgebung aufgenommen.

Ich habe ein Problem mit Socket io, bin mir aber nicht sicher, wo ich falsch liege.

Das obige Bild zeigt, dass es in der lokalen Umgebung gut funktioniert, aber das folgende Bild wird beim Versuch in einer AWS-Umgebung aufgenommen.

stehe vor dem gleichen problem