Introduction au protocole NNTP Un livre de Wikibooks. Aller à : Navigation, rechercher Regroupés au sein de Usenet, les groupes de discussion gérés par le protocole NNTP (Networks News Transfer Protocol) ont encore de beaux jours devant eux malgré l'avancée des forums (PhpBB et consorts) sur les pages web. On peut s'y abonner, les consulter en tout temps et poster des messages. Nous allons utiliser Python pour réaliser un petit lecteur de nouvelles qui permettra de rapatrier les messages d'un groupe.
Sections [masquer] •
1 Introduction
•
2 Aperçu du protocole NNTP
•
3 Le format des messages sur USENET
•
4 Mise en œuvre avec Python
•
5 Exemple complet
•
6 Liens utiles (en anglais)
[modifier] Introduction À la fin des années 70, les protocoles pour utiliser les réseaux se multiplient. En 1972, le courriel apparaît, suivi de TCP/IP une année plus tard. Si le courriel est intéressant pour quelques échanges, la solution apparaît moins commode pour établir des discussions entre plusieurs utilisateurs. Le concept de « mailing-list » est alors inventé pour permettre des envois à plusieurs correspondants abonnés. En 1979, des étudiants de la Duke University en Caroline du Nord, Tom Truscott et Jim Ellis planchent sur une innovation en la matière : réaliser un réseau qui se chargerait de stocker les messages qui pourraient être consultés à tout moment. C'est ainsi que débute l'histoire d'Usenet, contraction de « Unix User Network ». Aidés par d'autres étudiants, ils réalisent un réseau entre leur université et la University of North Carolina. Un protocole est spécialement développé pour gérer la diffusion des nouvelles : UUCP. Le réseau de nouvelles se répand rapidement au travers d'ARPANET et d'autres types de connexions (BBS, Fidonet, X.25, etc.). En 1984, le nombre de serveurs UUCP se monte à plus de 900 mais devant un tel succès, des modifications doivent être envisagées. Une des plus importantes est le passage à TCP/IP qui le lie à Internet. De plus, UUCP constitue un gouffre à ressources : chaque serveur transmet un nouveau message à un autre serveur sans vérifier si ce dernier le possède déjà. Les serveurs croulent ainsi sous des messages inutiles qui saturent le réseau. Avec l'expansion de Usenet, la masse de messages devient rapidement ingérable. Le protocole UUCP est alors abandonné au profit de NNTP (Networks News Transfer Protocol), présenté en février 1986 par Brian Kantor et Phil Lapsley dans la RFC-977 (puis mis à jour par C.Feather dans la RFC-3977 en Octobre 2006). NNTP résout ce problème en introduisant la notion d'interaction entre les serveurs. Un serveur peut demander la liste de groupes et d'articles d'un autre serveur et rapatrier les messages désirés. Le réseau peut aussi être fragmenté entre gros
et petits serveurs, ces derniers s'occupant par exemple d'une liste plus restreinte de groupes ou faisant office de cache. Plusieurs universités dont Berkeley travaillent sur les applications côté serveur en essayant d'optimiser la gestion des messages et le système est remodelé pour obtenir la structure que nous connaissons aujourd'hui. Usenet devient une vitrine de prédilection, des annonces importantes y sont faites et des groupes concernant les sujets les plus divers allant de l'anodin au sulfureux (alt.sex, groupes de secte, etc.) se répandent. Le 6 août 1991, Tim Berners-Lee annonce dans alt.hypertext la création du « WorldWideWeb project ». Dans l'ordre des choses, le spam y fait son apparition dès 1994. On attribue la paternité du spam sur Usenet à Clarence Thomas avec le message « Global Alert For All : Jesus is Coming Soon » (17 janvier 1994). Il sera suivi peu après par un spam sur le génocide arménien puis le premier véritable spam commercial sur Usenet orchestré par deux avocats américains. schéma de fonctionnement général :
[modifier] Aperçu du protocole NNTP Le protocole NNTP est basé sur une suite de commandes et de réponses en ASCII comme SMTP. Les communications se font en général via le port 119 du serveur. Les réponses
retournées par un serveur sont divisées en deux catégories dans la RFC : réponses « textuelles » et réponses « états » sous la forme de nombres. Les indications d'états permettent de savoir si une commande envoyée par le client a été correctement traitée par le serveur. Des paramètres peuvent être joints à l'identifiant de l'état du serveur. Une certaine liberté est prévue au travers de messages de débogage. Une commande réussie retournera un code de type 2xx (par exemple, 211 pour la commande GROUP). Les codes 4xx et 5xx sont des messages d'erreurs. Instructions complémentaires au standard RFC-977 (notamment amenées par la RFC-3977) : •
ARTICLE
: permet de récupérer l'en-tête et le corps du message identifié par ID, cet identifiant prend la forme d'une adresse mail classique, par exemple
•
ARTICLE : comme avant, sauf que l'on utilise un numéro attribué selon un simple compteur propre à chaque groupe de discussions
•
HEAD ou BODY : même syntaxe que pour ARTICLE sauf qu'elles permettent d'isoler l'en-tête ou le corps du message
•
LIST : permet d'obtenir la liste des groupes disponibles sur le serveur avec des indications sur le nombre de messages et l'intervalle des numéros de messages
•
GROUP : permet de sélectionner le groupe de discussion désiré, par exemple « sci.crypt », la commande retourne « 211 » (en cas de réussite) suivi du nombre d'articles dans le groupe et les indices du premier et du dernier article.
•
IHAVE : permet d'informer le serveur que nous sommes en possession du message avec l'identifiant indiqué. Le serveur formule une demande s'il désire recevoir une copie.
•
LAST : permet d'obtenir le dernier article stocké par le serveur
•
NEXT : positionne le pointeur d’article interne sur l’article suivant
•
HELP : Invite le serveur à envoyer un texte contenant la liste des instructions disponibles
•
SLAVE : indique au serveur qu’il ne communique pas avec un utilisateur final mais avec un serveur
•
STAT: place le pointeur d’article interne sur l’article défini
•
NEWSGROUPS date heure [GMT] : permet d'obtenir les nouveaux groupes apparus depuis la date indiquée, l'indication GMT permet d'indiquer si l'heure est donnée en fonction de celle du serveur ou celle du méridien de Greenwich. (format date : YYMMDD, heure : HHMMSS)
•
NEWNEWS groupes date heure [GMT] : agit de la même manière que la commande précédente pour obtenir les messages postés après la date indiquée, le champ « groupes » accepte des wildcards et des choix multiples comme par exemple « net.*.linux » ou encore « net.*,!net.unix.* » qui accepte tous les net sauf ceux qui se terminent par unix.*
•
POST : permet d'envoyer un message. Si la procédure est autorisée, le code 340 est retourné et le format décrit dans la RFC 1036 (mise à jour de la RFC 850) doit être suivi. Nous allons y revenir plus tard.
•
QUIT : stoppe la connexion
Grâce à un client Telnet, il est possible d'expérimenter ces commandes. Voici un exemple de session sur un serveur en lecture seule mais à l'accès libre :
En plus de ces commandes conformes à la RFC-977, quelques commandes ont été ajoutés au fil du temps pour combler quelques lacunes du protocole initial : •
XGTITLE : fournit l’intitulé d’un groupe de newsgroups
•
XHDR : Retourne la valeur d’un champ cité provenant de l’entête d’un message seul ou d’un ensemble de messages
•
XOVER : Réclame la transmission d’un fichier d’aperçu sur le message actuel
•
AUTHINFO : permet au client de se déclarer auprès du serveur avec un nom d’utilisateur et d’un mot de passe.
•
DATE : interroge la date sur le serveur actuel
•
LISTGROUP : Liste les numéros des messages disponibles à l’intérieur d’un newsgroup.
•
MODE : permet de switcher entre les modes « Transit » et « Lecteur »
Exemple simple de Dialogue NNTP pour le post d'un article par un client: [C] POST [S] [C] [C] [C] [C] [C] [C] [C] [S]
340 Input article; end with . From: "Macstras" [email protected] Newsgroups: misc.test Subject: Demo pour l’expose MGP2i Organization: Personnel Article de demonstration. . 240 Article received OK
(1) (2) (3) (3) (3) (3) (3) (3) (3) (4)