Socket.io: pourquoi socket.io utilise-t-il une connexion websocket et une interrogation xhr en parallèle ?

• "L'interrogation XHR" n'est pas une connexion, elle peut utiliser plusieurs connexions.
• Les transports websocket et polling ne sont pas encore initialisés simultanément. En fait, c'est ce que fait engine.io et ce que socket.io fera bientôt une fois qu'il l'aura implémenté. Lisez plus ici et vous pourriez reconsidérer l'étiquette "stupide", peut-être.

Si vous rencontrez une situation où socket.io 0.9 a deux transports ouverts simultanément, ce serait un bogue, et plus d'informations sur la façon de le reproduire seraient appréciées.

"L'interrogation XHR" n'est pas une connexion, elle peut utiliser plusieurs connexions.

Oui, mais parce que le sondage fonctionne sur la même URL toutes les demandes. Je suppose qu'il devrait en imiter un.

Si vous rencontrez une situation où socket.io 0.9 a deux transports ouverts simultanément, ce serait un bogue, et plus d'informations sur la façon de le reproduire seraient appréciées.

Je ne sais pas si nous voulons dire la même chose mais : Chromium me montre une connexion websocket ouverte et en plus il envoie des demandes d'interrogation à socket.io.
Le "stupide" signifie maintenant que je ne peux pas profiter des avantages d'une connexion et d'une interrogation Websocket utilisables.
La connexion Websocket ne devrait-elle pas être suffisante et l'interrogation xhr ne devrait-elle être utilisée que comme solution de secours ?

Corrige moi si j'ai raté quelque chose

@bodokaiser la connexion websocket a-t-elle réellement fonctionné ou s'agit-il d'un recours au sondage ?

Gardez à l'esprit que la poignée de main est HTTP standard

Chrome m'indique que la connexion Websocket est en attente. Il n'y a pas de message d'erreur. Je suppose que le ws fonctionne. Néanmoins, comment puis-je vérifier si socket.io est en train de se replier ?

Oui, ce n'est certainement pas la poignée de main. Je vois dans Chrome et dans la console de nœud comment une requête get se répète toutes les 2000 ms.

La journalisation node.js vous aiderait-elle ?

Salutations

Inspectez les cadres qui ont été échangés dans la connexion ws (je pense que seul Chrome a cela). Si vous ne voyez aucune donnée, cela n'a pas fonctionné.

Oui, il semble qu'il se replie :

  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 pouvez-vous me dire pourquoi c'est le repli ?

Quel navigateur utilisez-vous?

Chrome 21 pour Mac OSX

Je vois également le même problème sur Chrome 21/Windows 21.0.1180.79 m -- il y a une connexion d'interrogation JSONP (qui semble réussie) avec une connexion WebSocket simultanée qui ne se connecte jamais -- elle est toujours à l'état "En attente". La même version de Chrome sur Mac semble bien.

Cela ne semble pas lié au pare-feu ou à l'antivirus, tous les tests passent sur websocketstest.org et websocket.org/echo.html.

J'utilise socket.io 0.9, mais il semble également être présent dans la dernière version.

@guille Ce problème semble également assez facile à reproduire. Je viens de visiter un site qui utilise le transport WebSocket de socket.io :

http://beta.blaggart.com

Notez que, dans Chrome 21 sous Windows au moins, l'état de la connexion WS est toujours « En attente ».

Essayer avec socket.io master ?

Je viens d'essayer master et j'ai le même problème. Je pense que ce problème pourrait également être dupe de #998.

De plus, pour ce que cela vaut, la solution de contournement décrite dans # 998 a fonctionné pour moi en obtenant une connexion à établir - en désactivant les websockets et en utilisant uniquement les sondages xhr et jsonp.

est-ce vraiment un bug de chrome ?

lors d'un test sur www.websocket.org/echo.html

Ce qui est amusant, c'est que lorsque j'utilise "Secure WebSocket (TLS)" sur ce même site Web, Websocket fonctionne.

exactement le même comportement pour Chrome et Firefox .. très étrange ..

Serveur:

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

socket.on('connexion',fonction(données){
socket.emit('l_msg',{uname:data.uname,score:data.score,type:true});
});

Imprimer:
info : poignée de main autorisée 11012331592122282453
débogage : demande de configuration GET /socket.io/1/xhr-polling/11012331592122282453?t=1353485202761
débogage : définition du délai d'expiration du sondage
debug : client autorisé pour
débogage : effacement du délai d'attente du sondage
débogage : écriture xhr-polling 1 : :
débogage : définissez le délai de fermeture pour le client 11012331592122282453
débogage : xhr-polling a reçu le paquet de données 20,5 : : : {"name":"count"} 22 5 : : :{"name":"history"} 23 5 : : :{"name ":"liste d'utilisateur"}
débogage : demande de configuration GET /socket.io/1/xhr-polling/11012331592122282453?t=1353485202792
débogage : définition du délai d'expiration du sondage
débogage : suppression du transport
débogage : expiration du délai de fermeture pour le client 11012331592122282453
débogage : effacement du délai d'attente du sondage
débogage : écriture xhr-polling 8 : :
débogage : définissez le délai de fermeture pour le client 1896586469607627233
débogage : interrogation xhr fermée en raison d'une durée dépassée
débogage : xhr-polling a reçu le paquet de données 5 : : : {"name":"login","args":[{"uname":"gjjn","pwd":"3f01728152a0225ff9806c401ffdbe77"}]}
débogage : effacement du délai d'attente du sondage
débogage : écriture xhr-polling 5:::{"name":"l_msg","args":[{"uname":"gjjn","type":true,"head":" http://42.121. 14.234/non défini "}]}
débogage : définissez le délai de fermeture pour le client 11012331592122282453
débogage : xhr-polling a reçu le paquet de données 5 : : : {"name":"loginout"}
debug : websocket writing 5:::{"name":"l_msg","args":[{"uname":"gregergre","type":true,"head":" http://42.121.14.234/ non défini "}]}
débogage : émission de pulsations pour le client 5207531891749391108
débogage : écriture websocket 2 : :
débogage : définissez le délai d'attente de pulsation pour le client 5207531891749391108
débogage : a obtenu un paquet de pulsation
débogage : expiration du délai de pulsation pour le client 5207531891749391108
débogage : définissez l'intervalle de pulsation pour le client 5207531891749391108
débogage : écriture websocket 5:::{"name":"loginout","args":[{}]}

L'interrogation xhr a reçu le paquet de données 5:::{"name":"loginout"}.
Mais pas de résultat.

Pareil ici. J'ai utilisé le même code mais cela fonctionne sur Chrome MacOS mais pas sur Chrome Windows

comment reproduire - https://gist.github.com/jonnsl/5021596

+1, veuillez résoudre ce problème. @LearnBoost

Même si je vois cela, de mon côté, je vois une connexion Websocket et une demande XHR répétée envoyée au serveur SOCKET.io

On dirait qu'une connexion Websocket a réussi, mais je vois une demande XHR

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

Voici à quoi ressemblent les cadres Websocket
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

Et la demande d'interrogation longue

https://www.dropbox.com/s/pf7d56tp85864bg/Capture d'écran%202014-07-09%2011.15.47.png

Je cours sur Google Chrome 35.0.1916.153

et la version du problème de socket est [email protected]

J'ai le même problème. Les mises à jour? Utilisation de SocketIO 1.0.6

La première requête est toujours XHR, puis nous _mise à niveau_ vers WebSocket (si nous le pouvons). L'interrogation suivante est interrompue (il peut y avoir un cycle d'interrogation supplémentaire dans certains cas, mais jamais plus de 1)

@guille quant à ce que j'ai vérifié, je vois une interrogation XHR répétée même si la connexion Websocket a été établie avec succès

Salut,

Quelle est la solution pour résoudre ce problème ?

@rohittailor : Je teste ça sur le client :

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

Et jusqu'ici tout va bien. Cela évite complètement la connexion XHR.

Cela résout également mon problème, websocket fonctionnait bien MAIS il y avait aussi une interrogation XHR sale. Merci @gonzalodiaz

J'aimerais vraiment voir un scénario dans lequel il se met à niveau vers WS avec succès, mais les cycles d'interrogation XHR se poursuivent indéfiniment dans Web Inspector !

(une démo, une vidéo, un gif animé, tout fonctionne)

Je peux vous donner un accès démo à mon site web, hébergé sur le cloud MS Azure demain. Pouvez-vous nous donner votre URL de test et plus de détails sur l'hébergement de socket.io ?

@guille Que diriez-vous de ça

Voici à quoi ressemblent les cadres Websocket
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

Et la demande d'interrogation longue

https://www.dropbox.com/s/pf7d56tp85864bg/Capture d'écran%202014-07-09%2011.15.47.png

Ceux-ci continuent-ils indéfiniment? Y a-t-il des cadres en double dans le
réponses ? Pourriez-vous poster le journal du serveur correspondant avec DEBUG=* et le
journal du navigateur avec localStorage.debug='*' lorsque cette situation se produit ?

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

Le Mar 14 Oct 2014 à 22:59, Viren Negi [email protected]
a écrit:

@guille https://github.com/guille Que diriez-vous de cela

Voici à quoi ressemblent les cadres Websocket

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

Et la demande d'interrogation longue

https://www.dropbox.com/s/pf7d56tp85864bg/Capture d'écran%202014-07-09%2011.15.47.png

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/Automattic/socket.io/issues/991#issuecomment -59161273
.

@guille Je vois la réponse xhr se répéter indéfiniment pas sûr du cadre en double laissez-moi voir si je peux fournir tout ce dont vous avez besoin

Je ne sais pas à quel point je peux être utile, mais je remarque que je ne peux me connecter à une prise Web que si elle est sécurisée. Y a-t-il eu des changements de sécurité récents qui nécessitent un en-tête (comme CORS) pour autoriser les connexions WebSocket non sécurisées ?

WebSockets a fonctionné il y a un mois pour moi, maintenant cela ne fonctionne que pour les connexions wss://.
Chrome 38.0.2125.104 - Windows 8.1.1

Edit : ces résultats pourraient en fait être un problème avec http://www.websocket.org/echo.html
je n'ai pas pu tester ailleurs

Le succès de la connexion WS dépend vraiment des capacités du réseau/serveur. SSL garantit que rien ne peut le casser avant que les données ne soient déchiffrées (les proxys / équilibreurs de charge ultérieurs peuvent toujours le casser).

J'ai remarqué qu'il s'agissait en fait d'un bogue dans le code, il n'a même jamais interrogé la connexion WS, j'ai fait un changement et cela a fonctionné. Si je me souviens bien, je regarderai la source modifiée ce soir.

Mais si cela fonctionne pour tout le monde, cela pourrait être quelque chose d'autre qui ne va pas avec ma configuration, mais il n'essayait pas de se connecter car il pensait que WS n'était pas disponible sans essayer, en changeant un && en un || l'a réparé.

J'aimerais en savoir plus !

Encore un (petit) problème, le client fait toujours des requêtes de sondage au lieu d'essayer un autre transport. je dois préciser

{transports: ['websocket']}

Pour que cela fonctionne, mais le client doit essayer tous les transports pour trouver le bon, n'est-ce pas ?

Ce problème était la raison pour laquelle j'ai commencé en 2012/13 à travailler sur un propre package de socket Web "pur".

Ce problème a-t-il été résolu ? Je vois quelque chose de similaire, mais avant de commencer à creuser, je voulais faire une recherche rapide... des commentaires ?

Le code a beaucoup changé depuis mon dernier commentaire sur ce problème. Il est peu probable que ce soit le même bug. Je n'arrive pas à trouver la ligne que je soupçonnais d'être à l'origine du problème la dernière fois. Cela ne veut pas dire que c'est réparé.

Mon code socket.io est actuellement bloqué par un bogue engine.io-client, donc je n'ai pas utilisé s.io depuis quelques mois maintenant, donc je ne peux pas dire avec certitude si c'est toujours un problème.

@nevercast votre commentaire sur le fonctionnement de wss mais ws n'était pas tout à fait correct dans mon cas. Merci de l'avoir signalé, je cherche ce problème depuis plus d'une semaine. J'ai trouvé que d'une manière ou d'une autre, toute connexion ws sur mon réseau était bloquée, mais wss fonctionnait bien.

Ce site Web est génial : http://websocketstest.com/ il vous indique quels ports sont capables d'exécuter des Websockets sur un réseau donné. Nous vous recommandons de vérifier cela avant de vous impliquer trop dans le débogage des Websockets.

J'ai un problème avec le socket io mais je ne sais pas où je me trompe.

l'image ci-dessus montre que cela fonctionne bien en local, mais l'image ci-dessous est capturée lors de la tentative dans l'environnement AWS.

J'ai un problème avec le socket io mais je ne sais pas où je me trompe.

l'image ci-dessus montre que cela fonctionne bien en local, mais l'image ci-dessous est capturée lors de la tentative dans l'environnement AWS.

face au même problème