WO2000002354A1

WO2000002354A1 - Method for executing an application in a computer system connected to a communication network, and control module used in said method

Info

Publication number: WO2000002354A1
Application number: PCT/FR1999/001573
Authority: WO
Inventors: Dominique Bonjour; Laurent Rabret; François-Arnaud REMAEL
Original assignee: France Telecom
Priority date: 1998-07-01
Filing date: 1999-06-30
Publication date: 2000-01-13
Also published as: FR2781627B1; FR2781627A1; AU4376999A

Abstract

An application designed (12) to communicate to a first application programming interface (API) (10) adapted to a first network protocol, is executed in a system (1) equipped with a second API (11) adapted to a network (R) operating according to a second protocol. Prior to communicating with another unit (2) accessible through the network by means of an address defined according to the second protocol, the system associates to the network address a fictitious address defined according to the first protocol. The messages exchanged by the application to the first API are translated into a control module (15) of the system, which further ensures the required address substitutions so that the application may, without being modified, communicate by means of a network based on the second protocol. The control module (15) enables to specify the quality of service parameters which would be borne by the second protocol but not by the first.

Description

METHOD FOR EXECUTING AN APPLICATION IN A SYSTEM

IT CONNECTED TO A COMMUNICATION NETWORK,

AND CONTROL MODULE FOR USE IN SUCH A METHOD

The present invention relates to the field of computer networks.

A computer network R (FIG. 1) involves two general types of equipment, namely "terminals" and "network elements". The 1,2,3 terminals (this concept includes the servers here) are machines (computers) on which computer applications or programs are executed which may require communications with other terminals. The connection of these terminals to each other is ensured by the network elements 4.5 (transmission links and switch points). The dialogue between terminals and network elements is ensured according to predefined PROT procedures called communication protocols.

Computer applications designed to operate on a network use software programming interfaces ("Application Programming Interface", or API). These network communication interfaces are part of the resources offered by the operating system (OS) of each terminal. They allow access to the implanted protocols using a set of "primitives", which call for basic functions allowing to open a connection to a remote address, to send and receive data, etc. These primitives are then translated into elementary messages of the protocol in question (see illustration in Figure 2). In the terminals, the operation according to the communication protocol is ensured by other software resources of the operating system and by appropriate communication cards.

An additional distinction makes it possible to identify both the remote terminal (thanks to its network address), and to select a particular service within of this terminal thanks to a couple of additional identifiers called (protocol, port number). The combination (address, protocol, port number) therefore makes it possible to uniquely designate a particular application in a particular terminal.

The predominant interface to date is the so-called "sockets" API, available at the same time in a variety of system environments: Unix, Windows, etc. The vast majority of network applications available today thus rely on this interface, in its mode allowing the use of networks based on the network layer protocol IP (Internet Protocol).

Another important notion relates to the two logical levels that can be used to identify a terminal (or an application) connected to a computer network.

The first level is that of addressing the actual network layer. It is generally structured (that is to say that the addresses are hierarchical in order to facilitate the routing and the administration of the addresses), that the network layer functions in connected mode (in this case, the address n ' is provided only when establishing a connection) or in connectionless mode (the address is then carried by each packet).

The second level is that of naming, which makes it possible to identify the terminals by a logical name, which is generally in the form of a string of characters easily memorable and understandable by a human. In addition, the name can be chosen independently of any constraints of length or geographical location. For these reasons, these are the names that are most often used for identification.

A translation service makes it possible to match an address, the only concept comprehensible by the network to a name. This mechanism uses a directory which groups the associations <logical name, network address> and which offers interrogation services allowing translation between names and addresses. It is accessible at through a set of network API naming primitives.

Thus, an application generally comprises the following sequence of actions each time it wishes to communicate across the network:

1. use the translation service through the name resolution functions of the API. They return an address corresponding to the name indicated.

2. enter into communication with the remote terminal through the communication primitives of the network API, to which the address, protocol and port number identifying the targeted service are provided.

The predominance of the socket-IP interface, mentioned above, poses difficulties for the introduction of new network technologies, which have their own programming interface (API). Indeed, it is highly desirable for users to be able to reuse in the new environment the park already acquired and mastered of networked applications. A first problem therefore consists in resuming without change all the applications exploiting a common API (for example, IP sockets) in a new network environment.

A second problem relates to the introduction of the concept of quality of service, made possible for example thanks to networks based on ATM technology.

(Asynchronous Transfer Mode). It becomes possible to specify, data flow by data flow, its needs in terms of speed, transmission delay or network loss rate. Unfortunately, since these notions do not exist with IP sockets, current applications often cannot take advantage of them. The second problem is therefore to provide means within the terminal making it possible to specify quality of service parameters as well as the flows to which they apply.

There is no known published solution suggesting migrate existing applications while respecting the current API, while preserving the naming layer and modifying the network or transport protocol layers. With regard to the first problem cited, the proposed approaches only aim to stack the IP network layer on top of the new network technology. We then speak of protocol emulation. Beyond the technical difficulties which they impose, their weaknesses are on the one hand that they notably complicate the management and the design of the networks by duplicating the functionalities, and on the other hand that they reproduce the limitations, in particular in lack of quality of service management, of the IP layer. With regard to the second problem cited, the only current possibility is to rewrite the applications taking into account the API of the new network layer, which will make it possible to take advantage of the quality of service, but requires a modification of the code of the application and therefore prevents the identical recovery of the existing.

Another suggested approach consists in carrying out differential processing of data flows within the network, without the terminal being able to participate in the negotiation of the conditions (identification of flows and quality of service parameters) of this processing.

A main aim of the present invention is to propose a simple solution to the first problem mentioned above.

The invention thus provides a method for executing an application in a computer system connected to a communication network, the application being designed to exchange messages towards a first programming software interface adapted to a first network communication protocol, and the communication network operating according to a second network communication protocol for which the system is equipped with a second programming software interface. Before an exchange of messages between the application and another unit designated by a unit name and accessible by the network by means of a network address defined according to a format of the second protocol, the system arbitrarily associates with the network address of the unit an address for local use defined according to a format of the first protocol. During said exchange, each message received by the system according to the second protocol from the unit identified by its network address and intended for the application, is transformed into a translated message including the associated local use address, which is supplied to the application via the first programming interface, and each message presented by the application on the first programming interface to the unit identified by the address for local use is transformed into a message translated according to the second protocol, which is sent over the network to the unit identified by its network address.

By "computer system" is meant, in the above definition of the process, a terminal, client or server, connected to the network. This computer system can be a computer of greater or lesser power, or even a group of computers linked together by a separate local network comprising one or more gateways for connection to the communication network.

For the implementation of the process, the computer system is equipped with a software module which provides all the primitives of the first API (old), which allows the transparent recovery of applications. This module is based on the resources of the second (new) API. These can be supplied by a standard commercial module.

The mechanism of (fictitious) addresses for local use simulates an access procedure according to the first protocol from the point of view of the application, so that it does not need to be modified when the system is connected to the network operating according to the second protocol. The messages exchanged by the system on the network do not keep any trace of the first protocol, and therefore are not affected by any of the constraints specific to this first protocol. The fact of freeing the messages exchanged on the network from the limitations specific to the first protocol makes it possible to benefit from the application of communication management functions foreign to the first protocol, in particular for managing the quality of service in the case, for example, the transition from an IP protocol to an ATM protocol. Thus, in a preferred embodiment of the invention where the second protocol integrates communication management parameters not provided for in the first protocol, the connection establishment procedure, executed according to the second protocol in the processing of a request connection from or to the application, takes into account values defined for at least some of said management parameters.

The values of the management parameters can be chosen according to the application executed. For example, if the application performs file transfers, we can specify a high peak bit rate and low delay constraints, while if the application provides real-time communications (telephony, videophi ...), rather look for very short transmission delays. This kind of flexibility is possible in ATM networks, and is an important limitation of IP networks.

The choice of these values of the management parameters can result from a query of the user of the application, and / or from an association table stored in the system, and / or from a server provided for this purpose. in the network, and / or an adaptive mechanism based on the analysis of real data flows. This choice can be controlled by a specific program.

Another aspect of the present invention relates to a module for controlling the exchange of messages between a application executed in a computer system connected to a communication network, and another unit accessible by the network, the application being designed to exchange messages towards a first programming software interface adapted to a first network communication protocol, the network system operating according to a second network communication protocol for which the system is equipped with a second programming software interface, and the other unit being designated by a unit name and accessible by means of a defined network address according to a format of the second protocol. This control module is to be installed in the system. It includes means for assigning fictitious addresses, for arbitrarily associating with the network address of the unit a local use address defined according to a format of the first protocol, and for memorizing this association, and means for translation, designed to communicate with the application via the first programming interface and with the network via the second programming interface, and arranged on the one hand to transform each message received from the network from the unit identified by its network address and intended for the application into a translated message including the associated local use address, which is supplied to the application via the first programming interface, and on the other hand to transform each message received from the application to the unit identified by the address for local use in a message translated according to the second protocol, which is sent over the network to the unit identified by its network address. This module according to the invention will typically be a software module.

A third aspect of the invention relates to a computer program which, when loaded and executed in a computer system connected to a communication network, forms a message exchange control module as defined above. above to control message exchanges between an application running in said computer system and another unit accessible via the network, as well as to a computer-readable medium, on which such a program is recorded.

Other features and advantages of the present invention will appear in the following description of nonlimiting exemplary embodiments, with reference to the appended drawings, in which:

- Figures 1 and 2, previously discussed, are schematic illustrations of computer networks; - Figures 3 to 5 are diagrams showing a control module according to the invention and respectively illustrating name resolution procedures, local connection request and remote connection request; and - Figures 6 and 7 are diagrams similar to that of Figure 4 and illustrating two variants of the local connection request procedure.

The computer system 1 shown diagrammatically in FIGS. 3 to 7 is a terminal equipped with two programming software interfaces (API) 10 and 11. The terminal 1 hosts applications 12 designed to communicate with other applications via the API 10. API 10 is adapted to a first network communication protocol, hereinafter called "old" protocol.

Physically, the terminal 1 is connected to a communication network R which operates according to a second protocol, hereinafter called the "new" protocol. The terminal is equipped with software and hardware elements 14 providing a protocol layer for data exchanges with the network R according to this new protocol. The API 11 provides the interface of the terminal 1 with these elements 14.

The present invention proposes to install, between APIs 10 and 11, a module 15 for controlling message exchanges. This module 15 includes a primitive translator 16, an association table 17 and a module 18 for quality of service management (QoS). The association table 17 stores at least triples <name, address for the new API 11, address for the old API 10>, each triplet representing a unit (terminal and / or application hosted by this terminal) accessible by the intermediary of the network R. The address for the old API 10 is a fictitious address, generated locally by the terminal 1 so that the application 12 can continue to be executed by dialoguing with the existing unit via the API 10.

In these dialogs, the primitive translator 16 receives messages conforming to the old API 10 and translates them to retransmit them to the new API 11, and conversely it receives messages from the new API 11 and translates them to retransmit them to the 'old API 10. The primitive translator 16 is associated with a table (not shown) making it possible to convert the messages relating to one of the APIs to messages relating to the other API and vice versa. If a message received from the API 10 contains the fictitious address of an outdoor unit, the primitive translator 16 queries the association table 17 in order to obtain the effective network address of the unit and of the include in the translated message retransmitted to the new API 11. Likewise, if a message received from the new API 11 contains a network address of an outdoor unit, the primitive translator 16 interrogates the association table 17 in order to recover the corresponding fictitious address and to include it in the translated message retransmitted towards the old API 10. Thus, the application 12 handles an address in accordance with the appropriate protocol, even if this address does not allow the effective routing of information in the network.

It is assumed here that the new protocol supported by the API 11 integrates quality of service parameters which are not provided for in the old protocol supported by the API 10.

The module 18 is then used to provide the translator with primitives 16 the quality of service parameters that, by assumption, the old API 10 is unable to provide. The module 18 thus makes it possible to manage the conditions of transport in the network R of the different data flows from or to the applications 12 executed in the system 1.

FIG. 3 illustrates a procedure for resolving names executed on the initiative of an application 12 of the terminal 1. The application 12 begins by issuing to the API 10 a name resolution request 21 including the name N of the remote unit sought. Receiving this request according to the first protocol, the primitive translator 16 transforms it into a name resolution request 22 conforming to the second protocol and including the name N. This request 22 is supplied to the protocol layer 14 through the new API 11 By applying the second protocol (data exchanges designated by the references 23 and 24 in FIG. 3), the terminal 1 interrogates a naming server 6 connected to the network at a determined address. The naming server 6, which contains the associations between the names of the units connected to the network R and their addresses in this network, responds to the query by returning the address A corresponding to the unit name N included in the requests 21, 22.

This address A is supplied to the primitive translator 16 through the new API 11 in a message 25. The primitive translator 16 generates an available local use address A ', defined according to the format of the old protocol. The primitive translator 16 addresses to the association table 17 a message 26 including the tπplet (N, A ^T , A) which is then stored in the table 17. On the other hand, the fictitious address A 'is returned to the application in a response message 27 through the old API 10.

At the end of this procedure illustrated in FIG. 3, the application 12 can access the unit N using the fictitious address A ′, the primitive translator 16 then retrieving the real address A using the association table 17.

The application 12 may in particular require a connection to the unit 2 whose name is N and the network address A, as illustrated in FIG. 4.

In FIG. 4, the reference 31 designates the connection request sent by the application 12 to the old API 10. This request 31 includes the local use address A 'which was supplied to the application 12 in the message 27 of FIG. 3. On receipt of the request 31 from the API 10, the primitive translator 16 interrogates the association table 17 to retrieve the network address A with which the fictitious address A 'is associated (exchange 32). The quality of service management module 18 can be queried in order to obtain the quality of service parameters relevant to the application considered (exchange

33) synchronously or asynchronously with the request 31.

The terminal 1 can then execute, according to the new protocol, a procedure 34-37 for establishing a connection with the other unit 2 whose network address is A. The primitive translator 16 first supplies the layer with protocol 14, through the API 11 a connection request 34 including the network address A of the remote unit 2 and the quality of service parameters. The references 35 and 36 in FIG. 4 designate the conventional messages of the second protocol exchanged to establish the connection. Once the connection has been established, a message 37 is returned to the primitive translator 16, which translates it into a connection validation message 38 delivered through the old API 10.

The application 12 can then dialogue with the unit 2, the primitive translator 16 mutually substituting the message exchange primitives between the API 10 and the API 11.

FIG. 5 illustrates the case where the connection request with the application 12 comes from the unit di aunt 3.

When the application 12 declares itself ready to accept a connection via a primitive of the API 10 (message 40), the translator of primitives 16 converts this into a primitive of the API 11 (message 40 '), possibly with using the service quality management module 13 (message 40ter).

The reference 42 designates the request transmitted to the terminal 1 by the network R in response to that 41 sent by the remote unit 3. This request 42 notably includes the network address A of the unit 3. If the parameters of the message 42 are compatible with those of message 40 ′, the request is supplied to the primitive translator 16 through the new API 11, in a message 43. On receipt of this message 43, the primitive translator 16 generates an address for local use available A 'and commands the storage in table 17 (message 44) of the association between the addresses A and A' as well as the name N of the remote unit 3 if this name is provided in the request. The primitive translator 16 retransmits to the application 12, through the API 10, a connection indication 45 translated according to the first protocol and including the fictitious address A '. The protocol layer 14 manages the acceptance of the connection in the network via the message 49, translated to the remote terminal 3 into a message 50.

If the parameters of the message 42 are not compatible with those of the message 40 ', the protocol layer 14 will send a connection refusal message 49' to the network R, which will be translated into a message 50 'to the remote terminal 3.

The translator 16 substitutes the primitives for exchanging messages between APIs 10 and 11.

In the example illustrated by FIG. 4 or 5, the module 18 for managing the quality of service stores a table matching applications with sets of values of management parameters, in this case quality of service parameters. During a query 33, 40ter, the primitive translator 16 identifies the application concerned, and the module 18 returns the corresponding values of the quality of service parameters.

The values of the parameters contained in this table can be predefined, from a library of characteristics of applications existing on the market. It is also possible to provide for defining or adjusting these values using a quality of service management application 13 provided in the terminal 1 and interacting with the module 18 via an appropriate interface 19.

FIG. 6 illustrates a variant of FIG. 4 in which the values of the management parameters are obtained by interrogating a user of the application 12. The application 13 for managing the quality of service is then provided with a human interface. machine for interrogating the user. When the primitive translator 16 requests the quality of service parameters for the application 12 (message 33a), the module 18 sends a message 33b to the application 13 via the interface 19 in order to interrogate the user, possibly by proposing default values contained in a table of the module 18. Once the user has validated his choice of parameters, the application 13 supplies these parameters in a message 33c to the module 18 which retransmits them to the module 16 in a message 33d.

FIG. 7 illustrates another variant in which the values of the management parameters are obtained by interrogating a server 7 connected to the network R through the new API 11. When the primitive translator 16 requires values for the quality of service parameters in a message 33e, the module 18 delivers a message 33f to the API 11, including the network address of the server 7 as well as an identification of the application concerned 12. A data exchange 33g, 33h then intervenes with the server 7 via the network R, and the parameter values returned by the server 7 are supplied to the module 18 by a message 33ι through the API 11. These values are then retransmitted (possibly after modification or validation by the user questioned by means of the application 13) to the translator of primitives 16 in a message 33. The server 7 connected to the network can include, for a whole library of commercial applications, default values of the quality of service parameters. These default values can then be easily modified as the network capacities evolve and / or new versions of the applications are released.

By way of example, the first protocol supported by the API 10 can be an IP protocol, while the second protocol supported by the API 11 can be an ATM protocol. In the case of applications designed to run under the Windows operating system (trademark of the company Microsoft), API 10 is then the API Winsock 1 based on the IP protocol, while API 11 is the Winsock 2 API with ATM extensions. All the primitives exchanged between the network and the applications pass through the control module 15. To be called automatically by the application 12, the module must have the standard name of the sockets for Windows, namely currently "Winsock.dll", " Wsock32.dll "or" ws2_32.dll ". It is thus possible to provide the standard Winsock interface using the module proposed according to the invention.

Of course, another possibility is to carry out the invention in the form of an LSP (“Layered Service Provider”) module.

Of course, the invention is applicable to other protocols. It is also applicable when changing the version of the same protocol, so that applications designed for the first version can be identical to work with the second version, a separate application such as 13 allowing to integrate the protocol enrichments possibly provided by the new version. Thus, the invention is particularly applicable to migration between the IPV4 and IPV6 versions of the Internet Protocol (IP).

Claims

1. Method for executing an application (12) in a computer system (1) connected to a communication network (R), the application being designed to exchange messages towards a first programming software interface (10) adapted to a first network communication protocol, said communication network operating according to a second network communication protocol for which the system is equipped with a second programming software interface (11), characterized in that before an exchange of messages between the application and another unit (2,3) designated by a unit name (N) and accessible by the network by means of a network address (A) defined according to a format of the second protocol, the system arbitrarily associates with the 'network address of the unit a local use address (A') defined according to a format of the first protocol, and in that, during said exchange, each message received by the system according to the second protocol d since the unit identified by its network address and intended for the application, is transformed into a translated message including the associated local use address, which is supplied to the application via the first programming interface, and each message presented by the application on the first programming interface to the unit identified by the address for local use is transformed into a message translated according to the second protocol, which is transmitted over the network to the unit identified by its address network.

2. Method according to claim 1, in which the application (12) sends to the first programming interface (10) a name resolution request (21) relating to another unit designated by a name d (N) triggers operations following:

- the system obtains the network address (A) of the other unit on the basis of its unit name;

- the system generates an address for available local use (A '), defined according to the format of the first protocol;

- the system memorizes an association between the unit name, the network address of the other unit and the local use address generated; and - a message (27) is delivered to the application via the first programming interface to provide it with the address for local use generated.

3. Method according to claim 2, wherein the system (1) obtains the network address (A) of the other unit by interrogating a server (6) of the network through the second programming interface (11).

4. Method according to any one of claims 1 to 3, wherein the transmission by the application (12) to the first programming interface (10) of a request (31) for connection with another unit (2 ) identified by an address for local use (A ') triggers the following operations:

- the system retrieves the network address (A) of the other unit, with which said address for local use is associated;

- the system performs, according to the second protocol, a procedure (34-37) for establishing a connection with the other unit using its network address; and - after establishment of the connection according to the second protocol, a message (38) for validating the connection is delivered to the application via the first programming interface.

5. Method according to any one of claims 1 to 4, wherein the reception by the system (1), according to the second protocol, a request (42) for connection with the application (12) including the network address (A) of another unit (3) triggers the following operations:

- the system memorizes an association between the network address of the other unit and the local use address generated; - a connection indication message (45) including the address for local use generated is presented to the application via the first programming interface (10).

6. Method according to claim 4, in which the second protocol integrates communication management parameters not provided for in the first protocol, and in which said connection establishment procedure according to the second protocol takes account of values defined for at least some of said management parameters.

7. The method of claim 6, wherein said values of management parameters are chosen according to the application executed (12).

8. The method of claim 6 or 7, wherein said values of management parameters are obtained by interrogating a user of the executed application (12).

9. The method of claim 7, wherein said values of management parameters are obtained by means of a table, stored in the system, making applications (12) correspond with them of values of management parameters.

10. The method of claim 7, wherein said values of the management parameters are obtained by interrogating a server of the network (7) through the second programming interface (11).

11. Method according to any one of claims 6 to 10, in which the system (1) is provided with a program.

(13) for controlling said management parameters not provided for in the first protocol in order to define parameter profiles according to characteristics of the application executed and / or according to data supplied by the user.

12. Module for controlling the exchange of messages between an application (12) executed in a computer system

(1) connected to a communication network (R), and another unit (2,3) accessible by the network, the application being designed to exchange messages towards a first programming software interface (10) adapted to a first network communication protocol, said communication network operating according to a second network communication protocol for which the system is equipped with a second programming software interface (11), the other unit being designated by a unit name ( N) and accessible by means of a network address (A) defined according to a format of the second protocol, the control module (15) being to be installed in the system, and comprising: - means for allocating fictitious addresses (17), for arbitrarily associating with the network address of the unit a defined local use address (A ′) according to a format of the first protocol, and for memorizing this association; and - translation means (16), provided for communicating with the application via the first programming interface and with the network via the second programming interface, and arranged on the one hand to transform each message received from the network from the unit identified by its network address and intended for the application into a translated message including the associated local use address, which is supplied to the application via the first programming interface, and on the other hand to transform each message received from the application to the unit identified by the address for local use in a message translated according to the second protocol, which is sent over the network to the unit identified by its network address.

13. The module as claimed in claim 12, in which the means for assigning fictitious addresses (17) are arranged to store an association between the network address (A) of the unit, the associated local use address ( A ') and the name of the unit (N).

14. Module according to claim 12 or 13, wherein the second protocol integrates communication management parameters not provided for in the first protocol, and further comprising enrichment means (18) cooperating with the translation means (16) to provide defined values for at least some of said management parameters so that these values are taken into account in connection establishment procedures according to the second protocol.

15. Module according to claim 14, in which the enrichment means (18) cooperate with a program

(13) for controlling said management parameters not provided for in the first protocol, this control program being provided for defining profiles of parameters according to characteristics of the application executed and / or according to data supplied by the user.

16. Computer program which, when loaded and executed in a computer system (1) connected to a communication network (R), forms a message exchange control module according to any one of Claims 12 to 15, for controlling the exchange of messages between an application (12) executed in said computer system and another unit (2,3) accessible by the network.

17. A computer-readable medium on which a program (15) is recorded according to claim 16.