8.1Le client TCP générique
Beaucoup de services créés à l'origine de l'Internet fonctionnent selon le modèle du serveur d'écho étudié précédemment : les échanges client-serveur se font pas échanges de lignes de texte. Nous allons écrire un client tcp générique qui sera lancé de la façon suivante : java cltTCPgenerique serveur port
Ce client TCP se connectera sur le port port du serveur serveur. Ceci fait, il créera deux threads : 1. un thread chargé de lire des commandes tapées au clavier et de les envoyer au serveur 2. un thread chargé de lire les réponses du serveur et de les afficher à l'écran
Pourquoi deux threads? Chaque service TCP-IP a son protocole particulier et on trouve parfois les situations suivantes : le client doit envoyer plusieurs lignes de texte avant d'avoir une réponse
Aussi la boucle envoi d'une unique ligne au serveur - réception d'une unique ligne envoyée par le serveur ne convient-elle pas toujours. On va donc créer deux boucles dissociées :
une boucle de lecture des commandes tapées au clavier pour être envoyées au serveur. L'utilisateur signalera la fin des commandes avec le mot clé fin.
une boucle de réception et d'affichage des réponses du serveur. Celle-ci sera une boucle infinie qui ne sera interrompue que par la fermeture du flux réseau par le serveur ou par l'utilisateur au clavier qui tapera la commande fin.
Pour avoir ces deux boucles dissociées, il nous faut deux threads indépendants. Montrons un exemple d'excécution où notre client tcp générique se connecte à un service SMTP (SendMail Transfer Protocol). Ce service est responsable de l'acheminement du courrier électronique à leurs destinataires. Il fonctionne sur le port 25 et a un protocole de dialogue de type échanges de lignes de texte.
Dos>java clientTCPgenerique istia.univ-angers.fr 25 Commandes :
<-- 220 istia.univ-angers.fr ESMTP Sendmail 8.11.6/8.9.3; Mon, 13 May 2002 08:37:26 +0200 help
<-- 502 5.3.0 Sendmail 8.11.6 -- HELP not implemented mail from: machin@univ-angers.fr
<-- 250 2.1.0 machin@univ-angers.fr... Sender ok rcpt to: serge.tahe@istia.univ-angers.fr
<-- 250 2.1.5 serge.tahe@istia.univ-angers.fr... Recipient ok data
<-- 354 Enter mail, end with "." on a line by itself Subject: test
ligne1 ligne2 ligne3 .
<-- 250 2.0.0 g4D6bks25951 Message accepted for delivery quit
<-- 221 2.0.0 istia.univ-angers.fr closing connection [fin du thread de lecture des réponses du serveur] fin
[fin du thread d'envoi des commandes au serveur]
Commentons ces échanges client-serveur :
le service SMTP envoie un message de bienvenue lorsqu'un client se connecte à lui :
<-- 220 istia.univ-angers.fr ESMTP Sendmail 8.11.6/8.9.3; Mon, 13 May 2002 08:37:26 +0200
certains services ont une commande help donnant des indications sur les commandes utilisables avec le service. Ici ce n'est pas le cas. Les commandes SMTP utilisées dans l'exemple sont les suivantes :
o mail from: expéditeur, pour indiquer l'adresse électronique de l'expéditeur du message
o rcpt to: destinataire, pour indiquer l'adresse électronique du destinataire du message. S'il y a plusieurs destinataires, on ré-émet autant de fois que nécessaire la commande rcpt to: pour chacun des destinataires.
o data qui signale au serveur SMTP qu'on va envoyer le message. Comme indiqué dans la réponse du serveur, celui-ci est une suite de lignes terminée par une ligne contenant le seul caractère point. Un message peut avoir des entêtes séparés du corps du message par une ligne vide. Dans notre exemple, nous avons mis un sujet avec le mot clé Subject:
une fois le message envoyé, on peut indiquer au serveur qu'on a terminé avec la commande quit. Le serveur ferme alors la connexion réseau. Le thread de lecture peut détecter cet événement et s'arrêter.
l'utilisateur tape alors fin au clavier pour arrêter également le thread de lecture des commandes tapées au clavier. Si on vérifie le courrier reçu, nous avons la chose suivante (Outlook) :
On remarquera que le service SMTP ne peut détecter si un expéditeur est valide ou non. Aussi ne peut-on jamais faire confiance au champ from d'un message. Ici l'expéditeur machin@univ-angers.fr n'existait pas.
Ce client tcp générique peut nous permettre de découvrir le protocole de dialogue de services internet et à partir de là construire des classes spécialisées pour des clients de ces services. Découvrons le protocole de dialogue du service POP (Post Office Protocol) qui permet de retrouver ses méls stockés sur un serveur. Il travaille sur le port 110.
Dos> java clientTCPgenerique istia.univ-angers.fr 110 Commandes :
<-- +OK Qpopper (version 4.0.3) at istia.univ-angers.fr starting. help
<-- -ERR Unknown command: "help". user st
<-- +OK Password required for st. pass monpassword
<-- +OK st has 157 visible messages (0 hidden) in 11755927 octets. list
<-- +OK 157 visible messages (11755927 octets) <-- 1 892847 <-- 2 171661 ... <-- 156 2843 <-- 157 2796 <-- . retr 157 <-- +OK 2796 octets
<-- Received: from lagaffe.univ-angers.fr (lagaffe.univ-angers.fr [193.49.144.1]) <-- by istia.univ-angers.fr (8.11.6/8.9.3) with ESMTP id g4D6wZs26600; <-- Mon, 13 May 2002 08:58:35 +0200
<-- Received: from jaume ([193.49.146.242])
<-- by lagaffe.univ-angers.fr (8.11.1/8.11.2/GeO20000215) with SMTP id g4D6wSd37691; <-- Mon, 13 May 2002 08:58:28 +0200 (CEST)
...
<-- --- <-- NOC-RENATER2 Tl. : 0800 77 47 95
<-- Fax : (+33) 01 40 78 64 00 , Email : noc-r2@cssi.renater.fr
<-- --- <--
<-- . quit
<-- +OK Pop server at istia.univ-angers.fr signing off. [fin du thread de lecture des réponses du serveur] fin
[fin du thread d'envoi des commandes au serveur]
Les principales commandes sont les suivantes :
user login, où on donne son login sur la machine qui détient nos méls pass password, où on donne le mot de passe associé au login précédent list, pour avoir la liste des messages sous la forme numéro, taille en octets retr i, pour lire le message n° i
quit, pour arrêter le dialogue.
Découvrons maintenant le protocole de dialogue entre un client et un serveur Web qui lui travaille habituellement sur le port 80 :
Dos> java clientTCPgenerique istia.univ-angers.fr 80 Commandes :