WO2000033189A1 - Method and apparatus in a data communication system for establishing a reliable internet protocol session - Google Patents

Method and apparatus in a data communication system for establishing a reliable internet protocol session Download PDF

Info

Publication number
WO2000033189A1
WO2000033189A1 PCT/US1999/022981 US9922981W WO0033189A1 WO 2000033189 A1 WO2000033189 A1 WO 2000033189A1 US 9922981 W US9922981 W US 9922981W WO 0033189 A1 WO0033189 A1 WO 0033189A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
client
server
computer
session
connection point
Prior art date
Application number
PCT/US1999/022981
Other languages
French (fr)
Inventor
Christopher John Richardson
Robert John Wiebe
Original Assignee
Motorola Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/02Communication control; Communication processing contains provisionally no documents
    • H04L29/06Communication control; Communication processing contains provisionally no documents characterised by a protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/12Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents characterised by the data terminal contains provisionally no documents
    • H04L29/12009Arrangements for addressing and naming in data networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/12Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents characterised by the data terminal contains provisionally no documents
    • H04L29/12009Arrangements for addressing and naming in data networks
    • H04L29/12047Directories; name-to-address mapping
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/12Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents characterised by the data terminal contains provisionally no documents
    • H04L29/12009Arrangements for addressing and naming in data networks
    • H04L29/12207Address allocation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/12Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents characterised by the data terminal contains provisionally no documents
    • H04L29/12009Arrangements for addressing and naming in data networks
    • H04L29/12783Arrangements for addressing and naming in data networks involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address, functional addressing, i.e. assigning an address to a function
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/15Directories; Name-to-address mapping
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/20Address allocation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/35Network arrangements or network protocols for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/14Network-specific arrangements or communication protocols supporting networked applications for session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/16Transmission control protocol/internet protocol [TCP/IP] or user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/40Techniques for recovering from a failure of a protocol instance or entity, e.g. failover routines, service redundancy protocols, protocol state redundancy or protocol service redirection in case of a failure or disaster recovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/16Transmission control protocol/internet protocol [TCP/IP] or user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32High level architectural aspects of 7-layer open systems interconnection [OSI] type protocol stacks
    • H04L69/322Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer, i.e. layer four
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32High level architectural aspects of 7-layer open systems interconnection [OSI] type protocol stacks
    • H04L69/322Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/327Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions in the session layer, i.e. layer five
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32High level architectural aspects of 7-layer open systems interconnection [OSI] type protocol stacks
    • H04L69/322Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer, i.e. layer seven

Abstract

A server computer (402) and a client computer (404) establish a reliable Internet Protocol (IP) application session through a first network connection point (410) associated with a first IP address, and thereafter, determine that the first network connection point (410) is inadequate for continuing the session. In response, the server computer (402) and the client computer (404) cooperate to transfer the session to a second network connection point (412) associated with a second IP address, without interrupting the session.

Description

METHOD AND APPARATUS IN A DATA COMMUNICATION SYSTEM FOR

ESTABLISHING A RELIABLE INTERNET PROTOCOL SESSION

Field of the Invention

This invention relates in general to Internet Protocol networking using client/server applications, and more specifically to the provision of reliable communications between a server and a client.

Background of the Invention

The Internet Protocol (IP) provides a method of establishing communication between applications on separate, networked computers. Each computer is assumed to be identifiable by one IP address; therefore, if there is a network problem that interrupts communication between the two addressable points, the applications are unable to maintain their conversation and the session terminates abnormally.

Some computer platforms, most notably those that are capable of operating in a clustered configuration, can support network connections via two or more independent IP addressable points. One such computer can simultaneously maintain IP connectivity to a network via several addresses, however the network considers each address to be a separate entity. Thus, if there is a network problem that interrupts communication on one of the addresses, affected applications still are unable to maintain their conversation and the session still terminates abnormally. What is needed is a method and apparatus for establishing a reliable Internet

Protocol (IP) session between a server application and a client application. When a network problem occurs during a session between two networked computers, both computers require a method of locating an alternate IP network connection point, re-establishing the connection, and completing the data exchange from the point of failure, without interrupting the session. Summary of the Invention

An aspect of the present invention is a method in a data communication system for establishing a reliable Internet Protocol (IP) session between a server application and a client application. The method comprises the steps of establishing the session through a first network connection point associated with a first IP address, and thereafter, determining that the first network connection point is inadequate for continuing the session. The method further comprises, in response to the determining step, the step of transferring the session to a second network connection point associated with a second IP address, without interrupting the session.

Another aspect of the present invention is a first computer in a data communication system for establishing a reliable Internet Protocol (IP) session between a server application and a client application. The first computer comprises a network interface for establishing the session with a second computer through a network, and a processing system for controlling the session. The processing system is programmed to establish the session through a first network connection point associated with a first IP address, and thereafter, to determine whether the first network connection point is inadequate for continuing the session. The processing system is further programmed, in response to determining that the first network connection point is inadequate, to transfer the session to a second network connection point associated with a second IP address, without interrupting the session.

Another aspect of the present invention is a second computer in a data communication system for establishing a reliable Internet Protocol (IP) session between a server application and a client application. The second computer comprises a network interface for establishing the session with a first computer through a network, and a processing system for controlling the session. The processing system is programmed to establish the session through a first network connection point associated with a first IP address, and thereafter, to determine whether the first network connection point is inadequate for continuing the session. The processing system is further programmed, in response to determining that the first network connection point is inadequate, to transfer the session to a second network connection point associated with a second IP address, without interrupting the session. Brief Description of the Drawings

FIG. 1 depicts a prior-art IP client/server application session using available protocols.

FIG. 2 depicts a prior-art IP client/server application session interrupted during failure of part of the network connection.

FIG. 3 depicts a prior-art server computer with multiple network connections communicating with a client that has one network connection. FIG. 4 depicts an exemplary server computer with multiple network connection points communicating with a client computer in accordance with the present invention.

FIG. 5 depicts the exemplary server computer redirecting its client computer to an alternate network connection point in accordance with the present invention. FIG. 6 depicts a simplified schematic of FIGs. 4 and 5, in which an

Application Programmatic Interface (API), a Middleware Program (MP), and an Internet Protocol Network Layer (IPNL) are indicated in accordance with the present invention.

FIG. 7 depicts exemplary sets of IP addressable connection points that the server computer provides to its client computers, and exemplary connection information available to the client computer in accordance with the present invention.

FIG. 8 is an exemplary flow diagram depicting how the client computer utilizes the information it possesses about a server computer's network connection points to select a connection point and establish communication with the server computer in accordance with the present invention.

FIG. 9 is an exemplary flow diagram depicting how the server computer advertises additional network connection points to a client that has already established communication with the server computer in accordance with the present invention.

FIG. 10 is a ladder diagram depicting an example communication session between a client computer and the server computer in accordance with the present invention.

FIG. 11 depicts an exemplary list of additional server computer connection points maintained by the client computer once the server computer has made the information available. FIGs. 12-14 are ladder diagrams depicting example communication sessions between a client and server computer in accordance with the present invention.

FIG. 15 is an electrical block diagram of an exemplary computer suitable for use either as the server computer or as the client computer, in accordance with the present invention.

Detailed Description of the Drawings

Referring now to the drawings, FIG. 1 depicts a prior-art IP client/server application session using available protocols. The session takes place through a conventional server IP network layer 110, an IP network 106, and a conventional client IP network layer 116. When a server application 108 running on the server computer 102 with a single IP network connection point 112 maintains a session with a client application 118 running on a client computer 104, the session is subject to the failure of, or congestion within, the network connection point 112, 114 at either the client or server end.

FIG. 2 depicts a prior-art IP client/server application session interrupted during failure of part of the network connection, showing the effect of such a failure when it occurs at the server network connection point 112. As a result of the indicated failure, the application session is lost and any data transfer that may have been underway at the time is terminated with an accompanying loss of data.

FIG. 3 depicts the prior-art server computer 102 with multiple network connections for communicating with the client computer 104, which has one network connection. The server computer 102 can support multiple independently- addressable IP network connection points 302. The client computer 104 must select one of the server computer's available connection points 302 to establish communication. Once a session has begun, if the selected one of the network connection points 302 fails or has congestion, the session can be interrupted and can terminate abnormally. FIG. 4 depicts an exemplary server computer 402 with multiple network connection points 410, 412 communicating with a client computer 404 in accordance with the present invention. An Application Programmatic Interface (API) (not shown) and a middleware program 406 reside on the server computer 402, directing the application 108 to one of two available IP network connection points 410, 412 for receipt of application session requests. The middleware program 406 provides a layer of insulation between the application 108 and the multiple network connection points 410, 412, managing the provision of network connections to the application 108. A similar API and middleware program 408 also reside on the client computer 404, managing the selection of the target network connection points 410, 412 on the server computer 402. The middleware programs 406, 408 maintain a session between the application 118 on the client computer 404 and the application 108 on the server computer 402 in case the connection point, e.g. , the connection point 410, at the server end fails. In one embodiment, the communications between the server middleware program 406 and the client middleware program 408 preferably employ portions of a communication protocol known as Radio Data-Link Access Procedure (RD-LAP), available from Motorola, Inc. of Schaumburg, IL.

FIG. 5 depicts the exemplary server computer 402 redirecting its client computer 404 to an alternate network connection point 412 in accordance with the present invention. FIG. 5 is similar to FIG. 4, the essential difference being that in FIG. 5 the IP network connection point 410 has become inadequate for continuing the session, e.g. , it has failed or is congested. In response, the two middleware programs 406, 408 advantageously cooperate to transfer the session through the network connection point 412, without interrupting the session. How the transfer takes place will be described further below.

FIG. 6 depicts a simplified schematic of the systems of FIGs. 4 and 5, in which an Application Programmatic Interface (API), a Middleware Program (MP), and an Internet Protocol Network Layer (IPNL) are indicated. In this drawing, the server and client applications 108, 118 are not shown, however, any application running on the client computer 404 with a session to another application on the server computer 402 will utilize the API 604 to the middleware program 408, which then manages the IPNL 116. Similarly, any application running on the server computer 402 with a session to another application on the client computer 404 will utilize the API 602 to the middleware program 406, which then manages the IPNL 110.

FIG. 7 depicts exemplary sets of IP addressable connection points that the server computer 402 provides to its client computers 404, and exemplary connection information available to the client computers 404 in accordance with the present invention. The server computer IP addresses are split into two groups: the Static Computer Addresses (SCAs) 706 and the Dynamic Computer Addresses (DCAs) 708. The middleware program 408 on the client computer 404 has access to local configuration information (e.g. , a host name) such that it can determine an SCA table 702 comprising SCAs belonging to the server computer 402 using standard techniques (e.g. a domain name server, a hosts file, etc.). In this example, a domain name server 704 maps the SCA host names from the SCA table 702 on the client computer 404 to an IP address belonging to the SCAs 706 on the server computer 402. The domain name server 704 also makes the set of DC As 708 available to the client computer 404. The server computer 402 will provide the list of available DCAs 708 to the client computer 404 once a connection has been established using one of the SCAs 706.

When an application on the client computer 404 wishes to establish communication with an application on the server computer 402, it issues an API " Connect" request. The API 604 passes the request to the middleware program 408, which then follows an algorithm to determine which of the available SCA IP addressable connection points provided by the server computer 402 will be used. FIG. 8 is an exemplary flow diagram depicting how the client computer 404 utilizes the information it possesses about a server computer's network connection points to select a connection point and establish communication with the server computer 402 in accordance with the present invention. First, the client computer 404 examines the SCA table 702 to select 802 the next available SCA host identifier. The client computer 404 then uses well known techniques to resolve 804 the SCA host identifier into an IP address. The client computer next uses additional well-known techniques to attempt 806 to establish a connection with the server computer's IP addressable connection point identified by the IP address just resolved. At step 808 the client computer 404 determines whether the connection attempt was successful. If successful, the client computer 404 proceeds to step 812; if a time-out or error occurred instead, the client computer 404 proceeds to step 810. At step 812, the connection has been established, and the client computer sends 812 a success indication to the application on the client computer 404, and then sends 814 a connection acknowledgment to the server computer 402. At step 810, the client computer checks whether there are additional, unused SCAs in the SCA table 702. If so the client computer 404 returns to step 802; otherwise the client computer 404 proceeds to step 816, where it sends a failure indication to the client application.

Once an application on the client computer 404 has established communication with an application on the server computer 402, the server computer's middleware program 406 can "advertise" a set of DCAs to the client computer's middleware program 408. The server computer's MP configuration may change at any time, so it also may advertise an updated DC A list to the client computer's middleware program 408 at any time. It will be appreciated that the SCA and DCA lists preferably are made fully available to the client middleware program 408 each time a new or replacement connection is made. More specifically, any state information associated with an SCA or a DCA indicating that a connection attempt to that address has failed during a previous execution of the flow chart of FIG. 8 should be cleared before the client computer 404 attempts to establish or re-establish a connection with the server computer 402.

FIG. 9 is an exemplary flow diagram depicting how the server computer 402 advertises additional network connection points to a client computer 404 that has already established communication with the server computer 402, in accordance with the present invention. First, the server computer 402 uses well-known techniques to accept 902 a connection request from the client computer 404 and to establish communication therewith. The server computer 402 then sends 904 a list of DCAs 708 to the client computer 404. The server computer 402 periodically determines 906 whether the DCA list on the server computer 402 has been updated. If it has been updated, the server computer determines 908 whether the client computer 404 is still connected to the server computer 402. If the connection is still available, the flow returns to step 904 to send the DCA list; otherwise the process ends. If, on the other hand, at step 906 the DCA list has not been updated, the server computer 402 repeats step 906 (after a predetermined waiting period).

FIG. 10 is a ladder diagram 1000 depicting an example communication session between a client computer and the server computer in accordance with the present invention. In the diagram, time progresses forward down the vertical axes, as depicted by the time line 1006. A server middleware line 1002 depicts events generated and received by the server middleware program 406, while a client middleware line 1004 depicts events generated and received by the client middleware program 408. First, the client middleware program 408 locates an SCA IP network connection point, SCA1, from its SCA table 702 and attempts to connect to it. In this case, the attempt fails, when the client middleware program 408 determines that a time-out has occurred on the connection attempt. Next, the client middleware program 408 locates the next SCA IP connection point, SCA2, from its SCA table 702 and attempts to connect to it. In this case, the connection attempt succeeds. In response, the server middleware program 406 issues a successful connection message (OK) to the client middleware program 408. The client middleware program 408 then issues an acknowledgment of receipt of the successful connection message to the server middleware program 406. The server middleware program 406 then sends its list of DCA IP connection points to the client middleware program 408. At some point in time during the connection, the server middleware program 406 determines that its DCA list has been updated. In response, the server middleware program 406 sends its list of DCA IP connection points to the client middleware program 408. FIG. 11 depicts an example DCA table 1102 comprising additional server computer connection points maintained by the client computer 404 once the server computer 402 has made the information available to the client computer 404. The client computer 404 has successfully established a connection to the server computer 402 via the IP addressable connection point referenced by the entry named "SCA2" in the SCA table 702 maintained by the client middleware program 408. After the connection was made, the server computer 402 sent a new list of IP addressable connection points to the client computer 404 which then stored the information in its DCA table 1102.

The algorithms detailed in FIGs. 8 and 9 can be employed to provide the client middleware program 408 with the ability to "roam" between available IP addressable connection points on the server computer 402. When failure or congestion within an established connection is discovered by the client middleware program 408, it can then attempt to establish a connection to one of the alternate IP addressable points referenced by entries in either the SCA or DCA tables 702, 1102. The server and client applications are unaware of the changed connection point.

FIGs. 12-14 are ladder diagrams 1200, 1300, 1400 depicting example communication sessions between the client and server computers in accordance with the present invention. The diagram 1200 demonstrates a typical exchange between the client and server computers 404, 402 employing the middleware embodiment of this disclosure. In this example, a connection fails while the client and server applications are performing a data transfer. The recovery is handled by the middleware programs 406, 408 in such a way that the applications are never aware that a failure has occurred. In this diagram, time progresses forward down the vertical axes, as indicated by the time line 1208. A first server middleware line 1202 depicts events generated and received by the server middleware program 406 through the IP connection point SCA2, while a second server middleware line 1206 depicts events generated and received by the server middleware program 406 through the IP connection point. Using the algorithm described in FIG. 8, the client middleware program 408 locates the IP connection point, SCA2, from its SCA table and establishes a connection to it; the server middleware program 406 issues the successful connection message (OK) to the client middleware program 408; and the client middleware program 408 sends an acknowledgment of receipt of the successful connection message to the server middleware program 406. The server middleware program 406 then sends its list of DCA IP connection points to the client middleware program 408. The client application 118 issues an API "Send" request to the client middleware program 408 to transmit its first set of data to the server application 108. The server middleware program 406 then acknowledges receipt of the first set of data and forwards the data to the server application 108. The client application 118 issues an API "Send" request to the client middleware program 408 to transmit its second set of data to the server application 108. The server middleware program 406 acknowledges receipt of the second set of data and forwards the data to the server application 108. The connection between the client computer and the server computer at the IP addressable connection point identified by SCA2 then fails. The client application 118 issues an API "Send" request to the client middleware program 408 to transmit its third set of data to the application on the server computer. The client middleware program 408 makes several attempts to transmit the data to the server computer 402 but is unsuccessful due to the connection failure. The middleware programs 406, 408 preferably provide a configurable setting for the number of transmissions that will be attempted before a connection is deemed to have failed. They also preferably provide a configurable setting for the delay between transmission attempts for the same set of data. Having determined that the connection to SCA2 is no longer available, the client middleware program 408 selects an alternate connection point on the server computer 402 from its SCA and DCA tables 702, 1102. Using the algorithm described in FIG. 8, the client middleware program 408 locates the IP connection point, DCA1, from its DCA table 1102 and establishes a connection to it; the server middleware program 406 issues the successful connection message (OK); and the client middleware program 408 acknowledges the connection. The client middleware program 408 then completes the API "Send" request for the third set of data by successfully transmitting the data to the new connection point, DCA1. The server middleware program 406 acknowledges receipt of the third set of data and forwards the data to the application 108 on the server computer 402.

The ladder diagram 1300 demonstrates an exchange between client and server computers employing the middleware embodiment of this disclosure. In this example, the client computer 404, while in the middle of data transfer, determines that the original connection point is congested and roams to an alternate connection point. The change is handled by the middleware programs 406, 408 in such a way that the applications are never aware that the connection point has switched. Using the algorithm described in FIG. 8, the client middleware program 408 locates the IP connection point, SCA2, from its SCA table and establishes a connection to it; the server middleware program 406 issues the successful connection message (OK) to the client middleware program 408; and the client middleware program 408 sends an acknowledgment of receipt of the successful connection message to the server middleware program 406. The server middleware program 406 then sends its list of DCA IP connection points to the client middleware program 408. The client application 118 then issues an API "Send" request to the client middleware program 408 to transmit its first set of data to the server application 108. The server middleware program 406 acknowledges receipt of the first set of data and forwards the data to the server application 108. The client application 118 issues an API " Send" request to the client middleware program 408 to transmit its second set of data to the server application 108. The server middleware program 406 acknowledges receipt of the second set of data and forwards the data to the server application 108. The client middleware program 408 detects congestion within the SCA2 connection point and initiates the connection algorithm. The client middleware program 408 sends a " Roam" notification to the server computer 402 to indicate that it will be changing connection points. The client middleware program 408 uses the algorithm described in FIG. 8 to locate a new IP connection point from its SCA and DCA tables 702, 1102. In this example, it successfully locates the connection point DCA1 , and establishes a connection to it. The server middleware program 406 issues a successful connection message (OK) and the client middleware program 408 issues an acknowledgment. The client middleware program 408 completes the API "Send" request for the third set of data by successfully transmitting the data to the new connection point, DCA1. The server middleware program 406 acknowledges receipt of the third set of data and forwards the data to the server application 108.

The algorithms detailed in FIGs. 8 and 9 can be employed by the server computer 402 to command the client computer 404 to " roam" to an alternate IP addressable connection point. The server computer 402 can specify a DCA or SCA connection point in the connection change command.

The ladder diagram 1400 demonstrates an exchange between client and server computers 404, 402 employing the middleware embodiment of this disclosure. In this example, the server computer 402, while in the middle of data transfer, determines that the original connection point is congested and directs the client computer 404 to roam to an alternate connection point. The change is handled by the middleware programs 406, 408 in such a way that the applications 108, 118 are never aware that the connection point has switched.

Using the algorithm described in FIG. 8, the client middleware program 408 locates the IP connection point, SCA2, from its SCA table and establishes a connection to it; the server middleware program 406 issues the successful connection message (OK) to the client middleware program 408; and the client middleware program 408 sends an acknowledgment of receipt of the successful connection message to the server middleware program 406. The server middleware program 406 then sends its list of DCA IP connection points to the client middleware program 408. The client application 118 issues an API "Send" request to the client middleware program 408 to transmit its first set of data to the server application 108. The server middleware program 406 acknowledges receipt of the first set of data and forwards the data to the server application 108. The client application 118 issues an API "Send" request to the client middleware program 408 to transmit its second set of data to the server application 108. The server middleware program 406 acknowledges receipt of the second set of data and forwards the data to the server application 108. The server middleware program 406 then detects congestion within the SCA2 connection point and issues a " Go To" command to the client middleware program 408. The server middleware program 406 can provide a new connection point identifier or can allow the client middleware program 408 to select the next available connection point from its SCA and DCA tables 702, 1102. In this example, the server computer 402 provides a specific connection point identifier, DCA1. The client middleware program 408 uses the algorithm described in FIG. 8, starting with the connection point identifier provided by the server middleware program 406, to locate a new IP connection point. In this example, it successfully locates the connection point DCA1, and establishes a connection to it. Had the connection attempt failed, the client computer would have sought the next available connection point from its SCA and DCA tables 702, 1102. The server middleware program 406 issues a successful connection message (OK) and the client middleware program 408 issues an acknowledgment. The client middleware program 408 completes the API " Send" request for the third set of data by successfully transmitting the data to the new connection point, DCA1. The server middleware program 406 acknowledges receipt of the third set of data and forwards the data to the server application 108. It will be appreciated that applications utilizing the middleware programs

406, 408 preferably conform to an API (not a specific API since several APIs can be layered on the same MP, and it is possible that the client and server could use different APIs). It will be further appreciated that the invention disclosed here can be extended from a single computer that supports multiple, independent IP addressable network connection points to a set of independent computers each with their own IP addressable network connection point(s). The middleware embodiment of this invention can be utilized to collect a group of such IP addressable computers into a set of related IP addressable network connection points, such that application sessions could be transferred between independent computers rather than between network connection points on the same computer. This extension would require an additional set of middleware that would ensure that the context of an application session could be transferred from one computer to another when the connection point is changed.

FIG. 15 is an electrical block diagram of an exemplary computer 402, 404 suitable for use either as the server computer 402 or as the client computer 404, in accordance with the present invention. The computer 402, 404 comprises a conventional network interface 208 for establishing an application session with another computer through a network. The computer 402, 404 further comprises a processing system 206 coupled to the network interface for controlling the session. A user interface 214 is coupled to the processing system 206 for interfacing with a user. The user interface 214 includes a display 216, such as a conventional video display, and a conventional keyboard 220. The processing system 206 comprises a conventional processor 210 coupled to a conventional memory 212, which preferably includes a mix of ROM, RAM, and magnetic disk memory elements. The memory 212 includes software programs and other data for programming the processing system 206 in accordance with the present invention. The memory 212 comprises at least one application 108, 118 for establishing the application session with a similar application in another computer through a network. The memory 212 further comprises the Application Programmatic Interface (API) 602,604 for programming the processing system 206 to interface with the application 108, 118 in a predetermined manner. The memory 212 also includes the middleware program 406, 408 for programming the processing system 206 to establish and maintain a reliable Internet Protocol (IP) session between the server application 108 and the client application 118, in accordance with the present invention. In addition, the memory 212 includes the Internet Protocol Network Layer (IPNL) 110, 116 for interfacing with the network. The memory 212 further comprises an SCA store 230 and a DCA store 232 for storing Static Computer Addresses and Dynamic Computer Addresses, respectively. The preceding examples have described a server computer having redundant links to the network, communicating with a client computer having a non- redundant link to the network. It will be appreciated that, alternatively, the roles can be reversed. That is, the client computer can have redundant links and can advertise DCAs, while the server computer has a single non-redundant link and stores SCAs and DCAs. It will be further appreciated that, as another alternative for even better link reliability, both the client computer and the server computer can have redundant links to the network and each can incorporate the link reliability features of both the server computer and the client computer, as described herein above, in accordance with the present invention.

Thus, it should be clear from the preceding disclosure that the present invention provides a method and apparatus for establishing a reliable Internet Protocol (IP) session between a server application and a client application. When a network problem occurs during a session between two networked computers, the present invention advantageously provides a technique for locating an alternate IP network connection point, re-establishing the connection, and completing the data exchange from the point of failure.

Many modifications and variations of the present invention are possible in light of the above teachings. For example, alternatively, the link redundancy can be performed with SCAs exclusively, without the use of DCAs and advertising. Thus, it is to be understood that, within the scope of the appended claims, the invention can be practiced other than as specifically described herein above.

Claims

What is claimed is:CLAIMS
1. A method in a data communication system for establishing a reliable
Internet Protocol (IP) session between a server application and a client application, the method comprising the steps of: establishing the session through a first network connection point associated with a first IP address; thereafter, determining that the first network connection point is inadequate for continuing the session; and in response to the determining step, transferring the session to a second network connection point associated with a second IP address, without interrupting the session.
2. The method of claim 1 , further comprising, after the establishing step, the step of advertising, by a computer associated with the first and second IP addresses, at least one available dynamic computer address (DCA) that can be used as the second IP address.
3. The method of claim 1 , wherein the determining step is performed by a middleware program, and wherein the transferring step comprises the step of establishing a connection with the second network connection point by the middleware program.
PCT/US1999/022981 1998-11-30 1999-09-30 Method and apparatus in a data communication system for establishing a reliable internet protocol session WO2000033189A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US20111198 true 1998-11-30 1998-11-30
US09/201,111 1998-11-30

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
AU6507199A AU6507199A (en) 1998-11-30 1999-09-30 Method and apparatus in a data communication system for establishing a reliable internet protocol session

Publications (1)

Publication Number Publication Date
WO2000033189A1 true true WO2000033189A1 (en) 2000-06-08

Family

ID=22744536

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/022981 WO2000033189A1 (en) 1998-11-30 1999-09-30 Method and apparatus in a data communication system for establishing a reliable internet protocol session

Country Status (1)

Country Link
WO (1) WO2000033189A1 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004019599A1 (en) * 2002-08-20 2004-03-04 Cisco Technology, Inc. System and method for providing fault tolerant ip services
EP1466434A1 (en) * 2002-01-14 2004-10-13 Netmotion Wireless, Inc. Method and apparatus for providing secure connectivity in mobile and other intermittent computing environments
US7228415B2 (en) * 2001-11-02 2007-06-05 General Instrument Corporation Method and apparatus for transferring a communication session
WO2007067483A2 (en) * 2005-12-05 2007-06-14 Motorola, Inc. Methods and apparatus for switching nodes to a new packet data connection point
WO2014158217A1 (en) * 2013-03-28 2014-10-02 Microsoft Corporation Efficient socket transfer
CN105359561A (en) * 2013-07-26 2016-02-24 英特尔Ip公司 Apparatus, system and method of selectively providing internet protocol (IP) session continuity
US9473925B2 (en) 1998-10-09 2016-10-18 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5426773A (en) * 1991-06-28 1995-06-20 International Business Machines Corporation Communication controller allowing continued communication through an X25 network and an SNA network in the event of an SNA session failure
US5652908A (en) * 1991-10-02 1997-07-29 International Business Machines Corporation Method and apparatus for establishing communications sessions in a remote resource control environment
US5661719A (en) * 1995-10-19 1997-08-26 Ncr Corporation Method for activating a backup network management station in a network management system
US5812413A (en) * 1994-04-04 1998-09-22 Fujitsu Limited Restructure support device and method for printed-wiring board
US5948108A (en) * 1997-06-12 1999-09-07 Tandem Computers, Incorporated Method and system for providing fault tolerant access between clients and a server
US6009474A (en) * 1997-05-20 1999-12-28 Compaq Computer Corporation Method and apparatus for re-assigning network addresses to network servers by re-configuring a client host connected thereto

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5426773A (en) * 1991-06-28 1995-06-20 International Business Machines Corporation Communication controller allowing continued communication through an X25 network and an SNA network in the event of an SNA session failure
US5652908A (en) * 1991-10-02 1997-07-29 International Business Machines Corporation Method and apparatus for establishing communications sessions in a remote resource control environment
US5812413A (en) * 1994-04-04 1998-09-22 Fujitsu Limited Restructure support device and method for printed-wiring board
US5661719A (en) * 1995-10-19 1997-08-26 Ncr Corporation Method for activating a backup network management station in a network management system
US6009474A (en) * 1997-05-20 1999-12-28 Compaq Computer Corporation Method and apparatus for re-assigning network addresses to network servers by re-configuring a client host connected thereto
US5948108A (en) * 1997-06-12 1999-09-07 Tandem Computers, Incorporated Method and system for providing fault tolerant access between clients and a server

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9473925B2 (en) 1998-10-09 2016-10-18 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US7228415B2 (en) * 2001-11-02 2007-06-05 General Instrument Corporation Method and apparatus for transferring a communication session
EP1466434A1 (en) * 2002-01-14 2004-10-13 Netmotion Wireless, Inc. Method and apparatus for providing secure connectivity in mobile and other intermittent computing environments
EP1466434A4 (en) * 2002-01-14 2005-09-07 Netmotion Wireless Inc Method and apparatus for providing secure connectivity in mobile and other intermittent computing environments
US7602704B2 (en) 2002-08-20 2009-10-13 Cisco Technology, Inc. System and method for providing fault tolerant IP services
WO2004019599A1 (en) * 2002-08-20 2004-03-04 Cisco Technology, Inc. System and method for providing fault tolerant ip services
WO2007067483A3 (en) * 2005-12-05 2007-12-13 Motorola Inc Methods and apparatus for switching nodes to a new packet data connection point
WO2007067483A2 (en) * 2005-12-05 2007-06-14 Motorola, Inc. Methods and apparatus for switching nodes to a new packet data connection point
WO2014158217A1 (en) * 2013-03-28 2014-10-02 Microsoft Corporation Efficient socket transfer
US9021157B2 (en) 2013-03-28 2015-04-28 Microsoft Technology Licensing, Llc Reliable socket transfer based on initializing and re-initializing a communication link and retaining a connected state
CN105359561A (en) * 2013-07-26 2016-02-24 英特尔Ip公司 Apparatus, system and method of selectively providing internet protocol (IP) session continuity
EP3025533A4 (en) * 2013-07-26 2017-04-12 Intel IP Corporation Apparatus, system and method of selectively providing internet protocol (ip) session continuity
US10015797B2 (en) 2013-07-26 2018-07-03 Intel IP Corporation Apparatus, system and method of selectively providing internet protocol (IP) session continuity

Similar Documents

Publication Publication Date Title
US5768531A (en) Apparatus and method for using multiple communication paths in a wireless LAN
US6721787B1 (en) System and method for wireless hot-synchronization of a personal digital assistant
US6424654B1 (en) Network system and DHCP server selection method
US7054291B2 (en) Method of and system for mobile station abbreviated point-to-point protocol negotiation
US5774660A (en) World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network
US5410543A (en) Method for connecting a mobile computer to a computer network by using an address server
US6484206B2 (en) Efficient recovery of multiple connections in a communication network
US6490291B1 (en) Device for data communications between wireless application protocol terminal and wireless application server, and method thereof
US20050154774A1 (en) Method of data transfer in mobile and fixed telecommunications systems
US6704282B1 (en) VPN tunnel redirection
US6871296B2 (en) Highly available TCP systems with fail over connections
US6678726B1 (en) Method and apparatus for automatically determining topology information for a computer within a message queuing network
US20030237018A1 (en) Server takeover system and method
US5526483A (en) Fast network file system running over a hybrid connectionless transport
US7293107B1 (en) Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US20060047791A1 (en) System and method of assigning and reclaiming static addresses through the dynamic host configuration protocol
US20100030880A1 (en) Failover in proxy server networks
US5862348A (en) Method and apparatus for connecting a client node to a server node based on load levels
US6219712B1 (en) Congestion control in a network
US6434113B1 (en) Dynamic network master handover scheme for wireless computer networks
US6226684B1 (en) Method and apparatus for reestablishing network connections in a multi-router network
US20050243817A1 (en) System and method for message routing in a network
US20030220990A1 (en) Reliable server pool
US20040032865A1 (en) Apparatus and method for establishing a call connection state in a packet data communication system
US20090265467A1 (en) Method and System for Load Balancing over a Cluster of Authentication, Authorization and Accounting (AAA) Servers

Legal Events

Date Code Title Description
ENP Entry into the national phase in:

Ref country code: AU

Ref document number: 1999 65071

Kind code of ref document: A

Format of ref document f/p: F

AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IS JP KE KG KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase