CA2136921C - Procede de conversion automatique pour le portage d'applications de telecommunication du reseau pct/ip sur le reseau osi-co et module utilise dans ledit procede - Google Patents

Abstract

L'invention concerne un procédé de conversion d'adressage pour le portage d'uneapplication de télécommunication APP du réseau TCP/IP sur le réseau OSI-CO ainsi qu'un module de conversion d'adressage utilisé dans ce procédé. De manière connue, l'accès aux réseaux est autorisé par l'intermédiaire d'une interface "socket" (SOC) pour le réseau TCP/IP et d'une interface "XTI" pour le réseau OSI-CO. De manière remarquable les appels (SC) de l'interface "socket" sont, ainsi qu'une pluralité d'appels système (SY), dans un premier temps orientés, au moment de laphase d'édition de liens avant l'obtention de l'exécutable, vers un module (W) de conversion automatique d'adressage du genre librairie. Ce module (W) réalise alors la conversion des adresses propres au réseau TCP/IP en adresses du réseau OSI-CO et permet le passage du protocole TCP/IP vers le protocole OSI-CO. Après conversion les appels sont transmis vers l'interface "XTI" et peuvent êtredirectement exploités dans le réseau OSI-CO. Seuls les appels destinés au réseau TCP/IP sont traités, tout autre appel (NT) est renvoyé vers le système.

Description

36~21 Procédé de ~ ~' t - pour le portage d', ~12 '- - de du réseau TCP/IP ~ur le réseau OSI-CO et module utilisé
d~ns ledit procédé.
5 La présente invention concerne un procédé de Cvllv~ 0ll d'adressage pour le portage d'applications de ~.lf~.~,"~, cq~ion du réseau TCP/IP sur le réseau OSI-CO, I'accès aux dits réseaux étamt autorisé par 1';,.`. .".f.1;~: ~ d'une interA~ace dite "socket" pour le réseau TCP/IP et d'une interface dite "XTI" pour le réseauOSI-CO. Elle concerne également un module de conversion d'adressage utilisé
dans ledit procédé.
De manière génerale, bien qu'all~,;Cl le, I~ UI~:: TCP/IP (T"~
Control Protocol/Internet Protocol) est toujours répamdue sur un grand nombre dematériels ~ o IP se situe au niveau 3 du modèle OSI et assure 15 I'illlt; UUllllCi)~lU-- des réseaux et TCP co~ d au niveau 4 du modèle OSI et, offre de manière efficace un service de transport orienté ct)nn~.Yion Cependant les *~ 2llrg de réseau TCP/IP sont amenés à évoluer vers l'al~,LlLc~,lul~
d" ~ .A;rn OSI (Open System I...,~ ) p~ à des systèmes L~,t~,luo~llGs de ~ luuluuG~,kl et d'interagir ~v~ " en vue de la 20 réalisation d'~rFlir~*~ .f~ le rapide dév~lopp~mPnt du marché des réseaux locaux a entrâîné un retour important des lululuGOI~ TCPIIP
parfois au détriment des protocoles conformes à l'OSI. Pour ces di~i;l~l.4s raisons ces deux types de réseaux sont amenés à cohabiter et il est donc, dans certains cas, utile de pouvoir reprendre une ?rr1ir~*~n tournant dams um réseau TCP/IP et de la 25 faire tourner dans un réseau OSI-CO (orienté connexion).
Jusqu'à présent, de manière connue l'exploitation d'une application d'un monde àl'autre, c'est-à-dire d'un réseau TCP/IP à url réseau OSI-CO, présentait 1" - v~ d'être une opération lourde pour laquelle um temps import~nt devait 30 être consacré et donc ume opération g' ' re de coûts élevés. En effet pour qu'une application TCP/IP standard du genre FTP (File Transfer Protocol), Telnet(gestion de terminal virtuel), RPC (Remote Procedure Call) DCE (Distributed Computing E--vuu~.-l-."..) puisse être exploitée sur OSI, il fallait reprendre le code source, le mettre a jour ou le modifier, ~dcsc~ t; tous les appels, appeler les35 primitives et enfin refaire un adressage, et parce qu'une telle opération était particulièrement pénible et délicate elle était peu ou n'était pas utilisée.
La présente invention a pour but de remédier à l' vf,.ient p~écité et propose un .

procédé de conversion d'~ .s~g~ pour le portage d'applications de t~léc, ~ du réseau TCP/IP sur le réscau OSI-CO qui ne requiert pas de modification du code source, qui opère de manière Alltnn~q~iqllP la conversion et qui par c~ est peu onéreux et rapide.
5 Pour cela, le procédé de CU~ ;UII d~h~ s~ mPntionnP dans le lu~ lbldc est UdlL~le en ce que les appels de l'interface dite "socket" sont, ainsi qu'une pluralité d'appels système du genre lecture, éc~iture, fermeture, dans um premier temps orientés, au moment de la phase d'édition de liens avant l'obtention de '.Ar~ , vers un module de CUIIVt;l~;UII qlltnm~h~ P d'adressage du gerlre librairie réalisamt la conversion des adresses propres au réseau TCP/IP en adresses du réseau OSI-CO et p~ ~ll Ie passage du protocole TCP/IP vers le protocole OSI-CO, puis après conversion les appels sont transmis vers l'interface dite "XTI"
pour être alors dil~ Cllll~lll exploités dans le réseau OSI-CO, seuls les appelsdestinés au réseau TCP/IP étant traités, tout autre appel étant renvoyé vers le système.
Ainsi, grâce à l'mvention une qrrli~hnn tournant dans le monde TCP/IP pourra être également exploitée dans le monde OSI et ceci sams intervenir ou modifier le code source, ce qui est um énorme avantage pour les llhlie~tPllre dont les 20 d~v~lv~u~ restent jriPnhi-lllPe 11 suffit pour cela d'ajouter le module de conversion d'adressage qui sera utilisé juste au moment de la phase d'édition deliens (c'est-à-dire à la dernière étape de ~lu-lu~,liu~ de 1'~ c), à la fois du côté "client" et du côté "serveur" pour respecter la symétrie des ,u~ulo~-' et des adresses. Par cn~ en UIC~I~ul~lll un module de C~IIV~l~;ull du 25 type librairie CU,,.,.I,U,,~I à un ensemble de fonctions, qui est d'un faible coût, I'utilisateur peut exploiter son application ~lltn~s~iqllPmPnt dans un autre monde de t~.lé~l "nn Deux ~ Ir~ majeurs sont opérés. Un premier c'--~,, concerne 30 I'interface, les appels sont déroutés, au moment de la phase d'édition de liens, de l'interface "socket" (fonctions points de ~ - ( ) vers l'interface "XTI"
(X/OPEN Transport Interface ) via le module de . ~ ;Vll d'aL~ qui convertit les adresses. Le second ~ i - c,~,,., ..~ qui est opéré eimlll~snPmPntconcerne le protocole: passage du protocole TCP/IP au protocole OSI-CO. Seuls 35 sont convertis et traités les appels de l'interface "socket" ainsi que les appels système ("read", "write", "close",...) destinés au réseau TCP/IP, les autres appels ne sont pas convertis et sont renvoyés vers le système (par exemple un appel cnnrPrnsnt um ordre de lecture sur um fichier qui n'est pas du réseau TCP/IP). Une - ~36g~

fois convertis, les appels sont utilisés dans le monde OSI par l'intrrmP~ ire del'interface "XTI". Le module de conversion est donc ume librairie dont les JiIrrl~ - entrées reçoivent les divers appels qui doivent être convertis et traités.
Pour préciser, prenons par exemple rappel de fonction "socket", ce dernier réserve s un dFS' .. ;lllrlll de fichier et subit une vPrifir~tio~, si cet appel est bien destiné au réseau TCP/IP, c'est-à-dire cu,l~ d au mode ~ (par exemple type SOCK STREAM et farnille AF_INET) il est converti et l~a comnexion dans le monde OSI est réalisée, siuon il est redirigé vers la librairie TCP standard.
La description suivante en regard des dessins annexés, le tout domné à titre d'exemple non lirAitatif, fera bien comprendre comment l'iuvention peut être réalisée.
La figure I représente srhPn~ti-lllrn - le module de conversion d'adressage et son Cllvill ' ' ainsi que le trajet emprunté par les appels de l'mterface "socket" et les appels système considérés.
La figure 2 propose un exemple de réalisation du module de Cwlv~;lv;-;)dl&dl.,Dj~ selon l'invention.
20 La figure 3 présente un exemple de séquence de fonctions de transport en modeorienté ~ ~ n, utilisées d'une part figure 3.a, sur l'interface dite "Socket", et d'autre part, fgure 3.b sur l'iuterface dite "XTI".
La figure 4 représente uue table de CUII~ ' entre les appels de fonction de ~s l'interface dite "socket" et l'interface dite "XTI".
Sur la figure I est l~ le module de cull~ d'~d.~ W selon l'invention dans son CllVil~ Le module W est une librairie qui est construite à l'instar d'une imterface dont le premier objet est de recevoir, par30 1' ' ' '- ~; de l'Prrlir~ n APP du réseau TCP/IP, les appels SC de l'interface "socket" SOC ainsi que les appels système SY du geme lectrlre ("read"), écriture("~vrite"), fermeture ("close"), etc..., qui I r 1 ' des ~Fc..;l,t....~ de ficbiers et qui sont s ~(fl~ ! c de manipuler un ~ de ficbier "socket". Ces différents appels SC+SY sont ainsi déroutés vers le module W, au moment de la 35 phase d'édition de liens avant l'obtention de l'~ Le second objet du module W consiste à convertir de manière I ~,~ "qllF les adresses propres au réseau TCP/IP en des adresses du réseau OSI-CO et à permettre le passage du protocole TCP/IP vers le protocole OSI-CO. Après Cull~,lv;v~, les appels SC+SY

- ~13~21 destinés au réseau TCP/IP sont translnis vers l'interface "XTI" pour être dilC~t~ exploités dans le réseau OSI-CO, c'est le troisième objet du module W.
Tout appel NT qui n'est pas destiné au réseau TCP/IP, c'est-à-dire dont les arguments ne sont pas crérifil, de l'interface "socket", est renvoyé vers le 5 système à la librairie TCP standard. Les appels SC+SY reçus par l'interface "XTI"
sont ensuite transmis vers la pile du réseau OSI-CO puis vers les réseaux locauxOSI-LAN (dont le système de ~ ;..., a une al4L-t~ c en bus ou en boucle) ou vers les réseaux étendus OSI-WAN. Les c~ - - ;nng sont toujours établies pour des systèmes --l4l~.ollllc41c~ à même niveau, les couches de transfert les adresses des différentes ~onnP~ion~
Le module W fournit donc le moyen, pour des ~rrli~tione "orientées connrYion"
r-....~;--...-~--l sur un réseau TCP/IP, de fnT~rtlonnPr de manière directe et 1 ~ sur um réseau OSI-CO. Le module W conçu comme une librairie fournit une syntaxe et une s~m~ntiTI~o propres à des appels de l'interface "socket", les mêmes syntaxe et s~ ' cs pour gérer des c~ n~lnirotion~ entre "client" et "serveur" selon le protocole TCP/IP mais utilisés ici selon un protocole OSI-CO pour accéder à un réseau OSI-CO.
20 De manière ~ et ~ , Iorsque l'appel de l'interface "socket" est destiné au réseau TCP/IP, c'est-à-dire GU~,~u~ld à um mode ~,-cd~; (type SOCK_STREAM et famille AF_INET), il est créé une ressource propre en mémoire pour conserver la trace de la c~nnF-Yion, I'mterface "XTI" est alors appelée pour l'ouverture de ladite conn(~yinn~ I'ensemble étant géré au moyen d'um 2s arbre binaire de recherche. En effet, lorsque le nombre d'appels est iIII~JUI' t, ce qui est en gcnéMl le cas, il est difficile de retrouver rs~p~ nnPnt les inforn~qiinn~
propres aux ~O~ du module W s'il est utilisé une liste châînée, aussi pour accélerer le processus il est utilisé um arbre binaire de recherche. De manière résumée et dans ces cn~ inng, I'appel de la fonction "socket" ouvre url ~ s~
30 de fichier puis rend ce ~IF$~;Illrl~ de fichier, et lorsque cet appel est reconnu destiné au réseau TCP/IP (Irc~ 4 du mode adéquat), au moment de rouverture de la connexion sont donnés les po,alll~L.4. du ;~F.C. ` ;I-t~ ~ de fichier qui a été rendu à l'interface "socket" et la recherche de l'~vi u~ de cette connexion peut être réalisée au moyen de l'arbre binaire de recherche à partir de ce 35 IFC..;II~ .. de fichier pour aboutir à la connexion au réseau OSI-CO avec des ra OSl. En outre, ~ I'a4~ressage (qui est ~
I~.k.li~,ll.~,..L à l'qrrlir~h( ) il suffit que soit générée, par exemple par l'q ' - du système, une table de conveFsion des adresses pour autoriser la ~13692L

conversion des adresses OSI (NSAP: Network Service Access Point) en adresses TCP/IP (Internet) et vice-versa. Par c ~J t, I'utilisation d'un arbre binaire derecherche permet d'optimiser la recherche par l" ~l ~ d'une structure de séquences ordonnées à partir des ;..~ .c destinées à l'interface "socket". De 5 plus, le port ("socket") est 1~ en sélecteur de transport (TSEL) et vice-versa.
Sur la figure 2 est proposé un exemple de réalisation du module de conversion W
selon l'invention.

Le module W est con,cu sous la forme d'une librairie qui assure le service d'interface entre l'~rp]ir:-ti~ APP prévue pour être exploitée dans un réseau TCP/lP et les couches de . nn OSI (réseau OSI) par l'i ~ li~t; de l'interface XTI, la première couche de c, - on accédée étant la couche de transport OSI, I'~rp~ s~inn APP pouvant être alors exploitée de manière , sans mr~ifi-~ du code source dans le réseau OSI-CO. Pour ladite JliCdliull APP, tout se passe comme si elle continuait de dialoguer au travers du protocole TCP/IP.
20 Sur la figure 2, de manière ~ u~l~, le module de conversion ~ t~mqtjqll~
d'~ 7a~; W est I l 1 constitué d'un premier sous-module LIB formamt la librairie principale et contenant la table de Cull~ ' MT entre les fonctions de c~ tion TCP/IP et les fonctions de cullv~ incluses dans l'intelface d'entrée IW du module W, d'um second sous-module AM de service de 25 C~ 17iull d'adresses IP et OSI, d'un troisième sous-module SBT d'tlu~;i7~ t des inf~-rmq~ n~ de conrlexion gérant lesdites inform~tlonc au moyen d'um arbre binaire de recherche et d'un quattième sous-module KE de service pour l'Plq~ rq~l d'un ensemble spécifique d'~At~ ;ull7 au système.
30 Le premier sous-module LIB comporte donc la table ou plan de Cull~ uulldduCC-MT entre les fonctions de c~ - -nn utilisées dans um réseau TCP/IP et les fonctions de Cullv~17;ull intégrées d;ms l'interface d'entrée IW du module W. Latable MT fournit a~ ' ,, ' une correspondance bijective, telle qu'à toute fonctionde - c~ti~-n TCP/IP parl'i..~ P.~ ; du Il~ des "sockets"
3~ (décrit dans, "UNIX N~lwulh~.o Pl~,~,~ ..l..;..~" - de Richard W. STEVENS chez Prentice Hall), il existe ume fonction et une seule dans l'interface IW qui exécute le service (ou la requête) demandé par l'application APP, le nom des appels, le nombre des arguments de ~ d'un appel, la 7~ .. et 1~.. ,.. 1.,.,.,.. .. l

2~3~921 des appels étant ~t ~ rlll conservés De mamiere préférée, le second sous-module ~M de service de conversion d'adresses forme également une librairie et effectue la conversion entre d'ume part 5 les adresses IP Cu.l.~ .l l'adresse réseau de la machine concernée et le port relatif au service accédé et d'autre part les adresses OSI CfJIII~)OI 1~I~ le point d'accès de service du réseau (NSAP) et le selecteur de transport (TSEL), ladite Cullv~lai~
pouvant être effectuée dans les deux sens, adresses IP vers adresses OSI ou adresses OSI vers adresses IP.
I~) De manière également préférée, le troisième sous-module SBT d'~ ~ia~
des inforrnqtinng de conneAion gérées par un arbre binaire de recherche fournit un service in~l~rrn/' (disporLible comrne une boite noire) sous la forme d'une librairie p, d'~ t~ia~ l, trier, rechercher et supprimer de façon optimale tous les éléments d' ~ f~n gipnifiro~ifg relatifs à ume connexion dommée.
Enfin le quatrième sous~ llP de service permet d'élaborer un ensemble spécifique d'~ - au système pour rediriger et renvoyer, dans le cadre du - des "sockets" et par l';~.lr... i~l;-;.c; du noyau système, les appels de 20 t:l~c~........ : -';onc non destmés au reseau TCP/IP et qui ne sont donc pas convertis par le module de conversion, vers la librairie TCP standard.
Ce quatrième sous-module autorise ainsi la plus parfaite portabilité de l'application APP. En effet, lorsque des appels sont détectés non destinés au réseau TCP/IP ne25 ~O~ JOL~d~I~ pas au tvpe SOCK STREAM et à la famille AF_INET, ils ne doivent pas être pas être traités et donc convertis par le module W, aussi ils sont redirigés vers le système par le biais d'~,AIti1sio11s au noyau du système qui p~......... It~ .. I de rappeler la librairie TCP St~ndard.
30 Le I général est le suivant. L'a~ ... APP transmet un app~l au module W chaque fois qu'un des appels de fonction suivants est lancé:
- "socket", qui crée une extrémité de connexion pour une c~.. ,.:.. -~;on,- "bmd" qui affecte un nom pour référencer l'extrémité de c, f)n de la ~ ~n "3~ ~afJ~ L"~ of L~l,I" qui SPl~ctil-nnP/lit des options sur une extrémité
de . f~n de la ~.. ".. ;. ~ n, - "~Ptso~L-~q~ P" qui lit l'adresse courante pour une extrémité de C~nnP~ n ~13~92 1 spécifiée, - "listen" qui spécifie le nombre de c~nn~ n~ entrantes possibles - "connect" qui émet une requête pour ume connexion vers une extrémité de conn~ r~ locale, - "accept" qui attend et accepte une connexion entramte, - "send" qui transmet un message entre extrémités de connexion de même niveau, - "recv" qui lit un message transmis d'une extrémité de connexion éloignée o vers une extrémité de connexion locale, - i'shutdown" qui ferme partiellement une connexion bidir~ionnrll(~ (full-duplex).
Cependant comme il n'y a pas bijection entre les appels de l'interface "socket" et 15 les fonctions de l'interface XTI, il est nécessaire de trouver un moyen pour les faire cvll~,~ullJlti. Pour cela quatre phases de c. -ln sont p~,U~ S, une première 1'; ;~;AI;-";Il /".l~.:.;~;,,li-~;.."" des extrémités de connPYion pour la "~m, une seconde pour l'~ de la c~ Yion, une troisième pour la i des données et une quatrième pour la ~ n Sur la figure 3 est proposé um exemple de séquence de fDnctions de transport en mode orienté . t-n, utilisées d'ume part figure 3.a, sur l'interface "socket" etd'autre part figure 3.b, sur l'interface XTI de manière à comparer et préciser les deux --'- Les . sont decrits et comparés en parallèle fonction 25 par fonction dans les quatre phases de . nn plé~ .-1 citées.
Sur la figure 3.a, les flèches en trait plein sont Ic;~ lLlives d'un processus "client" alors que les flèches en trait pointillé le sont d'un processus "serveur".
30 Sur la figure 3.b, les flèches en trait plein sont I~ DI.~llt~ti'V~ d'un processus "utilisateur actif", alors que les flèches en trait pointillé le sont d'url ", ' passif".
Les figures 3a et 3b, seront lues, pour une meilleure ap~ n, en c~----l-i"-;~.---35 avec la figure 4 sur laquelle est ~ '~ une table de co~ ,ulld~lce entre lesappels de l'interface dit "socket" (côté "client") et l'interface dite "XTI" (côté"serveur"). Lorsque des appels de l'interface dite "socket" n'ont pas de ' sur l'interface "XTI", des routines d'interface spécifiques sont a utilisées, ces routines sont ~ ,S~ ,a par la lettre (R) sur la figule 4.
Ainsi dans la première phase d' ' ~n/''~lf~cinitiqlic~tion''~ au tout début l'état norl initialisé est appelé T_UNlNIT.

Lo}s d'un appel de fonction "socket" de l'interface "socket", une extrémité de connexion pour la ~ on est créée alors qu'est fourrli un i~if~ntifir:ltf .lr de transport. Pour cela, I'appel de l'interface "socket" (conforme à la famille AF_lNET) contient le domaine spécifié (par exemple Internet), le type spécifié
(par exemple type SOCK_STREAM), le protocole spécifié (par exemple TCP).
Les valeurs de retour de l'appel "socket" sont, soit un nombre entier équivalent au ~f cr.rjrtf llr de fichier, soit (-1) lorsqu'il est constaté une erreur.
La fonction COIl~,a~ ' ' en mode XTI-CO est "t_open", elle permet d'établir une extrémité de connexion d'une part en r., ,. ,.;~- --.1 un i iPntifi~.~qtf-~lr de transport qui indique un protocole particulier de transport et d'autre ~art en l~,tU ll~ull un l`if C. ,~ . de fichier qui identifie une extrémité de c~nnf ~don C'est la première étape de r ~ tilm d'une extrémité de connexion de transport (état T_UNINIT
vers état T_UNBND extrémité de commexion non attachée à ume adresse). Cette 20 fonction contient le nom spécifié, um drapeau spécifié et la structure de l'inforn~qti~-n fournie. Les valeurs de retour sont, soit le df.~ ;lt...~ de fichier concerné, soit la valeur (-1) er~ cas d'erreur.
Le df~,Ji~ de fichier retourné par la fonction "t open" sera utilisé pour tout 2s appel - ~ pour identifier cette extrémité de cu Iocale particulière.
Et, de manière à suivre 1' extrémité de connexion pour la c~mmlmi~tir,n à travers la séquence d'appels de fonctions de transport, chaque i- ~ ;l de fichier créésera stocké dans un arbre bmaire de recherche. Cette structure contiendra également d'autres inft~rn~tl~mc telles que l'adresse du réseau, le numéro du port 30 TCP qui identifie le service requis ainsi que tout autre élément d'illr~ ion nécessaire.
Un appel de fonction "bind" permet d'associer un appel "socket" à une adresse affectée en reliant une adresse à une extrémité de connexion de transport. L'appel 35 "bmd" (conforme à la famille AF_INET) contient le retour de l'appel "socket"
spécifié (domaine, type, protocole), le nom de l'adresse spécifiée, la taille del'adresse. Les valeurs de retour de l'appel "bind" sont, soit (0) si l'appel a abouti, soit (-1) en cas d'erreur.

~136921 La fonction corrPsron~l en mode XTI-CO est "t bind". C'est la seconde ~tape dans l';~ d'une extrémité de connexion de transport (état T_UNBND vers état T_IDLE, état non connecté mais déjà attaché à urle adresse). Elle permet d'une 5 part d'associer une adresse de protocole à l'extrémité de connexion de transport spécifiée par le dP~ de fichicr et d'autre part d'activer cette extrémité de c--nnP-~ion de transport. Elle contient l'extrémité de cormexion de transport spécifiée (~1f~ r ~1 de fichier), I'adresse de protocole spécifiée. Les valeurs de retour sont, soit (O) si l'appel a abouti, soit (-1) en cas d'erreur.

Un appel de fonction "s~ ocLu~" permet de sPlPctif~nnpr des options pour l'appel"socket" en gérant les options pour une extrémité de connexion de transport.
L'appel "s~ u~ L ~ 1~1" (conforme à la famille A~_INET) contient le retour de l'appel "socket" spécifé (domaine, type, protocole), le niveau spécifié, le nom de l'option spécifié, la valeur d'accès de l'option et la taille de l'option. Les valeurs de retour de l'appel "~ o-.L~ " sont, soit (O) si l'appel a abouti, soit (-1) en cas d'erreur.
Chaque option est émulée iU '~ ~ des autres lorsque ladite émulation est possible. Différentes options peuvent être de la sorte ~ , les l~
20 COIl~r~ll 11 parexemple:
- la mise au point (SO_DF.BUG), - le maintien actif (SO KEEPALIVE), - la r~l-ti~ ion d'une adresse (SO_REUSEADDR), - la fermeture différée si des données sont en attente d'émission (SO_LINGER), - I'f~ lrlll de la taille requise du tampon en réception (SO_RCVBUF~, de la taille requise du tampon en émission (SO_SNDBUF), - la réception des données express dans le flot de donmées normales (SO OOBINLINE).
Toute autre option peut être bien entendu S~1P~ .... F
Un appel de fonction "~r~o- L -~Il" permet d'accéder aux options pour l'appel "socket" et de retrouver des options sélectionnées pour une extrémité de connexion donnée. L'appel 'I~,rl~o L~-Iul'' (conforme à la famille AF_INET) contient le retour 21'~fi~21 de l'appel "socket" spécifié (domaine, type, protocole), le niveau spécifié, le nom de l'option spécifié, la valeur d'accès de l'option et la taille de l'option. Les valeurs de retour de l'appel l'~rlYocl-~,ul" sont, soit (0) si l'appel a abouti, soit (-1) en cas d'erreur.
5 Pour émuler ume lecture d'options d'appel "socket", une recherche du dc~ u~ul de fichier propre à cet appel "socket" est exécutée en utilisant l'arbre binaire derecherche. Puis les options specifiées sont extraites de la structure d'i~r~ a~ions désignée par le numéro du ~1F S~ de fichier. de l'appel "socket".
o Un appel de fonction ll~Pts- ' -" permet d'accéder au nom courant d'un appel "socket" et de retrouver, pour une extrémité de connexion de transport donnée, le pomt d'accès service du réseau ~SAP) et le sélecteur de transport (TSEL). L'appel "~Ptso~knq~ " (conforme à la famille AF_INET) contient le retour de l'appel "socket" spéciflé (domaine, type, protocole), le nom de l'appel spécifié et la taille 5 du nom de l'appel spécifié. Les valeurs de retour de l'appel "~rl ,~L, - "F-~ sont, soit (0) si l'appel a abouti, soit (-1) en cas d'erreur.
Une table structurée, organisée à l'mstar d'un arbre binaire de recherche, est consultée pour extraire l'adresse Internet et le port INET cu-..,~" ' au 20 ~1P~. . illlr~ll indiqué. Le numéro du port et l'adresse Internet sont toujours retournés.
Un appel de fonction "listen", permet à un "serveul" de spécifier le nombre de C~lllll ~;1~ r entrantes possibles ltsn~ q~ sur une entrée ' ', le "serveur"
signifiant son acceptation des requêtes des c~nnq~ n~ entrantes sur une extrémité
25 de connexion de transport donnée (en spécifiant les limites C.l. F .-~ la file d'attente pour les c~nnP~ n~ en attente d'qq~cPptqtion). L'appel "listen" (conforme à
la famille AF_~ET) contient le retour de l'appel "socket" spécifié (domaine, type, protocole) et la taille de la file d'attente spécifiée (la longueur maximum de cette file d'attente de c~nnP~i - en attente d'~çc~qptsti~n). 11 est à l~""a.~uel que les 30 entrées (ou ports) de l'interface "socket" non reliées seront '~ "IA ' ' reliées par le système. Dans ce cas, le nom et le numéro de port peuvent etre retrouvés en utilisant la fonction ll,~r~ ~O. 1.1' --lIF-II, Les valeurs de retour de l'appel "listen" sont, soit (0) si l'appel a abouti, soit (-1) en cas d'erre~r.

3~ Les fonctions Cullc:~,u~ à la fonction "listen" en mode xrl-(~o sont "t_unbind" et "t bind".La fonct=ion t_urlbind" est d'abord exécutée, c'est la troisième étape dans l~ A~ ;UII d'one extrémité de connexion de transport (état T_IDLE vers état T_UNBND). La fonction "t unbind" permet de désactiver - 2~g~
-l'extrérnité de cnnnPRi~n de transport qui avait été ~U~ reliée par 1';,.~ .". ~ de la fonction "t_bind". Elle contient 1' extrémité de connPYi~1n de transport spécifiée (dcs~ u. de fichier). Les valeurs de retour sont, soit la valeur (O) si l'appel a abouti, soit la valeur (-1) en cas d'erreur.
s La fonction "t_bind" est ensuite exécutée, c'est alors la dernière étape dams l~init~ c~ti~n d'une extrémité de connexion de transport (état T_UNBND vers étatT_IDLE). La fonction "t_bind" permet d'assurer la liaison ~lltnm~tiqllP et a~ uF d'un ~IfC~ . de fichier non relié. Elle contient l'extrémité de connexion de transport spécifiée (~1FC~ rlll de fichier) et l'adresse de protocole spécifiée. n est précisé également le nombre de connPRiong ~ ,lPF~ qu'il est permis de supporter pour l'extrémité de connexion de transport donnée. Les valeurs sont, soit la valeur (O) si l'appel a abouti, soit la valeur (-1) en cas d'erreur.
Si le 11F~ de fichier n'est pas trouvé dans la structure de recherche, I'appel 5 est redirigé vers la librairie TCP standard. Sinon, par principe, I'extrémité de de transport est sy~tPmqtiq~lPmPnt déliée, de manière à prendre en compte le nombre maximum de cnnnPcti~ en attente ~lltnri~éPC Cpppn~ t il peut se trouver que l'extrémité de connexion de transport ne possède pas d'adresse de liaison, dans ce cas cette extrémité est laissée non reliée.

En outre, une nouvelle liaison doit être exécutée en tenant compte du nombre de cnm~^Yi( - requis par le "serveur" (le nombre maximal de cnnnp~ilmc est négocié
en c~ 1r- h--l le nombre de c~ . ~ ;1l'`~ qu'il est possible de supporter).
25 Pour résumer cette phase d';";l ~ lf~ ;nn~, la création est réalisée au moyen de la fonction "socket", la liaison à ume adresse au moyen de la fonction "bind" et la sélection du nombre maximum de . ~m~ entrantes ("serveur") au moyen de la fonction "listen".
30 Dans la seconde phase dite d'.'l ~ . " ~ "l de la ~ ~n l~appel de fonction "cormect" est utilisé pour obtenir du "serveur" une connexion en p ...- li- l à um utilisateur du tramsport de demander une comnexion à une extrémité de connPRi~m de transport .1,~1 ~. L'appel "connect" (conforme à la famille AF_INET) contient, le retour de l'appel "socket" local spécifié (domaine, type, protocole), le 35 nom de l'adresse spécifiée et la taille de l'adresse spécifiée. Comme pour l'appel de fonction "listen", le système I , s~1Pctil - et relie l'adresse locale au port concemé si cette demière n'est pas reliée (I'adresse rest~mt reliée quoiqu'il arrive). Les valeurs de retour de la fonction "connect" sont~ soit la valeur (O) -lorsque l'appel a abouti, soit la valeur (- I) en cas d'erreur.
Les fonctions C~ ' ' à la fonction "connect" en mode XTI-CO sont "t bind" et "t_connect". La fonction "t_bind" est d'abord exécutée, c'est la première 5 étape d'~ de la connexion d'ume extrémlté de conneYion de transport (état T_UNBND vers état T_IDLE). La fonction "t_bind" permet de relier une adresse à un ~IP~ rl~ de fichier si celui-ci est trouvé non relié. Elle contientl'extrémité de connexion de transport spécifiée (dcs~ Jt~.,l de fichier), I'adresse de protocole spécifiée. Les valeurs de retour sont, soit la valeur (0) si l'appel a abouti, soit la valeur (-1) en cas d'erreur.
La fonction "t_connect" est ensuite exécutée, c'est la seconde étape d'établis~c.~
de la cn~ yjl~n d'une extrémité de connexion de transport (état T_IDLE vers étatT_OUTCON (en phase de connexion sortante) ou vers état T_DATAXFER (en 15 mode connecté, transfert des données) si le ~node est synchrone). La fonction"t connect" permet de demander une connexion vers une extrémite de connexion de transport distante. Elle contient 1' extrémité de cnnnPYin~ de transport spécifiée de fichier pour rouverture d'une extrémité de cnnnPYinn de transport locale où la ~( ~ sera établie), I'adresse de protocole spécifiée (pour 20 indiquerl';.-r.-", ~ nécessaireà1'~ .- .1delacnnnPYionetl'information qui est associée à la nouvelle connexion à établir). Les valeurs de retou~ sont~ ]a valeur (0) si l'appel a abouti, ou la valeur (-1) en cas d'erreur. Il est à noter que l'utilisateur peut, dans le présent cas, définir différentes options, il peut également choisir de ne pas négocier les options en s~ une taille d'option égale à
25 zéro.
Si le ~ de fichier du "client" n'est pas trouvé dans l'arbre binaire derecherche, I'appel est redirigé vers le noyau. Les autres erreurs sont traitées en utilisamt une procédure de I~C~ d'erreurs vérifiant la validité de chaque 30 argument (type, valeur, etc..), les erreurs crérifiqll~e étant gérées par ladite fonction en mode XTI-CO.
Ensuite, I'état de la connexion est ?~ltnmo~iq~PmPnt vérifié par l'interface "XTI"
lors d'un appel de fonction "t_connect". L'état T_lDLE est f 'lPn Pnt exigé, tout 35 autre état entraîne l'émission d'une erreur indiquant que la fonction a été émise lors d'ume séquence erronée.
Les infr~rm~inne utilisées pour spécifier un paramètre d'emission d'appel sont ~13~g21 d~ llc;lll retrouvées à partir du nom et de la taille du nom de l'appel de fonction "connect". En particulier, le nom contient le port du service distant et l'adresse de l'hote distant (le ~ c. .. ;~t de fichier est la seule référence locale).
Le format d'adresse de l'interface "socket" est converti en une adresse requise par l'interface XTI. Dans tous les cas où cela est nécessaire, le point d'acces se~vice de réseau (NSAP) local sera retrouvé en consultant dans le fichier de CU~V~:IaiOII
d'adresses, I'adresse CUll~,a~ ' de la machine du réseau OSI. L'adresse du protocole OSI sera générée en cn~ l'adresse de l'hôte distant et le sélecteur distant, suivant la structure OSI des adresses requises par l'interface XTI. Il y a accès à l'adresse distante, qui a été liée à l'extrémité de connexion de transport distante, par le "serveur". L'adresse de protocole qui est associée à lIt:AII~IIfilé de cnnnPYinn de transport de l'utilisateur passif est retournée. En outre, si la valeur du sélecteur de transport (TSEL) distant fournie par le "serveur" pour réaliser la cnnnP~ion est différente de la valeur requise par le client, une erreur est émise.
.

A ce stade, c'est-à-dire au moment où le "serveur" accepte la requête de CûnnP~ n auclme donnée n'est encore reçue.
Un appel de fonction "accept" est utilisé par le "serveur" pour attendre et accepter ume c~ Plrion d'um "client" sur ume entrée de l'interface "socket" repérée en attente de réception. Le "selveur" extrait la première connexion de la file d'attente et crée ume nouvelle entrée "socket" (si la longueur de la file d'attente est supérieure à 1), I'appel est bloqué jusqu'à ce que la comnexion soit établie à moins que cet appel soit repéré comme non-bloquant. L'appel "accept" (conforme à la famille AF_INET) contient, le retour de l'appel "socket" local spécifié (domaine, type, protocole), le nom de l'adresse spécifiée (I'argument adresse est um paramètre de retour qui est rempli avec l'adresse de l'entité "client" se G~.... F~.~n~l) et la taille de l'adresse spécifiée. Il est à remarquer que la séquence d'~ .b est identique à
celles des appels "bind", "~PtsorkT~P" et "commect", mais l'~ ..; adresse est un argument de sortie. En outre, si aucune connexion en attente n'est présente d~ms la file d'attente et que l'appel est repéré bloquant, I'appel "accept" bloque le.i -- 1~." jusqu~à ce qu'une connexion soit présente. Si l'appel est repéré non-bloquant et qu'aucune comnexion n'est présente sur la file d'attente, I'appel "accept"
retourne une erreur. Les valeurs de retour sont, I'adresse du client, la taille réelle de l'adresse retournée avec les mêmes propriétés d'~ "socket" mcluant les ports reliés et le ~'-~ . de fichier d'une nouvelle entrée "socket" si l'appel aabouti, smon la valeur (-1) en cas d'erreur.

.

Les fonctions c~"r~ à la fonction "accept" en mode XTI-CO sont "t_listen", "t_open", "t_bind" et "t_accept". La fonction "t_listen" est d'abordexécutée, ce qui c~"l. r ~ à l'étape du passage de l'état T_IDLE à l'état 5 T_INCON (attente de connexion entrante). La fonction "t_listen" permet d'attendre en vue d'accepter une requête de connexion venant d'un utilisatellr de transport.
Elle contient 1' extrémité de connexion de transport spéficiée (des~,-il,L~... de fichier) identifiant l'extrémité de connexion de transport distante où arrivent les AAhr~llC de connexion émises par l'utilisateur actif. Elle contient également I'adresse de protocole spécifiée pour récupérer l'information qui est associée à la connexion nouvellement établie. La taille maximum de l'adresse, des options et des données doit être sPlP~Ahr~ e avant l'émission de l'appel "t_listen" pour indiquer la taille maximum de chaque tarnpon. Les valeurs de retour sont, soit la valeur (0) si l'appel a abouti, soit la valeur (-1) en cas d'erreur. Il est à noter que l'utilisateur peut 15 mettre en attente une pluralité d'in~liroiionc de connexion avant de répondre à rurle d'entre elles.
La fonction "t open" est ensuite exécutée darls le cas du passage de l'état T_UNINIT vers l'état T_UNBND pour créer un nouveau ~' , de fichier de ~0 C ` A h ~ ~n La fonction "t_bind" est alors exécutée pour référencer l'adresse du nouveau l~F~ r." de fichier de c, Iors du passage de l'état T_UNBND ve}s l'état T_IDLE (avec la même adresse de protocole et avec une longueur nulle de 2s file d'attente).
La fonction "t accept" est enfin exécutée, c'est la dernière étape de la phase d'Pt~l-liccPmPnt de la connexion (état T_INCON vers état T DATAXFER). La fonction "t_accept" est émise par un utilisateur de transport passif pour accepter 30 ume requête de connexion venant d'un utilisateur actif identifié. Elle contient l'extrémité de commexion de transport du service spécifiée (~ir c. .. ;~t -- de fichier du "serveur") qui identifie l'extrémité de connexion de transport distante où les inrlirA~i~mc de connexion sont prélevées par l'utilisateur passif. Elle contient aussi le nouveau ~ t~-- de fichier de c~ ~ qui spécifie l'extrémité de 35 Cr ^Yir)t~ de transport locale différente où le transfert de données doit être établi.
Elle contient enfin l'adresse de protocole spéciféee pour préciser l~;~lr~ ;r~l~demandée par le 1`..~ . de transport pour achever la connexion nouvellement établie. Les valeurs de retour sont, soit la valeur (0) lorsque l'appel a abouti, soit la 211 3~92~
valeur (-1) en cas d'erreur.
r.. ~ .r~ 1.. de la procédure usuelle relative à la vérification du rlf 5- 1 il,t~ , de fichier, avant de générer un C~ "t-listen", I'état de çr)nnl~Yil du de~ u-5 de fichier du "serveur" est vérifié. L'état T_IDLE est alors absolurnent requis, sinon une erreur apparâît indiquant que la fonction a été émise lors d'une séquence erronée.
Avant de générer un ~VCIIC;III(.II- "t_accept", I'état de connexion de l'extrémité locale o n'est pas vérifié.
Dans le cas d'ume extrémité de connexion du côté "serveur", la fonction "t_accept"
ne peut aboutir et impose la valeur ((-~), eneur) lorsqu'il eYiste des irl~lir~tinnc (de C- on OU de dr~c~nnPYi~m) attendant d'être reçues sur cette extrémité de 15 ~ on particulière.
En retour d'um appel "t accept", comme l'argument adresse est un paramètre résultat de l'appel "t_accept", il est rempli avec l'adresse de l'entité distante à
connecter. Ensuite cette adresse est associée au ,1.~.1 il't' de fichier. De même, la 20 taille de l'adresse est également un paramètre résultat de l'appel "t_accept", cette dernière contient init~ mrnt la taille de l'espace désigné par l'adresse mais enetour de l'appel "t_accept" elle contienora la taille réelle de radresse retournée.
Fin~1 t~ suite à l'appel de fonction "accept", un nouveau rlr~ t - de fichier 25 de c. r~n est retourné, il c..ll~ ,l.d à la nouvelle entrée "socket"
disponible.
Un appel de fonction "~ -e~ " est utilisé lorsque "client" ou "serveur" veut connâître le nom de l'entité de c~ . de même niveau, I'u~ ~ actif 30 OU passif désirant obtenir le nom de l'extrémité de c~ n~ inn distante auquel il est connecté. L'appel "grll~e~ " (conforme à la famille AF_INET) contient le retour de l'appel "socket" local spécifié (domaine, type, protocole), I'adresse spécifiée (I'argument adresse étant un paramètre résultat qui est donné avec l'adresse de l'entité de même niveau se c~ "~ ) et la taille de l'adresse spécifiée.
35 Il est à noter que la séquence d'2lll, est identique à celles des fonctions "bind", ~g. t~ - rl', "connect" et "accept" mais que l'~;uul~ adresse est un argument de sortie. Les valeurs de retoUI sont sçit l'adresse du client, la taille réelle de l'adresse retournée et la valeur (0) si l'appel a abouti, soit la valeur (-1) en cas ~ 36921 , l6 d'erreur.
En fait, I'échange du nom de l'adresse est effectlé lorsque l'utilisateur passifaccepte (fonction "accept") la requête de connexion (fonction "connect") de l'entité
5 de même niveau. Cette adresse est alors décodée. Le nom de l'entité se .,.,....G~,L~.L, ainsi converti, est maintenu dans la liste des ~Ir;- ;l"r."~ de fichiers de l'arbre binaire de recherche où il est associé avec le nouveau fl.~...;~.lr.., de fichier qui a été créé pour la G~I IIIII r ~';on. De cette manière, I'utilisateur passif peut toujours connâître l'entité de même niveau distante (1~ ,l, est . I^~nf~nt lue).

Pour résumer les phases l"c~,éd~ s, la création est réalisée au moyen de la fonction "socket", la liaison à une adresse au moyen de la fonction "bind" et laconnexion est demamdée par 1' ' ' c de la fonction "connect" et acceptée par 1" ' ' c de la fonction "accept".
Dans la troisième phase dite de 1,,.,~ ", de données, I'appel de fonction "send"est utilisé pour Ll~..lclLIc des données selon un canal virtuel au travers des ports de l'interface "socket" connectés, autorisant ainsi l'utilisateur du transport àenvoyer un flot de données normales ou um flot de dommées express au travers de 20 c-~nnf-Yi-ne réalisées. La fonction "send" ne peut être utilisée que lorsque le port concerné de l'interface "socket" est c~cli~""c~l connecté. L'appel "send"
(conforme à la famille AF_INET) contient le retour de l'appel "socket" local spécifié (domaine, type, protocole), le message spécifié (une unité de caractères étant définie comme une cha~ne), la taille spécifiée de l'unité de données à
25 Ll~c.~.-cLL c et les drapeaux spécifiés (un drapeau étant um paramètre qui indique une f,~ spéciale GIJI~( r l l ~- ll la L-~ du message, par exemple pour l'envoi de données hors-bande, ou des données envoyées sans table 30 11 est à noter que si aucun espace n'est disponible dams les tampons de l'interface "socket" pour conserver le message à i c, alors l'émission est bloquée à
moins que l'interface "socket" n'ait été placée dans um mode d'entrée/sortie nonbloquant Ensuite il peut être déterrniné le moment où il est possible d'envoyer de nouveau des données.
Les valeurs de retour de la fonction "send" sont, soit le nombre de caractères envoyés si l'appel a abouti, soit la valeur (-1) en cas d'erreur.

2~6~

La fonction co~ r en mode XTI-CO est "t snd", c'est l'état T_DATAXFER qui subsiste jusqu'à ce qu'une requête de ." on soit émise par un utilisateur actif ou recue par un utilisateur passif. Elle perlnet d'envoyer, a travers une ~ on, un tlot de données normales ou un flot de domnées express.
5 Elle contient l'extremité de cormexion de transport spécifiée ((IF~ lr~ll de fichier~
identifiant l'extrémité de connexion de transport locale à partir de laquelle les données sont émises, le tampon de dormées spécifié (unité de domnées définie comme un pointeur d'une châîne), la taille du tampon spécifiée (le nombre d'octets des données utilisateur à envoyer) et les drapeaux spécifiés (incluant toute option).
o n est à noter qu'un drapeau sélectionnant le flot de données express sigrufie que les données sont envoyées à cette vitesse et ~ ion est faite par le ruul~
de transport. F.~lPment, un drapeau peut indiquer que les unités de données sontenvoyées par 1';, ~ P~ d'une séquence d'appels "t snd" multiple. La fin de données est identifiée par l'appel "t snd" avec ce même dernier drapeau non 15 5.'.1~ 111 F Cela permet à un utilisateur de dcculll~os~l de grandes unités de données logiques. Les valeurs de retour sont, soit le nombre d'octets accepté par le fou--lk.~ - de transport si l'appel a abouti, soit la valeur (-1) en cas d'erreur (indiquant l'imroecihilit~ de i c; les dornées).
20 Dans le cas où le ~ lr~ de fichier de l'utilisateur n'est pas trouvé dans l'arbre binaire de recherche, rappel est redirigé vers la librairie TCP standard.
L'état de comnexion du ~ de fichier est vérifié. L'état T_DATAXFER est ahsolllmP~ requis, tout autre état entrâîne rémission d'une erreu~ indiquant que la 25 ~onction a été émise lors d'une séquence erronée.
N; ' ~ le nombre d'octets envoyés est égal au nombre d'octets spécifié dans la taille spécifiée. Cependant, si le mode d'c~.l;c~aulLi~ non bloquant est sPIPcti( -" il est possible que seule une partie des données soit réellement 30 acceptée par le r~....,.:.~.." de transport. Dans ce cas, I'appel "t_snd" retourne une valeur indiquant un nombre d'octets inférieur à la taille specifiée.
L'appel de fonction "recv" est utilisé pour recueillir les données entrantes sur les ports connectés de l'interface "socket" sur un canal virtuel en autorisant un 35 utilisateur de transport, à recevoir sur une ~ un flot de données émis à
vitesse nor~nale ou express. L'appel "recv" ne peut être utilisé que lorsque, les ports concernés de l'interface "socket" sont cormectés. L'appel "recv" (conforme à la famille AF_INET) contient le retour de l'appel "socket" local (domaine, type, ~3~9~1 protocole), I'adresse du tampon spécifiee où les dommées doivent être placées, la taille du tampon de réception de données (si um message est trop long pour tenirdarls le tampon donné, les octets en excès peuvent être supprimés selon le type de port de l'interface "socket" duquel provient le message) et les drapeaux specifiés S (IJCU~IIC~ ;S mdiquant une cnmmPn-lP spéciale c~ ' la trPn~mi~ion du message, mêmes p~ WllCilC5 que ceux présentés avec l'appel "send"). Les mêmes arguments sont utilisés avec les appels "send" et "recv". L'argument drapeau dans un appel "recv" est formé par la réunion logique d'une ou plusieurs valeurs. Il est à
noter que si aucun message n'est disponible sur um port de l'interface "socket",o l'appel "recv" attend qu'un message arrive à moins que l'interface "socket" n'ait été
placée en mode non-bloquant, en tel cas une valeur (-1) est retournée. Les valeurs de retour de l'appel "recv" sont, soit le nombre d'octets reçus si l'appel a abouti, soit la valeur (- I) en cas d'erreur.
15 La fonction ~,ollr~ en mode XTI-CO est "t rcv". Même situation qu'avec l'appel "t snd", c'est l'état T_DATAXFER qui subsiste jusqu'à ce qu'une requête de dPcnnn ~inn soit émise par um utilisateur actif ou reçue par un utilisateur passif.
Elle permet de recevoir sur une comnexion un flot de dornées normales ou um flotde données express. Elle contient l'extrémité de cnnnP. rinn de transport spécifiée 20 (~ f~''' de fichier) identifiant l'extrémité de connexion de transport locale par laquelle les dormées arrivent, le tampon de réception spécifié où sont reçues les données `-fjlicof llr, la taille du tampon de réception (nombre d'octets). Les valeurs de retour sont, soit les valeurs sflpctlnnn~nt les drapeaux et spécifiant les drapeaux opf~innnPl~ ainsi que le nombre d'octets reçus par le r. de transport si 25 I'appel a abouti, soit la valeur (-1) en cas d'erreur.
Si le ~iP~ ' de fichier n'est pas trouvé dans l'arbre binaire de recherche, I'appel est redirigé vers la librairie TCP standard.
30 L'état de c. nn du ~ - - de fichier est vérifié. L'état T_DATAXFER est absolument requis, tout autre état entrâîne l'émission d'ume erreur indiquant que la fonction a été émise lors d'une séquence erronée.
En retour à l'appel "t_rcv", si, est sPIPcfinnnP un drapeau indiquant que d'autres 35 données sont à recevoir, les unités de données de service de transport courantes émises sur le flot de données normales ou sur le flot de données express (selon un second drapeau sflr~l;"""~) doivent être reçues au moyen d'appels "t_rcv"
multiples. Chaque appel "t_rcv", avec le drapeau sélectionné, indique qu'un autre ~13~921 appel "t rcv" suit ;.,~ pour fournir de nouvelles donmées pour l'unité de données courante et, ceci autant de fois qu'il est nécessaire pour recevoir toutes les données. La fin de cette unité de données est identifiée par le retour de l'appel "t rcv" lorsque le drapeall n'est plus s~l-cti~Ann Si un flot de dorLnées express (sélection du drapeau prévu à cet effet) arrive après qu'une partie d'un flot de données normales ait été reçue, la partie restante de ce flot de donnees normales ne sera pas reçue tant que l'ensemble du flot de données express n'aura pas été traité.

L'appel système de fonctions standards "read" ou "write" fourlAIit un autre moyen d'envoyer ou recevoir un flot de données normales ou um flot de données express vers une connexion donnée. Les appels "read" ou "write" cnntiPnn~nt le rlr~ ,t~ de fichier spécrfié (qui est ouvert et se réfère à un flot de données (STR~AM)), le tampon spécifié et la taille du tampon spécifié.
Les fonctions Cull~ t- C en mode XTI-CO sont ~ -,uc~ " "t snd" et "t rcv" telles que décrites ~ C'~ ' 20 Avec ume entité de même niveau à chaque extrémité de la . on, um utilisateur peut envoyer ou recevoir des données sans spécifier l'entité de même niveau. Grâce à cela, les appels "write" ou "read" st~ndards peuvent être utilisés sans inconvénuent.
25 Il est à remarquer qu'il existe la même cull. r ' -~ entre "read" et "t rcv"
qu'entre "recv" et "t rc,v" et entre " vrite et "t snd" qu'entre "send" et "t snd". Par c~. ~.c~ un appel "read" standard peut être exécuté quand le .~ ... de fichier ~ lL pas à la liste des rlr~ ;l,t. - ~ de fichiers gérée dans rarbre binaire de recherche. D'autre part, les arguments relatifs aux drapeaux sont sans 30 utilité et sont toujours forcés à la valeur 0.
Les valeurs de retour sont pour l'appel "read" le nombre d'octets reçus et pour l'appel "write" le nombre de caractères envoyés lorsque ces appels ont abouti et la valeur (-1) en cas d'erreur.
Dans la quatrième phase dite de "~coA~AYinn", I'appel système de fonction standard "shutdown" est utilisé pour faire cesser l'émission etlou la réception de données à travers un canal virLuel~ il est ainsi permis à l'utilisateur de transport 3g921 .

d'il~clluu~c la l.,...~...;~i.. de données vers une connP-rir.n La fonction "shutdown" ne peut être utilisée que lorsque le port concerné de l'interface "socket"
est ~ ,. connecté. Cette fonction provoque donc la fermeture totale ou partielle d'une connexion bilatérale et "full-duplex" entre le port de l'interface 5 "socket" concerné et la Ir~ ;c~lll associée de ladite connexion. L'appel "shutdown" (conforme à la famille AF_INET) contient le retour de l'appel "socket"
local spécifié (domaine, type, protocole) et la direction spécifiée de circulation de données, un argument de valeur û siglufiant que la réception est illL~:Ilu~ ue:, un argument de valeur I que l'émission est i~ u~ uue et un argument de valeur 2 que l'émission et la.réception sont iUlt~,llUIII~ ~s. Les valeurs de retour de l'appel "shutdown" sont, soit la valeur 0 si l'appel a abouti, soit la valeur (-1) en cas d'erreur.
Lorsque la fonction "shutdo~vn" est exécutée sur un port de l'interface "socket", 15 toutes les données mises en attente sont ;".."f.l;.~ "...1 sul.pli...f;es. Aussi, t,~' hl~ 1 I'utilisateur qui n'utilise pas les données en attente peut exécuter un appel "shutdown" sur un port déterminé de l'interface "socket" avant de le refermer.
20 Si le ~l~c. -;Illrlll de fichier de 1'1 l n'est pas trouvé dans l'arbre binaire de recherche, I'appel est traité par l'appel de la fonction standard "shutdown" dont la valeur de retour est d;.c.,t~ retournée vers 1'1 " de l'appel.
L'état de connexion du ~l~ , de fichier est ensuite vérifié. J,'état 25 T_DATAXFER est Pl~sol requis. Tout autre état provoque l'apparition *une erreur indiquant que la fonction a été émise lors d'une séquence erronee.
Aucune fonction de suppression n'existe dans l'interface XTI, les données entrantes ou sortantes dans les tampons ne peuvent donc être su~ Cependamt, hors 30 de l'interface XTI (c'est-à-dire en STREAM), il est possible de lire et supprimer les donnees présentes dans le tampon de lecture.
L'appel système de fonction standard "close" est utilisé pour une (lfPc~nnpl~ion d'un canal virtuel, IJ ~ ' ainsi à un utilisateur de transport de libérer la connexion 35 c~-nrPrnPP L'appel standard "close" peut toujours être utilisé sur un ~.. ;I,t.. de fichier de l'interface "socket". La règle est que l'appel "close" efface de la table de références objets des processus le des~, r~ de fichier concerné et lorsqu'il est la dernière référence à l'objet déterminé, alors celui-ci est désactivé. Le dernier appel - 21~6~

"close" sur un port de l'interface "socket" implique que rinformation associée et les données rnises en attente sont ,, L'appel "close" contient le retour de l'appel "socket" loc~l spécifié (domaine, type, protocole). Les valeurs de retour sont, soit la valeur (0) si l'appel a abouti, soit la valeur (- l) en cas d'erreur.

La fonction Gu~ yul~ en mode XTI-CO est "t close", elle peut être lancée dans n'importe quel état excepté l'état T_UNINIT, une G~ de ~ AA,nn~Yinn étant alors émise par l'utilisateur actif ou reçue par l'utilisateur passif. Le r ' _, de transport est informé que l'utilisateur n'utilise plus l'extrémité de connexion de transport spécifiée par le ~C~ iy~ul de ficbier. En outre, le fichier associé à l'extrémité de cormexion de transpûrt est fermé. La fonction "t close"contient l'extrémité de connexion de transport spécifiée (~ ". de fichier f~ l'extrémité de connexion de transport locale au trave}s de laquelle les données circulent). Les valeurs de retour sont, soit la valeur (0) si l'appel a abouti, 15 soit la valeur (-l) en cas d'erreur.
Un appel système standard "close" est ~e-,ti~ "~ exécuté lorsque le ~ ll de fichier n'~ya~ plus à la liste gérée dans l'arbre binaire de recherche.
20 La fonctioll "t close" devrait être appelée à partir de l'état T_UNBND, mais comme cette fonction ne vérifie pas l'infnrrAA-tinn d'état, elle peut donc être appelée à partir de n'importe quel état pour ferrlA,er une extrémité de ~ 'nn de transport.
Ainsi dans l'état T UNBND, l'appel "t close" est - ' exécuté, dans les etats T_IDLE, T_INCON ou T-OUTCON ce sont les appels "t unbind" et 25 "t close" qui sont exécutés et d~ns l'état T_DATAXFER un appel "t snddis" ou "t rcvdis" ("t snddis": demande de ~l~cnnnlAYinn, l'appel étant émis par l'utilisateur actif ou, "t rcvdis": recherche de la cause de la l~cA,nn~AYinn~ l'appel étant émis par l'utilisateur passif) est exécuté dans un premier temps puis ensuite seulement sont exécutés les appels "t unbind" et "t close".
Finalement si aucun autre p}ocessus ne fait }éfé}ence aux ~ de fichiersde l'extrémité de conneYion de transport (tous les '1f c.~. ;Illr",, de fichiers associés au fichier qui a été fermé):
- tous les 1~ c. . il.t .. ~ de fichiers associés à l'extrémité de connexion idé,~:~ sont q ---- libérés, - toute connexion de transport qui pouvait être liée à cette extrémité de ~3692~

connexion est u~ JU~, - il y a passage de l'état qui était Obli~;aluil~ différent de l'état T_UNINIT
vers l'état T_UNINIT et donc retour au tout début du processus.
D'autres appels systeme de fonctions standards peuvent être également utilisés.
Ainsi il est possible de contrôler les entrées/sorties de l'interface "socket" au moyen des appels de fonctions "ioctl" et "fcntl". Ces appels peuvent être dédiés.~.. ;l~.l.. : au ~ontrôle des opérations sur l'interface "socket", une application n'utilisant un tel appel qu'ume fois qu'un des~ ul de fichier a été affecté à ume entrée de l'interface "socket". Dans ce cas, cet appel contient, le retour de l'appel "socket" local spécifié (domaine, type, protocole), la cu....l.aulde spécifiée sous forme d'un code qui perlnet de sélectionner la fonction de contrôle à exécuter, et enfin rargument spécifié qui représente l'il~llllaliull Jl~r1itionnl~111q nécessaire pour .~t~, certaines valeurs du code de la C ..,....~ f spécifiée.
La . ' spécifiée peut selon le code permettre et ceci de manière non limitative:
- de comnâître l'identité du groupe de processus qui contient le processus courant (SIOCGPGRP).
- de demander que l'émission d'un signal asynchrone se fasse sur un processus ou sur un groupe de processus (SIOCSPGRP).

- de s'assurer que le pointeur de lecture d'ume entrée "socket" est ou n'est pasGuul ' posiùonné dans le flot de données à l'endroit où sont reçues des domnées hors-bande (SIOCATMARK).
- de retourner le nombre d'octets en attente de lecture sur une entrée "socket"
(FIONR~AD).
- de commuter l'entrée "socket" dans un mode d'entrée/sortie soit bloquant, soit non-bloquant (FIONBIO).
Les appels "ioctl" généraux qui pcillllc:Ll~l.L de contrôler des opérations relatives à
des fichiers peuvent être également utilisés pour contrôler l'interface "socket". Les arguments sont identiques à ceux décrits p,~,~.l.. ~.. l en ce qui concerne le ~369~1 retour de l'appel "socket" local spécifié et l'argument spécifié mais diffèrent en ce qui concerne la c~ -1c spécifiée. Ainsi, dans ce cas, le code peut permettre de S~ lF~ - la fonction de ' qui doit être exécutée relativement à un fichier ou à un ~ ---- de fichier:

- fermeture des entrées "socket" lors du ~ d'un nouveau code sur le processus.
pocitlcmnFn~Fnt ou suppression du mode d'entrées/sorties asynchrone.

Les appels "ioctl" peuvent etre, en outre utilises pour contrôler l'F~rl~A,itAti~An des 'interfaces de ~ A,n réseau ("ifnet"). Ces appels p~ de IG~,I.Gl~llF~l et retrouver des interfaces à partir de leurs adresses ou de retrouver une interface dans un réseau donné. Les arguments sont identiques à ceux décrits l~lrc.~lrlllll . .,l excepté en ce qui concerne d'une part la structure de la requête qui utilise des~lF~niti~Anc de p `~c~ et d'autre part la ~ spécifiée de la fonction à
exécuter sur l'interface donnée pour obtenir par exemple l'adresse "ifnet" (adresse de l'interface), I'adresse de diffusion générale ("I)lUAAdc&~"), la liste "ifnet" (utilisée pour retrouver la cc- ~L~...nl;~An de l'interface), des adresses entre entités de même 20 niveau (vers une machine distante avec laquelle un lien est établi) ou des drapeaux "ifnet" (le plus souvent l'interface réseau peut être identifiée: connectée ou non, op~rAti~nnf~11F Ou attachée à une adresse de diffusion générale).
La cull~ ;u~ des fonctions ~,-Gc~d~ cs peut être faite à l'aide de la fonction 2s "ioctl" sur des flots de données (I'interface XTI etant mise en oeuvre au moyen de flots de données: STREAMS). Dans ce cas la fonction "ioctl" contient le ~1~ , de fichier spécifié (fichier ouvert qui se réfère à um flot de données), la c, ' spécifiée (.l~lr,ll.;l.-.l~ la fonction de contrôle à exécuter) et l'~ullldlL
spécifié (l~,..' I';l.~llll.AI;~III A~l~l;t;l ~I . nécessaire pour certaines valeurs 30 du code, c'est en général un nombre entier ou un pointeur vers une structure de donmées pour une c. ' spécifique). Plus particulièrement, la c. '-spécifiée peut permettre et ceci de marlière non limitative:
- de i G vers la tête du flot de donrLées 1~ n exprimant que l'utilisateur désire que le noyau du système émette un signal (I_SETSIG) lors de l'apparition d'um évènement particulier sur ledit flot de données associé
aux .1~c ;l,t~ de fichiers (se référant à ce flot de données), 213fi~21 -de retoutner les inff~rm~iinn~ cnnf--- les ~V~ llLb pour lesquels le processus d'appel a demandé l'émission du signal SIGPOLL (I GETSIG), - de compter le nombre d'octets dans les blocs de données du premier message s de la file d'attente au début du flot de données (I NREAD) La Cul~ ;ùl~ des fonctions ~ d~ s peut être faite à l'aide de la fonction "fcntl" sur des flots de données. La fonction "fcntl" contient le ,IP~ de fichier spécifié (fichier ouvert qui peut faire référence au flot de données), la spécifiée (~rlrllll;"A ~ la fonction de contrôle à exécuter) et l'argument spécifié La cnmm mf1P spécifiée peut par exemple être utilisée pour - positionner ou lire la position du drapeau de fermeture des fichiers à la su*e d'un nouveau lancement de processus (F SETFD, F_GETFD), -retourner la valeur des différents drapeaux d'états qui fixent les modes synchrone (O_SYNC), asynchrone (FASYNC), non-bloquant (O_NDELAY), - demander que l'émission d'um signal a~y...Lu..e se fasse sur un processus ou sur un groupe de processus (SIOCSPGRP), - connaître l'identité du groupe de processus qui contient le processus courant (SIOCGPGRP) 25 De manière générale le contrôle des entrées/sorties sur les entrées "socket" peut être émulé à l'aide des fonctions de contrôle sur les flots de données (STREAMS) Le module W peut également traiter des entrées/sorties asynchrones. Pour cela, un signal spécifique ilA~IUl~lJI le module pour lui indiquer l'arrivée d'entrées/sorties 30 ~yll~,Lu~es, en réponse à ce signal un ,1vc.i est émis par le module vers I ~rrlir~iin Les entrées/sorties a~y..~Lunes peuvent appara~tre lors de l'exécution de différents appels de fonctions critiques Le cu---l~u-l~ ,la~ivc;ll~ aux appels de fonctions peut être résumé ci-après 35 -un ~V~ ,l,.u.ll survient sur une extrémité de cnnnPYinn de transport lors de l'execution d'un appel "connect" Un signal est reçu par le module W et un appel l't_l~V~UIIIIC~,l" (réception de la cnnfirm~ n après exécution d'un appel "t_connect") peut être utilisé pour ~c lr~ - I'état de la ~1369~1 , ~

requête de connexion émise ~,cG~ en mode asynchrone. La connexion est établie dès que l'appel ''t_l~,v~,ulUl~,L~ a abouti. En retour la ~ctlucture d'adresse d'appel contient le poirit d'accès du service de transport (TSAP) distant qui a émis l'appel.

-un ~ async~frone survient lors de l'application d'un appel "accept", au moment de l'extraction d'une première connexion de la file d'attente et de la création d'ume entrée "socket" de comm~ni~ ion~ Un signal est reçu par le modulfe W et un appel "t listen" peut être effectué. Par défaut ce dernier s'exécute en mode synchrone et attend l'arrivée d'une indication de connexion avant de répondre en retour à l'utilisateur passif. Cependant si le mode non-bloquant a été s~ ctinnn~5 par 1';1 ~.",~-1;,.;,~ d'appels "t_open" ou "fcntl", I'appel "t_'fisten" s'exécute de manière asynchrone, se réduisant à une scrutation des j~ U;~ r de cnnn~-Yinnc existantes. Si aucume Cnnnn-inn n'est en attente il est retourné une eTreur (valeur (-1)). Dans le cas d'une exécution .,.,~,,f~,l fu..e, if est possible d'utiliser un numéro de séquence (dont la valfeur permet 'f'id~--liL~. de façon u~fuque l'indication de connexion retournée) pour attendre plusieurs ' ~ns de commexion multiple avant de répondre à rune d'entre elles.

-um ~.V~ lf~ asynchrone survient lors de l'exécution d'un appel "send" pour l'émission d'un flot de données normales ou d'un flot de données express vers une ~ Unf signal est reçu par le module W et un appel "t_snd" peut être effectué. Par défaut il s'exécute en mode synchrone et peut, en outre, attendre si le flot de données contient des l~,lfi~liOIIs r~
1..~""...l r~ l's~ceFt~ )n des données par le ruuuffi~ ff de transport localf au moment où est effectué l'appel. Cependant, si le mode non-bloquant a été s~l~ctinnn~ par 1';"1~.""'.l;~ des appels "t open" ou "fcntl", I'~fppel "t snd" s'exécute de manière asynchrone. En cas de restriction de contrôle de flots de données rappel échoue mais le processus peut en être informé au moyen d'un sif~nal et lorsque ~ ...1 lesdites r~ctrirtionc les flots de données (normafes ou exp~ess) peuvent être réémis.
- un ~v~ II.,IUUIfC survient lors de l'~é.,uliu.. d'urf appel "recv" pour la réception de flots de données (normales ou express) sur une - 'on Un signal est reçu par le modu'fe W et un appel "t_rcv" peut être effectué. Par défaut ce dernier s'exécute en mode synchrone et attend l'arrivée de données si aucrfne n'est à ce moment disponible. Cependant, si le mode non-bloquant 2 ~ ~ 6 9 2 1 a été splpctil par 1' ' ' ~ des appels "t_open" ou "fcntl", I'appel "t_rcv" s'exécute en mode asy~ -u..~, il échoue en l'absence de donmées sauf si l'utilisateur peut être informé de l'arrivée de flots de données (norma~es ouexpress) après examen des signaux chargés de l'en avertir.
Des fonctions de duplication peuvent être également utilisées. En effet, la plupart des applications TCPQP r~r.,.~ la duplication d'un lrs.~ u~,.. de fichier ouvert. Le module W, dans ce cas, reçoit un a~pel système "dup" (duplication) etle convertit en un appel "fcntl" qui contient le d~ L~u- de fichier spécifié, la0 C~ F de duplication du d~s~ ul de fichier et l'argument spécifié. En réponse à la crmmAn-lP de duplication un nouveau (lperrirtpllr de fichier est n~rmDlPnnPnt retourné. Dans ce cas, le nouveau fichier -est le plus petit .~P...;~ .ll de fichier disponible supérieur ou égal à
I'argument spécifié, - se réfère au même objet que le ~, . de fichier d'origine, - utilise en commun le même pointeur de fichier, - utilise en commum le même mode d'accès, - utilise en commum les mêmes drapeaux d'états de d~s, ,: de fichier, 25 -possède un drapeau spécifique sPIPc~ir,nnP de manière à laisser ouvert le fichier à la suite de la création d'un nouveau processus.
En réponse à la c~ "-- ,- ~ P de dU~)IiC~IiUII~ une erreur peut être également retournée si :
3~
- le nombre maximum autorisé de ~ r~ de fichiers est atteint ou, -I'argument spécifié est négatif ou plus~grand que le nombre maximum autorisé de d~ de fichiers par processus.
Le module W peut également recevoir un appel système "dup2" et le convertir en un appel "fcntl" qui contient le .l~-5.~ .., de fichier spécifié, la cu-l-~ .dc de ~ rlirD~ir,n du ~ t~- de fichier et un deuxième ~ir~ lll de fichier 2~36921 dupliqué. Dans ce cas, il est vérifié d'abord que le second fichier est fermé, sinon ce dernier est fermé.
Le module W met pério~iiq.l-~ à jour l'arbre binaire de recherche avec les 5 différents fl~ r... ~ de fichiers . Il crée, au moins, dans cet arbre, une référence nouvelle de de~ lcu- pour la It~ti~n des inform~tif)n~ du fichier d'origine.
Il partage donc les mêmes inr r)n~ (utilisées en commun) que celles du ~lFj...lll(t~ de fichier d~origine. Si nécessaire, une liste châînée est alors créée reliant les des~ de fichiers dupliqués.

En conclusion, le procédé de conversion d'adlcssdge selon l'invention permet de fournir, à toute ~rpljr~tion cr.~m-mi(l~" t dans le domaine INTERNET (avec des protocoles TCP/IP), la possibilité de dialoguer au travers des couches de Cv..-l.lu. i~,d~ivlls OSI et d'être ainsi dilc~,t~ .; exploitée dans un réseau OSI-CO, 15 (sans autle protocole de c, ~m), tout se passant comme si ladite application continuait de dialoguer au travers du protocole TCP/IP, I'accès aux couches OSI étant llall~,Ua~ . La diffusion des messages au travers des couches OSI est obtenue sams aucune r~rltlifir~tion du code source de l'~rFIir~ti-~n (n~ ~ t, sans aucune -' ~ des l~lu~ s u~lisés par l'~rplic~ n 20 pour crmn~niq~ r) ni aucune ~ r~...--t~.... du CVllllJult~ des appels de t~' ''r employés dans l'~rplic~ti~m La Cull~ ;ull d'adressage est donc Ic-~ ,, dès lors qu'un module de conversion est ajouté au moment de la phase d'édition de liens (dernière étape de ~lud~.~,Lvll de I'I Y~c~t~hl^). Ce module de Cullv.,l~;vll est en fait une librairie correspondant à un 25 ensemble de fonctions, il est donc de très faible coût. En outre, ce module de Cu-~ ;vll comporte un sous-module de service p~ ll~-l d'élaborer un ensemble spécifique d'~t ~ du système ce qui perrnet d'assurer une parfaite portabilité
de l'application.

Claims (7)

1. Procédé de conversion d'adressage pour le portage d'applications de télécommunication du réseau TCP/IP sur le réseau OSI-CO, l'accès aux dits réseaux étant autorisé par l'intermédiaire d'une interface dite "socket" pour le réseau TCP/IP et d'une interface dite "XTI" pour le réseau OSI-CO, caractérisé en ce que les appels de l'interface dite "socket" sont, ainsi qu'une pluralité d'appels système du genre lecture, écriture, fermeture, dans un premier temps orientés, au moment de la phase d'édition de liens avant l'obtention de l'exécutable, vers unmodule de conversion automatique d'adressage du genre librairie réalisant la conversion des adresses propres au réseau TCP/IP en adresses du réseau OSI-CO
et permettant le passage du protocole TCP/IP vers le protocole OSI-CO, puis après conversion les appels sont transmis vers l'interface dite "XTI" pour être alors directement exploités dans le réseau OSI-CO, seuls les appels destinés au réseau TCP/IP étant traités, tout autre appel étant renvoyé vers le système.

2. Procédé de conversion d'adressage selon la revendication 1, caractérisé en ceque, lorsque l'appel de l'interface dite "socket" est destiné au réseau TCP/IP, il est d'abord créé une ressource propre en mémoire pour conserver la trace de la connexion, puis l'interface dite "XTI" est appelée pour l'ouverture de ladite connexion, l'ensemble étant géré au moyen d'un arbre binaire de recherche.

3. Module de conversion d'adressage utilisé dans le procédé selon la revendication 1 ou 2, caractérisé en ce qu'il est principalement constitué d'un premier sous-module LIB formant la librairie principale et contenant une table de correspondance entre les fonctions de communication TCP/IP et les fonctions de conversion incluses dans l'interface d'entrée IW du module W, d'un second sous-module AM de service de conversion d'adresses IP et OSI, d'un troisième sous-module SBT d'enregistrement des informations de connexion gérant lesdites informations au moyen d'un arbre binaire de recherche et d'un quatrième sous-module KE de service pour l'élaboration d'un ensemble spécifique d'extensions ausystème.

4. Module de conversion d'adressage selon la revendication 3, caractérisé en ce que la table de correspondance MT incluse dans le premier sous-module LIB fournit avantageusement une correspondance bijective, telle qu'à toute fonction de communication TCP/IP par l'intermédiaire du mécanisme des "sockets", il existeune fonction et une seule dans l'interface IW qui exécute le service demandé par l'application APP, le nom des appels, le nombre des arguments de paramètres d'unappel, la sémantique et l'enchaînement des appels étant exactement conservés.

5. Module de conversion d'adressage selon la revendication 4, caractérisé en ce que le second sous-module AM de service de conversion d'adresses forme également une librairie et effectue la conversion entre d'une part les adresses IP comportant l'adresse réseau de la machine concernée et le port relatif au service accédé etd'autre part les adresses OSI comportant le point d'accès de service du réseau (NSAP) et le sélecteur de transport (TSEL), ladite conversion pouvant être effectuée dans les deux sens, adresses IP vers adresses OSI ou adresses OSI versadresses IP.

6. Module de conversion d'adressage selon la revendication 5, caractérisé en ce que le troisième sous-module SBT d'enregistrement des informations de connexion gérées par un arbre binaire de recherche fournit un service indépendant sous la forme d'une librairie permettant d'enregistrer, trier, rechercher et supprimer de façon optimale tous les éléments d'information significatifs relatifs à une connexion donnée.

7. Module de conversion d'adressage selon la revendication 6, caractérisé en ce que le quatrième sous-module de service permet d'élaborer un ensemble spécifique d'extensions au système pour rediriger et renvoyer, dans le cadre du mécanisme des "sockets" et par l'intermédiaire du noyau système, les appels de télécommunications non destinés au réseau TCP/IP et qui ne sont donc pas convertis par le module de conversion, vers la librairie TCP standard.