2009-12-15 4 views
4

Je voudrais saisir les paramètres suivants:Comment suivre l'état en ligne de l'utilisateur?

lastAccessedTime - Le moment où l'utilisateur a visité le site pour la dernière fois (habituellement montré au cours du processus de connexion)

isOnline - Valeur booléenne pour représenter si un utilisateur est en ligne ou non.

a. Serait-il logique d'avoir ces variables dans le tableau des utilisateurs lui-même ou devrait-il être géré par une table d'audit utilisateur distincte?

b. Si certaines API SOAP/REST exposent la fonctionnalité via des appels d'API, comment suivez-vous les paramètres ci-dessus (par exemple, modifieriez-vous lastAccessedTime) - cela pourrait troubler l'utilisateur s'il se connecte au portail, le bit isOnline n'aurait pas de sens si l'utilisateur fait des appels d'API).

Répondre

6

Je créer une table de session qui renvoie vers l'utilisateur. Au lieu d'un champ isOnline, je voudrais simplement lancer une requête pour les sessions qui ont été actives au cours de la dernière période x. Je voudrais également mettre à jour ce champ de session avec chaque demande, même si cette demande passe par une API. Cela crée une certaine surcharge lors de l'élagage de la table de session, mais vous n'encombrez pas non plus votre table utilisateur avec des informations non utilisateur, qui ne peuvent pas être élaguées.

3

Faites de lastTimeActive un champ dans la table utilisateur et mettez-le à jour avec chaque accès à la page. Votre liste "Utilisateurs en ligne" désigne tous les utilisateurs dont le dernier élément est TimeTimeActive dans les 5 minutes.

1

Je voudrais créer une autre table (userid, lastTimeActive), et fréquemment mettre à jour & vérifier la table.

// update 
update onlineusers set lastTimeActive = getdate() where userid=1234 

// check 
delete from onlineusers where lastTimeActive < dateadd(minute,-5,getdate()) 
+0

Oh non ... c'est horrible ... ça va tuer votre serveur ... – Faruz

+1

Je maintiens un portail avec plus de 1000.000 utilisateurs. Mais il n'y a que 100 utilisateurs en ligne à la fois (moins de 1%). Il est préférable de sélectionner/mettre à jour/supprimer une nouvelle table plutôt que d'interroger la table utilisateur. –

1

Le plus gros problème avec le suivi de la présence de l'utilisateur (onine/offline) sur HTTP est comment déterminer quand l'utilisateur est déconnecté.

Il est facile de déterminer quand l'utilisateur est en ligne - la simple présence d'une requête authentifiée suppose que l'utilisateur est actif. Cependant, puisque HTTP est sans état, l'absence d'une requête ultérieure peut signifier soit que l'utilisateur est déconnecté, soit que l'utilisateur est en ligne, mais n'a rien fait de spécifique avec votre application récemment.

Ainsi, la meilleure estimation que vous pouvez faire est d'avoir un timeout et si l'utilisateur n'a pas fait une requête pendant ce délai, de passer en mode hors ligne.

L'implémentation la plus simple serait d'avoir un LastTimeActive, comme Jonathan Sampson l'a suggéré. Cependant, cela ne vous donnera pas la longueur de la session utilisateur, seulement une approximation de qui est en ligne en ce moment.

Une approche plus complexe serait d'avoir lastTimeActive et lastTimeLoggedIn. LastTimeLoggedIn est défini au moment de la première demande d'autorisation qui est à plus de 5 minutes d'une demande d'authentification précédente. Un utilisateur est considéré en ligne, s'il y a eu une demande authentifiée au cours des cinq dernières minutes. La longueur de session pour l'utilisateur est la différence de temps entre lastTimeActive et lastTimeLoggedIn.

Si votre application offre également le choix de se déconnecter de l'utilisateur, vous pouvez considérer cette action comme étant hors ligne. Cependant, à moins que votre application ne soit une application bancaire, il est probable que les utilisateurs ferment leur navigateur.

De même, évitez les threads d'arrière-plan pour mettre à jour le statut hors ligne/en ligne de vos utilisateurs.Vous ne devriez exécuter la logique ci-dessus que lorsqu'il y a une demande explicite sur le statut d'un utilisateur particulier et que vous ne devriez mettre à jour que les utilisateurs qui vous ont été demandés.

Questions connexes