JP2012216964A - Client device, communication system, existence confirmation method and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a technique for confirming existence satisfying contrary conditions of reduction of a processing load and reduction of an abnormal condition detection time.SOLUTION: In a client device that performs data communication with a server device through a tunnel constructed therebetween, if there is no data packet transmission, the client device transmits an existence confirmation request to the server device at first time intervals, and on receiving a response to the existence confirmation request, the client device transmits to the server device the reception of the response to the existence confirmation request. If there is data packet transmission, the client device transmits to the server device a data packet with the reception of the response to the existence confirmation request before a lapse of a second time after receiving the response to the existence confirmation request from the server device, and transmits to the server device a data packet with an existence confirmation request after the lapse of the second time. When a third time elapses without receiving from the server device the response to the existence confirmation request, the client device determines that the tunnel condition is deteriorated.

Description

  The present invention relates to a survival confirmation technique in a communication network.

  Firewall devices (including NAT devices) are generally installed between private networks such as corporate networks and home networks and external networks such as the Internet to ensure communication security. is there.

  In such a firewall device, a protocol for permitting communication is set according to a network management policy. For example, in many cases, HTTP / HTTPS communication related to a request from a client device in a private network is allowed. ing.

  Therefore, in order to perform communications such as IP phone calls and video conferencing between a client device in a private network and an external device, the target communication is performed using a protocol header that allows communication such as HTTP. A tunneling technique is used in which a tunnel, which is a virtual communication path, is formed by encapsulating these packets, and communication for a purpose such as an IP phone or video conference is performed through the tunnel.

  FIG. 1 is a diagram illustrating an example of communication across a firewall using the tunneling technique as described above. As shown in FIG. 1, in the tunneling technology, a tunnel is formed between a client device having a tunnel client function (PC in the example of FIG. 1) and a tunnel server device installed in an external network (Internet). Communicate.

JP 2010-109733 A

  When performing communication using tunneling, the firewall device or proxy server device that passes through the route may cause the device to be forcibly disconnected if there is no communication for a long time, or it may not be in a disconnected state. There may be a so-called tunnel clogged state where signals are not communicated. In order to avoid such a state, the client device periodically transmits a survival confirmation request to the tunnel server device, and the client device receives a survival confirmation request response from the server device, so that the client device determines the tunnel status. Conventionally, there is a communication confirmation technique for performing reconnection and the like.

  In the above technology, if the transmission interval of the survival confirmation request is short, the number of useless packets other than the original data packet increases, and processing is performed in the tunnel server device and its network where many clients including non-communication clients concentrate. There is a possibility that the load increases and the performance is reduced. Conversely, if the transmission interval is lengthened, the clogged state cannot be detected for a long time, causing a problem that communication is interrupted for a long time. That is, with the conventional technology for confirming communication, it has been difficult to simultaneously satisfy the conflicting conditions of reducing the processing load and shortening the abnormal state detection time.

  On the other hand, in communication channels that are guaranteed reliability realized by technologies such as TCP / IP, retransmission of packets occurs due to disturbances such as packet drops on the communication channel, resulting in delays that result in unstable communication. There is a case. In order to solve this problem, there is a conventional technique for stabilizing communication by bundling a plurality of tunnel connections to form one logical tunnel connection and distributing and transmitting packets therein.

  In the above technology, in order to realize more stable communication, for example, by applying the above-described communication confirmation technology to each of a plurality of tunnel connections, non-communication disconnection prevention and communication confirmation are performed, and When sending a packet via a tunnel connection, it is desirable to send the packet while avoiding a tunnel connection having a poor communication state.

  The present invention has been made in view of the above-described problems, satisfying the conflicting conditions of reducing the processing burden and shortening the abnormal state detection time, and in the communication system in which communication is performed by bundling a plurality of tunnel connections. An object of the present invention is to provide a survival confirmation technique that can quickly perform an operation to avoid a bad tunnel connection.

  Here, when using the conventional technology that stabilizes communication by bundling multiple tunnel connections and passing packets, the ordering is guaranteed on the receiving side due to disturbances on the way even if it is transmitted sequentially on the transmitting side. As a result, the order of the packets is reversed, and there is an influence that the application does not operate normally depending on the characteristics of the application, such as when real-time property such as telephone or video conference is required. Another object of the present invention is to provide a technique for preventing such order reversal.

In order to solve the above-described problem, the present invention is a client device that performs data communication via a tunnel established with a server device,
Client-side tunnel communication means for constructing the tunnel with the server device and transmitting and receiving packets via the tunnel;
A client side survival confirmation means for performing packet transmission and reception for survival confirmation through the tunnel,
The client side survival confirmation means is:
When there is no data packet transmission from the application unit included in the client device, a survival confirmation request is transmitted to the server device at a first time interval, and a survival confirmation request response is received from the server device that has received the survival confirmation request. If received, send a survival confirmation request response receipt to the server device,
When there is a data packet transmission from the application unit, a data packet with receipt of a survival confirmation request response within a second time after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device Is transmitted to the server device, and after the second time has elapsed after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device, a data packet with a survival confirmation request is transmitted to the server device. ,
A client device is characterized in that when the third time has elapsed without receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device, the state of the tunnel is determined to have deteriorated. be able to.

  The first time may be set to be longer than the third time, and the third time may be set to be longer than the second time.

Moreover, this invention is a communication system provided with the said client apparatus and the said server apparatus,
The server device
Server-side tunnel communication means for constructing the tunnel with the server device and transmitting and receiving packets via the tunnel;
Server side survival confirmation means for performing packet transmission and reception for survival confirmation through the tunnel,
The server side survival confirmation means
When there is no data packet transmission from the server device, when a survival confirmation request is received from the client device, a survival confirmation request response is transmitted to the client device, and when there is a data packet transmission from the server device. When a data packet with a survival confirmation request is received from the client device, a data packet with a survival confirmation request response is transmitted to the client device,
When a survival confirmation request response or a data packet with a survival confirmation request response is transmitted to the client device, and a survival confirmation request response is received or a data packet with a survival confirmation request response is not received from the client device within a fourth time period. The communication system may be configured to determine that the tunnel state has deteriorated.

In the above communication system,
The server side tunnel communication means includes:
Distributing transmission means for transmitting a packet with a transmission number indicating a transmission order sequentially to a plurality of tunnels established between the client side tunnel communication means,
The client side tunnel communication means includes:
The transmission number of the first packet that was retransmitted last time is compared with the transmission number of the second packet received from the server-side tunnel communication means, and the transmission number of the second packet is When the packet transmission number is equal to or less than +1, the second packet is retransmitted. When the transmission number of the second packet is equal to or greater than the transmission number of the first packet +2, the packet is stored in the queue. If the packet does not already exist, the second packet may be stored in a queue, and a retransmission order control unit may be provided to retransmit the second packet after a predetermined time has elapsed.

  The server-side tunnel communication means may be configured not to use a tunnel that has been determined to have deteriorated by the server-side survival confirmation means.

In the communication system,
The client side tunnel communication means includes:
Distributing transmission means for sequentially transmitting a packet with a transmission number indicating a transmission order for a plurality of tunnels established between the server side tunnel communication means,
The server side tunnel communication means includes:
The transmission number of the first packet that was retransmitted last time is compared with the transmission number of the second packet received from the client side tunnel communication means, and the transmission number of the second packet is When the packet transmission number is equal to or less than +1, the second packet is retransmitted. When the transmission number of the second packet is equal to or greater than the transmission number of the first packet +2, the packet is stored in the queue. If the packet does not already exist, the second packet may be stored in a queue, and a retransmission order control unit may be provided to retransmit the second packet after a predetermined time has elapsed.

  The client-side tunnel communication means may be configured not to use a tunnel that has been determined to have deteriorated by the client-side existence confirmation means.

  According to the present invention, the conflicting conditions of reducing the processing load and shortening the abnormal state detection time are satisfied, and the operation for avoiding the tunnel connection having a poor communication state is quickly performed in the communication method in which a plurality of tunnel connections are bundled for communication. It is possible to provide a survival confirmation technique that can be performed.

It is a figure which shows the example of communication over a firewall using a tunneling technique. 1 is an overall configuration diagram of a system in an embodiment of the present invention. 3 is a functional configuration diagram of a survival confirmation function unit 12 of the client device 1. FIG. 3 is a functional configuration diagram of a survival confirmation function unit 22 of the server device 2. FIG. It is a figure which shows the operation | movement image of a system. It is a figure which shows the example of a message format. This is a flow of liveness confirmation processing in the client device (when a tunnel is connected and when a liveness confirmation request response is received). It is a survival confirmation processing flow in the client device (when packet data is transmitted, during timer 4C timeout processing). It is a survival confirmation processing flow in the client device (timer 3C timeout processing). It is a survival confirmation processing flow in the client device (timer 2C timeout processing). It is a survival confirmation process flow in the client device (timer 1C timeout process). This is a survival confirmation processing flow in the server device (at the time of tunnel connection, receipt of receipt of a survival confirmation request response). It is a survival confirmation processing flow in the server device (when a data packet with a survival confirmation request is received). This is a survival confirmation processing flow in the server device (when the survival confirmation request (single) is received, when the timer 5S times out, when packet data is transmitted). It is a survival confirmation processing flow in the server device (timer 2S timeout). It is a state transition diagram of the survival confirmation request process in the client device. It is a state transition diagram of the survival confirmation request process in a server apparatus. It is a state transition diagram showing the state transition of the whole system. It is a figure which shows an example of the survival confirmation operation | movement sequence between a server apparatus and a client apparatus. It is a figure which shows an example of the survival confirmation operation | movement sequence between a server apparatus and a client apparatus. It is a figure which shows the structure of the tunnel function part in a packet transmission side and a packet reception side. It is a transmission process flow (initialization process) of multiple tunnel connection communication (for one direction). It is a transmission processing flow (distributed transmission processing) of multiple tunnel connection communication (for one direction). It is a transmission processing flow (processing at the time of tunnel state improvement, processing at the time of tunnel connection) of multiple tunnel connection communication (for one direction). It is a transmission processing flow (processing at the time of tunnel state response deterioration, processing at the time of tunnel disconnection) of multiple tunnel connection communication (for one direction). It is a reception process flow (initialization process) of multiple tunnel connection communication (for one direction). It is a reception processing flow (aggregate reception processing) of multiple tunnel connection communication (for one direction). It is a reception processing flow (timer timeout processing) of multiple tunnel connection communication (for one direction). It is a figure which shows the example of a communication process (when jitter is small) from a server apparatus (transmission side) to a client apparatus (reception side). It is a figure which shows the example of a communication process (when jitter is large) from a server apparatus (transmission side) to a client apparatus (reception side). It is a figure which shows the example of a communication process in a prior art from a server apparatus (transmission side) to a client apparatus (reception side).

  Embodiments of the present invention will be described below with reference to the drawings.

<First Embodiment>
(System configuration)
FIG. 2 shows the overall configuration of the system in the first embodiment. As shown in FIG. 2, the system of the present embodiment has a firewall device 4 installed at the boundary between the Internet 5 and a private network 6 such as a corporate network, and a tunnel client function under the firewall device 4. A client device 1, a server device 2 having a tunnel server function, and a communication partner device 3 that communicates with the client device 1 are included. In the present embodiment, the server device 2 and the communication partner device 3 are connected to the Internet 5.

  As shown in FIG. 2, the client device 1 includes a tunnel function unit 11 that performs processing related to client-side tunnel connection, a life confirmation function unit 12 that performs client-side life confirmation processing according to the present invention, an IP phone, An application unit 13 that performs communication for a purpose such as a video conference is provided. The server device 2 includes a tunnel function unit 21 that performs processing related to the server-side tunnel connection and a survival confirmation function unit 22 that performs server-side survival confirmation processing according to the present invention.

  The client device 1 in the present embodiment is a computer (PC, portable terminal, etc.) provided with an OS (operating system) and a program corresponding to the above functional unit. The server device 2 in the present embodiment is a computer that includes an OS, a program corresponding to the functional unit, and the like.

  FIG. 3 shows a functional configuration of the survival confirmation function unit 12 of the client device 1. As shown in FIG. 3, the survival confirmation function unit 12 includes a survival confirmation packet transmission / reception control unit 121, an information storage unit 122, a timer 1C, a timer 2C, a timer 3C, and a timer 4C.

  The existence confirmation packet transmission / reception control unit 121 is a functional unit that controls transmission / reception of packets for existence confirmation, and performs processing operations as described later with reference to a timer. The information storage unit 122 stores a state (good, response deterioration) and a survival confirmation request response received / transmitted flag.

  The timer 1C is a reconnection activation timer, and measures the time from when the client device 1 transmits the last packet until the reconnection is performed. In the present embodiment, a value of about 5 seconds is assumed as the time measured by the timer 1C.

  The timer 2C is a state deterioration determination timer, and measures a reference time from when the client device 1 transmits the final packet until the response is returned. In the present embodiment, a value of about 3 seconds is assumed as the time measured by the timer 2C.

  Timer 3C is a survival confirmation request transmission / response reception timer that measures the minimum time interval for sending a "survival confirmation request" when sending continuous packets, and at the same time measures the deadline until the "survival confirmation request response is received" To do. In the present embodiment, a value of about 0.5 seconds is assumed as the time measured by the timer 3C.

  The timer 4C is a survival confirmation request longest transmission timer, and measures a time limit for transmitting a single “survival confirmation request” when a packet is not transmitted for a long time. In the present embodiment, a value of about 10 seconds is assumed as the time measured by the timer 4C.

  FIG. 4 shows a functional configuration of the survival confirmation function unit 22 of the server device 2. As shown in FIG. 4, the survival confirmation function unit 22 includes a survival confirmation packet transmission / reception control unit 221, an information storage unit 222, a timer 2S, and a timer 5S.

  The existence confirmation packet transmission / reception control unit 221 is a functional unit that controls transmission / reception of packets for existence confirmation, and performs processing operations described later with reference to a timer. The information storage unit 222 stores the state (good, response deterioration).

  The timer 2S is a state deterioration determination timer, and measures a time limit from when the server apparatus 2 transmits a “survival confirmation request response” to when a “survival confirmation request response received” is received from the client apparatus 1. In the present embodiment, a value of about 3 seconds is assumed as the time measured by the timer 2S.

  The timer 5S is a “survival confirmation request response” timer, and measures a time limit from when the server apparatus 2 receives a “survival confirmation request” (excluding a single one) until it transmits a “survival confirmation request response”. In the present embodiment, a value of about 1 second is assumed as the time measured by the timer 5S.

  The “survival confirmation request” and “acknowledgment confirmation request response received” are signals transmitted from the client device 1 to the server device 2, and the “survival confirmation request response” is transmitted from the server device 2 to the client device 1. Signal.

  Each of the client device 1 and the server device 2 according to the present embodiment can be realized by causing a computer having a CPU, a storage device, and the like to execute programs for realizing the above functions. The program may be installed in a computer from a recording medium such as a portable memory, or may be downloaded from a server on the network.

  Although there are various methods for realizing tunnel connection, the method for realizing tunnel connection in the present invention is not limited to a specific method, and the present invention can be applied to various tunnel connection methods. is there.

(System operation)
Below, the operation | movement of the system in 1st Embodiment is demonstrated. The following operations are basically executed by the survival confirmation function unit 12 of the client device 1 and the survival confirmation function unit 22 of the server device 2.

  FIG. 5 is a diagram showing an operation image of the system. As shown in FIG. 5, there is a single survival confirmation message (packet) or a survival confirmation message attached to a data packet that is original communication data (data transmitted / received by an application program). Data is transmitted and received between the client device 1 and the server device 2.

  FIGS. 6A to 6E are diagrams showing examples of message formats used in the present embodiment. The format shown here is only an example, and values indicating various other formats, sizes, and message types can be used.

  In this embodiment, the header has a size of 1 byte. As shown in FIG. 6A, when “23h” flows through the upstream tunnel, it is regarded as a single survival confirmation request, and when it flows through the downstream tunnel, it is regarded as a single survival confirmation request response. As shown in FIG. 6B, the header “24h” is regarded as a single existence confirmation request response reception.

  As shown in FIGS. 6C to 6E, the header representing the data packet is “30h”, and the header when the survival confirmation request or the survival confirmation request response is superimposed on this is “31h”. Become. In addition, the header when the existence confirmation request response reception is superimposed is “32h”.

  In this way, by using some bits of the header, it is possible to confirm the existence without overhead.

Next, operations of the client device 1 and the server device 2 will be described with reference to the flowcharts of FIGS.
FIG. 7 is a flowchart showing processing at the time of tunnel connection in the client device 1 and processing at the time of receiving a survival confirmation request response. As shown in FIG. 7, in the client device 1, immediately after the start of the tunnel connection, the state is set to “good” (step 1), and the survival confirmation request response received / transmitted flag is set to “not transmitted” (step 2). ). Subsequently, timer 3C (survival confirmation request transmission / response reception timer) and timer 4C (survival confirmation request longest transmission timer) are started, and timer 1C (reconnection activation timer) and timer 2C (state deterioration determination timer) are stopped. . Thereafter, the survival confirmation function unit 12 in the client device 1 operates in response to a packet arrival or timer operation (timeout) event.

  FIG. 8 is a flowchart showing processing at the time of data packet transmission and processing at the time of timeout of the timer 4C (survival confirmation request longest transmission timer).

  As shown in FIG. 8, when the client device 1 transmits a data packet, it is first determined whether or not the timer 3C (life check request transmission / response reception timer) has timed out (step 11). If the timer 3C has timed out (Yes in step 11), it is determined that a survival confirmation request should be sent, and the survival confirmation request is superimposed on the data packet and transmitted (step 12), and the timer 3C is stopped (step 13).

  On the other hand, if the determination in step 11 is No, that is, if the timer 3C (survival confirmation request transmission / response reception timer) has not timed out, it is determined that a survival confirmation request response receipt should be transmitted as necessary. The response received / transmitted flag is verified (step 14), and only when the response has not been transmitted (No in step 14), the survival confirmation request response reception is superimposed on the data packet and transmitted (step 15). Set the received / sent flag to “sent”. If the determination in step 14 is Yes, that is, the receipt of the survival confirmation request response has been transmitted, nothing is superimposed and transmitted as a single data packet (step 17).

  After steps 13, 16, and 17, timer 4C is stopped and timers 1C and 2C are started (step 19).

  Processing of the client device 1 when a survival confirmation request response is received from the server device 2 will be described with reference to FIG. As shown in FIG. 7, when a survival confirmation request response is received from the server device 2, it is checked whether or not the timer 2C (state deterioration determination timer) has timed out (step 4), and the timer 2C has not timed out Only (No in Step 4), the state is set to “good” (Step 1), and then the state in the client device 1 is initialized in the same manner as immediately after the tunnel connection (Steps 2 and 3). If the timer 2C has timed out (Yes in step 4), the state is set to “deteriorated”, and the flag and the like in the client device 1 are initialized in the same manner as immediately after the tunnel connection (step 4). 2, 3).

  Processing when the timer 4C (survival confirmation request longest transmission timer) times out will be described with reference to FIG. When the timer 4C times out, this means that the data packet has not been transmitted for a while, so a survival confirmation request is transmitted as a single packet (step 18). Thereafter, the timer 4C is stopped, and the timer 1C (reconnection activation timer) and the timer 2C (state deterioration determination timer) are started (step 19).

  FIG. 9 is a flowchart showing processing in the client apparatus 1 when the timer 3C (survival confirmation request transmission / response reception timer) times out. When timer 3C (survival confirmation request transmission / response reception timer) has timed out, it is the transmission timing of survival confirmation request response reception, so check the survival confirmation request response received transmission flag to check whether transmission has been completed ( If not transmitted (No in Step 21), the existence confirmation request response reception is transmitted as a single packet (Step 22), and the existence confirmation request response received transmission flag is set to “transmitted” (Step 21). 23).

  FIG. 10 is a flowchart showing processing in the client device 1 when the timer 2C (state deterioration determination timer) times out. As shown in FIG. 10, when the timer 2C (state deterioration determination timer) times out, it is determined that the state has deteriorated, and the state is set to “response deterioration” (step 31).

  FIG. 11 is a flowchart showing processing in the client apparatus 1 when the timer 1C (reconnection activation timer) times out. As shown in FIG. 11, when the timer 1C (reconnection trigger timer) times out, a new one tunnel connection is made (step 51), the tunnel connection process is performed (step 52), and the old tunnel connection is disconnected. (Step 53), control is passed to the new tunnel connection.

  FIG. 12 is a flowchart showing processing of the server device 2 at the time of tunnel connection or the like. As shown in FIG. 12, the server apparatus 2 sets the state to “good” at the time of tunnel connection (step 61), and thereafter operates on an event basis as described below.

FIG. 13 is a flowchart showing processing of the server device 2 when a data packet with a survival confirmation request is received from the client device 1. As shown in FIG. 13, when a data packet with a survival confirmation request is received from the client device 1, a timer 5S (a survival confirmation request response timer) is started (step 71).
FIG. 14 is a flowchart showing processing of the server device 2 when a survival confirmation request is received from the client device 1 as a single packet. As shown in FIG. 14, when the survival confirmation request is received alone, the server apparatus 2 transmits the survival confirmation request response alone to the client apparatus 1 (step 81) and sets the timer 2S (state deterioration determination timer) ( The timer 5S is stopped (step 84).

  As shown in FIG. 14, when a data packet is transmitted to the client device 1, it is determined whether or not the timer 5S (survival confirmation request response transmission timer) is in operation (step 82). If Yes, a data packet with a survival confirmation request response is transmitted to the client device 1 (step 83), the timer 2S (state deterioration determination timer) is (re) started, and the timer 5S is stopped (step 84). . When the timer 5S (survival confirmation request response transmission timer) is not in operation (No in step 82), normal data packet transmission is performed (step 85).

  As shown in FIG. 12, when the receipt of the survival confirmation request response is received from the client device 1, the state is set to “good” only when the timer 2S (state deterioration determination timer) has not timed out (No in step 62). Set (step 61).

  As shown in FIG. 14, when the timer 5S (survival confirmation request response transmission timer) times out, a single survival confirmation request response is transmitted to the client device 1 (step 81), and step 84 is performed.

  Further, as shown in FIG. 15, when the timer 2S (state deterioration determination timer) times out, the state is set to “response deterioration” (step 91).

  Next, the state transition corresponding to the processing procedure in each apparatus described above will be described.

  FIG. 16 is a state transition diagram of the survival confirmation request process in the client device 1. As shown in FIG. 16, when the timer 2C (state deterioration determination timer) elapses from the “good” state, the response becomes worse (step 101). The timer 2C starts when a packet is transmitted before the timer 1C (reconnection activation timer) elapses, and becomes “good” when the packet arrives before the timer 2C elapses (step 102).

  When the timer 1C (reconnection activation timer) elapses from the “response deterioration” state, “connection failure” (* 1) and “disconnection” (* 2) are obtained (steps 103 and 104). Then, after initial connection or reconnection, the state becomes “good” (step 105). However, in the embodiment of the present invention, when it is determined that the connection is poor (when the timer 1C has elapsed), the “connection failure” state does not exist effectively because the connection is immediately cut off. In addition, since it is not necessary to handle the “disconnected” state in the configuration of the present embodiment, the “disconnected” state is not shown in the flowchart.

  FIG. 17 is a state transition diagram of the survival confirmation request process in the server device 2. As shown in FIG. 17, “response deterioration” is caused when timer 2 S (state deterioration determination timer) elapses from the “good” state (step 201). After the timer 2S restarts, the packet becomes “good” due to the arrival of the packet before the timer 2S elapses (step 202). Also, when disconnected from the “good” or “response deteriorating” state, it becomes “disconnected” and then connected (steps 203, 204, 205). As described above, the “disconnected” state is not shown in the flowchart because it is not necessary to handle the “disconnected” state in the configuration of the present embodiment.

  FIG. 18 is a state transition diagram showing state transition of the entire system, assuming that the client device 1 and the server device 2 are one set of systems. In FIG. 18, generally, a control signal received alone or in a superimposed manner is represented as “state”, and timer timeout and packet transmission are represented in the form of state transition conditions.

  FIG. 19 shows an example of a survival confirmation operation sequence between the server apparatus 2 and the client apparatus 1 that perform the processing operation according to the flowchart and the state transition. The example shown in FIG. 19 shows an operation when there is no data packet communication.

  In the case of FIG. 19, since the data packet is not transmitted in the client device 1, the timer 4C (the survival confirmation request longest transmission timer) started in step 3 of FIG. 7 is not stopped by the transmission of the data packet. Then, a time-out occurs, and a single survival confirmation request is transmitted as shown in step 18 of FIG. 8 (step 501 of FIG. 19). The server apparatus 2 that has received the existence confirmation request transmits a single existence confirmation request response to the client apparatus 1 (step 502 in FIG. 19) as shown in steps 81 and 84 in FIG. ) (Re) start.

  The client device 1 that has received the survival confirmation request response performs the process when receiving the survival confirmation request response shown in FIG. 7, and starts the timers 3C and 4C. In the example of FIG. 19, since the survival confirmation request response attached to the data packet is not received, the timer 3C times out, and as shown in FIG. 8, the client apparatus 1 receives a single survival confirmation request response reception as a server. It transmits to the apparatus 2 (step 503 in FIG. 19). In the server apparatus 1 that has received the receipt of the survival confirmation request response, as shown in FIG. 12, the timer 2S is timed out. In this example, the timer 2S has not timed out and the state is determined to be “good”. To do.

  Thereafter, the timer 4C (survival confirmation request longest transmission timer) times out in the client device 1, a survival confirmation request is transmitted (step 504), and a survival confirmation request response is transmitted from the server device 2 (step 505).

  When there is no data packet transmission / reception in this way, the survival check is repeated at the longest interval determined by the timer 4C.

  Another example of the survival confirmation operation sequence is shown in FIG. The example shown in FIG. 20 shows an operation when there is data packet transmission / reception.

  In this example, when there is no data packet, transmission / reception of a survival confirmation request, a survival confirmation request response, and a survival confirmation request response reception is performed in the same manner as the above-described processing (steps 601 to 603).

  When there is a data packet to be transmitted in the client apparatus 1, the timer 3C (survival confirmation request transmission / response reception timer) is checked as shown in FIG. 8, and since a time-out has occurred here, a data packet with a survival confirmation request is transmitted. (Step 604).

  On the other hand, data packets are sequentially transmitted from the server device 2, but in the example of FIG. 20, the data packet shown in step 605 is a normal data packet because the timer 5S (survival confirmation request response timer) is not operating. It is transmitted (step 85 in FIG. 14).

  In the server device 2 that has received the data packet with the survival confirmation request in step 604, the timer 5S (survival confirmation request response timer) starts as shown in step 71 of FIG. 13, and as shown in step 83 of FIG. With the transmission as a trigger, a data packet with a survival confirmation request response is transmitted (step 606 in FIG. 20), the timer 5S is stopped, and the timer 2S (state deterioration determination timer) is restarted.

  Although data packets are also transmitted sequentially from the client device 1, in the example of FIG. 20, for the data packets shown in steps 607 and 612, the timer 3C is stopped (not timed out), and the survival confirmation request response Since the receipt has been transmitted, it is transmitted as a data packet without a survival confirmation request (step 17 in FIG. 8).

  Receiving the data packet with the survival confirmation request response in step 606, the client device 1 starts the timers 3C and 4C as shown in FIG. Step 608 in FIG. 20 and Step 15 in FIG. 8).

  The data packets shown in steps 609 and 610 are transmitted from the server apparatus 2 to the client apparatus 1 as they are because the timer 5S is not operating.

  After transmitting the data packet with receipt of the survival confirmation request response in step 608, the client apparatus 1 transmits the data packet with survival confirmation request when transmitting the data packet (step 611 in FIG. 20 and step 12 in FIG. 8).

  In the server device 2 that has received the data packet with the survival confirmation request in step 611, the timer 5S (survival confirmation request response timer) starts. Here, the timer 5S times out and a single survival confirmation request response is transmitted ( Step 613). In response to this, the client apparatus 1 transmits a single survival confirmation request response receipt triggered by the timeout of the timer 3C (step 614).

  When data packets are transmitted and received in this manner, the survival confirmation is repeated at a short time interval determined by the timer 2S (state deterioration determination timer) and the uplink packet transmission interval from the client device 1. As a result, state monitoring becomes frequent, so that deterioration of the state can be detected in a shorter time.

  In the present embodiment, the number of tunnels between the client device 1 and the server device 2 is not particularly limited, but the description so far assumes a case where there is one tunnel.

  When using a plurality of tunnels as in a second embodiment to be described later, the survival confirmation process described in this embodiment is performed for each tunnel.

  The configuration according to the present embodiment can also be expressed as follows.

  The client device 1 that performs data communication with the server device 2 through a tunnel established with the server device 2 constructs the tunnel with the server device 2 and transmits and receives packets through the tunnel. A tunnel communication unit 11 and a client-side existence confirmation unit 12 that transmits and receives packets for existence confirmation through the tunnel. The client-side existence confirmation unit 12 includes an application unit 13 included in the client device 1. When there is no data packet transmission, a survival confirmation request is transmitted to the server apparatus 2 at a first time (timer 4C) interval, and a survival confirmation request response is received from the server apparatus 2 that has received the survival confirmation request. In this case, a survival confirmation request response receipt is transmitted to the server device 2 and the application unit 13 In the case where there is a data packet transmission, data with a survival confirmation request response received within a second time (timer 3C) after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device 2 After the second time elapses after the packet is transmitted to the server device 2 and a survival confirmation request response or a data packet with a survival confirmation request response is received from the server device, the data packet with a survival confirmation request is sent to the server device 2. When the third time (timer 2C) elapses without receiving the survival confirmation request response or the data packet with the survival confirmation request response from the server device, it is determined that the state of the tunnel has deteriorated. .

  Further, the server device 2 establishes the tunnel with the server device 2, and transmits and receives a packet through the tunnel by means of server-side tunnel communication means 21 for confirming the existence through the tunnel. The server-side survival confirmation unit 22 receives a survival confirmation request from the client device 1 when there is no data packet transmission from the server device 2. In this case, when a survival confirmation request response is transmitted to the client device 1 and a data packet is transmitted from the server device 2, a survival confirmation request is received when a data packet with a survival confirmation request is received from the client device 1. A data packet with a response is transmitted to the client device 1, and the existence confirmation request response or the previous When a data packet with a survival confirmation request response is transmitted to the client device 1 and a survival confirmation request response or a data packet with a survival confirmation request response is not received from the client device 1 within the fourth time (timer 2S). Then, it is determined that the state of the tunnel has deteriorated.

<Second Embodiment>
Next, a second embodiment of the present invention will be described. The system configuration in this embodiment is the same as that of the first embodiment described with reference to FIGS. However, in the present embodiment, each of the tunnel function unit 11 of the client device 1 and the tunnel function unit 21 of the server device 2 has a function of bundling a plurality of tunnel connections and performing packet transmission / reception. In addition, the survival confirmation function units 12 and 22 include a function corresponding to a configuration using a plurality of tunnel connections.

  FIG. 21 is a diagram illustrating the configuration of the tunnel function units 11 and 21 on the packet transmission side and the packet reception side. FIG. 21 shows a one-way communication configuration for easy understanding of the function of the present embodiment. In practice, each of the client device 1 and the server device 2 transmits the packet shown in FIG. Side functions and packet receiving side functions. That is, FIG. 21 illustrates an upstream communication configuration from the client device 1 to the server device 2 or a downstream communication configuration from the server device 2 to the client device 1.

  As illustrated in FIG. 21, the tunnel function unit on the packet transmission side includes a distribution unit 101, a counter 102, and a tunnel connection list storage unit 103. The tunnel function unit on the packet receiving side includes an aggregate receiving unit 201, a final transmission number storage unit 202, and a timer 203. Of course, each tunnel function unit includes a function of performing a plurality of tunnel connections.

  On the packet transmission side, a tunnel connection list which is a list of tunnels being connected is stored in the tunnel connection list storage unit 103. In the example of FIG. 21, tunnel connections 0 to N are shown. Using the tunnel connection list and the counter, the distribution unit 101 sequentially assigns numbers to the transmission target packets and sequentially transmits the packets to a plurality of tunnels. The tunnel used for transmission is configured to be transmitted in order as a plurality of lists. Also, if the status of each tunnel deteriorates, it is removed from the list, and when it returns well, it is added to the list again.

  On the packet receiving side, the last retransmitted packet number is stored in the final transmission number storage unit 202. The aggregate receiving unit 201 includes a queue (buffer memory) for storing packets, and performs the following processing. The aggregate receiving unit 201 that performs the following control is an example of a retransmission order control unit.

  Aggregation reception unit 201 compares the last transmission packet number with the packet number of the received packet, and immediately transmits if the packet number of the received packet is equal to or less than final transmission packet number + 1, and if it is +2 or more, aggregate reception The queue in the unit 201 is checked, and if there is already a waiting packet, the received packet is retransmitted following the packet in the queue. If there is no packet in the queue, the received packet is stored in the queue and the timer 203 is started. If there is no next packet until the timer 203 times out, the packet stored in the queue is transmitted.

  Hereinafter, the above process will be described in more detail with reference to flowcharts.

  FIG. 22 is a flowchart showing an initialization process in the packet transmission side tunnel function unit. As shown in FIG. 22, the counter value is set to 0 (step 111), the tunnel connection list is emptied (step 112), and N tunnel connections are opened (step 113).

  FIG. 23 is a flowchart showing a distribution transmission process performed by the distribution unit 101 in the packet transmission side tunnel function unit. As shown in FIG. 23, a counter value is added to the packet (step 121), and the packet is transmitted to the tunnel at the head of the tunnel connection list (step 122). Then, 1 is added to the counter value (step 123), and the top element of the tunnel connection list is moved to the end of the list (step 124).

  FIG. 24 is a flowchart showing processing when the tunnel state is “good” or when the tunnel is connected in the packet transmission side tunnel function unit. Here, when the tunnel state is “good”, the existence confirmation unit (12, 22) detects when the tunnel connection is changed from “response deteriorated” to “good”. It is.

  Here, the connected (or improved) tunnel is added to the end of the tunnel connection (step 131).

  FIG. 25 is a flowchart showing processing at the time of tunnel state “response deterioration” or tunnel disconnection in the packet transmission side tunnel function unit. Here, the tunnel state “response deterioration” is when the survival confirmation unit (12, 22) detects that the tunnel connection is changed from “good” to “response deterioration”. It is.

  Here, the corresponding tunnel is deleted from the tunnel connection list (step 141).

  FIG. 26 is a flowchart showing the initialization process in the packet receiving side tunnel function unit. At the time of initialization, the final transmission number is set to -1 (step 151).

  FIG. 27 is a flowchart showing the aggregate reception process executed by the aggregate receiver 201 in the packet reception side tunnel function unit.

  When a packet is received, it is checked whether the packet number of the received packet is equal to or less than the final transmission number + 1 (step 161). If it is equal to or less than the final transmission number + 1 (Yes in step 161), the received packet is retransmitted, and the final transmission number is set as the number of the packet (step 162).

  In step 161, if the packet number of the received packet is not less than or equal to the final transmission number +1 (+2 or more), it is checked whether there is a packet already waiting in the queue (step 163). If there is a waiting packet (Yes in step 163), all the packets in the queue are transmitted, the timer is stopped, and the final transmission number is updated (step 164). Thereafter, the received packet is retransmitted, and the final transmission number is set as the number of the packet (step 162). If there is no waiting packet in step 163, the packet is put into the queue (step 165), and the timer is started (step 166).

  FIG. 28 is a flowchart showing a timer timeout process in the packet receiving side tunnel function unit. As shown in FIG. 28, when the timer times out, all the packets in the queue are transmitted in the order in which the packets are received, the timer is stopped, and the final transmission number is updated (step 171).

  In the present embodiment, it is a condition that the tunnel connection used for transmission is in the connection state and the tunnel state is “good”. In other words, the tunnel connection determined to have deteriorated is not used. Thereby, it is possible to avoid a tunnel connection whose response has been temporarily deteriorated due to packet retransmission or the like and maintain a good response.

  An example of communication processing from the server apparatus 2 (transmission side) having the tunnel function unit operating as described above to the client apparatus 1 (reception side) will be described with reference to FIGS.

  FIG. 29 shows a processing example when the jitter in the transmission path from the server apparatus 2 to the client apparatus 1 is small. As shown in FIG. 29, packets # 0 to # 15 are sequentially transmitted from the server apparatus 2 via each tunnel connection. In this example, the packet # 4 arrives at the client device 1 slightly later than the packet # 5. In this case, as shown in FIG. 27 showing the processing on the receiving side, the client device 1 stores packet # 5 received next to packet # 3 in the queue, and receives packet # 4 before timer timeout. Packet # 4 is transmitted to the application program (application unit 13), and then packet # 5 in the queue is transmitted to the application program. The same applies to packets # 8 and # 9.

  In this way, when jitter is small, packets that arrive after the order has been changed can be rearranged in order and transmitted.

  FIG. 30 shows a processing example when the jitter in the transmission path from the server apparatus 2 to the client apparatus 1 is large.

  In this example, packet # 6 arrives at the client apparatus 1 with a large delay. In this case, in the client device 1, the packet # 7 received next to the packet # 5 is stored in the queue. However, before the subsequent packet is received, the timer times out and the packet # 7 in the queue is transmitted. The Therefore, packet # 7 is slightly delayed.

  Packet # 6 is received next to packet # 9, and packet # 11 is received next. In this case, the determination in step 161 of FIG. 27 for packet # 6 received next to packet # 9 is Yes, so that packet # 6 is immediately transmitted to the application program. Packet # 11 received next is stored in the queue (No in step 161, steps 163 and 165). By receiving packet # 10 before the timer timeout, packet # 10 is transmitted to the application program, and then packet # 11 in the queue is transmitted to the application program.

  When the jitter is large, it is impossible to prevent the change of the order of the packet subjected to a large delay, but other packets are processed without a large delay.

  Here, FIG. 31 shows an example of reception processing (in the case of small jitter) in the multiple tunneling communication according to the conventional technique. As shown in FIG. 31, even if the jitter is small, the order inversion occurs in the conventional technique, but the technique according to the present embodiment can prevent the order inversion. Thereby, even in an application where the order of packets is a problem such as a real-time communication system, it is possible to suppress a deterioration in quality by preventing the order reversal.

<Effect of Embodiment>
According to the techniques described in the first and second embodiments, when a data packet is transmitted / received, a configuration for transmitting and receiving a survival confirmation signal superimposed on the data packet is adopted. It is possible to perform a survival check that satisfies the conflicting condition of shortening the abnormal state detection time, and also to perform the state determination in a shorter time by determining the stability of the communication state on the server device side, and the client device Similarly to the state determination in the up direction from 1 to the server device 2, the state determination in the down direction from the server device 2 to the client device 1 can be performed. For this reason, it is possible to quickly detect an abnormal situation such as the disconnection of the tunnel and distribute it to another normal tunnel connection, thereby shortening the influence time on the communication via the tunnel.

  In addition, by correcting packet order change within a certain period of time, it is possible to transmit with little delay time while maintaining almost all packet orders, so communication protocol that affects packet quality in real-time communication such as VoIP and video communication. Can be used stably.

  The present invention is not limited to the above-described embodiments, and various modifications and applications are possible within the scope of the claims.

DESCRIPTION OF SYMBOLS 1 Client apparatus 11 Tunnel function part 12 Survival confirmation function part 13 Application part 2 Server apparatus 21 Tunnel function part 22 Survival confirmation function part 3 Communication partner apparatus 4 Firewall apparatus 5 Internet 6 Private network 121 Survival confirmation packet transmission / reception control part 1C, 2C 3C, 4C timer 122 Information storage unit 221 Survival confirmation packet transmission / reception control unit 2S, 5S timer 222 Information storage unit 101 Distribution unit 102 Counter 103 Tunnel connection list storage unit 201 Aggregate reception unit 202 Final transmission number storage unit 203 Timer

Claims (9)

A client device that performs data communication via a tunnel established with a server device,
Client-side tunnel communication means for constructing the tunnel with the server device and transmitting and receiving packets via the tunnel;
A client side survival confirmation means for performing packet transmission and reception for survival confirmation through the tunnel,
The client side survival confirmation means is:
When there is no data packet transmission from the application unit included in the client device, a survival confirmation request is transmitted to the server device at a first time interval, and a survival confirmation request response is received from the server device that has received the survival confirmation request. If received, send a survival confirmation request response receipt to the server device,
When there is a data packet transmission from the application unit, a data packet with receipt of a survival confirmation request response within a second time after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device Is transmitted to the server device, and after the second time has elapsed after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device, a data packet with a survival confirmation request is transmitted to the server device. ,
A client device, wherein when the third time has elapsed without receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device, the client device determines that the state of the tunnel has deteriorated.   The client device according to claim 1, wherein the first time is longer than the third time, and the third time is longer than the second time. A communication system comprising the client device according to claim 1 or 2, and the server device,
The server device
Server-side tunnel communication means for constructing the tunnel with the server device and transmitting and receiving packets via the tunnel;
Server side survival confirmation means for performing packet transmission and reception for survival confirmation through the tunnel,
The server side survival confirmation means
When there is no data packet transmission from the server device, when a survival confirmation request is received from the client device, a survival confirmation request response is transmitted to the client device, and when there is a data packet transmission from the server device. When a data packet with a survival confirmation request is received from the client device, a data packet with a survival confirmation request response is transmitted to the client device,
When a survival confirmation request response or a data packet with a survival confirmation request response is transmitted to the client device, and a survival confirmation request response is received or a data packet with a survival confirmation request response is not received from the client device within a fourth time period. And determining that the state of the tunnel has deteriorated. The communication system according to claim 3,
The server side tunnel communication means includes:
Distributing transmission means for transmitting a packet with a transmission number indicating a transmission order sequentially to a plurality of tunnels established between the client side tunnel communication means,
The client side tunnel communication means includes:
The transmission number of the first packet that was retransmitted last time is compared with the transmission number of the second packet received from the server-side tunnel communication means, and the transmission number of the second packet is When the packet transmission number is equal to or less than +1, the second packet is retransmitted. When the transmission number of the second packet is equal to or greater than the transmission number of the first packet +2, the packet is stored in the queue. A communication system comprising: a retransmission order control unit that stores the second packet in a queue when the packet does not already exist and retransmits the second packet after a predetermined time has elapsed. The communication system according to claim 4,
The server-side tunnel communication means does not use a tunnel determined to have deteriorated by the server-side survival confirmation means. The communication system according to any one of claims 3 to 5,
The client side tunnel communication means includes:
Distributing transmission means for sequentially transmitting a packet with a transmission number indicating a transmission order for a plurality of tunnels established between the server side tunnel communication means,
The server side tunnel communication means includes:
The transmission number of the first packet that was retransmitted last time is compared with the transmission number of the second packet received from the client side tunnel communication means, and the transmission number of the second packet is When the packet transmission number is equal to or less than +1, the second packet is retransmitted. When the transmission number of the second packet is equal to or greater than the transmission number of the first packet +2, the packet is stored in the queue. A communication system comprising: a retransmission order control unit that stores the second packet in a queue when the packet does not already exist and retransmits the second packet after a predetermined time has elapsed. The communication system according to claim 6,
The client-side tunnel communication means does not use a tunnel determined to have deteriorated by the client-side existence confirmation means. A survival check method executed by a communication system including a client device that performs data communication via a tunnel established between the server device and the server device,
The client device is
When there is no data packet transmission from the application unit included in the client device, a survival confirmation request is transmitted to the server device at a first time interval, and a survival confirmation request response is received from the server device that has received the survival confirmation request. If received, send a survival confirmation request response receipt to the server device,
When there is a data packet transmission from the application unit, a data packet with receipt of a survival confirmation request response within a second time after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device Is transmitted to the server device, and after the second time has elapsed after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device, a data packet with a survival confirmation request is transmitted to the server device. ,
When a third time has elapsed without receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device, it is determined that the state of the tunnel has deteriorated,
The server device
When there is no data packet transmission from the server device, when a survival confirmation request is received from the client device, a survival confirmation request response is transmitted to the client device, and when there is a data packet transmission from the server device. When a data packet with a survival confirmation request is received from the client device, a data packet with a survival confirmation request response is transmitted to the client device,
When a survival confirmation request response or a data packet with a survival confirmation request response is transmitted to the client device, and a survival confirmation request response is received or a data packet with a survival confirmation request response is not received from the client device within a fourth time period. And determining that the state of the tunnel has deteriorated. A program for causing a computer to function as a client device that performs data communication via a tunnel established with a server device,
Client-side tunnel communication means for constructing the tunnel with the server device and transmitting and receiving packets via the tunnel,
Function as client side survival confirmation means for sending and receiving packets for survival confirmation through the tunnel,
The client side survival confirmation means is:
When there is no data packet transmission from the application unit included in the client device, a survival confirmation request is transmitted to the server device at a first time interval, and a survival confirmation request response is received from the server device that has received the survival confirmation request. If received, send a survival confirmation request response receipt to the server device,
When there is a data packet transmission from the application unit, a data packet with receipt of a survival confirmation request response within a second time after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device Is transmitted to the server device, and after the second time has elapsed after receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device, a data packet with a survival confirmation request is transmitted to the server device. ,
A program for determining that the state of the tunnel has deteriorated when a third time has elapsed without receiving a survival confirmation request response or a data packet with a survival confirmation request response from the server device.

Images