Destruction de socket, un thread reste actif

Version imprimable

26/03/2013, 14h11
franckcl

Destruction de socket, un thread reste actif
bonjour,

J'utilise la classe TClientSocket (dans System.Win.ScktComp) avec laquelle je suis confronté à un problème lorsque je détruit l'objet.

Je créé le socket par:
Code:

1 2 3 4 5 ClientSocket1 := TClientSocket.Create(nil); ClientSocket1.OnError:= ClientSocket1Error; ClientSocket1.Host := '192.168.0.1'; ClientSocket1.Port := 502; ClientSocket1.Active:=true;
Je le détruit par :
Code:

1 2 ClientSocket1.Close; ClientSocket1.free;
Dans mon cas l'adresse IP n'existe pas et donc lorsque je détruit l'objet, le thread qui a été créé par l'API n'est pas détruit et alors une exception apparait quelques secondes après la destruction du socket :

Exception 'first chance' à $00000000. Classe d'exception $C0000005 avec un message 'access violation at 0x00000000: read of address 0x00000000'. Processus MyAPP.exe (5452)

Si quelqu'un a une idée pour détruire le thread du socket en même temps qu'on détruit le socket ??

En revanche je n'ai pas de problème lorsque je quitte mon application.
Merci
Franck
26/03/2013, 14h43
ShaiLeTroll
Citation:

Envoyé par franckcl

une exception apparait quelques secondes après la destruction du socket

une VA en 00000000, typique d'un objet nil
Probablement le membre privé de type TClientWinSocket interne au TClientSocket qui a été libéré, quoi qu'en lisant le code de Destroy, il n'y a pas d'affectation à nil
Code:

1 2 3 4 5 6 7 if Assigned(ClientSocket1) then begin ClientSocket1.OnError := nil; if ClientSocket1.Active then ClientSocket1.Close(); ClientSocket1.Free(); end;
Citation:

Envoyé par franckcl

Si quelqu'un a une idée pour détruire le thread du socket en même temps qu'on détruit le socket ??

ClientType est par défaut à ctNonBlocking, cela utilise des variantes asynchrones des API, j'ignore si l'on peut dire que cela crée un thread mais ce n'est pas effectivement éloigné en terme de comportement !

En réalité, comme tu es en mode ctNonBlocking, à mon avis, tu dois attendre la notification par OnError ou OnConnect pour poursuivre !

Peux-tu différer la destruction ?
Par exemple, dans le OnError, utiliser un PostMessage personnalisé pour libérer l'objet (un peu comme le Release d'une TForm, version différée du Free)

Le TServerSocket fonctionne ainsi avec son DeferFree\CM_DEFERFREE mais pas le TClientSocket

Cette VA apparait-elle qu'en Notification (first chance) puis une seconde fois en vrai Exception ?
Ce n'est peut-être qu'un signalement par le déboggueur !

Pense que le TClientSocket est fourni pas compatibilité avec Delphi 6, normalement le composant c'est TTCPClient ou TIdTCPClient, l'unité ScktComp a été dépréciée en Delphi 7 (depuis semble que l'on ne sache plus vraiment si ils sont considérés comme bon ou pas, leurs absences de la Palette amène un fort doute )
26/03/2013, 14h55
franckcl

toujours le même qui répond...merci ShaiLeTroll
Je viens d'essayer ton code mais ça ne change rien, j'avais déjà essayé de mettre le OnError à nil.
J'ai essayé en release et si je le lance depuis l'IDE alors j'ai ce même message puis si je lance l'exécutable directement depuis windows, alors l'application se fige complêtement. (obligé de tuer la tâche)

Il doit bien y avoir un moyen pour tuer le thread qui a été lancé par l'API et qui tourne en fond !
26/03/2013, 15h47
tourlourou

Y a-t-il un TimeOut à respecter avant de détruire ? Mais il devrait déclencher un OnError, je suppose.
26/03/2013, 16h59
franckcl

Oui, Il y a un TimeOut, la fonction OnError est appellée environ 20 secondes après l'affectation de ClientSocket1.Active:=true
Le problème est que lorsqu'arrive ce callback, l'objet est détruit car je ne l'utilise plus. Je ne peux pas me permettre d'attendre ce temps avant de le détruire. Je souhaiterai stopper le thread ou mettre fin à la connexion avant ce temps. En plus, je ne sais pas si l'adresse IP en question est valide ou non. Si elle est valide, il n'y a pas de problème puisque OnError n'est pas appelée.
Et je ne sais même pas si un thread est en cours, c'est d'autant plus gênant que je ne peux pas le gérer.
26/03/2013, 18h12
franckcl

Un nouvel indice à mon problème.
Ce que je n'ai pas dit c'est que l'activation du socket est appellé par un thread:

ClientSocket1.Active:=true; // appellé par un thread

Ce thread appelle cette fonction régulièrement tant que la connexion n'est pas active (par exemple, en attendant la mise sous tension du serveur).

J'ai essayé d'appeler cette fonction par un timer et je n'ai pas de problème.

Mais bien sur il me faut absolument le lancer via le thread donc problème !

Ouf, ça y est, après une batterie de tests de validation je peux dire que maintenant ça marche. J'ai testé avec plusieurs sockets ouverts simultanément, deconnexion de com, reconnexion, destruction de socket, re-création etc...plus de problème.
Alors pour ceux qui veulent utiliser TClientSocket de l'unité ScktComp dans un thread pour créer un socket non bloquant (interruptible à tout moment) voilà la recette:
Après avoir affecté Active à true, il faut appeller "Application.ProcessMessage" et ceci tant que Active est à false.

C'est un peu barbare mais ça marche nickel chrome.

S'il y en a qui veulent l'algo, voici les sources de mon code. La fonction Loop est appellé par mon thread en permanence avec un sleep(1) dans le fonction execute.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
 
Procedure TMySocket.loop;
Begin
  inherited loop;
 
  case step of
     S_DISABLED : ;   // do nothing
     S_CONNECTION :   // Connexion requested
        Begin
          StartLongTMO       := GetTickCount;
          StartOnErrorTMO    := GetTickCount;
          LastErrorMsg       := 'Connecting';  // used by the inherited class to display hint message
          LastErrorTime      := now;
          ClientSocket1.Port := Port;
          ClientSocket1.Host := IPAdr;
          SocketErrCode      := 0;
          Step               := S_WAIT_CONNECTION;
          if not(ClientSocket1.Active) and not(RegErrStatus) then MyLog.LogEvent('',ChamberId,li_SOCKET_CONNECTING,LOG_COM,EL_NONE,'['+Name+']'+' Trying to connect to IP='+IPAdr+' and port='+IntToStr(Port));
          ClientSocket1.Active:=true;
        End;
     S_WAIT_CONNECTION: // Waiting for connection
        Begin
 
          if (ClientSocket1.Active) THEN //and (SocketErrCode=0) then  // Connected !
          Begin
            CallAllStartModules;
            inc(CounterConnect);
            DateConnected := now;
            step          := S_LOOP_COM;
            LastErrorMsg  := 'Connected';  // used by the inherited class to display hint message
            LastErrorTime := now;
            SocketErrCode := 0;
            SetErrStatus(false); // This will dispatch the information to all module which are connected to this socket with the SetErrStatus function
            if RegSecEnabled then  MyLog.logEvent('',ChamberId,li_SOCKET_ERROR,LOG_COM,EL_RESTORED,'['+Name+']'+' Connected to IP='+IPAdr+' and port='+IntToStr(Port));
          End else // not connected !
          Begin
            //---------------!!
            if MyScheduler.UsesThread then Application.ProcessMessages;
            //---------------!!
            if (GetLapsTickCount(StartLongTMO)>TMO_Connect) then  // TMO_Connect=30s
            Begin
              step:=S_CONNECTION; // if the timeout is reached then try to reconnect
              if not(RegErrStatus) then
              Begin
                MyLog.logEvent('',ChamberId,li_SOCKET_TMO,LOG_COM,EL_CRITICAL,'['+Name+']'+' Time out occured when trying to connect to IP='+IPAdr+' and port='+IntToStr(Port));
                SetErrStatus(true); // This will dispatch the information to all module which are connected to this socket with the SetErrStatus function
              End;
            End else
            if ((SocketErrCode>0) and (GetLapsTickCount(StartOnErrorTMO)>TMO_RECONNECT_ONERROR)) then  // if error occured (OnError) then after TMO_RECONNECT_ONERROR = 9s
            Begin
              SocketErrCode      := 0;
              StartOnErrorTMO    := GetTickCount;
              ClientSocket1.Active:=true;
            End;
          End;
        End;
 
       S_LOOP_COM: // idle step
        Begin
 
          // Check connection and if error, log error and reconnect
          if (not ClientSocket1.Active) then // or (SocketErrCode>0) then // if loss of connection then reconnect
          Begin
            MyLog.LogEvent('',ChamberId,li_SOCKET_LOST_CONNECT,LOG_COM,EL_WARNING,'['+Name+']'+' Loss of connection to IP='+IPAdr+' and port='+IntToStr(Port));
            StartLongTMO       := GetTickCount;
            StartOnErrorTMO    := GetTickCount;
            SocketErrCode      := 1; // to force to reconnect
            step:=S_WAIT_CONNECTION;
          End else
          Begin
            SocketErrCode:=0;
            CallLoopModule;
          End;
        End;
     else step:=S_CONNECTION;
  end; // end case
end;

27/03/2013, 11h22
ShaiLeTroll

Application.ProcessMessages est donc appelé depuis TThread.Execute !
C'est juste périlleux au possible, Erreur 1400 à prévoir !

ClientType est par défaut à ctNonBlocking, passe le en ctBlocking ou utilise le composant TTCPClient qui est mieux adaptés à l'utilisation dans un thread !
Par contre, c'est une logique de programmation assez différente, pas d'event et il faut donc mettre en place un thread de lecture

Tu essayes de faire fonctionner un TClientSocket en ctNonBlocking qui est justement conçu pour une utilisation simpliste sans Thread alors qu'il y a justement un mode ctBlocking conçu pour eux !

Pour éviter que ton code devienne une uzinagaz, tu devrais essayer ctBlocking !
27/03/2013, 11h34
franckcl

Citation:

C'est juste périlleux au possible, Erreur 1400 à prévoir !

Oui mais c'est la seule solution que j'ai trouvée et ça à l'air de bien fonctionner.

Citation:

passe le en ctBlocking

non, je dois pouvoir l'interrompre à tout moment, je ne peux rester bloquer pendant 22 secondes !! puisque c'est apparemment le timeout windows socket.

Citation:

utilise le composant TTCPClient

J'ai essayé tout un tas de solution et c'est la seule qui permet de faire du véritable non bloquant, ou alors je n'ai pas trouvé la méthode pour exploiter TTCPClient. Il faut qu'on puisse détruire le socket à tout moment. J'utilise une interface graphique, l'utilisateur peut glisser des sockets les configurer et les démarrer quand il veut avec toute la souplesse d'un port de com série. Les déconnexion doivent être gérées et la liaison rétabli automatiquement au plus vite.
27/03/2013, 11h48
ShaiLeTroll

Citation:

Envoyé par franckcl

Je ne peux pas me permettre d'attendre ce temps avant de le détruire.

C'est une erreur !
Si tu conserves ton code en ctNonBlocking, il te suffit d'encapsuler le TClientSocket dans un ton propre objet

Cet objet contient un TThread et un pool de TClientSocket, c'est je suppose ton TMySocket mais j'ai l'impression que tu lances plusieurs TMySocket alors que c'est lui qui devrait te fournir cette souplesse de connexion !

A voir ton code, tes objets semblent très imbriqués les uns dans les autres avec MyLog, MyScheduler, je préfère au possible utiliser des Events pour les notifications et des propriétés pour le paramétrage pour avoir un faible couplage !

Lorsqu'une action utilisateur rend cet la connexion obsolète, tu ne le libère pas immédiatement, tu appelles juste un Close, tu attends l'event OnError, OnConnect ou OnDisconnect pour passer à l'étape suivante

Au lieu de gérer un seul socket, tu gères un pool de socket
Ainsi lors que relance une nouvelle connexion ton objet Close le Socket en cours et le laisse en vie le temps qu'il soit dans un état "propre", et crée un nouvel objet

Tu confonds ce que l'on "affiche à l'utilisateur" et ce que l'on fait réellement !
Tu peux faire croire ce que tu veux à ton utilisateur tout en étant rigoureux dans ton code

Citation:

Envoyé par franckcl

Il faut qu'on puisse détruire le socket à tout moment. J'utilise une interface graphique, l'utilisateur peut glisser des sockets les configurer et les démarrer quand il veut avec toute la souplesse d'un port de com série. Les déconnexion doivent être gérées et la liaison rétabli automatiquement au plus vite.

En utilisant des threads séparés, il ne devrait y avoir aucun problème !
tu peux "déclarer un socket" comme obsolète, tu le laisse vivre sa vie, si lors du OnConnect ou du OnError, il est voit qu'il a été annulé, il se ferme tout seul et proprement !

Pendant ce temps, tu peux lance un autre objet qui lui prendra la main !

Ton code à mon avis laisse trainer de la merde dans les API Windows, avoir CallBack\Message des Api WSA qui provoque un OnError sur un objet libéré est vraiment le signe d'un gros problème, preuve que Windows gère encore des Handles qui ne devrait plus être là !
27/03/2013, 14h38
franckcl

Concernant le composant TTcpClient je suis tombé sur ceci:

TTcpClient (and TTcpServer) is a HORRIBLY written component. It was
Borland's attempt at a cross-platform socket solution for the CLX framework,
but they wrote it in a least-common-demoninator manner that ends up with
very little useful functionality. I strongly advice you to stop using it
altogether and either use the legacy VCL TClientSocket component, or switch
to a third-party socket library, such as Indy, ICS, or Synapse.

source: http://embarcadero.newsgroups.archiv...010144873.html
27/03/2013, 15h25
ShaiLeTroll

C'est pour cela que j'avais aussi conseillé le TIdTCPClient de Indy !

Et tout le monde, te dira d'utiliser ICS !

Mais tu noteras que le TTCPClient est toujours dans la palette mais pas le TClientSocket, ce n'est pas parce qu'un sujet mentionne les limitations du TTCPClient lié à l'apparition de Kylix qu'il est si mauvais !
Surtout une critique en 2010 est facile pour un composant écrit en 2000 qui n'as pas évolué puisque la CLX étant abandonné et que Indy faisait aussi bien !

Mais, comme le TTCPClient est pénible à l'utilisation par rapport à un TClientSocket donc autant passer au TIdTCPClient tout aussi pénible mais plus complet

Perso, j'ai utilisé massivement TClientSocket et TServerSocket, il y a 10 ans, en mode ctNonBlocking, mes OnRead se limitait à ajouter le buffer reçu dans une TThreadList après tout le reste en codé en thread !
Et mon Thread d'envoi, utilisait une autre TThreadList et comme toi, un vilain ProcessMessages semblait faire mieux marcher le bousin (un try except autour pour les OSError 1400 qui se produisait tous les 36 du mois)

J'ai utilisé le TTCPClient en thread dans un petit projet, il a été tout à fait correct une fois habitué à son read bloquant

Même aujourd'hui, vu que je n'ai pas fait de socket depuis au moins 5 ans, je choisirais un TClientSocket pour sa rapidité de mise en œuvre pour un petit projet et je m'orienterais vers TIdTCPClient pour un projet plus massif
27/03/2013, 15h34
franckcl

Ok donc pour le moment je vais rester avec mon TClientSocket et son ProcessMessage (et comme toi je vais mettre un try except, au cas ou...) et si je rencontre trop de problèmes j'envisagerai de passer avec un TIdTCPClient.
merci