Résumé

  • Le maître MTP déclarait un message accepté après avoir vu data[eom] et tous les paquets intermédiaires ; il le laissait en attente ou le rejetait selon l’incomplétude et son appréciation de l’état du producteur.
  • Un vecteur roulant de douze positions propageait ces états, tandis que la réussite des consommateurs restait normalement silencieuse et que les pertes déclenchaient des NAK.
  • Cette décision établissait un accord de transport et un ordre ; elle ne prouvait ni la réception positive de chaque consommateur, ni le traitement applicatif, ni l’identité authentifiée, ni un résultat durable.

Douze cases n’étaient pas douze témoins

La structure la plus révélatrice de MTP tenait dans un enregistrement compact. Un drapeau indiquait si une synchronisation était requise. À côté, douze éléments de deux bits portaient les états accepté, en attente ou rejeté des douze messages précédents. Le premier concernait le message immédiatement antérieur, puis les autres reculaient dans l’histoire.

Il serait facile de lire ce tableau comme un vote des membres. RFC 1301 disait autre chose. Seul le maître pouvait fixer l’état. Les membres apprenaient le verdict en lisant les paquets suivants. Le vecteur distribuait donc une décision commune ; il ne rassemblait pas douze témoignages indépendants.

Cette différence protège la signification du mot « accepté ». Dans la juridiction du protocole, le terme était précis. Hors de cette juridiction, il ne répondait pas à la question du traitement métier.

Le multicast IP ne promettait pas l’arrivée partout

RFC 1112 définissait le groupe multicast comme un ensemble dynamique de machines rassemblées par une adresse. Les datagrammes y recevaient la même livraison au mieux que les datagrammes IP ordinaires. Ils n’étaient garantis ni intacts chez tous les membres, ni dans le même ordre.

MTP ajoutait une couche de transport à cette base. Il appelait web l’ensemble des processus collaborateurs. Le web devait avoir un maître. Les autres membres pouvaient produire et consommer, ou seulement consommer. Le maître gouvernait l’admission, les paramètres et les jetons de transmission. Un producteur obtenait un jeton et le numéro de message associé avant d’envoyer ses données.

La réplication de datagrammes et l’ordre des messages appartenaient ainsi à deux autorités différentes. IP transportait vers un groupe. MTP organisait la production et l’accord. L’application restait encore au-dessus.

Le silence était une économie de protocole

MTP reposait sur les accusés négatifs. Un consommateur qui constatait un trou demandait les paquets manquants. Celui qui ne voyait pas d’anomalie n’envoyait normalement pas de confirmation positive au producteur. Le silence réduisait le trafic retour qui, dans un grand groupe, aurait pu submerger le réseau.

Ce choix donnait au silence une valeur conditionnelle : aucun défaut détecté n’avait déclenché de NAK dans l’intervalle pertinent. Il ne produisait pas un reçu durable par application. Il ne disait pas qu’un utilisateur avait lu le contenu, qu’une commande était autorisée ou qu’un système externe avait changé d’état.

L’absence de réponse n’était donc pas une absence de conception. C’était le cœur du compromis. Mais une archive qui remplace ce compromis par « tous les destinataires ont confirmé » invente des paquets qui n’ont jamais existé.

Le maître décidait à partir de sa propre observation

Le maître marquait accepté lorsqu’il avait vu la fin data[eom] et tous les paquets intermédiaires. Si le message restait incomplet mais que l’émetteur lui paraissait encore opérationnel et connecté, l’état demeurait en attente. Si l’émetteur paraissait défaillant ou isolé par une partition, le message devenait rejeté.

Le verdict mêlait donc deux types d’éléments : la complétude observable et une appréciation de la disponibilité du producteur. Pour auditer une décision, il faut garder les paquets vus par le maître, l’association au numéro de message et la raison du jugement de disponibilité. Le vecteur seul montre le résultat, pas tout son raisonnement.

Surtout, les données du client étaient des octets sans interprétation pour MTP. Le maître pouvait prouver sa complétude de transport sans savoir si le contenu formait une requête valide. Une application pouvait refuser un message parfaitement accepté, le reconnaître comme doublon ou ne produire aucun effet.

Le vecteur empêchait de cacher une incertitude

Une mémoire roulante finit par oublier. Les états plus anciens que douze messages sortaient du vecteur. RFC 1301 assumait cette limite, mais empêchait un cas dangereux : un message encore en attente ne pouvait pas être poussé hors de la dernière case.

Si l’incertitude atteignait le bord, le maître devait cesser de confirmer de nouveaux jetons jusqu’à pouvoir accepter ou rejeter le plus ancien message. L’inconnu devenait une contre-pression visible. Le système ne pouvait pas afficher une progression illimitée en effaçant sa dette de décision.

Une fois le verdict final sorti normalement, cependant, les en-têtes suivants ne le conservaient plus. Le vecteur était un mécanisme de coordination, pas un journal permanent. Un service d’archives devait enregistrer séparément le verdict et les observations qui l’avaient produit.

Même le jeton révélait une ambiguïté

Les paquets de contrôle ne consommaient pas les numéros ordinaires. Quand un producteur répétait une demande de jeton, le maître ne savait pas nécessairement s’il s’agissait d’un nouveau besoin ou de la répétition d’une demande dont la confirmation avait été perdue. Il pouvait aussi avoir manqué toutes les données déjà envoyées, ou voir la nouvelle demande dépasser l’ancienne confirmation en transit.

Le protocole choisissait une réponse : si le jeton restait en attente du point de vue du maître, celui-ci pouvait le réattribuer. Une confirmation dupliquée ordonnait alors au producteur de retransmettre les données déjà associées au numéro. Un producteur qui n’en avait plus besoin rendait le jeton avec empty[cancel].

La retransmission résolvait l’état pratique sans prouver quel paquet avait disparu. Demande, confirmation, observation du maître et nouvelle émission restaient des faits distincts.

La récupération avait un prix et une échéance

Le rythme dépendait de trois paramètres partagés. heartbeat fixait l’intervalle. window limitait les paquets nouveaux et retransmis qu’un producteur pouvait émettre durant cet intervalle. retention imposait combien de battements les données devaient rester disponibles pour réparation.

Sans paquet plein, le producteur utilisait empty[dally] pour signaler sa présence et maintenir la synchronisation. Les messages courts étaient prolongés jusqu’à compter au moins autant de paquets que la rétention, afin d’augmenter la probabilité qu’un consommateur voie quelque chose du producteur. Répéter améliorait l’observation ; cela ne créait pas une attestation universelle.

Un trou de séquence ou un fragment inachevé suivi d’un battement silencieux provoquait un NAK unicast. Le producteur retransmettait les plages demandées à tout le web. La réparation utilisait la fenêtre, précédait les données nouvelles et créait des doublons chez les membres qui n’avaient rien perdu. Ils devaient les ignorer.

Si les données avaient déjà quitté la rétention, nak[deny] constatait l’impossibilité de réparation. Le client devait recevoir un rapport d’échec. Ici, l’échec devenait explicite, tandis que le chemin ordinaire demeurait silencieux.

Adresse, appartenance et sécurité restaient ailleurs

Sur IP, MTP exigeait le niveau 2 de RFC 1112, utilisait le groupe permanent 224.0.1.9 et passait par un petit pont sous le numéro de protocole IP 92. Les ports, TSAP et identifiants de connexion localisaient une instance de transport.

Ils ne l’authentifiaient pas. RFC 1301 indiquait que les questions de sécurité n’étaient pas traitées. L’appartenance reconnue par le protocole, le rôle de maître et un identifiant de connexion ne suffisaient donc pas à prouver une personne, une organisation ou une autorisation.

RFC 1458 a montré le coût du centre

Un an plus tard, RFC 1458 a examiné MTP pour la diffusion de grandes images. Le document reconnaissait le maître, les jetons, le contrôle de débit, la récupération sélective par NAK et la gestion des doublons. Il relevait aussi les dépendances externes pour l’adresse et certains identifiants, ainsi que le délai et la congestion produits par un trafic de contrôle presque entièrement centré sur le maître.

Cette critique concernait un besoin précis. Elle ne changeait pas rétroactivement le sens d’accepté. Elle rappelait qu’une autorité de consensus a aussi un coût de capacité et un domaine d’emploi.

Sources et limites

Ces textes établissent des mécanismes et une analyse historique. Ils n’établissent aucun web MTP réel, aucune population de récepteurs, identité authentifiée, exécution applicative, adoption ou résultat opérationnel.