Discussion :

[Coussati]

bonjour,
j'essaie de m'habituer avec ces composants que je n'ai jamais aimé :/ et j'ai une question concernant la connexion d'un client au serveur
quand le serveur est en ligne (et que le port est bien ouvert bien sur) tout se passe bien, la connexion se fait en à peine 2 sec
lorsque le serveur est offline, ou que le port n'est pas ouvert, lorsque le client essaie de se connecter au serveur notre application se bloque (lag) est figé ...
pas très pratique, indy n'avait jamais pensé à cette éventualité ?
j'ai pensé lancer mes connexions cliente dans AnonymousThread, afin que l'application continue à fonctionner normalement, mais est ce une bonne méthode ?
je préfère avoir votre avis avant de me lancer dans quelque chose qui ne serait sans doute pas une bonne idée
sachant que dans mon application, le client va se connecter / déconnecter à plusieurs serveur
merci

[Paul TOTH]

c'est la différence principale entre ICS et Indy

ICS utiliser des appels asynchrones avec des évènements ... donc difficile de faire un simple GET() HTTP car il faut un OnXXX
Indy fait des appels bloquants, donc c'est facile de faire un GET()...mais ça fige l'application.

donc soit tu fixes la valeur de ConnectTimeout sur une durée suffisante pour établir la connexion mais pas trop longue pour ne pas figer l'application.
soit tu fais ta connexion dans un thread effectivement

j'utilise personnellement 1000ms (1 sec) sur un TidTCPClient sur le port 3050 vers une serveur Firebird avant de tenter un accès BDD car le client Firebird n'a pas de paramètre de timeout et si le serveur n'est pas disponible on reste bloqué 30 secondes si je me souviens bien.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
procedure TData.IBDatabase1BeforeConnect(Sender: TObject);
begin
  if (IBDatabase1.Server <> '') and (LowerCase(IBDatabase1.Server) <> 'localhost') and (IBDatabase1.Server <> '127.0.0.1') then
  begin
    idTCPClient1.Host := IBDataBase1.Server;
    try
      idTCPClient1.Connect;
      idTCPClient1.Disconnect;
    except
      ShowMessage('Pas de réponse du serveur ' + idTCPClient1.Host + ' assurez vous du bon fonctionnement de votre réseau.');
    end;
  end;
end;

[Coussati]

merci pour ton éclaircissement Paul
par contre il se passe quelque chose de pas très compréhensible pour moi
certaines instructions qui viennent AVANT la connexion du client ne s'exécute qu'APRES la tentative de connexion et donc ne s'exécute pas lors du lag de l'application ...

Code :

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

1
2
3
4
5
6
7
8
9
10
 
  Label4.Text := 'Chargement  4 sur 4';
 
  ProgressBar1.Value := 100;
 
  TabControl1.ActiveTab := form1.Tab_2
 
  IdTCPClient1.Port := 4562;
 
  IdTCPClient1.Connect;

mon label et la progessbar ont bien été modifié, mais le changement d'onglet du tabcontrol n'est pas fait ! du coup l'application lag sur une fenêtre qui est sensé disparaitre après l'affichage du label est ce normal ?
seul moyen trouvé afin que le tabcontrol s'exécute, est d'intégrer un showmessage avant la connexion du client (pas très pratique)
concernant le timeout, 1 sec ce n'est pas trop peu ? si la machine distante ne répond pas tout de suite, ou que la machine cliente soit un peu lente, ça ne risque pas de jouer sur le temps de connexion ?

je ne connais pas tout ce qui se passe en dessous du capot, quand je lance la connexion, j'attends bien sur le retour du serveur : parfois il est très rapide et parfois pas trop (selon ma connexion internet bien souvent) est ce une incidence sur la connexion ? ou c'est ce qui se passe après la connexion ? d'où mon appréhension concernant la durée du timeout ...

[Paul TOTH]

les affichages se font dans le thread principal, donc tant que ton code n'est pas terminé il n'y a pas d'actualisation de l'écran.
tu peux ajouter un Application.ProcessMessages pour traiter les messages en attente, mais il faut faire gaffe avec ça car tu peux avoir un code réentrant; tu peux par exemple re-cliquer sur le bouton dont la procédure onClick fait appel à ProcessMessages....mais tu as le même problème avec un thread secondaire en fait

1 sec c'est normalement suffisant pour la connexion sans être trop long pour un écran qui se fige....le thread reste le plus propre; prend l'exemple des navigateurs, quand tu cliques sur un lien tu as le "X" qui indique qu'un requête est en cours mais rien n'est figé.