Question théorique sur le TCP

Recherche :

Dernière réponse

Sujet : Question théorique sur le TCP

d'ho

Vinny_the_true a écrit :

Je n'ai pas tout compris là :??:
Arrête-moi si je me trompe, mais le client ne peux pas acquitter le message FIN puisque sa séquence est bien plus élevée que ne l'est sa valeur d'accusé à ce moment-là. Donc deux options, soit il attend les 26 octets manquant, sans rien faire, puis envoi ACK+FIN dans un message, soit il envoi le ACK que j'ai mis sur le dessin (le même qu'auparavant à priori, puisqu'incrémenter l'accusé pour signifier la réception du FIN semble peu judicieux). Du coup, s'il envoi ce ACK, le serveur renvoi ses données parce-qu'il reçoit ce message ? Ou plutôt parce-que son timeout expire :??:
Mon problème exact concerne le comportement du client lorsqu'il reçoit un message de FIN à séquence supérieure à son accusé.

En tout cas merci de ton aide, tu t'es même documenté pour moi, il ne fallait pas :sweat:

Il y a une erreur que je n'avais pas vu, d'ou ton probleme de comprehension ;)
En effet, le SYN envoyé par le serveur doit être SYN(b+27;a+2)("j'envoie le segment n°a+1 et j'attend de recevoir le segment n°a+2" ); car le serveur a envoyé un segment DATA[26](b+1;a+1) avant mais ne sais pas encore que le segment a été perdu (pas d'expiration encore du timeout associé à ce segment).
Alors le client doit envoyer un ACK(a+2;b+28) et sait donc qu'il lui manque le segment a+1.

Enfin, le serveur ferme la connexion client ->serveur par un ACK(b+28;a+3).

Ensuite, la question d'une fermeture de connexion, alors qu'un segment manque me turlupine du coup. Je me renseigne ;)

PS: j'espere pas trop m'etre embrouille ou t'avoir embrouille :D

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

d'ho

Vinny_the_true a écrit :

Vinny_the_true

Je n'ai pas tout compris là :??:
Arrête-moi si je me trompe, mais le client ne peux pas acquitter le message FIN puisque sa séquence est bien plus élevée que ne l'est sa valeur d'accusé à ce moment-là. Donc deux options, soit il attend les 26 octets manquant, sans rien faire, puis envoi ACK+FIN dans un message, soit il envoi le ACK que j'ai mis sur le dessin (le même qu'auparavant à priori, puisqu'incrémenter l'accusé pour signifier la réception du FIN semble peu judicieux). Du coup, s'il envoi ce ACK, le serveur renvoi ses données parce-qu'il reçoit ce message ? Ou plutôt parce-que son timeout expire :??:
Mon problème exact concerne le comportement du client lorsqu'il reçoit un message de FIN à séquence supérieure à son accusé.

En tout cas merci de ton aide, tu t'es même documenté pour moi, il ne fallait pas :sweat:

d'ho

Aprés vérification, TCP fait le coup du reset moins souvent que je ne le croyais :D

Donc dans ton cas, ce que tu as mis est bon, l'envoi du segement DATA[26] déclenche un timeout (30s à 2 minute après vérification, 200ms est pour un autre cas :p).

Pendant ce temps, le serveur envoit son FIN, acquitté par le client => connexion client ->serveur fermée

Voila, ce que je n'avais pas capté, au même moment que la réception du ACK, le timeout du serveur expire et il renvoit DATA[26] => ack du client qui attend bien b+28 (b+27 ayant déjà été reçu ;)) inclus dans un FIN.

Il manque juste une flèche cote serveur qui renvoit un ack pour le FIN du client ;)

Vinny_the_true

hum...d'accord. Mais n'est-ce pas possible que le client se comporte avec le message FIN comme il se comporterais avec des données ? Dans le cas de données, et bien on avancerait pas encore la fenêtre, puisqu'il y aurait un trou, mais dès que ce trou serait comblé, on avance directement de plusieures éléments.
En tout cas, merci pour ta réponse :hello: ...même si je dois bien avouer que pour le coup elle ne me satisfait pas pleinement... peut-être dans une ancienne version du protocole ? :lol:

d'ho

Je pencherais plutôt pour un désynchronisation entre l'émetteur et le récepteur: côté serveur, apres l'envoi de DATA[26], se déclenche un timeout (200ms il me semble) en attendant un ack de ce segment, auquel cas, il reessaiera de renvoyer ledit segment. Or côté client, il attend le segment b+1 et voit arriver b+27 => désynchronisation (depuis les recnete versions de TCP, au moindre probleme, pouf reset) donc il y a reset du client :p

Vinny_the_true

Voilà, ma question concerne le dessin ci-dessous.
Il décrit une connexion entre A et B du début jusqu'à la fin. Le texte en noir est la base, à moi de remplir, j'ai donc mis tout le rouge (plus la plupart des flèches)
Pour chaque message, le tag indique le type de message, les deux chiffres entre parenthèses sont les numéros de séquence et d'accusé.
Mon problème principal concerne l'endroit du cercle rouge, le renvoi des données est-il déclenché par la réception d'un ACK (accusé de réception) "éronné" ou par le passement du délai (symbolisé par la flèche verticale ?
Sinon, à part ce point sensible, le reste est conforme au comportement de TCP ?

http://vinnythetrue.free.fr/temp/TCP.jpg

merci pour votre aide :bounce: