pack(), nous allons pouvoir nous concentrer sur
l'établissement de la sockette. Tout d'abord le client initialise son
côté de la sockette dans une structure de file handle Perl,
MYSOCK. Le second argument de la fonction
socket() spécifie le type de connexion réseau, c'est à
dire la façon dont la sockette va être utilisée et le protocole de
transmission. PF_INET est une autre constante provenant
du module Socket.pm. Elle est liée à AF_INET
et indique que cette sockette sera du type IP ( en fait, au début
d'IP, AF-INET était utilisé à la fois dans la structure C et dans la
fonction socket(), cette pratique est
déconseillée). SOCK_STREAM est une 3ème constante qui
indique que la communication se déroulera sur le mode d'une
communication téléphonique. Chaque correspondant peut parler en même
temps que l'autre et la communication cesse quand l'un des deux
raccroche. (SOCK_STREAM est la méthode de communication
la plus commune, mais il existe d'autres méthode comme
SOCK_DGRAM qui ressemble plus à une communication par
signaux, le client et le serveur s'échangent des messages mais il n'y
a pas de garantie qu'ils les reçoivent).
Au bout du compte la communication est établie. Ce n'est pas le
propos de cet article que de discuter des vertus comparées de TCP et
d'UDP. Sachez simplement que TCP est toujours la bonne solution à
moins que vous n'ayez de bonnes raisons de choisir UDP. Prenez
toujours la peine d'utiliser la fonction
getprotobyname(). Les programmeurs paresseux codent cette
valeur en dur parce qu'elle est constante sur la majorité des
UNIX. Les gens comme moi les maudissent quand ils ont à porter leur
code sur des UNIX exotiques ou sur d'autres systèmes.
En tenant fermement un des côtés de la sockette (sous la forme du
file handle MYSOCK), le client invoque
connect() pour contacter le serveur. La fonction
connect() prend comme argument le file handle et la
structure C que nous venons d'examiner. En supposant que l'appel à
connect() réussisse, le client a établi sa connexion avec
le serveur.
Utilisons la
MYSOCK peut maintenant être manipulée comme n'importe
quel file handle de Perl avec en plus la possibilité de pouvoir
écrire et lire dans la même sockette. Dans ce context d'entrées
sorties réseau, il est particulièrement important que vous terminiez
vos accès par un close() pour économiser les
ressources réseau et système.
Comme ce client s'est connecté au serveur Web
www.netmarket.com, souvenez vous du port 80, le programme
client peut causer avec le serveur en utilisant le protocole HTTP :
select(MYSOCK);
$| = 1;
select(STDOUT);
print MYSOCK "GET /\n\n";
while (<MYSOCK>) {
print;
}
close(MYSOCK);
Les 3 premières lignes arrêtent la bufferisation standard des entrées
sorties. Habituellement, il est intéressant de lire et d'écrire dans
un fichier par gros paquets (en lisant plus de données que nécessaire
ou en regroupant en une seule de nombreuses petites lectures) et la
plus part des systèmes UNIX pratiquent cette optimisation par
défaut. Cependant cette option peut être désactivée, par exemple dans
le cas d'un dialogue client serveur ou les deux parties échangent des
petits messages. Le mécanisme de bufferisation et règlé en Perl par
la variable $|. Il suffit de la passer à une valeur non
nulle (zéro est sa valeur par défaut). L'affectation de cette variable
influe sur le file handle du dernier select()
effectué (STDOUT est utilisé par défaut). Il faut donc
d'abord sélectionner MYSOCK, affecter $|,
puis selectionner à nouveau STDOUT.
Ceci étant fait, le client demande un fichier au serveur Web en
utilisant la command GET du protocole http. L'argument de
la commande GET est le nom du fichier réclamé. Dans ce
cas le client demande simplement le fichier racine de l'arbre des
documents, mais il aurait tout aussi bien pu demander :
/some/other/file.html.
La requête GET est suivie par 2 lignes vides.
Une fois que le client a passé sa requête, le serveur envoie le
contenu du fichier dans la sockette ( ou un message d'erreur si le
fichier n'est pas trouvé ou si une autre erreur s'est produite). Le
standard HTTP stipule que le serveur coupe la communication après
qu'il a envoyé le contenu du fichier. Le client à l'autre bout de la
sockette, interprète cette rupture de communication comme une lecture
ayant atteint la fin du fichier. Dans le programme précédant, le
contenu du fichier est simplement affiché sur le standard output.
Pratiquons la
L'exemple que nous venons de voir couvre les bases de l'écriture d'un
programme client. Il y a bien d'autres choses à savoir sur ce sujet,
mais il y a également beaucoup de personnes fort bien payées qui
n'en savent pas d'avantage. Dans mon prochain article j'aborderai
l'écriture d'un serveur et nous verrons un serveur Web simplifié.
En attendant, pratiquez ces concepts en prenant exemple sur ce
programe pour écrire une application qui prend sur la ligne de
commandes le nom du serveur, le numéro du port, le nom du fichier et
qui récupère ce fichier depuis le serveur Web distant. Impressionnez
vos amis, et améliorez votre productivité, en écrivant un robot qui
surfera sur le Web à la recherche de tag HTML dans les documents que
vous téléchargerez puis qui récupèrera également ces documents
pointés. Prenez bien garde d'arrêter la recherche à un moment, faute
de quoi vous finirez par télécharger tout le Web.
Traduit de ;login: Vol. 21 No. 4, August 1996.
Dernière édition: 23 décembre 1997 phb
Original 11/22/96pc
Back to the original
Retour à l'index