Discussion :

[djiga4me]

Bonjour,
Grand bug qui se faufile !
Mon Appli Serveur communique avec des Clients, et normalement (d'après la source) détecte lorsque le client se déconnecte (pour x raison). Et avant tout fonctionnait bien, mais depuis quelques temps, le serveu ne détecte pas ça.
J'ai testé ça sur un réseaux virtuel, sans succès, et sur un "vrai" physique aussi. Et le serveur (sous Windows7) ne détecte que le client n'est plus là que lorsque l'ordinateur du client (sous windows xp) pendant le redémarrage (après la fin du rechargement de Windows)..

C'est un peu long comme explication.
Mais auriez vous une idée ? une piste à suivre ? Je n'ai pas modifié le code du networking, qui avant marchait normalement !

[ShaiLeTroll]

Utilise un système de KeepAlive, tu envoies toutes les 5 secondes à tes clients une très petite requête, tu verras très vite lesquels ont été déconnecté violemment (echec du send, en TCP\IP tu as un ACK pour la bonne reception d'une TRAME, et NAK dans le cas contraire)
C'est un peu le principe de TimeOut !
En WAN, cela arrive très souvent de ne pas avoir le signal de déconnexion, faut savoir le contourner ...

[djiga4me]

Oui, c'est un bonne idée, mais ça un désavantage, ça risque de surcharger le réseau non ?
En plus, comment ça se fait qu'avant ça marchait normalement !?!

[ShaiLeTroll]

Cela peut venir du réseau lui-même, une passerelle, un routeur,...
Pour la surcharge du réseau, si tu envoie une petite trame, (un code + TimeStamp) et idem en retour (tu peux ainsi synchroniser tes horloges), ça ne fait à peine que 10o/s (du moins de données, ça doit faire 100o/s avec les entêtes de protocol)

[mick605]

Salut

C'est bien toi qui utilisait les composants IdTCPServer et IdTCPClient ? Dans ce cas, l'évenement OnDisconnect du server te permet de savoir quand un utilisateur se déconnecte. J'utilise ca, et quelque soit la manière dont la personne se déconnecte (proprement ou pas), je n'ai jamais eu de probleme ...

Sinon, tu n'as qu'a essayer en mettant un serveur et un client sur ta fiche, et en spécifiant comme adresse hote, l'adresse de loopback : 127.0.0.1 . Ainsi, tu verra vite si le probleme vient de ton réseau ou pas ^^

Bonne chance

[djiga4me]

C'est bien toi qui utilisait les composants IdTCPServer et IdTCPClient ?

Bonjour,
c'est exact ! Encore moi !
J'utilise l'évènement OnDisconnect, et avant ça marchait, et maintenant (sans que je mode quoique ce soit) ça ne marche plus, j'ai essayé sous VirtualBox et sur deux vrais réseaux, et ça ne marche pas !

Je vais tester ce soir la méthode que vous dîtes, mais je n'ai pas bien compris, pouvez m'expliquer le truc !
- sur la même fiche ?
- et comment puis-je tester la "chose" ?!
Merci encore !

[mick605]

Je vais tester ce soir la méthode que vous dîtes, mais je n'ai pas bien compris, pouvez m'expliquer le truc !
- sur la même fiche ?
- et comment puis-je tester la "chose" ?!
Merci encore !

Non, en fait, tu ne modifies rien a tes programmes, sauf la ligne :

Code :

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

IdTCPClient1.Host:='127.0.0.1'

sur l'appli client. Ensuite, sur le même poste, tu exécutes ton appli serveur et ton appli client. Ainsi, meme si tu n'es connecté a aucun réseau, tu peux simuler un réseau local. L'adresse 127.0.0.1 correspond en fait a l'adresse de ton ordi.

Comme ca, tu es sur que tu n'auras aucune perte d'information, en plus, tu n'as besoin que d'un seul ordinateur pour faire tes tests. Quand ton appli fonctionnera, tu pourra la distribuer sur tous les postes qui en ont besoin !

Un conseil quand même : dans le cas d'une appli réseau comme la tienne, coté serveur, j'affiche a l'écran (dans un mémo par exemple) tout ce que le composant recoit et envoie, et le destinataire. Ainsi, tu peux vérifier que tes applis communiquent bien comme tu le souhaites. Tu pourras ensuite supprimer le mémo quand ton appli sera 100% fonctionnelle !

Quant a ton probleme, je pense avoir une petite idée (quelque chose qui m'est déja arrivé). Peut être tu envoie a ton serveur un message a partir de ton client, et ce message est mal traité par le serveur, et fait bugger le programme (boucle infinie, violation d'acces). Et dans ce cas, le serveur ne réponds plus a rien ... Essaye de lancer l'exécutable du client normalement, et de lancer le serveur en mode débuggage par Delphi. Tu met quelques points d'arrets sur ton programme, et tu lances. Tu pourras mieux cerner ton probleme.

Bonne chance

[djiga4me]

Bonjour,
Et merci pour l'info.
En fait pour ce qui est du client et du Serveur sur le même poste, c'est ainsi que je procède et je met seulement localhost au nom d'hôte, c'est la même chose. Mais dans ce cas, je me peux pas simuler le truc qui cause qui cause le problème, car c'est en redémarrant le pc que ça arrive : le signale de déconnexion n'arrive que lorsque le client (après démarrage) essaie de se reconnecter, et en mode débogage, rien avant la reconnexion, et à la reconnexion je vois une exception : "Connection reset by peer", mais ça arrive tard !

Et ce qui est bizarre, c'est que si je tue le processus avec le gestionnaire des tâches (sur un vrai réseau ou sous VirtualBox) , le serveur se rend bien compte que le client est déconnecté.

Et même avec les version anciennes (les backups que j'ai faits) qui marchaient normalement ne marche pas maintenant, même souci.

[mick605]

Oula, c'est de plus en plus bizarre ...

Quelques idées qui me viennent a l'esprit :
Peut être que quand tu fermes ton client, tu ne termines pas bien le processus que tu utilises, et donc ton client est toujours connecté.
Ensuite, peut être que tu as un TimeOut de déconnection sur le serveur assez élevé, et quand tu redémarres l'ordi de ton client, tu obliges windows a tuer le processus, mais le timeout se déclenche pendant le rallumage du pc client ...

C'est la seule idée qui me vienne a l'esprit ... Vérifie que le processus est bien terminé quand tu fermes ton client. D'ailleurs, donne nous le code de fermeture de ton appli client. Si tu cliques simplement sur la croix, donne nous l'évenement OnClose de ta form.

Bonne chance !

[djiga4me]

Comme vous dîtes, c'est de plus en plus bizarre.
Au fait si je ferme le client normalement avec la croix !! Ou même si je le tue avec le gestionnaire des tâches, le serveur se rend compte de la déconnexion.
Par contre, si je redémarre la machine du client brutalement, le serveur ne se rend compte de rien, sauf à la prochaine re-connexion !! (Ce qui me dit qu'il y a un truc qui n'est pas libéré, un thread qui se termine pas, ...etc. Mais en regardant le code, je ne trouve rien de louche !)

Et normalement, en tuant le processus avec le gestionnaire des tâches, il n'a pas le temps d'envoyer quoi que ce soit au PC serveur, et c'est un peu la même chose en redémarrant !

[Andnotor]

Et normalement, en tuant le processus avec le gestionnaire des tâches, il n'a pas le temps d'envoyer quoi que ce soit au PC serveur, et c'est un peu la même chose en redémarrant !

Ca dépend ce que tu appelles "tuer le processus avec le gestionnaire des tâches"

Depuis l'onglet Applications, c'est une fermeture tout à fait normale qui est demandée (WM_CLOSE ou similaire), alors que depuis l'onglet Processus, c'est un TerminateProcess qui est invoqué.

[djiga4me]

Je le fais d'après l'onglet Processus.
Donc je pense que ça ne laisse pas le temps à l'application de réagir, non ?

[mick605]

Je le fais d'après l'onglet Processus.
Donc je pense que ça ne laisse pas le temps à l'application de réagir, non ?

Non ce n'est pas ca. Je viens de faire le test, et tuer le processus n'empeche pas l'evenement OnDisconnect du serveur. Mais je me rend compte que je n'avais pas tout compris. Je n'avais pas compris que c'était seulement quand tu forces le redémarrage d'une machine que tu as le probleme.


Par hasard, serais-tu en train de participer au défi Pascal ?

[djiga4me]

... c'était seulement quand tu forces le redémarrage d'une machine que tu as le problème.

Exactement, un redémarrage forcé, quand j'appuie par exemple sur le bouton !

Par hasard, serais-tu en train de participer au défi Pascal ?

Non, je travaille sur un vraie application à livrer, qui est achevé ...disons à 98%, il reste juste à régler ce détail, un pour l'affichage de certaines fenêtres, et faire un fichier d'installation, c'est tout !
Mais le défi est intéressant ! (A voir si j'ai le temps ...et les connaissances !)

[mick605]

Peut être une piste : le message Windows WM_ENDSESSION envoyé lors de la fermeture de la session.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
        ''' <summary>The WM_ENDSESSION message is sent to an application after the system processes the results of the WM_QUERYENDSESSION message. The WM_ENDSESSION message informs the application whether the session is ending.
        ''' A window receives this message through its WindowProc function.</summary>
        ''' <remarks><list type="table">
        ''' <item><term>wParam</term>
        ''' <description>If the session is being ended, this parameter is TRUE; the session can end any time after all applications have returned from processing this message. Otherwise, it is FALSE.</description></item>
        ''' <item><term>lParam</term>
        ''' <description>This parameter can be one or more of the <see cref="lParam.WM_ENDSESSION"/> values. If this parameter is 0, the system is shutting down or restarting (it is not possible to determine which event is occurring).
        ''' Note that this parameter is a bit mask. To test for this value, use a bit-wise operation; do not test for equality.</description></item>
        ''' <item><term>Return value</term>
        ''' <description>If an application processes this message, it should return zero.</description></item>
        ''' </list><seealso></seealso></remarks>
        WM_ENDSESSION = &H16

Voir ici pour tout les messages windows !

Bonne chance

[djiga4me]

(Désolé du retard pour réponde, je fus occupé ailleurs)
Bon, je ne peux pas utiliser le message ENDSESSION, puisque l'ordinateur distant n'a pas le temps de faire appel à ça, donc ne peut informer le serveur.

Je me suis résolu à utiliser cette méthode :

1- Créer un thread sur le serveur (avec un sleep (4000)
2- Créer un variable globale ResponseIs[0..MAX] of Boolean;
3- Envoie du Thread d'une information au clients avec TCPServer.SendCommand().
4- Mise à false de la variable pour chacun des éléments.
5- Vérification à nouveau par le thread de la valeur de la variable.
6- Signaler les éléments à False.
-- Et la boucle continuer de tourner.

Qu'est-ce que vous en dîtes ?

@ShaiLeTroll : Comment pourrais savoir si j'ai reçu un ACK ou NAK ?

[mick605]

Non, ce que je pensais, c'est se servir du message ENDSESSION pour déconnecter proprement le client, en faisant un IdTCPClient1.Disconnect puis Application.Terminate par exemple.

[djiga4me]

Non, mais je comprend, mais dans mon cas, ça me sert à rien ! En plus, si je veux moi même redémarrer le client, la commande existe déjà et ça marche !
Imagine qu'il y ait une coupure de courant chez le client,
Donc je pense mettre le système décrit dans le message d'avant, qu'est-ce que tu en dis ?

[djiga4me]

Toujours aucun commentaire sur ma méthode ?

[mick605]

C'est sur que ce moyen est fiable au moins. Sinon, tu peux essayer de pinguer les clients. Perso, je n'ai jamais eu ce genre de probleme lors de la deconnection.