Lorsque je démarre mon nœud.js Server et Client est connecté, je suis en mesure d'envoyer une demande de client (socket.emit) et d'obtenir une réponse (socket.on («RentsAndound» ....)). Mais lorsque je connecte la deuxième heure, le client est capable d'envoyer, mais le serveur ne peut pas envoyer ou émettre. Je dois donc redémarrer le serveur à nouveau. Je comprends que cela fonctionne comme prévu, mais ma compréhension est malade quelque part ... quelqu'un voudrait signaler.
côté client:
======== côté serveur:
========
3 Réponses :
socket.IO 0.7 On va essayer de réutiliser des connexions au même hôte. Dans mon expérience, j'ai trouvé que ce comportement peut être un peu factice.
Je ne peux pas dire à la petite échantillon de code que vous avez fourni, mais je suspect le problème est que le deuxième appel à La solution de contournement consiste à transmettre l'option connect () essaie de réutiliser le premier Connexion (fermée).
'forcer nouvelle connexion' lorsque vous appelez connect () . Par exemple:
io.connect ("http: // localhost", {'Force nouvelle connexion': vrai});
Merci pour «Force New Connection» ... Je ne savais pas à ce sujet.
Merci beaucoup. Vous avez sauvé ma vie;) Je déteste ces nœuds / socket.io gars avec leurs mises à jour. Je n'ai presque jamais réussi à mettre à jour sans quelque chose qui tombe à part. J'ai développé sur 0.6 et récemment mis à jour le serveur de production. Et a reçu des plaintes de clients qu'il "ne fonctionne pas". Généralement, ce n'est pas si facile à tester tout correctement et changements comme ça ne le rend pas mieux.
Quelqu'un peut-il marquer cela comme la meilleure réponse puisque OP a dit cela fonctionnait?
FYI, il y a un effet secondaire ennuyeux à ce travail. Si vous utilisez un signe de nom d'espacement sur vos connexions de socket io.Connectez ('/ mysocket1') et io.connect ('/ mysocket2'), à l'aide de «la nouvelle connexion FORCE» les provoquera de ne pas partager une connexion comme indiqué par défaut; Ainsi, alors qu'il vous permettra de reconnecter les deux connexions perdues après une déconnexion forcée lorsque vous les reconnectez, ils auront chacun leur propre connexion.
Votre deuxième ligne rejette l'objet créé dans la première ligne. Cela devrait simplement fonctionner:
sio.set('transports', [
'websocket'
, 'flashsocket'
, 'jsonp-polling'
, 'xhr-polling'
, 'htmlfile'
]);
comme de socket.io 1.0, deux réglages contrôlent ce comportement:
Apparemment, les deux produisent exactement le même comportement.
La deuxième méthode est, à compter d'aujourd'hui, sans papiers. Toutefois, en regardant le code source, vous pouvez voir que toutes les options passées à Socket.io Server () sont transmises au constructeur de serveur de bibliothèque interne.IO, ce qui vous permet de modifier l'une des options. Ces options sont documentées ici:
"forcer nouvelle connexion": true , sur l'appel de connexion client ().
"cookie": faux , sur le constructeur serveur de serveur ().
Je n'ai pas vraiment tabouillé de sockets.io, mais d'après ce que je peux dire, vous ne fermez pas la connexion et votre écoute de l'événement de connexion. En théorie, votre première connexion ne ferait-elle que la réponse du serveur et les messages suivants ne feraient pas toucher cet événement?
Je suis désolé de ne pas fournir le code complet. Mais j'ai une déconnexion à la fois au client et au serveur .. Mise à jour du code en question ..
obtenu le problème tout en répondant à vos questions. En réalité, le code de la prise est tout simplement bien. Tout en se déconnectant du côté serveur, je déconnectais également la connexion de base de données et qui a créé le problème. Merci pour votre pointeur !!
Je ne peux pas répondre définitivement à votre question car vous n'avez pas inclus le deuxième appel à
Connect . Si vous avez besoin de, postez plus de code sur gist.github.com ou site équivalent et inclure un lien dans ta question.