Discussion :

[tom_31]

bonjour à tous,

Je me présnte brièvement : je suis l'unique développeur d'une TPE d'éléctronique.
Suite à un problème de connexion chez un client, je me suis lancé à analyser les trames TCP avec wireshark afin de trouver une piste de debug et suis tombé sur une retransmission curieuse :

// partie connection OK :

PC -> serveur : [SYN], Seq = 0, Length = 0

serveur -> PC : [SYN,ACK], Seq = 0, Ack = 1, Length = 0

PC -> serveur : [ACK], Seq = 1, ,Ack = 1, Length = 0

// puis debut de communication : retransmission dès le premier envoi de données

PC -> serveur : [PSH,ACK], Seq = 1, Ack = 1, Len = 37

// là, le serveur n'acquite pas (au bout de 3 secondes), alors le PC retransmet le segment mais avec plus de données !!!! :

PC -> serveur : (TCP retransmission) : [PSH,ACK], Seq = 1, Ack = 1, Len = 48

// POURQUOI ? EST-CE NORMAL ? EST-CE MA FAUTE ? QUELS SONT MES MOYENS D'ACTION SUR CE COMPORTEMENT ?
// enfin, le serveur aquite mais c'est trop tard pour le logiciel (time out à 1 seconde) :

serveur -> PC : (TCP Acked unseen segment) : [PSH,ACK] Seq = 1, Ack = 49, Len = 200

Un peu plus d'infos sur le contexte :
- le serveur est une alimentation de labo que nous produisons et vendons (société d'électronique), le fait qu'il n'acquite pas est donc un bug de notre côté mais ma question porte uniquement sur le pourquoi de la retransmission d'un segment contenant plus de données que celui d'origine.
- le code de notre logiciel est en C++ et utilise winsock 2.0 (le PC client est sous windows XP)
- le réseau se limite au châssis que nous vendons connecté directement à la carte réseau du PC.
- les données supplémentaires du segment retransmis sont issus de notre soft (mais pas mal de lignes plus tard) :

segment initial : "syst:verb0;syst:cpu?;syst:vers?" (commandes SCPI)

segment retransmis : "syst:verb0;syst:cpu?;syst:vers?syst:err ?"

merci d'avance à ceux qui auront le courage de me lire...

[ram-0000]

Le comportement que tu décris me parait explicable (et donc normal)

• Tu ouvres ta connexion TCP
• Ton appli envoie des données "syst:verb0;syst:cpu?;syst:vers?"
• la Pile IP attend un acquittement (qui ne vient pas)
• Ton appli envoie des données "syst:err ?"
• La pile IP locale renvoie les données à acquitter + les nouvelles données (pour optimiser le nombre d'envois). La pile IP a le droit de faire cela puisque les anciennes données ne sont pas acquitées et le nouvelles données n'ont jamais été envoyées et donc ne sont pas acquittées non plus.

Par contre, le timeout de ton appli est me semble t'il un peu court à 1 seconde. Cela laisse peut de temps à la pile IP locale pour transférer tes données et à la pile distante de les recevoir, de les remonter à l'appli et de les acquitter (sans compte le temps de teraitement de ton appli).

Il faudrait voir au niveau de TCP le valeur de ce timeout TCP (ainsi que le paramètre TCP NbRetry) mais il ne faudrait pas le timeout appli soit plus petit que timeout_tcp * nb_retry_tcp sinon tu est plus "royaliste" que le roi et demande à ton appli a être plus performante que la pile IP sur laquelle elle repose.

[tom_31]

Avant tout, MERCI BEAUCOUP !

En effet, concaténer les nouvelles données à celles non acquittées me parait assez sain et il semblerait que la pile tcp de nos châssis le gère correctement. Me voila à moitié rassuré ...

Pour la valeur de time-out, le problème vient de la convention SCPI qui veut qu'en cas d'erreur, le châssis ne réponde pas. On ne peut décemment pas attendre trois secondes pour dire "out of range" si l'utilisateur entre 2000V sur une alim 12V ...
Il faut donc que j'arrive à séparer un time-out TCP (ack non reçu) et un autre time out SCPI (pas de données renvoyées). Déjà, c'est une grande avancée pour moi, il me faut améliorer ma librairie de communication (chassis connectables en TCP, RS232, RS422 GPIB et USB ...)

D'autre part, mes collègues côté châssis doivent sûrement aussi revoir leur copie car les problèmes de réseau quand on a seulement deux machines connectées directement entre elles par un câble de moins d'1 mètre ... il aurait dû acquitter !

En tout cas, vraiment merci, je me sentais bien seul et ne trouvais que peu d'infos sur le net.

J'vais chercher pour les paramètres time-out et nbRetry de la couche tcp que je ne connaissais pas. (ou du moins que je ne pensais pas disponibles du côté appli)

[ram-0000]

On ne peut décemment pas attendre trois secondes pour dire "out of range" si l'utilisateur entre 2000V sur une alim 12V ...

Même pas joueur

J'vais chercher pour les paramètres time-out et nbRetry de la couche tcp que je ne connaissais pas.

Je pense qu'il va falloir que tu plonges dans la RFC 793, tout y est expliqué (et c'est un tout petit peu plus complexe que ce que j'avais expliqué, déjà, il semble que le timeout soit calculé dynamiquement, ce qui a du sens, sur un réseau réactif, on peut mettre un petit timeout)

Ceci aussi à l'air intéressant : http://www.pcvr.nl/tcpip/tcp_time.htm

(ou du moins que je ne pensais pas disponibles du côté appli)

C'est pas sûr que ces paramètres soient accessibles au niveau applicatif.