Device and method for recovering session between server and client

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

The present invention relates to a client / server session recovery, and more particularly to a technique for recovering a client / server session from a TCP / IP processing failure.

【0002】

[Conventional technology]

Typically, client / server communication requires the use of protocols such as TCP / IP (Transmission Control Protocol / Internet Protocol). An example of client / server communication is when the client acts as a dam terminal for the server and the client user accesses an application stored in memory by the server software. In TCP / IP, a socket is a communication interface that enables communication between a client and a server. To connect to the server, the client communicates with the server listening socket. Normally, the server and the client exchange data via a data socket. The client has a client data socket and the server has a server data socket for each client. The client data socket and the server data socket specified for that particular client are logically connected.

【0003】

[Problems to be Solved by the Invention]

However, processes running the TCP / IP protocol can sometimes crash (corrupt). In traditional systems, such an error causes the server to terminate the client / server session. Therefore, a new session must then be established. As a result, a significant amount of the data generated by the application software can be lost.

【0004】

In some systems, backup TCP / IP processing is performed by the backup server. While the main TCP / IP process is being performed, the main TCP / IP process checks the server data socket configuration and state information for the backup TCP / IP process. If the main TCP / IP process gets stuck or is stopped by the operator, the backup TCP / IP process will take over. Such a process is called a switchover or switchover. At the time of the switchover, the server data socket becomes unavailable by the application software until a long wait time elapses. RFC (Internet request for comment) No. 793 describes this waiting time, that is, the MSL (Maximum Segment Lifetime) waiting time in the range of 60 seconds to 2 to 4 minutes.

【0005】

Occasionally, the process of executing TCP / IP may send an error message even though it has not crashed. Typically, in such situations, the TCP / IP process blocks the use of the server data socket for a fixed amount of time, such as the MSL latency. The present invention has been made in view of the above points, and an object of the present invention is to enable quick recovery of a session even in the event of a switchover or a problem with TCP / IP.

【0006】

[Means for solving problems]

The present invention relates to a device and a method for high-speed session recovery when a session is interrupted due to an error such as a TCP / IP processing failure. This method and system implements a method for recovering a session without the long latency required by, for example, a switchover or the occurrence of an error message, such as MSL (Maximum Segment Lifetime). This method and system also eliminates the need for the user to manually reconnect to the server for a new session.

【0007】

In a preferred embodiment of the invention, when a client / server communication protocol process such as TCP / IP process issues an error message to the server and client, the server and client will each have their previous server data socket and client data. Switch from a socket to a new server data socket and a new client data socket. This switching is realized by having the client open the listening socket during the initialization process. For example, in the case of an error message from the TCP / IP process, the client listens to a connection from the server to obtain a new data socket by using the client listening socket.

【0008】

From a systematic point of view, a preferred embodiment of the present invention is a server device for recovering a session between a server and a client. The server device includes a communication protocol portion that provides communication between the server and the client. The communication protocol portion includes a portion that provides a server listening socket and a portion that provides a server data socket. Further, the communication protocol portion provides a new server data socket for sending data to the client when the communication protocol portion generates an error message, and a portion for switching from the server data socket to a new server data socket. Includes.

【0009】

Also, from a methodological point of view, a preferred embodiment of the present invention is a method executed by a processor having memory to recover a session between a server and a client. The method includes a step by which the server determines that the client understands the interterminal protocol, a step by which the server receives an error message from communication protocol processing, and a step by which the server provides a first data socket. It consists of a closing step and a step of opening a second data socket for sending data to the client by the server.

【0010】

BEST MODE FOR CARRYING OUT THE INVENTION

Hereinafter, an embodiment of the present invention will be described in detail with reference to the accompanying drawings. FIG. 1 is a system for executing a preferred embodiment of the present invention, and is a diagram showing a system for performing session recovery from an error such as a failure of TCP / IP processing at high speed. The system in Figure 1 implements a method for easy session recovery without the long latency required by switchovers or error messages, for example. The system in Figure 1 also eliminates the need for the user to manually reconnect to the server for a new session.

【0011】

In FIG. 1, the CPU 110 has a memory 114. The second CPU 118 also has a memory 122. The CPUs 110 and 118, and these memories 114 and 122 are connected via a message system 126. Both CPUs 110 and 118 are connected to a LAN (Local Area Network) controller 130. The LAN controller 130 is connected to a router 134 (or a plurality of routers or the Internet). The router 134 is connected to LAN 138, which LAN 138 is connected to various clients such as client 142. The client 142 has a memory 144 and a CPU 148.

【0012】

The memories 114 and 122 store a main version and a backup version for various components in the system for the purpose of redundancy. The memory 114 stores a backup version of the application program 150. Further, the memory 114 stores a backup server 154 and a main TCP / IP process 158 including Telnet. Telnet is a simple remote terminal protocol typically used on the Internet. Further, the main LAN process 162 is also stored in the memory 114.

【0013】

Similarly, the memory 122 stores the main application 166, the main server 170, the backup TCP / IP process 174, and the backup LAN process 178. The memory 144 of the client 142 stores the client TCP / IP process 182 for communicating with the main TCP / IP process 158 and, if necessary, with the backup LAN process 178. There is.

【0014】

The primary server listening socket 186 is associated with the primary server 170 and is intended to allow all clients connected to the primary server 170 to access the primary server. However, each client 142 has access to a dedicated primary server data socket 190. Client 142 uses the primary server data socket 190 to send data to the primary server 170. Server listening sockets and server data sockets are also associated with backup server 154. However, for the sake of brevity, these are not shown in Figure 1.

【0015】

Related to the client 142 is the client listening socket 198. As will be described in detail later, for example, when the main TCP / IP process 158 fails, the client 142 hears a command from the main server 170 through the client listening socket 198. The main application 166 and the main server 170 are stored in the memory 122. However, the main TCP / IP process 158 is stored in the memory 114 so that it is executed by the CPU 110 instead of the CPU 118. In this way, if the CPU 110 fails, only the main TCP / IP process 158 is lost and the main server 170 is not lost.

【0016】

The system of FIG. 1 works by having the client 142 emulate a terminal for controlling the execution of the key application 166 via the key server 170. From the user's point of view, the client 142 operates as a terminal connected to the main server 170. An example of such an operation mode is NVT (Network Virtual Terminal).

【0017】

The main TCP / IP process 158 sometimes fails. In this embodiment, the backup TCP / IP process 174 takes over the main TCP / IP process 158 and sends an error message to the main server 170 and the client 142. An example of such an error message is the ECONNRESET error. The primary server 170 receives the ECONNRESET error via the primary server listening socket 186. Normally, upon receiving this error message, the primary server 170 disconnects from the client 142. Typically, when the primary server disconnects, the primary server closes the primary server data socket 190 dedicated to the particular client. In addition, the primary server 170 frees resources such as internal data structures associated with this session. However, in the system of FIG. 1, upon receiving the ECONNRESET error, the primary server 170 and client 142 are renewed from the primary server data socket 190 and the client data socket 194 (which were used when the ECONNRESET error occurred). It switches to the main server data socket and the new main client data socket, respectively, and quickly recovers the session controlled by the main TCP / IP process 158. The switchover to this new data socket will be described in detail later.

【0018】

2A and 2B are performed by the system of FIG. 1 at the initial connection 210 of the telnet session between the client 142 (indicated as C) and the primary server 170 (indicated as S). It is a flowchart which shows the step. In FIGS. 2A and 2B, time 214 elapses from top to bottom when the step is performed by the system of FIG. When the client 142 is connected to the primary server 170, the client 142 preferably determines if it has the ability to perform a data socket switchover. In this embodiment, not only the main server 170 but also the client 142 can perform switching from the main socket to another socket. In step 226, the client 142 can pull up the ability to switch to a new client data socket, for example, during its configuration.

【0019】

If it is determined that the client 142 has the switching ability, the client 142 allocates the client listening socket 198 in step 226. After allocating the client listening socket 198, the client 142 listens for communication from the main server 170 through the client listening socket 198. As will be described in detail later, upon receiving the error message from the backup TCP / IP process 174, the main server 170 will communicate with the client 142 via the client listening socket 198.

【0020】

In step 230, the primary server 170 detects a new connection from the client 142. Then, the main server 170 sets the main server data socket for data communication with the client 142. Next, in the same step 230, the main server 170 requests the terminal type 324 from the client 142 (see steps 310 to 322 in FIG. 3 described later). As shown in Figure 3, a large number of terminal types are available.

【0021】

In step 234, the client 142 sends the terminal type 324 of the client 142 to the main server 170. In step 238, the terminal type 324 of the client 142 is processed. To communicate with the client 142, the main server 170 sends a telnet command. Some of these Telnet commands will be described in detail later in relation to FIG. In step 242, the client 142 and the primary server 170 further communicate to establish a session, as is known in the art. In step 246, the primary server 170 establishes the session.

【0022】

The above steps initialize the session. This embodiment also performs additional initialization steps described below. According to this embodiment, in step 250, the main server 170 requests the terminal type 324 of the client 142 again (second time) (steps 330 to 332 in FIG. 3). In another embodiment, the main server 170 may request the terminal type 324 of the client 142 again (second time) immediately after step 238. In step 250, the primary server 170 determines if the client 142 has been modified to include the ability to switch to a new client data socket. This embodiment is a protocol called an "end-to-end protocol" because the main server 170 at one end and the client 142 at the other end can switch to a new data socket. To execute. As will be described later, the switching ability depends in part on the client 142 having the client listening socket 198. FIG. 3 shows in more detail the second request of the primary server 170 (having inter-termination protocol capability) for the terminal type 324. In step 254 of FIG. 2B, the end-to-end client 142 (ie, the client with end-to-end protocol capability) responds to the request of the primary server 170 by identifying the socket number of the client listening socket 198. To do.

【0023】

FIG. 3 is a diagram showing processing of terminal type 324. In step 310, the primary server 170 sends a standard telnet command to the client 142. The command in step 310 informs the client 142 that the main server 170 wants to process terminal type 324. In step 314, the client 142 responds by means of a standard telnet command that the client 142 is ready to supply its terminal type 324. In step 318, the primary server 170 sends the client a standard telnet command requesting the terminal type 324 of the client 142. In step 322, the client 142 sends its terminal type 324. Examples of client terminal types are listed after "type" in Figure 3. In step 330, the primary server with intertermination protocol capability sends a standard telnet command containing the second request for terminal type 324. In step 332, the client 142 returns a modified telnet command that includes not only the terminal type 324 but also the fact that it has end-to-end protocol recognition. This end-to-end protocol recognition 334 is indicated by "TE". Further, in the command of step 332, the client 142 specifies the client listening socket number 338 as indicated by pppp. The client listening socket number 338 identifies the client listening socket 198.

【0024】

Further, in step 254 of FIG. 2B, the non-end-to-end client returns only its terminal type 324. Of course, neither the end-to-end protocol recognition 334 nor the client listening socket number 338 is included in the non-end-to-end client response. In step 258, the primary server 170 records the client listening socket number 338. In addition, the primary server 170 records the fact that the client 142 has end-to-end protocol awareness. Record the socket number for future use. In step 262, the main server 170 generates session identification information (ID). The primary server 170 generates the session identification information (ID), preferably by using a time stamp combined with a secret text.

【0025】

In step 262, the primary server 170 sends the session ID to the client 142 using the modified telnet command 410 as shown in FIG. As shown in FIG. 4, the telnet command is modified by adding the extension "SESSION_ID_IS". In Figure 4, the session ID itself in the modified telnet command 410 is indicated by "ABC ... UTS". The session ID "ABC ... UTS" is 16 bytes, where each character can be a different byte. In step 266, the end-to-end client 142 records the session ID for use in switching new client data sockets, as described in detail later.

【0026】

As mentioned above, the main TCP / IP process 158 can crash. In the system of FIG. 1, when the main TCP / IP process 158 crashes, the backup TCP / IP process 174 takes over the main TCP / IP process 158. The backup TCP / IP process 174 sends an error message such as ECONNRESET to the main server 170 and the client 142. This is shown in step 514 of FIG. 5A. 5A and 5B are flowcharts of the steps performed by the end-to-end client 142 and the primary server 170 to recover the session interrupted by the error in primary TCP / IP processing 158. In step 518, the client 142 receives an error message from the backup TCP / IP process 174. In step 522, the primary server 170 also receives an error message from the backup TCP / IP process 174.

【0027】

In step 526, the client 142 closes the client data socket 194 that was used to exchange data between the client 142 and the primary server 170 prior to the error in the primary TCP / IP process 158. Further, in step 526, the client 142 informs the user that recovery is in progress. Further, in step 526, the client 142 listens to the client listening socket 198 in order to receive communication from the main server 170. If the client 142 receives no communication from the main server 170 via the client listening socket 198, the client 142 times out.

【0028】

In step 530, the primary server 170 examines, for example, a table to determine which client is associated with the error message sent by the backup TCP / IP 174. In addition, the primary server 170 checks its memory to determine if the client 142 is an end-to-end client. If not an end-to-end client, in step 530, the primary server 170 terminates the connection to the client.

【0029】

On the other hand, if it is an end-to-end client, the primary server 170 closes the primary server data socket 190 and obtains a new primary server data socket, for example through a telnet call "socket". The main server 170 then attempts to reconnect to the client 142 by communicating with the end-to-end client 142 via the client listening socket 198. The primary server 170 attempts to reconnect, for example through a telnet call "Connect".

【0030】

In step 538, the end-to-end client 142 receives an I / O completion signal from the primary server 170 via the client listening socket 198. During the course of the session, the end-to-end client 142 keeps informing the user of this fact. Further, when the I / O is completed, the end-to-end client 142 notifies the main server 170. In step 542, only for the end-to-end client 142, the primary server 170 again (third time) requests the terminal type 324 of the client 142. Further, in step 546, the end-to-end client 142 processes the request of the terminal type 324 by the main server 170. The end-to-end client 142 translates the client listening socket 198 into a new client data socket. Then, for example, if the backup TCP / IP process 174 takes over the failed primary TCP / IP process 158, the end-to-end client 142 will refer to the primary server 170 for further reference. Gives a new client listening socket number. The client 142 also informs the primary server 170 of the fact that it has intertermination protocol capability. This type of terminal processing, already described in connection with FIG. 3, is shown again in step 610 of FIG. (In other embodiments, steps 610 and 614 are omitted. However, if these steps 610 and 614 are omitted, some clients may not respond to step 618 by step 622. FIG. 6 shows a recovery command executed by the main server 170 and the end-to-end client 142 to recover the session.

【0031】

Then, in step 550 of FIG. 5B, the primary server 170 determines that the client 142 has inter-termination protocol capability based on the response of the end-to-end client 142. The primary server 170 communicates with many different clients at different times, some of which may not have inter-termination protocol capability, so check again to see if client 142 has inter-termination protocol capability. It is desirable to do.

【0032】

Further, in step 550, the primary server 170 requests the session ID from the end-to-end client 142. In step 262 of FIG. 2B described above, the main server 170 has already generated the session ID and sent it to the client 142. The modified telnet command for requesting the session ID is shown in step 626 of FIG. The telnet command has been modified by adding "SESSION_ID_SEND".

【0033】

In step 554 of FIG. 5B, the end-to-end client 142 gives the primary server 170 an encrypted version of the session ID received in step 262. A modified telnet command to give this encrypted session ID is shown in step 630 of FIG. 6, where the telnet command is modified by adding "SESSION_ID_IS". The encrypted session ID "ABC ... UTS" is based on the well-known MD5 method.

【0034】

In step 558, the primary server 170 verifies the authenticity of the session ID from the end-to-end client 142. If this confirmation is OK, the main server 170 switches the data socket connection to the client 142, which was originally the client listening socket 198, from the new main server data socket to the new client data socket. Of course, it will be appreciated from the above description that socket allocation may be done in a different way than above. For example, the client 142 may maintain the same client listening socket 198 and open a new client data socket instead of converting the client listening socket 198 into a new client data socket.

【0035】

In step 562, the primary server 170 generates a new session ID. The primary server 170 sends this session ID to the end-to-end client 142. The telnet command for sending the session ID, modified by the primary server 170, is shown in step 634 of FIG. In this command, "sssssssssssssss" is the new session ID. This new session ID is also 16 bytes, with each s indicating one byte.

【0036】

In step 566 of FIG. 5B, the end-to-end client 142 stores the new session ID sent by the primary server 170 in step 562. This new session ID is stored for other error message events from the backup TCP / IP process 174 that actually became the main TCP / IP process after the switch. In this way, session recovery 510 is completed.

【0037】

All of this session recovery was done without involving the Key Application 166 or Backup Application 150. In other words, the session recovery of the present invention allows the main server 170 to hide the error of the main TCP / IP process 158 from the main application 166. While the recovery is in progress, the main server 170 buffers commands and data from the main application 166. The main server 170 continues the buffer storage operation until the free space in the buffer memory is exhausted. When the free space in the buffer memory is exhausted, the main server 170 informs the main application 166 that the command needs to be tried again and / or the data needs to be sent again.

【0038】

So far, some preferred embodiments of the present invention have been described. However, various changes can be made without departing from the spirit and scope of the invention. In the event of a hardware failure, such as a router failure, the main TCP / IP process 158 sometimes raises an ECONNRESET error. In that case, switching the data socket does not resolve the failure of the router 134. However, the backup TCP / IP process 174 attempts to communicate with the client 142 via the client listening socket 198 only for a limited time. After this limited time elapses, the backup TCP / IP process 174 ceases to communicate with the client 142.

【0039】

Although the above embodiment has been described with respect to the main server 170 and the backup server 154, only one server 170 may be provided and the backup server 154 may be omitted. In fact, in the embodiments described here, backup is not used for each of the above items. In this embodiment, there is no failure of the TCP / IP processing, but for example, an error of the TCP / IP processing such that an error message such as ECONNERESET is sent to the server and the client 142 by the TCP / IP processing. Occurs. As mentioned above, the end-to-end client 142 and primary server 170 switch to new data sockets and reestablish connections for data transfer through these new data sockets.

【0040】

In another embodiment, the client 142 does not receive an error message such as ECONNERESET due to a failure. This failure is not a problem because the client 142 is not always listening to the client listening socket 198 to receive messages from the primary server 170. Upon receiving the primary server session recovery command, the end-to-end client 142 is programmed to close the client data socket 194 as described in step 526 above and continue as described with reference to FIG. There is.

【0041】

Although the above embodiment has been described for an ECONNERESET error, the invention is also applicable to other errors, in which case the end-to-end primary server 170 and the end-to-end client 142 It will respond to the other errors as described for the ECONNERESET error. An example of such another error is a timeout error. The timeout error is generated by the TCP / IP process 158 when the primary TCP / IP process 158 is unable to send data to the client 142. The reason why the data cannot be sent in this way is that the data buffer in the main TCP / IP process 158 is full. Another problem that can cause this timeout error is a hardware problem such as a router 134 or LAN 138 failure.

【0042】

As can be recognized by those skilled in the art from the above, the 16-byte session ID may be of any other length and may be based on an algorithm different from MD5. Further, the above embodiment can be used in an SPX / IPX (SPX is an abbreviation for Sequenced Packet Exchange) environment instead of the TCP / IP environment. The SPX, like TCP / IP, is a communication protocol for controlling message transmission in a network. IPX is a protocol for delivering messages. SPX / IPX is also embedded in the NetWare operating system supplied by Novell. As described above, the present invention is not limited to the above-described embodiment, and can be modified in various manners obvious to those skilled in the art.

【0043】

[Effect of the invention]

As described above, the present invention has an excellent effect that the session can be recovered quickly even at the time of switchover or when a problem related to TCP / IP occurs.

[Simple explanation of drawings]

[Figure 1]

FIG. 5 illustrates a system for fast session recovery from errors such as TCP / IP processing failures, according to a preferred embodiment of the present invention.

[Fig. 2A]

A diagram showing half of the messages exchanged by the system in Figure 1 during the initial connection from the client to the main server.

[Fig. 2B]

FIG. 5 shows the other half of the messages exchanged by the system of FIG. 1 during an initial connection from the client to a major server.

[Fig. 3]

FIG. 5 shows a second request of said major server requesting a terminal type when the client has inter-terminal protocol capability, according to an embodiment of FIG.

[Fig. 4]

The figure which shows the modified telnet command according to the embodiment of FIG.

[Fig. 5A]

FIG. 1 illustrates half of the steps performed by an end-to-end client and said primary server to recover a session interrupted by a major TCP / IP processing error in the embodiment of FIG.

[Fig. 5B]

FIG. 5 shows the other half of the steps performed by an end-to-end client and the primary server to recover a session interrupted by the major TCP / IP processing error.

[Fig. 6]

FIG. 5 shows a recovery command executed by the end-to-end client and the primary server to perform session recovery according to an embodiment of FIG.

[Explanation of symbols]

110,118 CPU 114,122 memory 126 Message system 130 controller 142 client 154 Backup server 158 Major TCP / IP processing 170 Main server 174 Backup TCP / IP processing 186 Main server listening socket 190 Main server data socket 194 Client data socket 198 Client listening socket