Un exemple d'application: SMTP

Pour donner une petite idée de ce qui se passe au niveau des protocoles d'application, je vais prendre l'exemple de SMTP (Simple Mail Transfer Protocol), qui est le protocole de messagerie. Supposons que l'ordinateur TOPAZ.RUTGERS.EDU veuille envoyer le message suivant:

Date: Sat, 27 Jun 87 13:26:31 EDT

From: bardosoft2000@gmail.fr

to: bardosoft@bardosoft.net

Subject: Reunion

Allons-y ensemble Lundi a 13H

Notons tout d'abord que le format du message est décrit par un standard Internet (RFC 822), qui précise que le message doit être codé en ASCII réseau, avec une structure générale composée d'un groupe de lignes d'en-tête, d'une ligne blanche, et ensuite du corps du message. La syntaxe des lignes de l'en-tête est également définie en détail (mot clé suivi d'une valeur).

A l'origine, les adresses étaient simplement de la forme: SPMlt;<nom-de-personne à nom-de-machineSPMgt;>, les derniers standard ont rendu les choses plus souples : on peut maintenant distribuer automatiquement des messages à des ordinateurs ne faisant pas partie de l'Internet, on peut également envoyer les messages à un serveur central de messagerie qui les distribue aux destinataires. Il n'est plus nécessaire qu'il existe, physiquement, un ordinateur du nom de RED.RUTGERS.EDU, les serveurs de noms peuvent être configurés de façon à pouvoir envoyer des messages à des noms de services, et chaque message du service est routé vers l'ordinateur correspondant. La partie précédent le SPMlt;<@SPMgt;> n'est plus obligatoirement un nom d'utilisateur. Les programmes eux mêmes peuvent envoyer des messages. On peut aussi gérer des listes de distribution et des noms génériques comme SPMlt;<postmasterSPMgt;> ou SPMlt;<operatorSPMgt;>.

La façon d'envoyer les messages est décrite dans les RFCs 821 et 974. Le programme qui doit envoyer le message interroge le serveur de noms pour déterminer la route à suivre, la première question permet de connaître les machines qui gèrent les messages pour le nom RED.RUTGERS.EDU, dans notre cas le serveur de noms indique que c'est RED.RUTGERS.EDU qui gère ses propres messages, la deuxième question permet de trouver l'adresse Internet de RED.RUTGERS.EDU (128.6.4.2). Le programme de messagerie peut, maintenant, ouvrir une connexion TCP sur le port 25 de 128.6.4.2 (25 est le port réservé pour la réception de messages), une fois la connexion établie le client de messagerie commence à envoyer des commandes préfixées par son nom (TOPAZ a initialisé la connexion ):

RED220 RED.RUTGERS.EDU SMTP Service at 29 Jun 87 05:17:18 EDT

TOPAZHELO topaz.rutgers.edu

RED250 RED.RUTGERS.EDU - Hello, TOPAZ.RUTGERS.EDU

TOPAZMAIL From:<hedrick@topaz.rutgers.edu>

RED250 MAIL accepted

TOPAZRCPT To:<levy@red.rutgers.edu>

RED250 Recipient accepted

TOPAZDATA

RED354 Start mail input; end with <CRLF>.<CRLF>

TOPAZDate: Sat, 27 jun 87 13:26:31 EDT

TOPAZFrom: hedrick@topaz.rutgers.edu

TOPAZSubject: reunion

TOPAZ

TOPAZAllons-y ensemble Lundi a 13H

TOPAZ.

RED250 OK

TOPAZQUIT

RED221 RED.RUTGERS.EDU Service closing transmission channel

Notez tout d'abord que toutes les commandes sont en langage naturel, ceci est spécifique des standards Internet et facilite considérablement les diagnostics. Par exemple, le programmme de messagerie garde, dans un fichier, une trace de chaque conversation, si quelquechose se passe mal il suffit d'envoyer ce fichier à la personne responsable de la messagerie (postmaster). Pour des tests on peut également interagir directement avec le serveur de messagerie. (Certains protocoles plus récents sont trop complexes pour permettre cela, ils utilisent le format binaire et des structures semblables aux enregistrements de C ou Pascal).

Vous avez aussi remarqué que toutes les commandes sont précédées d'un nombre, ceci est également caractéristique des protocoles Internet, toutes les réponses possibles sont définies dans le protocole. Ces nombres permettent des réponses non ambigües, la suite de la réponse, sous forme de texte, est destinée à l'utilisation par un être humain et n'est, en général, pas interprétée par le programme de messagerie. Les commandes elles-mêmes sont simplement utilisées, par le programme de messagerie (client), pour fournir au serveur les informations nécessaires à la délivrance du message. Dans ce cas, le serveur pourrait prendre les informations directement dans le message, mais cela ne serait pas assez sûr pour des cas plus complexes. Chaque session doit commencer par une commande HELO pour donner le nom du système qui initialise la connexion, à partir de ce moment là l'expéditeur et le destinataire sont connus (il peut y avoir plus d'une commande RCPT, s'il y a plusieurs destinataires). Enfin on envoie les données, notez que le texte du message se termine par une ligne contenant seulement un point (si une telle ligne apparait dans le message, le point est alors doublé). Aprés l'acceptation du message, l'émetteur peut envoyer un autre message ou terminer la session.

Généralement, pour une commande donnée, le protocole définit des réponses qui peuvent être envoyées, ce qui permet aux programmes, qui ne veulent pas les analyser en détail, de ne regarder que le premier chiffre. En général, les réponses qui commencent par un 2 indiquent que tout c'est bien passé, un 3 indique que l'on attend d'autres actions, 4 et 5 représentent une erreur (4 pour une erreur temporaire comme le manque d'espace disque, 5 pour une erreur permanente comme l'inexistance du destinataire), dans ces deux cas le message doit être renvoyé à l'expéditeur.

Pour plus de détails concernant les protocoles décrits ci-dessus, consultez les RFCs 821/822 en ce qui concerne la messagerie, le RFC 959 pour le transfert de fichiers, ainsi que les RFCs 854/855 pour les connexions interactives à distance. Pour les numéros de ports réservés voir l'édition de SPMlt;<Assigned NumbersSPMgt;> et le RFC 814.