Nodejs - Fermeture de connexion

[niahoo]

Mais ton joueur côté serveur, il est bien identifié par son ID nan ? donc tu peux ne pas le compter plusieurs fois …

[Damocorp]

C'est justement la que ca coince. Apparemment Opéra ouvre une nouvelle connexion à chaque fois.

J'ai lu qu'il était possible de reprendre la connexion si elle existe, mais certains article sur le net le déconseil. Mais j'ai pas encore trouvé pourquoi, c'était pas clair puisqu'en anglais

[niahoo]

Ben pareil que précédemment, si tu ouvres 1 ou 50 000 connextions, le joueur est identifié non ? ça ne devrait pas vraiment poser de problèmes.

[Damocorp]

Je te suis pas la. Bien sur que si ca pose un problème.

Imagine que je ne vérifie pas les doublons partant du principe que le joueur est identifié.
X étant notre joueur.

X se connecte et obtiens son ID. Il est affiché en tant que connecté.
X change de page et reviens et obtient un autre ID ( sous opéra ). Il est affiché en double dans les connectés car deux connexions sont ouvertes.

Quelque secondes après l'un d'eux disparait. Ca ferai plutôt bizarre non ? Et je suis sur que ca serai super tentant pour lui de faire afficher son nom 50 fois
Donc construire une liste des connectés en se basant sur le 'disconnect' n'est pas viable à mon sens puisqu'Opéra ne semble pas encore prêt.

[Sephi-Chan]

Il faut considérer la liste des connectés comme un ensemble (en anglais, set). Une collection (pas forcément ordonnée) ne pouvant contenir qu'une fois une même valeur (ici, les identifiants des joueurs connectés).

Et de toute façon tu ne devrais pas te fier aux événements de déconnexion émis par le navigateur car ils peuvent ne pas être émis (coupure d'alimentation, coupure du réseau, plantage du navigateur, mise en veille de l'ordinateur portable, etc.). Tu peux t'en servir pour le confort mais la seule chose fiable est la coupure de la connexion au niveau du serveur.

[niahoo]

Après je sais pas comment fonctionne node... mais sur un système erlang qui est asynchrone aussi, j'ai une liste de connectés .. si opera envoie un event deconnection, je ne fais rien, par contre quand mon joeur a pas envoyé d'infos depuis X secondes je considère qu'il est déco et je le vire de ma liste. Comme ça celle-ci est toujors à jour.

Mais effectivement je dépends d'un timeout pour afficher les déco, je ne sais pas afficher la déco immédiatement. Sinon, je le considèrerais comme déco alors qu'il a peut être d'autres communications en cours via simili-socket

---

X se connecte et obtiens son ID. Il est affiché en tant que connecté.
X change de page et reviens et obtient un autre ID ( sous opéra ).

Pourquoi une autre ID ? il faut lui donner son ID de joueur unique, comme ça, comme dit sephi tu peux trier les doublons.

[quentin01]

Node.JS avec Socket.IO n'ont pas de système de session. Peu importe le navigateur si le joueur actualise la page il change d'ID. Il faut donc faire toi même ton système d'authentification. Tu utilises un ID que le client connait et qui l'envoit au serveur juste après l'initialisation de la connexion pour l'identifier côté serveur. Cette ID peut être par exemple l'ID de session PHP si ton système est couplé à PHP, ou tout simplement un ID au hasard que tu lui donnes et qu'il stocke en cookie ( ou en local storage ) lors de la première connexion.

[Damocorp]

Pourquoi une autre ID ? il faut lui donner son ID de joueur unique, comme ça, comme dit sephi tu peux trier les doublons.

Je parlais de l'id obtenu via socket.id, l'id attribué automatiquement par nodejs ou socket.io lors de la connexion d'un client.

Je vais faire des tests sur l'event timeout pour voir, mais d'après la doc et ce que j'en ai vu. Je ne devrai pas avoir de problème avec.

Et merci pour votre aide !

[niahoo]

Node.JS avec Socket.IO n'ont pas de système de session. Peu importe le navigateur si le joueur actualise la page il change d'ID. Il faut donc faire toi même ton système d'authentification. Tu utilises un ID que le client connait et qui l'envoit au serveur juste après l'initialisation de la connexion pour l'identifier côté serveur. Cette ID peut être par exemple l'ID de session PHP si ton système est couplé à PHP, ou tout simplement un ID au hasard que tu lui donnes et qu'il stocke en cookie ( ou en local storage ) lors de la première connexion.

Oui ça ok, j'avais un équivalent (l'id du processus) sur mon système. Mais bien sûr je ne m'en servais pas pour identifier le joueur, juste le transport (la connexion quoi). Ce n'est pas un problème si le mec à 5 onglets ouverts sur le jeu du coup, ça fait 5 connexions mais le jeu sait que c'est le ^même joueur