Résumé

  • Le RFC 977 traitait le doublon comme un coût dépendant de la liaison : des hôtes interactifs pouvaient comparer leurs articles avant d’envoyer le texte.
  • Le même RFC conservait l’envoi puis l’élimination des doublons sur les liaisons UUCP à transaction unique, où un lot pouvait arriver plus vite qu’une négociation.

En février 1986, Brian Kantor et Phil Lapsley publièrent le RFC 977, proposition de protocole de transfert des nouvelles. Son idée la plus révélatrice n’était pas qu’un transport devait prendre le dessus sur Usenet. Le coût d’un doublon dépendait de la liaison qui le transportait. Sur un flux interactif, deux machines pouvaient comparer leurs collections avant de décider quoi envoyer. Sur une liaison ouverte une fois par jour, cette négociation pouvait prendre plus de temps que le doublon lui-même.

Le mécanisme traditionnel décrit par le RFC reposait sur la propagation en cascade : chaque site transmettait ses nouveaux articles à ses voisins, qui les retransmettaient à leur tour. Un site relié à deux fils pouvait recevoir deux fois le même article. Avec un transfert programmé ou à sens unique, l’émetteur ne pouvait pas facilement s’arrêter pour demander si le destinataire possédait déjà l’article. Celui-ci recevait le lot puis supprimait les copies répétées. Le réseau dépensait du temps et de la capacité, mais la session restait simple.

NNTP instaurait un échange préalable. Le client pouvait demander quels groupes étaient nouveaux, puis obtenir les identifiants des articles des groupes qu’il souhaitait suivre. Il réclamait ceux qui lui manquaient. Dans l’autre sens, un hôte pouvait indiquer à son voisin les articles qu’il venait de recevoir ; le serveur distinguait alors ceux déjà présents dans sa collection de ceux à lui transmettre. Le corps de l’article n’était plus la première preuve que le message avait franchi la liaison : les machines comparaient d’abord les identifiants.

Ce choix dépendait du chemin. Le RFC 977 estime que des hôtes bien reliés par un réseau local ou une autre liaison rapide pouvaient distribuer les nouvelles plus efficacement ainsi qu’avec des méthodes traditionnelles comme UUCP. Mais il explique aussi l’intérêt des lots UUCP : sur une liaison à transaction unique, surtout si elle ne s’ouvrait qu’une fois par jour, tout envoyer puis supprimer les doublons pouvait réduire le délai total. Une négociation interactive n’était pas forcément moins coûteuse parce qu’elle envoyait moins d’octets.

Le RFC décrit aussi un autre usage, qu’il faut distinguer du transfert entre sites. Une université ou une entreprise pouvait garder un spool central et laisser les postes lire les nouvelles sur le réseau local. Les lecteurs sélectionnaient les articles dans un stockage partagé, sans conserver une copie complète sur chaque poste. Un serveur intermédiaire pouvait mettre en cache les articles récemment consultés. Cela concernait l’accès des lecteurs et le stockage local ; cela ne transformait pas Usenet en base centrale unique.

Le RFC 850 avait déjà défini le format des articles Usenet tout en laissant le choix du transport aux sites : matériel, logiciels et envoi par lots pouvaient varier. Le RFC 977 s’inscrivait dans cette diversité. Il précisait une méthode sur flux pour consulter, récupérer, publier et échanger des articles, tout en reconnaissant l’avantage d’un autre transport sur les lignes intermittentes. La règle était conditionnelle : dialoguer quand le réseau le permet, regrouper les envois quand cela fait gagner du temps.

Ces documents attestent une conception, pas une migration universelle. Le RFC 977 ne donne ni la part d’Usenet passée à NNTP en 1986, ni les économies mesurées, ni la preuve que toutes les implémentations évitaient les doublons. Sa contribution est plus précise : la sélection des articles devenait un échange entre pairs, permettant au destinataire d’indiquer ce qu’il voulait et ce qu’il possédait déjà avant un nouvel envoi.

Sources : RFC 977, Network News Transfer Protocol ; RFC 850, format d’échange des messages USENET ; RFC 1036, format d’échange des messages USENET.