Network communication apparatus, method and program

The present invention relates to a communication function with a device on a network that operates on, for example, a PC (personal computer). In particular, it relates to a communication function that uses IPv6 (Internet Protocol Version 6) as a communication protocol.

In response to the depletion of addresses in the current Internet Protocol (IPv4), IPv6 is practically used as a next-generation Internet Protocol with improvements such as increased address space, addition of security functions, and data transmission according to priority. Is beginning to become. The IPv6 protocol is designed so that multiple addresses can be assigned to one network interface. For example, a link-local unicast address (hereinafter referred to as a link-local address), a global unicast address (hereinafter referred to as a global address), and the like are known as assigned addresses. Furthermore, since a plurality of addresses can be assigned as global addresses, an IPv4 address and a plurality of IPv6 addresses may be registered in a DNS (Domain Name System) server for one host.

An FQDN (Fully Qualified Domain Name), which is usually called a "name", is used to identify the communication partner. The FQDN is a host name or domain name displayed from the root along the hierarchical structure of the DNS domain. FQDN Is sometimes referred to simply as the "name" below. Multiple IPv6 may be obtained by querying the DNS server for a binary address by specifying a name. Not all of these addresses can be reached from the inquiring PC. Therefore, in TCP communication using IPv6, multiple addresses obtained as a result of name resolution using DNS will be tried to connect in sequence, and the address at the time of successful connection will be used as the remote address. .. In UDP communication using IPv6, the application must confirm the reachability to the communication partner by using a method such as packet retransmission, so this is also essentially the same as TCP communication for multiple addresses in sequence. Must try to send the packet. In this way, IPv6 communication essentially results in increased network traffic associated with multiple addresses and increased trial time to connect.

Further, there are a plurality of addresses as the own address that is opposite to the other party's address. Once the address of the communication partner is determined, the local address corresponding to that address is to be selected according to the algorithm defined as RFC3484 ("Default Address Selection for Internet Protocol version 6 (IPv6)"). Since this address selection algorithm is usually executed in a program close to the OS (Operating System) called the protocol stack, the application program cannot be involved in the selected own address.

The existence of multiple IPv6 addresses as described above at each of the two communication endpoints causes the following situations to occur, especially when communicating using the UDP protocol. Both communication endpoints A and B hold three IPv6 addresses of their own, which are Addr_A1, Addr_A2, Addr_A3 and Addr_B1, Addr_B2, Addr_B3, respectively. It is assumed that two of the addresses of the communication endpoint B, Addr_B1 and Addr_B2, are registered in DNS.

As shown in Fig. 3 (A), when the communication endpoint A starts communication with the communication endpoint B, first, the name of the communication endpoint B with respect to DNS (here, the name is assumed to be "communication endpoint B"). Request (query) name resolution by specifying. As a result of name resolution, the DNS server returns (responses) two addresses (Addr_B1 and Addr_B2) to the communication endpoint A.

It is assumed that the communication endpoint A that receives the result of the name resolution sends a request to Addr_B1 and reaches the communication endpoint B. The communication endpoint B returns the response corresponding to the request, but at this time, the communication endpoint knows Addr_A1 as the source address of the request, so the response is returned to this address. Then, the address selection algorithm specified in RFC3484 described above functions, and Addr_B3 may be selected instead of Addr_B1 as the optimum address among the three addresses held by the communication endpoint B. In this way, the response from the communication endpoint B is sent from Addr_B3 toward Addr_A1 at the communication endpoint A. Standing on the side of communication endpoint A, data is sent from an unknown address.

When it is determined that the other party to which the communication end point A has sent the request is only the communication end point B, it may be possible to determine that the data from the unknown address is "the response sent from the communication end point B". is there. However, considering the case where a request is sent from the communication end point A to two parties, the communication end point B and the communication end point C, at almost the same time as shown in FIG. 3 (B), it can be seen that the above judgment is impossible. It is assumed that the addresses of the communication end point A, the communication end point B, and the communication end point C in FIG. 3B are Addr_A1, Addr_A2, Addr_A3 and Addr_B1, Addr_B2, Addr_B3 and Addr_C1, Addr_C2, Addr_C3, respectively. Further, it is assumed that among the addresses of the communication endpoint B, the addresses registered in the DNS server are Addr_B1 and Addr_B2, and similarly, those of the communication endpoint C are Addr_C1 and Addr_C2. It is assumed that the communication endpoint A queries the DNS server for the names of the communication endpoint B and the communication endpoint C, and receives two addresses for each endpoint described above as a response. Here, it is assumed that the communication endpoint A sends a request to the communication endpoint B and the communication endpoint C, the communication endpoint B sends a response from Addr_B3 to Addr_A1, and the communication endpoint C sends a response from Addr_C3 to Addr_A1. ..

Communication endpoint A will receive data from unknown addresses Addr_B3 and Addr_C3. It is not possible to determine whether these two received data are the response data transmitted from the communication end point B or the communication end point C. In the case of a protocol such as IPv4 that can always rely on the response being sent back from the destination address of the request, such a problem because the communication partner can be identified by the set of addresses including the port numbers at both ends of the communication. Does not happen. In such a situation, if the source address of the response packet does not match the destination address of the request packet, the reception is rejected, which causes a security problem that packet filtering based on the address cannot be performed.

That is, the data packet sent from an unknown address may be a legitimate response to some request packet, so it cannot be filtered and discarded. Therefore, it means that any packet must be received once.

Decide which protocol to use to access the server where IPv4 and IPv6 addresses are registered in order to improve the traffic increase and processing delay due to name resolution to the DNS server based on past achievements. There is a way to do this (see, for example, Patent Document 1). The conventional technology disclosed in Patent Document 1 mainly assumes a situation in which IPv4 and IPv6 are mixed. The IP protocol that was able to communicate with the server process to be accessed in the past is associated with the server process and cached, and the IP protocol and the corresponding address are used for the next access again. .. This conventional technology is effective in reducing access to the DNS server and reducing unnecessary access attempts when the server process is not waiting for all the protocol addresses registered in the DNS server. To do.

<p num="0012"><patcit num="1"><text>Japanese Unexamined Patent Publication No. 2007-19612</text></patcit></p>

<p num="0013"> However, even with the invention disclosed in Patent Document 1, in the situation where the response from the server process is sent from an unknown address, the prior art does not cache itself, and the following problems cannot be solved. 1. Basically, response data from an address other than the one selected as the destination must be received. That is, there is a security problem that packet filtering by address must be canceled. 2. Applications that communicate using both IPv4 and IPv6 protocol addresses increase the number of name resolution queries to the DNS server. This increases traffic and delays response time. 3. If multiple IPv6 addresses are registered in the DNS server for one communication endpoint, packets may be sent at all of the multiple addresses. That is, the traffic increases.</p>

<p num="0014"> An object of the present invention is to solve the above problems. Therefore, the present invention is a data communication device that communicates with a network device to which a plurality of addresses are assigned via a network. An acquisition method for acquiring the address corresponding to the name of the destination network device,<u style="single">Obtained</u>For the address<u style="single">、</u>Send data<u style="single">Said</u>The transmission means to be transmitted together with the identification information of the transmission data, A receiving means for receiving response data including identification information, and When the identification information of the response data and the identification information of the transmission data are not the same<u style="single">Said</u>A response processing means that does not deliver the response data to the requester for data transmission, but delivers the response data to the requester for data transmission when the identification information of the response data and the identification information of the transmission data are the same.<u style="single">Have,</u><u style="single">When the identification information of the response data and the identification information of the transmission data are the same, the response processing means has the address of the transmission destination of the transmission data or the address of the transmission source of the response data, and the transmission destination. The name of the network device is associated with the name of the network device and stored in the storage means.</u><u style="single">The acquisition means searches the storage means for an address corresponding to the name of the destination network device, and if found, acquires the address as an address corresponding to the name of the destination network device.</u>。 </p>

<p num="0015"> According to the present invention, the application can provide the effect of solving the above problems. That is, it is possible to solve the security problem that packet filtering by address must be canceled. In addition, even in applications that communicate using addresses of both the IPv4 protocol and the IPv6 protocol, it is possible to prevent traffic increase and response time delay. Further, even when a plurality of IPv6 addresses are registered in the DNS server for one communication end point, the increase in traffic can be suppressed.</p>

<figref num="1">It is a block diagram of the printer driver in embodiment.</figref><figref num="2">It is a block diagram which shows the structure of the PC in Embodiment.</figref><figref num="3">(A) It is a figure which shows the relationship between the communication end point which handles an IPv6 address, and the DNS server. (B) It is a figure which shows the relationship of the address used between a plurality of communication endpoints which handle an IPv6 address.</figref><figref num="4">(A) It is a flowchart which shows the data acquisition process in embodiment. (B) It is a flowchart which shows the request issuance processing in embodiment. (C) It is a flowchart which shows the response receipt processing in embodiment.</figref><figref num="5">It is a flowchart which shows the transmission / reception processing in an embodiment.</figref><figref num="6">(A) It is a flowchart which shows the communication partner address acquisition processing in embodiment. (B) It is a flowchart which shows the communication partner address registration process in embodiment.</figref><figref num="7">(A) It is a figure which showed the structure of the request data in an embodiment. (B) It is a figure which showed the structure of the response data in an embodiment.</figref>

FIG. 2 is a block diagram showing a configuration of a PC as a data communication device that is loaded and operates in an application program when the present invention is applied to a printer driver. The PC on which this printer driver is installed functions as a print control device that controls the printer. The operating system (OS) of the PC is stored in the storage means of either RAM4, HDD5, or the storage medium of the disk drive device described later, and is executed by CPU3. Further, the OS is responsible for displaying on the display device 6 at the request of the printer driver, taking in the user's input from the input device 7, and notifying the printer driver. Further, the OS controls the communication unit 8, controls and inputs / outputs the peripheral device 9 in addition to the peripheral device connected by the communication unit 8, and inputs / outputs data to / from the printer driver. Peripheral devices to be controlled include PC cards, various disk drive devices, printers, network cards, and the like. Furthermore, the OS provides a file system function, and the file storage medium is not limited to HDD5 and RAM4 in Fig. 2, but also includes external storage devices including other PCs on the network connected via the communication unit 8. It is a memory. The OS and printer driver send and receive data of hardware modules connected to each other through system buses 1 and 2 on the PC.

The printer driver accesses resources on the PC and uses the functions provided by the OS through the application program interface (API) provided by the OS. The main process of the printer driver is to load it into an application program, pass print data, and translate it into a language that the printer can understand. In addition, the printer driver provides the user with a function to acquire and display the status of the staple device, stacker device, and paper tray mounted on the printer. Furthermore, the printer driver also provides a function of acquiring and displaying a list of jobs waiting to be printed stored inside the printer.

The printer driver is stored in any storage means of RAM4, HDD5, or a storage medium of a disk drive device described later, and is executed by CPU3. Furthermore, the printer driver refers to the file stored in the file system provided by the OS. In the following description of the configuration and operation of the printer driver, the detailed description of the function related to the translation of print data is omitted. The printer driver of this embodiment assumes a network printer, a copier, or the like as a network device of a communication partner designated by the user. These network printers, copiers, and the like are collectively referred to as printers. In the following description, the function of accessing these printers via a network, acquiring the model name of the printer, the function list installed in the printer, and the print job list inside the printer, and displaying them on the display device 6 in FIG. Will be described in detail.

FIG. 1 is a block diagram showing a configuration of a printer driver of the present invention. The printer driver translates the data created by the application program or the like into a printer description language that can be interpreted and executed by the printer specified by the user, and transmits the translated data to the printer. The data to be transmitted is generally referred to as transmission data here, but the above-mentioned translated data sent to the printer is also referred to as print data. The printer driver 10 includes a display unit 50, an input unit 60, an access logic unit 20, a transport unit 30, and a driver logic unit 40. First, define the three functional blocks that exist inside the printer driver.

The driver logic unit 40 is a functional block that instructs the access logic unit 20 to acquire information by designating the name of the printer. The driver logic unit 40 processes the translation of the print data of the printer driver 10 and displays the screen on the display device of the PC. In addition, it is responsible for controlling the printer selection means from the user, the instruction means for acquiring the function of the selected printer, and displaying the information acquired from the printer on the screen. Further, the access logic unit, which will be described later, is requested to specify the name of the printer to acquire desired information, and the process of acquiring the result is also performed.

The access logic unit 20 creates request data based on the transmission data, specifies the destination of the request specified by the domain name or host name (that is, FQDN), and requests the transport unit to transmit the request. It is a block that controls. The request destination can be specified not only in the FQDN but also in the format of IPv4 or IPv6 (Internet Net Protocol version 6) binary address, computer name, etc., but the access logic unit 20 specifies at least the FQDN.

The transport unit is a functional block that sends the requested request data to the requested destination, receives a response to it, and hands it over to the access logic unit. The transport section shall not have any knowledge about the content of the request requested to be sent and the content of the response. Furthermore, the transport unit makes an inquiry to the DNS server for the purpose of specifying the binary address of the destination specified by the FQDN.

The printer driver 10 accesses the DNS server existing on the network. Specify the FQDN of the printer with which the printer driver communicates with the DNS server, and receive the address assigned to that printer as a response.

The input unit 60 receives the user's input via the input device 7 of FIG. 2 and delivers it to the driver logic unit. As the information to be input, the FQDN of the printer as the communication partner and the acquisition start instruction are passed. The display unit 50 controls the process of creating and displaying the data to be displayed on the display device 6 of FIG. The displayed contents are the model name acquired from the printer, the installed function list, and the print job list in the printer.

The driver logic unit 40 passes the printer FQDN and address acquisition start instruction passed from the input unit 60 to the access logic unit 20.

The access logic unit 20 includes a request ID generation unit 201, a communication partner name-request ID-related storage unit 202, a request ID-request-related storage unit 203, and a control unit 200. When the address acquisition start instruction is given, the control unit 200 issues a request ID generation request to the request ID generation unit 201. The request ID generation unit 201 generates and returns a unique ID in response to a request from the control unit 200. The request ID uses an ID that circulates in a relatively long cycle. Therefore, it is very unlikely that the same request ID as the request ID generated when transmitting to a certain printer is used for another request to the same device or a request to another printer at the same time. Conversely, as the cycle of the request ID, a length that does not allow the same request ID to be used at the same time in the same system is selected. One request ID has a maximum of (number of addresses registered in DNS for the destination host name (printer in this example)) x (response waiting time) + (wake-up time from sleep) + (response required) May be used for as long as (hours). Assuming that this time is the maximum ID usage time, the uniqueness of the request ID is maintained if the request ID cycle&gt; maximum ID usage time / (average time interval at which transmission requests occur) is satisfied.

Communication partner name-Request ID-related storage unit 202 is passed the FQDN of the communication partner and the request ID from the control unit 200, and stores them in association with each other. Further, the communication partner name-request ID related storage unit 202 has a function of searching for and returning the FQDN associated with the request ID specified. Request ID-Request-related storage unit 203 is passed a request ID and request data from the control unit, and stores them in association with each other. Further, the request ID-request-related storage unit 203 has a function of searching for and returning the request data associated with the specified request ID.

The control unit 200 controls the request ID generation unit 201, the communication partner name-request ID-related storage unit 202, the request ID-request-related storage unit 203, and the transport unit 30, and is required by the printer of the communication partner. Get information.

Further, the control unit 200 does not know the details of the location (address) of the external DNS server 70 and the printer 80 on the network. The control unit 200 creates protocol data called request data for the transport unit 30 that has been agreed with the printer. A request ID, which is a unique ID for uniquely identifying a communication partner, is embedded in the protocol data. The request data, which is the transmission content, and the communication partner name (FQDN), which is the destination, are passed from the control unit 200 to the transport unit 30, and a transmission request is made.

The transport unit 30 includes a name resolution unit 301, a communication partner name-address-related storage unit 304, a request transmission unit 302, and a response reception unit 303. The request transmission unit 302 receives the request data and the name of the printer to which the request data is sent, that is, the FQDN, as input. The request transmission unit 302 then requests the name resolution unit 301 to convert the received FQDN into an address. The name resolution unit 301 searches the communication partner name-address-related storage unit 304 for the address associated with the FQDN passed from the request transmission unit 302, and if a related address is found, delivers the address to the request transmission unit 302. The communication partner name-address-related storage unit 304 functions as a practical execution part of the function of the name resolution unit 301 that searches for and returns an address from the FQDN. The request transmission unit 302 acquires an address (communication partner address) corresponding to the FQDN of the destination in this way. Both IPv4 and IPv6 can be used as the address specified for name resolution. As described above, in IPv6, a plurality of addresses can be assigned to one name (FQDN).

The request transmission unit 302 transmits the request data requested to the acquired communication partner address using UDP (User Datagram Protocol). At this time, if there are a plurality of addresses returned from the name resolution unit 301, request data is transmitted to each address, and if there is no response within a certain period of time, the process of resending is performed.

The response receiving unit 303 provides a function of receiving the response data from the printer and delivering it to the access logic unit 20 as the response data. At that time, the source address of the response data is also acquired and handed over together with the response data. The printer sends the response data using UDP. The request is associated with the request ID included in the packet.

The packet structures of the request data 701 and the response data 702 sent and received between the printer driver 10 and the printer will be described with reference to FIGS. 7 (A) and 7 (B). FIG. 7A shows request data 701 sent from the printer driver 10 to the printer. It consists of a fixed size packet header and a variable length request body. The packet header is the same as the response data 702 in terms of field configuration. However, in the request data 701, the numerical value "0" meaning the request is specified in the "type" part, and the numerical value "1" meaning the response is specified in the "type" part of the packet header of the response data 702. The size (number of octets) of the request data 701 or the entire response data 702 is stored in the "packet size" part of the packet header. The request ID specified by the side that created the request data 701 is also stored in the corresponding response in the "ID" part. That is, the request ID stored in the corresponding request data is written as it is in the "ID" part in the packet header of the response data 702. The request body has a "command" part that specifies the desired processing content for the receiving side. The type of processing content specified in the "command" part defines a device model name request, a function list request installed in the device, a print job list request in the device, and the like. The parameters specified for each "command" are specified in the "parameter" part of the request body part.

On the other hand, the response body has a "command" part that indicates the processing content, and the content of the "command" stored in the corresponding request data is stored as it is. A value that means the result of executing the process is stored in the "result" part of the response body. Values that mean the results of processing such as success, invalid parameters, and run-time errors are defined.

Next, the processes executed by the access logic unit 20 and the transport unit 30 will be described by the flowcharts shown in FIGS. 4 (A) to 6 (B). FIG. 4A is a flow showing the data acquisition process from the printer, which is the main function of the access logic unit 20.

In step S10, a destination printer is specified, and a request issuance process for transmitting request data to the specified printer is performed. In step S20, the response reception process of receiving the response data from the designated printer together with the address of the communication partner is performed. In step S30, the FQDN which is the destination (communication partner) name specified together with the request data and the address (for example, IP address) received together with the response data are passed to the transport unit 30. As a result, the transport unit 30 is made to associate the name (FQDN) of the communication partner with the address.

The data acquisition process in step S10 includes the processes from step S11 to step S13 as shown in FIG. 4 (B). Step S11 is a request data creation step for creating request data to be sent to the printer. In step S11, request data is created by embedding a unique request ID generated in the request ID generation unit 201 of FIG. 1 in a request packet at least at that time.

Step S12 is an association step of associating the request data with the communication partner. The communication partner here is the name (FQDN) of the printer, and the contents of the request data are copied and stored in the request ID-request-related storage unit 203 of FIG. 1 until a response is received. In step S12, the request packet is associated with the request ID and stored in the request ID-request-related storage unit 203.

In step S13, the created request data 701 is passed to the transport unit 30 together with the name (FQDN) of the printer as the communication partner, and transmission is requested. At the same time as the transmission request, the name of the printer and the request ID are stored in association with each other in the communication partner name-request ID related storage unit 202. This completes the request issuance process.

Since the request data includes the request ID itself, for example, the request ID and the request packet may not be stored in step S12, but the communication partner name and the request packet may be stored in association with each other in step S13. .. In this way, the request data having a specific request ID can be searched.

Next, the response receiving process in step S20 of FIG. 4A, that is, the response process will be described. Figure 4 (C) shows the detailed flow of response receipt processing. The response receipt process consists of the processes from step S21 to step S23. Step S21 is a process of receiving the response data 702 from the transport unit 30. The access logic unit 20 periodically inquires of the transport unit 30 about the arrival of response data, and receives the response data if it has been received. If the data has not been received yet, the transport unit 30 is inquired about the arrival of the data at regular intervals.

If the data can be received, the source address (IP address) of the received data is also acquired at the same time. This is information that the transport unit 30 can obtain from the protocol stack attached to the OS, which will be described later. After this, the process proceeds to step S22.

In step S22, the request ID is extracted from the packet header of the response data 702. Furthermore, using the extracted request ID as a key, the request data associated with the inquiry request ID is acquired in the request ID-request-related storage unit 203 of FIG. That is, the request ID of the response packet is collated with the request ID of the request transmitted in the past. This process is for determining whether or not the response data 702 from the printer is a normal response to the request data 701 sent from the printer driver 10. The fact that the request data having the request ID included in the response data is stored is a proof that the response data has been returned from the correct transmission destination. That is, it can be determined that the response data having the request ID of the transmitted request data has a high probability of being a regular response. Since it is usually difficult to completely prevent forgery and error of the response as long as the request and the response are associated with each other by collating the information, it is judged as a legitimate response based on this high probability. This is the same as in the normal request / response sequence. On the other hand, it can be determined that the response data that does not have the request ID of the transmitted request data is not a regular response.

If it is determined that the response is not a normal response, the response data is discarded without further analysis of the contents. By this processing, it is possible to realize a filter function that detects and discards spoofed packets from a malicious third party on the network to some extent. Next, the content of the response data is analyzed and passed to the display unit 50. The display unit 50 creates display data and displays it on the display device 6 of FIG.

Step S23 is a process of searching the communication partner name from the request ID. Specify the request ID acquired in step S22, and have the communication partner name-request ID related storage unit 202 return the communication partner name (FQDN) associated with the specified request ID. The FQDN obtained here and the source address of the response data obtained in step S21 are returned to the caller, and the response reception process ends.

In step S30, the name-address association function of the name resolution unit 301 of the transport unit 30 is called by inputting the FQDN of the printer acquired in step S20 and the address of the same printer. The name resolution unit 301 performs the process shown in FIG. 6 (B). The explanation will be described later. After that, the request data corresponding to the received normal response and the corresponding request ID are deleted from the request ID-request-related storage unit 203. Similarly, for the request for which the regular response could not be received, the corresponding request data and the corresponding request ID are deleted from the request ID-request-related storage unit 203.

FIGS. 5, 6 (A), and 6 (B) are flows showing the processes executed by the transport unit 30. The transmission process of FIG. 5 is a process executed by the transport unit 30 as a result of the transmission request to the transport unit 30 described as the process of the access logic unit 20 in step S13 of FIG. 4 (B). The transmission process of FIG. 5 includes steps S50 and steps S60 to S67. The communication partner address acquisition process in step S50 will be described as a detailed step in FIG. 6 (A). In step S50, the name of the printer with which the communication is made is received as input. Since it is necessary to convert the name of the communication partner to an address before actually sending the request, access the communication partner name-address-related storage 304 and / or both of the external DNS server 70 to obtain a valid address. Try to get it. The details will be described with reference to FIG. 6 (A).

In step S51 of FIG. 6A, it is determined whether or not the communication partner name passed as the input of step S50 to the communication partner name-address-related storage unit 304 has already been registered as a key. If it has already been registered, in step S53, the address associated with the communication partner name is acquired from the communication partner name-address-related storage unit 304 and returned to the caller. The communication partner name-address-related storage unit 304 may be called a "cache". On the other hand, if it is not registered, the DNS server 70 is requested to resolve the name in step S52. When requesting, request resolution using both IPv4 and IPv6 addresses. If there are multiple obtained addresses, all of them are returned to the caller as a list (address list). When the printer driver 10 accesses a certain printer for the first time, step S51 in FIG. 6 (A) becomes No, and name resolution is executed by the DNS server 70. It should be noted that the "cache" in step S53 does not mean that the result of name resolution on the DNS server 70 is cached as it is. The cache, that is, the communication partner name-address-related storage unit 304 holds the information input in the communication partner address registration process shown in FIG. 6 (B) described later.

After the address of the printer to communicate with is acquired in step S50, the request transmission and response reception processes are executed in step S60 and subsequent steps in FIG. As an outline of the transmission / reception processing in FIG. 5, a request packet is transmitted to the acquired communication partner address, and then it is confirmed whether there is a response after the specified response waiting time. If there are multiple acquired packets, select one of them and send it to the selected address. If there is no response within the specified time, the process is repeated for the specified number of times (for example, twice) for one address, and an attempt is made for all the addresses acquired in step S50. Even if the request is sent to all the addresses obtained by name resolution, the trial is stopped when the response is received.

Next, the transmission / reception process will be described step by step. In step S60 of FIG. 5, it is determined whether or not there is an address that has not yet been focused on in the address list of the communication partner acquired in step S50. That is, in step S60, the index pointing to the address is incremented from the beginning of the address list, and it is determined whether or not the address exists there. If there is an unfocused address, it is determined that there is an address that can be acquired next. If the end of the address list has already been reached, the process of step S60 is determined as No, and the process ends because no further processing can be continued. In the case where the judgment of the first step S60 is No, the response cannot be returned within the specified time when the name of the printer to communicate with is not registered in the DNS server and the printer is in the power off state or offline state. It is possible that there is a case. If the following address exists, that address is used as the address of interest. At this time, the counter that counts the number of transmissions is returned to the initial value, for example, 0. Then, the process proceeds to step S61, and it is determined whether or not the predetermined number of times of attempting transmission for each address has been exceeded. That is, when the counter value exceeds the predetermined number of times, the process proceeds to step S60 and an attempt is made to acquire the next address.

If No in step S61, the process of transmitting request data is performed in step S62. Step S61 is a process executed by the request transmission unit 302 of the transport unit 30. In step S61, the request data received from the access logic unit 20 is transmitted to the address of interest in step S60.

In the following step S63, the response is waited for a predetermined response waiting time (for example, 5 seconds). This waiting time is defined by taking into account the time required for awakening and the time required for responding after awakening when the printer is in the sleep state.

Step S64 attempts to receive response data from the printer. Specifically, the received data acquisition function provided by the protocol stack attached to the OS is called to check whether the data has arrived.

In step S65, it is determined whether or not the received data has been received based on the result of step S64. If the determination is No, the process proceeds to step S67, the number of transmissions is increased by 1, and the process proceeds to step S61. On the other hand, if Yes in step S65, it is highly possible that the response corresponding to the request sent from the printer was received. Therefore, if Yes in step S65, it is determined that the response corresponding to the request has been received. In step S66, the received data is created as information to be passed to the access logic unit 20 which is the transmission request source. This information includes, for example, the received response data and the address of the printer that sent the response data.

Next, the communication partner address registration process of FIG. 6B will be described. This process is executed in step S30 of FIG. 4A by calling the name-address association function of the name resolution unit 301 of the transport unit 30 by the access logic unit 20. In the communication partner address registration process shown in Fig. 6 (B), a set of printer FQDN and address is given as input. In step S71, the FQDN and the address are associated and stored. Communication destination name-The FQDN and address stored in the address-related storage unit 304 are referred to as an address cache. Therefore, it is desirable to delete cache records (FQDN / address pair) whose non-reference time exceeds a certain period of time. This is because the address may have been changed and the storage capacity is finite. It is also desirable to delete the record when a request is sent to the cached address and there is no response. The registered address is the destination address of the request data for which a legitimate response is returned. In addition, for example, it may be the source address of a legitimate response.

By associating the destination name (FQDN) with the identification information (request ID) added to the packet by the above procedure, it is possible to identify that the received response is the response corresponding to the transmitted request. Therefore, it is possible to realize a filtering process that discards responses other than the identified response.

Furthermore, IPv4 and IPv6 addresses can be acquired once, and the number of name resolutions and the required time can be reduced.

In addition, by caching the addresses that have succeeded in communication in association with the destination name (FQDN), the number of packet transmission attempts can be reduced even when multiple addresses are registered in the IPv6 DNS server. Can be done. This can reduce network traffic.

Although the present embodiment has been described by taking the case where the printer driver transmits print data, that is, request data to the printer as an example, it can be applied to general data transmission. That is, the invention according to the present embodiment can be applied to other application programs and system programs instead of the printer driver 10. In that case, the access logic unit 20 and the transport logic unit 30 function in the same manner as in the present embodiment for an alternative application or system program.

Further, in the present embodiment, the access logic unit 20 and the transport logic unit 30 have been described as being included in the printer driver. However, the access logic unit 20 and the transport logic unit 30 may be outside the printer driver and may be called by an appropriate interface such as a function call between the driver logic unit 40 and the driver logic unit 40. With such a configuration, the access logic unit 20 and the transport logic unit 30 can be used by describing the interface between the access logic unit 20 and the transport logic unit 30 in a desired program.

Further, the ID included in the request packet, that is, the transmission data is a code generated cyclically in the present embodiment, but any code that can uniquely identify the packet, such as a time or a combination of a source address and a time, may be used.

Further, in the present embodiment, when the request data having the same request ID as the response data is stored, only the ID is used as the identification information and it is determined as a normal response. However, if the contents of the data are further collated and the fields having a value common to the corresponding request and the response, such as the command shown in FIG. 7, are collated and match, it may be determined as a normal response. .. That is, in this case, in addition to the ID, the common field of the request and the response is used as the identification information to determine that the response is normal.

The present invention may be applied to a system composed of a plurality of devices (for example, a host computer, an interface device, a reader, a printer, etc.) or a device composed of one device (for example, a copying machine, a facsimile machine, etc.). You may.

Each process of the present invention can also be realized by executing software (program) acquired via a network or various storage media on a processing device (CPU, processor) such as a personal computer.