World Wide Web et HTML

On ne présente plus le World Wide Web (aussi appelé communément Web, WWW ou W3)! C'est probablement la facette la plus médiatique d'Internet. C'est certainement aussi la plus impressionnante: hypertexte, multimédia, distribuée... Paradoxalement, nous allons le voir, c'est aussi la plus accessible pour publier votre information!

En un mot, le Web est un outil idéal, puissant et facile à utiliser. Placez un utilisateur devant le Web et il apprendra à s'en servir tout seul, comme si c'était inné! Au bout de quelques clics de souris, il aura déjà fait le tour de la planète! Pour la suite, vous devez néanmoins savoir que pour consulter le Web, vous utilisez un client (Netscape NavigatorMosaïc,CelloLynx, etc...) qui permet de vous connecter à différents serveurs répartis dans le monde. Vous pouvez, bien sûr, passer d'un serveur à un autre de manière transparente, en cliquant simplement sur un lien. Vos propres informations seront donc installées sur un serveur particulier... mais seront visibles du monde entier comme si elles faisaient partie du Web entier.

Le client le plus utilisé actuellement est très probablement Netscape Navigator (communément appelé Netscape tout court), mais il faut garder à l'esprit qu'une proportion non négligeable des lecteurs potentiels de vos informations utiliseront toujours un client différent et aux capacités différentes, ne serait-ce que parce que tous les logiciels de navigation ne sont pas disponibles sur toutes les plates-formes. Cependant, pour garantir une représentation à peu près uniforme de vos données auprès de n'importe quel utilisateur, tous les clients reconnaissent un langage standardisé de structuration des documents. Ce langage est appelé HTML pour HyperText Markup Language, et consiste à enrichir vos différentes pages d'information avec des marqueurs ("tags") indiquant que telle phrase est un titre, que telle autre est une citation, qu'il faut insérer une image à tel endroit, etc...

Le langage HTML - qui est en fait une application particulière de la norme ISO-SGML (Standard Generalized Markup Language) - a été défini à l'origine par le CERN. Mais rapidement, d'autres acteurs d'Internet (notamment NCSA et Netscape) sont venus apporter des suggestions pour étendre le langage. HTML est donc devenu un standard en perpétuel développement sous le contrôle de l'IETF (Internet Engineering Task Force). On a ainsi vu apparaître successivement HTML version 1 puis 2 et bientôt 3. La particularité de ces différentes versions est d'être compatibles plus ou moins dans les deux sens, c'est-à-dire qu'un document écrit sous HTML 1 peut être affiché sans problème par un client implémentant HTML 3; de même, un document HTML 3 peut être affiché par un client HTML 1 mais cette fois-ci avec certaines restrictions... La compatibilité est étudiée de telle sorte que les restrictions se fassent les plus discrètes possibles et ne gênent pas la lecture.

Programmer un serveur Minitel (2): Dompter le Minitel!

[NDA: Article écrit en Setembre 1995, publié dans ST Magazine n° 100 en Décembre 1995.]

Le mois dernier, je vous présentais le code source du logiciel serveur Minitel STUT ONE 2.6X et son fonctionnement général. Ce mois ci, mous allons nous intéresser aux traitements spécifiques nécessaires pour communiquer avec un Minitel. Vous allez découvrir que malgré sa petite taille, il ne se laisse pas dompter si facilement... Le Minitel est il asocial? C'est la question que nous allons élucider ici, en tentant de communiquer avec lui...

Inutile de vous dire que, pour nos explications, nous allons très fortement nous baser sur le code source de STUT ONE fourni sur la disquette du mois dernier. Si vous avez été assez fou pour ne pas vous procurer le numéro précédent de l'unique magazine au monde qui n'a pas peur d'expliquer comment fonctionnent les composantes indispensables de notre monde (un serveur Minitel par exemple!), sachez qu'il n'est peu être pas trop tard et qu'avec un peu de chance, il en reste un exemplaire à la boutique Pressimage...

LES OREILLES DU MINITEL

Posez donc votre Minitel sur une table et regardez le en face. Regardez le bien. Est-ce que vous voyez des oreilles? Oui? Alors je vous conseille d'arrêter de manger des champignons... Non? Rassurez vous c'est normal! Simplement parce que les oreilles du Minitel sont sur sa face arrière!

Vous avez maintenant le choix entre retourner votre Minitel ou bien contourner votre table. Toujours est-il que sur la face arrière, vous verrez une prise DIN, ronde avec 5 canaux auditifs (5 trous quoi). C'est dans cette oreille là qu'il faut causer pour que votre Minitel vous écoute. C'est surtout, par là que le serveur va causer pour dominer le Minitel, tel un maître son esclave.

L'autre oreille du Minitel, elle se situe au bout d'un tentacule (un cordon quoi) qui part de la face arrière et se loge dans la première prise téléphonique qu'elle trouve. C'est par là que le Minitel écoute ce que veulent les connectés du serveur. Ce qu'il entend par là, il devra le rapporter à son maître: l'ordinateur serveur...

Mais comment fait-il, justement, pour parler au maître. Eh bien, en fait, les oreilles du Minitel sont aussi des bouches et il peut donc parler avec ses oreilles! C'est vraiment incroyable l'anatomie de ces bêtes là!

Le mode de fonctionnement de ces organes est néanmoins assez simple à la base: quand le serveur envoie quelque chose dans une oreille, le Minitel l'envoie au connecté par l'autre. Et quand le connecté fait une requête dans l'autre oreille, le Minitel la transmet au serveur par la première...

Vous connaissez cette moquerie: "çà rentre par une oreille et çà ressort par l'autre". Oui? Eh bien, elle est tout à fait adaptée au fonctionnement du Minitel. En gros, le Minitel est donc une boîte sans cervelle, tout à fait stupide et qui ne sait s'affranchir que d'un éventail de tâches très limité. Ceci implique que nous allons constamment devoir être derrière lui...

MAIS A QUOI SERT-IL?

En temps normal, quand vous utilisez le Minitel en tant qu'interprète, pour vous connecter au 11 par exemple (commercialement parlant, je devrais dire: quand vous vous connectez au 3615 STMAG)... quand vous vous connectez au 11 donc, c'est un peu différent, puisque les informations à afficher arrivent par l'autre oreille - celle qui est dans la prise téléphonique. Les commandes que vous tapez repartent également par cette 'oreille'...

Résumons nous: les deux oreilles fonctionnent à peu près de la même manière. Quand vous parlez dans l'une, çà ressort par l'autre, et en plus çà s'affiche sur l'écran. Et quand vous parlez dans l'autre, çà ressort par la première et çà s'affiche aussi sur l'écran. Et encore plus subtil: quand vous tapez sur le clavier, çà lui sort par les deux oreilles en même temps, au Mintel!

Vous avez probablement un doute là... En effet, pourquoi deux oreilles au fonctionnement identique ont elles une apparence physique si différente? Il y a en effet une petite différence, elle se situe au niveau des signaux: l'oreille-fiche-téléphonique parle une langue "analogique" alors que l'oreille-prise-DIN-5-broches parle une langue "digitale". Quant au clavier et à l'écran, ils parlent une langue "humaine".

Le métier du Minitel est donc un métier d'interprète (même si vous ne l'aviez jamais remarqué jusque là). Le Minitel effectue instantanément la traduction entre trois langue: le "digital", la langue des ordinateurs, "l'analogique", la langue du réseau téléphonique, et "l'humain", la langue des utilisateurs.

Cet interprète, vous le payez 20 Francs/mois, ce qui est peu cher payé, voire complètement immoral. Néanmoins, comme il ne bronche pas, on ne va pas se priver et on va le faire travailler à plein régime.

Bien sûr, cette explication est un peu simpliste, et je vais vous la résumer, façon techno-maniac pour être sûr que tout le monde comprend bien: Le Minitel n'est autre qu'un terminal asynchrone interconnectant de manière complète un écran 40*25 8 niveaux de gris, un clavier AZERTY étendu, un modem V23 et un codec TTL. C'est clair? Bon, alors continuons...

AFFICHE!

La légende veut que les sysops de serveurs RTC, et à fortiori les auteurs de logiciels serveurs comme vous et moi, soient assoiffés de pouvoir. Ce pouvoir, ils, enfin nous, l'avons tout d'abord exercé sur notre chien, maintenant sur notre Minitel et le mois prochain, nous tenterons de l'exercer sur nos connectés. Ensuite nous serons probablement maîtres du monde. Mais d'ici là, nous avons du boulot! Je ne vais pas ici vous expliquer comment faire asseoir ou coucher votre Minitel, néanmoins, je vais tenter de vous montrer comment le faire afficher... Faciiiiile.

Première solution: vous allumez votre Minitel et vous écrivez en langage humain sur le clavier. Le Minitel va afficher en langage humain sur l'écran. C'est simple, rapide et efficace, sauf que vous allez vite en avoir marre de taper au clavier et de recommencer pour chaque nouveau connecté.

Deuxième solution: vous appelez le 11 et là bas un gentil ordinateur se charge de parler dans l'oreille téléphonique de votre Minitel pour le faire afficher. L'inconvénient c'est qu'il n'affiche pas vraiment ce que vous voulez!

Troisième solution: vous lui parlez dans son oreille-prise-DIN, mais cette oreille ne comprend que le "digital". Le grand bonheur, c'est que vous avez dans les parages un ordinateur de type ATARI ST (Avouez, nous savons tout!) parfaitement à même de parler le 'digital' avec votre Minitel. Un câble entre la prise DIN et la prise série de votre ATARI et ils sont prêts à se parler.

Votre ordinateur dispose également de la capacité fort intéressante de pouvoir être programmé. Vous pouvez donc lui faire mémoriser un série d'actions qu'il refera autant de fois que vous le désirez. Dans le cas qui nous intéresse, nous voulons qu'il mémorise des "phrases" et qu'il les répète dans l'oreille du Minitel lorsque bon nous semble.

En GfA Basic, il y a plusieurs manières de parler au Minitel en utilisant la prise série. La première s'applique très rapidement comme ceci:

OUT 1,65,66,67

Cette instruction affiche ABC sur l'écran de votre Minitel. Le 1 correspond au port série. Si vous avez plusieurs ports série, le 1 correspond au port série par défaut réglé dans le panneau de contrôle. Nous n'avons pas à chercher plus loin ici, puisque STUT ONE 2 ne gère qu'un seul port série. Les nombres 65, 66 et 67 quant à eux correspondent aux codes ASCII des lettres A, B et C.

La deuxième méthode est un peu plus civilisée:

OPEN "",#99,"AUX:"
PRINT #99,"ABC";
CLOSE #99

Il faut ici commencer par ouvrir un canal vers le port série (AUX:). Ici nous attribuons arbitrairement le n° 99 à ce canal. Ensuite nous pouvons faire des prints vers le port série, et c'est, ma foi, bien agréable. A la fin du programme, nous n'oublions pas de refermer la porte derrière nous...

La deuxième méthode, plus civilisée, semble avoir tous les avantages. Eh oui, on pourrait par exemple stocker une grande chaîne de caractères dans la variable page$ et l'afficher en un tournemain avec:

PRINT #99;page$;

Malheureusement ce n'est pas si simple, en effet, le Minitel se laisse piloter par un certain nombre de codes de contrôles assez barbares. Dans ce cas, on aura par exemple le choix entre:

OUT 1,27,66

et

PRINT #99;chr$(27);chr$(66);

pour passer en encre verte.

Déjà, la première solution semble plus courte. Autre exemple:

PRINT #99;"çà c'est génial";

produira quelque chose de bizarre. En effet, le Mintel et l'ATARI ne sont pas d'accord sur la représentation des caractères accentués. Pour afficher une telle phrase, il faut donc l'analyser caractère par caractère et envoyer des codes spéciaux à chaque fois que l'on rencontre un caractère accentué. C'est ce que fait la procédure affiche_msg() par exemple. La conversion d'un caractère accentué en une chaîne de caractères équivalente pour le Minitel se fait en appelant la procédure code_accent().

STUT ONE mélange donc allègrement la méthode OUT1,x et la méthode PRINT #99;x$; pour afficher sur le minitel, selon ce qui est le plus pratique à un instant donné.

VITESSE, PARITE ET LES AUTRES...

Envoyer des caractères vers le port série, d'une manière ou d'une autre, est une bonne chose. Mais en pratique cela pose quelques petits problèmes de compréhension entre la machine qui émet et celle qui est censée recevoir. Nous évoquions plus haut que le port série de l'ordinateur et la prise DIN 5 broches parlaient la même langue: le 'digital'. Soit, mais cette langue se décompose en plusieurs 'dialectes'! Il y a des paramètres tels que le débit, le nombre de bits par caractère, la parité et le contrôle de flux sur lesquels ils doivent se mettre d'accord.

Le Minitel impose des échanges à 7 bits par caractère et une parité paire. Quant à la vitesse (le débit), il y a plusieurs possibilités. D'un côté, sur la prise téléphonique, le Minitel (hormis les modèles les plus récents que seuls les employés de France Télécom peuvent s'offrir) ne peut communiquer qu'à 1200 bps. Que signifie bps? Cela signifie 'bits par secondes'. Dans ce cas précis on peut aussi parler de 1200 bauds, mais évitez, çà vous évitera de dire des âneries par la suite.

Concrètement, à quoi correspond cette vitesse? Nous avons vu que le Minitel utilisait 7 bits par caractère. Il y a également un bit de parité (paire). S'ajoute à cela, un bit de début de caractère et un bit de fin de caractère. Sans eux, deux Minitels (ou modems) communiquant entre eux ne sauraient pas où commencent les caractères. Ca nous fait donc 10 bits par caractère. Si on divise alors 1200 par 10 on se rend compte que le Minitel transmet (ou reçoit, selon les cas) 120 caractères par seconde. Sachant que son écran de 40 colonnes et 25 lignes fait 1000 caractères, un écran complet peut donc théoriquement s'afficher en 8,3 secondes, ce qui est déjà assez long...

Mais ce chiffre correspond à une suite de caractères blancs sur fond noir, sans jamais changer de couleur, sans clignotement, sans soulignement, sans animations, sans caractères semi-graphiques, etc... En effet à chaque fois que l'on veut introduire l'un des effets ci-dessus, il faut introduire dans le flux de caractères affichables, des caractères de contrôle permettant de changer de couleur, de passer en inverse vidéo, etc... Ces caractères de contrôles viennent rarement seuls, c'est souvent une séquence de 2, 3 ou 4 caractères d'un coup. Pour distinguer ces séquences de caractères du texte, elles commencent généralement par le caractère 'escape' de code ASCII 27 ($1B en héxadécimal). Vous le retrouverez dans l'exemple plus haut permettant de passer en entre verte.

C'est ainsi que le Minitel est devenu célèbre pour sa légendaire vitesse de transmission. La seule solution pour que çà aille un tout petit peu plus vite est d'afficher des pages un peu plus dépouillées...

Imaginez maintenant que vous êtes en train de créer une page vidéotex (un écran Minitel). Si a chaque modification, vous devez attendre 10 secondes pour voir le résultat, vous allez vite devenir fou. C'est pour cela que sur la prise DIN (qui s'appelle en fait prise péri-informatique), le Minitel 1B peut communiquer jusqu'à 4800 bps et le Minitel 2, jusqu'à 9600 bps. Et celui qui me parle de bauds sur la prise péri-informatique sera banni à jamais!

Au début, on se dit donc la chose suivante: on va communiquer à 9600 bps entre l'ordinateur et le Minitel, et puis derrière, sur la ligne téléphonique, ma foi, on ne communiquera qu'à 1200 bps, puisqu'on ne peut pas aller plus vite. Oui, c'est très intéressant çà! Comme çà, quand on fait des tests en local, çà va vite, et puis quand un type est connecté sur notre serveur, eh bien çà va aussi vite que çà peut!

Mais ce n'est pas si simple. Dans le cas précis où un type est connecté à 1200 bps et que l'ordinateur envoie une page vers le Minitel à 9600 bps, le Minitel reçoit, en une seconde, 8 fois plus d'informations qu'il ne peut en transmettre dans le même intervalle de temps. Ces données doivent êtres mises en mémoire par le Minitel, pour les envoyer un peu plus tard. Mais l'ordinateur continue d'envoyer, et le Minitel doit mettre de plus en plus de données en Mémoire. Cette mémoire, qu'on appelle une mémoire tampon (buffer en anglais) est limité. Dans le cas du Minitel, elle fait 256 octets, c'est à dire que c'est comme s'il n'y en avait pas. En envoyant à 9600 bps, vous la remplissez en un peu plus d'un quart de seconde! Et en moins d'une demi seconde, vous aurez envoyé plus de données que le Minitel n'a pu en stocker ou envoyer. Ces données en trop disparaîtront littéralement dans le néant (il y a un trou noir dans tous les Minitel, sisi, croyez moi!).

La seule solution pour éviter ces fâcheux problèmes, est de repasser la liaison ordinateur-Minitel à 1200 bps lorsqu'on travaille en mode connecté. Si vous arrivez à comprendre çà, vous êtes sur la bonne voie. Les éminents programmeurs d'une éminente société d'édition du nom de Log Access n'ont jamais saisi... [NDA: Private joke... sorry!]

CHANGER DE VITESSE

Bon, accrochez-vous, on va faire une comparaison vraiment tirée par les cheveux! Quand vous conduisez une voiture, si vous voulez changer de vitesse, vous devez d'abord débrayer et ensuite vous pouvez manipuler le levier de vitesse. Si vous ne débrayez pas avant de changer de vitesse, vous n'arriverez pas au résultat escompté. Vous aurez même des effets secondaires indésirables...

Eh bien pour changer la vitesse de la liaison ordinateur-Minitel, c'est pareil. L'ATARI dispose d'un appel système: XBIOS(15) pour changer la vitesse du port série. La procédure init_rs_520_1040 utilise cet appel système. Mais cet appel système, c'est comme le levier de vitesse: il faut 'débrayer' avant de l'utiliser!

En effet, imaginez que l'ordinateur communique avec le Minitel à 1200 bps et que tout à coup vous changez la vitesse de l'ordinateur à 9600 bps. La vitesse du Minitel, elle, reste à 1200 bps. Et les deux appareils ne peuvent plus communiquer jusqu'à ce que vous les mettiez à nouveau sur la même vitesse.

Pour changer la vitesse de la prise péri-informatique du Minitel, on peut utiliser la combinaison de touches Fnct+P puis 9 sur le clavier du Minitel (9 comme 9600, 4 comme 4800, 1 comme 1200 ou 3 comme 300 bps). Néanmoins ce sera vite lassant si vous devez répéter cette gymnastique avec vos doigts à chaque fois. Les ingénieurs de France Télécom y ont pensé et ont prévu une séquence de codes (vous savez celles qui commencent par Escape) que l'on peut envoyer par la prise péri-info, ce qui changera sa vitesse. Seulement voilà, si vous avez changé la vitesse de l'ordinateur, tout ce qu'il pourra bien envoyer à la prise péri-info sera incompris. Il faut donc demander au Minitel de changer de vitesse AVANT de changer la vitesse de l'ordinateur! Vu?

De plus, il ne faut pas changer la vitesse de l'ordinateur avant d'être sûr que les codes de changement de vitesse soient bien arrivés au Minitel. Il faut donc marquer une petite pose. Mais, bien sûr, entre le moment où le Minitel à changé de vitesse et celui ou l'ordinateur l'a fait aussi, il y a un laps de temps pendant lequel toute communication est impossible. Si le Minitel avait quelque chose d'important à dire à ce moment là, par exemple "j'ai détecté un appel entrant", l'ordinateur ne l'entendra pas.. et comme le Minitel ne le répétera pas... on distingue dores et déjà un deuxième trou noir! Les aléas de la technique... mmmh...

Permettez moi de faire une parenthèse et de vous dire comment les américains on traité le problème. Vous savez déjà que chez eux, les voitures sont automatiques et qu'on n'y débraye pas avant de changer de vitesse. Eh bien, quand ils ont inventé le modem à plusieurs vitesses, ils ont continué dans cette voie. Prenez un modem compatible Hayes, branchez-le, réglez la vitesse de l'ordinateur à n'importe quelle vitesse, envoyez une commande AT quelconque, et hop, le modem à adopté la vitesse. Changez la vitesse de l'ordinateur, renvoyez une commande Hayes, hop le modem s'est adapté... "Trop puissant le protocole Hayes!" serait-on tenté de dire. M'enfin, revenons en au Minitel...

Le corollaire du problème, c'est que quand STUT ONE démarre, il n'a aucune idée de la vitesse actuelle du Minitel, et pourtant il doit s'aligner sur cette vitesse pour commencer à communiquer avec lui! Il a trois chances sur quatre de se planter. Voici donc la méthode utilisée pour obtenir un taux de réussite de 100%. STUT ONE passe la prise série de l'ATARI successivement aux vitesses de 9600 bps, 1200 bps et 300 bps. A chaque fois, on demande au Minitel de passer à 4800 bps. Soit le Minitel reconnaît la requête lors d'un des trois essais, soit il était déjà à 4800 bps. Ensuite on passe l'ordinateur à 4800 bps et là on est sûr d'être à la même vitesse que le Minitel. On peut maintenant continuer sur de bonnes bases.

LES BASES, PARLONS-EN DES BASES!

Maintenant que vous savez à peu près tout ce qui est nécessaire pour envoyer des caractères, commandes et autres séquences de codes au Minitel, il ne vous reste plus qu'à connaître la syntaxe desdites commandes.

Je vous ai dévoilé au début, comment passer en encre verte. Je suis conscient que ce n'est pas très palpitant, mais vous pourrez trouver pratiquement toutes les séquences de commande du Minitel rien qu'en fouinant dans le code source de STUT ONE. La procédure code_vdt() est particulièrement adaptée pour commencer vos recherches. En effet, c'est elle qui s'occupe de traduire les pages vidéotex composées en langage SOVI.

Maintenant, si vous voulez de la documentation officielle, sachez qu'elle existe. Ca s'appelle "Spécifications Techniques d'Utilisation du Minitel 1B" (STUM1B pour les intimes) et çà se commande au CNET (renseignements dans les agences France Télécom). Existe aussi en version STUM2, additif au STUM1B et décrivant les nouvelles fonctions du Minitel 2. On espère le STUM4 pour bientôt... Remarquez, on est pas encore sûr du nom, ce sera peut-être aussi STUM-TVR (Télétel Vitesse Rapide) STUM-Photo ou même STUM'95 (Si ils s'inspirent de Microsoft...)

Bon allez, je vous laisse tenter de dompter votre Minitel. Bon courage!

Débugguer les mallocs!

[NDA: Article écrit en Juillet 1995 et publié dans ST Magazine n° 99 en Novembre 1995. Il est intéressant de constater qu'il existe depuis des produits commerciaux d'aide à la gestion de la mémoire, basés sur des concepts très similaires à ceux exposés ici!]

Sous ce titre de science-fiction, se cache en fait un petit utilitaire, qui se révélera sans aucun doute, fort pratique pour tous ceux qui utilisent la gestion dynamique de la mémoire en C.

Gestion dynamique de la mémoire?

Qu'entendons nous au juste, par "gestion dynamique de la mémoire" ? Il s'agit simplement de toutes les fonctions offertes avec le C ANSI permettant d'allouer et de réserver des zones de mémoire dynamiquement, sur le tas (heap). Concrètement, il s'agit des fonctions suivantes:

  • malloc() "Memory ALLOCation", pour réserver une zone.
  • calloc() pour réserver une zone et l'initialiser à 0.
  • realloc() pour réallouer une zone avec une taille différente.
  • free() pour libérer une zone préalablement allouée.
  • strdup() pour dupliquer une chaîne de caractères, ce qui entraîne un malloc() pour contenir la nouvelle chaîne de caractères.

Le recours à ces fonctions est en particulier nécessaire à chaque fois que vous ne pouvez pas prévoir, lors de l'écriture du programme, la taille de la zone de mémoire dont vous aurez besoin.

De même, si vous avez besoin d'un grande quantité de mémoire, mais seulement sur une durée limitée par rapport à la durée d'exécution de votre programme, vous voudrez réserver cette mémoire au moment voulu et la libérer dès que vous n'en avez plus besoin...

Post complet »

Programmer un serveur Minitel (1)

[NDA: Article écrit en Juillet 1995, publié dans ST Magazine n° 99 en Novembre 1995.]

Le Minitel à beau être technologiquement dépassé, il n'en reste pas moins le moyen de consultation électronique de données le plus répandu en France avec près de 7 millions d'unités installées. En ouvrant un serveur Minitel, vous avez donc un public potentiel assez large! Néanmoins, il vous faut un logiciel adapté à vos besoins. Nous vous proposons ici de partir du "best-seller" STUT ONE pour réaliser votre propre logiciel, sur mesure!

HISTORIQUE

Il y a deux ans (déjà!) nous vous offrions sur la disquette du magazine, le logiciel serveur STUT ONE 2.6 et nous vous expliquions comment l'utiliser pour créer un serveur Minitel (numéros 72 à 75). Remercions au passage Thomas Conté pour l'initiative. Avant de lire la suite, nous vous recommandons vivement de relire ces numéros, ou, si besoin est, de les commander à la boutique Pressimage.

Simulation d'écran Minitel
Simulation d'écran Minitel

Aujourd'hui, STUT ONE 2.6 est encore très utilisé mais... vous vous êtes fait la main dessus et il finit par accuser certaines limitations que vous jugez probablement insupportables. Disons par exemple qu'il ne supporte pas d'autre protocole de téléchargement que Transteaser ou encore que la capacité des BALs est trop limitée.

Alors bien sûr il y a STUT ONE 3... mais personne ne peut dire quand est-ce qu'il sera fini! Je suis particulièrement bien placé pour le dire, puisque j'en suis l'auteur! De toute façon, STUT 3 fonctionne sur un principe assez différent de STUT 2 et vous demanderait une phase d'adaptation assez importante...

Finalement, vous êtes nombreux à me poser régulièrement des questions sur l'art et la manière de programmer un logiciel serveur sur ST et je n'ai pas toujours le temps de répondre. Parfois, vos questions sont tellement techniques qu'elles m'obligeraient à effectuer des recherches approfondies dans le code source de STUT ONE pour retrouver la solution.

Pour toutes ces raisons, nous avons décidé de vous offrir ce mois-ci le code source intégral de STUT ONE version 2.6X. Vous le trouverez sur la disquette. [NDA: Vous le trouverez en téléchargement sous cet article.]

NOTRE OBJECTIF...

Nous n'avons pas l'intention de vous donner un code source de 500 Kilo-octets et de vous dire "débrouillez-vous avec çà!". Nous allons en fait vous donner plus de détails sur la manière dont il est structuré et surtout les grands principes à appliquer lorsque l'on programme un logiciel serveur. Vous pourrez constater que le code source ne respecte pas toujours ces principes; mais cela s'explique peut-être par le fait que j'ai déterminé ces principes en partant des erreurs commises en écrivant le logiciel!

Nous n'allons cependant pas nous attarder sur les détails d'utilisation du logiciel. C'est surtout par manque de place, mais aussi parce que nous l'avons déjà fait dans les numéros 72 à 75 de ST Mag.

Si vous êtes utilisateur de STUT ONE 2.6, vous pourrez prochainement le modifier selon vos besoins et ajouter les fonctions qui vous manquaient jusque là. Si vous n'utilisez pas encore STUT ONE, c'est peut-être le moment de vous y mettre; vous ne risquez rien, puisque vous pourrez TOUT adapter à[FP1] vos besoins spécifiques. Quant à ceux qui ont déjà ou sont en train de programmer leur logiciel serveur "maison", ils pourront bien sûr s'inspirer des principes donnés ici, voire intégrer les leurs à STUT ONE.

Cette version de STUT ONE est programmée en GfA-Basic, mais en fait, le langage utilisé n'a pas beaucoup d'importance. En effet, nous ne faisons pas ici un cours de programmation, mais plutôt une revue de concepts applicables aux serveurs télématiques. En conséquence, vous êtes donc supposés savoir déjà programmer... mais, le cas échéant, apprendre le GfA-Basic reste une tâche tout à fait abordable...

Par contre, il faut savoir que cette version de STUT ONE ne gère que le Minitel (pas de modem), et un seul (un seul connecté à la fois). Nous nous limiterons donc (dans un premier temps du moins) à expliquer le fonctionnement de logiciels serveurs Minitel Monovoie.

Dernier détail: STUT ONE est prévu pour être utilisé sur le réseau téléphonique commuté (RTC) et non sur Transpac. Concrètement, cela veut dire que votre serveur est accessible par un numéro de téléphone standard à 8 chiffres et non pas par un quelconque 36 15 suivi d'un code. La programmation d'un serveur pour Transpac serait sensiblement différente... elle implique le multivoies, une partie des fonctions est prises en charge directement par les Points d'Accès Videotex de France Télécom, etc... Mais de toute façon, vu le coût d'une ligne Transpac, çà n'intéresserait qu'un nombre très restreint de nos lecteurs!

A part cela, j'ai un avertissement à donner: le style de programmation utilisé dans ce logiciel n'est vraiment pas un exemple à suivre. Si vous le faites quand même, je ne réponds plus de rien le jour ou voudrez débugguer votre application!

A VOS MARQUES...

Si vous décompactez le fichier fourni sur la disquette vous obtiendrez un dossier prosaïquement nommé "SOURCE" contenant le code source de STUT ONE 2.6X et tous les fichiers nécessaires à son exploitation. Vous avez le logiciel complet prêt à l'emploi. Vous trouverez également le fichier LICENSE.TXT dans lequel vous trouverez les conditions d'utilisation du logiciel (nous en reparlerons!)

Le gros morceau c'est le fichier STUT_26X.LST. Il contient 20 000 lignes de GfA-Basic bien tassées. J'entends par là, qu'il y a peu de commentaires, ce qui est un tort. (Rassurez-vous, il y en a quand même un certain nombre!) Sachez simplement que ce fichier doit être chargé dans votre interpréteur GfA-Basic avec l'option MERGE (Ca prend quelques minutes, vu la taille!). Vous pourrez ensuite le sauvez en STUT_26X.GFA ce qui sera plus rapide! Nous vous avons fourni le source sous forme de .LST parce que les .GFA ne sont pas compatibles d'une version à l'autre. Pour le développement, j'ai utilisé les version 3.07 puis 3.50... si vous avez une autre version, essayez et vous verrez bien! La seule certitude est que çà ne marchera pas avec les versions antérieures à la 3.0.

STUT_26X.RSC est le fichier de ressources; c'est là que sont définis les menus et boîtes de dialogues utilisées par le programme. Vous avez besoin d'un éditeur de ressources pour le modifier. N'importe lequel fera l'affaire, mais le fichier de définition STUT_26X.RSD vous rendra la vie plus agréable si c'est "Interface" que vous utilisez. ATTENTION: le fichier .RSC est assez gros: il fait près de 64 Ko... et les fichiers ressources de plus de 64 Ko posent souvent de gros problèmes... surtout avec le GfA!

STUT_26X.DEF est un fichier texte (éditable avec 7Up par exemple) qui contient un certain nombre de paramètres par défaut. Une copie est fournie sous COPY_26X.DEF pour le cas où vous auriez modifié ces paramètres au delà du raisonnable et que vous voudriez rapidement revenir à l'original.

Finalement STUT_26X.NEW est un fichier contenant un serveur de base sous forme pseudo-compactée. STUT ONE va lire ce fichier lorsque vous invoquez l'option "Créer un nouveau serveur".

...PRET

Voilà, vous êtes maintenant prêts à utiliser le code source. Si vous le chargez dans l'interpréteur et que vous cliquez sur "Run" il devrait s'éxécuter sans aucun problème et pouvoir charger, sans aucun problème non plus, votre serveur réalisé sous STUT ONE 2.60. (En fait, le format des fichiers est resté le même depuis la version 2.4, si ma mémoire est bonne.) Songez seulement que vous aurez besoin de plus de mémoire qu'à l'accoutumée, puisque le GfA-Basic à lui seul, en occupera une certaine partie. Vous bénéficierez ensuite immédiatement des corrections de quelques bugs gênants dans STUT ONE 2.60.

STUT ONE 2.6X est en fait l'ultime évolution de STUT ONE 2.63. La version 2.6X était destinée à devenir la version 2.7 mais elle n'a jamais été achevée. Vous constaterez d'ailleurs que certaines nouvelles fonctions ne sont que partiellement implantées... Je pense en particulier à la gestion de TEXTES qui utilise actuellement le même espace mémoire que la gestion des pages vidéotex... Mais rassurez vous, la compatibilité ascendante avec la version 2.63 est totale.

Pour la petite histoire, sachez simplement que si j'ai arrêté le développement de STUT 2.7, c'est d'une part, parce que je ne supportais plus les caprices du GfA-Basic et de son compilateur ainsi que leurs limitations respectives et d'autre part, parce que j'avais tout un panier d'idées nouvelles qui auraient été très difficiles à rajouter à la version 2.6. J'ai alors recommencé un nouveau logiciel: STUT 3, écrit en langage C, multivoies et tout çà... Le hic, c'est que j'ai eu les yeux plus gros que le ventre, où plutôt devrais-je dire: les pensées plus rapides que les doigts, et je suis loin d'avoir fini de le programmer. Aujourd'hui, STUT 2.6 lui reste encore supérieur quant au nombre de fonctions disponibles...

Si vous disposez d'un compilateur GfA Basic, vous devriez également pouvoir compiler le source sans problème en utilisant les options par défaut. Cependant, il y a une variable globale (inter!) à mettre à 0 dans le code source.

Si vous n'avez pas encore réalisé de serveur avec une version antérieure de STUT ONE que vous pouvez charger et si vous n'avez pas encore reçu vos numéros 72 à 75 de ST Mag, le meilleur endroit pour commencer est de cliquer sur l'option "Créer un nouveau serveur..." du menu "Fichier" de STUT ONE. Après çà, vous devrez utiliser une méthode un peu plus heuristique pour arriver à vos fins! (Pour ceux qui veulent des termes plus concrets: vous devrez utiliser votre pifomètre!)

...PARTEZ!

Bien, si vous êtes arrivés jusque là sans recourir à l'utilisation de médicaments pour le nerfs ou la migraine, c'est que vous avez le profil requis pour développer un serveur, ou du moins, pour faire évoluer STUT ONE! Surtout, pas de panique, mais si néanmoins vous avez coincé alors que vous êtes très intéressé par la suite, contactez-moi par Minitel (j'ai dit: PAR MINITEL!) au (1) 00.00.29.45 [NDA: ce numéro n'est plus attribué... évidemment :)] code STUT ou bien sur Internet [NDA: en fait, aujourd'hui je ne pourrai plus vous en dire grand chose :)]. Il y a aussi le 36 15 STMAG... mais il y a fort à parier que si vous vous intéressez à la programmation d'un serveur RTC, vous n'ayez pas des sentiments très tendres envers les 36 15...

Commencez donc par regarder le code source dans son intégralité avec les procédures repliées (Control-Help en ayant le curseur sur un nom de procédure). Vous constaterez qu'il y a cinq parties principales.

La première est un bla-bla parlant du logiciel et de sa licence qu'il est bon de lire au moins une fois mais qui n'a aucune influence sur le fonctionnement du logiciel proprement dit. Bon, trêve de plaisanterie, passons aux choses sérieuses...

La deuxième partie est le programme principal. Il est assez court et appelle de nombreuses fonctions qui se chargent d'effectuer les différentes tâches. Il y a quelques détails à noter lors de l'initialisation. Tout d'abord la variable inter! indique au reste du programme que l'on tourne sous l'interpréteur ou que le programme est compilé (dans ce cas, vous devez bien sûr le compiler vous même!). Sous interpréteur, certaines actions supplémentaires sont effectuées par rapport au programme compilé. En particulier, on dessine un fond de bureau au démarrage puisque le GfA démarre avec un écran blanc. Sous interpréteur, on fixe aussi "à la main" (avec CHDRIVE et CHDIR) le dossier dans lequel se trouvent les fichiers utilisés par STUT ONE (.RSC .DEF etc...) puisque le GfA reste toujours dans le dossier courant... ce qui peut changer au cours du temps. Lorsque l'on lance un programme compilé (.PRG) par contre, le dossier courant est le dossier contenant le .PRG (en général) et le fond de bureau est déjà dessiné.

Après le programme principal, on trouve toutes les procédures et fonctions regroupées en trois catégories: les procédures générales, les procédures d'édition et les procédures d'exploitation. Les procédures d'édition servent pour toutes les fonctions concernant l'édition d'un serveur (création de pages vidéotex, de pages arbo, etc...) alors que les procédures d'exploitation servent pour toutes les fonctions utilisées en mode serveur proprement dit (affichage des pages, saisie de messages, détection de sonnerie, téléchargement, etc...). Les procédures générales quant à elles, servent dans tous les cas.

Cette décomposition est un héritage de l'époque ou le 520 STF était la machine la plus répandue alors qu'il fallait un mega de mémoire vive pour faire tourner STUT ONE. On pouvait alors séparer le logiciel en deux parties: un éditeur ("MAKE_ONE": prog ppal + proc générales + proc d'édition) et un serveur proprement dit ("USE_ONE": prog ppal + proc générales + proc d'exploitation), chacunes d'entre elles pouvant alors s'accommoder de 512 Ko de RAM seulement. Sachez néanmoins qu'il vous faudra quelque peu modifier les procédures ayant pour suffixe _520_1040 dans chaque cas.

Ceci dit, même si la majorité des utilisateurs disposent aujourd'hui d'un Mega-octet de RAM et souvent plus, la séparation est restée. Elle est en effet bien pratique pour retrouver plus rapidement une procédure donnée. Par contre, à l'intérieur de chacun des trois grands groupes, les procédures sont classées selon l'anarchie la plus totale, puisqu'elles y apparaissent par ordre alphabétique! Autrement dit, soit vous savez comment s'appelle la fonction qui vous intéresse, soit vous allez mourir ailleurs! Il serait clairement profitable de réorganiser toutes ces procédures en sous-groupes fonctionnels...

Mais vous voudrez sans doute faire bien plus que çà, aussi allons nous maintenant entrer dans les détails de fonctionnement du serveur.

LE NOYAU DU SERVEUR

Ce qui nous intéresse ici, ce sont les procédures d'exploitation. C'est là que nous trouverons les fonctions spécifiques à un serveur télématique; le reste du logiciel, quant à lui, n'est que de la programmation GEM "relativement" classique, avec des fautes de style en plus! On me dit parfois que je devrais avoir plus de respect pour mon travail... En tout cas, Claude Attard à traité le sujet récemment, reprenez ses articles, si besoin est, pour vous y retrouver. (Je dois quand même signaler que STUT ONE 2 utilise très mal le GEM: fenêtre non déplaçables, etc... et il se permet même des horreurs comme de faires des PRINT TOS dans les fenêtres GEM... c'était pour que çà aille plus vite! blurg!)

Bref, lorsque vous lancez le serveur depuis le menu principal, vous appelez en fait une des procédures suivantes: local, off_line ou normal, selon le mode choisi. Ces procédures s'occupent en fait d'ouvrir la fenêtre serveur et de débuter une connexion. Si en mode local, vous démarrez immédiatement sur les chapeaux de roues, les procédures off-line et normal sont un peu plus complexes. En effet, en mode off-line, le serveur affiche des écrans de pub (ou autres...) sur le Minitel local en attendant qu'on appuie sur Connexion/Fin pour démarrer une connexion (c'est un mode "spécial salon" pour faire des écrans qui défilent avec des messages: "Notre produit est génial et pas cher, pour en savoir plus, approchez-vous et appuyez sur Connexion/Fin!"). Finalement, en mode normal, le serveur attend de détecter une sonnerie et que la connexion soit établie pour commencer. (La détection de sonnerie se fait soit par réception de codes spéciaux provenant d'un Minitel 2 ou 12 ou bien par détection d'un appui sur le bouton FEU du joystick, si vous avez connecté un détecteur de sonnerie en lieu et place du joystick!)

Une fois la connexion établie, chacune des procédures ci-dessus appelle la procédure serveur. Vous y trouverez tout d'abord un certain nombre d'initialisations devant être effectuées au début de chaque nouvelle connexion. Puis, on entre dans la boucle principale du serveur... C'est le moment de sortir le grand jeu!

Le principe même de STUT ONE (révolutionnaire à l'époque! sisi!) est de tourner dans une boucle infinie. A chaque tour de boucle on traite la "page arbo" courante: on la décode, on affiche les pages vidéotex correspondantes, on effectue des saisies au clavier, on fait divers traitement et finalement on définit la prochaine page arbo sur laquelle il faut se rendre. A ce moment là, on boucle et on recommence tout çà. Grosso modo, on ne sort de cette boucle principale que le lorsque le connecté à appuyé sur "Connexion/Fin". Enfin çà, c'est la théorie; en pratique, on sort également suite à une erreur dans l'arbo, un ordre du sysop, etc...

La page arbo courante est identifiée par son nom (8 lettres) dans la variable page_a$. Une fois que cette page a été trouvée dans le tableau contenant toutes les pages arbo, on va généralement vouloir afficher une page vidéotex. Cette page vidéotex est indiquée dans le parametre$(0) de la page arbo en cours.

Mais le traitement commun s'arrête là. Ensuite, chaque page arbo peut avoir une fonction différente. Ainsi, certaines pages auront pour fonction de présenter un menu à l'utilisateur, d'autres saisiront un message, d'autres afficheront la liste des messages en BAL, d'autres permettront de télécharger un fichier, etc... Pour traiter ainsi les actions spécifiques à chaque page, la boucle principale contient un SELECT/CASE qui va aiguiller le traitement vers une procédure dédiée à une fonction arbo donnée. La fonction de la page arbo courante est codée sous forme de numéro dans la variable fnct|. Vous constaterez que certains codes ne sont plus attribués. En effet, certaines fonctions arbo sont devenues obsolètes au fil des versions successives de STUT ONE.

UN EXEMPLE DE TRAITEMENT

Prenons par exemple une page arbo de fonction MENU (Fonction n°7). Elle est traitée par la procédure menu. Malgré les quelques commentaires très hermétiques (pour tout vous avouer, à une époque, j'ai du limiter au strict minimum les commentaires par manque de mémoire vive!)... malgré l'herméticité des commentaires donc, vous devriez réussir à distinguer quatre phases dans la gestion de la page menu. Ce sera sensiblement le même schéma pour les autres fonctions arbo.

Dans un premier temps, on extrait des paramètres de la page arbo, certaines données importantes telles que la position du champ de saisie sur la page. Toutes ces données sont disponibles dans un tableau de chaînes de caractères appelé parametre$(). Ce tableau est rempli lors du décodage de la page par la procédure serveur. Quant à l'ordre des paramètres dans le tableau, il n'est pas aléatoire mais presque! Il dépend en fait plus ou moins de l'ordre des champs de saisie dans les formulaires de saisie. Voyez pour cela les procédures d'édition...

Vous pourrez constater également que les noms de variables sont parfois on ne peut plus explicites, puisque du type g3, m8 ou encore l2. Ces lettres signifient en fait portée Globale, portée Moyenne et portée Locale. C'était une astuce pour économiser de la mémoire, puisque chaque variable de ce type pouvait être utilisées plusieurs fois pour des usages différents en divers endroits du programme. Bien sûr, c'est une source de bug difficilement égalable! La méthode propre aurait été d'utiliser des variables locales (instruction LOCAL) mais il s'est trouvé que l'utilisation de LOCAL produisait des bugs inadmissibles lors de la compilation avec les premières versions du GfA 3.00, 3.01 etc... Quand je vous disais que j'ai fini par succomber aux caprices du GfA... Mais maintenant que cela fonctionne, je vous conseille vivement de n'utiliser plus que des variables déclarées avec LOCAL.

Après les initialisations spécifiques à la page arbo, on trouve une boucle contenant trois étapes: l'affichage de la (ou des) page(s) vidéotex, la saisie d'une commande ou d'un mot clef puis le traitement de la saisie.

Le fait de gérer l'affichage de la page vidéotex dans la boucle peut vous sembler bizarre, mais cela est dû au système de pages interruptibles. En effet, si vous commencez à taper une commande au clavier pendant l'affichage de la page vidéotex, celle-ci va s'interrompre et le champ de saisie va s'afficher immédiatement. Si vous appuyez alors sur Annulation, la page vidéotex continue à être affichée là ou elle s'était arrêtée.

Notez que cette pratique est techniquement assez délicate. En effet, lorsque l'on reprend l'affichage de la page interrompue, on a entre-temps déplacé le curseur à l'écran, modifié la couleur d'écriture courante, etc... Reprendre l'affichage là où on s'était arrêté serait donc le meilleur moyen pour réaliser une superbe page vidéotex style Picasso à peu de frais. Pour éviter cet écart de style qui ne plairait sans doute pas à tout le monde, la procédure locate_ptr se charge de remonter en arrière dans les codes composant la page, à partir de la position courante, jusqu'à ce qu'elle trouve un endroit "sûr" pour continuer l'affichage. Un endroit "sûr" peut être un CLS (code 12), un HOME (code 30) ou un LOCATE (codes 31 yy xx).

La saisie d'une commande ou d'un mot clef est ensuite assurée par une procédure générique: get_command. Cette procédure est appelée par la grande majorité des fonctions arbo. Nous l'étudierons un peu plus en détails la prochaine fois.

get_command nous rend la main lorsqu'une touche de fonction (Sommaire, Suite, Retour, Guide, Envoi, etc...) a été pressée. Il est possible de passer en paramètres à get_command, les noms des pages arbo auxquelles il faut se rendre lors de l'appui à ces touches. Ceci explique la présence de la ligne:

EXIT IF LEN(page_a$)

En effet, si la variable page_a$ a été remplie par get_command, c'est qu'il faut quitter la page courante (donc la boucle) pour aller à une autre.

La procédure menu traite ensuite les cas plus délicats, par exemple, en ce qui concerne la touche Sommaire, on se rendra à une page arbo différente selon que l'appui était précédé de * ou non. (Notez que '*' est un exemple, le caractère "spécial" est configurable dans parametre$(2)).

Si aucune condition n'a mené à remplir la variable page_a$, c'est qu'on ne doit pas quitter la page courante; on affiche alors éventuellement un message "touche sans effet" et on boucle...

LOOP UNTIL LEN(page_a$)

ENCORE UN MOT

Voilà, après avoir fait le tour du propriétaire, vous devriez commencer à avoir une certaine idée de la manière dont fonctionne STUT ONE. Vous devriez même deviner comment fonctionnent les autres logiciels serveur d'après la manière dont on les utilise.

Conceptuellement, STUT ONE 2.6 est probablement assez bien architecturé (Si vous pensez le contraire, écrivez-moi!). Par contre, la méthode utilisée ne permet pas le multitâche/multivoies. Nous en reparlerons... Mais sans aller jusque là, vous avez déjà dû constater que dans la pratique, ce logiciel peut être grandement amélioré, ne serait-ce qu'en éliminant les "astuces" destinées à économiser la mémoire vive... si vous en avez assez!

J'attends donc vos réactions et je vous donnerais plus d'explications la prochaine fois. En attendant, vous pourrez probablement rencontrer d'autres personnes intéressées par le développement de STUT ONE version 2.6X sur le serveur dédié: (1) 00.00.29.45 code STUT.

Finalement, avant de nous quitter, il convient de dire un mot sur la licence d'utilisation du logiciel et de son code source.

LICENCE

STUT ONE 2.6X et son code source sont placé sous la "GNU General Public License". Cette licence garantit la plus grande liberté d'utilisation du logiciel à tous. Elle vous permet de l'utiliser, de le modifier et de le diffuser librement. MAIS ATTENTION: dans tous les cas, vous devez indiquer le logiciel original et les modifications que vous y avez apportées et VOUS DEVEZ FOURNIR LE CODE SOURCE de toute version du logiciel que vous diffusez, à qui vous le demande.

Cette licence, encore appelée GPL pour les intimes a été élaborée par la Free Software Foundation dans le but d'offrir la plus large diffusion possible aux logiciels placés sous cette licence. C'est notamment le cas de tous les outils GNU, y compris Emacs ou les compilateurs gcc et g++ également disponibles sur ATARI.

Vous trouverez sur Internet un certain nombre de logiciels placés sous la GPL, ce qui est toujours très intéressant dans la mesure ou vous avez accès au code source. Notez bien qu'un logiciel sous GPL n'est ni un domaine public, ni un freeware, ni un shareware. Le texte complet de la licence est fourni dans le fichier LICENSE.TXT.

Les Protocoles Réseau

[NDA: Article écrit en Mars 1995, publié dans ST Magazine n° 94 en Mai 95]

Lorsque je vous invitais, il y a un an déjà, à prendre le train de l'Internet en marche, je ne m'attendais pas moi même à un développement aussi rapide en France. Le nombre de prestataires de services grand public (World-Net, FranceNet, Pressimage...) augmente tous les mois alors que les prix se font de plus en plus abordables. Les entreprises françaises sont de plus en plus connectées et tout le monde en parle: Internet est en passe de faire partie de notre vie quotidienne au même titre que le Minitel. Minitel, qui au passage, prend un sérieux coup de vieux!

LE PROTOCOLE DU FUTUR

Bien sûr, le réseau Internet n'est pas le seul. En France, un autre grand réseau est Transpac. Et puis, il y a les réseaux privés comme celui de CompuServe et ce "Marvel" [NDA: nom de code de ce qui deviendra MSN, avant que MSN ne passe à l'Internet...] que Microsoft déploie actuellement sur le monde entier. Finalement il y a les réseaux locaux des entreprises, institutions et universités.

Tous ces réseaux ont la fâcheuse tendance à ne pas être compatibles entre eux. Il est impossible de relier directement l'un d'eux à un autre et de voir ainsi, une machine reliée au premier échanger des données avec une machine sur le second. La cause en est que le format des données et le protocole utilisé pour leur transmission est différent sur chaque réseau. Ce ne sont que quelques conventions, et pourtant chaque propriétaire de réseau se réserve jalousement l'exclusivité de son protocole... Bien évidemment, ça n'arrange rien à l'interconnexion de ces réseaux.

Pour palier au problème, on utilise des "gateways" entre les différents réseau. Ces machines traduisent les données dans un sens et dans l'autre. Les performances globales sont tout simplement affligeantes et la plupart du temps, les capacités de chaque réseau sont limitées par celles de l'autre.

Pourtant il existe une exception notoire: le protocole TCP/IP. Ce protocole peut être utilisé sur un réseau local (du plus simple reliant un ordinateur à une imprimante jusqu'au réseau d'entreprise à 5000 postes ou plus) mais également sur un réseau de grande envergure. De plus, ce protocole est libre d'utilisation, très bien documenté et livré en standard avec un certain nombre de machines en particulier tous les systèmes UNIX. Que demander de plus? C'est ainsi que des dizaines de milliers d'entreprises, d'universités et d'institutions sont équipées d'un réseau local fonctionnant sous TCP/IP. Et bien sûr, le protocole étant là pour ça, les universités et les institutions, suivies des entreprises ont relié leurs réseaux locaux entre eux. Depuis, le phénomène à fait boule de neige et l'agglomération de réseaux interconnectés à donné naissance à l'Internet.

Internet tire son nom de IP. En effet IP veut dire Internet Protocol. C'est grâce à IP que n'importe quel ordinateur dans le monde peut être identifié par une adresse unique. Chaque ordinateur peut ainsi échanger des données avec précisément n'importe quel autre ordinateur qui l'intéresse, pour peu qu'il soit relié au réseau.

Post complet »