JP2022161704A - Communication system and communication method - Google Patents

Abstract

To provide a mechanism that allows communication on a network in an appropriate packet size with a simple configuration.SOLUTION: A communication system includes a transmission-side device that transmits a communication packet and a reception-side device that is communicable with the transmission-side device via a network, and the communication system includes a management device that manages a packet size that allows communication in the network without the occurrence of fragments. The transmission-side device comprises: acquisition means that requests the packet size managed by the management device via the network and acquires the packet size; and transmission means that transmits a communication packet of the acquired packet size to the network with the reception-side device as a destination.SELECTED DRAWING: Figure 8

Description

The present invention relates to a communication system and communication method including a relay device.

When a communication terminal device communicates with a server device via a TCP/IP (Transmission Control Protocol/Internet Protocol) network, a communication path may be established via a plurality of relay devices. A data link connects between the communication terminal device and the relay device, between the plurality of relay devices, and between the relay device and the server device. The size of IP packets that can be transmitted and received on each data link is determined based on the MTU (Maximum Transfer Unit) value determined for each data link. When communication is performed between a communication terminal device and a server device, the MTU value of the entire path (hereinafter referred to as path MTU value) is determined according to the data link to be routed.

When an IP packet constructed by a communication terminal device is transmitted to a relay device, the relay device cannot directly transmit the packet to the next data link if the packet size exceeds the MTU value of the next data link. Therefore, the relay device divides the IP packet so that the size of the IP packet is equal to or smaller than the MTU value of the next data link. The process of dividing this packet is called fragmentation. Each fragmented IP packet is transferred to the next relay device and combined by the receiving relay device or the terminal server device, and the server device receives a packet of the same size as the original transmission packet.

Non-Patent Document 1 discloses a path MTU search method as Path MTU Discovery. Further, Patent Document 1 describes that a screen for setting the MTU value is displayed on the liquid crystal display section of the operation panel.

IETF RFC1191: Path MTU Discovery

JP 2017-041849 A

In Non-Patent Document 1, in order to properly execute path MTU discovery, all relay devices on the path must respond to packets for path MTU discovery. However, for security reasons, it may be set so as not to respond to the ICMP message used for route MTU search toward the external network. In such cases, path MTU discovery cannot be performed properly. Further, in Patent Document 1, when the communication terminal device cannot communicate with the server device, the user needs to set an appropriate MTU value in the communication terminal device. However, it is not easy for a user to identify the cause of communication failure caused by fragmentation or to obtain an appropriate MTU value when path MTU search cannot be performed.

SUMMARY OF THE INVENTION An object of the present invention is to provide a mechanism that enables communication on a network with an appropriate packet size with a simple configuration.

In order to solve the above problems, a communication system according to the present invention is a communication system including a transmitting device that transmits communication packets, and a receiving device that can communicate with the transmitting device via a network, The communication system includes a management device that manages a packet size that allows communication without fragmentation in the network, and the transmitting device requests the packet size managed by the management device via the network. a means for acquiring the packet size; and a transmission means for transmitting the communication packet of the packet size acquired by the acquisition means to the network with the receiving device as a destination.

According to the present invention, it is possible to communicate on a network with an appropriate packet size with a simple configuration.

It is a figure which shows the structure of a communication system. 3 is a block diagram showing the configuration of the control system of the MFP; FIG. 3 is a block diagram showing the configuration of a control system of the server device; FIG. FIG. 4 is a diagram showing data structures of an HTTP request and an HTTP response; FIG. 4 is a diagram showing a communication sequence between devices; 4 is a flow chart showing processing executed by a communication terminal device; 4 is a flowchart showing processing executed by the server device; FIG. 4 is a diagram showing a communication sequence between devices; FIG. 4 is a diagram showing data structures of an HTTP request and an HTTP response; FIG. 4 is a diagram showing a communication sequence between devices;

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. In addition, the following embodiments do not limit the invention according to the scope of claims. Although multiple features are described in the embodiments, not all of these multiple features are essential to the invention, and multiple features may be combined arbitrarily. Furthermore, in the accompanying drawings, the same or similar configurations are denoted by the same reference numerals, and redundant description is omitted.

[First embodiment]
FIG. 1 is a diagram showing an example of the configuration of a communication system 100 according to this embodiment. A communication system 100 includes a plurality of communication terminal devices 101, a server device 102, and a plurality of relay devices 103, and the devices are connected via a network so as to be able to communicate with each other. FIG. 1 shows that the relay device 103 b and the relay device 103 c are connected via the Internet 105 . In FIG. 1, a plurality of communication terminal devices 101 are shown as communication terminal device 101a and communication terminal device 101b. In this embodiment, the communication terminal device 101a and the communication terminal device 101b may be collectively referred to as the communication terminal device 101 in some cases. Also, in FIG. 1, the plurality of relay devices 103 are shown as relay devices 103a, 103b, and 103c. In this embodiment, the relay devices 103a, 103b, and 103c may be collectively referred to as the relay device 103. FIG. The communication terminal device 101 is, for example, a personal computer (PC), a smartphone terminal, or a multifunction printer (MFP). Also, the relay device 103 is a device that relays communication packets transmitted from the communication terminal device 101, and is, for example, a bridge, HUB, router, or wireless LAN access point. In FIG. 1, an MFP 101a as the communication terminal device 101 and a PC 101b as the communication terminal device 101 are shown.

In the communication system 100 , the server device 102 can collect service usage information transmitted from the communication terminal device 101 , for example. Further, the communication terminal device 101 can download update firmware from the server device 102, for example. Also, the communication terminal device 101 can execute a cloud print function via the server device 102, for example. With the cloud print function, print data uploaded from a PC or smartphone terminal to the server device 102 is sent to the MFP 101a as a print job or together with the print job.

The paths between communication terminal device 101 and relay device 103, between a plurality of relay devices 103, and between relay device 103 and server device 102 are connected as data links 104a to 104d, respectively. A data link 104a indicates a data link between the MFP 101a and the relay device 103a, and a data link 104b indicates a data link between the PC 101b and the relay device 103a. A data link 104c indicates a data link between the relay device 103a and the relay device 103b, and a data link 104d indicates a data link between the relay device 103c and the server device . Communication between the communication terminal device 101 and the server device 102 is performed by appropriately selecting the data links 104a to 104d connecting the plurality of relay devices 103 in a mesh pattern.

The size of IP packets that can be communicated over each data link is determined based on the MTU (Maximum Transfer Unit) for each data link. For example, the MTU in Ethernet (registered trademark) is 1500 octets. If an encapsulation protocol such as IPSec is used, it is considered to form a logical data link (logical data link). In that case, the MTU value in the logical data link is determined according to the header capacity used in the encapsulation, relative to the physical MTU value. That is, a value smaller than the MTU value of the physical data link becomes the MTU value of the logical data link. In FIG. 1, for example, the MTU of the data link 104c from the relay device 103a to the relay device 103b is defined as 1454 octets. As described above, when communication is performed between the communication terminal device 101 and the server device 102 via a plurality of relay devices 103, the MTU value is determined according to the data link to be routed.

When an IP packet exceeding the MTU value is transmitted from the communication terminal device 101, and if the packet size exceeds the MTU of the next data link in the relay device 103, the relay device 103 directly transfers the packet to the next data link. Unable to send. Therefore, the relay device 103 divides the IP packet so that the size of the IP packet is equal to or less than the MTU value of the next data link. Hereinafter, the process of dividing this packet will be referred to as fragmentation. Each fragmented IP packet is transferred to the next relay device 103 and combined by the relay device 103 on the receiving side or the server device 102 at the final end. As a result, server device 102 receives a packet of the same size as the original transmission packet.

For example, in FIG. 1, assume that a packet of 1500 octets is transmitted from communication terminal device 101 to server device 102 . In the relay device 103a, the packet size exceeds the MTU value of 1454 octets of the next data link 104c, so the relay device 103a fragments the packet so that it fits within 1454 octets and transfers the packet. Packets that have been fragmented and transferred are to be recombined at the relay device 103c on the receiving side or the server device 102 at the final end.

However, depending on the relay device 103c or server device 102 being used, such recombination may not be performed. For example, there are cases where recombination on the receiving side is not performed due to the operational load of the relay device. In order to reassemble the fragmented packets on the receiving side, it is necessary to hold all of the multiple fragmented packets until reception is complete. Due to the characteristics of the TCP/IP network, the arrival order of a plurality of fragmented packets is not guaranteed, so the receiving side needs a memory for holding. The processing load on a server connected to a large number of terminals is not small. Further, some relay devices and server devices are configured to discard fragmented packets as illegal packets without recombining them. In this way, if fragmented packets are not recombined, a communication problem will occur between the communication terminal device 101 and the server device 102 .

In this embodiment, the communication terminal device 101 acquires the packet size indicated by the used MTU value from the server device 102, and transmits the packet with that packet size. The used MTU value, which will be described later, indicates a packet size that is not fragmented on the way. Therefore, since fragmentation is not performed, even if the configuration is such that recombination is not performed as described above, communication failures between the communication terminal device 101 and the server device 102 can be prevented. can be prevented.

FIG. 2 is a block diagram showing an example of the control system configuration of the MFP 101a having a network connection function. Here, the MFP 101a is shown as an example of the communication terminal device 101, but other forms of devices may be used as long as they can connect to a network and communicate with the server device 102. FIG. For example, the PC 101b, a smart phone terminal, or other devices may be used. A CPU 201 in the form of a microprocessor comprehensively controls the inside of the MFP 101a. For example, the CPU 201 reads and executes a control program stored in a ROM-type program memory 203 connected via an internal bus 202 and the contents of a RAM-type data memory 204 . For example, the CPU 201 controls the scanner unit 205 to optically read a document placed on a document platen (not shown), and stores the reading result as image data in the image memory 206 in the data memory 204 . The CPU 201 also controls the printing unit 207 to print on a recording medium based on the image data in the image memory 206 in the data memory 204, for example.

The CPU 201 controls the wireless LAN unit 208 to connect to a wireless LAN access point 211 provided outside. The wireless LAN access point 211 is connected to a network such as the Internet, and the CPU 201 connects to the Internet via the wireless LAN access point 211, for example, and communicates with other devices. Here, the wireless LAN access point 211 operates as a router for connecting to the Internet. That is, wireless LAN access point 211 operates as relay device 103 in communication system 100 .

The CPU 201, for example, controls the operation unit control unit 209 to display the state of the MFP 101a and the function selection menu on the operation panel 210 provided on the outer surface of the MFP 101a, and to receive operations from the user. The CPU 201 also accesses the server device 102 connected via the Internet 105, acquires print content, and controls the printing unit 207 to print on a recording medium based on the print content. The CPU 201 also transmits image data obtained by reading a document with the scanner unit 205 to the server device 102 or another device, for example. Further, the CPU 201 receives additional services from the server device 102 by collecting, for example, the print execution status of the printing unit 207 as log information and transmitting the log information to the server device 102 . Further, the CPU 201 can start the operation of the device based on user input to the operation panel 210 . For example, when the CPU 201 receives a user instruction for a copy function, the CPU 201 causes the printing unit 207 to print image data obtained by scanning a document with the scanner unit 205 .

FIG. 3 is a block diagram showing an example of the configuration of the control system of the server device 102. As shown in FIG. The server device 102 includes a main board 310 that controls the entire device, a network connection unit 301 and a hard disk unit 302 . The CPU 311 of the main board 310 controls the inside of the server device 102 by reading and executing the control program stored in the program memory 313 connected via the internal bus 312 and the contents of the data memory 314. control effectively. The CPU 311 controls the network connection unit 301 via the network control unit 315 to connect to a network such as the Internet and communicate with other devices. The CPU 311 can read/write data from/to the hard disk unit 302 connected via the hard disk controller 316 . The hard disk unit 302 stores an operating system that is read into the program memory 313 and executed, control software for the server apparatus 102, and various data. Control software running on the server device 102 is, for example, a web application. The server device 102 receives a request from the communication terminal device 101 by HTTP protocol, HTTPS protocol, or the like, for example. Server device 102 also transmits content stored in hard disk unit 302 to communication terminal device 101 in response to a request, for example.

FIG. 4 is a diagram showing an example of the data structure of an HTTP request and HTTP response from the MFP 101a to the web application of the server device 102. As shown in FIG. FIG. 4(a) shows an example of the data structure of an HTTP request. The data structure of FIG. 4A is a data structure when a request is transmitted from the communication terminal device 101 to the server device 102 using the HTTP protocol. The HTTP request 400 is entirely described as text data, and its structure is determined in units of lines separated by line feed codes. The first line of HTTP request 400 is request line 401 . A request line 401 starts with an HTTP method to be requested, followed by a URI (Universal Resource Identifier) specifying a resource to be requested and a protocol version notation, and ends with a linefeed code.

A line following the request line 401 to the first blank line is a request header 402 . The request header 402 describes the request and additional information about the HTTP client that is the source of the request, and such information is passed to the HTTP server that is the destination of the request.

The lines after the blank line after the request header 402 are the message body 403 . The message body 403 describes the data itself passed from the HTTP client to the HTTP server according to the type of HTTP method requested. Note that the message body 403 may not exist depending on the HTTP method. FIG. 4(a) shows dataentry. An example of sending data of name=xxxx&data=yyyyy described in the message body 403 to the HTTP server using the POST method to html is shown.

FIG. 4(b) is a diagram showing an example of the data structure of an HTTP response. The data structure of FIG. 4B is a data structure for transmitting a response from the server device 102 to the communication terminal device 101 in response to an HTTP request. The HTTP response 410 is entirely described as text data, and its structure is determined in units of lines separated by line feed codes. The first line of HTTP response 410 is response line 411 . The response line 411 begins with the protocol version, followed by a numeric status code and a string of characters, and ends with a line feed code.

A line following the response line 411 to the first blank line is a response header 412 . The response header 412 describes the status, additional information about the data passed in the response body 413 included in the HTTP response, and the like, and such information is passed to the HTTP client that is the source of the request.

Lines after the blank line after the response header 412 are the response body 413 . The response body 413 describes the data itself passed from the HTTP server to the HTTP client. Note that the response body 413 may not exist depending on the HTTP method. FIG. 4(b) shows an example in which the response body 413 of the HTML format web page document data is sent to the HTTP client as a response to the HTTP request.

FIG. 5 is a diagram showing an example of a communication sequence between the MFP 101a and the server device 102. As shown in FIG. FIG. 5(a) shows a communication sequence when the packet size does not exceed the MTU value. In S501, an IP packet is transmitted from the MFP 101a to the relay device 103a. Here, assume that the packet size of the IP packet is 1400 octets. In S502, the relay device 103a transfers the received IP packet to the relay device 103b. At this time, since the route MTU of the data link 104a from the relay device 103a to the relay device 103b is 1454 octets, the IP packet is transferred without being fragmented. Similarly, in S503, the IP packet is transferred from the relay device 103b to the relay device 103c without being fragmented. Also, in S504, the IP packet is transferred from the relay device 103c to the server device 102 without being fragmented.

The server device 102 that received the IP packet in S504 transmits an IP packet as a response to the IP packet to the relay device 103c in S5005. Here, assume that the packet size of the response IP packet is 800 octets. Since the packet size of the response IP packet is smaller than the MTU value of each route, the response IP packet is transferred to the MFP 101a without being fragmented in steps S506 to S508.

FIG. 5(b) is a diagram showing an example of a communication sequence when fragmentation is performed because the packet size exceeds the MTU value. In S511, an IP packet is transmitted from the MFP 101a to the relay device 103a. Here, assume that the packet size of the IP packet is 1480 octets. The relay device 103a transfers the received IP packet to the relay device 103b, but since the route MTU of the data link 104a from the relay device 103a to the relay device 103b is 1454 octets, the IP packet is fragmented into two packets and transferred. be done. At S512, the first fragment packet of 1454 octets is transmitted, and at S513, the second fragment packet is transmitted. The relay device 103b that received the first fragment packet transfers the first fragment packet (1454 octets) to the relay device 103c in S514. Then, the relay device 103b transfers the second fragment packet (remaining data) subsequently received to the relay device 103c in S515. The relay device 103 c recombines the received two fragment packets and transfers them to the server device 102 .

The first fragment packet transmitted in S514 is held in the buffer within the relay device 103c in S516. Subsequently, when the second fragment packet transmitted in S515 is received, it is recombined with the first fragment packet held in the buffer in S517. The IP packets restored to the original packet size of 1480 octets by recombination are transferred to the server device 102 in S518. The server device 102 that received the IP packet in S518 transmits the IP packet as a response to the relay device 103c in S519. Here, it is assumed that the packet size of the IP packet used as a response is 800 octets. Since the packet size of the response IP packet is smaller than each path MTU value, the response IP packet is transferred to the MFP 101a without being fragmented in steps S520 to S522.

FIG. 5(c) is a diagram showing an example of a communication sequence when fragmented packets are discarded without being recombined. In S531, an IP packet is transmitted from the MFP 101a to the relay device 103a. Here, assume that the packet size of the IP packet is 1480 octets. The relay device 103a transfers the received IP packet to the relay device 103b, but since the route MTU of the data link 104a from the relay device 103a to the relay device 103b is 1454 octets, the IP packet is fragmented into two packets and transferred. be done. At S532 the first fragmented packet (1454 octets) is transmitted, and at S533 the second fragmented packet is transmitted. The relay device 103b that has received the first fragment packet transfers the first fragment packet to the relay device 103c in S534, and then transfers the second fragment packet received subsequently to the relay device 103c in S535.

Here, the relay device 103c does not have a function of recombining fragmented packets. Therefore, the first fragmented packet sent at S534 is discarded at S536. The second fragment packet transmitted in subsequent S535 is also discarded in S537. As described above, when the relay apparatus 103c does not have a function to reassemble fragmented packets, and the packet transmitted from the MFP 101a exceeds 1454 octets, the packet is discarded without reaching the server apparatus 102. put away. The operation of this embodiment for preventing communication between the communication terminal device 101 and the server device 102 from being stopped due to such fragments will be described below.

FIG. 6 is a flowchart showing processing executed by the MFP 101a. The processing in FIG. 6 is executed, for example, when the MFP 101a transmits an HTTP request to the server device 102. FIG. The processing in FIG. 6 is implemented, for example, by reading and executing a program stored in the program memory 203 by the CPU 201 of the MFP 101a. Further, in the present embodiment, the processing executed by the MFP 101a will be described, but the same applies to the processing executed by the PC 101b.

In S<b>601 , the CPU 201 transmits to the server apparatus 102 a packet requesting an inquiry about the used MTU value. The used MTU value will be described later with reference to FIG. Here, the packet size of the used MTU value query request packet is restricted so as not to be fragmented on the way. Alternatively, only the inquiry request for the used MTU value may be transmitted after dividing the packet by a predetermined small MTU value in advance. In S<b>602 , the CPU 201 waits for reception of a response to the inquiry request for the used MTU value from the server apparatus 102 . Upon receiving the used MTU value response, the CPU 201 advances to step S<b>6003 and stores the used MTU value stored in the received response in the work area in the data memory 204 .

After storing the used MTU value, the CPU 201 transmits an HTTP request packet to the server apparatus 102 in S604. At this time, the CPU 201 divides the HTTP request packet by the used MTU value stored in S603 and then transmits the packet. The used MTU value is a value at which fragmentation is not performed on the route between the MFP 101a and the server apparatus 102. FIG. Therefore, the HTTP request packet reaches the server device 102 without being fragmented on the route between the MFP 101a and the server device 102. FIG.

When all the HTTP request packets divided in S604 have been transmitted, the CPU 201 waits for reception of an HTTP response to the HTTP request from the server apparatus 102 in S605. Although an HTTP request has been described as an example here, a packet corresponding to a GET request, a POST request, or other requests may also be used. In addition, the HTTPS protocol may be used as encrypted communication when measures against leakage and falsification are required. Furthermore, protocols other than HTTP may be used.

As described above, in this embodiment, the used MTU value is inquired each time an HTTP request packet is transmitted. With such a configuration, an appropriate use MTU value can be acquired at the timing of transmitting an HTTP request packet. However, other arrangements may be made to query the used MTU value. For example, if there is a previously stored used MTU value in the work area, the inquiry about the used MTU value may not be made. Such a configuration can reduce the communication load on the network. Also, when the power of the MFP 101a is turned on again, the used MTU value may be reset, and the inquiry about the used MTU value may be made again. Further, when a predetermined period of time has elapsed after acquisition of the used MTU value, the used MTU value may be reset and an inquiry about the used MTU value may be made again.

FIG. 7 is a flow chart showing processing executed by the server device 102 . The processing in FIG. 7 is executed as a web application program running on the server device 102, for example. 7 is implemented by the CPU 311 reading and executing a program stored in the program memory 313, for example. The processing in FIG. 7 is a loop processing that repeats steps S701 to S710 as a whole. In the loop processing, each time a request is received from the MFP 101a in step S702, processing is performed according to the content of the received request. .

In S702, the CPU 311 receives a request from the MFP 101a. Although the MFP 101a is described here as an example of the communication terminal device 101, the same applies to the PC 101b. In S703, the CPU 311 determines whether or not the request received from the MAP 101a is an inquiry request for the used MTU value. If it is determined that the request received from the MFP 101a is a use MTU value inquiry request, the process advances to step S704, and the CPU 311 performs processing for the use MTU value inquiry request.

In S704, the CPU 311 creates a response packet to the used MTU value inquiry request packet. Here, the used MTU value held in advance in the server device 102 is stored in the response packet. The used MTU value held in the server device 102 is set to, for example, “1500” as a default value, and other values can be set by the operator of the server device 102 . For example, when it is confirmed that the communication from the MFP 101a to the server apparatus 102 normally reaches the server 102 even with the fragmentation performed on the way, the operator sets that value as the used MTU value.

For example, when a request is received from the MFP 101a, it may be determined whether reconnection has been executed by checking the execution history of reconnection in the relay device 103c. The confirmation of the execution history of recombining may be performed by the operator of the server 102 or by the CPU 311 . As in the case of FIG. 5(a), if the relay device 103c has not recombined, the received packet size (for example, 1400 octets) is set as the used MTU value. At that time, the previously used MTU value may be updated. Also, as in the case of FIG. 5(b), if the relay device 103c has recombined, the size of the recombined fragmented packets (for example, 1454 octets) is set as the used MTU value. At that time, the previously used MTU value may be updated.

When the creation of the response packet in S704 is completed, the process advances to S7005, and the CPU 311 transmits the created response packet to the MFP 101a. Then, the processing for the inquiry request for the used MTU value is terminated, and the loop processing is executed again.

If it is determined in S703 that the request received from the MFP 101a is not a request to inquire about the used MTU value, in S706 the CPU 311 determines whether the request received from the MFP 101a is an HTTP request related to a web application. If it is determined that the request received from the MFP 101a is an HTTP request, the process advances to step S707, and the CPU 311 processes the HTTP request. In S707, the CPU 311 creates a response packet for the HTTP request. The CPU 311 analyzes the contents of the request header 402 and message body 403 passed in the HTTP request, and creates necessary data of the response header 412 and response body 413 . Note that depending on the size of the HTTP request and HTTP response, packet division on the transmitting side and packet recombination on the receiving side are performed according to the MTU value used for each of the receiving path and the transmitting path. However, these segmentation/recombination processes are performed in the transport layer, which is a lower layer, and therefore are not considered as web application processes.

In S707, when the creation of the HTTP response packet is completed, the CPU 311 advances to S708, transmits the created HTTP response packet to the MFP 101a, ends the processing for the HTTP request, and executes loop processing again.

If it is determined in S706 that the request received from the MFP 101a is not an HTTP request, that is, if the request received from the MFP 101a is a request other than an inquiry request for the used MTU value and an HTTP request, the process proceeds to S709. Then, the CPU 311 performs processing according to the received request, and then executes the loop processing again.

FIG. 8 is a diagram showing a communication sequence between the MFP 101a and the server device 102. As shown in FIG. The communication sequence of FIG. 8 is realized by the communication terminal device 101 and the server device 102 performing the processes of FIGS. 6 and 7, respectively.

In step S801, when a packet requesting an MTU value to be used is transmitted from the MFP 101a to the server device 102, it reaches the server device 102 via the relay devices 103a, 103b, and 103c (S802, S802, S803, S804). Here, the packet size of the used MTU value query request packet is restricted so as not to be fragmented on the way. For example, the message body 403 is not attached to the HTTP request used for the packet of the inquiry request for the used MTU value, and the content of the request header 402 is restricted to the minimum. Alternatively, packets may be divided in advance with a small MTU value and transmitted. That is, the packet of the used MTU value inquiry request is defined as a packet size smaller than the used MTU value held by the server device 102 so as not to be fragmented on the way.

When the server device 102 receives the used MTU value query request packet, in step S805, the server device 102 transmits a used MTU value response packet to the MFP 101a. The used MTU value response packet reaches the MFP 101a via the relay devices 103c, 103b, and 103a (S806, S807, S808).

The MFP 101a that has received the response packet of the used MTU value transmits an HTTP request in S809 and S810. FIG. 8 shows a case where the HTTP request is split into two packets at the transport layer in the MFP 101a because the packet size of the HTTP request exceeds the MTU value used. That is, the first packet is transmitted to the server device 102 in S809, and the second packet is transmitted to the server device 102 in S810. The first packet reaches the server device 102 via the relay devices 103a, 103b, and 103c (S811, S812, S813). Similarly, the second packet reaches the server device 102 via the relay devices 103a, 103b, and 103c (S814, S815, S816).

When the two packets reach the server device 102, the HTTP requests are recombined at the transport layer and passed to the web application. Note that the two HTTP requests may pass through different relay devices. Also, even if the order of arrival at the server device 102 is changed, the packets are recombined in the correct order in the transport layer based on the sequence numbers of the packets.

When the web application completes the processing of the HTTP request, the server apparatus 102 generates an HTTP response packet and transmits it to the MFP 101a in step S817. The HTTP response packet reaches the MFP 101a via the relay devices 103c, 103b, and 103a (S818, S819, S820).

9(a) and 9(b) are diagrams showing an example of the data structure of an HTTP request 900 inquiring about the MTU value to be used and the corresponding HTTP response 910. FIG. FIG. 9(a) shows an example of the data structure of an HTTP request 900 that inquires about the MTU value used as the packet size. A request line 901 and a request header 902 correspond to the data structures of the request line 401 and the request head 402 in FIG. 4(a). Request line 901 uses the GET method to /mturequest. It shows an example of requesting html data. As shown in FIG. 9(a), the request header 902 is restricted to a minimum content so as not to increase the size of the entire HTTP request.

FIG. 9(b) shows an example of the data structure of an HTTP response 910 to an inquiry about the MTU value to be used. A response line 911, a response header 912, and a response body 913 correspond to the data structure of the response line 411, response header 412, and response body 413 in FIG. 4B. As shown in FIG. 9(b), the response header 912 is limited to the minimum contents, and the response body 413 is limited to the minimum necessary contents for returning the used MTU value. In addition, in FIG. 9B, it is described that the used MTU value is returned using the HTML document format, but it is not limited to this. For example, a lighter data format such as JSON (Javascript Object Notation) other than HTML may be used.

As described above, according to the present embodiment, the communication terminal apparatus 101 such as the MFP 101a acquires the used MTU value from the server apparatus 102 and transmits IP packets with the packet size indicated by the used MTU value. As a result, the IP packet can be transmitted to the server device 102 without being fragmented on the way. Also, if a communication problem occurs due to the MTU value, for example, a communication problem such as reconnection not being performed, the packet size may be changed to that indicated by the used MTU value transmitted from the server device 102 . With such a configuration, for example, there is no need to change settings for each of a plurality of devices connected to the server device 102, and the convenience of network management can be improved.

[Second embodiment]
The second embodiment will be described below with respect to differences from the first embodiment. In the first embodiment, a configuration has been described in which the server device that is the destination of the packet holds the used MTU value. In this embodiment, a configuration will be described in which an MTU management server different from the web application server device to be accessed is inquired about the used MTU value.

FIG. 10 is a diagram showing a communication sequence between MFP 101a, MTU management server device 102a, and web application server device 102b. In this embodiment, the processing of the MFP 101a is the same as that described in the first embodiment, except that the destination of the used MTU value inquiry request packet from the MFP 101a is different. Also, the configurations of the MTU management server device 102a and the web application server device 102b are the same as those of the server device 102 in the first embodiment. In this embodiment, the processing of the MTU management server device 102a corresponds to the processing of S702, S704, and S705 in FIG. Also, the processing of the web application server device 102b corresponds to the processing of S702 and S706 to S709 in FIG.

In S1001, when a packet requesting an inquiry about the used MTU value is sent from the MFP 101a to the MTU management server device 102a, it reaches the MTU management server device 102a via the relay devices 103a and 103b (S1002, S1003). . When the MTU management server apparatus 102a receives the used MTU value inquiry request packet, in S1004 it transmits a used MTU value response packet to the MFP 101a. The response packet of the used MTU value reaches the MFP 101a via the relay devices 103b and 103a (S1005, S1006).

The MFP 101a that has received the response packet of the used MTU value transmits HTTP request packets in S1007 and S1008. Here, since the packet size of the HTTP request exceeds the MTU value used, the HTTP request is split into two packets at the transport layer in the MFP 101a. That is, the first packet is transmitted to the web application server device 102b in S1007, and the second packet is transmitted to the web application server device 102b in S1008. The first packet reaches the web application server device 102b via the relay devices 103a, 103b, and 103c (S1009, S1010, S1011). Similarly, the second packet reaches the web application server device 102b via the relay devices 103a, 103b, and 103c (S1012, S1013, S1014).

When the two packets reach the web application server device 102b, the HTTP requests are recombined at the transport layer and passed to the web application. Note that the two HTTP requests may pass through different relay devices. Also, even if the arrival order to the web application server device 102b is changed, the packets are recombined in the correct order in the transport layer based on the sequence numbers of the packets.

When the web application completes the processing of the HTTP request, the web application server device 102b creates an HTTP response packet and transmits it to the MFP 101a in S1015. The HTTP response packet reaches the MFP 101a via the relay devices 103c, 103b, and 103a (S1016, S1017, S1018).

As described above, according to the present embodiment, the MFP 101a acquires the used MTU value from the MTU management server device 102a, and transmits IP packets with the packet size indicated by the used MTU value. As a result, the IP packet can be transmitted to the web application server device 102b without being fragmented on the way. Also, if a communication problem occurs due to the MTU, for example, a communication problem due to non-reconnection, the packet size may be changed to that indicated by the used MTU value transmitted from the MTU management server device 102a. . With such a configuration, for example, it is not necessary to change the settings of each of a plurality of devices connected to the web application server device 102b, and the convenience of network management can be improved.

Further, in this embodiment, the MTU management server device 102a is provided as a separate device from the web application server device 102b. Such a configuration has the following effects when the web application server device 102b is managed by an administrator different from the administrators of the MFP 101a and the MTU management server device 102a. For example, even if a packet transmitted from the MFP 101a fails to reach the web application server device 102b due to fragmentation and a problem occurs, it may be difficult for the web application server device 102b to respond at an appropriate timing. In such a case, in this embodiment, the packet size is changed to that indicated by the used MTU value transmitted from the MTU management server device 102a. As a result, regardless of the management status of the administrator of the web application server device 102b, it is possible to transmit an IP packet having a packet size that is not fragmented.

This embodiment can also be applied to a configuration in which fragments are not recombined only for packets accessing a specific web application server device 102b when a plurality of web application server devices 102b are configured. For example, the MTU management server device 102a may transmit different used MTU values depending on which web application server device 102b the MFP 101a is attempting to access. As a result, it is possible to prevent communication problems due to fragments even in a configuration in which recombining of fragments is not performed only for communications addressed to a specific web application server device 102b.

Further, this embodiment can also be applied to a configuration in which a plurality of applications corresponding to packets transmitted from the MFP 101a exist on the web application server 102b. For example, the MTU management server apparatus 102a may transmit different used MTU values according to the type of request issued by the MFP 101a. As a result, it is possible to prevent the occurrence of communication problems caused by fragments even in a configuration in which recombining of fragments is not performed only for a request of a specific application among a plurality of applications operating on the web application server device 102b.

Moreover, this embodiment can also be applied to a configuration in which fragments are generated only when passing through a specific relay device 103 on a plurality of routes. For example, the MTU management server device 102a may transmit different used MTU values according to the path through which the MFP 101a accesses the web application server device 102a. As a result, even in a configuration in which fragments occur only when passing through a specific relay device 103 on a plurality of routes, it is possible to prevent the occurrence of communication problems due to fragments.

Also, the operation of each embodiment may be combined with a method of determining an MTU value such as path MTU search. For example, when the path MTU search cannot be performed, such as a configuration that does not respond to the ICMP message used in the path MTU search, the operation of each embodiment is performed. You can do it.

The present invention supplies a program that implements one or more functions of the above-described embodiments to a system or device via a network or a storage medium, and one or more processors in the computer of the system or device reads and executes the program. It can also be realized by processing to It can also be implemented by a circuit (for example, ASIC) that implements one or more functions.

The invention is not limited to the embodiments described above, and various modifications and variations are possible without departing from the spirit and scope of the invention. Accordingly, the claims are appended to make public the scope of the invention.

100 Communication system: 101a MFP: 101b PC: 103a, 103b, 103c Relay device: 102 Server device

Claims (18)

A communication system including a transmitting device that transmits communication packets and a receiving device that can communicate with the transmitting device via a network,
The communication system includes a management device that manages a packet size that allows communication without fragmentation in the network,
The transmitting device,
an acquisition means for requesting a packet size managed by the management device via the network and acquiring the packet size;
transmission means for transmitting the communication packet of the packet size acquired by the acquisition means to the network with the receiving device as a destination;
A communication system comprising: 2. The communication system according to claim 1, wherein said acquisition means transmits a request packet requesting a packet size managed by said management device via said network with said management device as a destination. 3. The communication system according to claim 2, wherein a packet size of said request packet is smaller than a packet size managed by said management device. The management device
generating a first response packet including packet size information managed by the management device when the request packet is received, and transmitting the first response packet via the network to the transmission side device as a destination; 1 response means;
4. The communication system according to claim 2 or 3, characterized by: 5. The communication system according to claim 4, wherein the packet size of said first response packet is smaller than the packet size managed by said management device. The management device is included in the receiving device,
The receiving device,
determining means for determining a request from the transmitting device;
When the determination means determines that the request from the transmission-side device is a request for a packet size managed by the management device, the first response means creates the first response packet, sending a response packet over the network destined for the sending device;
6. The communication system according to claim 4 or 5, characterized by: The receiving device,
if the request from the transmitting device is not a request for a packet size managed by the managing device as a result of determination by the determining means, creating a second response packet in response to the request from the transmitting device; further comprising a second response means for transmitting a second response packet via the network with the sending device as a destination;
7. The communication system according to claim 6, characterized by: 8. The communication system according to claim 7, wherein the packet size of said second response packet is a packet size that allows communication without fragmentation in said network. 6. The communication system according to claim 4, wherein said management device is a device different from said receiving side device. there are a plurality of the receiving devices on the network;
The first response means creates the first response packet including information on a packet size corresponding to a receiving device that is the destination of the communication packet.
10. The communication system according to claim 9, characterized by: 11. The communication system according to claim 10, wherein said first response means creates said first response packet including information on a packet size corresponding to an application of a receiving device to which said communication packet is addressed. 10. The communication system according to claim 9, wherein said first response means creates said first response packet including information on a packet size corresponding to a route of said communication packet. 13. The communication system according to any one of claims 1 to 12, further comprising storage means for storing the packet size obtained by said obtaining means. 14. The communication system according to any one of claims 1 to 13, wherein the packet size managed by said management device is a packet size of an IP (Internet Protocol) packet. 15. The communication system according to any one of claims 1 to 14, wherein the packet size managed by said management device is obtained from a relay device that relays said communication packet on said network. 16. A communication system according to any preceding claim, wherein said receiving device is a web application server. 17. The communication system according to any one of claims 1 to 16, wherein said sending device includes at least one of a printer and a PC. A communication method executed in a communication system including a transmitting device that transmits communication packets and a receiving device that can communicate with the transmitting device via a network,
The communication system includes a management device that manages a packet size that allows communication without fragmentation in the network,
the transmitting device,
an acquisition step of requesting a packet size managed by the management device via the network and acquiring the packet size;
a sending step of sending the communication packet having the packet size obtained in the obtaining step to the network with the receiving device as a destination;
A communication method characterized by comprising:

Images