Coïncidence, j'étais justement en train de lire le RFC793 quand je suis tombé sur ce journal.
Merci pour la référence, c'est effectivement la « suite » des documents que je cite.
C'est rigolo, j'ai justement demandé par mail hier à Stéphane Bortzmeyer si ce cas de connexion simultanée existait en réalité. Je colle sa réponse (je pense qu'il ne m'en voudra pas, même si un mail est censé être privé), qui indique justement que ça peut se produire avec un port source fixe:
Oui, et en fait il faut se remettre en tête le contexte de l'époque : le réseau était beaucoup moins grand, moins dynamique, les processus aussi, et on mettait alors en place des « associations » entre processus sur des machines distantes en fixant statiquement certains paramètres. Ainsi, on pouvait éventuellement fixer complètement une association en y mettant les adresses locales et distantes, ainsi que les ports. Une association est alors ouverte (la commande OPEN de l'API de l'époque, décrit dans le 2.7 de ta RFC 793). Ce qui déclenche la synchronisation de numéro de séquence est l'activation de la socket, soit en l'indiquant explicitement, soit à l'époque également à l'envoi de données (c.f. 2.4.1 de l'IEN 21).
C'est une chose qui n'est pas tout à fait reflétée dans l'API des socket d'aujourd'hui : on ne peut pas (à ma connaissance) fixer d'adresse et le port d'une socket distante avec cette API en TCP sans l'activer immédiatement. En UDP, on peut tout à fait faire un ''connect'' (oui, ça peut sembler étrange pour un protocole « non-connecté ») pour les fixer à l'avance, si on n'accepte que les connexions d'un processus sur un nœud précis du réseau, et cela ne générera absolument aucun trafic.
Je ne connaissais par contre pas l'utilisation historique de ce genre de chose dans le DNS ou BGP : merci à Stéphane, donc.
Et tu donnes dans ce billet un exemple concret. Merci, ça tombe très bien :)
Exemple concret mais d'une utitilée très limitée quand même... Il sert quand même à réfléchir aux principes qui sous-tendent TCP. De rien :-)
[^] # Re: RFC793
Posté par benoar . En réponse au journal SYN c'est pour « SYNchronisation ». Évalué à 3.
Merci pour la référence, c'est effectivement la « suite » des documents que je cite.
Oui, et en fait il faut se remettre en tête le contexte de l'époque : le réseau était beaucoup moins grand, moins dynamique, les processus aussi, et on mettait alors en place des « associations » entre processus sur des machines distantes en fixant statiquement certains paramètres. Ainsi, on pouvait éventuellement fixer complètement une association en y mettant les adresses locales et distantes, ainsi que les ports. Une association est alors ouverte (la commande OPEN de l'API de l'époque, décrit dans le 2.7 de ta RFC 793). Ce qui déclenche la synchronisation de numéro de séquence est l'activation de la socket, soit en l'indiquant explicitement, soit à l'époque également à l'envoi de données (c.f. 2.4.1 de l'IEN 21).
C'est une chose qui n'est pas tout à fait reflétée dans l'API des socket d'aujourd'hui : on ne peut pas (à ma connaissance) fixer d'adresse et le port d'une socket distante avec cette API en TCP sans l'activer immédiatement. En UDP, on peut tout à fait faire un ''connect'' (oui, ça peut sembler étrange pour un protocole « non-connecté ») pour les fixer à l'avance, si on n'accepte que les connexions d'un processus sur un nœud précis du réseau, et cela ne générera absolument aucun trafic.
Je ne connaissais par contre pas l'utilisation historique de ce genre de chose dans le DNS ou BGP : merci à Stéphane, donc.
Exemple concret mais d'une utitilée très limitée quand même... Il sert quand même à réfléchir aux principes qui sous-tendent TCP. De rien :-)