Résumé

  • Le RFC 1693, publié en novembre 1994 comme document expérimental, étudiait un service de transport à ordre et fiabilité partiels. Dans son exemple de quatre fiches, les requêtes admettaient respectivement un, deux, quatre ou 24 ordres de résultat.
  • Dès la première page, l'IESG refusait de recommander l'implémentation des changements proposés à TCP, tout en jugeant utile l'analyse des données désordonnées ou incomplètes au-delà de TCP.

Le guichet fermé devant une fiche déjà arrivée

Un résultat peut franchir le réseau avant son prédécesseur. Avec le flot d'octets ordonné que décrit le RFC 793, l'application attend néanmoins le morceau manquant. C'est une promesse précieuse quand chaque élément dépend du précédent. Pour une liste de résultats interchangeables, le même zèle immobilise une fiche parfaitement lisible. TCP se comporte alors comme un agent qui refuse de remettre un dossier parce que le numéro précédent n'est pas encore passé.

T. Connolly, P. Amer et P. Conrad ont mis des chiffres sur ce décalage dans le RFC 1693. Leur base imaginaire contient quatre fiches. Un tri sur quatre noms de vendeurs distincts n'accepte qu'une sortie. Un tri par ville, avec deux fiches à égalité, en accepte deux. Un tri par description, avec deux paires à égalité, en accepte quatre. Sans clause ORDER BY, les 4! permutations, soit 24, conviennent. Le tableau compte les ordres possibles dans un exemple construit. Il ne mesure ni un gain de débit ni une attente observée sur un réseau.

Entre l'ordre total et le désordre complet, les auteurs placent l'ordre partiel. Certaines fiches doivent précéder certaines autres; deux fiches indépendantes peuvent échanger leurs places. Pour fournir ce service, les correspondants doivent partager les relations de précédence, et le récepteur doit décider, à chaque arrivée, si la fiche a désormais le droit d'être livrée. La question cesse d'être « est-elle la prochaine ? » et devient « tous ses préalables sont-ils là ? »

La fiabilité constitue un autre réglage. Une recherche dans une base peut exiger finalement chaque fiche tout en tolérant plusieurs ordres. Un flux audiovisuel peut imposer un ordre dans un canal et accepter que des images devenues inutiles disparaissent. Le RFC discute vidéo, deux canaux sonores, texte et image en langue des signes, ainsi que le rafraîchissement de fenêtres. Ces scènes montrent pourquoi un contrat unique, parfaitement ordonné et parfaitement fiable, peut être plus strict que le besoin exprimé.

Les auteurs ont examiné une connexion à ordre partiel dans un cadre TCP modifié, avec un établissement de connexion capable de reconnaître un pair ordinaire. Ils ont analysé la possibilité de livrer plus tôt des objets indépendants. Le mécanisme était proposé et étudié, pas installé par décision de ce RFC dans le TCP courant. L'avertissement institutionnel est imprimé avant même l'argument : le directeur de la zone Transport et son directorat ne recommandaient pas ces modifications. Ils retenaient en revanche l'intérêt de l'analyse pour d'autres lieux que TCP.

Cette décision donne à l'article son vrai ressort historique. Les chercheurs ont montré que l'ordre n'est pas une propriété magique du paquet : il naît des dépendances de l'application et du service promis entre les deux bouts. L'IESG a tracé la limite de la proposition d'implémentation. La deuxième fiche, elle, reste une excellente question posée à tout concepteur de transport : qui lui ordonne d'attendre ?