WO2001076175A2

WO2001076175A2 - Optimized connection life cycle for an authenticated client-server relationship

Info

Publication number: WO2001076175A2
Application number: PCT/SE2001/000703
Authority: WO
Inventors: Stéphane DESROCHERS
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2000-03-30
Filing date: 2001-03-30
Publication date: 2001-10-11
Also published as: WO2001076175A3; AU2001244977A1; EP1269310A2

Abstract

The connection (20) between a client (12) and server (16) is more efficiently managed in such a way that the actual connection between client and server is provided when needed, reused as much as possible and destroyed when that actual connection is unused for an excessive amount of time. One disclosed mechanism utilizes a connection manager (18) that responds to client application requests to open and close a connection to a server by reusing an existing connection to the server if already in place to handle plural open requests (30-40) and waiting following receipt of corresponding close requests for a delay period before closing the connection to the server in order to efficiently accommodate subsequent requests to open (50-74). Another disclosed mechanism instantiates (172) a connection object (120) presenting a virtual connection to the server in response to the opening of the client application, and further instantiating an encapsulated real connection object (122) responsive to a client application request for access to the server. The real connection is then closed (198) if it remains idle for an excessive time period, and the virtual connection is thereafter closed (192) only when the application terminates.

Description

OPTIMIZED CONNECTION LIFE CYCLE FOR AN AUTHENTICATED CLIENT-SERVER RELATIONSHIP

BACKGROUND OF THE INVENTION Technical Field of the Invention

The present invention relates to client-server relationships and, in particular, to a method and apparatus for more efficiently managing the connection between a client and its server.

Description of Related Art Client-server relationships are well known in the art. It is recognized that a thread or routine of an application being executed by a client may generate a request for access to the server (which may, for example, comprise a database). In many situations, access to the server is restricted to only those clients who are authorized. Such authorization is typically granted in response to the client being first successfully authenticated. In this regard, the initial access by the client to the database involves opening a communications connection and executing an authentication transaction. If the authentication is successful, the open communications connection is then made available for client use in accessing the server resources. When client access to the server is no longer needed, the communications connection should be closed as such connections comprise valuable and limited resources that must be shared among and between many clients. In this regard, given the limited nature of the resource and the potential for high demand, it is imperative that clients optimize their connection life cycles with respect to the server.

A number of current mechanisms are known for managing the life cycle of a client-server connection. One solution is to open the connection when an application in the server starts and to then close the connection when the application terminates. This mechanism is not particularly efficient as the connection may remain open, perhaps to the exclusion of other clients making connections, during extended idle times when the threads or routines of the application being executed by a client are not generating requests for access to the server. As an example, an application may, in some instances, run for weeks, and many thousands of such applications over the collected plurality of clients may be active at any one time. Another solution is to manage the opening and closing of the connection at strategic points in application process. In this way the connection may be opened and closed a minimum number of times while maximizing the number of requests processed during the life of each connection. This mechanism is not preferred because it is difficult to achieve as the management of the connection must be uniquely specified for each different application, and is subject to error due to requests being issued from many unrelated modules of an application. Yet another solution involves opening and closing the connection for each individual thread or routine generated request for access to the server. This mechanism, while simple to implement, unfortunately requires an authentication transaction to be performed with each new connection set-up (causing unacceptable overhead levels), fails to efficiently utilize any of the individual open connections, and decreases both client and server performance levels.

SUMMARY OF THE INVENTION

In accordance with a first embodiment of the invention, a connection manager for each client manages an object representing a connection with the server in such a way that the connection is reused as much as possible and destroyed when the connection is unused for an excessive amount of time. The client (through its applications) makes requests to open a connection with a server. Responsive to such requests to open, the manager first checks to see if an existing actual connection to the server is in place through the managed object representing the connection. If so, that existing actual connection is efficiently reused to handle the newly received request. If not, a new actual connection (object) is opened and authenticated for that request. This open connection is thereafter maintained in place until each received open request is matched with a corresponding close request. At that point, the connection is not immediately closed, but instead a delay timer is started. Only when that timer times out, and provided that no new requests to open are received by the manager in the interim period, is the actual connection to the server closed. In accordance with a second embodiment of the invention, a connection factory responds to the starting of an application by instantiating a smart connection object. This smart connection object resembles a normal connection object with the server from the perspective of the application but does not provide a real connection to that server. Instead, the smart connection object acts to efficiently manage a real connection object representing an actual connection with the server. The real connection object is not directly available to the client applications, and is managed by the smart connection object in such a way that the actual connection is provided when needed, reused as much as possible and destroyed when the actual connection is unused for an excessive amount of time. The client (through its applications) makes requests to access the server. Responsive to such requests, the smart connection object first checks to see if a real connection object (representing an actual connection to the server) is available. If so, that existing real connection object handles the request. If not, a real connection object is created. The real connection object is thereafter maintained until the actual connection to the server goes unused until a delay time expires. At that point, the real connection object is destroyed (closed). The smart connection object remains in place until the application is terminated.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the method and apparatus of the present invention may be acquired by reference to the following Detailed Description when taken in conjunction with the accompanying Drawings wherein:

FIGURE 1 is a block diagram illustrating a client-server relationship and connection manager of the present invention; FIGURE 2 is a flow diagram for an "open" operation performed by the connection manager;

FIGURE 3 is a flow diagram for a "close" operation performed by the connection manager; FIGURE 4 is a block diagram illustrating a client-server relationship and smart connection mechanism of the present invention; and

FIGURE 5 is a flow diagram for the operation of the smart connection mechanism.

DETAILED DESCRIPTION OF THE DRAWINGS

Reference is now made to FIGURE 1 wherein there is shown a block diagram illustrating a client-server relationship and connection manager of the present invention. An application 10 being executed in the client 12 includes threads and routines (not explicitly shown) that may generate requests 14 to open or close access to the server 16. The server may, for example, comprise a database such as a lightweight directory access protocol (LDAP) server. The requests 14 are handled by a singleton object 18 acting as a connection manager and implementing a connection management process (to be described in more detail herein) the generally speaking provides the actual connection when needed, reuses the actual connection as much as possible and destroys the actual connection when unused for an excessive amount of time. Advantageously, this singleton object 18 may be quite easily accessed throughout the diverse modules (not shown) of the application. The singleton object 18 implements two primary management operations. A first operation, called "open," generally responds to a request 14 to open access by either opening a new connection (such as a TCP/IP connection) 20 to the server 16 or re-using a currently available

(i.e., previously opened) connection (see, FIGURE 2 for particulars). A second operation, called "close," generally responds to a request 14 to close access by closing an open connection if it has not been used (i.e., it remains idle following receipt of the request to close) for a certain period of time (see, FIGURE 3 for particulars).

Reference is now made to FIGURE 2 wherein there is shown a flow diagram for the "open" operation performed by the singleton object 18 (connection manager). This operation is executed by the singleton object 18 in response to any application

10 generated request 14 to open access to the server 16. In decision step 30, a determination is made as to whether an open connection 20 currently exists with the server 16. If not (path 32), a new connection 20 is opened (step 34) and authenticated (step 36). If yes in step 30, or following authentication in step 36, a connection counter is incremented by one in step 38. The process then returns (step 40) a connection reference to the requesting application. The process then ends. In this way, the requesting application may advantageously reuse an already opened connection (if yes in step 30) and avoid having to authenticate (step 36).

Reference is now made to FIGURE 3 wherein there is shown a flow diagram for a "close" operation performed by the singleton object 18 (connection manager).

This operation is executed by the singleton object 18 in response to any application 10 generated request 14 to close access to the server 16. In step 50, the connection counter is decremented by one. Next, in decision step 52, a determination is made as to whether the counter has reached zero. If no (path 54), the close operation returns in step 56 to await another request 14 (either to open or close). If yes (path 58), indicating that all open requests in the client have been matched by corresponding close requests, an idle timer is started in step 60 to measure a length of time that the open connection 20 remains open and idle (i.e., not in use by the client and one of its applications). The process then returns in step 56 to await another request 14 (to open). In the meantime, responsive to starting of the idle timer, a determination is made in decision step 62 as to whether the idle time has expired (i.e., the timer has timed out). If yes (path 64), the open connection 20 is closed in step 66 and the process returns in step 56 to await another request 14 (to open). If no (path 68), the connection counter is again checked in step 70 to ensure that it is still zero (i.e., that no new requests 14 to open have been received in the interim period while the idle timer is running). If yes (path 72), the process loops back to decision step 62. If no (path 74), the idle timer is ended in step 76 and the process returns in step 56 to await another request 14 (to open or close).

The procedure implemented by the connection manager singleton object 18 provides a simple way to optimize the connection life cycle between clients and their associated server by preventing undue usage and monopolization of connection ports . It is recognized that a new connection is opened and authenticated between a client and its server in response to an initial request, and that connection is then reused in response to later received requests. In fact, as long as new requests to open are received, the previously established connection remains open and is efficiently reused to handle those requests. It is only after all requests to open have been served (i.e., corresponding close requests are received and the counter is decremented to zero) that the timer starts counting down to close the connection. Advantageously, even though the connection is idle at that point, it remains open on the chance that the client and one of its applications will make another request. If this occurs before the timer expires, the existing open connection is efficiently reused and there is no need to re- perform the authentication process. This maximizes the efficient use of existing connection while still providing for timely closure of unused idle connections.

Reference is now made to FIGURE 4 wherein there is shown a block diagram illustrating a client-server relationship and smart connection mechanism of the present invention. An application 110 being executed in the client 112 includes threads and routines (not explicitly shown) that may generate requests to access the server 116. The server may, for example, comprise a database such as a lightweight directory access protocol (LDAP) server, and the requests may comprise methods relating to database access such as, for example, add, modify, search, delete and close. When an application 110 is started in the client, a smart connection factory 118 responds by instantiating a smart connection object 120 for that application. One smart connection object 120 is accordingly provided for each opened application 110. The smart connection object 120 resembles a normal connection object with the server 116 from the perspective of its corresponding application 110 but does not provide a real (or actual) connection to that server. Notwithstanding the foregoing, it appears to the application 110 as if such an actual connection exists through the smart connection object 120. Provision of an actual connection (such as a TCP/IP connection 114) with the server is made in accordance with a management process (to be described in more detail herein) using a single real connection object 122 (per object 120) that is created and managed by the smart connection object 120 through the use of a connection factory 124. This real connection object 122 is encapsulated within the smart connection object 120 and is not directly available to the client applications 110.

Reference is now made to FIGURE 5 wherein there is shown a flow diagram for the operation of the smart connection mechanism. Generally speaking, the actual connection with the server is managed by the smart connection object in such a way that the actual connection is provided when needed, reused as much as possible and destroyed when the actual connection is unused for an excessive amount of time. In step 170, the application is opened (started). Responsive thereto, the smart connection factory creates (step 172) the smart connection object for that application. Again, this smart connection object appears, from the perspective of the client application, to comprise an actual connection in spite of the fact that it, by itself, does not provide that connectivity. In step 174, the client (through an open application) makes a request to access the server. Responsive to such a request, the smart connection object first checks in decision step 176 to see if a real connection object (representing an actual connection to the server) is available. If so (path 178), the timer (see also separate thread) is reset in step 180, and that existing real connection object handles (step 182) the request for communication with the server using its associated actual connection. If not (path 184), the timer (see also separate thread) is started in step 186, and a real connection object is created in step 188 using the connection factory of the smart connection object and the request is handled (step 182). In either case, the real connection object is maintained until closed by the separate timer thread, and the process loops back to test in step 190 whether the application has been closed. If so, the smart connection object is destroyed in step 192 (which may also destroy the real connection object if still alive) and the process ends. With respect to the timer thread, the process starts in step 186, the timer is initialized in step 194 and a determination is made in step 196 as to whether the timer has expired. If not, the process tests whether it has been instructed by the connection object management thread in step 180 to reset and then loops back to decision step 196. If reset in step

180, the process returns to step 194. If the time has expired in step 196, the process closes the real connection object in step 198 and the timer thread ends.

Concerning the issue of authenticating the client/application with database, when the application is started its authentication related credentials are provided to the smart connection factory 118 which then creates the smart connection obj ect 120. The object 120 is aware of these credentials, but no authentication takes place at this time. When the smart connection object 120 later receives requests to access the server, the smart connection object invokes the connection factory 124 with those credentials. The connection factory then creates a real connection object 122. It is at creation of this object 122 (see, FIG. 5 step 172) that the client/application is authenticated with the server.

The procedure implemented to manage the connection through the smart connection obj ect provides a mechanism to optimize the connection life cycle between a client application and an associated server. From the perspective of the open application, the smart connection object gives the appearance of an actual connection without requiring one. This advantageously prevents undue usage and monopolization of connection ports by an application. An actual connection is opened with the server using an encapsulated real connection object in response to an initial request for access, and that actual connection is then reused in response to later received requests for access. In fact, as long as new requests for access are received, the real connection object provided actual connection remains open and is efficiently reused to handle those requests. If the actual connection thereafter remains idle for an excessive period of time, the actual connection is closed. In the meantime (as the idle time is measured), the actual connection remains available on the chance that the client application will make another request for access. If this occurs before the timer expires, the existing actual connection is efficiently reused. This maximizes the efficient use of the existing connection while still providing for timely closure of unused idle actual connections. When the application closes, the smart connection object (that provides a "virtual" connection to the server from the perspective of the application) is terminated.

Although preferred embodiments of the method and apparatus of the present invention have been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it will be understood that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.

Claims

WHAT IS CLAIMED IS:

1. A system, comprising: a server; a client including at least one application making requests to open and close a communications connection with the server; and a connection manager that manages the communications relationship between the client and the server, the connection manager operating in response to a received application request to open by determining whether a communications connection with the server is already in place and if so reusing that connection to handle the application request, and operating in response to a subsequently received application request to close by delaying closing of the connection for a predetermined time period and checking during that time period as to whether a new application request to open is received before closing the connection at the expiration of the time period.

2. The system of claim 1 wherein the server comprises a lightweight directory access protocol database.

3. The system of claim 1 wherein the communications connection comprises a TCP/IP connection.

4. The system of claim 1 wherein the connection manager responds to a received application request where a communications connection with the server is not already in place by opening a connection and authenticating the client for use of that connection and access to the server.

5. The system of claim 1 wherein the connection manager maintains a record of the received requests to open and does not begin the process to delay closing of the connection for the predetermined time period until a corresponding request to close has been received for each of the recorded requests to open.

6. The system of claim 5 wherein the record comprises a counter that is incremented for each received request to open and decremented for each received request to close, and wherein the process to delay closing of the connection is not begun until the counter is decremented to zero.

7. A connection management method, comprising the steps of: receiving a request to open a communications connection between a client and a server; determining whether a communications connection with the server is already in place; if so, reusing that connection to handle the request to open; receiving a subsequent request to close that communications connection; delaying closing of the communications connection for a predetermined time period; and checking during that time period as to whether a new request to open is received before closing the connection at the expiration of the time period.

8. The method of claim 7 wherein the communications connection comprises a TCP/IP connection.

9. The method of claim 7 further comprising the step of: responding to a received application request where a communications connection with the server is not already in place by opening a connection and authenticating the client for use of that connection and access to the server.

10. The method of claim 7 further including the steps of: maintaining a record of the received requests to open and performing the step of delaying only when a corresponding request to close has been received for each of the recorded requests to open.

11. The method of claim 10 wherein the step of maintaining comprises the steps of: incrementing a counter for each received request to open; and decrementing the counter for each received request to close; and wherein the step of delaying is performed when the counter is decremented to zero.

12. A system, comprising: a server; a client including at least one open application capable of making requests for access to the server; a smart connection object instantiated in response to the opening of the application, the smart connection object presenting from the perspective of the client application the appearance of an actual connection to the server without providing that actual connection; and a real connection object instantiated by the smart connection object in response to receipt of an initial client application request for access to the server, the real connection object being encapsulated within the smart connection object and providing an actual connection to the server for the handling of received client application requests for access; wherein the smart connection object further manages the provision of the real connection object by closing the real connection object, following handling of the initial client application request, in the event no additional client application requests for access to the server are received within a predetermined time period.

13. The system of claim 12 wherein the server comprises a lightweight directory access protocol database.

14. The system of claim 12 further comprising a smart connection factory operating responsive to the opening of the application to instantiate the smart connection object.

15. The system of claim 12 wherein the smart connection object further comprises a connection factory responsive to the initial client application request to instantiate the real connection object encapsulated within the smart connection object.

16. The system of claim 12 wherein the smart connection object is closed in response to termination of the application.

17. The system of claim 12 wherein the real connection object is maintained to handle subsequent client application requests for so long as the predetermined time period has not expired.

18. A connection management method, comprising the steps of: detecting the opening of a client application capable of making requests for access to a server; instantiating a smart connection object in response to the opening of the application, the smart connection object presenting from the perspective of the client application the appearance of an actual connection to the server without providing that actual connection; receiving at the smart connection object in initial request for access to the server; instantiating a real connection object in response to the received initial request, the real connection object being encapsulated within the smart connection object and providing an actual connection to the server for the handling of received client application requests for access; managing the provision of the real connection object by closing the real connection object, following handling of the initial client application request, in the event no additional client application requests for access to the server are received within a predetermined time period.

19. The method of claim 18 further comprising the step of closing the smart connection object in response to termination of the application.

20. The method of claim 18 further comprising the step of maintaining the real connection object to handle subsequent client application requests for so long as the predetermined time period has not expired.