Discussion :

[klimasDavid]

Bonjour,

j'ai une petit application client-server par TCP/IP (comme le chat).
Voici l'extrait d'une partie du serveur :

Code :

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

1
2
3
4
5
6
7
8
9
procedure TForm1.IdTCPServer1Execute(AThread: TIdPeerThread);
VAR
    Str1:    String;
BEGIN
    Str1:=AThread.Connection.Readln;
    If Str1 = '#Question' then
         AThread.Connection.WriteLn('#Reponse');
    ...
END;

et voici le client :

Code :

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

1
2
3
4
5
6
7
procedure TMainForm.QuestionButtonClick(Sender: TObject);
VAR
    Str1:    String;
BEGIN
    ServerConnection.WriteLn('#Question');
    Str1 := ServerConnection.ReadLn('#');
END;

Le problème c'est, que ça marche pas toujours. En générale le client attente, sans aucun réponse. Comment recevoir la réponse du serveur, tout en gardant la connection ouvert?
Merci pour vos conseilles...

[ShaiLeTroll]

J'aurais tendance à penser qu'il soit nécessaire d'envoyer 'Question#' et 'Reponse#' puisque tu définie '#' comme la fin de ligne (ce que tu as confondu avec un début de ligne), laisse ReadLn utilisé par défaut le caracter EOL (CR+LF) qu'ajoute naturellement WriteLn !

ou simplement

Code :

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

1
2
3
4
5
6
7
8
9
procedure TForm1.IdTCPServer1Execute(AThread: TIdPeerThread);
VAR
    Str1:    String;
BEGIN
    Str1:=AThread.Connection.Readln();
    If Str1 = 'Question' then
         AThread.Connection.WriteLn('Reponse');
    ...
END;

Code :

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

1
2
3
4
5
6
7
procedure TMainForm.QuestionButtonClick(Sender: TObject);
VAR
    Str1:    String;
BEGIN
    ServerConnection.WriteLn('Question');
    Str1 := ServerConnection.ReadLn();
END;

[LadyWasky]

Cherches TCP sur le forum avec auteur waskol.
J'ai dû exposer en long en large en travers ce problême d'implémentation des sockets (c'est un des bugs du standard Berkeley, et il y en a un autre).

J'ai du fournir à plusieurs reprises un lots de composants (attention, c'est du socket bloquant) qui gèrent ces problêmes, et ils sont tout simples à utiliser.

En gros, le truc, c'est qu'il y a un délais à l'envoi des données d'un socket.
Si tu envois tout au plus quelques octets, ça reste en tampon... jusqu'au moment où tu envois un 2eme paquet, et là... ton client récupère et le premier et le deuxième envoi !!!

Et il me semble que celà fait aussi la même chose avec un gros envoi qui arrive en deux fois chez le client.

Du coup, pour palier à ça, il faut envoyer ton message en lui ajoutant en tête, la taille de ce qui est envoyé, comme ça, à la réception, le client est "prévenu" de ce qu'il doit recevoir (la taille), et recompose son message en fonction des paquets qu'il reçoit au fur et à mesure.

C'est nul, mais c'est comme ça.

Enfin, bref, te voilà prévenu et cherches sur le forum.