[Delphi 6] Comment détecter si un poste est connecté ?

**Laurent Dardenne** · 29/03/2005, 21h41

Salut,
peut être une autre approche, proposé par Aurélien modérateur du forum Développement Windows , pour un problème semblant identique :

Tu peux utiliser IsNetworkAlive:
http://msdn.microsoft.com/library/en-us/syncmgr/syncmgr/isnetworkalive.asp

A vérifier.

**Lung** · 30/03/2005, 15h40

A première vue, cette solution semble fonctionner : http://www.developpez.net/forums/vie...782153#1782153

Elle donne la bonne réponse quand le cable réseau est débranché, et réponse quasi-instantannément.

**Lung** · 30/03/2005, 15h56

Et bien non : encore un problème. si, si ...

Sous NT, le ping mets 37 secondes environ pour échouer, quand le cable réseau est débranché.
Pourtant, dans le dernier paramètre de la fonction IcmpSendEcho, j'ai mis 1000 pour un TimeOut d'une seconde.

Envoyé par MSDN

Timeout
[in] Time to wait for replies, in milliseconds.

Où est l'erreur ?

:

**/dev/null** · 30/03/2005, 16h07

C'est fait par Microsoft

En fait je vois pas là... essay de mettre 1... ou alors, utilise une fonction callback (si y'a un moyen

)

**Lung** · 30/03/2005, 16h23

Envoyé par /dev/null

utilise une fonction callback (si y'a un moyen

)

C'est-à-dire ?

:

**/dev/null** · 30/03/2005, 16h29

Je ne sais pas si les fonction que tu emplois peuvent integrer le principe de callback... en gros une fonction apeller en evenement...
Si oui, dans ce cas tu fait
1. Ping Threader
2. Si TimeOut Ecouler (grace a un timer) continuer sans tenir compte du Thread
3. Si TimeOut pas Ecouler est connecter...

Je t'avoirais que j'ai peur de dire une bêtise

**Lung** · 30/03/2005, 16h37

Le coup du Timer, c'est une bonne idée,

... mais je ne vois pas bien comment m'y prendre.

Je sens que je vais encore faire une usine à gaz ... tout ca juste pour tester s'il y a du réseau ...

**/dev/null** · 30/03/2005, 16h45

Envoyé par Lung

Je sens que je vais encore faire une usine à gaz ... tout ca juste pour tester s'il y a du réseau ...

ça me rassure... je suis du genre aussi

En gros, tu utilise un Thread pour le ping. A ce moment tu lance un Timer.
Si le Thread ce temine en 1er... tu dévalide le Timer et tu déclanche un évement du Genre EventCestConnecter. Si non, ton Timer indique au Thread que quoi qu'il se passe faut qu'il se la ferme et le Timer declanche un élément du type EventIlSontOuLesBresilien...

Tu vois le principe ?

**Lung** · 11/04/2005, 11h31

Bon, j'ai un thread et un Timer qui sont lancés.
- Si le tnsping répond, je coupe le Timer, et je continu.
- Si le Timer répond, time out : je continu sans tenir compte du thread qui se termine plus tard.

Ca semble bien fonctionner sous XP.
Mais, sous NT, avec un interval d'une seconde pour le Timer, ca me mets 30 secondes pour réagir.
NT est multi-tâches, ou pas ?

:
J'ai l'impression qu'il m'a exécuté mon thread, puis quand il s'est terminé il m'a lancé mon Timer ...

**cpdump** · 11/04/2005, 11h43

Envoyé par Lung

Et bien non : encore un problème. si, si ...

Sous NT, le ping mets 37 secondes environ pour échouer, quand le cable réseau est débranché.
Pourtant, dans le dernier paramètre de la fonction IcmpSendEcho, j'ai mis 1000 pour un TimeOut d'une seconde.

Envoyé par MSDN

Timeout
[in] Time to wait for replies, in milliseconds.

Où est l'erreur ?

:

Est que tu fait le ping avec l'adresse IP ou le nom de la machine, auquel cas cela peut prendre du temps car il faut faire la résolution nom -> IP qui peut être impossible si cable débranché d'où délai supplémentaire d'attente de réponse du DNS.

**Lung** · 11/04/2005, 11h46

Envoyé par cpdump

Est que tu fait le ping avec l'adresse IP ou le nom de la machine

Je le faisais avec l'adresse IP.
Mais maintenant, je fais un TNSPING d'une instance Oracle.

**Lung** · 11/04/2005, 15h34

Envoyé par Lung

Bon, j'ai un thread et un Timer qui sont lancés.
- Si le tnsping répond, je coupe le Timer, et je continu.
- Si le Timer répond, time out : je continu sans tenir compte du thread qui se termine plus tard.

Ca semble bien fonctionner sous XP.

Rectification : le TNSPING dans le thread gèle parfois toutes l'application, ce qui fait que le Timer n'avance plus non plus.
Donc, le multi-tâche n'exécute qu'une tâche à la fois ...

Je sèche, là ...

Personne aurait une idée lumineuse ?

**/dev/null** · 12/04/2005, 10h12

Ne connaisant pas l'implémentation du Timer Delphi, et n'ayant pas NT 4 pour faire des test... je te dirait d'éssayer un sleep(1000)

pour emplacer le timer

**Lung** · 12/04/2005, 10h16

Envoyé par /dev/null

je te dirait d'éssayer un sleep(1000)

pour emplacer le timer

Avec un Sleep, je bloque à coup sûr mon application ...

**Sub0** · 12/04/2005, 10h20

A tout hasard, as-tu essayé de libérer la liste des messages Windows avec Application.ProcessMessages ?
Normalement, un thread en a besoin pour être non bloquant...

**/dev/null** · 12/04/2005, 10h23

Je sous antendait (partant du principe de l'usine à gaz

) un nouveau Thread

**Lung** · 12/04/2005, 10h25

Envoyé par Sub0

A tout hasard, as-tu essayé de libérer la liste des messages Windows avec Application.ProcessMessages ?
Normalement, un thread en a besoin pour être non bloquant...

Oui.

Je me suis rendu compte que ca marchait mieux avec (mais c n'empêche pas que c'est pas multi-tache).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
   MainForm._Result.bReseau := False;      MainForm._Result.bTimeOut := False;
   Timer.Enabled := True;
   //.Test du réseau dans un thread.
   with TThreadTestReseau.Create(False) do
      OnTerminate := ThreadDone;
 
   //.Attente de réponse.
   while not MainForm._Result.bTimeOut do
      Application.ProcessMessages;
 
   //.Si réseau.
   if MainForm._Result.bReseau then
           // traitement ...

**Lung** · 12/04/2005, 10h29

Envoyé par /dev/null

Je sous antendait (partant du principe de l'usine à gaz

) un nouveau Thread

Non, mais si le Timer se bloque, je me demandais si ca valait le coup de faire un 2ième thread.
J'essairais ...

**Sub0** · 12/04/2005, 10h42

Perso, je ne me sers pas souvent du composant Thread, j'utilise soit un Timer, soit une simple boucle du genre :

Code :

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

1
2
3
4
5
Repeat
  // <- Mon traitement ici -> //
  Application.ProcessMessages;
  Sleep(250);
Until (Condition);

En pratique, cela revient au même que l'objet Thread, mis à part que c'est moins précis au niveau du réglage de la priorité. En effet, j'utilise Sleep pour définir la priorité du "thread"... Pour bien faire, il faudrait tenir compte de la puissance du cpu et des ressources disponibles pour ajuster la valeur de Sleep si je veux obtenir une priorité précise... Mais qu'importe, ça fonctionne très bien et cette méthode est bien souvent plus simple à mettre en place... Tu noteras qu'Application.ProcessMessages reste nécessaire quelque soit la méthode choisie.

C'est toujours du multitâche; Le multi-tâche reste malgré tout des instructions appellées les unes derrières les autres, surtout si le matériel est incapable de réaliser 2 opérations simultannément. C'est pour cette raison qu'il faut définir la priorité d'un thread. Par exemple, une boucle du genre bloquera le système et la charge du cpu sera à 100% même si il ne fait pas grand chose :

Code :

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

Repeat Until(Condition);

Ajoute Application.ProcessMessages pour libérer la liste des messages Windows et Sleep pour ralentir la boucle, diminuer le nombre d'itération et par conséquent, diminuer la charge du processeur... à+