JP2006031685A - Socket connection management system and socket connection state check method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce unnecessary work that many application program modules executed on a server-client must manage to manage socket connections.
At least one application program module that generates a socket necessary for server or client communication, calls an API defined for checking a connection state of the socket, and manages the generated socket When an arbitrary API is called from the application program module, a common library module in which a program for performing an operation set in the called API is coded, and execution of the program coded in the common library module And a socket check execution module that periodically checks the connection state of the socket generated by the application program module.
[Selection] Figure 3

Description

  The present invention relates to socket management between a server and a client, and more specifically, manages a connection state between servers or facilities having a BSD, Unix (registered trademark), or Linux (Linux) system of operation and connection. The present invention relates to a socket connection management system that disconnects and reconnects when an abnormal problem occurs, and a socket connection state check method.

  Various applications are executed in a server or facility having an operating system (OS) of BSD, Unix (registered trademark), or Linux. When such applications communicate with each other, a connection-oriented protocol such as TCP (Transmission Control Protocol) is often used. TCP is a reliable, full-duplex, connection-oriented protocol that provides continuous bytes, basically providing error checking and retransmission and flow control functions for the reliability of transmitted data. To do. Therefore, the application executed on the server or the facility can know the connection state by the TCP protocol, and exchanges main messages between them using this.

  Most operating systems use sockets as an interface for connection-oriented protocols, and each application manages the sockets they each need to connect.

  The conventional connection-oriented socket system can be connected or released between the server and the client in a normal state, and can be released when the other party is disconnected. However, in situations where the other party's power is turned off on the server side or the client side, or the other party is removed by equipment consisting of a detachable slot, the connection socket is not released immediately, and the connection socket is not connected for a relatively long time. To maintain. Moreover, since the socket is considered to be continuously maintained, it is determined that information can be exchanged internally, which may cause malfunction. In particular, it becomes a further problem in the case of a real-time system.

  Also, not only when the connection is not released, but also when the connection between the server and the client is cut off due to a malfunction of a module between the server and the client, the specified socket must be released and reconnected. However, if the situation is not recognized, an error occurs that causes the malfunction state to be continuously maintained.

  FIG. 1 is a flowchart showing an error when a conventional connection-oriented socket is used.

  Referring to FIG. 1, the server 1 generates sockets with the first client 2 and the second client 3 and communicates with each other, even though a power failure occurs in the second client 3. However, without recognizing this, by subsequently transmitting data to the second client 3, an error in data transmission is caused.

  On the other hand, among standard socket options, there is one that performs connection management called “KEEPALIVE”. Generally, it has a basic value of 2 hours (7200 seconds), and there is no exchange of messages in the middle. Prompt connection recovery is impossible.

  Therefore, in most application programs, for processing in the above-described case, a check must be performed separately using a specific method for each application program. In this case, an individual program is used for each application program. Since it must have a connection management system, the very unnecessary work of having all similar functions implemented in all application programs is duplicated.

  In addition, since each connection management is not performed collectively, it is difficult to recognize whether the problem is actually a connection problem between the server and the client, or simply an operation problem between the corresponding applications, making system management difficult. There is a problem that becomes complicated.

  The present invention has been made to solve the above-described conventional problems, and the object of the present invention is to make sure that many application program modules executed on a server-client manage socket connections. It is an object of the present invention to provide a socket connection management system and a method for checking a socket connection state that can reduce unnecessary work that should not be performed.

  To achieve the above object, a socket connection management system according to an aspect of the present invention generates a socket necessary for server or client communication, and defines an API defined for checking a connection state of the socket. (Application Programmable Interface) is called, and at least one application program module that manages the generated socket, and when an arbitrary API is called from the application program module, an operation set for the called API is performed. The common library module in which the program is coded and the socket connection status generated by the execution of the program coded in the common library module are periodically checked. And a socket check execution module.

  In addition, the socket connection state check method according to another aspect of the present invention can be performed by executing an application program module programmed to generate and manage a socket required for server or client communication. Generating a socket, an application program module calling an arbitrary API (Application Programmable Interface) defined for checking the connection status of the generated socket, and an arbitrary API being called from the application program module When the operation is set, the operation set in the called API is executed by the common library module, and the socket check execution module generated by executing the program coded in the common library module. And periodically checking the connection state of the socket generated by the application program module using the program.

  A method for checking a socket connection state according to still another aspect of the present invention is a method for checking a connection state of a socket set in a server for setting an arbitrary client and socket, wherein the client and the socket are set. In this case, a step of calling a library function that stores a program for checking the connection state of the corresponding socket, a step of registering a socket to be checked periodically by executing the called library function, and By executing the library function, the socket check request message is periodically transmitted to the client, and the connection status of the registered socket is periodically determined depending on whether the socket check response message transmitted from the client is received. And having a step of checking And butterflies.

  A method for checking a socket connection state according to still another aspect of the present invention is a method for checking a connection state of a corresponding socket in a client that has set a socket with an arbitrary server, and sets the server and the socket. In response to a socket check request message periodically received from the server by calling a library function that stores a program for checking the connection status of the corresponding socket, and executing the called library function. Transmitting a socket check response message, and checking a connection state between the server and the set socket according to whether the socket check request message is periodically received.

  According to the present invention, by implementing a connection state check, a connection release and a reconnection function at the time of power-off of the other party in a common library form, which are basically not provided in a connection-oriented protocol such as TCP. Various application programs can provide corresponding functions using only interface functions of one module.

  As a result, each application program not only has the desired connection management function, but can also accurately grasp the connection state between the server and the client necessary for system management, enabling quick connection recovery or connection termination. To.

  In addition, many application program modules can eliminate the unnecessary work of managing connection of sockets and can be efficiently realized by using a library composed of one module. As a result, when an exceptional situation such as abnormal power off of the other party or dropping of a module occurs in a network clustering environment or in a server clustering environment, it can be applied with various application programs.

  In addition, errors that are not processed promptly, such as reconnection and connection release in TCP connection, can be easily and quickly processed. As a result, system management that can unify server-client connection management can be realized, and the reliability of the system can be improved.

  Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. However, the present invention is not limited to the following embodiments, and various modifications are possible.

  FIG. 2 is a block diagram of a server-client to which a socket management system according to an embodiment of the present invention is applied.

  Referring to FIG. 2, the server 100 and a plurality of clients 200, 300, 400, 500 are connected via a network. The server application program module executed on the server 100 and the client application program module executed on each client 200, 300, 400, 500 are connected by socket communication.

  The server application program module executed on the server 100 sets a socket necessary for communication with the client application program module executed on each client 200, 300, 400, 500, and connects the set socket. Check status periodically.

  Here, each application program module executed by the server 100 or each client 200, 300, 400, 500 provides various services by performing a process programmed in the application program module. Thus, the application program module can be realized in various forms according to the type of service provided by the server 100 or each of the clients 200, 300, 400, and 500.

  In addition, the application program modules can include various types of software application program modules that are operated in various digital processing procedures according to a server-client based communication protocol.

  In addition, the application program module is operated by a server-client based communication protocol, so that when executed by the server 100 or each client 200, 300, 400, 500, the server 100 and each client 200, 300, 400 , 500 generates a socket for communication between the application program modules, and after the communication is completed, a series of operations for releasing the generated socket connection are performed.

  Each application program module needs to grasp the connection state of the socket set between the server 100 and each client 200, 300, 400, 500 in real time. For this purpose, the application program module calls an API to check the connection state of the socket, and performs a socket check operation using a socket check execution module generated by the API.

  Here, each application program module generates a socket for communication with an arbitrary client, and applies a general technique to procedures for maintaining or releasing the generated socket. Therefore, in the following, a configuration and an operation in which an API (Application Programmable Interface) is called to check an arbitrary set socket and a socket check operation is performed using a socket check execution module generated by the API will be described in detail. To do.

  In the present embodiment, the application program module executed by the server 100 and each client 200, 300, 400, 500 defines an API for checking the connection state of sockets set between each other, and each application program The module calls the API and periodically checks the connection status for each socket.

  As a result, the API for providing the function of checking the connection state of the socket is binarized so that the server 100 and the clients 200, 300, 400, 500 can be used and called. Hereinafter, the API socket connection state check function is named health check (Health-Check), and HC (or hc) is used as an abbreviation. Thus, every API for checking the socket connection status starts with “hc_”.

  The server and client exchange messages for checking the connection status of the socket every cycle. The server transmits a health check request message (HC_REQUEST) for checking the connection state of the socket for each period to the client, and the client transmits a health check response message (HC_RESPONSE) to the server.

  FIG. 3 is a block diagram of a socket management system operating on a server according to an embodiment of the present invention.

  Referring to FIG. 3, the socket management system executed on the server generates a socket necessary for communication with the client, and defines an API (Application Programmable Interface) defined for checking the connection state of the socket. , And at least one application program module 110 for managing the generated socket, and when an arbitrary API is called from the application program module 110, an operation set for the called API is performed. A common library module 120 in which a program is coded, and a socket connection state generated by the execution of the program coded in the common library module 120 and generated by the application program module 110 And a socket check execution module 130 for checking automatically and a DB (database) 140.

  The application program module 110 encodes an API defined for checking the connection state of the socket. First, the defined API will be described.

  A server initialization API (hc_server_init) 111 is an API that generates a thread for a health check function used in the health check. The server initialization API is added to the application program start part. Hereinafter, the thread for the health check function is named the socket check execution module 130.

  The server registration API (hc_server_register) 112 is an API for registering a socket so that a connection state for an arbitrary socket can be checked by a health check. The server registration API opens a server socket in the application program module and is added to a position connected to the client. The socket connected to the client is registered, and thereafter the status is continuously checked.

  The server registration cancellation API (hc_server_unregister) 113 is an API for canceling the registration of the socket checked by the health check. The server registration cancellation API 113 is used in the application program module when releasing a normal socket. The server registration cancellation API 113 is coded at a position for releasing the connection with the client in the application program module.

  When the server process API (hc_server_process) 114 receives data from the corresponding socket registered so as to check the connection state of the socket by the application program module executed on the server, the corresponding data is data for health check. Confirm whether or not. Since the server process API 114 is for the server, it is for processing when a socket check response message (hc_response) that is a response to the socket check request message (hc_request) is received.

  The server release API (hc_server_exit) 115 is an API for releasing registration of all registered sockets and releasing the socket check execution module 130.

  In the common library module 120, when an arbitrary API is called from the application program module 110, a program for performing an operation set in each called API is coded. As a result, the common library module 120 is coded so as to be able to perform functions defined corresponding to the server initialization API 111, the server registration API 112, the server registration cancellation API 113, the server process API 114, and the server cancellation API 115, respectively. The program is provided.

  That is, when the server initialization API (hc_server_init) 111 is called from the application program module 110, the health code is executed by executing a program coded so as to be able to perform the function defined corresponding to the server initialization API 111. Create a socket check execution module to be used in the check, and prepare to periodically check the connection status of any socket.

  When the server registration API (hc_server_register) 112 is called from the application program module 110, an arbitrary program is executed in the health check by executing a program coded so as to be able to perform the function defined corresponding to the server registration API 112. The socket is registered in a predetermined socket check execution module 130 so that the connection state with respect to the socket can be checked.

  When the server registration cancellation API 113 is called from the application program module 110, the socket check execution module 130 checks by executing a program coded so as to be able to perform the function defined in correspondence with the server registration cancellation API 113. Cancel the registered socket. If the socket registration is canceled by the socket check execution module 130, the socket is released.

  When a server process API (hc_server_process) 114 is called from the application program module 110, an arbitrary message is received from the client by executing a program coded so as to be able to perform a function defined corresponding to the server process API 114. When the message is transmitted, it is confirmed whether or not the corresponding message is a health check response message corresponding to the health check request message transmitted from the server to the corresponding client, thereby changing the state value of the client.

  When the server cancellation API (hc_server_exit) 115 is called from the application program module 110, the socket check execution module 130 is executed by executing a program coded so as to be able to perform the function defined corresponding to the server cancellation API 115. All the sockets registered for checking the connection state of the corresponding socket are deregistered, and the corresponding socket check execution module 130 is released.

  By calling the server initialization API 111 from the application program module 110, a program coded so as to be able to perform the function defined corresponding to the server initialization API 111 in the common library module 120 is executed, and the socket check is performed. An execution module 130 is generated.

  The socket check execution module 130 transmits a health check request message in order to check the connection state of the corresponding socket with respect to the socket designated by the application program module 110 at each cycle, thereby causing a health check response message from the client. Depending on whether or not is received, the connection status of the socket is checked.

  The DB 140 stores the ID and status information of each client that is communicating with the server 100 by creating a socket.

  FIG. 4 is a block diagram of a socket management system operating on a client according to an embodiment of the present invention.

  Referring to FIG. 4, the socket management system executed on the client includes at least one application program module 210 programmed to call an API for checking the connection status of the socket, and any application program module 210. When an API is called, an application program module is generated by executing a common library module 220 in which a program for performing an operation set in the called API is coded, and a program coded in the common library module 220. The socket check execution module 230 that periodically checks the connection state of the socket generated by 210 and the DB 240 are configured.

  The application program module 210 has an API defined for checking the connection state of the socket. The API defined by the client will be described.

  In the client, a client initialization API 211, a client process API 212, and a client release API 213 are defined.

  The client initialization API (hc_client_init) 211 is an API that initializes variables used in the health check. The client initialization API 211 is coded at the start of the application program module.

  A client process API (hc_client_process) 212 is an API that checks and processes whether or not the data is health check data when the application program module 210 executed by the client receives data from the server 100. is there. This is for processing when the request message hc_request is received from the server by the API executed by the client.

  The client cancellation API (hc_client_exit) 213 is an API that initializes necessary variables and ends the health check operation.

  In the common library module 220, when an arbitrary API is called from the application program module 210, a program for performing an operation set for each called API is coded. Accordingly, the common library module 220 includes respective programs coded so as to be able to perform functions defined corresponding to the client initialization API 211, the client process API 212, and the client release API 213.

  That is, when the client initialization API (hc_client_init) 211 is called from the application program module 210, a program coded so as to be able to perform the function defined corresponding to the client initialization API 211 is executed, and the socket check is performed. Is prepared for periodically checking the connection state between the server and the set socket by generating the socket check execution module 230.

  When the client process API 212 is called from the application program module 210, the application program module executed on the client is executed by executing a program coded so as to be able to perform a function defined corresponding to the client process API 212. When 210 receives a message from the server 100, it determines whether the corresponding message is a health check request message (HC_REQUEST).

  When the client release API 213 is called from the application program module 210, the health check operation is released by executing a program coded so as to perform the function defined in correspondence with the client release API 213, and the corresponding socket. An operation for terminating the check execution module 230 is performed.

  By calling the server initialization API 211 from the application program module 210, a program coded so as to be able to perform the function defined corresponding to the server initialization API 211 in the common library module 220 is executed, and the socket check is performed. An execution module 230 is generated.

  If the socket check execution module 230 receives a health check request message transmitted to check the connection status of the corresponding socket with respect to the socket designated from the application program module 210 at each cycle, the socket check execution module 230 By transmitting the health check response message, the connection state of the corresponding socket can be checked depending on whether the health check response message is received from the server.

  The DB 240 stores socket setting information for the server 100 for maintaining the socket set with the server 100.

  FIG. 5 is a configuration diagram of a message (HC message) for checking a socket connection state according to an embodiment of the present invention.

  Referring to FIG. 5, the header of the health check message includes a magic number field (Magic Number), a message type field (Message Type), a client ID field (Client ID), and a packet length field (Length). The body includes a time stamp field (Timestamp), a time-out value field (Timeout Value), and a reserved field (Reserved).

  Each of the magic number field, the message type field, the client ID field, and the packet length field is assigned 2 bytes.

  The value set in the magic number field is a magic number for checking the connection status of the socket, and a specific value is set to determine whether or not the corresponding message is a health check message. The system time value is set.

  A value for displaying whether the corresponding message is a health check request message or a health check response message is set in the message type field.

  In the client ID field, an identifier of a client ID in which a socket connection with the server is set is set, and each client is distinguished.

  In the packet length field, the length of the message is set in order to check the transmission error of the corresponding packet.

  In the time stamp field, time information for transmitting the packet is set. When sending and receiving a message between the server and the client, the time stamp value is transmitted to the client by setting the current time in the time stamp field on the server in order to check whether or not the server operates normally. The value is set in the health check response message (HC_RESPONSE) as it is and transmitted to the server. The server checks whether this value comes correctly from the client, and determines the state of the client.

  In the timeout value field, the time after the health check request message is transmitted from the server to the client is counted, and if the health check response message is not received until a certain time elapses, the connection status of the corresponding socket is blocked. This is the timeout setting value for determining and forcibly blocking the socket.

  If the server transmission cycle Ts changes, the client wait cycle Tc must also change. Therefore, when the Tc value changes, a timeout value is set and transmitted. At this time, Tc preferably has a value of Ts + α. Here, α is a margin value set by the user.

  On the other hand, in order to manage each client by the server 100, it is necessary to store client status information. Accordingly, the server 100 configures the DB 140 in the form of an array or a linked list for each registered client socket, and includes a client ID (client ID), a client socket (client socket), and a client status (client status). Is stored.

  The client state can have three states as shown in FIG.

  Initially, if an arbitrary socket is registered in the socket check execution module 130 for the socket check in the end state (HC_ST_CLOSED), the state changes to a normal state (HC_ST_NORMAL), and the server socket check execution module 130 If a health check request message (HC_REQUEST) is transmitted to the client 200, the transmission state (HC_ST_SEND) is entered. Here, if the health check response message is received from the client 200, the state changes to the normal state (HC_ST_NORMAL) again. The server 100 transmits a health check request message (HC_REQUEST), and checks the state of the client 200 at the next check.

  As a result, the client that has received the health check request message from the server 100 transmits the health check response message to the server 100, and the server 100 changes the state of the corresponding client depending on whether the health check response message is received. Judgment is made and the status of the corresponding client is set in the DB 140.

  When an arbitrary message is received from the client, the application program module 110 executed by the server 100 calls the server process API 114. When the server process API 114 is called, the program coded in the common library module 120 is executed to determine whether the corresponding message received from the client is a health check response message. If the result of this determination is a health check response message, the status value of the corresponding client is set to the normal status (HC_ST_NORMAL).

  If it is in the normal state (HC_ST_NORMAL), it is a case where the health check response message is normally received.

  FIG. 7 is a flowchart for explaining socket management in a server by applying a socket management system according to an embodiment of the present invention.

  Referring to FIG. 7, when an arbitrary application program module is executed on the server, the application program performs a procedure for forming a socket with the set client, and checks the connection status of the socket. An API coded in the program module is called (step 100. In the figure, step is abbreviated as S. The same applies hereinafter). When the API is called by the application program module 110, the common library module 120 executes a program defined corresponding to the called API, and executes a socket check for periodically checking the connection state of the socket. A module 130 is generated (step 200).

  The application program module 110 generates an arbitrary client and socket, and then calls an API for registering the socket in the socket check execution module 130 in order to periodically check the connection state of the socket. As a result, the common library module 120 executes the program defined corresponding to the corresponding API, and registers the corresponding socket in the socket check execution module 130 for the health check for an arbitrary socket (step 300). .

  The socket check execution module 130 periodically checks the connection status of the registered socket (step 400).

  FIG. 8 is a flowchart showing an operation of the socket check execution module in the server according to the embodiment of the present invention.

  Referring to FIG. 8, the socket check execution module 130 once generated by the server 100 is registered with a socket to periodically check the connection state of the socket, and periodically performs a health check according to a set procedure ( Step 410).

  When one health check operation is performed, the socket check execution module 130 acquires current time information (step 420) and transmits a health check request to a client having a socket registered in the health check list. A message (HC_REQUEST) is generated (step 430). At this time, the ID of the client in which the corresponding socket is set, the current time information, and the timeout value are set in the header of the generated health check request message.

  The socket check execution module 130 transmits the generated health check request message (HC_REQUEST) to the corresponding client that has set the socket (step 440).

  FIG. 9 is a flowchart illustrating an operation of periodically checking a connection state of a registered socket by a socket check execution module of a server according to an embodiment of the present invention.

  Referring to FIG. 9, the socket check execution module 130 reads the status value of the corresponding client set in the DB 140 (step 411), and determines whether the client status value is a non-response state (step 412). ). If the client state is normal (HC_ST_NORMAL), it is a case where the message is normally received. If the client state remains in the transmission state (HC_ST_SENT), it can be determined that there is no response (No response).

  If there is no response as a result of this determination, the first count value is increased (step 413). Then, it is determined whether or not the first count value exceeds a predetermined first allowable number of times Ns (step 414). Here, the first allowable number of times Ns means the maximum number of times the server 100 waits for the clients 200 and 300 that do not respond.

  As a result of this determination, when the first count value exceeds the predetermined first allowable number Ns, the socket connection with the corresponding clients 200 and 300 is released (step 415).

  On the other hand, as a result of determining whether or not the state values of the clients 200 and 300 are in a no-response state, if it is not a response, it is determined whether or not the response is an incorrect response (step 416). As a result of this determination, if there is a response but the clients 200 and 300 having different magic values have an error, the second count value is increased (step 417). Then, it is determined whether or not the second count value exceeds a predetermined second allowable number of times Ns_w (step 418). Here, the second allowable number of times Ns_w means the maximum number of times that the server 100 waits for a continuous response having errors from the clients 200 and 300 having different magic values.

  As a result of this determination, if the second count value exceeds a predetermined second allowable number Ns_w, the log and timeout values are adjusted (step 419).

  FIG. 10 is a flowchart illustrating an operation performed when the socket check execution module of the client checks a socket according to an embodiment of the present invention.

  Referring to FIG. 10, the socket check execution module 230 of the client determines whether a health check request message (HC_REQUEST) is received from the server 100 before the reception cycle times out (step 510). If a health check request message (HC_REQUEST) is received as a result of this determination, a health check response message (HC_RESPONSE) is transmitted to the server 100 (step 520).

  When the health check response message (HC_RESPONSE) is transmitted to the server 100, the socket check execution module 230 initializes a reception cycle counter (not shown) (step 530) and then newly counts the reception cycle (step). 540).

  On the other hand, as a result of this determination, if the health check request message (HC_REQUEST) is not received before the reception cycle time-out and the reception cycle time-out is exceeded, the count value for counting the number of times the time-out has been exceeded is increased ( Step 550), it is determined whether this count value exceeds the allowable number of times (step 560). As a result of this determination, if the corresponding count value does not exceed the allowable number of times, the reception cycle counter is initialized (step 530) and the reception cycle is counted (step 540). If the number exceeds the allowable number, the socket connection is released (step 570).

  FIG. 11 is a flowchart of a health check message transmission between a server and a client according to an embodiment of the present invention.

  The socket health check function is realized by using periodic health check data between the server 100 and the clients 200 and 300 and both timers. The server 100 transmits a health check request message (HC_REQUEST), and the clients 200 and 300 transmit a health check response message (HC_RESPONSE) as a response thereto.

  Here, Ts is a period for transmitting a health check request message (HC_REQUEST) from the server 100 to the clients 200 and 300. When Ts timeout occurs, the client state is checked and a health check request message is sent to a normal client. (HC_REQUEST) is transmitted.

  Referring to FIG. 11, the first client 200 transmits a socket setting message to the server 100 and attempts connection. As a result, the server 100 sets a connection to the first client 200 and transmits a connection approval message. As a result, one socket is set between the first client 200 and the server 100.

  On the other hand, the second client 300 also transmits a socket setting message to the server 100 to attempt connection. As a result, the server 100 sets a connection to the second client 300 and transmits a connection approval message. As a result, one socket is set between the second client 300 and the server 100.

  The server 100 sets the socket with the first client 200 and the second client 300, and then checks the connection status of the socket with the first client 200 and the second client 300 at regular intervals. Each request message (HC_REQUEST) is transmitted.

  The first client 200 and the second client 300 that have received the health check request message (HC_REQUEST) from the server 100 transmit a health check response message (HC_RESPONSE) to the server 100.

  The server 100 that receives the health check response message (HC_RESPONSE) from the first client 200 and the second client 300 receives the first client 200 and the second client when it is time to transmit the health check request message (HC_REQUEST). A health check request message (HC_REQUEST) is transmitted to the client 300. At this time, the transmitted health check request message (HC_REQUEST) is set so that the magic number value is different from the previously transmitted health check request message (HC_REQUEST).

  Similarly, the first client 200 and the second client that have received the health check request message (HC_REQUEST) from the server 100 transmit a health check response message (HC_RESPONSE) to the server 100.

  FIG. 12 is a flowchart of client failure detection and processing using a health check message according to an embodiment of the present invention.

  Here, Ts is a cycle of transmitting a health check request message (HC_REQUEST) from the server 100 to the clients 200 and 300, and the first allowable number Ns is the maximum waiting for the clients 200 and 300 that do not respond in the server 100. Is the number of times. That is, if there is no response message from the client for a time of Ts * Ns, this is a variable used to release the connection at the server.

  Referring to FIG. 12, the server 100 sets the sockets with the first client 200 and the second client 300, and then connects the sockets to the first client 200 and the second client 300 at regular intervals. A health check request message (HC_REQUEST) for checking each is transmitted.

  The first client 200 and the second client 300 that have received the health check request message (HC_REQUEST) from the server 100 transmit a health check response message (HC_RESPONSE) to the server 100.

  The server 100 that receives the health check response message (HC_RESPONSE) from the first client 200 and the second client 300 receives the first client 200 and the second client when it is time to transmit the health check request message (HC_REQUEST). A health check request message (HC_REQUEST) is transmitted to the client 300. At this time, the transmitted health check request message (HC_REQUEST) is set such that the magic number value is different from the previously transmitted health check request message (HC_REQUEST).

  Similarly, the first client 200 that has received the health check request message (HC_REQUEST) from the server 100 transmits a health check response message (HC_RESPONSE) to the server 100.

  On the other hand, when a failure occurs in the second client 300, the second client 300 cannot send a health check response message (HC_RESPONSE) to the server 100. The client failure may include an error such as a client power-off.

  When it is time to transmit the health check request message (HC_REQUEST), the server 100 transmits the health check request message (HC_REQUEST) to the first client 200 and the second client 300. At this time, the transmitted health check request message (HC_REQUEST) is set so that the magic number value is different from the previously transmitted health check request message (HC_REQUEST).

  Similarly, the first client 200 that has received the health check request message (HC_REQUEST) from the server 100 transmits a health check response message (HC_RESPONSE) to the server 100.

  On the other hand, the second client 300 cannot send a health check response message (HC_RESPONSE) to the server 100 because the failure has not yet been resolved.

  When it is time to transmit the health check request message (HC_REQUEST), the server 100 sets a different magic number value for the first client 200 and transmits the health check request message (HC_REQUEST).

  However, when the number of times that the health check response message that should be received from the second client 300 is not received for the second client 300 exceeds the predetermined number Ns, the server 100 determines that the second client 300 Disconnect the socket set with.

  FIG. 13 is a flowchart showing a server failure detection and processing flow using the health check message according to the present embodiment.

  Here, Tc is a period of a timer that waits until the next health check request message (HC_REQUEST) is received after receiving the health check request message (HC_REQUEST) from the clients 200 and 300.

  If Nc does not send a health check request message (HC_REQUEST) from the server 100, the maximum number of times that the clients 200 and 300 wait, and if there is no response from the server for Tc * Nc time, the connection of the set socket is set. To release.

  Referring to FIG. 13, a health check request message (HC_REQUEST) is transmitted from the server 100 to the first client 200 and the second client 200. As a result, the first client 200 and the second client 300 transmit a health check response message (HC_RESPONSE) to the server 100 in response thereto.

  In the server 100, a health check request message is transmitted to the first client 200 and the second client 300 at predetermined intervals. When a failure occurs in the server 100, the health check request message is further transmitted. Cannot be transmitted.

  Server failures can include errors such as server power off, for example. In this case, whether or not the client should request reconnection may vary depending on the application program, and is therefore processed as an option.

  After transmitting the health check response message to the server 100, the first client 200 and the second client 300 check whether a health check request message is received from the server 100.

  Furthermore, the first client 200 and the second client 300 check the elapsed time after they transmit the health check response message to the server 100, and the number of times that the transmission cycle Tc timeout has elapsed is a predetermined number of times. When Nc is exceeded, the connection between the server 100 and the maintained socket is released.

  Then, the first client 200 and the second client 300 try a new connection in order to set a new socket in the server 100.

It is a flowchart which shows an error when using the conventional connection oriented socket. 1 is a configuration diagram of a server-client to which a socket management system according to an embodiment of the present invention is applied. FIG. 1 is a configuration diagram of a socket management system operating on a server according to an embodiment of the present invention. FIG. 1 is a configuration diagram of a socket management system operating on a client according to an embodiment of the present invention; FIG. It is a block diagram of the message (HC message) for the check of the socket connection state by one Embodiment of this invention. It is a state diagram of a client. 6 is a flowchart illustrating a flow of managing a socket in a server by applying a socket management system according to an embodiment of the present invention. 6 is a flowchart illustrating an operation of a socket check execution module in a server according to an embodiment of the present invention. 4 is a flowchart illustrating an operation of periodically checking a connection state of a registered socket by a server socket check execution module according to an exemplary embodiment of the present invention. 4 is a flowchart illustrating an operation performed when a socket check execution module of a client according to an exemplary embodiment of the present invention checks a socket. 4 is a flowchart of health check message transmission between a server and a client according to an exemplary embodiment of the present invention. 6 is a flowchart of client failure discovery and processing using a health check message according to an embodiment of the present invention. 6 is a flowchart of server failure discovery and processing using a health check message according to an exemplary embodiment of the present invention.

Explanation of symbols

100 server 200 client 1
300 Client 2
400 Client 3
500 clients 4
110 Application Program Module 120 Common Library Module 130 Socket Check Execution Module 210 Application Program Module 220 Common Library Module 230 Socket Check Execution Module

Claims (21)

At least one application that generates a socket required for server or client communication, calls an API (Application Programmable Interface) defined to check the connection status of the socket, and manages the generated socket A program module;
When an arbitrary API is called from the application program module, a common library module in which a program for performing an operation set in the called API is coded;
A socket check execution module that is generated by executing a program coded in the common library module and periodically checks the connection state of the generated socket;
A socket connection management system comprising: The API is
A server initialization API for generating a socket check execution module;
A server registration API for registering a socket in the generated socket check execution module so that a connection state to an arbitrary socket can be checked;
A server registration cancellation API for canceling the registration of the socket registered in the socket check execution module and checking the connection state;
A server process API for processing a socket check message received from a client;
A server release API for unregistering all sockets registered in the socket check execution module and releasing the socket check execution module;
The socket connection management system according to claim 1, comprising at least one API. The common library module is
A program coded to perform a function defined in response to a call to a server initialization API for generating a socket check execution module;
A program coded to perform a function defined in response to a call to a server registration API for registering a socket in the generated socket check execution module so that a connection state for an arbitrary socket can be checked;
A program coded to perform a function defined in response to a call to a server registration cancellation API for canceling registration of a socket that has been registered in the socket check execution module and that has been checking the connection state;
A program coded to perform a function defined in response to a call to a server process API for processing a socket check message received from a client;
A program coded to perform a function defined in response to a call to a server release API for releasing all sockets registered in the socket check execution module and releasing the socket check execution module;
The socket connection management system according to claim 1, wherein at least one of the socket connection management systems is provided. The socket check execution module is mounted on a server,
A socket check request message is periodically transmitted to the client that has set up an arbitrary socket with the server, and the connection status of the registered socket is determined depending on whether or not a socket check response message transmitted from the client is received. The socket connection management system according to claim 1, wherein the socket connection management system is periodically checked.   The socket connection management system according to claim 1, further comprising a DB that stores status information of a client that is generating a socket.   6. The socket connection management system according to claim 5, wherein the status information of the client includes an end status, a transmission status, and a normal status depending on whether or not a socket check message is transmitted / received. The API is
A client initialization API for generating a socket check execution module;
A client process API for processing socket check messages received from the server;
A client release API for unregistering all sockets registered in the socket check execution module and releasing the socket check execution module;
The socket connection management system according to claim 1, comprising at least one API. The common library module is
A program coded to perform a function defined in response to a call to a client initialization API to generate a socket check execution module;
A program coded to perform a function defined in response to a call to a client process API for processing a socket check message received from a server;
A program coded to perform a function defined in response to calling a client release API for releasing all sockets registered in the socket check execution module and releasing the socket check execution module;
The socket connection management system according to claim 1, wherein at least one of the socket connection management systems is provided. The socket check execution module is mounted on the client,
The socket connection management system according to claim 1, wherein a socket check response message is transmitted to the server in response to a socket check request message periodically transmitted from a server in which the corresponding client and the socket are set. Creating any socket by an application program module programmed to create and manage the sockets necessary for server or client communication; and
The application program module calling any API defined to check the connection status of the generated socket;
When an arbitrary API is called from the application program module, an operation set in the called API is executed in the common library module;
Using the socket check execution module generated by the common library module to periodically check the connection state of the generated socket;
A method for checking a socket connection state, comprising: The periodically checking step includes:
A socket check request message is periodically transmitted to the server and the client setting the socket, and the connection status of the registered socket is periodically determined depending on whether or not a socket check response message transmitted from the client is received. The method of checking a socket connection state according to claim 10, wherein the check is performed. The periodically checking step includes:
11. The socket connection status check method according to claim 10, wherein a socket check response message is transmitted to the server in response to a socket check request message periodically transmitted from the server. The common library module is mounted on a server,
The steps performed in the common library module include:
Generating a socket check execution module for checking the connection status of the generated socket;
Registering the corresponding socket in the generated socket check execution module so that a connection state to an arbitrary socket can be checked;
By using the generated socket check execution module, a socket check request message is periodically transmitted to a client setting a server and a socket, and a socket check response message transmitted from the corresponding client is received or not. , Periodically checking the connection status of registered sockets;
The method for checking a socket connection state according to claim 10, comprising: The common library module is mounted on a client,
The steps performed in the common library module include:
Generating a socket check execution module for checking the connection status of the generated socket;
Transmitting a socket check response message to the server in response to a socket check request message periodically transmitted from the server by the generated socket check execution module;
The method for checking a socket connection state according to claim 10, comprising: The common library module is mounted on a client,
The steps performed in the common library module include:
Generating a socket check execution module for checking the connection status of the generated socket;
Releasing the connected socket when the number of times that the socket check request message periodically transmitted from the server by the generated socket check execution module is not received within a predetermined period exceeds a certain number of times;
The method for checking a socket connection state according to claim 10, comprising: A method for checking a connection state of the set socket in a server for setting a socket with an arbitrary client,
Calling a library function that stores a program for checking the connection status of the socket when the client and socket are set;
Registering sockets to be checked periodically by execution of the called library function;
By executing the called library function, a socket check request message is periodically transmitted to the client, and a connection state of a registered socket is determined depending on whether a socket check response message transmitted from the client is received. Periodically checking
A method for checking a socket connection state, comprising: The periodically checking step includes:
Getting the current time information,
Transmitting the acquired time information attached to a request message for periodically checking the socket connection state to the client setting the socket;
Checking the connection status of the socket according to whether a response message transmitted from the client is received;
The socket connection state check method according to claim 16, further comprising: Checking the connection status of the socket includes
After transmitting a request message for checking a connection state of a socket to the client, determining whether or not there is no response message from the client until a timeout of a predetermined transmission period is exceeded;
If the result of the determination is that there is no response, counting the number of times that the timeout of the transmission cycle has been exceeded, and if the predetermined allowable number of times has been exceeded, releasing the socket connection;
The socket connection state checking method according to claim 17, further comprising: Checking the connection status of the socket includes
When a response message is received from the client, it is determined whether the time information included in the corresponding response message is a normal response message that matches the time information stored in the request message transmitted to the client. Stages,
If the time information does not match as a result of the determination, the number of times that an abnormal response message is received is counted, and if the predetermined allowable number is exceeded, the socket connection with the client is released. When,
The socket connection state checking method according to claim 17, further comprising: A method of checking the connection status of a socket in a client that has set up a socket with an arbitrary server,
Calling a library function that stores a program for checking the connection status of the socket when setting the server and socket;
Whether or not the socket check request message is periodically received by transmitting a socket check response message to the socket check request message periodically received from the server by executing the called library function. A step of checking a connection state between the server and a set socket;
A method for checking a socket connection state, comprising: Checking the connection status of the socket includes
Determining whether a socket check request message has been received from the server after transmitting the socket check response message to the server and before exceeding a predetermined transmission period timeout;
As a result of the determination, if the socket check request message is not received until the transmission cycle timeout is exceeded, the number of times that the transmission cycle timeout has been exceeded is counted, and a predetermined allowable number of times is exceeded. The stage of disconnecting the socket,
21. The method for checking a socket connection state according to claim 20, further comprising:

Images