Discussion :

[Alain Defrance]

Dans ce cas c'est différent, c'est une méthode à implémenter ..., et elle est déclenchée à la destruction d'un session. Elle ne la détruit en rien ...

[r1-1024]

Hello,

Si g bien compris ton pb, tu veux lister les clients connectés.

Dans tous les protocoles, même si il est prévu un évènement de déconnexion, il n'est pas possible d'associer un évènement, à la déconnexion d'un client de façon sure. Tout simplement parce que les raisons de cette déconnexion peuvent êtres multiples :
-kill -9 du client
-débranchement réseau qui n'invalide pas forcément les connexions (par ex sous linux)
-engorgement réseau
-etc...

Ce genre de pb ressemble furieusement aux gestions de licences par réseau.

La seule solution est de faire une connexion régulière sur ton serveur. Lorsqu'un client ne s'est pas connecté depuis un certain temps, tu invalides sa session (ya pas besoin de le faire sur un serveur d'application cf timeout, ton listener pourra alors retirer le client d'une liste).
On appelle cela du heartbeat.

Le pb c que c gourmand
Il y a donc plusieurs solutions :
-Si tu peux faire du tcp, conserve la connexion et fais le heartbeat dedans (c pas possible en flash mais oui en air il me semble).
-Limiter le délais de heartbeat (y a un petit calcul à faire sur le ratio délais_de_détection/nbr_de_clients_max) sachant que si tu ajoutes du https, ça va plomber les perfs.

Pour moi la meilleur solution étant de faire un get depuis flash. La servlet renvoie un xml avec :
-versions du protocole
-info persos
-et surtout le prochain délais de connection (heartbeat).

Ce délais te permet de limiter la casse. La servlet fonctionne un peu comme un garbage collector : plus un client est connecté depuis longtemps, plus il y aura de chance qu'il reste connecté encore longtemps. Donc tu peux augmenter régulièrement son délais de heartbeat. Le client renvoie un get à cette adresse au bout de (heartbeat-epsilon), epsilon étant le temps de traitement du heartbeat que tu peux évaluer côté client entre le get et la reponse.

Voili.

[Alain Defrance]

Pour moi la meilleur solution étant de faire un get depuis flash

Flash oO ?

[cashmoney]

Envoyé par r1-1024
il n'est pas possible d'associer un évènement, à la déconnexion d'un client de façon sure

Toute façon je ne travaille qu'avec des évènement sous flex, alors il est possible de déconnecter un client et de façon sure.

Envoyé par r1-1024
La seule solution est de faire une connexion régulière sur ton serveur.

Encore désolé mais ce n'est pas des communication réseau comme tu l'entends, c'est juste une application java côté serveur et une application flex côté client et quand je dis serveur, un serveur J2EE(Tomcat, JBoss, Glassfish).

Flex et Java communique comme un EJB communiquerait avec une simple classe Java.

Envoyé par Alain Defrance
Dans ce cas c'est différent, c'est une méthode à implémenter ..., et elle est déclenchée à la destruction d'un session. Elle ne la détruit en rien ...

Si elle ne la détruit en rien comme tu dis, alors je peux insérer la session.invalidate() dans la medthode sessionDestroy, ainsi du côté client, la méthode écoutant la fermerture de naviagteur appelera la sessionDestroy et lancera la session.invalidate().
Qu'est ce que vous en dites de cette solution??

[tchize_]

tout dépend, en quoi t'as la garantie que ton client sera bien notifié de la fermeture du navigateur? Ta solution est abordable (appeleter un servlet / service / autre du serveur qui ferais un session.destroy() ) et marcherais probablement dans 90% des cas, mais ne fonctionnerais pas, comme on l'a dit, dans les cas suivant:

1) le client perd sa connection adsl (perte réseau) -> impossible de faire ledit appel au serveur
2) le browser crash -> ton code flex ne sera jamais appelé
3) le browser ne notifiant pas flash / flex de sa fermeture (pas impossible que ca existe)



La question de base qu'on est occupé de se poser est, pourquoi t'as besoin d'invalider la session aussi vite, et que tu ne peux pas attendre les 30 minutes de timeout?

[Alain Defrance]

Si elle ne la détruit en rien comme tu dis, alors je peux insérer la session.invalidate() dans la medthode sessionDestroy, ainsi du côté client, la méthode écoutant la fermerture de naviagteur appelera la sessionDestroy et lancera la session.invalidate().

Non, si la session ne se détruit pas, la méthode ne sera pas appelée. Si tu fait la destruction dans cette méthode, alors elle ne sera jamais détruite par ton code.
C'est un listener, et au même titre qu'il est inutile de notifier l'ouverture de fenêtre concernée dans un windowsListener sous swing, il en est de même avec les sessions.

[r1-1024]

Toute façon je ne travaille qu'avec des évènement sous flex, alors il est possible de déconnecter un client et de façon sure.

Encore désolé mais ce n'est pas des communication réseau comme tu l'entends, c'est juste une application java côté serveur et une application flex côté client et quand je dis serveur, un serveur J2EE(Tomcat, JBoss, Glassfish).

Flex et Java communique comme un EJB communiquerait avec une simple classe Java.

Je persiste, c kif kif

Si tu ne veux pas avoir de clients qui ne déclarent pas leur déconnexion (une fuite ds le comptage quoi), t obligé de mettre un timeout sur la session.

Si tu veux avoir de la réactivité dans le comptage, le timeout doit être petit.

Ca c du heartbeat.
Si tu veux augmenter les perfs du serveur, il faut bidouiller avec un calcul de défaillance comme je t'ai dit.

Pour avoir pas mal bossé sur le sujet, j'peux t'affirmer que tu ne peux pas avoir d'évènement lié à une déconnexion autre que de faire du heartbeat (pense au kill -9 client, même si ton serveur écrit dans la réponse au moment du kill, sous linux il ne le verra même pas. Comment flash peut avertir qu'il vient de se faire butté, vu qu'il est mort).

Alors c'est sur que rajouter un évènement de déconnexion lorsque c'est possible, ça fait partie des trucs qui vont augmenter les perfs globales, mais tu ne peux pas compter dessus pour assurer le décomptage (tu dois prendre en considération que l'évènement peux ne jamais arriver jusqu'au serveur).
Mais qd ton serveur fonctionne depuis qq mois, sans le heartbeat tu auras des clients fantômes qui ne seront pas d'augmenter.

Si tu as 1000 clients, une coupure réseau de ton FAI serveur suffisamment longue te rajoutera 1000 clients fantômes dans ton comptage.

Pour t'en convaicres, tu peux matter la doc de flexLM (ça n'a rien a voire avec as3, mais bon courage).

A+

[cashmoney]

Merci à vous, je pense que je vais opter pour le time out. Si aucune réaction au bout de ce time out, déconnection. Je vais l'appliquer, mais je vais continuer de chercher de mon côté mon idée première, voir si elle tient.
Merci et bonne journée

[r1-1024]

G mis un peu de temps à retrouver ça ... mais je pense que ça peut être utile à d'autres qui travaillent sur le sujet (faut se réveiller un peu).

-Si on considère que la déconnexion d'un client est une loi de poisson (http://www.techno-science.net/?ongle...efinition=6212 pour ceux qui veulent chauffer), ce qui est pas mal du tout sauf pour les heures creuses du serveur (ça fait trop longtemps que j'suis au boulot donc je rentre, qui est incompatible avec la loi de poisson)
-Si T est le temps moyen de connexion (ici le temps entre la première requête du client et son évènement de déconnexion)
-Soit hb le délais de heartbeat.

Sans aucune stratégie d'optimisation des perfs serveurs, on trouve facilement un majorant de la précision du nombre de clients connectés : hb/T

Par exemple, mes clients restent connectés en moyenne 1h. Mon hearbeat est de 6 min (ici mon timeout session est de 6min et toutes les 6min mon client fait un get). Je connais donc mon nombre de client à chaque instant à 10% près (6/60=0.1).

On estime facilement le temps moyen de connexion avec le session listener
lors d'un sessionDestroyed

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
sessionDestroyed(HttpSessionEvent ev)
{
    HttpSession session=ev.getSession();
    long delay;
    synchronized(session)
   {
     delay=System.currentTimeMillis()-session.getCreationTime();
   }
 
   SessionTracking.getInstance().registerSessionDelay(delay);
}

SessionTracking peux ensuite faire une moyenne des délais comme il veut.

Maintenant si une autre loi de stat intervient (coupure du réseau serveur par exemple) on est dans les choux pendant le délais de heartbeat (ici on verra que tous les clients sont KO au bout de 6 min).

Maintenant le nombre de connexions par secondes liées au heartbeat est N/hb si N est le nombre de clients. (ici pour 1000 clients ça fait environ 3 requêtes par secondes ce qui commence à faire et pour 100 000 clients on approche les 300 requêtes/sec qui me semble être la limite de conf de base pour tomcat).

Voili

[r1-1024]

e vais l'appliquer, mais je vais continuer de chercher de mon côté mon idée première, voir si elle tient

Si tu as un moyen de compter plus finement (comme l'évènement de déconnexion) tu devrais l'inclure dans la boucle. Tu auras alors dans 90% des cas un comptage exacte mais en cas de coup dur tu peux compter sur le timeout.

A+

[cashmoney]

Meric l'ami, j'opte pour ta soluce... Bon après midi à tous