Résumé

  • Le point de reprise suivant était relevé sur l'horloge du serveur avant l'exécution de NEWNEWS, tandis que la recherche partait de la borne conservée lors de la session précédente.
  • Deux interrogations se recouvraient donc. Un même Message-ID pouvait réapparaître, mais ce doublon était observable et supprimable ; un intervalle sauté ne l'était pas.
  • La liste ne décrivait qu'une vue située : arrivées sur ce serveur, groupes sélectionnés, période demandée et commande effectivement disponible.

Un manque parfaitement silencieux

Le piège tient dans quelques secondes. Un lecteur lance une recherche, le serveur constitue sa réponse, puis le lecteur enregistre l'heure de fin comme prochain départ. Entre le début et la fin, un article arrive. Il peut être trop tard pour entrer dans la sélection déjà amorcée et pourtant trop ancien pour franchir la nouvelle borne. Les deux réponses successives paraissent cohérentes. Aucun code d'erreur ne signale l'article absent.

Une base de données peut alors sembler propre précisément parce qu'elle a perdu la seule preuve de son manque. C'est ce type d'échec que la procédure de RFC 3977 évite : avant d'interroger, le client demande DATE et garde la valeur en mémoire temporaire. Il recherche depuis l'ancien horodatage. Ce n'est qu'après la relève qu'il remplace ce dernier par l'heure déjà obtenue.

Le prochain passage recommence donc un peu trop tôt. L'inconfort est visible : certains identifiants reviennent. Mais la zone pendant laquelle la première réponse était en fabrication reste couverte.

En 1986, une liste d'identifiants

RFC 977 définissait NEWNEWS comme une commande de découverte. Le client indiquait des groupes de discussion, une date et une heure ; le serveur énumérait les Message-ID des articles publiés ou reçus depuis cette limite. Des motifs élargissaient la sélection, un point d'exclamation excluait une branche et une liste vide constituait une réponse valide.

Le contenu même de la réponse imposait une discipline. Elle ne transportait pas les corps d'articles. Elle donnait des clés permettant de demander ensuite ce qui intéressait le lecteur. Trouver un identifiant n'équivalait donc ni à posséder l'article, ni à garantir sa conservation future.

La première syntaxe autorisait aussi un paramètre de distribution. RFC 2980 a plus tard constaté que les implémentations ne lui donnaient pas toutes le même sens. Le texte notait en outre que NEWNEWS faisait partie des commandes souvent désactivées. L'histoire du mécanisme est donc aussi celle d'une limite : une norme disponible n'est pas une fonction assurée partout.

« Nouveau » pour quel témoin ?

NNTP distingue plusieurs clés. Le Message-ID vise l'identité globale de l'article. Le couple groupe-numéro ne vaut que sur un serveur. L'horodatage d'arrivée, lui, indique quand ce serveur a reçu l'article. C'est cette troisième valeur que NEWNEWS consulte.

Le choix écarte la date rédigée par l'auteur. Un article retardé ou mal daté peut être nouveau pour le serveur aujourd'hui. Inversement, le même article possède des heures d'arrivée différentes selon les relais. NEWNEWS ne promet donc pas une chronologie universelle d'Usenet. Il répond à une question plus modeste : qu'est-il entré ici, dans ces groupes, depuis la borne donnée ?

Cette modestie explique DATE. RFC 2980 présentait la commande comme l'heure GMT vue par le serveur. RFC 3977 exige ensuite qu'elle provienne de la même horloge que celle qui fixe les arrivées d'articles et les créations de groupes. Le client n'emprunte pas cette horloge pour remplacer NTP. Il emprunte le référentiel du témoin qui décidera plus tard si une arrivée est postérieure à la borne.

Le chevauchement comme preuve de continuité

La procédure comporte deux états : un point de reprise durable, hérité de la dernière relève, et une heure temporaire, capturée avant la nouvelle recherche. Les confondre ouvre le trou. Les séparer permet de redémarrer : si le traitement échoue avant validation, l'ancien point reste en vigueur et l'intervalle sera rejoué.

RFC 3977 va plus loin. Pour absorber de petites erreurs, le client peut reculer sa borne de deux ou trois minutes. L'exemple de la norme montre alors le même Message-ID dans deux réponses consécutives. Le doublon n'est pas un accident honteux ; il matérialise la marge de sûreté.

La commande n'offre par ailleurs aucun ordre stable. Le serveur peut ordonner différemment deux réponses d'une même session et peut répéter un Message-ID dans une seule liste. Le client doit raisonner comme sur un ensemble : identité, présence, rapprochement. La position d'une ligne ne possède aucune autorité temporelle.

Une sûreté strictement bornée

Le chevauchement ferme une course, pas toutes les lacunes possibles. Un motif de groupes trop étroit restera trop étroit. Une commande absente ne devient pas disponible. Une politique de rétention peut avoir effacé un article avant la reprise. Une réponse interrompue ne doit pas faire avancer la borne. Et deux serveurs ne partagent pas nécessairement la même histoire d'arrivée.

Le registre IANA des paramètres NNTP inscrit NEWNEWS comme capacité signalant la disponibilité de la commande. Cette inscription établit un nom interopérable ; elle ne certifie ni activation, ni exhaustivité d'un serveur donné.

Reste la décision de conception : choisir l'échec qui laisse des pièces au dossier. Un doublon porte son Message-ID. On peut compter sa réapparition, vérifier l'écart et le réunir avec l'enregistrement déjà connu. Un article sauté entre deux bornes ne laisse rien dans la collection locale. Il ressemble au calme.

La borne raconte ce que l'on ose abandonner

Un point de reprise n'est pas seulement une heure. Il affirme que tout ce qui précède a été observé et accepté avec assez de solidité pour ne plus être demandé. Le placer après la réponse revient à certifier un intervalle que personne n'a intégralement examiné.

NNTP a retenu une autre économie : relire un peu, identifier ce qui revient, ne déplacer la borne qu'après traitement. Le réseau n'y devenait pas parfait. Mais son incertitude prenait une forme que l'on pouvait encore auditer.

Sources