EP1382148A2

EP1382148A2 - Method for providing communication waiting times between at least two data nodes

Info

Publication number: EP1382148A2
Application number: EP02706845A
Authority: EP
Inventors: Miguel Thales Intellectual Property DE MIGUEL
Original assignee: Thales SA
Current assignee: Thales SA
Priority date: 2001-02-12
Filing date: 2002-02-12
Publication date: 2004-01-21
Also published as: WO2002065680A2; US20040068558A1; FR2820922B1; FR2820922A1; WO2002065680A3

Abstract

The invention concerns a method for providing communication waiting times between at least two data nodes using a resource reservation protocol in the intermediate MW layer (10) between the operating system (11) and the application layers (9) by integrating the resource reservation procedures and services (15) and the communication procedures in the MW layer.

Description

METHOD FOR ENSURING THE LATENCY TIME OF COMMUNICATIONS BETWEEN AT LEAST TWO PASSAGE POINTS

DATA

The present invention relates to a method for ensuring the latency of communications between at least two data crossing points.

In real-time distributed data processing systems, the processing time requirements make it necessary to take into account the prediction of processing time. Resource reservation techniques provide solutions to these requirements, but only in some cases, as discussed below.

The Java language has already been used in real-time systems.

However, this language does not make it possible to easily limit the latency times and the blocking times, in particular for treatments such as “crumb collection” (

“Garbage collection” in English, scheduling algorithms and protocols of synchronization processes. 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. However, these 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"). To limit the effects of these problems, D. Jensen established with a group the specification "J.S.R. 000050 Distributed Real-Time Systems ”,“ J.S.R. Meaning "Java Specification Request". 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.

Furthermore, there is a software platform (“Framework” in English) of intermediate layer between the operating system and the application layers (intermediate layer commonly called “Middleware” in English, which will be called MW thereafter) called CORBA. The Java-RMI and CORBA programs include an MW layer allowing users to invoke operations performed by distributed objects. A well-known working group, called OMG ("Object Management Group") published in March 1999 an OMG standard for CORBA applications in real time. In August 2000, this group published the "Dynamic Scheduling Real-Time CORBA" specifications extending the above-mentioned standard in order to make it support dynamic planning algorithms which were not taken into account by the CORBA real-time standard. The purpose of these specifications is to extend the CORBA standard in order to facilitate its possibility of end-to-end prediction of the activities of a distributed system and to provide support for the management of resources in the CORBA environment. The ability to predict the end-to-end execution of tasks in a timely manner is only possible if we respect the priorities of the processes between client and server to resolve resource grabbing problems ("resource contention" in English ), if we limit the resource use priority inversions and if we limit the latency time of invocations of operations. But it is clearly specified in this publication that the authors do not offer a solution making it possible to limit the latency times relating to the operating system, to specific applications and especially to the means of communication.

We know from the article by Chao-Ju Hou, Ching Chih Han and Yao-Min Chen "Communication middleware and software for QoS control in distributed real-time environments", published in 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. of August 13, 1997, pages 558 to 564, a process of. communication using the RSNP protocol, but this document does not provide any solution to the problems caused by the use of this protocol, and, on the other hand, this document evokes WM, but does not associate it with CORBA or JANA- RMI.

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. According to the invention, 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 .

According to a characteristic of the invention, 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.

According to another characteristic of the invention, 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.

Thus, 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. As a result, this integration makes compatible the protocols carrying out the communication at the MW layer and the resource reservation protocols.

Thanks to the fact that 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.

The present invention will be better understood on reading the detailed description of an embodiment, taken by way of nonlimiting example and illustrated by the appended drawing, in which:

FIG. 1 is a diagram of a known resource reservation node, and

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. These protocols are described for example in the specifications of the Sun Microsystems Company (Java Remote Method Invocation Specification for JDK 1.2) and in the document of the working group "Object Management Group" entitled "Real-Time CORBA 1.0 Spec, OMG Document number ptc / 00-09-02 ", respectively.

The principle of implementing a known protocol for reserving resources via an API (Application Programming Interface) has been illustrated in FIG. 1. This protocol is mainly implemented in a node by a background routine 1 (commonly called "DAEMON"). This protocol is here of the RSVP type ("Resource Reservation Protocol"), well known per se, for example according to the article by Zhang, S. Berson, S. Herzog and S. Jamin, entitled "Resource ReSerVation Protocol (RSNP ) - Version 1 Function Specification ", Internet RFC 2205, 1997. 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. Hoffman: "RAPI - An RSNP Application Programming Interface", Internet Draft of August 1998 operating with a "Windows QoS Socket Library" described in the document by Y Bernet, J. Stewart, R. Yavatkar, D. Andersen, C. Tai, B. Quinn and K. Lee, entitled "Winsock Generic QoS Mapping (Draft)", from Microsoft. This interface 4 is itself in two-way connection with an application 5. The routine 1 controls a packet classifier 6 and a packet sending scheduler 7. The classifier 6 receives a stream of data 8 which it rearranges into packets, and the scheduler 7 sends these packets according to the possibilities of the network through which they must transit. Most API 4 functions use a session descriptor as an input parameter. 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. In the reservation process, 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.

In the node diagram (transmitter or receiver) of FIG. 2, 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. On the other hand, an RSVP resource reservation routine 15 of layer 10 communicates with a reservation protocol routine 16 of the operating system 11. In this way, 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. Only 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. In the example described here, 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.

Different solutions can associate the reservation with different software elements. According to a preferred aspect of the invention, this association is made according to the approach of remote references. In these cases, each remote reference specifies the temporal distribution of its invocations, and a specific reservation is made for each remote reference. According to the invention, 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.

Among the other possible reservation association solutions, we can first note the "client object" approach, according to which the client specifies the time distribution of its remote invocations for each server. According to the invention, the client object is then associated with the transmitter of the invocation sessions and with the receiver of the sessions. return. On the client side, two reservation sessions are associated with each server used. This solution reserves resources for each communication from a client to a server.

Another approach that can be implemented by the invention in the case of the use of the Java language. 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. According to the invention, 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.

As stated above, the preferred solution of the invention is the approach

“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. In fact, according to the second and third approaches described above, a second task can modify the reservation of a first task, which will change the response time. In the latter two solutions, the tasks must approve their reservation time. According to the first approach, the reference can be a local variable of the task, and the reservation is fixed within the task. In the first approach, the server and the references negotiate the reservation from a Java-Reservation set which is an extension of the Java-RMI API interface. These extensions allow the identification of the methods which will be invoked by the reference to the server, as well as the temporal distribution of the invocations. Another type of reservation is simple reservation, whereby the references establish the bandwidth of the invocation and response sessions. The second approach is interesting when the size of the set of invocations and responses cannot be statistically evaluated.

The RMI invocation method can be implemented with the JDK tool (“Java Development Kit”), in version 1.2 for example. However, this implementation poses several problems which the invention solves in the manner described below, in the case of the approach of remote references.

When two tasks use the same remote reference in parallel, they use two different connections, and therefore two different "sockets". This can also occur when two callbacks (RMI) are used, and if the client calls the server from the client callback, when the first callback is not yet finished. In this case, the RMI procedure uses two "sockets" to communicate the same reference with the same server. This process has incompatibilities with the approach of reservation sessions by API interfaces, and with the three approaches described above (association of the reservation with the different software elements). Indeed, the RSNP protocol is “session oriented”, while the JDK 1.2 implementation is “connection oriented”. 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". To solve this problem, 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. Their purpose is to provide a model in which two endpoints can each open multiple full duplex connections with the other point in an environment in which only one of the endpoints is capable of opening such a two-way connection using d other possibilities. In this case, we use the multiplexing capabilities of the RMI invocation to reuse the same "socket" for all the methods of invoking the same reference, and the reservation session is generated with this "socket". The JDK 1.2 tool recognizes the arrival of multiplexed packets in the transport task (“TCPTransport”) and produces a multiplexed TCP channel to route these packets. However, this tool does not allow client multiplexing to be configured and the receiver-side implementation results in unrestricted blocking times: the implementation calls for wait wait instructions and includes new tasks which do not limit the blocking time. It is then necessary to adapt the server classes of the JDK tool, as on the client side. 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.

These problems and their solutions are described in the article by Miguel A. de Miguel published in "Proceedings of ISORC 2001 (May 2001) and entitled" Solutions to make Java RMI Time Predictable ".

Claims

1. - Method for ensuring the latency of communications between at least two data crossing points according to a Java-RMI or CORBA object-oriented protocol, characterized in that it implements an RSNP protocol in each crossing point resource reservation in the MW-layer (10) of Java-RMI or CORBA, intermediary between the operating system (11) and the application layers (9), by integrating the resource reservation processes and services (15) and communication processes in the MW layer.

2. - Method according to claim 1, characterized in that the extensions of the interface of the MW layer are carried out with the application to give it access to the reservation services according to the RSNP protocol.

3. - Method according to one of claims 1 or 2, characterized in that the reservation is associated with the various software elements involved in the communication according to the approach of remote references.

4. - Method according to claim 3, characterized in that 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 necessary buffers.

5. - Method according to claim 3 or 4, characterized in that the RSNP protocol ensures the reservation of resources on the path between two remote Java-RMI or CORBA objects.

6. - Method according to one of claims 3 to 5, characterized in that each remote reference specifies the temporal distribution of its invocations, and that a specific reservation is made for each remote reference.

7. Method according to claim 6, characterized in that the remote references identify the sender of the reservation at the origin of the invocation session, and that the server does the same for the response sessions.

8. - Method according to claim 7, characterized in that the remote reference is associated with two reservation sessions and that two different remote references, forming part of the same object or virtual machine reference the same server and are associated with remote reservations