Les forums sont fermés. Ils restent présent pour consultation et archivage.
Vous pouvez désormais poser vos questions directement dans les commentaires en bas de chaque page du site.
Alors n'hésitez pas à participer

Problème avec la séquence de fermeture de socket

Bonjour, J'ai deux systèmes qui ont des comportements très différents pour la fermeture d'un socket. Le premier a le comportement suivant : à l'ouverture ==> [SYN] Seq=0 Ack=? <== [SYN, ACK] Seq=0 Ack=1 ==> [ACK] Seq=1 Ack=0 à la fermeture ==> [FIN, ACK] Seq=1 Ack=0 <== [FIN, ACK] Seq=0 Ack=2 ==> [ACK] Seq=2 Ack=1 Le deuxième a un comportement différent : à l'ouverture ==> [SYN] Seq=0 Ack=? <== [SYN, ACK] Seq=0 Ack=1 ==> [ACK] Seq=1 Ack=1 à la fermeture ==> [FIN, ACK] Seq=1 Ack=1 <== [ACK] Seq=1 Ack=2 <== [FIN, ACK] Seq=1 Ack=2 ==> [ACK] Seq=2 Ack=2 Lequel des deux comportements est correct ? D'avance merci smu

Le second. On rajout un au numéro d'acquittement lorsque le paquet précédent contenait le flag SYN ou FIN (pour montrer qu'on les a reçus, même s'ils étaient vides, ce qui est toujours le cas pour les SYN)

Merci pour l'explication. Je me pose encore une question. Qu'en est il, si les séquences d'ouverture et de fermeture sont les suivantes : à l'ouverture ==> [SYN] Seq=0 Ack=? <== [SYN, ACK] Seq=0 Ack=1 ==> [ACK] Seq=1 Ack=1 à la fermeture (Si le client répond immédiatement) ==> [FIN, ACK] Seq=1 Ack=1 <== [FIN, ACK] Seq=1 Ack=2 ==> [ACK] Seq=2 Ack=2 à la fermeture (Si le client temporise sa réponce) ==> [FIN, ACK] Seq=1 Ack=1 <== [FIN, ACK] Seq=1 Ack=2 <== [FIN, ACK] Seq=1 Ack=2 <== [FIN, ACK] Seq=1 Ack=2 <== [FIN, ACK] Seq=1 Ack=2 <== [FIN, ACK] Seq=1 Ack=2 <== [FIN, ACK] Seq=1 Ack=2 ==> [ACK] Seq=2 Ack=2 Merci smu

Qu'en est il, si les séquences d'ouverture et de fermeture sont les suivantes : à l'ouverture ==> [SYN] Seq=0 Ack=? <== [SYN, ACK] Seq=0 Ack=1 ==> [ACK] Seq=1 Ack=1 à la fermeture (Si le client répond immédiatement) ==> [FIN, ACK] Seq=1 Ack=1 <== [FIN, ACK] Seq=1 Ack=2 ==> [ACK] Seq=2 Ack=2 à la fermeture (Si le client temporise sa réponce) ==> [FIN, ACK] Seq=1 Ack=1 <== [FIN, ACK] Seq=1 Ack=2 <== [FIN, ACK] Seq=1 Ack=2 <== [FIN, ACK] Seq=1 Ack=2 <== [FIN, ACK] Seq=1 Ack=2 <== [FIN, ACK] Seq=1 Ack=2 <== [FIN, ACK] Seq=1 Ack=2 ==> [ACK] Seq=2 Ack=2 Alors ici c'est un cas qui ne devrait pas se produire car TCP est fait pour envoyer de la signalisation, même si aucun paquet n'est envoyé. Donc à la demande de fremeture du serveur <== [FIN, ACK] Seq=1 Ack=2 le client doit envoyer un accusé de réception. S'il ne le fait pas, le serveur va réenvoyer ses paquets avec des timeouts importants, donc ce que tu représentes est possible mais s'étend sur un temps important (au niveau réseau, pas humain) De toute manière, le comportement du client dans ce cas est "anormal"

Bonsoir Eric, Merci pour vos réponses. Encore une question (je pense que ce sera la dernière). J'ai fait la même manip avec un serveur sous windows (en Python). Le résultat: Après que le serveur est émis la séquence [FIN, ACK], j'ai constaté aucune réémission sur une période d'une heure. Et d'après ce que vous dites, cela serait un comportement anormal. Quand est il ? Je vais vérifier le comportement sous linux. Pour information, le serveur embarqué réémet la séquence [FIN, ACK] à intervalle de 50 ms. Steve

Pourquoi le client ne réémet-il pas de ACK ? Est-ce vous qui le forcez ?

Bonjour, En fait, dans l'utilisation du système embarqué, le client tourne sous un OS temps réel. Il se trouve qu'à la fermeture des sockets, le client n'envoie pas de paquet ACK et le serveur du système embarqué envoie des [FIN, ACK] ad eternam. J'ai compris, d'après vos explications, que c'est un comportement normal. J'ai essayé de comparer au comportement de Windows et là, j'ai constaté que le serveur sous Windows ne réémettais pas le paquet [FIN, ACK]. Pourquoi le client ne réémet-il pas de ACK ? Sûrement un problème dans la pile TCP/IP de l'OS temps réel. Est-ce vous qui le forcez ? Non Steve

Ce n'est pas, à priori, un comportement normal. Vous trouverez des informations plus précises dans la RFC tcp: [url]http://abcdrfc.free.fr/rfc-vf/rfc793.html[/url] Et si vous êtes un valeureux lecteur vous pouvez vous attaquer au "TCP/IP illustré" de Richard Stevens qui met en avant tous les éléments de la RFC.