FR2781627A1 - Procede pour executer une application dans un systeme informatique raccorde a un reseau de communication, et module de controle utilisable dans un tel procede - Google Patents
Procede pour executer une application dans un systeme informatique raccorde a un reseau de communication, et module de controle utilisable dans un tel procede Download PDFInfo
- Publication number
- FR2781627A1 FR2781627A1 FR9808393A FR9808393A FR2781627A1 FR 2781627 A1 FR2781627 A1 FR 2781627A1 FR 9808393 A FR9808393 A FR 9808393A FR 9808393 A FR9808393 A FR 9808393A FR 2781627 A1 FR2781627 A1 FR 2781627A1
- Authority
- FR
- France
- Prior art keywords
- protocol
- network
- address
- application
- unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/4608—LAN interconnection over ATM networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
- H04L69/085—Protocols for interworking; Protocol conversion specially adapted for interworking of IP-based networks with other networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/02—Protocol performance
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Une application (12), conçue pour communiquer vers une première interface logicielle de programmation (API) (10) adaptée à un premier protocole de réseau, est exécutée dans un système (1) équipé d'une seconde API (11) adaptée à un réseau (R) fonctionnant selon un second protocole. Avant de communiquer avec une autre unité (2) accessible par le réseau au moyen d'une adresse définie selon le second protocole, le système associe à l'adresse de réseau de l'unité une adresse fictive définie selon le premier protocole. Les messages échangés par l'application vers la première API sont traduits dans un module de contrôle (15) du système, qui assure en outre les substitutions d'adresses requises pour que l'application puisse, sans modification, communiquer au moyen du réseau fondé sur le second protocole. Le module de contrôle (15) permet de spécifier des paramètres de qualité de service qui seraient supportés par le second protocole mais non par le premier.
Description
PROCÉDÉ POUR EXÉCUTER UNE APPLICATION DANS UN SYSTEME
INFORMATIQUE RACCORDÉ A UN RESEAU DE COMMUNICATION,
ET MODULE DE CONTRÈLE UTILISABLE DANS UN TEL PROCÉDÉ
La présente invention concerne le domaine des réseaux informatiques. Un réseau informatique R (figure 1) fait intervenir deux types généraux d'équipements, à savoir les "terminaux" et les "éléments de réseau". Les terminaux 1,2,3 (cette notion inclut ici les serveurs) sont des machines (ordinateurs) sur lesquelles sont exécutées des applications ou programmes informatiques susceptibles de requérir des communications avec d'autres terminaux. La mise en relation de ces terminaux entre eux est assurée par les éléments de réseau 4,5 (liens de transmission et points d'aiguillage). Le dialogue entre terminaux et éléments de réseau est assuré selon des procédures
prédéfinies PROT appelées protocoles de communication.
Les applications informatiques conçues pour fonctionner en réseau utilisent des interfaces logicielles de programmation ("Application Programming Interface", ou API). Ces interfaces de communication en réseau font partie des ressources offertes par le système d'exploitation (SE) de chaque terminal. Elles permettent d'accéder aux protocoles implantés en utilisant un ensemble de "primitives", qui appellent des fonctions élémentaires permettant d'ouvrir une connexion vers une adresse distante, d'envoyer et de recevoir des données, etc. Ces primitives sont ensuite traduites en messages élémentaires du protocole en question (voir illustration en figure 2). Dans les terminaux, le fonctionnement selon le protocole de communication est assuré par d'autres ressources logicielles du système d'exploitation et par
des cartes de communication appropriées.
Une distinction supplémentaire permet d'identifier à la fois le terminal distant (grâce à son adresse de réseau), et de sélectionner un service particulier au sein de ce terminal grâce à couple d'un identifiants -2supplémentaire appelé (protocole, numéro de port). La combinaison (adresse, protocole, numéro de port) permet donc de désigner de façon univoque une application
particulière dans un terminal particulier.
L'interface prédominante à ce jour est l'API dite "sockets", disponible à la fois dans une variété d'environnements de système: Unix, Windows, etc. L'immense majorité des applications réseau disponibles aujourd'hui s'appuient ainsi sur cette interface, dans son mode permettant d'utiliser des réseaux fondés sur le protocole
de couche réseau IP (Internet Protocol).
Une autre notion importante se rapporte aux deux niveaux logiques utilisables pour identifier un terminal
(ou une application) raccordé à un réseau informatique.
Le premier niveau est celui de l'adressage de la couche réseau proprement dite. Il est en général structuré (c'est-à-dire que les adresses sont hiérarchisées afin de faciliter l'acheminement et l'administration des adresses), que la couche réseau fonctionne en mode connecté (dans ce cas, l'adresse n'est fournie qu'au moment de l'établissement d'une connexion) ou en mode sans
connexion (l'adresse est alors portée par chaque paquet).
Le second niveau est celui du nommage, qui permet d'identifier les terminaux par un nom logique, qui se présente en général sous la forme d'une chaîne de caractères aisément mémorisable et compréhensible par un humain. De plus, le nom peut être choisi indépendamment de toutes contraintes de longueur ou de localisation géographique. Pour ces raisons, ce sont les noms qui sont
le plus souvent utilisés comme identification.
Un service de traduction permet de faire correspondre une adresse, seule notion compréhensible par le réseau à un nom. Ce mécanisme utilise un annuaire qui regroupe les associations <nom logique, adresse de réseau> et qui offre des services d'interrogation permettant la traduction entre noms et adresses. Il est accessible à travers un ensemble de primitives de nommage de l'API -3 réseau. Ainsi, une application comporte en général la séquence suivante d'actions à chaque fois qu'elle désire communiquer à travers le réseau: 1. faire appel au service de traduction à travers les fonctions de résolution de nom de l'API. Elles
renvoient une adresse correspondant au nom indiqué.
2. entrer en communication avec le terminal distant à travers les primitives de communication de l'API réseau, auxquelles on fournit l'adresse, le protocole et le numéro
de port identifiant le service visé.
La prédominance de l'interface socket-IP, mentionnée ci-dessus, pose des difficultés pour l'introduction de nouvelles technologies de réseau, qui disposent de leur propre interface de programmation (API). En effet, il est hautement souhaitable pour les utilisateurs de pouvoir réutiliser dans le nouvel environnement le parc déjà acquis et maîtrisé d'applications en réseau. Un premier problème consiste donc à reprendre sans changement l'ensemble des applications exploitant une API commune (par exemple, les sockets IP) dans un nouvel environnement
de réseau.
Un second problème se rapporte à l'introduction de la notion de qualité de service, rendue possible par exemple grâce aux réseaux fondés sur la technologie ATM (Asynchronous Transfer Mode). Il devient possible de spécifier, flux de données par flux de données, ses besoins en termes de débit, de retard de transmission ou encore de taux de pertes du réseau. Malheureusement, comme ces notions n'existent pas avec les sockets IP, les
applications actuelles ne peuvent souvent pas en profiter.
Le second problème est donc de fournir au sein du terminal des moyens permettant de spécifier des paramètres de qualité de service ainsi que les flux auxquels ils
s'appliquent.
On ne connaît pas de solution publiée suggérant de faire migrer les applications existantes en respectant -4- l'API actuelle, tout en préservant la couche de nommage et en modifiant les couches de protocoles réseau ou transport. En ce qui concerne le premier problème cité, les approches proposées visent uniquement à empiler la couche
réseau IP au dessus de la nouvelle technologie de réseau.
On parle alors d'émulation de protocole. Au-delà des difficultés techniques qu'elles imposent, leurs faiblesses sont d'une part qu'elles compliquent notablement la gestion et la conception des réseaux en dupliquant les fonctionnalités, et d'autre part qu'elles reproduisent les limitations, en particulier en matière d'absence de
gestion de la qualité de service, de la couche IP.
Pour ce qui est du second problème cité, la seule possibilité actuelle est de réécrire les applications en tenant compte de l'API de la nouvelle couche réseau, ce qui permettra de tirer parti de la qualité de service, mais nécessite une modification du code de l'application
et donc empêche la reprise à l'identique de l'existant.
Une autre approche suggérée consiste à réaliser des traitements différenciés de flux de données à l'intérieur du réseau, sans que le terminal puisse participer à la négociation des conditions (identification des flux et des
paramètres de qualité de service) de ce traitement.
Un but principal de la présente invention est de
proposer une solution simple au premier problème cité ci-
dessus. L'invention propose ainsi un procédé pour exécuter une application dans un système informatique raccordé à un réseau de communication, l'application étant conçue pour échanger des messages vers une première interface logicielle de programmation adaptée à un premier protocole de communication en réseau, et le réseau de communication fonctionnant selon un second protocole de communication en réseau pour lequel le système est équipé d'une seconde interface logicielle de programmation. Avant un échange de messages entre l'application et une autre unité désignée par un nom d'unité et accessible par le réseau au moyen d'une adresse de réseau définie selon un format du second protocole, le système associe arbitrairement à l'adresse de réseau de l'unité une adresse à usage local définie selon un format du premier protocole. Lors dudit échange, chaque message reçu par le système selon le second protocole depuis l'unité identifiée par son adresse de réseau et destiné à l'application, est transformé en un message traduit incluant l'adresse à usage local associée, qui est fourni à l'application via la première interface de programmation, et chaque message présenté par l'application sur la première interface de programmation à destination de l'unité repérée par l'adresse à usage local est transformé en un message traduit selon le second protocole, qui est émis sur le réseau vers l'unité
identifiée par son adresse de réseau.
Par "système informatique", on entend, dans la définition ci-dessus du procédé, un terminal, client ou serveur, raccordé au réseau. Ce système informatique peut être un ordinateur de puissance plus ou moins grande, ou encore un groupement d'ordinateurs reliés entre eux par un réseau local distinct comportant une ou plusieurs passerelles pour le raccordement au réseau de communication. Pour la mise en oeuvre du procédé, le système informatique est équipé d'un module logiciel qui fournit l'ensemble des primitives de la première API (ancienne), ce qui permet la reprise transparente des applications. Ce module s'appuie sur les ressources de la seconde (nouvelle) API. Ces dernières peuvent être fournies par un
module standard du commerce.
Le mécanisme des adresses (fictives) à usage local simule une procédure d'accès selon le premier protocole du point de vue de l'application, de sorte que celle-ci n'a pas besoin d'être modifiée lorsque le système est raccordé au réseau fonctionnant selon le second protocole. Les messages échangés par le système sur le réseau ne -6 conservent aucune trace du premier protocole, et donc ne sont affectés par aucune des contraintes propres à ce
premier protocole.
Le fait d'affranchir les messages échangés sur le réseau des limitations propres au premier protocole permet de faire bénéficier l'application de fonctions de gestion des communications étrangères au premier protocole, notamment de gestion de la qualité de service dans le cas, par exemple, du passage d'un protocole IP à un protocole ATM. Ainsi, dans un mode de réalisation préféré de l'invention o le second protocole intègre des paramètres de gestion des communications non prévus dans le premier protocole, la procédure d'établissement de connexion, exécutée selon le second protocole dans le traitement d'une requête de connexion en provenance ou à destination de l'application, tient compte de valeurs définies pour
certains au moins desdits paramètres de gestion.
Les valeurs des paramètres de gestion peuvent être choisies en fonction de l'application exécutée. Par exemple, si l'application réalise des transferts de fichiers, on pourra spécifier un débit-crête élevé et de faibles contraintes de retard, tandis que si l'application assure des communications en temps réel (téléphonie, visiophonie...), on recherchera plutôt des retards de transmission très courts. Ce genre de flexibilité est possible dans les réseaux ATM, et constitue une limitation
importante des réseaux IP.
Le choix de ces valeurs des paramètres de gestion peut résulter d'une interrogation de l'utilisateur de l'application, et/ou d'une table d'association mémorisée dans le système, et/ou d'un serveur prévu à cet effet dans le réseau, et/ou d'un mécanisme adaptatif basé sur l'analyse des flux de données réels. Ce choix peut être
piloté par un programme spécifique.
Un autre aspect de la présente invention se rapporte à un module de contrôle d'échanges de messages entre une application exécutée dans un système informatique raccordé -7- à un réseau de communication, et une autre unité accessible par le réseau, l'application étant conçue pour échanger des messages vers une première interface logicielle de programmation adaptée à un premier protocole de communication en réseau, le réseau de communication fonctionnant selon un second protocole de communication en réseau pour lequel le système est équipé d'une seconde interface logicielle de programmation, et l'autre unité étant désignée par un nom d'unité et accessible au moyen d'une adresse de réseau définie selon un format du second protocole. Ce module de contrôle est à installer dans le système. Il comprend des moyens d'attribution d'adresses fictives, pour associer arbitrairement à l'adresse de réseau de l'unité une adresse à usage local définie selon un format du premier protocole, et pour mémoriser cette association, et des moyens de traduction, prévus pour communiquer avec l'application via la première interface de programmation et avec le réseau via la seconde interface de programmation, et agencés d'une part pour transformer chaque message reçu du réseau depuis l'unité identifiée par son adresse de réseau et destiné à l'application en un message traduit incluant l'adresse à usage local associée, qui est fourni à l'application via la première interface de programmation, et d'autre part pour transformer chaque message reçu de l'application à destination de l'unité repérée par l'adresse à usage local en un message traduit selon le second protocole, qui est émis sur le réseau vers l'unité identifiée par son adresse
de réseau.
D'autres particularités et avantages de la présente
invention apparaîtront dans la description ci-après
d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels: - les figures 1 et 2, précédemment commentées, sont des illustrations schématiques de réseaux informatiques; - les figures 3 à 5 sont des schémas montrant un module de contrôle selon l'invention et illustrant
-- 8 --
respectivement des procédures de résolution de nom, de requête locale de connexion et de requête distante de connexion; et - les figures 6 et 7 sont des schémas semblables à celui de la figure 4 et illustrant deux variantes de
procédure de requête locale de connexion.
Le système informatique 1 représenté schématiquement sur les figures 3 à 7 est un terminal équipé de deux interfaces logicielles de programmation (API) 10 et 11. Le terminal 1 héberge des applications 12 conçues pour dialoguer avec d'autres applications par l'intermédiaire de l'API 10. L'API 10 est adaptée à un premier protocole de communication en réseau, ci-après appelé protocole "ancien". Physiquement, le terminal 1 est relié à un réseau de communication R qui fonctionne selon un second protocole, ci-après appelé protocole "nouveau". Le terminal est équipé d'éléments logiciels et matériels 14 fournissant une couche de protocole pour les échanges de données avec le réseau R selon ce protocole nouveau. L'API 11 procure
l'interface du terminal 1 avec ces éléments 14.
La présente invention propose d'installer, entre les API 10 et 11, un module 15 de contrôle d'échanges de messages. Ce module 15 comporte un traducteur de primitives 16, une table d'association 17 et un module 18
de gestion de la qualité de service (QoS).
La table d'association 17 mémorise au moins des triplets <nom, adresse pour la nouvelle API 11, adresse pour l'ancienne API 10>, chaque triplet représentant une unité (terminal et/ou application hébergée par ce terminal) accessible par l'intermédiaire du réseau R. L'adresse pour l'ancienne API 10 est une adresse fictive, générée localement par le terminal 1 afin que l'application 12 puisse continuer à être exécutée en dialoguant avec l'unité existante par l'intermédiaire de
l'API 10.
Dans ces dialogues, le traducteur de primitives 16 reçoit des messages conformes à l'ancienne API 10 et les traduit pour les retransmettre vers la nouvelle API 11, et inversement il reçoit des messages depuis la nouvelle API 11 et les traduit pour les retransmettre vers l'ancienne API 10. Le traducteur de primitives 16 est associé à une table non représentée permettant de convertir les messages relatifs à l'une des API en des messages relatifs à l'autre API et vice versa. Si un message reçu depuis l'API contient l'adresse fictive d'une unité extérieure, le traducteur de primitives 16 interroge la table d'association 17 afin d'obtenir l'adresse de réseau effective de l'unité et de l'inclure dans le message traduit retransmis vers la nouvelle API 11. De même, si un message reçu depuis la nouvelle API 11 contient une adresse de réseau d'une unité extérieure, le traducteur de primitives 16 interroge la table d'association 17 afin de récupérer l'adresse fictive correspondante et de l'inclure
dans le message traduit retransmis vers l'ancienne API 10.
Ainsi, l'application 12 manipule une adresse conformément au protocole adéquat, même si cette adresse ne permet pas
l'acheminement effectif des informations dans le réseau.
On suppose ici que le nouveau protocole supporté par l'API 11 intègre des paramètres de qualité de service qui ne sont pas prévus dans l'ancien protocole supporté par
l'API 10.
Le module 18 sert alors à fournir au traducteur de primitives 16 les paramètres de qualité de service que,
par hypothèse, l'ancienne API 10 est incapable de fournir.
Le module 18 permet ainsi de gérer les conditions de transport dans le réseau R des différents flux de données en provenance ou à destination des applications 12
exécutées dans le système 1.
La figure 3 illustre une procédure de résolution de noms exécutés à l'initiative d'une application 12 du
terminal 1.
L'application 12 commence par délivrer vers l'API 10 une requête de résolution de nom 21 incluant le nom N de
- 10 -
l'unité distante recherchée. Recevant cette requête selon le premier protocole, le traducteur de primitives 16 la transforme en une requête de résolution de nom 22 conforme au second protocole et incluant le nom N. Cette requête 22 est fournie à la couche de protocole 14 à travers la nouvelle API 11. En appliquant le second protocole (échanges de données désignés par les références 23 et 24 sur la figure 3), le terminal 1 interroge un serveur de nommage 6 raccordé au réseau à une adresse déterminée. Le serveur de nommage 6, qui contient les associations entre les noms des unités raccordées au réseau R et leurs adresses dans ce réseau, répond à l'interrogation en renvoyant l'adresse A correspondant au nom d'unité N
inclus dans les requêtes 21,22.
Cette adresse A est fournie au traducteur de primitives 16 à travers la nouvelle API 11 dans un message 25. Le traducteur de primitives 16 génère une adresse à usage local disponible A', définie selon le format de l'ancien protocole. Le traducteur de primitives 16 adresse à la table d'association 17 un message 26 incluant le
triplet (N,A',A) qui est alors mémorisé dans la table 17.
D'autre part, l'adresse fictive A' est retournée à l'application dans un message de réponse 27 à travers
l'ancienne API 10.
A l'issue de cette procédure illustrée par la figure 3, l'application 12 pourra accéder à l'unité N à l'aide de l'adresse fictive A', le traducteur de primitives 16 récupérant alors l'adresse réelle A à l'aide de la table
d'association 17.
L'application 12 peut notamment requérir une connexion vers l'unité 2 dont le nom est N et l'adresse de
réseau A, de la manière illustrée par la figure 4.
Sur la figure 4, la référence 31 désigne la requête de connexion émise par l'application 12 vers l'ancienne API 10. Cette requête 31 inclut l'adresse à usage local A' qui a été fournie à l'application 12 dans le message 27 de la figure 3. A réception de la requête 31 depuis l'API 10,
- 11 -
le traducteur de primitives 16 interroge la table d'association 17 pour récupérer l'adresse de réseau A à
laquelle est associée l'adresse fictive A' (échange 32).
Le module 18 de gestion de la qualité de service peut être interrogé, afin d'obtenir les paramètres de qualité de service pertinents pour l'application considérée (échange
33) de manière synchrone ou asynchrone avec la requête 31.
Le terminal 1 peut alors exécuter, selon le nouveau protocole, une procédure 34-37 d'établissement de connexion avec l'autre unité 2 dont l'adresse de réseau est A. Le traducteur de primitives 16 fournit d'abord à la couche de protocole 14, à travers l'API 11 une requête de connexion 34 incluant l'adresse de réseau A de l'unité distante 2 et les paramètres de qualité de service. Les références 35 et 36 de la figure 4 désignent les messages conventionnels du second protocole échangés pour établir la connexion. Une fois la connexion établie, un message 37 est renvoyé au traducteur de primitives 16, qui le traduit dans un message 38 de validation de la connexion délivré à
travers l'ancienne API 10.
L'application 12 pourra ensuite dialoguer avec l'unité 2, le traducteur de primitives 16 substituant mutuellement les primitives d'échange de messages entre
l'API 10 et l'API 11.
La figure 5 illustre le cas o la requête de connexion avec l'application 12 est issue de l'unité
distante 3.
Lorsque l'application 12 se déclare prête à accepter un connexion via une primitive de l'API 10 (message 40), le traducteur de primitives 16 convertit celle-ci en une primitive de l'API 11 (message 40'), éventuellement avec l'aide du module 13 de gestion de la qualité de service
(message 40ter).
La référence 42 désigne la requête transmise au terminal 1 par le réseau R en réponse à celle 41 émise par l'unité distante 3. Cette requête 42 inclut notamment l'adresse de réseau A de l'unité 3. Si les paramètres du
- 12 -
message 42 sont compatibles avec ceux du message 40', la requête est fournie au traducteur de primitives 16 à travers la nouvelle API 11, dans un message 43. A réception de ce message 43, le traducteur de primitives 16 génère une adresse à usage local disponible A' et commande la mémorisation dans la table 17 (message 44) de l'association entre les adresses A et A' ainsi que le nom N de l'unité distante 3 si ce nom est fourni dans la requête. Le traducteur de primitives 16 retransmet vers l'application 12, à travers l'API 10, une indication de connexion 45 traduite selon le premier protocole et incluant l'adresse fictive A'. La couche de protocole 14 gère l'acceptation de la connexion dans le réseau via le message 49, traduit vers le terminal distant 3 en un
message 50.
Si les paramètres du message 42 ne sont pas compatibles avec ceux du message 40', la couche de protocole 14 émettra un message de refus de connexion 49' vers le réseau R, qui sera traduit en un message 50' vers
le terminal distant 3.
Le traducteur 16 substitue les primitives d'échange
des messages entre les API 10 et 11.
Dans l'exemple illustré par la figure 4 ou 5, le module 18 de gestion de la qualité de service mémorise une table faisant correspondre des applications avec des jeux de valeurs des paramètres de gestion, en l'occurrence des paramètres de qualité de service. Lors d'une interrogation 33,40ter, le traducteur de primitives 16 identifie l'application concernée, et le module 18 retourne les valeurs correspondantes des paramètres de qualité de service. Les valeurs des paramètres contenus dans cette table peuvent être prédéfinis, à partir d'une bibliothèque de
caractéristiques d'applications existantes sur le marché.
On peut également prévoir de définir ou d'ajuster ces valeurs à l'aide d'une application de gestion de la qualité de service 13 prévue dans le terminal 1 et
- 13 -
dialoguant avec le module 18 par l'intermédiaire d'une
interface appropriée 19.
La figure 6 illustre une variante de la figure 4 dans laquelle les valeurs des paramètres de gestion sont obtenus en interrogeant un utilisateur de l'application 12. L'application 13 de gestion de la qualité de service est alors pourvue d'une interface homme-machine permettant d'interroger l'utilisateur. Lorsque le traducteur de primitives 16 requiert les paramètres de qualité de service pour l'application 12 (message 33a), le module 18 adresse un message 33b à l'application 13 via l'interface 19 afin d'interroger l'utilisateur, éventuellement en lui proposant des valeurs par défaut contenues dans une table du module 18. Une fois que l'utilisateur a validé son choix de paramètres, l'application 13 fournit ces paramètres dans un message 33c au module 18 qui les
retransmet au module 16 dans un message 33d.
La figure 7 illustre une autre variante dans laquelle les valeurs des paramètres de gestion sont obtenus en interrogeant un serveur 7 raccordé au réseau R à travers la nouvelle API 11. Lorsque le traducteur de primitives 16 requiert des valeurs pour les paramètres de qualité de service dans un message 33e, le module 18 délivre un message 33f vers i'API 11, incluant l'adresse de réseau du serveur 7 ainsi qu'une identification de l'application concernée 12. Un échange de données 33g, 33h intervient alors avec le serveur 7 par l'intermédiaire du réseau R, et les valeurs de paramètres retournées par le serveur 7 sont fournies au module 18 par un message 33i à travers l'API 11. Ces valeurs sont alors retransmises (éventuellement après modification ou validation par l'utilisateur interrogé au moyen de l'application 13) au traducteur de primitives 16 dans un message 33j. Le serveur 7 relié au réseau peut comprendre, pour toute une bibliothèque d'applications du commerce, des valeurs par défaut des paramètres de qualité de service. Ces valeurs par défaut peuvent alors être aisément modifiées au fur et
- 14 -
à mesure de l'évolution des capacités du réseau et/ou des
éditions de nouvelles versions des applications.
A titre d'exemple, le premier protocole supporté par l'API 10 peut être un protocole IP, tandis que le second protocole supporté par l'API 11 peut être un protocole ATM. Dans le cas d'applications conçues pour fonctionner sous le système d'exploitation Windows (marque de la société Microsoft), l'API 10 est alors l'API Winsock 1 basée sur le protocole IP, tandis que l'API 11 est l'API Winsock 2 avec extensions ATM. Toutes les primitives échangées entre le réseau et les applications passent par le module de contrôle 15. Pour être appelé automatiquement par l'application 12, le module doit posséder le nom standard des sockets pour Windows, à savoir actuellement "Winsock.dll", "Wsock32. dll" ou "ws2 32.dll". On peut ainsi fournir l'interface Winsock standard à l'aide du
module proposé selon l'invention.
Bien entendu, l'invention est applicable à d'autres protocoles. Elle est également applicable lors d'un changement de version du même protocole, pour que des applications conçues pour la première version puissent être reprises à l'identique pour fonctionner avec la seconde version, une application séparée telle que 13 permettant d'intégrer les enrichissements de protocole éventuellement procurés par la nouvelle version. Ainsi, l'invention est notamment applicable à la migration entre
les versions IPV4 et IPV6 du protocole Internet (IP).
-15-
Claims (11)
1. Procédé pour exécuter une application (12) dans un système informatique (1) raccordé à un réseau de communication (R), l'application étant conçue pour échanger des messages vers une première interface logicielle de programmation (10) adaptée à un premier protocole de communication en réseau, ledit réseau de communication fonctionnant selon un second protocole de communication en réseau pour lequel le système est équipé d'une seconde interface logicielle de programmation (11), caractérisé en ce qu'avant un échange de messages entre l'application et une autre unité (2,3) désignée par un nom d'unité (N) et accessible par le réseau au moyen d'une adresse de réseau (A) définie selon un format du second S15 protocole, le système associe arbitrairement à l'adresse de réseau de l'unité une adresse à usage local (A') définie selon un format du premier protocole, et en ce que, lors dudit échange, chaque message reçu par le système selon le second protocole depuis l'unité identifiée par son adresse de réseau et destiné à l'application, est transformé en un message traduit incluant l'adresse à usage local associée, qui est fourni à l'application via la première interface de programmation, et chaque message présenté par l'application sur la première interface de programmation à destination de l'unité repérée par l'adresse à usage local est transformé en un message traduit selon le second protocole, qui est émis sur le réseau vers l'unité
identifiée par son adresse de réseau.
2. Procédé selon la revendication 1, dans lequel l'émission par l'application (12) vers la première interface de programmation (10) d'une requête de résolution de nom (21) relative à une autre unité désignée 16- par un nom d'unité (N) déclenche les opérations suivantes: - le système obtient l'adresse de réseau (A) de l'autre unité sur la base de son nom d'unité; - le système génère une adresse à usage local disponible (A'), définie selon le format du premier protocole; -le système mémorise une association entre le nom d'unité, l'adresse de réseau de l'autre unité et l'adresse à usage local générée; et - un message (27) est délivré à l'application via la première interface de programmation pour lui
fournir l'adresse à usage local générée.
3. Procédé selon la revendication 2, dans lequel le système (1) obtient l'adresse de réseau (A) de l'autre unité en interrogeant un serveur (6) du réseau à travers
la seconde interface de programmation (11).
4. Procédé selon l'une quelconque des revendications
1 à 3, dans lequel l'émission par l'application (12) vers la première interface de programmation (10) d'une requête (31) de connexion avec une autre unité (2) repérée par une adresse à usage local (A') déclenche les opérations suivantes: - le système récupère l'adresse de réseau (A) de l'autre unité, à laquelle est associée ladite adresse à usage local; - le système exécute, selon le second protocole, une procédure (34-37) d'établissement de connexion avec l'autre unité à l'aide de son adresse de réseau; et - après établissement de la connexion selon le second protocole, un message (38) de validation de la connexion est délivré à l'application via la -17-
première interface de programmation.
5. Procédé selon l'une quelconque des revendications
1 à 4, dans lequel la réception par le système (1), selon le second protocole, d'une requête (42) de connexion avec l'application (12) incluant l'adresse de réseau (A) d'une autre unité (3) déclenche les opérations suivantes: - le système génère une adresse à usage local disponible (A'), définie selon le format du premier protocole; - le système mémorise une association entre l'adresse de réseau de l'autre unité et l'adresse à usage local générée; - un message d'indication de connexion (45) incluant l'adresse à usage local générée est présenté à l'application via la première interface de
programmation (10).
6. Procédé selon l'une quelconque des revendication 4 ou 5, dans lequel le second protocole intègre des paramètres de gestion des communications non prévus dans le premier protocole, et dans lequel ladite procédure d'établissement de connexion selon le second protocole tient compte de valeurs définies pour certains au moins
desdits paramètres de gestion.
7. Procédé selon la revendication 6, dans lequel lesdites valeurs des paramètres de gestion sont choisies
en fonction de l'application exécutée (12).
8. Procédé selon la revendication 6 ou 7, dans lequel lesdites valeurs des paramètres de gestion sont obtenues en interrogeant un utilisateur de l'application exécutée
(12).
9. Procédé selon la revendication 7, dans lequel
- 18 -
lesdites valeurs des paramètres de gestion sont obtenues au moyen d'une table, mémorisée dans le système, faisant correspondre des applications (12) avec des jeux de
valeurs de paramètres de gestion.
10. Procédé selon la revendication 7, dans lequel lesdites valeurs des paramètres de gestion sont obtenues en interrogeant un serveur du réseau (7) à travers la
seconde interface de programmation (11).
11. Procédé selon l'une quelconque des revendications
6 à 10, dans lequel on munit le système (1) d'un programme (13) de contrôle desdits paramètres de gestion non prévus dans le premier protocole pour définir des profils de paramètres selon des caractéristiques de l'application exécutée et/ou selon des données fournies par
l'utilisateur.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9808393A FR2781627B1 (fr) | 1998-07-01 | 1998-07-01 | Procede pour executer une application dans un systeme informatique raccorde a un reseau de communication, et module de controle utilisable dans un tel procede |
| PCT/FR1999/001573 WO2000002354A1 (fr) | 1998-07-01 | 1999-06-30 | Procede pour executer une application dans un systeme informatique raccorde a un reseau de communication, et module de controle utilisable dans un tel procede |
| AU43769/99A AU4376999A (en) | 1998-07-01 | 1999-06-30 | Method for executing an application in a computer system connected to a communication network, and control module used in said method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9808393A FR2781627B1 (fr) | 1998-07-01 | 1998-07-01 | Procede pour executer une application dans un systeme informatique raccorde a un reseau de communication, et module de controle utilisable dans un tel procede |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2781627A1 true FR2781627A1 (fr) | 2000-01-28 |
| FR2781627B1 FR2781627B1 (fr) | 2000-10-13 |
Family
ID=9528124
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR9808393A Expired - Fee Related FR2781627B1 (fr) | 1998-07-01 | 1998-07-01 | Procede pour executer une application dans un systeme informatique raccorde a un reseau de communication, et module de controle utilisable dans un tel procede |
Country Status (3)
| Country | Link |
|---|---|
| AU (1) | AU4376999A (fr) |
| FR (1) | FR2781627B1 (fr) |
| WO (1) | WO2000002354A1 (fr) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1995031060A1 (fr) * | 1994-05-09 | 1995-11-16 | Motorola Inc. | Procede pour transmettre des paquets de donnees, en fonction du type de message |
-
1998
- 1998-07-01 FR FR9808393A patent/FR2781627B1/fr not_active Expired - Fee Related
-
1999
- 1999-06-30 AU AU43769/99A patent/AU4376999A/en not_active Abandoned
- 1999-06-30 WO PCT/FR1999/001573 patent/WO2000002354A1/fr active Application Filing
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1995031060A1 (fr) * | 1994-05-09 | 1995-11-16 | Motorola Inc. | Procede pour transmettre des paquets de donnees, en fonction du type de message |
Non-Patent Citations (5)
| Title |
|---|
| ALMESBERGER W ET AL: "GUARANTEEING QUALITY OF SERVICE FOR THE WEB USING ATM", DATA HIGHWAY, 1 January 1995 (1995-01-01), pages A21/1 - A21/16, XP000570052 * |
| CHEN X ET AL: "EVOLUTION OF ATM INTERNETWORKING", BELL LABS TECHNICAL JOURNAL, vol. 2, no. 2, 21 March 1997 (1997-03-21), pages 82 - 110, XP000695170 * |
| KEMPAINEN S: "GIGABIT ETHERNET AND ATM GO NECK AND NECK IN THE COMMUNICATIONS RACE", EDN ELECTRICAL DESIGN NEWS, vol. 42, no. 1, 2 January 1997 (1997-01-02), pages 32, 34 - 38, 40, 42, 44, 46, 48, XP000721999 * |
| POZEFSKY D ET AL: "MULTIPROTOCOL TRANSPORT NETWORKING: ELIMINATING APPLICATION DEPENDENCIES ON COMMUNICATIONS PROTOCOLS", IBM SYSTEMS JOURNAL, vol. 34, no. 3, 21 June 1995 (1995-06-21), pages 472 - 499, XP000529593 * |
| SUNG J: "WWW Browser and Server with Guaranteed QoS Support over Native ATM API", PROCEEDINGS TWELFTH INTERNATIONAL CONFERENCE ON INFORMATION NETWORKING (ICOIN-12), 21 January 1998 (1998-01-21) - 23 January 1998 (1998-01-23), TOKYO (JP), pages 212 - 217, XP002096226 * |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2781627B1 (fr) | 2000-10-13 |
| WO2000002354A1 (fr) | 2000-01-13 |
| AU4376999A (en) | 2000-01-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR101066757B1 (ko) | 미디어 세션 확립 방법 | |
| KR100723320B1 (ko) | 인터넷 클라이언트-서버 멀티플렉서 | |
| US7003574B1 (en) | Session load balancing and use of VIP as source address for inter-cluster traffic through the use of a session identifier | |
| EP0822692A2 (fr) | API orientée objet pour client et passerelle pour la réalisation de OLTP sur Internet | |
| EP2271054B1 (fr) | Procédé de commande d'une entité d'un réseau distant à partir d'un réseau local | |
| EP1169837A1 (fr) | Procede de gestion de transmissions de donnees multimedias via internet et carte a puce pour la mise en oeuvre du procede | |
| WO2006115526A2 (fr) | Appareil et procede de delivrance d'un noeud relais communautaire | |
| FR2893803A1 (fr) | Methode de communication entre une cartre (u)sim en mode serveur et un client | |
| FR2869180A1 (fr) | Systeme de communication et dispositif de passerelle | |
| FR2842377A1 (fr) | Systeme et procede de configuration automatique et de lancement d'applications clients telnet 3270 dans un environnement windows | |
| EP2543165B1 (fr) | Pilotage d'un dispositif d'un reseau distant a partir d'un reseau local | |
| EP2807815B1 (fr) | Système et procédö de controle d'une requête dns | |
| WO1997005727A1 (fr) | Dispositif, procede et routeur d'interconnexion de reseaux | |
| FR2851867A1 (fr) | Ordonnancement d'adresses dans serveur de noms de domaine | |
| FR2781627A1 (fr) | Procede pour executer une application dans un systeme informatique raccorde a un reseau de communication, et module de controle utilisable dans un tel procede | |
| EP2169903A1 (fr) | Dispositif et procédé de routage permettant des traductions d'adresses en cascade dans un réseau | |
| FR3023098A1 (fr) | Procede et systeme de traitement d'une demande de resolution d'un nom d'un serveur, emise par une application cliente sur un reseau de communication. | |
| FR2837045A1 (fr) | SYSTEME ET PROCEDE DE GESTION DE TRANSFERT D'INFORMATIONS SUR UN RESEAU CONFORME A UNE NORME DE TRANSMISSION DE DONNEES, NOTAMMENT LA NORME UPnP, MACHINE D'INTERFACAGE ET D'EMULATION ET PROGRAMME D'ORDINATEUR CORRESPONDANTS | |
| FR2843847A1 (fr) | Systeme permettant d'etablir une connexion telnet avec un dispositif eloigne depourvu de modem | |
| WO2002052439A1 (fr) | Serveur d'annuaire reparti | |
| EP1432213B1 (fr) | Plate-forme de médiation et réseau de transport de messages | |
| CA2446774C (fr) | Systeme et procede de communication entre stations traitant des dossiers communs | |
| EP2384566B1 (fr) | DETECTION D'UN DISPOSITIF DE CONTROLE UPnP ET ÉTABLISSEMENT D'UNE CONNEXION AVEC UN TERMINAL | |
| EP4362391A1 (fr) | Procédé de gestion d'accès d'un utilisateur à au moins une application, programme d'ordinateur et système associés | |
| FR2853177A1 (fr) | Procede et systeme de controle d'acces a des sites internet |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20060331 |