La fenêtre glissante de TCP (qui permet le contrôle de flux) est une valeur
relative qui se réfère au numéro d'acquittement. Le numéro d'acquittement
n'étant à considérer que si le flag ACK est positionné, j'en déduis que la
fenêtre n'est aussi valide que si ce flag est positionné.
Et pourtant, je ne vois pas dans RFC793 l'indication d'une quelconque
dépendance entre ACK et fenêtre, ou alors je lis mal.
Quelqu'un a-t-il une idée sur le sujet ?
J'ajoute que je n'ai pas réussi à faire l'essai avec mon W98 et Ethereal. Je
n'arrive pas à faire des acquittements cumulés pour observer la valeur de la
fenêtre.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Angelot
Bonjour Olivier,
C'est venu un peu plus tard. Lisez la RFC 1323.
Merci pour cette réponse, cette RFC discute du facteur d'échelle de la fenêtre, mais pas d'une relation entre ACK et validité de la fenêtre. C'est un autre sujet, tout aussi intéressant d'ailleurs : le facteur d'échelle de la fenêtre est une option TCP, comme le MSS.
Sauf erreur, la fenêtre ne devrait pas être prise en compte si ACK = 0.
Dans les traces que je lance en communiquant avec mon FAI, j'observe toujours ACK = 1 : mon PC ou le serveur acquittent immédiatement les octets envoyés, sans aucun cumul. Je ne peux donc pas observer les valeurs de fenêtre lorsque ACK = 0. Est-ce aussi votre cas ?
Cordialement, Angelot
Bonjour Olivier,
C'est venu un peu plus tard. Lisez la RFC 1323.
Merci pour cette réponse, cette RFC discute du facteur d'échelle de la
fenêtre, mais pas d'une relation entre ACK et validité de la fenêtre. C'est
un autre sujet, tout aussi intéressant d'ailleurs : le facteur d'échelle de
la fenêtre est une option TCP, comme le MSS.
Sauf erreur, la fenêtre ne devrait pas être prise en compte si ACK = 0.
Dans les traces que je lance en communiquant avec mon FAI, j'observe
toujours ACK = 1 : mon PC ou le serveur acquittent immédiatement les octets
envoyés, sans aucun cumul. Je ne peux donc pas observer les valeurs de
fenêtre lorsque ACK = 0. Est-ce aussi votre cas ?
Merci pour cette réponse, cette RFC discute du facteur d'échelle de la fenêtre, mais pas d'une relation entre ACK et validité de la fenêtre. C'est un autre sujet, tout aussi intéressant d'ailleurs : le facteur d'échelle de la fenêtre est une option TCP, comme le MSS.
Sauf erreur, la fenêtre ne devrait pas être prise en compte si ACK = 0.
Dans les traces que je lance en communiquant avec mon FAI, j'observe toujours ACK = 1 : mon PC ou le serveur acquittent immédiatement les octets envoyés, sans aucun cumul. Je ne peux donc pas observer les valeurs de fenêtre lorsque ACK = 0. Est-ce aussi votre cas ?
Cordialement, Angelot
Olivier Tharan
* Angelot (Fri, 27 Aug 2004 23:11:17 +0200):
La fenêtre glissante de TCP (qui permet le contrôle de flux) est une valeur relative qui se réfère au numéro d'acquittement. Le numéro d'acquittement n'étant à considérer que si le flag ACK est positionné, j'en déduis que la fenêtre n'est aussi valide que si ce flag est positionné.
Et pourtant, je ne vois pas dans RFC793 l'indication d'une quelconque dépendance entre ACK et fenêtre, ou alors je lis mal.
C'est venu un peu plus tard. Lisez la RFC 1323.
-- olive
* Angelot <OnSePame@KesceKonSePame.fr> (Fri, 27 Aug 2004 23:11:17 +0200):
La fenêtre glissante de TCP (qui permet le contrôle de flux) est une valeur
relative qui se réfère au numéro d'acquittement. Le numéro d'acquittement
n'étant à considérer que si le flag ACK est positionné, j'en déduis que la
fenêtre n'est aussi valide que si ce flag est positionné.
Et pourtant, je ne vois pas dans RFC793 l'indication d'une quelconque
dépendance entre ACK et fenêtre, ou alors je lis mal.
La fenêtre glissante de TCP (qui permet le contrôle de flux) est une valeur relative qui se réfère au numéro d'acquittement. Le numéro d'acquittement n'étant à considérer que si le flag ACK est positionné, j'en déduis que la fenêtre n'est aussi valide que si ce flag est positionné.
Et pourtant, je ne vois pas dans RFC793 l'indication d'une quelconque dépendance entre ACK et fenêtre, ou alors je lis mal.
C'est venu un peu plus tard. Lisez la RFC 1323.
-- olive
Angelot
Bonsoir Angelot,
Et pourtant, je ne vois pas dans RFC793 l'indication d'une quelconque dépendance entre ACK et fenêtre, ou alors je lis mal.
Eh bien, tu lis mal Angelot.
En fait, la réponse m'a été donnée par un suisse, sur le newsgroup anglais. La RFC793 décrit la machine à états de TCP. Après un détricotage fastidieux des lignes imbriquées if... then... else..., on peut découvrir cette phrase magique : quand un segment arrive dans l'état CONNEXION ETABLIE, si le flag ACK n'est pas levé, le segment est détruit.
Ceci répond entièrement à ma question : même dans des rafales de segments envoyées avec un seul acquittement cumulé du distant, tous les segments partent avec ACK positionné (et donc un numéro de séquence et une valeur de fenêtre).
Cordialement, Angelot
Bonsoir Angelot,
Et pourtant, je ne vois pas dans RFC793 l'indication d'une quelconque
dépendance entre ACK et fenêtre, ou alors je lis mal.
Eh bien, tu lis mal Angelot.
En fait, la réponse m'a été donnée par un suisse, sur le newsgroup anglais.
La RFC793 décrit la machine à états de TCP. Après un détricotage fastidieux
des lignes imbriquées if... then... else..., on peut découvrir cette phrase
magique : quand un segment arrive dans l'état CONNEXION ETABLIE, si le flag
ACK n'est pas levé, le segment est détruit.
Ceci répond entièrement à ma question : même dans des rafales de segments
envoyées avec un seul acquittement cumulé du distant, tous les segments
partent avec ACK positionné (et donc un numéro de séquence et une valeur de
fenêtre).
Et pourtant, je ne vois pas dans RFC793 l'indication d'une quelconque dépendance entre ACK et fenêtre, ou alors je lis mal.
Eh bien, tu lis mal Angelot.
En fait, la réponse m'a été donnée par un suisse, sur le newsgroup anglais. La RFC793 décrit la machine à états de TCP. Après un détricotage fastidieux des lignes imbriquées if... then... else..., on peut découvrir cette phrase magique : quand un segment arrive dans l'état CONNEXION ETABLIE, si le flag ACK n'est pas levé, le segment est détruit.
Ceci répond entièrement à ma question : même dans des rafales de segments envoyées avec un seul acquittement cumulé du distant, tous les segments partent avec ACK positionné (et donc un numéro de séquence et une valeur de fenêtre).
