Discussion :

[xavier3333]

Bonjour,

Je n’arrive pas un résoudre un problème de reconnexion à une socket.
Quand on fait de la Socket.IO avec Node.JS, on utilise la commande suivent côté client :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var socket=io.connect('http://127.0.0.1:80');

Est cela fonctionne très bien.
Mais le fait d’exécuter cette commande à chaque chargement de la page peut causer un problème. Car chaque fois que cette commande est exécutée, il crée un nouvelle connexion avec le serveur. Et c'est là tout le problème, il ne va pas se reconnecter à la socket déjà existante. On peut constater l'erreur dans la console de Firefox :

La connexion avec ws://127.0.0.1/socket.io/?EIO=3&transport=websocket a été interrompue pendant le chargement de la page. socket.io.js:5310:15

Cela est très gênant quant on fait de la session avec les sockets, car la session est perdue à chaque chargement de page. Il faut donc mettre une condition quand la page se charge, qui dit que si il y a déjà une connexion existante, on se reconnecte à la socket. Sinon on crée une nouvelle connexion.

Je n'ai pas trouver de réponse à ce problème (personne n’évoque cette problématique sur internet).
Un grand merci à ceux qui pourront m'aider.

[sekaijin]

Ce n'est pas fait pour ça.
L’idée d'ouvrir un socket c'est pour faire communiquer deux Prog. entre eux.
il convient de connecter le socket,
le garder ouvert tout le temps nécessaire,
puis de le fermer.

c'est donc bien adapté pour les singlePage App
Lorsque l'application se lance, elle ouvre la connexion
la garde ouverte tout le temps
échange avec le serveur via le socket
et la ferme à la fin

Ce n'est pas du tout adapté au page web.
le navigateur ouvre une page
la page est plus ou moins autonome et ne communique quasiment pas avec le serveur (à l'origine elle ne communiquait pas du tout)
le navigateur change de page.
Et ça recommence.

À chaque changement de page, on recommence tout.
en mode multi page (classique)
On passe son temps à ouvrir et fermer des pages.
on peut leur ajouter de la com avec le serveur
Mais par définition, une page est volatile.
C’est pour cette raison que XHR est né.
Il est bien adapté à ce mode de fonctionnement.

Avec le temps et l'arrivée des SinglePage App, ce mode de communication est devenu insuffisant.
En effet, on a une app client qui est active pendant des heures (j'en ai qui tournent plusieurs jours),
Et devoir ouvrir une requête HTTP à chaque fois est une contrainte coûteuse.
Sont donc nés les connexions permanentes comme les websocket.

Utiliser une connexion volatile (requête HTTP) depuis une application permanente peut être utile pour une communication ponctuelle.
Lorsque la communication devient fréquente, depuis une telle application mieux vaut utiliser une connexion qui elle aussi est permanente.

Utiliser une connexion volatile depuis une page volatile semble être logique.
Utiliser une connexion permanente depuis une page volatile c'est comme construire une voie de TGV pour desservir une cabane en bois dont la durée de vie est d'un seul jour.

Cela ne signifie pas que ce soit impossible. J’attirais juste ton attention sur l'absurdité de la chose.
la solution
lorsque la page ouvre le socket, garder une référence sur ce socket
lorsqu’on change de page, il se passe deux choses
unload de la page -> load de la page suivante
sur le onUnLoad de la page courante
Il faut fermer la connexion.

En clair cela revient à utiliser une techno faite pour les connexions permanentes pour mettre en oeuvre une connexion volatile.

Je pense que tu peux tester la fermeture du socket
Mais je pense que tu devrais sérieusement réfléchir à cette communication.
Soit ton appli peut être transformée en SinglePage (changement dynamique du contenu de la même page) et tu bénéficieras pleinement de la communication permanente.
Soit ton appli est fondamentalement multi-page et tu as peut-être intérêt à utiliser un autre mode de communication.
A+JYT

[xavier3333]

Merci pour ta réponse.
Je croie que j'ai bien compris ce que tu ma expliquer.
Soi je change dynamiquement le contenu de ma page ,comme ça elle n'est pas rafraichi et je peut utiliser le WebSocket comme méthode de communication.
Soi je choisi un autre mode de communication comme le BUS par exemple.
Et pour faire disparaitre l'erreur il faut fermer la Socket (chose que je ne fessai pas jusque à présent).
Mai dans c'est cas la à quoi serve les modules de session pour Socket.io ?
J'ai réussi à faire de l’authentification (session) avec de l'Ajax en POST.
Mai le problème se pose quant on veux vérifier l’authentification coté serveur à la suite d'une demande d'action côte client.
On peut le faire en Ajax, mai dans c'est cas la, on n'eut peut pas communiquer à tout les client pour maitre à jour les info suite à l'action qui vient d'aitre faite.
Car on ne peut pas faire du WebSocket dans un événement GET avec Node.JS.
Donc je me suis dit la meilleur solution est d'utiliser le module de session de WebSocket (express-socket.io-session).
Mai on peut peut être faire du BUS dans un événement GET !
Je préférer quand même faire du WebSocket, c'est tellement plus simple à maitre en n’œuvre avec Node.JS.
J'espère que je me suis bien fais comprendre.
Que pence tu de cette problématique ?

[xavier3333]

OK C'est bon j'ai réussi à récupérer la session dans une Socket.
Donc plus de problème je peut faire ce que je veux.
Un grand merci sekaijin.
Pour info :
C'est impossible de reconnecter une Socket car j'ai fait un console.log sur l'id de la Socket côté serveur est elle est détruite au rechargement de la page qui li est fermeture ou non de la Socket.