Generally, a communication application establishes a communication session between transmitting and receiving terminals connected to each other through a network and performs communications on the established session. If a propagation delay time between the transmitting and receiving terminals is very long or they communicate with each other across networks having different properties such as wired and wireless networks, then the throughput of communications between the transmitting and receiving terminals is lowered.
One known method of solving the above problem has been not to perform communications between transmitting and receiving terminals on one session, but to install a relay device between transmitting and receiving terminals and relay data between two sessions, i.e., a session from the transmitting terminal to the relay device and a session from the relay device to the receiving terminal. Examples of such a session relay process include “Indirect TCP” described in Non-patent document 1 (Ajay Bakre and B. R. Badrinath “I-TCP; Indirect TCP for Mobile Host”, Department of Computer Science Rutgers University, DSC-TR-314, 1994) and communication methods described in Patent document 1 (Japanese patent No. 3448481), Patent document 2 (Japanese patent No. 3482091), and Patent document 3 (Japanese patent No. 3494610).
An example of session communications according to TCP will be described below. Details of an ordinary TCP process are described in Non-patent document 2 (Jon Postel, “Transmission Control Protocol”, IETF, RFC 793, 1981) and Non-patent document 3 (W. Richard Stevens, “TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley”, 1994, ISBN 0-201-63346-989).
FIG. 1 shows a double-sided-transmission session relay device for relaying sessions transmissively from both a transmitting terminal and a receiving terminal. As shown in FIG. 1, double-sided-transmission session relay device 32-0 comprises packet input section 32-1 to which packets from a network are input, packet output section 32-2 which outputs packets to the network, session relay section 32-3 for terminating and relaying sessions, session status storing section 32-4 for storing a session status of session relay section 32-3, session determining section 32-5 for determining whether a packet is a session packet or not, session relay determining section 32-6 for determining whether a session relay process is to be performed or not, and session starting process monitoring section 32-7 for monitoring a session starting packet.
Packet input section 32-1 performs a process of receiving packets from the network. Session determining section 32-5 determines whether an input packet from packet input section 32-1 is a session packet or not. If the input packet is a session packet, then session determining section 32-5 passes the input packet to session relay determining section 32-6. If the input packet is a packet other than a session packet, then session determining section 32-5 passes the input packet to packet output section 32-2.
Session relay determining section 32-6 determines whether the session packet from session determining section 32-5 is a packet in a session registered in session status storing section 32-4 and also a packet sent after a session start acknowledging packet, or not. If these conditions are satisfied, then session relay determining section 32-6 passes the session packet from session determining section 32-5 to session relay section 32-3. If the conditions are not satisfied, then session relay determining section 32-6 passes the session packet from session determining section 32-5 to session starting process monitoring section 32-7.
When session starting process monitoring section 32-7 receives a session starting packet, it registers session information representing a reception sequence number (a sequence number to be received from a receiving terminal) and a transmission sequence number (a sequence number to be transmitted to a transmitting terminal) which are temporarily generated, but not yet determined. When session starting process monitoring section 32-7 receives a session start acknowledging packet, it determines the reception sequence number and the transmission sequence number, which have been temporarily generated, in the session information. After the processing of session starting process monitoring section 32-7 is over, the session packet from session determining section 32-5 is passed to packet output section 32-2.
Session relay section 32-3 performs a session relay process based on the session status stored in session status storing section 32-4, stores an updated session status in session status storing section 32-4, and passes a packet from session relay determining section 32-6 to packet output section 32-2, Packet output section 32-2 outputs the supplied packet to the network.
A session according to a TCP in the session relay device shown in FIG. 1 will be described below. In the session according to the TCP, a session starting packet and a session start acknowledging packet are referred to as a SYN packet and a SYN• ACK packet, respectively.
FIG. 2 is a block diagram of a network configuration including session relay device 32-0 shown in FIG. 1. FIG. 3 is a sequence diagram of a TCP relay process performed by session relay device 32-0 in the network configuration shown in FIG. 2. The example shown in FIG. 3 represents a sequence operation for transferring data from transmitting terminal 10 having IP address A to port number 80 of receiving terminal 20 having IP address B.
First, transmitting terminal 10 sends a connection starting SYN packet to receiving terminal 20. The connection starting SYN packet includes information representing source IP address “A”, source port number “x”, sequence number “1”, destination IP address “B”, and destination port number “80”.
In session relay device 32-0 on the route, the connection starting SYN packet from transmitting terminal 10 is supplied to packet input section 32-1. Packet input section 32-1 passes the supplied SYN packet to session determining section 32-5. Session determining section 32-5 determines that the packet from packet input section 32-1 is a session packet, and passes the packet to session relay determining section 32-6. Session relay determining section 32-6 determines that the packet received from session determining section 32-5 does not corresponds to a session registered in session status storing section 32-4, and passes the received packet to session starting process monitoring section 32-7.
Session starting process monitoring section 32-7 determines that the packet received from session relay determining section 32-6 is a session starting (SYN) packet, registers the session in session status storing section 1-4, and starts a session relay process to pass the received packet to packet output section 32-2. At this stage, at least a transmission sequence number to receiving terminal 20 and a reception sequence number from transmitting terminal 10 are stored in session status storing section 32-4. These two sequence numbers are initialized by the sequence number of the session starting (SYN) packet. The information of the session registered at this stage is incomplete session information as a whole because the transmission sequence number to receiving terminal 20 and the reception sequence number from transmitting terminal 10 have not yet been determined.
Having received the packet from session starting process monitoring section 32-7, packet output section 1-2 sends the received packet over the network to receiving terminal 20. The packet information in the SYN packet which is input to session relay device 32-0 and the packet information in the SYN packet which is output from session relay device 32-0 do not differ from each other.
When receiving terminal 20 receives the SYN packet from session relay device 32-0, it returns a SYN• ACK packet to transmitting terminal 10.
In session relay device 32-0 on the route, the SYN• ACK packet from receiving terminal 20 is supplied to packet input section 32-1. Packet input section 32-1 passes the SYN• ACK packet to session determining section 32-5. Session determining section 32-5 determines that the packet received from packet input section 32-1 is a session packet, and passes the received packet to session relay determining section 32-6. Session relay determining section 32-6 determines that the packet received from session determining section 32-5 corresponds to a session registered in session status storing section 1-4, and is not a packet after the session start acknowledging (SYN• ACK) packet, and passes the received packet to session starting process monitoring section 32-7.
Session starting process monitoring section 32-7 determines that the packet received from session relay determining section 32-6 is not a session starting (SYN) packet, but is a session start acknowledging (SYN• ACK) packet, updates the session information in session status storing section 32-4, and starts a session relay process to pass the received packet to packet output section 1-2. At this stage, the transmission sequence number to receiving terminal 20 and the reception sequence number from transmitting terminal 10 are updated. These two sequence numbers are initialized by the sequence number of the session start acknowledging (SYN• ACK) packet.
Having received the packet from session starting process monitoring section 32-7, packet output section 32-2 sends the received packet over the network to transmitting terminal 10. The packet information in the SYN• ACK packet which is input to session relay device 32-0 and the packet information in the SYN packet which is output from session relay device 32-0 do not differ from each other.
Thereafter, in session relay device 32-0, session relay section 32-3 returns an ACK packet responsive to the SYN• ACK packet to receiving terminal 20. In this manner, session relay device 32-0 opens a session between transmitting terminal 10 and receiving terminal 20.
When the communication route suffers a certain failure after the session has been opened, a status notification is performed according to ICMP (Internet control massage Protocol). Details of operation according to ICMP are described in Non-patent document 3 and Non-patent document 4 (Jon Postel, “INTERNET CONTROL MESSAGE PROTOCOL”, IETF, RFC 792, 1981).
If an IP header contains a “Don't Fragment” flag when the route includes zones of different MTUs (Maximum Transfer Units), then the data cannot be fragmented and transferred. One solution to this problem is a process called Path MTU discovery proposed in Non-patent document 5 (J. Mogul, S. Deering, “Path MTU discovery”, IETF, RFC 1191, 1990).
FIG. 4 shows a packet configuration of an ICMP Destination Unreachable/fragmentation request message. FIG. 5 shows a configuration of a PET part which has caused an error that is included in the ICMP Destination Unreachable/fragmentation request message. According to the Path MTU discovery process, if data cannot be fragmented and transferred because of the “Don't Fragment” flag in a router which includes zones of different MTUs, then the next-hop MTU is added to the ICMP Destination Unreachable/fragmentation request message shown in FIG. 4 and the message is sent to the source, so that the terminal of the source will retransfer a segment with a reduced MSS (Maximum Segment Size). In FIG. 4, “Internet Header+64 bits of Original Data Datagram” includes the information shown in FIG. 5 which is included in the packet which has caused the error.
When the communication route contains a plurality of zones of different MTUs, a process of notifying the source of an MTU according to the ICMP to reduce the MSS is repeated until a minimum MTU is detected. At the time the minimum MTU is detected, communications are made possible between the source and the destination. A similar process is disclosed in Patent document 4 (JP-A No. 2003-18216).
FIG. 6 is a diagram illustrative of an operation based on Path MTU discovery of a network apparatus having the double-sided-transmission session relay device shown in FIGS. 1 and 2. The operation based on Path MTU discovery with respect to an example according to TCP will be described below with reference to FIG. 6. In this example, the sum of IP and TCP header sizes is 40 bytes.
After the SYN process, transmitting terminal 421 (address: A, port: x) sends data having a segment size of 1460 bytes and a packet size of 1500 bytes toward receiving terminal 423 (address: B, part: 80). The data output from transmitting terminal 421 is supplied to router 422 (address: C). Since the next hop is in the zone of “MTU=500”, router 422 which has received the data from transmitting terminal 421 adds the next-hop MTU to the ICMP Destination Unreachable/fragmentation request message, and sends the message to transmitting terminal 421. The ICMP Destination Unreachable/fragmentation request message from router 422 is supplied to transmitting terminal 421.
In response to the fragmentation request message, transmitting terminal 421 resends data having a segment size of 460 bytes and a packet size of 500 bytes toward receiving terminal 423. As the packet size of the data resent from transmitting terminal 421 is 500 bytes, router 422 sends the data resent from transmitting terminal 421 to receiving terminal 423. As a result, the packet of the resent data reaches receiving terminal 423, allowing data to be exchanged continuously between transmitting terminal 421 and receiving terminal 423.