Détecter la fermeture du navigateur coté server

[Ter Rowan]

Je suis du même avis que Nico

en effet, quelle différence entre les comportements suivant :

- je ferme le navigateur
- je change de page pour aller sur un autre site
- j'ouvre une nouvelle fenêtre/onglet et je navigue ailleurs, oubliant de fermer la fenêtre/onglet du site en question

pour moi la question est donc que doit faire le serveur quand l'utilisateur/joueur quitte le site ?

donc, y a t il un traitement spécifique qui doit être fait sans intervention de l'utilisateur mais après que celui ci ait quitté ?

ou encore

ce traitement ne peut il être fait :
- à la fin de chaque page
- par un cron
- à la prochaine connexion ?

[Furukoo]

donc, y a t il un traitement spécifique qui doit être fait sans intervention de l'utilisateur mais après que celui ci ait quitté ?

ou encore

ce traitement ne peut il être fait :
- à la fin de chaque page
- par un cron
- à la prochaine connexion ?

Le traitement en question c'est d'informer les autres joueurs (encore connectés).
Aujourd'hui je simule cette notification avec du pooling, je cherchais à savoir
si une autre technique existait.
Et pour les WebSockets ... je suis preneur d'un tuto ... n'ayant jamais réussi à
l'implémenter moi même

Bonne journée

[Furukoo]

Bonjour à tous.

J'ai trouvé la réponse ici :
http://www.php.net/manual/fr/function.co...status.php

I was building a chat and I wanted my script to detect when the browser was closed, so the user could be deleted from the online_users table.

echo str_repeat(" ",300);

ignore_user_abort(true); //this way, the user can stop the output, but not the script.

while (true) {

         echo "test<br>\n";

         flush();

         sleep(2);

         if (connection_status()!=0){

                 include ('dbconnect.inc');

                 $sql="delete from online_users where online_user=$user";

                 $sql_exec=pg_exec($vChatDB, $sql);

                 die(); //kills the script

         }

}

J'espère que ça peut vous aider.

Bonne journée

[Sephi-Chan]

Du coup tu es resté sur le choix du long polling.
Quel serveur utilises-tu ? Si c'est Apache ou IIS, il me semble qu'ils ne sont pas très forts quand il s'agit de laisser traîner une connexion. Surtout que dans ton cas, tu risques d'en avoir pas mal !


Sephi-Chan

[NicoMSEvent]

il faut aussi faire gaffe a la limite des 30 sec d'exécution pour un script PHP, et puis apache ne permet (sans aucune modif) 10 connexion simultanées, il me semble.

Donc, si on considère cela, je ne crois pas que ce soit la meilleure solution

[niahoo]

Pour la limite du temps d'exécution , tu peux utiliser la fonction set_time_limit.

Pour le serveur, oublies apache effectivement. Mais il y en a d'autres !

echo str_repeat(" ",300);

ignore_user_abort(true); //this way, the user can stop the output, but not the script.

while (true) {

         set_time_limit(5)

         echo "test<br>\n";

         flush();

         sleep(2);

         if (connection_status()!=0){

                 include ('dbconnect.inc');

                 $sql="delete from online_users where online_user=$user";

                 $sql_exec=pg_exec($vChatDB, $sql);

                 die(); //kills the script

         }

}

[Ieyasu]

Possibilité de bidouiller en Javascript avec un petit module Ajax.

Lorsque l'utilisateur se connecte et s'identifie, le module lui attribut un identifiant unique lié à son compte, ainsi qu'un timestamp.

Le script est minimal, et ne perdure pas dans le temps.

Toutes les 15 secondes (admettons), le module rafraichit le Timestamp sur l'identifiant correspondant.
A chacune de ces vérifications, le script vérifie les timestamps de toutes les connexions stockés dans la table, si une connexion possède un timestamp vieux de plus de 30secondes, c'est que le module ne l'a pas rafraichit.

Inconvénients de cette méthode : Le serveur ne reconnait pas "la fermeture du navigateur" lorsqu'il y a une seule personne connecté.
Autre soucis : Lorsque de nombreuses personnes sont connectés, le serveur multiplie les vérifications, augmentant la charge de la base de donnée par la même.


Solution possible : Exécution d'un script shell sur le serveur, avec un sleep(30) qui lance le script php de vérification des timestamp, de cette façon le serveur ne se surcharge pas puisqu'on aura toujours qu'un seul script de vérification qui tournera.

Je ne sais pas si c'est là une solution à ton problème ni si c répond a tes besoins.

[Furukoo]

Du coup tu es resté sur le choix du long polling.
Quel serveur utilises-tu ? Si c'est Apache ou IIS, il me semble qu'ils ne sont pas très forts quand il s'agit de laisser traîner une connexion. Surtout que dans ton cas, tu risques d'en avoir pas mal !


Sephi-Chan

Oui pour l'instant je suis sur du long polling. J'utilise Silverlight.
Je fais pas un long polling infini.
Je fais un long polling de 30 secondes.
Ce qui veux dire que toutes les 30 secondes je ferme et je réouvre une connection HTTP
sur le port 80.
J'en profite pour "timestamper" le client ^^
Si le serveur (Apache) ferme la connection, Silverlight détecte (cotè client donc) la fermeture et relance une boucle.
Sur les limitations du nombre de connections simultanées (Apache) je ne sais
pas trop répondre.
Je redéveloppe un mini chat sur ce principe. quand c'est au point je vous le dirais.

Bonne soirée

[niahoo]

Pourquoi couper toutes les 30 secondes au lieu de maintenir la connexion ?

[Furukoo]

Pourquoi couper toutes les 30 secondes au lieu de maintenir la connexion ?

Je signale en début de script la présence du client. (timestamp)
Il y a une mise à jour de la liste des clients connectés à ce moment.
Ensuite je fais la boucle d'attente des nouveaux messages.
Je répète ça toutes les 30 secondes.
C'est cette partie qui est "criticable" effectivement et que je cherche à améliorer un peu.