Prague pour 900 F.

Usage de TCP/IP en APL2

Par Bernard Mailhol

Présentation

2 Ce qu'est TCP/IP

2.1 TCP/IP est un ensemble de protocoles

2.2 Propriétés

3 Utiliser TCP/IP depuis APL/2

3.1 Usage direct et indirect

3.2 Le processeur auxiliaire

3.3 Programmer en Sockets

3.4 Ouvrir une session d'un serveur

3.5 Ouvrir une session d'un client

3.6 Envoyer un message

3.7 Recevoir un message

4 Utiliser TCP/IP dans des applications

4.1 Protocoles personnels

4.2 Protocoles standard

4.3 Installer un serveur Web en APL2

5 Un serveur Web sommaire

5.1 Sa programmation

5.1.1 START Lancement général

5.1.2 REQUEST Attendre et traiter une requête

5.1.3 SCRIPT Traiter (par un script) le message reçu

5.1.4 MIME Préparer le header Mime de la réponse

5.2 Son usage

6 Un client Web sommaire.

6.1 La programmation

6.1.1 CALL_URL Appeler l'URL, globalement

6.1.2 ANZ_URL Eclater l'URL en ses composants simples

6.1.3 GET_URL Lire un URL, après connexion

6.1.4 LINKS Extraire les liens d'un URL lu précédemment.

6.2 Exemple d'usage

7 Sources documentaires

1 Présentation

TCP/IP est un outil très répandu, ensemble de protocoles permettant des transmissions entre machines diverses. Ce texte introduit ces protocoles, puis en donne un exemple d'usage, en APL2.

L'application de TCP/IP la plus connue, aujourd'hui, est le Web. Nous allons ainsi décrire comment écrire un serveur Web spécifique, en APL2, comment répondre à un serveur externe.

Ce texte se réfère à des présentations effectuées à Moscou, en Novembre 1996, et à Paris, en Décembre 1996. Ces présentations ont été préparées en "Web", et peuvent être visualisées par votre fureteur Web.

Elles sont bientôt à votre disposition, accompagnées de la programmation en APL, sur le serveur Web de l'AF/APL.

Cet article a été publié dans le numéro 22 des Nouvelles, mais des incidents combinés ont fait que les programmes APL2 n'ont pas utilisé les polices nécessaires. C'est pourquoi nous rééditions cet article, complété à l'occasion par l'usage de TCP/IP en mode client.

B. Mailhol, 100317.3113@Compuserve.com

2 Ce qu'est TCP/IP

TCP/IP est un mot mythique, lié à Internet, laissant planner le plus grand mystère quant à son domaine, son universalité.

TCP/IP est en fait un ensemble de protocoles de transmission, utilisés sur le réseau Internet, répondant à des besoins particuliers de transmissions universelles, mais simplifiées.

Ce protocole est certes le protocole utilisé sur Internet, mais c'est aussi un protocole utilisable sur un réseau indépendant d'Internet. Dans le cas d'usage de TCP/IP dans un réseau d'entreprise, ce réseau peut s'appeler un Intranet.

2.1 TCP/IP est un ensemble de protocoles

TCP/IP est composé de protocoles, élaborés depuis plus de 20 ans, ayant tout d'abord permis - dans le monde Unix - des transmissions entre universités, par ce réseau universitaire appelé Internet.

Récemment, ce réseau s'est ouvert à des "fournisseurs" (providers), ayant la possibilité d'accueillir des abonnés non universitaires. Cette ouverture permet à chacun d'entre nous de nous connecter, mais déstabilise son usage initial : le partage d'informations non commerciales.

L'ensemble de ce réseau fonctionne en TCP/IP.

On voit ainsi que TCP/IP :

1 - Sait utiliser de nombreux supports de transmission

2 - Est reconnu sur de nombreuses machines (sinon toutes les machines).

... il apparaît comme étant universel.

1 - TCP/IP sait utiliser de nombreux supports de transmission

Les protocoles TCP/IP peuvent utiliser de nombreux supports de transmission. Parmi eux, on peut citer :

*Les réseaux locaux (Ethernet, Token-Ring, FDDI ...)

*Les réseaux téléphoniques "permanents" (X25)

*Les réseaux téléphoniques "intermittents" (réseau commuté), selon les protocoles SLIP (Serial Line Internet Protocol) ou PPP (Point to Point Protocol).

Ces protocoles physiques sont reconnus et validés par un organisme indépendant, sur des propositions venant des utilisateurs, et implémenteurs. Ces protocoles sont ainsi le fait d'un consensus d'utilisateurs et de fournisseurs.

Une même machine peut disposer en même temps de liens de différentes natures : elle devient alors un routeur IP, et permet de relier plusieurs réseaux. Toute installlation IP a la capacité potentielle d'agir en routeur.

2 - TCP/IP est reconnu sur de nombreuses machines (sinon toutes les machines).

En 1997, toutes les machines proposent la connexion d'au moins un support de transmission (des réseaux à grands débits pour les sites centraux, jusqu'à la prise modem pour les machines familiales).

Pratiquement tous les systèmes d'exploitation contiennent des protocoles TCP/IP. (Si ces systèmes n'en disposent pas, des fournisseurs indépendants les fournissent).

En résumé, toutes les machines peuvent utiliser TCP/IP sur tous types de support. Encore faut-il que les flux échangés soient aussi normalisés !

2.2 Propriétés

TCP/IP est un ensemble de protocoles destinés à permettre une communication entre Universités. On comprend alors que sa définition ne soit pas le fait d'un seul organisme, mais issue d'un consensus.

L'idée directrice, lors de la création de TCP/IP - et d'Internet - a été la diffusion rapide des thèses et autres publications universitaires, dans la course à l'antériorité que chaque chercheur doit normalement poursuivre. De même, ce réseau devait faciliter la transmission de messages - écrits en anglais.

Les propriétés de TCP/IP sont ainsi déduites de ces buts, et de ce public :

1 - Installation facile, mais chacun doit configurer

2 - Indépendance de chacun,

3 - Pas de supervision centralisée du réseau

4 - Routages universels, sans discrimination selon les extrémités

5 - Très peu de confidentialité

6 - égalité de tous devant les transmissions (pas de priorité, pas de notion de qualité de service garantie)

7 - Pas de facturation !

3 Utiliser TCP/IP depuis APL/2

APL2 permet depuis longtemps, via le processeur auxiliaire AP119, l'usage de TCP/IP en mode natif, ou en mode caché.

3.1 Usage direct et indirect

APL2 permet la mise en oeuvre de TCP/IP selon deux méthodes complémentaires:

1 - La première méthode consiste à partager des variables entre deux machines différentes, selon les mêmes méthodes que celles permettant le partage de variables entre deux APL situés sur la même machine.

La différence est que les temps de transmission ne sont plus négligeables. Les applications doivent prendre un minimum de précautions (par exemple, positionner les valeur du SVC et assurer un verrouillage mutuel).

On peut ainsi monter une application client/serveur entre plusieurs machines en APL, en ne se servant que des variables partagées. C'est très sommaire mais souvent suffisant (Je me sers parfois de cette technique).

On peut aussi travailler sur une machine, mais utiliser des processeurs auxiliaires situés sur une autre machine. D'une machine, on peut travailler sur des fichiers d'une autre machine, ou sur le lecteur de disquette d'un PC, tout en étant situé sur une machine ne disposant pas de lecteur de disquette...

Le gestionnaire de session n'étant qu'un processeur auxiliaires, rien n'empêche de piloter une session APL depuis une autre machine.

Les applications sont innombrables.

2 - La seconde méthode consiste à utiliser les primitives de transmission de TCP/IP.

Plusieurs méthodes sont utilisables. APL2, via son processeur AP119 propose l'accès aux sockets.

En utilisant alors cette interface de bas niveau, on peut dialoguer avec des programmes qui ne sont (peut-être) pas écrits en APL2.

On peut alors ouvrir les systèmes APL sur l'univers complet de l'informatique, à condition toutefois de connaître le flot de données à recevoir et à transmettre.

Dans la mesure où le monde de TCP/IP est régi par un consensus, des publications numérotées et accessibles (appelées Request For Comments RFC), on peut toujours connaître et utiliser ces applications - si elles respectent ces règles, évidemment.

3.2 Le processeur auxiliaire

La notion de processeur auxiliaire remonte au début des années 70. Un processeur auxiliaire est un programme

1 - Indépendant de l'APL.

Plusieurs processeurs sont fournis avec APL2, mais vous pouvez développer (ou faire développer) vos propres processeurs : leur documentation fait partie de la documentation standard, et contient des exemples, développés en C.

2 - Ce programme s'exécute indépendamment de la session APL, selon son propre temps, avec les périphériques de son choix, ou les interfaces de programmation de son choix.

3 - Il peut se synchroniser avec une session APL (ou un autre processeur auxiliaire), et échanger des messges via un mécanisme de boîte aux lettres.

4 - Il peut s'exécuter sur une autre machine que la machine de base, la gestion des transmissions étant effectuées par le gestionnaire de partage d'APL2.

De fait ce concept est un concept très contemporain.

Le processeur auxiliaire APL119 permet l'usage de TCP/IP en mode "socket"; il est disponible sur tous les environnments d'APL2

3.3 Programmer en Sockets

La programmation en sockets suit des règles générales, seulement transposées en APL2.

Plusieurs notions sont fondamentales :

1 - Chaque utilisateur est situé sur un host. Ce host est aussi bien un site central (disposant de dizaines ou milliers d'utilisateurs) qu'un PC, ne disposant que d'un seul utilisateur.

2 - Chaque host dispose d'une adresse appelée adresse ip. Cette adresse doit être unique sur le réseau. Si vous créez votre propre réseau, vous avez la liberté de son choix; si vous voulez participer à Internet, vous devez demander une adresse de réseau.

Une adresse ip prend la forme de quatre nombres - de 0 à 255 - séparés par un point. Par exemple : 216.94.110.76.

3 - Une adresse IP peut avoir des synonymes (par exemple www.bmailhol.fr). Ce synonyme est appelé nom de domaine.

4 - Chaque programme, situé sur un host, se connecte sur le TCP/IP de sa machine sous un numéro, appelé numéro de port.

Certains programmes disposent d'un numéro de port bien connu, et sont ainsi facilement utilisables.

5 - Chaque programme voulant dialoguer avec le TCP/IP de sa machine via un numéro de port doit créer une session via un socket.

Vous disposez maintenant du vocabulaire suffisant pour programmer TCP/IP en sockets.

3.4 Ouvrir une session d'un serveur

Un serveur se met à l'écoute des appels entrants. On distingue alors deux catégories de sockets:

1 - Les sockets passifs qui sont à l'écoute des appels entrants

2 - Les sockets actifs, dialoguant avec les clients.

1 - La première étape consiste à ouvrir une session. Pour commencer, créer un socket.

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'SOCKET'

('GET SOCKET' APRC TCPIPRC)err APRC

SOCKLIS½CMDRC

Le processeur (appelé via la fonction tcp) recoit l'ordre SOCKET pour lui demander la création d'un socket.

La fonction tcp permet un usage synchrone du processeur AP119, les variables étant partagées préalablement :

Z½tcp CDE

ä appeler le processeur TCP/IP

tcp¶1½CDE

Z½tcp¶1

a - L'objet APL à transmettre au processeur est un vecteur généralisé, dont le premier élément est le mot 'TCPIP le second la commande passée, les suivants les paramètres de cette commande.

b - Le retour est un vecteur de trois éléments :

1 - Le premier est le code retour propre du processeur

2 - Le second est le code retour de TCP/IP

3 - Le troisième est le résultat de la commande.

Dans ce cas, le retour est l'identification du socket qui vient qu'être créé.

2 - Associer ce socket à un numéro de port.

ä lier ce socket au port (sp‚cial) du Web

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'BIND' SOCKLIS 8080 '0.0.0.0'

('BIND SOCKET' APRC TCPIPRC)err APRC

Dans cet exemple, le socket est associé au port numéro 8080, sur l'adresse ip locale.

3 - Dans le cas d'un serveur, mettre ce socket à l'écoute des appels entrants.

ä rendre ce socket passif

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'LISTEN' SOCKLIS 5

('LISTEN' APRC TCPIPRC)err APRC

Il dispose d'une file d'attente de 5 appels entrants non encore acceptés.

4 - Il se met en attente du prochain appel entrant

ä attendre un appel entrant

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'ACCEPT' SOCKLIS

('ACCEPT' APRC TCPIPRC)err APRC

(SOCKBRW PORTBRW IPADDBRW)½CMDRC

'appel entrant de' SOCKBRW IPADDBRW

A cette occasion, TCP/IP crée un nouveau socket, dont nous connaissons le numéro. Le retour indique aussi l'adresse IP de l'interlocutaur nous ayant appelé, ainsi que son numéro de port.

A ce moment, il peut commencer les échanges de messages.

3.5 Ouvrir une session d'un client

Un client ouvre une session, et a l'initiative de la connexion.

1 - La première étape consiste à ouvrir une session. Pour commencer, créer un socket.

ä ouvrir un socket

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'SOCKET'

('GET SOCKET' APRC TCPIPRC)err APRC

SOCK½CMDRC ä socket ouvert

Le processeur (appelé via la fonction tcp) recoit l'ordre SOCKET pour lui demander la création d'un socket.

2 - La seconde étape est d'associer ce socket à un port et une adresse IP.

Dans ce cas présent, le port indiqué (0) fait que le système recherche un port disponible; l'adresse IP indiquée ('0.0.0.0') fait que le socket est lié à la première adresse associée à cette machine.

ä lier ce socket … un port quelconque

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'BIND' SOCK 0 '0.0.0.0'

('BIND' APRC TCPIPRC)err APRC

La troisième étape consiste à se connecter sur le serveur dont on connaît l'adresse complète.

ä se connecter sur le serveur dont on connait l'URL

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'CONNECT' SOCK PORT IP

('CONNECT' APRC TCPIPRC)err APRC

3.6 Envoyer un message

La programmation en sockets vous permet d'envoyer un vecteur alpha.

Le programme de l'interlocuteur n'est peut-être pas écrit en APL. Il n'est alors pas question de lui envoyer un objet APL, qu'il en comprendrait pas.

ä Envoi d'un message

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'SEND' SOCKBRW 0 'B'(,VCT)

('SEND MESSAGE' APRC TCPIPRC)err APRC

Cet appel demande la mise en file d'attente de la chaîne précisée en VCT. Un code retour correct signifie seulement que ... la mise en file d'attente a été correctement effectuée. Ceci ne signifie nullement que le message sera délivré.

Ce message est seulement considéré comme une suite d'octets, qu'il faut acheminer vers leur destinataire.

Plusieurs questions se posent alors :

1 - Puis-je envoyer d'autres messages ?

2 - Où est mon message ?

3 - Quand arrivera-t-il ?

4 - Est-il arrivé ?

Nous devons construire un protocole complémentaire applicatif , pour tenter de répondre à ces questions. Chaque application dispose alors de son protocole personnel.

3.7 Recevoir un message

L'ordre de réception permet de recevoir tout ou partie du contenu de la file d'attente.

La réception d'une chaîne vide marque la fin de la session.

ä recevoir ses donn‚es

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'RECV' SOCKBRW 0 'B'

('RECEIVE' APRC TCPIPRC)err APRC

BRW½CMDRC ä donn‚es initiales (un seul RECV dans cette d‚mo)

Le retour de la commande est un vecteur de caractère.

Les données reçues sont garanties :

1 - Sans erreur de transmission

2 - Les octets reçus sont dans le même ordre que les octets émis.

Mais les messages émis ne sont qu'une suite d'octets, mis en file d'attente, sans notion de séparation entre messages (de même que les fichiers sous Unix ne sont qu'une suite de caractères, que l'application doit structurer).

Plusieurs questions se posent alors :

1 - Ce retour est-il message est-il complet ?

2 - Est-il un message émis, suivi de tout ou partie d'un autre message ?

Le protocole applicatif que nous devons construire doit pouvoir aussi répondre à ces questions. On constate plusieurs types de reconstitution des messages initiaux.

Remarquons que cette transmission de flot et non de message fait qu'un message volumineux peut être envoyé en plusieurs tronçons. (par exemple, un fichier de 2 MB). Il peut être envoyé par segments de 1000 octets, et reçu par segments de 800 !

4 Utiliser TCP/IP dans des applications

On peut utiliser TCP/IP dans nos applications, soit en utilisant des protocoles personnels, soit en utilisant des protocoles standard dans la communauté TCP/IP. L'usage du protocole du Web est un exemple important de l'usage de protocoles standard.

4.1 Protocoles personnels

On peut utiliser des protocoles personnels internes à différents composants d'une application.

Par exemple, l'application ADAGIO de la Banque de France (présentée à l'AF/APL par Henri Sinturel), est articulée autour de deux composants :

1 - Un serveur situé sur site central, en VM/CMS, développé en APL2, assurant la gestion des fichiers, de l'historique, des reprises, les calculs...

2 - Les clients situés sur des postes de travail en OS/2, chargés de l'affichage des images et de l'édition graphique. Ils sont développés en C.

3 - La liaison entre Client et Serveur se fait en TCP/IP sur un réseau local Token-Ring à 16 Mbits.

On peut aussi imaginer des applications mettant en oeuvre des protocoles TCP/IP personnels sur le réseau Internet. Il n'y a aucune contrainte technique l'interdisant.

4.2 Protocoles standard

APL2 et son processeur AP119 permettent aussi d'utiliser des protocoles standard. Ces protocoles sont définis dans des documents publics, appelés Request For Comments - RFC. Chaque RFC est numéroté.

On peut ainsi piloter une imprimante, en connaissant le protocole LPR/LPD, échanger du courrier, transmettre et recevoir des fichiers par FTP. (en simulant la présence de fichiers en APL ...)

En particulier, aujourd'hui, vous pouvez découvrir et mettre en place le protocole HTTP(hypertext transfer protocol), suivi par les systèmes "Web".

Si vous disposez d'une application connaissant ou calculant des données importantes, vous pouvez les mettre à disposition de vos interlocuteurs, qu'ils disposent ou non d'un système APL, quelque soit la machine sur laquelle ils travaillent, via un Serveur Web écrit en APL.

Vos utilisateurs seront impressionnés.

4.3 Installer un serveur Web en APL2

L'installation d'un serveur Web en APL2 demande la connaissance :

1 - Des concepts du protocole HTTP (RFC 1945)

2 - Des concepts du langage html, dans lequel sont construites les pages du Web

3 - Des concepts du Header mime (eux-aussi dans un RFC), introduisant la réponse.

La section suivante donne un exemple concret de serveur écrit en APL2.

Ses fonctions permettent :

1 - De se connecter sur TCP/IP, de se mettre à l'écoute

2 - De recevoir un message complet. (dans ce cas, il est reçu en un seul bloc, vu sa taille)

3 - D'analyser ce message, d'extraire le nombre à multiplier par deux

4 - De construire un texte html pour présenter cette réponse

5 - De préfixer de texte par un header Mime

6 - D'envoyer la réponse

7 - De clore la session.

5 Un serveur Web sommaire

Ce serveur Web est très sommaire : Il permet de multiplier par deux (mais le vôtre le sera moins).

5.1 Sa programmation

Il est composé de quelques fonctions (développées en origine 0)

1 - START Lancer l'attente générale

2 - REQUEST Attendre et traiter une requête

3 - SCRIPT Traiter (par un script) le message reçu

4 - MIME Préparer le header Mime de la réponse

5.1.1 START Lancement général

Dans cette démonstration, cette fonction est appelée (manuellement) pour lancer le serveur. Le port standard bien connu d'un serveur Web est 80. Nous avons choisi ici le port 8080, ce qui permet d'installer ce serveur spécifique à côté d'un serveur standard, mais impose que son appel précise ce numéro de port, 8080.

START

ä commencer une session WEB

ä 1 - cr‚er un socket passif

ä 2 - attendre sur le port 8080

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'SOCKET'

('GET SOCKET' APRC TCPIPRC)err APRC

SOCKLIS½CMDRC

ä lier ce socket au port (sp‚cial) du Web

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'BIND' SOCKLIS 8080 '0.0.0.0'

('BIND SOCKET' APRC TCPIPRC)err APRC

ä rendre ce socket passif

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'LISTEN' SOCKLIS 5

('LISTEN' APRC TCPIPRC)err APRC

5.1.2 REQUEST Attendre et traiter une requête

Cette fonction est appelée pour attendre et traiter un seul message (démonstration oblige).

La variable BRW est le texte reçu du fureteur (browser en langue d'origine), la variable RSP est le vecteur alphanumérique à renvoyer en réponse.

REQUEST

ä attendre un appel entrant

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'ACCEPT' SOCKLIS

('ACCEPT' APRC TCPIPRC)err APRC

(SOCKBRW PORTBRW IPADDBRW)½CMDRC

'appel entrant de' SOCKBRW IPADDBRW

ä recevoir ses donn‚es

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'RECV' SOCKBRW 0 'B'

('RECEIVE' APRC TCPIPRC)err APRC

BRW½CMDRC ä donn‚es initiales (un seul RECV dans cette d‚mo)

ä les donn‚es sont la commande HTTP du fureteur (browser)

RSP½IPADDBRW SCRIPT BRW

ä il reste … envoyer la r‚ponse

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'SEND' SOCKBRW 0 'B'(,RSP)

('SEND RESPONSE' APRC TCPIPRC)err APRC

ä et terminer la session.

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'CLOSE' SOCKBRW

('CLOSE SOCKET' APRC TCPIPRC)err APRC

5.1.3 SCRIPT Traiter (par un script) le message reçu

Le message reçu du fureteur Web suit les procédures HTTP. La chaîne reçue comprend plusieurs lignes, séparées par un code de saut de ligne.

1 - Première ligne

a - Le mot GET

b - Les paramètres du get

c - Le nom et la version du protocole

2 - Lignes suivantes

Chaque ligne suivant donne un paramètre du fureteur.

3 - Fin du message

La fin du message est marquée par une ligne vide.

La réponse à faire au fureteur comprend deux parties :

1 - Un Header Mime expliquant le contenu de la seconde partie

2 - Une ligne vide pour marquer la fin du header mime.

3 - (dans ce cas) un texte en langage HTML, décrivant l'affichage souhaité.

Le header donne la taille du message en réponse, ce qui permet au fureteur d'en détecter la fin.

La trace de la session montre le message reçu, la réponse fournie.

RSP½IPADD SCRIPT BRW;K;W;N

ä la requˆte du fureteur est : GET nnn HTTP/1.0 ...

'Requˆte re‡ue' TS

BRW

W½(Kô' ')âK½eb1 30ÆBRW ä ignorer les autres ‚l‚ments

N½'0' EA 1Ç1ãW

ä construire la r‚ponse

K½â'<!- APL Demo B. Mailhol -->'

K½K,â'<HTML><HEAD><TITLE>WEB en APL2</TITLE></HEAD>'

K½K,â'<BODY><H1>Retour : le double de l''entr&eacute.e</H1>'

K½K,â'<hr><p>L''entr&eacute.e est...',(®N)

K½K,â'<p>La r&eacute.ponse est ainsi ... ',(®2õN),'<hr></BODY></HTML>'

ä ajouter le header MIME

RSP½MIMEîK,þâAF 13 10

'R‚ponse au fureteur'

RSP

5.1.4 MIME Préparer le header Mime de la réponse

HEAD½MIME RSP

ä construire la r‚ponse avec son header

K½'HTTP/1.0 200 Document follows.' 'Server: BMA APL Demo'

K½K,'Content-Type: text/html'('Content-Length: ',®æRSP)''

ä header puis la r‚ponse

HEAD½(îK,þâAF 13 10),RSP

5.2 Son usage

Ce serveur est appelé par un message de la forme http://apl.demo:8080/543. Cette demande appelle le serveur Web situé à l'adresse IP décrite en apl.demo, sous le numéro de port 8080. Le message envoyé comprend 543.

La réponse doit alors être 1086, le double de 543. Cette réponse est présentée, dans un texte html.

Appel entrant de 31 216.94.110.95

Requête reçue 1997 2 18 23 52 35 90

GET /543 HTTP/1.0

Accept: */*; q=0.300

Accept: application/octet-stream; q=0.100

Accept: text/plain

Accept: text/html

Accept: application/book

Accept: application/hlp

Accept: application/inf

Accept: text/plain

Accept: audio/x-wav

............e/tiff

Accept: image/jpeg

Accept: image/gif

Accept: application/editor

User-Agent: IBM-WebExplorer-DLL/v1.1f

Réponse au fureteur

HTTP/1.0 200 Document follows.

Server: BMA APL Demo

Content-Type: text/html

Content-Length: 224

<!- APL Demo B. Mailhol -->

<BODY><H1>Retour : le double de l'entr‚e</H1>

<hr><p>L'entr‚e est...543

<p>La r‚ponse est ainsi ... 1086<hr></BODY></HTML>

Il ne vous reste qu'à essayer ... avec un service un peu plus consistant que cette multiplication. Vous allez émerveiller vos utilisateurs.

6 Un client Web sommaire.

Ce client Web sommaire est lui aussi très simple : à partir d'un URL, ce client se connecte sur le site, utilise le protocole GET pour interroger le serveur, et extrait de la réponse l'ensemble des références qu'elle contient.

On peut imaginer que cette routine serve à charger localement l'ensemble des pages liées à un URL, pour pouvoir les lire localement, en-dehors de toute connexion.

Encore une fois, il suffit de très peu de fonctions APL pour parvenir à cette fonctionnalité intéressante.

Un exemple se sert de l'URL de Gérard Langlet.

6.1 La programmation

La programmation comprend

1 - CALL_URL Appeler l'URL, globalement

2 - ANZ_URL Eclater l'URL en ses composants simples

3 - GET_URL Lire un URL, après connexion

4 - LINKS Extraire les liens d'un URL lu précédemment.

En voici l'expression (développée en origine 0)

6.1.1 CALL_URL Appeler l'URL, globalement

Cette fonction se connecte sur l'URL donné en argument, en utilisant les primitives TCP/IP décrites ci-dessus.

La variable rz est un code retour général, dans lequel le premier élément est un code retour pur (vecteur vide, ou vecteur ,1 ), suivi de la réponse effective en cas de succès, ou d'un message d'erreur sinon.

Le retour normal contient le texte de la page Web interrogée.

rz½CALL_URL URL;PORT;IP;ARG;SOCK;APRC;TCPIIPRC;CMDRC

ä appeler un URL http, rendre son texte

¸0õÆ(pCC PORT IP ARG)½4Ærz½ANZ_URL URL

ä ouvrir un socket

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'SOCKET'

('GET SOCKET' APRC TCPIPRC)err APRC

SOCK½CMDRC ä socket ouvert

ä lier ce socket … un port quelconque

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'BIND' SOCK 0 '0.0.0.0'

('BIND' APRC TCPIPRC)err APRC

ä se connecter sur le serveur dont on connait l'URL

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'CONNECT' SOCK PORT IP

('CONNECT' APRC TCPIPRC)err APRC

ä envoyer la requˆte

¸0õÆrz½SOCK GET_URL ARG

ä la session est ferm‚e

6.1.2 ANZ_URL Eclater l'URL en ses composants simples

Cette fonction utilise la structure de l'URL, en protocole http

1 - Le nom du protocole http:

2 - Un double slash indiquant que l'URL n'est pas relatif à la page dans laquelle nous sommes

3 - Le nom du domaine

4 - (éventuellement) le numéro du port interrogé, s'il est différent de 80

5 - Les arguments, commençant sur le slash /.

Cette fonction contient un nouvel appel de TCP/IP : l'adresse IP du correspondant peut être donnée soit sous forme "décimale pointée" ('100.101.102.103') soit par le nom de son domaine ('www.afapl.fr').

La connexion permise par ce processeur AP119 utilise la forme numérique de l'adresse IP. Il est alors nécessaire de convertir le nom du domaine en une adresse numérique. Ceci est effectué par la commande GETHOSTBYNAME de TCP/IP - AP119.

Cette commande fait alors appel à un site externe, appelé "Domain Name Server", qui connaît les tables de correspondance entre les noms de domaine, et les adresses numériques.

rz½ANZ_URL URL;I0;I1;PORT;IP;AREG;N;K

ä cette fonction ‚clate un URL entre PORT, adresse IP, et argument du GET

ä l'URL est de la forme http://<adresse IP>:<port (ou 80)><argument (ou /)>

¸0õ'L''URL doit ˆtre en protocole http' srvERR~(7ÆURL)Ï'http://'

N½(Kì':/'),æK½7ÇURL

(IP ARG)½((I0½¾/N)ÆK)((I1½1ÓN)ÇK)

¸(^/IPî'.0123456789')/L0

ä rechercher l'adresse IP par son num‚ro

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'GETHOSTBYNAME' IP

('GETHOSTBYNAME' APRC TCPIPRC)err APRC

IP ½ CMDRC

L0:PORT½Æ1Ç'0 80' EA '0,',(I0+1)ÇI1ÆK

rz½(ì0)PORT IP((0ôæARG)ã'/' ARG)

6.1.3 GET_URL Lire un URL, après connexion

Cette fonction est appelée après ouverture d'une session.

Elle doit transmettre la demande, et recevoir l'ensemble de la réponse.

Le serveur doit clore la session, dès la fin de l'envoi.

rz½SOCK GET_URL ARG;K;L

ä envoyer un URL, la session est ouverte

'envoi des donn‚es'

K½'GET ',ARG,' HTTP/1.0',nl,accept

ä envoyer cette chaŒne vers le serveur

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'WRITE' SOCK 'B' K

('WRITE' APRC TCPIPRC)err APRC

ä lire la r‚ponse jusqu'… fermeture de la session

K½L½''

ä boucle sur des tron‡ons de r‚ponse

B0:K½K,L

(APRC TCPIPRC CMDRC)½tcp 'TCPIP' 'READ' SOCK 'B'

('READ' APRC TCPIPRC)err APRC

¸(0ôæL½CMDRC)/B0 ä portion de message rendu

ä le message est complet, la session est ferm‚e

rz½(ì0)K

6.1.4 LINKS Extraire les liens d'un URL lu précédemment.

Cette dernière fonction doit rechercher, dans la chaîne passée en argument (sous forme de rz), tous les chaînes commençant par href=", et se finissant sur ".

Cette fonction calcule un vecteur dont chaque élément est le vecteur donnant le nom de la référence. La mise en colonne finale permet seulement une meilleure présentation.

HREF½LINKS rep;CH;M;K

ä rechercher les liens de cet URL

(1ãrep)srvERRÆrep

ä explorer la r‚ponse href=" ... "

M½'href='ÑCH½min[AF eb 1ãrep]

HREF½cOL(Kìþ'"')ÆþK½5Çþ1Ç(~M)âCH

6.2 Exemple d'usage

Cet exemple utilise l'URL de Gérard Langlet.

1 - Le premier appel extrait la réponse html de l'accès dans la variable appelée Gérard (APL2 permet d'utiliser des voyelles accentuées dans les noms de variables. Ne nous en privons pas) :

URL½'http://www.ensmp.fr/~scherer/langlet/'

G‚rard ½ CALL_URL URL

æþG‚rard

0 4893

500Æ1ãG‚rard

HTTP/1.1 200 OK

Date: Mon, 12 May 1997 21:10:46 GMT

Server: Apache/1.2b2

Connection: close

Content-Type: text/html

Last-Modified: Sat, 03 May 1997 20:11:54 GMT

ETag: "2f85e-122c-336b9c0a"

Content-Length: 4652

Accept-Ranges: bytes

<HTML>

<head>

<TITLE>L'oeuvre de Gérard LANGLET ?</TITLE>

<link rev=mad

Le texte précédent est limité aux 500 premiers caractères.

2 - Le second appel analyse le contenu de cette réponse

LINKS G‚rard

mailto:scherer@ensmp.fr

whoisgl.html

transform.html

erreur.txt

erreur.doc

http://cri.ensmp.fr/~scherer/langlet/nvapl15/

http://cri.ensmp.fr/~scherer/langlet/nvapl16/nvapl16.html

http://cri.ensmp.fr/~scherer/langlet/nvapl17/

http://cri.ensmp.fr/~scherer/langlet/nvapl18/

http://cri.ensmp.fr/~scherer/langlet/nvapl19/

http://cri.ensmp.fr/~scherer/langlet/nvapl19/page69.jpeg

http://cri.ensmp.fr/~scherer/langlet/nvapl20/

http://cri.ensmp.fr/~scherer/langlet/nvapl21/

http://cri.ensmp.fr/~scherer/langlet/nvapl22/

http://cri.ensmp.fr/~scherer/langlet/nvapl16/histapl.htm

http://users.aol.com/lemagnen/Sciences_et_Cosmos/

http://www.vector.org.uk/

http://www.vector.org.uk/baa.html

http://www.vector.org.uk/aplfont.html

http://www.vector.org.uk/apl97.html

http://www.yahoo.com/computers/languages/apl/

http://www.acm.org/sigapl/

http://www.torolab.ibm.com/ap/apl/apl2.html

http://webzone1.co.uk/www/dogon/apl.htm

http://www.adminet.com/mail/hoffmann.22feb97.txt

http://www.ensmp.fr/~scherer/mail/apl.2feb96

http://www.ensmp.fr/~scherer/deuriat/

http://math.uwaterloo.ca/~ljdickey

mailto:scherer@ensmp.fr

http://www.ensmp.fr/~scherer/

On peut constater qu'une page Web fait très souvent appel à de nombreuses autres pages Web, afin que nous puissions partir à la découverte.

Ces pages sont mises en place par Christian Scherer, que nous remercions vivement.

7 Sources documentaires

Ces programmes liés au Web sont développés selon des définitions trouvées dans diverses sources :

1 - APL/2 for OS/2 User's guide Description du processeur AP119

2 - TCP/IP Reference manual Warp Online reference + Toolkit, décrit le comportement des primitives "socket"

3 - RFC1945 Hypertext Transfer Protocol HTTP/1.0

4 - RFC1521 Mime Header

5 - HTML, le format des textes transmis, est décrit dans de nombreux ouvrages. Il varie avec chaque fureteur. Le livre HTML The definitive guide (Chuck Musciano & Bill Kennedy - O'Reilly & Associates) est une bonne synthèse des dialectes reconnus en HTML 2.*

6 - Les nouvelles d'APL, pour connaître l'URL de son serveur.

Une trace "IP" des échanges entre un fureteur et un serveur m'ont aussi été d'un grand secours, pour décortiquer précisément les échanges et les synchronisations... Mais vous en avez ici la synthèse