Résumé

  • Discard recevait des données sur le port 9, les jetait et ne renvoyait aucune réponse applicative. En TCP, l’appelant décidait quand terminer la connexion.
  • L’établissement et les acquittements TCP produisent des indices que l’UDP nu ne possède pas, mais ils ne constituent pas un reçu signé par le processus Discard.
  • En UDP, le même silence peut suivre une réception conforme, une perte, un filtrage ou l’absence de service. Une mesure défendable doit donc ajouter une observation indépendante et borner chaque conclusion.

Quand l’absence est la spécification

Un service de mesure ordinaire rend quelque chose : les octets reçus, un résultat, un code ou au moins une fermeture initiée par le serveur. Discard avait une autre ambition. Il devait fournir une destination qui accepte une charge sans fabriquer de travail de retour. Pour examiner un chemin d’émission, cette soustraction pouvait être utile.

Elle retirait aussi le signe le plus facile à interpréter. Si rien ne revient, le client ne sait pas, par l’application, si les octets sont arrivés. Le succès conforme et plusieurs échecs possibles partagent la même apparence. L’erreur consiste à croire que la norme transforme cette apparence en verdict.

RFC 863 ne disait pas que le silence prouvait la réception. Il disait qu’un serveur ayant reçu des données devait les jeter et ne pas répondre. La règle gouvernait l’action du serveur réel ; elle ne donnait pas au client la faculté d’identifier à distance la cause de toute absence.

Le client fermait la connexion TCP

Dans la version TCP, le serveur écoutait sur le port 9. Après l’établissement de la connexion, toute donnée reçue était jetée, sans réponse. Le service continuait jusqu’à ce que l’utilisateur appelant termine la connexion.

Ce dernier détail empêche une fausse procédure de test. Attendre une clôture de réussite envoyée par le serveur revient à attendre un événement absent du contrat. Le client fixe la quantité offerte et décide quand cesser. Un serveur silencieux et encore ouvert peut être parfaitement conforme.

TCP fournit néanmoins plusieurs niveaux d’observation. La connexion établie atteste qu’un point terminal TCP distant a accepté ce tuple à cet instant. Les numéros de séquence, acquittements, retransmissions, remises à zéro et délais permettent ensuite de suivre la responsabilité du transport.

RFC 9293 précise que le TCP destinataire acquitte lorsqu’il prend la responsabilité de livrer les données à son utilisateur. Cette phrase est plus étroite qu’un reçu applicatif. Elle ne certifie pas qu’un appel de lecture du processus Discard a eu lieu, qu’un compteur a progressé ou que l’opérateur a autorisé la charge.

Même l’appel local d’envoi doit être qualifié. RFC 9293 décrit la possibilité d’un retour immédiat au processus émetteur alors que le TCP distant n’a pas encore acquitté le segment. Le succès de write peut donc s’arrêter à la pile locale. Seuls l’état ultérieur et les garanties de l’interface permettent d’aller plus loin.

Si l’objectif exige de prouver que le processus distant a consommé exactement une quantité donnée, il faut un second témoin : compteur serveur, trace du processus, capture reliée au point terminal ou canal de contrôle séparé. Ce témoin enrichit l’essai ; il ne révèle pas un message secret de RFC 863.

En UDP, le silence ne choisit pas une histoire

Le service UDP écoutait lui aussi sur le port 9. À la réception d’un datagramme, il le jetait et n’envoyait rien. Aucun état de connexion, identifiant de transaction ou décompte ne liait la tentative à une observation distante.

RFC 768 prévient que la livraison et la protection contre les duplications ne sont pas garanties. Discard n’ajoutait aucun mécanisme de fiabilité. L’absence de réponse peut donc suivre cinq états incompatibles : traitement conforme, perte en chemin, filtrage, aucun auditeur, ou message d’erreur que l’application n’a pas reçu.

RFC 8085 limite aussi la valeur d’ICMP. Les messages d’erreur peuvent être filtrés par les intermédiaires ; une application UDP ne doit pas dépendre de leur livraison pour fonctionner correctement et sûrement. Un ICMP validé apporte une information. Aucun ICMP n’apporte pas la preuve opposée.

Une expérience contrôlée peut installer son propre dénominateur : nombre de datagrammes envoyés d’un côté, nombre vu par une capture ou un compteur de processus de l’autre, fenêtre de temps et lieu d’observation. Sans ce dispositif, « aucune réponse » demeure une ligne de journal, pas un taux de livraison.

Une soustraction qui distingue Discard d’Echo

Echo renvoie ce qu’il reçoit. Character Generator émet de nouvelles données. Discard supprime précisément ce trajet retour au niveau applicatif. Il ne peut donc pas former la boucle de réponses Echo/Chargen décrite dans un article précédent : aucune réponse Discard ne devient la demande suivante.

Cela ne rend pas l’exposition gratuite. Une destination muette peut consommer débit, files, descripteurs, temps processeur et attention opérationnelle. Les sources fermées ne fournissent toutefois ni fréquence d’abus actuelle ni facteur universel. L’analyse doit rester sur l’autorisation de la charge, la capacité et la qualité de la preuve.

Le bénéfice du service était de séparer l’émission du calcul d’une réponse. Son coût épistémique était de supprimer le matériau de comparaison. Avec Echo, le client peut au moins comparer des octets aller-retour, sans pour autant authentifier le pair. Avec Discard, la confirmation doit venir d’un autre niveau.

IANA nomme le port, pas le processus

Le registre IANA associe encore discard au port 9 pour TCP et UDP, ainsi que pour SCTP et DCCP avec d’autres références. RFC 863 définit directement les deux premiers cas. Le registre préserve un vocabulaire commun ; il ne déploie pas les services.

RFC 6335 place le port 9 dans la plage des ports système et explique la différence entre valeurs attribuées, non attribuées et réservées. « Attribué » décrit l’état du registre. Il ne prouve ni qu’une adresse écoute, ni que le processus rencontré est conforme, ni que l’accès public est autorisé.

Cette séparation est décisive pour un protocole silencieux. Le numéro ne peut pas combler l’absence d’observation. Une connexion TCP renseigne davantage qu’un registre ; un compteur sous le contrôle de l’opérateur renseigne davantage qu’une connexion. Chaque autorité doit rester à sa place.

Définir la preuve avant le débit

Un rapport sérieux formule d’abord sa proposition. « La pile locale a accepté le tampon », « le TCP distant a pris en charge cette plage », « le processus Discard a consommé le flux » et « 99 % des datagrammes ont atteint le récepteur » exigent quatre ensembles de mesures différents.

Il faut conserver le tuple, les horaires, le transport, les octets acceptés localement et acquittés à distance, les retransmissions, les erreurs, l’initiateur de la fermeture et les compteurs côté récepteur. Une seule case verte efface la chaîne de preuve.

La réception d’une réponse applicative est elle-même un signal : l’extrémité ne se comporte pas comme le Discard de RFC 863. Il faut alors préserver le contenu et l’identité observable, non conclure qu’un port bien connu authentifie le service.

Sources et limites

Le mécanisme vient de RFC 863, et le statut elective de RFC 880. Les limites de connexion, d’acquittement et d’interface TCP proviennent de RFC 9293. Les non-garanties UDP sont celles de RFC 768, complétées par les précautions de RFC 8085.

La gouvernance des numéros repose sur RFC 6335 et le registre IANA. Ces textes ne mesurent pas le déploiement, les performances, le trafic ou les abus actuels et n’identifient aucun service vivant.