Télécharger

Question 2 : Courrier électronique et principes de base de la programmation socket (TCP et UDP).
Courrier électronique : Vue générale : Il y a trois grands composants dans le système des e­mail sur internet : SMTP (Simple Mail Transfer Protocol), les serveurs mail et les agents d'utilisateur.
Un agent d'utilisateur permet aux utilisateurs de lire, répondre, transmettre, sauver et composer des messages (Eudora, Outlook, Netscape Messenger, etc...).
SMTP transfère des messages d'un serveur mail à un autre. SMTP est plus vieux que le HTTP, il contient donc certaines caractéristiques archaiques. Par exemple, il contraint le corps de tous les e­mail à être en 7­bit ASCII. Avant cette restriction ne posait pas de problèmes mais maintenant dans l'ère des multimédia ce n'est plus le cas. Il requiert que les données multimédia en binaires soient encodées en ASCII avant d'être envoyées par SMTP et il requiert que les messages correspondants soient décodés en binaire après le transport SMTP. SMTP utilises le service de transfert de données fiable TCP pour transférer les e­mail. Il a deux côtés : un côté client qui est utilisé sur le serveur mail qui envoie et un côté serveur qui est utilisé sur le serveur mail qui reçoit. Les deux fonctionnent sur chaque serveur mail.
Pour illustrer l'opération basique du SMPT voici un exemple : Alice veut envoyer un message en ASCII à Bob.
1. Alice appelle son agent d'utilisateur, fournit l'adresse e­mail de Bob, compose un message et dis à l'agent d'utilisateur d'envoyer le message.
2. L'agent d'utilisateur d'Alice envoie le message à son serveur mail où il est placé dans la queue de messages (queue = cadre contenant 8 fichier dans le cadre Mail server du schéma).
3. Le côté client de SMTP, fonctionnant sur le serveur mail d'Alice, voit le message dans la queue de messages. Il ouvre une connection TCP sur le port 25 vers le serveur mail de Bob.
4. Après quelques handshaking , le client SMTP envoie le message d'Alice à travers la connection TCP.
5. Sur le serveur mail de Bob, le côté serveur SMTP reçoit le message. Le serveur mail de Bob place le message dans la boite à messages de Bob.
6. Bob va lire ses messages quand il le désire.
Il y a trois phases pour le transfert : ● handshaking
● transfert du / des message(s) (une seule connection pour plusieurs messages)
● fermeture
Il est important d'observer que le SMTP n'utilise pas de serveurs mail intermédiaire pour envoyer les mail, même lorsque les deux serveurs mail se trouvent à l'autre bout du monde. Si le serveur mail du côté serveur est down, le message reste dans le serveur mail de celui qui envoie et attend pour une nouvelle tentative. Voici ce qui se passe entre le client C et le serveur S. Le nom d'hôte du client est crepes.fr et celui du serveur est hamburger.edu.
S : 220 hamburger.edu
C : HELO crepes.fr
S : 250 Hello crepes.fr, pleased to meet you
C : MAIL FROM : <[email protected]>
S : 250 [email protected] ... Sender ok
C : RCPT TO : <[email protected]>
S : 250 [email protected] ... Recipient ok
C : DATA
S : 354 Enter mail, end with ''.'' on a line by itself
C : Do you like ketchup ?
C : How about pickles .
C : .
S : 250 Message accepted for delivery
C : QUIT
S : 221 hamburger.edu closing connection
Cet exemple envoie un message (''Do you like ketchup ? How about pickles ?'') du serveur mail crepes.fr au serveur mail hamburger.edu. Le client possède 5 commandes : HELO (abréviation de HELLO), MAIL FROM, RCPT TO, DATA et QUIT. Le serveur répond à chaque commande par un code et quelques explications en anglais. SMTP utilise une connection persistante, càd que l'on peut envoyer plusieurs mail à la même personne à travers la même connection TCP.
Comparaison entre SMTP et HTTP : Ces deux protocoles sont utilisés pour transférer des fichiers d'un hôte à un autre. HTTP transfère des fichiers d'un serveur Web à un agent d'utilisateur Web (browser); SMTP transfère des fichiers d'un serveur mail à un autre. Ils utilisent tous les deux des connections persistantes. Voici les principales différences : HTTP est un pull protocol càd que quelqu'un charge des informations sur un serveur Web et les utilisateurs utilisent HTTP pour prendre les informations du serveur à leur convenance. En particulier, la connection TCP est initialisée par la machine qui veut recevoir le fichier. Tandis que le SMTP est un push protocol càd le serveur envoyant le mail pousse le fichier dans le serveur recevant le mail. La connection TCP est ici initialisée par la machine qui veut envoyer le fichier.
SMTP requiert que tous les messages soient dans un formt 7­bit ASCII. Il requiert aussi que le corps de chaque message finisse avec ''CRLF.CRLF'' (où CR et LF correspondent à carriage return et line feed) pour que le serveur puisse délimiter chaque message reçut, lorsqu'une série de messages est envoyée par une connection TCP persistante. Si jamais le corps d'un des messages est en binaire, il est possible que cette donnée binaire contienne l'échantillon de bits correspondant à la représentation ASCII de ''CRLF.CRLF''. Le serveur SMTP concluera donc de façon erronée que le message se termine. Pour empêcher ce genre de problèmes, les données binaires sont d'abord encodées en ASCII de façon à ce que certains caractères ('.') ne soient pas utilisés. Notons que ni HTTP persistant ni HTTP non persistant ne doivent s'ennuyer avec la conversion en ASCII. Pour HTTP persistant, chaque message comporte une ligne Content­length permettant de délimiter la fin de chaque message.
HTTP encapsule chaque objet en un message de réponse. SMTP place tous les objets message en un message.
Les formats des messages : RFC 822 spécifie le format exact des en­têtes des e­mail. Comme avec HTTP, chaque ligne d'en­tête contient du texte lisible, consistant en un mot clé suivit du caractère ':' suivit de la valeur. Certains des mots clé sont optionnels, d'autres sont obligatoires. Ces lignes d'en­têtes sont différentes des commandes SMTP montrées plus haut. Les commandes précedantes font partie du handshaking de SMTP tandis que les lignes font parties du message lui même. Après les en­têtes, une ligne blanche suit et après le corps du message (en ASCII).
From: [email protected]
To: [email protected]
Subject: Searching for the meaning of life.
Les messages d'en­têtes décris dans RFC 822 sont satisfaisant pour envoyer du texte ASCII ordinaire mais ils ne sont pas assez riches pour les messages multimedias (messages avec images, musiques ou vidéos) ou pour les textes n'étant pas en ASCII. Pour cela, l'agent d'utilisateur qui envoie doit inclure des en­têtes supplémentaires. Ils sont définis dans RFC 2045 et RFC 2046 (extension MIME de RFC 822 où MIME signifie multimedia mail extension). Deux en­
têtes de MIME sont nécessaires pour contrer ces inconvénients. L'en tête Content­Type: permet à l'agent d'utilisateur qui reçoit le message d'effecteur une action appropriée. Par exemple, en indicant que le corps du message contient une image JPEG, l'agent d'utilisateur qui reçoit peut dirigé le corps du message vers une routine de décompression JPEG. L'en tête Content­Transfer­Encoding: prévient l'agent d'utilisateur qui reçoit que le corps du message a été encodé en ASCII et le type d'encodage utilisé. Donc, lorsqu'un agent d'utilisateur reçoit un message avec ces deux en­têtes, il utilise en premier la valeur de Content­Transfer­Encoding pour convertir le corps du message en son encodage de base et après il utilise la valeur de l'en­tête Content­Type: pour déterminer l'opération à exécuter sur le corps du message.
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME­Version: 1.0
Content­Transfer­Encoding: base64
Content­Type: image/jpeg
base64 encoded data ......
.........................
..... base64 encoded data
base64 encoded est une des nombreuses techniques d'encodages standardisée dans RFC 2045 pour la conversion vers le format 7­bit ASCII.
Protocoles d'accès aux mails : Après que le serveur mail de Bob ai reçu le message venant du serveur mail d'Alice, le message est placé dans la boite à messages. A travers cette discussion, nous supposons que Bob lit ses mails en se connectant à un serveur hôte et après exécute un lecteur de mail sur cet hôte. Jusqu'au début des années 90, c'était la manière standard de faire les choses. Mais aujourd'hui, un utilisateur lit ses mails avec un agent d'utilisateur qui est excéuté sur son propre PC. En exécutant l'agent d'utilisateur sur son PC, les utilisateurs bénéficient d'un riche ensemble de propriétés (voir les messages multimedia, les fichiers joints).
Mais il y a un problème avec cette approche car un serveur mail gère la boite à messages et lance les côtés client et serveur de SMTP. Si le serveur mail se trouvait sur le PC local de Bob, celui­ci devrait rester constamment connecté à Internet pour recevoir les nouveaux mails qui peuvent arriver n'importe quand. En fait, maintenant, un utilisateur utilise sur son propre PC un agent d'utilisateur mais accède à la boite à messages à partir d'un serveur mail partagé (serveur mail qui fonctionne toujours, qui est toujours connecté à Internet et qui est partagé avec les autres utilisateurs).
Un protocole est nécessaire pour autoriser la communication entre l'agent d'utilisateur et le serveur mail. Pour qu'Alice envoye un message à Bob il suffirait que les agents d'utilisateurs de Alice et de Bob communiquent directement ensemble. Cette approche n'est pas utilisée car elle n'offre pas de recours en cas de serveur mail de réception down. A la place, l'agent d'utilisateur d'Alice initialise un dialogue SMTP avec son propre serveur mail et upload le message. Le serveur mail d'Alice établit alors une nouvelle session SMTP avec le serveur mail de Bob et transmet le message. Si le serveur mail de Bob est down, alors le serveur mail d'Alice conserve le message et réessaye plus tard. Pour que l'agent d'utilisateur de Bob récupère le message qui se trouve sur son serveur mail, on utilise un des deux protocoles d'accès POP3 ou IMAP. L'agent d'utilisateur de Bob ne peut utiliser SMTP pour récupérer le message car obtenir le message est une opération pull tandis que SMTP est un protocole push.
POP3
POP3 commence quand l'agent d'utilisateur (client) ouvre une connection TCP vers le serveur mail (serveur) sur le port 110. Avec la connection TCP établie, POP3 progrèsse à travers 3 étapes : autorisation, transaction et mise àjour. Durant la première phase, l'agent utilisateur envoie un nom d'utilisateur et un mot de passe pour authentifier l'utilisateur téléchargeant le mail. Durant la deuxième phase, l'agent d'utilisateur récupère les messages et peut également marqué des messages devant être supprimé, supprimé des marques ou encore obtenir des statistiques. La dernière phase arrive après que le client ai quitté la session POP3 grâce à la commande quit, le serveur mail supprime les messages devant être supprimé. Les commandes du client sont user et pass. Le serveur répond par +OK et ­ERR.
telnet mailServer 110
+OK POP3 server ready
user alice
+OK
pass hungry
+OK user successfully logged on
Dans la phase de transaction, un agent d'utilisateur utilisant POP3 peut souvent être configuré en ''download and delete'' ou en ''download and keep''. La séquence de commandes issues d'un agent d'utilisateur utilisant POP3 dépend du mode de l'agent. Ces commandes sont list, retr et dele. Voici un exemple, supposons que deux mails se trouvent dans la boite : C: list
S: 1 498
S: 2 912
S: .
C: retr 1
S: <contenu du message 1>
S: .
C: dele 1
C: retr 2
S: <contenu du message 2>
C: dele 2
C: quit
S: +OK POP3 server signing off
Dans le mode ''downlood and delete'', on ne pourra plus relire un mail après l'avoir récupéré car on l'aura supprimé du serveur mail. Après la commande quit, le serveur POP3 entre dans la phase de mise à jour et supprime les messages 1 et 2. Entre différentes sessions POP3, les états ne sont pas sauvegardés (messages marqués par exemple).
IMAP
POP3 n'est pas adapté aux utilisateurs nomades qui préfèrent maintenir une hierarchie de dossier sur un serveur isolé qui peut être accédé par n'importe quel ordinateur. Ce n'est pas possible avec POP3. Pour solutionner cela et d'autres problèmes, IMAP (Internet Mail Acces Protocol) a été inventé (RFC 1730). Il a beaucoup plus de propriétés que POP3 mais il est aussi plus complexe. IMPA est implémenté pour permettre aux utilisateurs de manipuler des boites à messages isolées comme si elles étaient en local. IMAP conserve l'état des boites à messages de tous les utilisateurs à travers les différentes sessions, c'est d'ailleurs une des raisons pour lesquelles IMAP est plus compliqué. Une autre propriété de IMAP est qu'il contient des commandes pour récupérer seulement certaines parties du message, cela est utile lorsqu'il y a une faible bande passante
HTTP
Avec les sites comme Hotmail ou Gmail les utilisateurs peuvent communiquer par HTTP plutot que par POP3 ou IMAP avec la boite à messages se trouvant sur le serveur mail. Pour lire ses messages, ceux­ci sont envoyés de serveur mail au browser. Les messages sont envoyé par HTTP à partir du browser vers le serveur mail. Cette solution est très pratique quoique des fois un peut lente vu l'éloignement du serveur.
Programmation socket : Le coeur d'une application réseau consiste en une paire de programmes, un programme client et un programme serveur. Quand ces deux programmes sont exécutés, un processus client et un processus serveur sont créés et ces deux processus communiquent entre eux en lisant et en écrivant sur le socket. Il y a deux sortes d'applications client­serveur. Une sorte est une application qui est une implémentation d'un protocole standard défini dans RFC. Les programmes client et serveur doivent être conformes aux règles données par RFC. Quand un client ou un serveur implémente un protocole défini, il doit utiliser le numéro de port associé au protocole. L'autre sorte est une application client­serveur propriétaire, càd que les programmes de client et de serveur ne doivent pas nécessairement être conformes à un protocole existant dans RFC. Le problème est que les autres développeurs ne savent pas développer du code qui puisse interagir avec. Les developpeurs doivent faire attention de ne pas utiliser un numéro de port déjà utilisé par un protocole.
Avant de développer une application client­serveur propriétaire, il faut d'abord choisir entre TCP et UDP. TCP est connection­oriented, fourni une transmission fiable des données, flow control et congestion control. UDP est conectionless et envoie des paquets indépendants de données sans aucune garantie sur la réception.
TCP : Un processus est analogue à une maison et le socket du processus en est la porte.
Le client a le rôle d'initialiser le contact avec le serveur. Le serveur doit être prêt pour pouvoir réagir au contact initial du client. Cela implique deux choses. Premièrement, le programme du serveur ne doit pas être endormi, il doit fonctionner. Deuxièmement, le programme du serveur doit avoir une sorte de porte (socket) qui accueille le contact initial d'un client. Lorsque le processus du serveur tourne, le processus du client peut initialiser une connection TCP vers celui­ci. Cela est fait dans le programme client en créant un objet socket. Lorsque le client crée cet objet socket, il spécifie l'adresse IP et le numéro de port du serveur. Après la création de l'objet socket, un hanshake à trois voie est initialisée (transparent pour les programmes client et serveur) et la connection avec le serveur est établie.
Ici, le fait de frapper à la porte correspond au contact initial effectué par le client. Durant le handshake à trois voie, le processus client frappe à la porte de bienvenue du processus serveur (welcoming socket). Lorsque le serveur entend frapper, il crée une nouvelle porte (nouveau socket) qui est dédiée à ce client particulier. A la fin de cette phase, une connection TCP existe entre le socket client et le nouveau socket du serveur (connection socket). Le processus client peut envoyer des bytes à travers son socket et également en recevoir. Le processus serveur peut faire de même. La connection TCP est un tuyau virtuel direct entre le socket du client et celui du serveur.
Un flux est une séquence de caractères qui coule dans ou hors un processus. Chaque flux est soit un flux d'entrée soit un flux de sortie pour le processus. Si le flux est un flux d'entrée, alors il est attaché à une source d'entrée comme une entrée normale (clavier) ou un socket d'ou coule des caractères venant d'Internet. Si le flux est un flux de sortie, alors il est attaché à une source de sortie comme une sortie normale (écran) ou un socket dans lequel on envoie des caractères vers Internet.
UDP : UDP permet aussi à deux (ou plus) processus fonctionnant sur différentes machines de communiquer. Mais avec UDP, il n'y a pas de phase handshaking car UDP ne possède pas un tuyau comme TCP. Lorsqu'un processus veut envoyer un groupe de bytes à un autre processus, le processus qui envoie doit attacher au groupe de bytes l'adresse du processus destination et cela doit être fait pour chaque groupe de bytes que le processus envoie. Un paquet contient un groupe de bytes, l'adresse IP de destination et le numéro de port.
Après avoir crée un paquet, le processus qui envoie pousse le paquet dans le réseau à travers un socket sans garantie que le paquet arrive à destination.
Voire le bouquin ou le cours pour avoir des exemples de programmes client­serveur utilisant TCP ouUDP.