Gestion particulière de sessions
Utilisateur anonyme
-
13 nov. 2007 à 10:04
neigedhiver Messages postés 2480 Date d'inscription jeudi 30 novembre 2006 Statut Membre Dernière intervention 14 janvier 2011 - 13 nov. 2007 à 14:41
neigedhiver Messages postés 2480 Date d'inscription jeudi 30 novembre 2006 Statut Membre Dernière intervention 14 janvier 2011 - 13 nov. 2007 à 14:41
A voir également:
- Gestion particulière de sessions
- Cahier des charges gestion de stock - Forum Java
- Interface logiciel de gestion de stock - Forum Java
- Tableau gestion des clés ✓ - Forum VB.NET
- [Clos] cahier des charges d'une application de gestion des stocks et achats clas - Forum Java
- Gestion association joomla - Forum PHP
3 réponses
neigedhiver
Messages postés
2480
Date d'inscription
jeudi 30 novembre 2006
Statut
Membre
Dernière intervention
14 janvier 2011
19
13 nov. 2007 à 12:59
13 nov. 2007 à 12:59
Salut,
Tout d'abord, le serveur n'a absolument aucun contrôle sur le navigateur. Il se contente de lui envoyer les fichiers que celui-ci demande, ça s'arrête là.
Les sessions servent à conserver des informations lors de la navigation sur le site, sans avoir besoin de les demander à chaque fois. Le cas le plus courant étant l'identification d'un utilisateur, mais aussi le thème graphique, la langue, bref, quelques paramètres permettant une navigation plus agréable.
Utiliser les sessions pour autre chose peut ne pas fonctionner comme on l'attend.
Sache par ailleurs qu'il est tout à fait impossible d'avoir le nombre d'utilisateurs connectés en temps réel. Ce qu'on voit couramment sur les sites, ce sont les membres qui ont eu une activité pendant les X dernières minutes ou secondes. On ne peut pas faire mieux : c'est lié au premier point de mon explication.
Ce qui se fait le plus souvent, c'est une gestion des connexions par une base de données. Toujours le plus souvent, la base de données sert à stocker les variables de session. En effet, les sessions ne permettent de conserver ces données qu'un temps limité et sont associées à une session, laquelle est identifiée par un paramètre dans l'url, ou un cookie. Sans la présence de ceux-ci, une nouvelle session est générée, les informations sont perdues.
Stocker les variables de sessions dans une base de données permet de les associer non pas à un cookie ou un paramètre dans l'url, mais à un utilisateur, ce qui permet de les restituer à sa prochaine connexion.
Pour en venir à ton problème, il te faut trouver ce qui te convient le mieux... Soit stocker tes informations de sessions dans une base de données, ou sur tout autre support (fichier, etc). Si la base de données est le mode de stockage le plus courant, ce n'est pas pour rien : c'est le plus facile à mettre en oeuvre, sans trop de pertes de performances (tout est relatif : disons simplement que les performances sont tout à fait acceptable quand le traffic n'est pas de plusieurs millions de visites par seconde).
En stockant tes informations de sessions dans une base de données (avec la date de création et la date de mise à jour) tu peux facilement compter combien d'utilisateurs ont eu une activité dans les X dernières minutes.
Tout ceci n'a de valeur que dans le contexte que tu décris : un chat en php.
Pour avoir les statistiques de fréquentation en temps réel, il faudrait une application client/serveur, ce qui n'est pas le cas de php.
Tout d'abord, le serveur n'a absolument aucun contrôle sur le navigateur. Il se contente de lui envoyer les fichiers que celui-ci demande, ça s'arrête là.
Les sessions servent à conserver des informations lors de la navigation sur le site, sans avoir besoin de les demander à chaque fois. Le cas le plus courant étant l'identification d'un utilisateur, mais aussi le thème graphique, la langue, bref, quelques paramètres permettant une navigation plus agréable.
Utiliser les sessions pour autre chose peut ne pas fonctionner comme on l'attend.
Sache par ailleurs qu'il est tout à fait impossible d'avoir le nombre d'utilisateurs connectés en temps réel. Ce qu'on voit couramment sur les sites, ce sont les membres qui ont eu une activité pendant les X dernières minutes ou secondes. On ne peut pas faire mieux : c'est lié au premier point de mon explication.
Ce qui se fait le plus souvent, c'est une gestion des connexions par une base de données. Toujours le plus souvent, la base de données sert à stocker les variables de session. En effet, les sessions ne permettent de conserver ces données qu'un temps limité et sont associées à une session, laquelle est identifiée par un paramètre dans l'url, ou un cookie. Sans la présence de ceux-ci, une nouvelle session est générée, les informations sont perdues.
Stocker les variables de sessions dans une base de données permet de les associer non pas à un cookie ou un paramètre dans l'url, mais à un utilisateur, ce qui permet de les restituer à sa prochaine connexion.
Pour en venir à ton problème, il te faut trouver ce qui te convient le mieux... Soit stocker tes informations de sessions dans une base de données, ou sur tout autre support (fichier, etc). Si la base de données est le mode de stockage le plus courant, ce n'est pas pour rien : c'est le plus facile à mettre en oeuvre, sans trop de pertes de performances (tout est relatif : disons simplement que les performances sont tout à fait acceptable quand le traffic n'est pas de plusieurs millions de visites par seconde).
En stockant tes informations de sessions dans une base de données (avec la date de création et la date de mise à jour) tu peux facilement compter combien d'utilisateurs ont eu une activité dans les X dernières minutes.
Tout ceci n'a de valeur que dans le contexte que tu décris : un chat en php.
Pour avoir les statistiques de fréquentation en temps réel, il faudrait une application client/serveur, ce qui n'est pas le cas de php.
Utilisateur anonyme
13 nov. 2007 à 14:24
13 nov. 2007 à 14:24
D'accord. Donc ca veut aussi dire que les mesures de médiamétrie sont toutes fausses ?
neigedhiver
Messages postés
2480
Date d'inscription
jeudi 30 novembre 2006
Statut
Membre
Dernière intervention
14 janvier 2011
19
13 nov. 2007 à 14:41
13 nov. 2007 à 14:41
Re,
Je vois pas le rapport avec Médiamétrie...
Pour PHP, le fait est que le serveur HTTP n'intéragit pas avec le client. Il envoie des données en fonction d'une requête reçue, c'est tout.
Au contraire, une application client/serveur ne se contente pas de cela puisque le client envoie des informations au serveurs qui sont prises en compte à chaque instant. Ainsi, lors de la déconnexion, le serveur est aussitôt informé que l'utilisateur se déconnecte.
En PHP, ce n'est pas le cas. En tout cas, pas forcément. Le script est exécuté une fois, point barre. Il ne tourne pas en tâche de fond, comme un démon (serveur).
Avec un chat PHP, il y a deux manières de se déconnecter : cliquer sur un bouton déconnecter, ou fermer le navigateur. Dans le premier cas, on peut effectivement savoir que l'utilisateur s'est déconnecté et tenir compte instantanément de l'événement. Dans le second, il est IMPOSSIBLE de savoir si l'utilisateur est toujours connecté ou pas.
La différence vient du fait que la déconnection est confiée à l'utilisateur, et pas à une application autonome. Si l'utilisateur omet de se déconnecter, le serveur le considère comme toujours connecté. D'où la nécessité d'avoir un temps de latence. On peut décemment considérer que les personnes connectées sur un chat sont celles qui ont une activité régulière et à petits intervalles (5 minutes pour un site web classique, 1 à 2 minutes maxi pour un chat).
Je sais pas si je suis bien clair, mais il n'y a pas de connexion persistante entre le navigateur (IE, FF, Opera, Safari, Lynx, ou autre) et le serveur HTTP comme il y a une connexion persistante quand on passe un coup de téléphone.
Dans une application client/serveur, le serveur peut envoyer une requête au client pour s'assurer qu'il est toujours connecté. PHP ne PEUT PAS faire ça.
Je vois pas le rapport avec Médiamétrie...
Pour PHP, le fait est que le serveur HTTP n'intéragit pas avec le client. Il envoie des données en fonction d'une requête reçue, c'est tout.
Au contraire, une application client/serveur ne se contente pas de cela puisque le client envoie des informations au serveurs qui sont prises en compte à chaque instant. Ainsi, lors de la déconnexion, le serveur est aussitôt informé que l'utilisateur se déconnecte.
En PHP, ce n'est pas le cas. En tout cas, pas forcément. Le script est exécuté une fois, point barre. Il ne tourne pas en tâche de fond, comme un démon (serveur).
Avec un chat PHP, il y a deux manières de se déconnecter : cliquer sur un bouton déconnecter, ou fermer le navigateur. Dans le premier cas, on peut effectivement savoir que l'utilisateur s'est déconnecté et tenir compte instantanément de l'événement. Dans le second, il est IMPOSSIBLE de savoir si l'utilisateur est toujours connecté ou pas.
La différence vient du fait que la déconnection est confiée à l'utilisateur, et pas à une application autonome. Si l'utilisateur omet de se déconnecter, le serveur le considère comme toujours connecté. D'où la nécessité d'avoir un temps de latence. On peut décemment considérer que les personnes connectées sur un chat sont celles qui ont une activité régulière et à petits intervalles (5 minutes pour un site web classique, 1 à 2 minutes maxi pour un chat).
Je sais pas si je suis bien clair, mais il n'y a pas de connexion persistante entre le navigateur (IE, FF, Opera, Safari, Lynx, ou autre) et le serveur HTTP comme il y a une connexion persistante quand on passe un coup de téléphone.
Dans une application client/serveur, le serveur peut envoyer une requête au client pour s'assurer qu'il est toujours connecté. PHP ne PEUT PAS faire ça.