JP2006019802A - Http communication device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To enable to easily perform data transfer using HTTP in an environment where transfer size of proxy is restricted. <P>SOLUTION: A communication device having a function of transferring the data using an HTTP protocol is provided with a deciding means for deciding the size of dividing the transmission data, a means for dividing the transmission data into a plurality of HTTP packets, and a means for adding data numbers to the divided data and transmitting the data. The device divides the data into the size within the maximum transfers size and transfer the data to a server, and the server performs processing of collecting the dividedly received data into a single file. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a mass data communication method in HTTP data communication.

A method of transferring data using the HTTP protocol as a transport is currently used for various purposes and has become common. Under such an environment, it is also possible to communicate large data such as image data and print data using HTTP. Further, as an advantage of performing data transfer using HTTP, there is an advantage that communication can be performed beyond the proxy.
JP 2002-287931 A

  However, in recent years, with increasing interest in security, it has become possible to set an upper limit of the HTTP data transfer size once by setting the proxy. For example, when data is transferred from the office to a server on the Internet through a proxy, the data is transferred using the POST processing of the HTTP protocol. In order to prevent information leakage in the office, HTTP through the proxy is used. In the POST process, there is a case in which a maximum transfer size of 40 Mbytes is limited to one POST process, and settings are made so that a large amount of data is not transferred from the office to the Internet.

  On the other hand, there is also a service that registers electronic documents and electronic image data in the office with a storage service on the Internet. In a proxy environment with such size restrictions, the user is aware of the upper limit of the transfer size, When the upper limit is exceeded, there is a problem that transmission data must be divided into two or more files.

  The present invention has been made in view of the above problems. When the user sets the maximum transfer size of the proxy in the device, the device divides the data into the maximum transfer size and transfers it to the server. The purpose is to provide an environment in which data transfer using HTTP can be easily performed even in an environment in which the proxy is limited in transfer size by performing a process of consolidating the received data into one file. .

  Therefore, the present invention has the following features.

  In a communication apparatus having a function of transferring data using the HTTP protocol, a determination unit that determines a division size of transmission data, a unit that divides transmission data into a plurality of HTTP packets at the division size, and data in the divided data A communication client having an HTTP data transmission means, wherein the data is divided and transmitted when data is transmitted to a server.

  In addition, in a communication device having a function of transferring data using the HTTP protocol, a communication device having means for receiving data divided into a plurality of HTTP packets and means for handling the divided data as combined data server.

  The means for determining the division size according to claim 1 inputs the size from the user interface of the communication apparatus.

  The means for determining the division size according to claim 1 is designated from the server to which the communication apparatus is connected.

The communication client according to claim 1, wherein the means for determining the division size according to claim 1 acquires the size from a user interface of the communication device when the size cannot be acquired from a server to which the communication device is connected. And a communication server described in claim 2.

  The device divides the data within the maximum transfer size and transfers it to the server. At the same time, the server performs processing to consolidate the divided received data into one file. However, data transfer using HTTP can be easily performed.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

  FIG. 1 is a schematic diagram in which a multifunction device having a network connection function is connected to a LAN as an HTTP client device and an HTTP server device according to the present embodiment.

  Reference numeral 101 denotes a multi-function device capable of HTTP communication. In this embodiment, a device that transfers a scanned image by HTTP communication. Reference numeral 102 denotes a firewall. 101 multifunction devices are located in an office protected by 102 firewalls. A multi-function device 103 on the Internet has a print function.

  In this embodiment, the scanner data read by the device 101 is printed out to the device 103 from the device 101 via the firewall 102 to the device 103 connected on the Internet.

  FIG. 2 is a block diagram showing an outline of the multifunction device apparatuses 101 and 103 in this embodiment.

  201 is a scanner engine control unit that controls the scanner engine 213, 202 is a CP, 203 is a bootable ROM that can be programmed, 204 is a RAM, and 205 is a non-volatile storage for holding values set from the panel RAM (NVRAM), 206 is an engine control unit that controls the printer engine 212, 207 is an HDD, 208 is a timer, 209 is an I / O control unit that controls a user interface part 214 such as a panel or button lamp, and 210 is a network control unit Each is connected to the bus 211.

  FIG. 3 shows a user interface portion owned by the devices 101 and 103 in this embodiment.

  Reference numeral 301 denotes a large touch panel, and the user can perform various settings by operating the touch panel. The screen shown in the figure is a copy standby screen. A numeric keypad 302 is used to enter numbers from 1 to 0. The S button is a service button. When this button is pressed, various service screens appear on the touch panel, and services other than copying can be performed. The R button is a setting button. When this button is pressed, various setting screens appear on the touch panel, and parameters can be set. Reference numeral 303 denotes a speaker which outputs voice, buzzer, and the like. A lamp 304 blinks when printing or copying is jammed.

  FIG. 4 is a block diagram of a module configuration for performing control around the network of 101 devices.

  Reference numeral 401 denotes a driver module for connecting to the office LAN with an Ethernet driver and transmitting and receiving Ethernet (registered trademark) packets. Reference numeral 402 denotes a TCP / IP protocol stack. The device of the present invention supports a multi-protocol and can communicate with a protocol such as NetWare or AppleTalk, but the description is omitted here. Reference numeral 403 denotes a socket layer. An API for using the TCP / IP protocol is defined. All programs that communicate using TCP / IP communicate using the API provided by the socket layer. Reference numeral 404 denotes an HTTP PC module, which has an HTTP processing function, and communicates with the other party using the HTTP protocol. Reference numeral 405 denotes a SOAP module, and reference numeral 406 denotes a scanner service module which is a module for realizing a scan To print service using SOAP / XML. In the device 101, the scan service 406 transfers an image scanned from the scanner engine 213 to the print device 101 using the SOAP module 405 and the HTTP client module 404 in response to an input instruction from the panel.

  FIG. 5 shows a block diagram of a module configuration for performing control around the network of 103 devices.

  Reference numeral 501 denotes a driver module for connecting to the Internet with an Ethernet driver and transmitting and receiving Ethernet (registered trademark) packets. Reference numeral 502 denotes a TCP / IP protocol stack. The device of the present invention supports a multi-protocol and can communicate with a protocol such as NetWare or AppleTalk, but the description is omitted here. Reference numeral 503 denotes a socket layer. An API for using the TCP / IP protocol is defined. All programs that communicate using TCP / IP communicate using the API provided by the socket layer. Reference numeral 504 denotes an HTTP server module, which has an HTTP processing function and communicates with a partner using the HTTP protocol. Reference numeral 505 denotes a SOAP module, and reference numeral 506 denotes a print service module, which is a module for realizing a scan to print service using SOAP / XML. The device 103 extracts print data from the HTTP data using SOAP / XML received from the scanner device 101, and sends the print data to the printer engine 212 via the engine control 206 for printing.

  FIG. 6 is an example of packet data called “CreateJob” transmitted from the client to the printing apparatus in the SOAP print service protocol on HTTP in the present embodiment. This data is described in the XML format. The CreateJob packet is a command for instructing the printing apparatus to start a job (printing), and includes a request source user name (<requesting-user-name> tag) and an instruction relating to job processing (<job-instruction> tag). ) Etc. are described. The <job-instruction> tag includes a <copy> tag for setting the number of copies to be printed, a <sides> tag for setting double-sided printing, a <finishing> tag for setting print finishing, and the like. The job is processed based on the set value. Further, the <job-instruction> tag can optionally include a <notification-instruction> tag. In this <notification-instruction> tag, notification information about the job is described. In the example of FIG. 6, a <notification-recipient> tag for setting a notification destination and an <event> tag for setting a notification condition are described as notification information. The printing apparatus performs event transmission processing based on the values set in these tags. In this embodiment, since job-completed and job- canceled are specified, an event is notified when job printing ends and when the job is canceled.

  FIG. 7 is an example of response packet data for the CreateJob packet in FIG.

  This data is also described in the XML format as in FIG. 6, and is transmitted and received using SOAP on HTTP in this embodiment. The CreateJob response packet includes a result code (<result-code> tag) for the CreateJob command, an identifier of the generated job (<job-id> tag), and a URI for the print port (<data-sink-uri> tag). Etc. are included. A portion indicated by reference numeral 701 in FIG. 7 is a portion indicating the URI of the print port. In the example of FIG. 7, a URI “http://192.168.1.4/job001” is shown.

  FIG. 8 is a flowchart illustrating the operation of the printing apparatus according to the present exemplary embodiment when data is transferred from the scan device 101 to the print device 103.

  Hereinafter, the operation of the print device 103 according to the present exemplary embodiment will be described with reference to FIG.

  When the CreateJob packet as shown in FIG. 6 is transmitted from the scanner device 101 to the printing apparatus, the printing apparatus analyzes the XML data described in CreateJob in S801, and proceeds to S802 to determine whether there is an error in the analysis result. To do. If there is no error, a print port for receiving print data is generated in S803. When the process of S803 is completed, the process proceeds to S804, and XML data for a response to the CreateJob packet is generated. At this time, the URI of the port generated for receiving print data is set as the value of the <data-sink-uri> tag. A URI such as 701 is embedded in the XML data. When the creation of CreateJob response data is completed, the process advances to step S806, and the data is transmitted to the scanner device 101 using SOAP. Thereafter, the scanner device 101 transmits print data to the URI specified by the <data-sink-uri> tag using the HTTP POST method. FIG. 9 shows an example of a print data transfer packet by the HTTP POST method. In step S807, the printing apparatus receives the data arriving at the print port, and prints it on the printer while performing appropriate processing. In S807, when the reception of the print data ends normally, the printing apparatus transmits an HTTP response packet like the example shown in FIG. 10 to the scanner device 101 in S808, deletes (closes) the print port, and performs the printing operation. finish. On the other hand, if it is determined in S802 that there is an error in the XML data described in CreateJob, the process proceeds to S804, and error response data is generated. FIG. 11 shows an example of an error response. Next, when an error response is transmitted to the scanner device 101 in step S806, the scanner device 101 does not transmit print data and ends the process.

  FIG. 12 shows details of the POST processing shown in FIG.

  Normally, as shown in FIG. 8, data is transferred to the other party in one HTTP POST process, and the printing apparatus receives it and returns a response.

  In the present invention, the HTTP POST process is performed a plurality of times as shown in FIG. Therefore, as shown in 901, a sequence number is registered as an x-Sequence-Number in the HTTP header portion, and a plurality of HTTP POST processes are performed. At the very end of the POST process, x-Sequence-Number: last indicates that the POST process is the last POST process.

  FIG. 13 is a screen showing the maximum transfer size of HTTP displayed on the local interface of the device 101.

  The user can input the maximum transfer size using the numeric keypad 302.

  This maximum transfer size is referred to by the HTTP client module 404, and the HTTP POST processing is divided so as to be within the size.

  FIG. 14 is an example of a sequence for acquiring proxy information from the proxy 102 when the scanner device 101 accesses the proxy 102.

  Based on the IP address of the connection destination, the scanner device determines whether the connection to the IP needs to be connected through a proxy or is connected directly. When connecting via a proxy, first, the maximum transfer size information is acquired from the proxy. The HTTP client module 404 refers to the maximum transfer size to which the proxy has responded, and divides the HTTP POST processing so as to be within the size.

  FIG. 15 is a flowchart showing a flow of processing for acquiring transfer size information from the proxy server at the time of proxy connection.

  FIG. 16 is a flowchart showing the flow of processing when data is transmitted by the HTTP client module.

  FIG. 17 is a flowchart showing the flow of processing when data is received by the HTTP server module.

  The processing flow of the present invention will be described below with reference to the drawings.

  A process flow of the HTTP client module 404 of the device 101 will be described.

  The scan service module 406 of the device 101 reads an image set by the user from the scanner engine 213 via the scanner control 201 when the user instructs to scan and transmit data to another printer. The read image is transferred to the HTTP client module 404. The scanner service 406 designates a destination designated by the user and instructs the HTTP client module 404 to transfer data. The HTTP client module 404 is transferred to the print device 103 by a control method using SOAP / XML.

  When receiving an instruction for a transfer destination from the scanner service module, the HTTP client module 404 determines whether the transfer destination is transferred via the proxy 102 or can be directly connected to the device (not shown). The processing when data is transferred via the proxy 102 will be described with reference to FIG.

  When connecting to the device 103 via the proxy 102, first, the HTTP client module 404 acquires the maximum transfer size from the proxy 102 (S1501). The exchange of packets between the device 101 and the proxy 102 at this time is a sequence as shown in FIG. In FIG. 14, the proxy server 102 requests acquisition of x-PROXY-MAX-TransferSize by HTTP GET, and the proxy server 102 returns x-PROXY-MAX-TransferSize: 40 Mbytes as HTTP OK. In this example, it can be seen that the maximum size of one POST process of the proxy server 102 is 40 Mbytes. If the maximum size of one POST process can be acquired from the proxy server 102 in S1502, the maximum size is stored in the RAM 204 as MAX-TRANSFER-SIZE (S1504). If the proxy server 102 does not return a response in S1502, the proxy server 102 acquires it from the panel in S1503 (S1503). Then, this value is held on the RAM 204 in S1504. The input from the panel is input in advance from the screen shown in FIG. In FIG. 13, 40 Mbytes are input.

  In this embodiment, the maximum transfer size for one POST process is 40 Mbytes.

  Next, the flow of actual transfer processing will be described with reference to FIG.

  The scanner service 406 transfers the data to the HTTP client module 404 when the data scan is completed, and the HTTP client module 404 transfers the data to the device 103 using HTTP and SOAP / XML.

  The sequence of transferring data is as shown in FIG. In the present embodiment, if the scanned data is within 40 Mbytes, HTTP POST is performed only once as shown in FIG. In the case of 40 Mbytes or more, the transfer size of one POST is set to a maximum of 40 Mbytes, and the transfer is performed a plurality of times as illustrated in FIG.

  Now, the flow of the plurality of transfer processes will be described with reference to FIG. After receiving the CreateJob response, the HTTP client module 404 transfers the data of the scanner service 406 by HTTP to the specified URL. First, x-Sequence-Number = 1 is set (S1601), and then, from the MAX-TRANSFER-SIZE (40 Mbytes in this embodiment), the total transfer size designated by the scan service is previously stored in the RAM 204. It is determined whether it is larger (S1603). If it is determined in S1603 that it is large, the transfer size (Content-length) of one POST is set to MAX-TRANSFER-SIZE (40 Mbytes) (S1603). Subsequently, a POST process corresponding to the size is executed (S1604). The HTTP client module 404 waits for an HTTP response from the device 103 (S1605). After receiving the response, the transfer size actually transferred is subtracted from the total transfer size (S1606). After subtraction, it is determined whether the total transfer size is 0 (S1607). If it is not 0, there is still data to be transferred, so 1 is added to x-Sequence-Number (S1608), and the process returns to S1602.

  If the total transfer size is smaller than the MAX-TRANSFER-SIZE in S1602, the POST process ends when it is sent. Therefore, the POST transfer size (Content-length) is set as the total transfer size, and the x-Sequence-Number is set. Is set to Last (S1609). In step S1604, a POST process is executed.

  In this manner, the data transfer is completed until the total transfer size becomes 0 in S1607. The sequence on the network at this time is as shown in FIG.

  Next, the flow of processing on the printer device side 103 will be described. A processing flow of the HTTP server module 504 of the printer device 103 will be described. After returning the Data-Sink-URI as shown in FIG. 8, the device 101 transfers the scan data using the HTTP POST process. The HTTP server module 504 is waiting for data reception in S1701. When data is received from the device 101, x-Sequence-Number is acquired from the HTTP header (S1702). Subsequently, the Body part (actual data) of the HTTP is transferred to the print process, and the print process is performed (S1703). In step S1704, it is determined whether data corresponding to HTTP Content-length has been received. If it has not been received yet, data is waited in S1707, and the received data is transferred to the print module (S1708). When the content-length data is received in S1704, an HTTP response 200OK is returned to the device 101 in S1705. After the return, it is determined whether the x-sequence-number acquired in S1702 is Last (S1706). If it is not Last, there is data continuously, so that data reception waits in S1701. If it is Last, all the data has been received, and the process ends.

  In this embodiment, the HTTP POST transfer size can be given as Content-length, but the same can be realized by using HTTP chunk processing.

  Further, in an environment where there is no proxy, the same can be realized even in an environment where the maximum transfer size is limited by the router.

1 is a schematic diagram in which a multifunction device having a network connection function is connected to a LAN as a network device apparatus according to an embodiment. FIG. 1 is a block diagram illustrating an outline of a multifunction device according to an embodiment. User interface part owned by this device. The block diagram of the module structure of the device 101 in a present Example. The block diagram of the module structure of the device 103 in a present Example. An example of packet data called CreateJob transmitted from a client to a printing apparatus in the protocol of the SOAP print service on HTTP in the present embodiment. An example of response packet data for the CreateJob packet in FIG. 6 is a flowchart illustrating an operation of the printing apparatus according to the present exemplary embodiment when the client performs printing. An example of the print data transfer packet by the HTTP POST method. An example of an HTTP response packet. An example of an error response. Example of a sequence in which the HTTP POST method is divided and sent Example of a panel for entering the maximum transfer size Example sequence for obtaining the maximum transfer size from a proxy server Flowchart for obtaining the maximum transfer size from the proxy server Flowchart showing the flow of processing of the HTTP client module The flowchart which shows the flow of a process of an HTTP server module

Claims (6)

In a communication device having a function of transferring data using the HTTP protocol,
A determination means for determining a division size of transmission data;
Means for dividing the transmission data into a plurality of HTTP packets at the division size;
Means for adding a data number to the divided data and transmitting the data;
Have
A communication client characterized by having HTTP data transmitting means characterized by dividing and transmitting data when transmitting data to a server. In a communication device having a function of transferring data using the HTTP protocol,
Means for receiving data divided into a plurality of HTTP packets;
A means of handling the received data as a collection of data;
A communication server comprising:   2. The communication apparatus according to claim 1, wherein the means for determining the division size inputs a size from a user interface of the communication apparatus.   2. The communication apparatus according to claim 1, wherein the means for determining the division size is designated from a server to which the communication apparatus is connected.   2. The communication apparatus according to claim 1, wherein the means for determining the division size acquires the size from a user interface of the communication apparatus when the size cannot be acquired from a server to which the communication apparatus is connected.   A communication system comprising a communication client described in claim 1 and a communication server described in claim 2.

Images