FR2820922A1

FR2820922A1 - Procede pour assurer le temps de latence des communications entre au moins deux points de passage de donnees

Info

Publication number: FR2820922A1
Application number: FR0102172A
Authority: FR
Inventors: Miguel Miguel De
Original assignee: Thomson CSF SA
Current assignee: Thales SA
Priority date: 2001-02-12
Filing date: 2001-02-12
Publication date: 2002-08-16
Anticipated expiration: 2021-02-12
Also published as: EP1382148A2; WO2002065680A2; US20040068558A1; FR2820922B1; WO2002065680A3

Abstract

Selon l'invention, on assure le temps de latence des communications entre au moins deux points de passage de données en mettant en oeuvre un protocole de réservation de ressources dans la couche MW (10) intermédiaire entre le système d'exploitation (11) et les couches d'application (9), et ce, en intégrant les processus et services de réservation de ressources (15) et les processus de communication dans la couche MW.

Description

PROCEDE POUR ASSURER LE TEMPS DE LATENCE DES COMMUNICATIONS
ENTRE AU MOINS DEUX POINTS DE PASSAGE DE DONNEES
La présente invention a pour objet un procédé pour assurer le temps de latence des communications entre au moins deux points de passage de données.

Dans les systèmes de traitement de données distribuées à fonctionnement en temps réel, les exigences en matière de temps de traitement obligent à prendre en compte la prédiction du temps de traitement. Les techniques de réservation de ressources offrent des solutions à ces exigences, mais dans certains cas seulement, comme on le verra ci-dessous.

Le langage Java a déjà été utilisé dans les systèmes à fonctionnement en temps réel.

Cependant, ce langage ne permet pas de limiter facilement les temps de latence et les temps de blocage, en particulier pour des traitements tels que le ramassage de miettes ( garbage collection en anglais), les algorithmes de planification ( scheduling algorithms en anglais) et les protocoles des processus de synchronisation. Des groupes de travail Java ( Java Consortium , Real-Time for Java Experts Group ) ont proposé d'étendre les spécifications et les A. P. I. (Interfaces de programmation d'applications) de Java. Ces extensions permettent de mettre en oeuvre des programmes à possibilité de prédiction en Java, en fournissant des possibilités de réservation du temps de calcul, et d'autres ressources telles que le temps de ramassage des déchets. Cependant, ces extensions ne prennent pas en compte les principes de programmation distribuée inhérents à Java, et ne proposent pas de solutions à l'absence actuelle de possibilité de prédiction des caractéristiques distribuées de Java, telles que R. M. I. ( Remote Method Invocation ), E. J. B. ( Enterprise Java Beans ) et J. N. D. I.

( Java Naming and Directory Interface ). Pour limiter les effets de ces problèmes, D. Jensen a établi avec un groupe la spécification J. S. R. 000050 Distributed Real-Time Systems , J. S. R. signifiant Java Specification Request . Ce groupe, ainsi que la Société SUN ont établi une nouvelle J. S. R. afin de développer les concepts liés à cette spécification.

L'objectif principal de cette requête Java est d'étendre les spécifications de Java Temps-réel et de Java lui-même afin de rendre possible la prédiction du temps de traitement des programmes Java dans une communication noeud à noeud.

Par ailleurs, on connaît une plate-forme logicielle ( Framework en anglais) de couche intermédiaire entre le système d'exploitation et les couches d'application (couche

intermédiaire couramment dénommée Middleware en anglais, et qui sera dénommée MW par la suite) appelé CORBA. Les programmes Java-RMI et CORBA comportent une couche MW permettant aux utilisateurs d'invoquer des opérations effectuées par des objets

distribués. Un groupe de travail bien connu, dénommé O. M. G. ( Object Management Group ) a publié en Mars 1999 un standard OMG pour les applications CORBA en temps réel. En Août 2000, ce groupe publie les spécifications Dynamic Scheduling Real-Time CORBA étendant le standard précité afin de lui faire supporter les algorithmes de planification dynamique qui n'étaient pas prises en compte par le standard CORBA temps réel. Le but de ces spécifications est d'étendre le standard CORBA afin de faciliter sa possibilité de prédiction de bout en bout des activités d'un système distribué et de fournir un support pour la gestion des ressources de l'environnement CORBA. La faculté de prédire de bout en bout l'exécution des tâches en temps voulu n'est possible que si l'on respecte les priorités des processus entre client et serveur pour résoudre les problèmes d'accaparement de ressources ( resource contention en anglais), si l'on limite les inversions de priorité d'utilisation de ressources et si l'on limite le temps de latence des invocations d'opérations.

Mais il est clairement précisé dans cette publication que les auteurs ne proposent pas de solution permettant de limiter les temps de latence relatifs au système d'exploitation, à des applications spécifiques et surtout aux moyens de communication.

La présente invention a pour objet un procédé permettant de prédire le temps de traitement de programmes, en particulier en langage Java temps réel sur plates-formes clientserveur, exécutés sur plusieurs noeuds et utilisant la méthode RMI dans la couche MW .

De façon plus générale, la présente invention a pour objet un procédé permettant d'assurer le temps de latence des communications entre au moins deux points (noeuds) par réservation des ressources de l'infrastructure de communication dans une couche MW.

Le procédé de l'invention met en oeuvre un protocole de réservation de ressources dans la couche M. W., en intégrant les processus et services de réservation de ressources et les processus de communication dans la couche MW. Ainsi, cette intégration rend compatibles les protocoles réalisant la communication au niveau de la couche MW et les protocoles de réservation de ressources.

Selon un autre aspect de l'invention, on réalise les extensions de l'interface de la couche MW avec l'application pour lui donner l'accès aux services de réservation. Ces extensions permettent de faire la spécification des besoins en temps lorsque l'on établit la communication distante, et d'assurer un temps de réponse déterminé.

La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de réalisation, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel :

-La figure 1 est un diagramme d'un noeud de réservation de ressources connu, et ZD -La figure 2 est un diagramme simplifié des éléments essentiels mettant en oeuvre le procédé de l'invention.

La présente invention est décrite ci-dessous en référence à l'échange de données entre deux noeuds ou plus (micro-odinateurs par exemple) reliés entre eux par un réseau tel qu'Internet et utilisant un protocole tel que Java-RMI, mais il est bien entendu qu'elle n'est pas limitée à cette seule application et à ce seul protocole, et qu'elle peut être mise en oeuvre dans d'autres applications nécessitant la transmission de données par paquets entre au moins deux points (ou noeuds), que ce soit selon un protocole Java-RMI, CORBA, ou autre.

On a illustré en figure 1 le principe de mise en oeuvre d'un protocole connu de réservation de ressources via une interface API (Interface de programmation d'application).

Ce protocole est principalement mis en oeuvre dans un noeud par une routine d'arrière-plan 1 (communément appelée DAEMON ). Ce protocole est ici du type RSVP ( Resource ReServation Protocole ), bien connu en soi. La routine 1 est en liaison bidirectionnelle avec un programme 2 de contrôle de processus et un programme 3 de contrôle d'admission, ainsi qu'avec une interface 4 de réservation (RAPI), elle-même en liaison bidirectionnelle avec une application 5. La routine 1 commande un classificateur de paquets 6 et un planificateur d'envoi de paquets 7. Le classificateur 6 reçoit un flot de données 8 qu'il réarrange en paquets, et le planificateur 7 envoie ces paquets selon les possibilités du réseau par lequel ils doivent transiter. La plupart des fonctions de l'API 4 utilisent en tant que paramètre d'entrée un descripteur de session. Une session est produite dans le noeud émetteur, et le noeud récepteur identifie les adresses socket des paquets de la session (les adresses IP et le numéro de port du récepteur). L'interface 4 doit être utilisée conjointement avec une interface API de socket . Les descripteurs de fichiers de socket , qui fournissent les fonctions de socket ( bound , accept et connect ) sont utilisés pour créer des sessions de réservation de l'interface 4.

La routine 1 communique avec les routines des routeurs inclus sur le trajet de la session, et toutes ces routines assurent ensemble la réservation des ressources indiquées par l'émetteur et le récepteur. Les objets de la réservation permettent de spécifier le débit des grappes de jetons ( token bucket en anglais), la profondeur de ces grappes, le débit maximal et la dimension maximale des grappes. Dans le processus de réservation, la caractérisation du flux de données décrit la qualité désirée de service. Le paramètre qualité de service garantie assure que les paquets de données vont arriver à destination dans le

temps imparti garanti et ne seront pas rejetés s'il y avait des débordements dans les files d'attente. Ce paramètre caractérise la largeur de bande maximale pour une transmission de bout en bout sur le trajet des données. L'application du récepteur fournit une spécification de filtre indiquant aux routeurs intermédiaires à services de réservation quels émetteurs doivent faire partie du processus de réservation. Ainsi, les applications du récepteur peuvent rattacher la qualité de service correspondante aux seules données provenant des applications de l'émetteur.

Dans le diagramme de noeud (émetteur ou récepteur) de la figure 2, on a indiqué les principaux composants logiques intervenant dans un processus de réservation de ressources conforme à l'invention. Les couches de ce noeud sont : l'application 9, la couche MW 10, et le système d'exploitation 11. L'application 9 communique avec la couche 10 par l'intermédiaire d'une interface API de communication 12 et lui envoie ses requêtes de réservation via une interface API de réservation 13.

La couche 10 communique avec la routine de protocole de communication 14 du système d'exploitation 11. D'autre part, une routine de réservation de ressources 15 de la couche 10 communique avec une routine de protocole de réservation 16 du système d'exploitation 11. De cette façon, la routine 16 du système d'exploitation n'a pas besoin d'être adaptée à chaque nouvelle application, et elle peut donc être une routine standard. Seule la routine 15 est spécifique de la couche MW 10, mais comme elle est située dans la couche MW 10, elle est adaptable à chaque application, car la couche 10 est bien plus facile à modifier que le système d'exploitation. Dans l'exemple décrit ici, la couche 10 est une couche Java-RMI, mais pourrait être de type CORBA ou autre.

Le but de l'invention est de mettre en oeuvre des logiciels distribués Java (ou similaire) produisant des processus d'invocation distante et des réponses en un temps limité que l'on peut prédire. Les protocoles de réservation fournissent un support permettant de limiter le temps de transit au cours de communications. Ces protocoles ont deux types différents de sessions : sessions d'invocations associées à l'invocation distante et sessions de réponses associées aux réponses aux invocations distantes.

Différentes solutions peuvent associer la réservation aux différents éléments logiciels.

Selon un aspect préféré de l'invention, cette association se fait selon l'approche des références distantes. Dans ces cas, chaque référence distante spécifie la répartition temporelle de ses invocations, et une réservation spécifique est faite pour chaque référence distante. Selon l'invention, les références distantes Java identifient l'émetteur de la réservation à l'origine de la session d'invocation, et le serveur en fait autant pour les sessions de réponse. La référence

distante est associée à deux sessions de réservation. Deux références distantes différentes, faisant partie du même objet ou machine virtuelle peuvent référencer le même serveur et peuvent être associées à des réservations distantes.

Parmi les autres solutions possibles d'association de réservation, on peut d'abord noter l'approche objet client , selon laquelle le client spécifie la distribution temporelle de ses invocations distantes pour chaque serveur. Selon l'invention, on associe alors l'objet client à l'émetteur des sessions d'invocation et au récepteur des sessions de retour. Du côté client, on associe deux sessions de réservation à chaque serveur utilisé. Cette solution réserve des ressources pour chaque communication d'un client à un serveur.

Une autre approche pouvant être mise en oeuvre par l'invention dans le cas de l'utilisation du langage Java. Cette approche est celle de la machine Java, selon laquelle la machine virtuelle spécifie la distribution temporelle des ses invocations distantes pour chaque serveur. Selon l'invention, on associe la machine virtuelle client à l'émetteur des sessions d'invocation et au récepteur des sessions de réponse. On associe à la machine virtuelle deux sessions de réservation pour chaque serveur distant. Cette solution permet de réserver des ressources à chaque communication entre une machine client et un serveur.

Comme précisé ci-dessus, la solution préférée de l'invention est l'approche références distantes parce qu'elle permet à différentes tâches ( threads ) d'établir leur propre réservation, et ainsi de pouvoir encapsuler leur propre réservation, ce qui évite les effets de concurrence que peuvent produire les autres solutions. En effet, selon la deuxième et la troisième approches décrites ci-dessus, une deuxième tâche peut modifier la réservation d'une première tâche, ce qui va en changer le temps de réponse. Dans ces deux dernières solutions, les tâches doivent approuver leur temps de réservation. Selon la première approche, la référence peut être une variable locale de la tâche, et la réservation est fixe au sein de la tâche.

Dans la première approche, le serveur et les références négocient la réservation à partir d'un ensemble Java-Réservation qui est une extension de l'interface API de Java-RMI..

Ces extensions permettent l'identification des méthodes qui seront invoquées par la référence vers le serveur, ainsi que la distribution temporelle des invocations. Un autre type de réservation est la réservation simple, selon laquelle les références établissent la largeur de bande des sessions d'invocation et de réponse. La deuxième approche est intéressante lorsque la taille de l'ensemble des invocations et des réponses ne peut pas être évaluée statistiquement.

La méthode d'invocation RMI peut être mise en oeuvre avec l'outil JDK ( Java Development Kit ), dans sa version 1. 2 par exemple. Cependant, cette mise en oeuvre pose plusieurs problèmes que l'invention résout de la façon décrite ci-dessous, dans le cas de l'approche des références distantes.

Lorsque deux tâches utilisent en parallèle la même référence distante, elles utilisent deux connexions différentes, et donc deux sockets différents. Ceci peut également se produire lorsque l'on utilise deux rappels ( callbacks en anglais) de type RMI, et si le client rappelle le serveur à partir du rappel client, alors que le premier rappel n'est aps encore fini. Dans ce cas, la procédure RMI utilise deux sockets pour faire communiquer la même référence avec le même serveur. Ce procédé présente des incompatibilités avec l'approche des sessions de réservation par les interfaces API, et avec les trois approches décrites ci-dessus (association de la réservation aux différents éléments logiciels). En effet, le protocole RSVP est orienté sessions , alors que l'implémentation JDK 1.2 est orientée connexions .

L'implémentation JDK 1.2 utilise un nombre non limité de sockets pour chaque référence, tandis que les réservations sont associées à des sessions RSVP qui ne requièrent qu'un seul socket .

Pour résoudre ce problème, l'invention propose la solution suivante, valable dans le cas de l'utilisation de Java-RMI, avec l'outil JDK 1.2. Les sessions de réservation associées aux communications entre références distantes et serveur nécessitent un seul socket pour toutes les invocations. L'outil JDK 1.2 utilise (ou réutilise) une connexion pour l'invocation, et un socket est associé à chaque connexion. L'implémentation JDK 1.2 ne permet pas d'utiliser la même connexion en parallèle pour deux invocations, sinon cela produirait des conditions de concurrence pendant les séquences d'envoi de données d'appel ( marshalling en anglais) et la création d'appels distants. L'approche orientée connexion permet d'associer les réponses aux invocations (les valeurs retournées sont envoyées en utilisant la même connexion que pour l'invocation), ce qui peut être à l'origine d'une autre condition de concurrence si l'on ne respecte pas la solution présente. Le protocole JRMP (voir l'article de SUN MICROSYSTEMS : Java Remote Method Invocation Specification paru en Octobre 1998) assure des possibilités de multiplexage. Leur but est de fournir un modèle dans lequel deux points terminaux peuvent ouvrir chacun des connexions multiples en duplex intégral avec l'autre point dans un environnement dans lequel seulement l'un des points terminaux est capable d'ouvrir une telle connexion bidirectionnelle en utilisant d'autres possibilités. Dans le cas présent, on utilise les facultés de multiplexage de l'invocation RMI pour réutiliser le même socket pour toutes les méthodes d'invocation de la même référence, et la session de

réservation est générée avec ce socket . L'outil JDK 1. 2 reconnaît l'arrivée de paquets multiplexés dans la tâche de transport ( TCPTransport ) et produit un canal TCP multiplex pour acheminer ces paquets. Cependant, cet outil ne permet pas de configurer le multiplexage client et l'implémentation côté récepteur entraîne des temps de blocage non limités : l'implémentation fait appel à des instructions wait d'attente et inclut des tâches nouvelles qui ne limitent pas les temps de blocage. Il faut alors adapter les classes serveur de l'outil JDK, comme du côté client.

Un autre problème lié à JDK 1.2 est le suivant. L'adresse de socket est encapsulée dans le sous-système JDK. Cette information est pourtant nécessaire pour créer des sessions de réservation. Si l'on crée une nouvelle couche (couche de réservation), le couches des références et de transport doivent inclure des fonctions nouvelles. L'invention propose de modifier l'implémentation de JDK 1.2 pour que le socket soit associé à la référence distante en utilisant les extensions ayant servi à la construction des sessions de réservation..

Claims

REVENDICATIONS 1. - Procédé pour assurer le temps de latence des communications entre au moins deux points de passage de données, caractérisé en ce qu'il met en oeuvre un protocole de réservation de ressources dans la couche MW (10) intermédiaire entre le système d'exploitation (l l) et les couches d'application (9), en intégrant les processus et services de réservation de ressources (15) et les processus de communication dans la couche MW.
2.-Procédé selon la revendication 1, caractérisé en ce que l'on réalise les extensions de l'interface de la couche MW avec l'application pour lui donner l'accès aux services de réservation.
3.-Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que l'on associe la réservation aux différents éléments logiciels intervenant dans la communication selon l'approche des références distantes.