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)
• Mobile Radio Communication Systems (AREA)
• Stored Programmes (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=8860135

Family Applications (1)

Country Status (4)

Families Citing this family (7)

Family Cites Families (3)

• 2001
  • 2001-02-12 FR FR0102172A patent/FR2820922B1/fr not_active Expired - Fee Related
• 2002
  • 2002-02-12 WO PCT/FR2002/000527 patent/WO2002065680A2/fr active Application Filing
  • 2002-02-12 US US10/467,655 patent/US20040068558A1/en not_active Abandoned
  • 2002-02-12 EP EP02706845A patent/EP1382148A2/de not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events