Les Forums
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
TCP : Aux bornes des numéros de séquence
Bonjour, Intro : Dans TCP, chaque octect envoyé est lié à un numéro de séquence codé sur 32 bits. Ce numéro de séquence, fixé lors de l'initialisation (mettons 2000) permet entre autre de réorganiser les paquets reçus, ainsi un paquet ayant le numérode séquence 2200 coorespond à des données situées après celles contenues dans un paquet ayant le numéro de séquance 2100. Question: Existe-t-il des hypothèses que l'on peut faire quand on atteint les limites des 32 bits? Ou bien Comment peu-on faire techniquement que gérer le rebouclage des numéro de séquence une fois 2^32-1 atteint? Merci Je cherhche à suivre l'évolution des numéros de |
Question: Existe-t-il des hypothèses que l'on peut faire quand on atteint les limites des 32 bits? Ou bien Comment peu-on faire techniquement que gérer le rebouclage des numéro de séquence une fois 2^32-1 atteint? On reboucle à 0. Ca se produisait environ toutes les 9h pour l'ISN quand il croissant de 64000 toutes les demi secondes. Maintenant c'est aléatoire (pour des raisons de sécurité) donc ça peut arriver plus ou moins souvent. |
En lisant le RFC j'ai bien compris qu'il rebouclait à zero, mais cela signifie donc qu'au niveau des tests effectués lors du passage à zéro il faut prévoir certains mécanismes. Je pense notamment au numéro de séquence qui "subitement" seraient invalides , voir ci dessous Packet X : RCV.NXT = 2^32 - 1458 SEG.SEQ = 2^32 - 1457 (SEG.SEQ >= RCV.NXT) : VRAI (le packet est valide (disons à peu près valide) Packet X + 1: RCV.NXT = 2^32 - 1 SEG.SEQ = 0 (SEG.SEQ >= RCV.NXT) : FAUX le packet serait non valide |
Je crois qu'il y a une méthode de calcul particulière quand on boucle. A voir dans les implémentations de pile TCP. |