EP1382148A2 - Procede pour assurer le temps de la latence des communications entre au moins deux points de passage de donnees - Google Patents

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

Info

Publication number
EP1382148A2
EP1382148A2 EP02706845A EP02706845A EP1382148A2 EP 1382148 A2 EP1382148 A2 EP 1382148A2 EP 02706845 A EP02706845 A EP 02706845A EP 02706845 A EP02706845 A EP 02706845A EP 1382148 A2 EP1382148 A2 EP 1382148A2
Authority
EP
European Patent Office
Prior art keywords
reservation
remote
java
protocol
layer
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.)
Withdrawn
Application number
EP02706845A
Other languages
German (de)
English (en)
Inventor
Miguel Thales Intellectual Property DE MIGUEL
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales SA
Original Assignee
Thales SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Thales SA filed Critical Thales SA
Publication of EP1382148A2 publication Critical patent/EP1382148A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/803—Application aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • 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/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the present invention relates to a method for ensuring the latency of communications between at least two data crossing points.
  • the Java language has already been used in real-time systems.
  • Java working groups (“Java Consortium”, “Real-Time for Java Experts Group”) have proposed to extend the specifications and the A.P.I. (Application programming interfaces) of Java. These extensions make it possible to implement programs with the possibility of prediction in Java, by providing possibilities for reserving the calculation time, and other resources such as the time for collecting waste.
  • Java extensions do not take into account the principles of distributed programming inherent in Java, and do not offer solutions to the current lack of possibility of predicting the distributed characteristics of Java, such as R.M.I. ("Remote Method Invocation"), E.J.B. ("Enterprise Java Beans”) and J.N.D.I. ("Java Naming and Directory Interface”).
  • This group along with the SUN Company, has established a new J.S.R. in order to develop the concepts related to this specification.
  • the main objective of this Java request is to extend the specifications of Java Real-Time and Java itself in order to make it possible to predict the processing time of Java programs in node-to-node communication.
  • the subject of the present invention is a method for predicting the processing time of programs, in particular in real time Java language on client-server platforms, executed on several nodes and using the RMI method in the "MW" layer. More generally, the subject of the present invention is a method for ensuring the latency of communications between at least two points (nodes) by reserving the resources of the communication infrastructure in an MW layer.
  • the method for ensuring the latency time of communications between at least two data crossing points according to an object-oriented protocol Java-RMI or CORBA is characterized in that it implements in each crossing point an RSNP resource reservation protocol in the Java-RMI or CORBA layer, intermediate between the operating system and the application layers, by integrating the resource reservation processes and services and the communication processes in the MW layer .
  • extensions of the interface of the MW layer are carried out with the application to give it access to reservation services according to the RSVP protocol.
  • the reservation is associated with the various software elements involved in the communication according to the approach of remote references.
  • the operations associated with the remote references include the operations of determining the bandwidth to be used, the maximum size of the data packets and the maximum size of the buffers required.
  • the RSNP protocol ensures the reservation of resources on the path between two remote Java-RMI or CORBA objects. Each remote reference specifies the time distribution of its invocations, and a specific reservation is made for each remote reference.
  • the method of the invention implements a resource reservation protocol in the M.W. layer, by integrating the resource reservation processes and services and the communication processes in the MW layer.
  • this integration makes compatible the protocols carrying out the communication at the MW layer and the resource reservation protocols.
  • extensions are made to the interface of the MW layer with the application to give it access to reservation services, these extensions make it possible to specify the time requirements when establishing the remote communication, and to ensure a determined response time.
  • FIG. 1 is a diagram of a known resource reservation node
  • FIG. 2 is a simplified diagram of the essential elements implementing the method of the invention.
  • the present invention is described below with reference to the exchange of data between two or more nodes (micro-computers for example) linked together by a network such as the Internet and using a protocol such as Java-RMI, but it it is understood that it is not limited to this single application and to this single protocol, and that it can be implemented in other applications requiring the transmission of data in packets between at least two points (or nodes ), whether according to a Java-RMI protocol, or CORBA.
  • Routine 1 is in bidirectional connection with a process control program 2 and an admission control program 3, as well as with a reservation interface 4 (LPR) ), as described for example in the document by R. Braden and D.
  • a session is produced in the sending node, and the receiving node identifies the "socket” addresses of the session packets (the JP addresses and the port number of the receiver).
  • Interface 4 must be used in conjunction with a “socket” API interface.
  • “Socket” file descriptors, which provide “socket” functions (bound “,” accept “and” connect ") are used to create reservation sessions for interface 4.
  • Routine 1 communicates with the routines of the routers included in the session path, and all these routines together ensure the reservation of the resources indicated by the transmitter and the receiver.
  • the objects of the reservation make it possible to specify the speed of the token bucket, the depth of these clusters, the maximum flow and the maximum dimension of the clusters.
  • the characterization of the data flow describes the desired quality of service.
  • the “guaranteed quality of service” parameter ensures that the data packets will arrive at their destination within the guaranteed time limit and will not be rejected if there were overflows in the queues. This parameter characterizes the maximum bandwidth for end-to-end transmission on the data path.
  • the receiver application provides a filter specification telling intermediary routers to reservation services which transmitters should be part of the reservation process. Thus, the applications of the receiver can relate the corresponding quality of service to the only data coming from the applications of the transmitter.
  • the main logic components involved in a resource reservation process in accordance with the invention have been indicated.
  • the layers of this node are: the application 9, the MW layer 10, and the operating system 11.
  • the application 9 communicates with the layer 10 via a communication API interface 12 and sends it its reservation requests via a reservation API 13.
  • Layer 10 communicates with the communication protocol routine 14 of the operating system 11.
  • an RSVP resource reservation routine 15 of layer 10 communicates with a reservation protocol routine 16 of the operating system 11.
  • the routine 16 of the operating system does not need to be adapted to each new application, and it can therefore be a standard routine.
  • routine 15 is specific to the MW layer 10, but since it is located in the MW layer 10, it is adaptable to each application, since the layer 10 is much easier to modify than the operating system.
  • layer 10 is a Java-RMI layer, but could be of CORBA type.
  • the object of the invention is to implement distributed Java software (or similar) producing remote invocation processes and responses in a limited time which can be predicted.
  • Reservation protocols provide support allowing to limit the transit time during communications. These protocols have two different types of sessions: invocation sessions associated with remote invocation and response sessions associated with responses to remote invocations.
  • each remote reference specifies the temporal distribution of its invocations, and a specific reservation is made for each remote reference.
  • the Java remote references identify the sender of the reservation at the origin of the invocation session, and the server does the same for the response sessions.
  • the remote reference is associated with two reservation sessions. Two different remote references, belonging to the same object or virtual machine can reference the same server and can be associated with remote reservations.
  • client object approach, according to which the client specifies the time distribution of its remote invocations for each server.
  • the client object is then associated with the transmitter of the invocation sessions and with the receiver of the sessions. return.
  • two reservation sessions are associated with each server used. This solution reserves resources for each communication from a client to a server.
  • This approach is that of the Java machine, according to which the virtual machine specifies the time distribution of its remote invocations for each server.
  • the client virtual machine is associated with the transmitter of the invocation sessions and the receiver of the response sessions.
  • We associate to the virtual machine two reservation sessions for each remote server. This solution allows resources to be reserved for each communication between a client machine and a server.
  • “Remote references” because it allows different tasks (“threads”) to establish their own reservation, and thus to be able to encapsulate their own reservation, which avoids the effects of competition that other solutions can produce.
  • a second task can modify the reservation of a first task, which will change the response time.
  • the tasks must approve their reservation time.
  • the reference can be a local variable of the task, and the reservation is fixed within the task.
  • the server and the references negotiate the reservation from a Java-Reservation set which is an extension of the Java-RMI API interface.
  • the RMI invocation method can be implemented with the JDK tool (“Java Development Kit”), in version 1.2 for example.
  • JDK tool Java Development Kit
  • this implementation poses several problems which the invention solves in the manner described below, in the case of the approach of remote references.
  • the JDK 1.2 implementation uses an unlimited number of "sockets" for each reference, while reservations are associated with RSNP sessions which require only one "socket".
  • the invention proposes the following solution, valid in the case of the use of Java-RMI, with the JDK 1.2 tool.
  • the reservation sessions associated with communications between remote references and the server require a single "socket" for all invocations.
  • the JDK 1.2 tool uses (or reuses) a connection for invocation, and a "socket" is associated with each connection.
  • the JDK 1.2 implementation does not allow the same parallel connection to be used for two invocations, otherwise this would produce conditions of competition during the sequences of sending of call data ("marshalling" in English) and the creation of remote calls.
  • the “connection-oriented” approach makes it possible to associate responses with invocations (the returned values are sent using the same connection as for the invocation), which can be the source of another condition of competition if the present solution is not respected.
  • the JRMP protocol (see the article by SUN MICROSYSTEMS: "Java Remote Method Invocation Specification” published in October 1998) provides multiplexing possibilities.
  • JDK 1.2 Another problem with JDK 1.2 is as follows.
  • the "socket" address is encapsulated in the JDK subsystem. This information is however necessary to create reservation sessions. If a new layer (reservation layer) is created, the reference and transport layers must include new functions.
  • the invention proposes to modify the implementation of JDK 1.2 so that the "socket" is associated with the remote reference by using the extensions that were used to build the reservation sessions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multi Processors (AREA)
  • Communication Control (AREA)
  • Stored Programmes (AREA)
  • Mobile Radio Communication Systems (AREA)

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 Spécification 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 pris 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.
On connaît d'après l'article de Chao-Ju Hou , Ching Chih Han et Yao-Min Chen "Communication middleware and software for QoS control in distributed real-time environments", publié dans COMPUTER SOFTWARE AND APPLICATIONS CONFERENCE, 1997. COMPSAC '97. PROCEEDINGS, THE TWENTY FIRST ANNUAL INTERNATIONAL WASHINGTON, DC, USA 13-15 AUG. 1997, LOS ALAMITOS, CA, USA, IEEE COMPUT. SOC, US. du 13 Août 1997, pages 558 à 564, un procédé de. communication faisant appel au protocole RSNP, mais ce document n'apporte aucune solution aux problèmes qu'entraîne l'utilisation de ce protocole, et, d'autre part, ce document évoque le M.W. , mais ne l'associe ni à CORBA ni à JANA- RMI.
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 client- serveur, 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. Selon l'invention, le procédé pour assurer le temjps de latence des communications entre au moins deux points de passage de données selon un protocole orienté objet Java- RMI ou CORBA, est caractérisé en ce qu'il met en oeuvre dans chaque point de passage un protocole RSNP de réservation de ressources dans la couche de Java-RMI ou CORBA, intermédiaire entre le système d'exploitation et les couches d'application , en intégrant les processus et services de réservation de ressources et les processus de communication dans la couche MW.
Selon une caractéristique 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 selon le protocole RSVP.
Selon une autre caractéristique de l'invention, on associe la réservation aux différents éléments logiciels intervenant dans la communication selon l'approche des références distantes. Les opérations associées aux références distantes comprennent les opérations de détermination de la largeur de bande à utiliser, la taille maximale des paquets de données et la taille maximale des tampons nécessaires. Le protocole RSNP assure la réservation des ressources sur le trajet compris entre deux objets distants Java-RMI ou CORBA. 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.
Ainsi, 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. Il en résulte que 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.
Grâce au fait 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, 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 nœud de réservation de ressources connu, et
-La figure 2 est un diagramme simplifié des éléments essentiels mettant en œuvre 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, ou CORBA. Ces protocoles sont décrits par exemple dans les spécifications de la Société Sun Microsystems (Java Remote Method Invocation Spécification pour JDK 1.2 ) et dans le document du groupe de travail "Object Management Group" intitulé "Real-Time CORBA 1.0 Spec, OMG Document number ptc/00-09-02", respectivement.
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 Réservation Protocole») , bien connu en soi, par exemple d'après l'article de Zhang, S. Berson, S. Herzog et S. Jamin, intitulé "Resource ReSerVation Protocol (RSNP) - Version 1 Function Spécification ", Internet RFC 2205, 1997. 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) , telle que décrite par exemple dans le document de R. Braden et D. Hoffman : "RAPI - An RSNP Application Programming Interface", Internet Draft d'Août 1998 fonctionnant avec une "Windows QoS Socket Library" décrite dans le document de Y. Bernet, J. Stewart, R. Yavatkar, D. Andersen, C. Tai, B. Quinn et K. Lee , intitulé "Winsock Generic QoS Mapping (Draft)", de la Société Microsoft. Cette interface 4 est 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 J-P 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 RSVP 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 .
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 œuvre avec l'outil JDK (« Java Development Kit »), dans sa version 1.2 par exemple. Cependant, cette mise en œuvre 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 pas 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 RSNP 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 RSNP 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 Spécification » 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 multiplexes dans la tâche de transport (« TCPTransport ») et produit un canal TCP multiplexe 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.
Ces problèmes et leurs solutions sont décrits dans l'article de Miguel A. de Miguel paru dans "Proceedings of ISORC 2001 (Mai 2001) et intitulé "Solutions to make Java RMI Time Predictable" .

Claims

REVENDICATIONS
1. - Procédé pour assurer le temps de latence des communications entre au moins deux points de passage de données selon un protocole orienté objet Java- RMI ou CORBA, caractérisé en ce qu'il met en oeuvre dans chaque point de passage un protocole RSNP de réservation de ressources dans la couche MW (10) de Java-RMI ou CORBA, intermédiaire entre le système d'exploitation (11) 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 selon le protocole RSNP.
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.
4. - Procédé selon la revendication 3, caractérisé en ce que les opérations associées aux références distantes comprennent les opérations de détermination de la largeur de bande à utiliser, la taille maximale des paquets de données et la taille maximale des tampons nécessaires.
5. - Procédé selon la revendication 3 ou 4, caractérisé en ce que le protocole RSNP assure la réservation des ressources sur le trajet compris entre deux objets distants Java-RMI ou CORBA.
6. - Procédé selon l'une des revendications 3 à 5, caractérisé en ce que chaque référence distante spécifie la répartition temporelle de ses invocations, et qu'une réservation spécifique est faite pour chaque référence distante.
7. Procédé selon la revendication 6, caractérisé en ce que les références distantes identifient l'émetteur de la réservation à l'origine de la session d'invocation, et que le serveur en fait autant pour les sessions de réponse.
8. - Procédé selon la revendication 7, caractérisé en ce que la référence distante est associée à deux sessions de réservation et que deux références distantes différentes, faisant partie du même objet ou machine virtuelle référencent le même serveur et sont associées à des réservations distantes
EP02706845A 2001-02-12 2002-02-12 Procede pour assurer le temps de la latence des communications entre au moins deux points de passage de donnees Withdrawn EP1382148A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0102172 2001-02-12
FR0102172A FR2820922B1 (fr) 2001-02-12 2001-02-12 Procede pour assurer le temps de latence des communications entre au moins deux points de passage de donnees
PCT/FR2002/000527 WO2002065680A2 (fr) 2001-02-12 2002-02-12 Procede pour assurer le temps de la latence des communications entre au moins deux points de passage de donnees

Publications (1)

Publication Number Publication Date
EP1382148A2 true EP1382148A2 (fr) 2004-01-21

Family

ID=8860135

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02706845A Withdrawn EP1382148A2 (fr) 2001-02-12 2002-02-12 Procede pour assurer le temps de la latence des communications entre au moins deux points de passage de donnees

Country Status (4)

Country Link
US (1) US20040068558A1 (fr)
EP (1) EP1382148A2 (fr)
FR (1) FR2820922B1 (fr)
WO (1) WO2002065680A2 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8477610B2 (en) 2010-05-31 2013-07-02 Microsoft Corporation Applying policies to schedule network bandwidth among virtual machines
US9112890B1 (en) 2014-08-20 2015-08-18 E8 Storage Systems Ltd. Distributed storage over shared multi-queued storage device
US9529542B2 (en) 2015-04-14 2016-12-27 E8 Storage Systems Ltd. Lockless distributed redundant storage and NVRAM caching of compressed data in a highly-distributed shared topology with direct memory access capable interconnect
US10496626B2 (en) 2015-06-11 2019-12-03 EB Storage Systems Ltd. Deduplication in a highly-distributed shared topology with direct-memory-access capable interconnect
US9842084B2 (en) 2016-04-05 2017-12-12 E8 Storage Systems Ltd. Write cache and write-hole recovery in distributed raid over shared multi-queue storage devices
US10031872B1 (en) 2017-01-23 2018-07-24 E8 Storage Systems Ltd. Storage in multi-queue storage devices using queue multiplexing and access control
US10685010B2 (en) 2017-09-11 2020-06-16 Amazon Technologies, Inc. Shared volumes in distributed RAID over shared multi-queue storage devices

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6134603A (en) * 1998-03-20 2000-10-17 Sun Microsystems, Inc. Method and system for deterministic hashes to identify remote methods
CA2332586A1 (fr) * 1998-06-17 1999-12-23 Tellabs Research Limited Systeme de messagerie d'unite de commande de telecommunications
US7237012B1 (en) * 2000-12-29 2007-06-26 Nortel Networks Limited Method and apparatus for classifying Java remote method invocation transport traffic

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO02065680A2 *

Also Published As

Publication number Publication date
WO2002065680A2 (fr) 2002-08-22
FR2820922B1 (fr) 2005-02-18
US20040068558A1 (en) 2004-04-08
FR2820922A1 (fr) 2002-08-16
WO2002065680A3 (fr) 2003-09-25

Similar Documents

Publication Publication Date Title
Barzilai et al. Design and implementation of an RSVP-based quality of service architecture for an integrated services Internet
US9288132B2 (en) Method and system for monitoring messages passed over a network
EP2667541B1 (fr) Orchestration de services de connectivité
US10785163B2 (en) Maintaining a queuing policy with multipath traffic
JP2001034576A (ja) メディア処理システム及び方法
Charbonneau et al. Advance reservation frameworks in hybrid IP-WDM networks
CN107666474B (zh) 一种网络报文处理方法、装置及网络服务器
WO2002065680A2 (fr) Procede pour assurer le temps de la latence des communications entre au moins deux points de passage de donnees
CN111970149B (zh) 一种基于硬件防火墙qos的共享带宽实现方法
Garces-Erice Building an enterprise service bus for real-time SOA: A messaging middleware stack
CN114363269A (zh) 一种消息传输方法、系统、设备以及介质
de Miguel Solutions to make Java-RMI time predictable
US20050135397A1 (en) Buffer replenishing
EP3818442B1 (fr) Gestion de la mise en application d'une politique dans un environnement sdn de réseau de communication
Carella et al. A network function virtualization framework for network slicing of 5G networks
Hossain et al. Quality of Service in Software Defined Networking
JP3787802B2 (ja) ネットワーク・サービスオーダ処理装置及びネットワーク／サービス管理システム
Breabăn et al. Endorsement of a user-level bandwidth management application in a directory service environment
El Abdouni Khayari Class‐based weighted fair queueing: validation and comparison by trace‐driven simulation
WO2023088702A1 (fr) Configuration dynamique de la planification de transmission des flux dans les réseaux déterministes
Subedi Testbed-based Evaluation of QoS Differentiation for Network Slicing in Multi-Application Scenarios
EP1018818B1 (fr) Architecture d'agent pouvant coopérer avec des applications corba
FR2665040A1 (fr) Procede et dispositif de pontage entre reseaux locaux.
Li et al. Learning Profile based Resource Management Architecture for Active Network
CN115720191A (zh) 基于网络业务的自动配置QoS方法、系统及网络设备

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20030730

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

17Q First examination report despatched

Effective date: 20071120

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RTI1 Title (correction)

Free format text: METHOD FOR ENSURE COMMUNICATION WAITING TIMES BETWEEN AT LEAST TWO DATA NODES

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20090616