Résumé

  • Le RFC 977 permettait à un lecteur de demander des articles choisis dans une base centrale hébergée par un ou quelques serveurs locaux, au lieu de conserver une copie complète sur chaque poste.
  • Kantor et Lapsley distinguaient cette lecture de l’échange d’articles entre serveurs. Le texte évoquait aussi des caches intermédiaires, mais ne spécifiait pas leur fonctionnement.
  • Le RFC énonce une économie de stockage attendue, sans mesurer les gains ni l’adoption. Il concentre stockage, indexation, expiration et disponibilité dans le service local sans centraliser toute Usenet à l’échelle mondiale.

Le poste n’avait pas à porter toute l’archive

Le point de départ du RFC 977 n’est pas un réseau mondial abstrait. C’est un groupe de machines reliées par un réseau local, dont certaines stations de travail disposent de peu d’espace disque. Faut-il que chacune conserve tous les articles de nouvelles avant que son utilisateur puisse en lire un seul ?

En février 1986, Brian Kantor, à l’Université de Californie à San Diego, et Phil Lapsley, à Berkeley, proposent une frontière client-serveur. Un hôte central conserve la collection d’articles et les fichiers d’index. Les lecteurs des autres machines s’y connectent par TCP pour demander les éléments qui les intéressent. L’indexation, les références croisées et l’expiration des anciens messages appartiennent au modèle du dépôt; le poste individuel n’a pas à devenir une seconde archive.

Le raisonnement porte à la fois sur la capacité et sur la diversité des machines. Pour un grand groupe, éviter les copies identiques sur chaque hôte peut réduire l’espace disque total et permettre aux stations les plus modestes de participer. Le RFC préfère aussi un flux TCP à l’hypothèse d’un système de fichiers partagé compatible avec des clients différents. Le protocole expose un service commun; il n’impose pas la même organisation des disques à tous les systèmes.

Le mot « central » doit rester à son échelle. Dans les sections consacrées à la lecture, il s’agit du serveur central d’un réseau local, parfois d’un petit groupe d’hôtes. Le texte ne décrit pas une machine qui stockerait toutes les nouvelles Usenet pour tous les lecteurs. Une collection locale peut être partagée sans abolir les relations entre serveurs ailleurs.

Deux trajets de partage

NNTP sert aussi aux serveurs qui veulent obtenir leurs propres copies d’articles. Le RFC 977 distingue ce trajet de celui d’un lecteur qui interroge son serveur local. Un hôte peut demander à un voisin quels groupes ou articles sont nouveaux, choisir ceux qu’il souhaite recevoir et signaler ce qu’il possède déjà. L’objectif est de ne transférer que les articles voulus et absents.

La différence est décisive. Le dépôt commun évite de multiplier les copies à l’intérieur d’un groupe de machines; l’échange entre hôtes détermine quelles copies circulent d’un site à l’autre. Une lecture centralisée dans un laboratoire ou une université reste compatible avec une distribution entre pairs. Résumer NNTP à la centralisation ferait disparaître cette seconde moitié.

Le rôle du serveur reste circonscrit. Le RFC le présente comme une interface entre les programmes et la base d’articles. La présentation à l’écran, la navigation et les choix propres à l’utilisateur sont laissés aux logiciels clients, qui connaissent mieux leur environnement. Le document normalise la conversation sur le réseau, pas toute l’expérience de lecture.

Le cache restait à concevoir

Pour les groupes plus importants, Kantor et Lapsley suggèrent un serveur intermédiaire capable de relayer les demandes et de mettre en cache les articles récemment lus. Un client pourrait d’abord essayer ce serveur local; en cas d’échec, l’installation choisirait de refuser le service ou de joindre l’hôte central.

Cette esquisse reconnaît le coût d’un dépôt partagé: que se passe-t-il quand l’hôte tombe ou qu’un article est déjà disponible près du lecteur ? Mais les auteurs précisent que le fonctionnement des serveurs esclaves n’entre pas dans le RFC. Le cache est une piste, pas une garantie de disponibilité ni un protocole complet de bascule. Chaque site doit donc définir lui-même l’actualité des copies, les règles de repli et la reprise après panne.

La charge change d’endroit

Le bénéfice attendu est d’éviter que chaque poste stocke l’ensemble des nouvelles. L’espace disque ne disparaît pourtant pas; il se concentre sur le serveur, qui héberge aussi les index et applique les règles d’expiration. Les lecteurs gagnent un poste plus léger, tandis que l’opérateur du service assume davantage de capacité et de continuité.

Il s’agit d’une conséquence architecturale, pas d’un bilan mesuré dans le RFC. Celui-ci juge l’économie intéressante pour un grand groupe, mais ne publie ni volumes de disque économisés, ni taux d’adoption, ni charge serveur, ni résultats d’usage. Il faut séparer la raison de conception de la preuve d’un déploiement réel.

La disponibilité suit le même déplacement. Si plusieurs lecteurs dépendent d’un même hôte, sa panne, ses index ou sa politique d’expiration deviennent visibles à l’échelle du groupe. Un cache local pourrait réduire cette dépendance, mais son fonctionnement étant hors du périmètre du RFC, la résilience restait une décision d’exploitation. Le dépôt commun remplace des copies locales par un service qu’il faut maintenir.

Une architecture poursuivie dans les RFC suivants

En octobre 2006, le RFC 3977 a déclaré obsolète le RFC 977 et s’est présenté comme son remplacement, avec des clarifications et de nouvelles fonctions de base. Son introduction décrit toujours la récupération d’articles conservés dans une base centrale. Le RFC 4644, publié le même mois, formalise pour sa part le transfert asynchrone entre serveurs grâce à CHECK et TAKETHIS.

Ces textes ne prouvent pas qu’un site donné déployait NNTP conformément aux RFC. Ils montrent toutefois deux lignes d’évolution: permettre à un lecteur d’accéder au dépôt et rendre plus efficace le transport d’articles entre pairs. Ce sont deux fonctions reliées, mais elles ne se confondent pas.

Situer la contribution de Kantor

Une notice commémorative de l’Université de Californie à San Diego décrit les 47 années de carrière de Kantor à l’université, son travail de maître de poste et d’opérateur de serveurs de noms, ainsi que sa participation à l’infrastructure réseau. Elle lui attribue la conception de NNTP. Le RFC de 1986 précise l’attribution technique: Kantor et Lapsley en sont les coauteurs. La biographie replace le protocole dans une carrière d’exploitation des services; le document conserve la trace de sa collaboration.

L’apport durable de cette proposition tient à la frontière qu’elle rend lisible: partager localement un dépôt de lecture, laisser l’interface au client et traiter la réplication entre serveurs comme un autre échange. Ce choix allège certains postes mais concentre des responsabilités opérationnelles. Les textes précisent le mécanisme et son intention; les résultats réels de stockage, de disponibilité et d’adoption ne sont pas établis par les sources citées.

Sources