JP2011044823A - Communication equipment, communication system, communication method and communication program - Google Patents
Communication equipment, communication system, communication method and communication program Download PDFInfo
- Publication number
- JP2011044823A JP2011044823A JP2009190429A JP2009190429A JP2011044823A JP 2011044823 A JP2011044823 A JP 2011044823A JP 2009190429 A JP2009190429 A JP 2009190429A JP 2009190429 A JP2009190429 A JP 2009190429A JP 2011044823 A JP2011044823 A JP 2011044823A
- Authority
- JP
- Japan
- Prior art keywords
- processing
- block
- data
- request
- communication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000006854 communication Effects 0.000 title claims abstract description 124
- 238000004891 communication Methods 0.000 title claims abstract description 118
- 238000000034 method Methods 0.000 title claims description 67
- 238000012545 processing Methods 0.000 claims abstract description 413
- 230000005540 biological transmission Effects 0.000 claims description 26
- 230000008569 process Effects 0.000 claims description 25
- 238000012790 confirmation Methods 0.000 claims description 24
- 238000004364 calculation method Methods 0.000 claims description 2
- 238000005516 engineering process Methods 0.000 abstract description 2
- 238000009825 accumulation Methods 0.000 abstract 1
- 230000006870 function Effects 0.000 description 47
- 238000007726 management method Methods 0.000 description 34
- 238000010586 diagram Methods 0.000 description 21
- 238000013500 data storage Methods 0.000 description 17
- 238000012986 modification Methods 0.000 description 11
- 230000004048 modification Effects 0.000 description 11
- 239000000470 constituent Substances 0.000 description 3
- 238000007405 data analysis Methods 0.000 description 3
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 238000007796 conventional method Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Landscapes
- Detection And Prevention Of Errors In Transmission (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Description
本発明は、通信装置、通信システム、通信方法及び通信プログラムに関する。 The present invention relates to a communication device, a communication system, a communication method, and a communication program.
例えば、文字を認識したりバーコードを認識したりする画像処理は大量の計算を必要とするため、一般にCPU（Central Processing Unit）の処理能力を必要とする。CPUなどのコンピュータの処理能力が飛躍的に増大する現在においても、これらの画像処理の処理時間は無視できるほど小さな時間とはなっていない。大量の計算を短時間で行うために有効な方法の一つは、処理単位を小さく分割して、多数のコンピュータで分散処理させることである。具体的には、例えば、クライアントからの処理要求を受け付ける受付サーバＳ１と、処理対象の画像を記憶するストレージサーバＳ２と、複数の処理サーバＷ１〜Ｗｎとがネットワークを介して接続される分散処理システムがある。受付サーバＳ１は、外部から処理対象の画像データをストレージサーバＳ２に取り込み、受付サーバＳ１は、各処理サーバＷ１〜Ｗｎに対して当該画像データの各々異なる部分に対する処理を要求する処理要求を送信する。各処理サーバＷ１〜Ｗｎはそれぞれ、当該処理要求に従って、ストレージサーバＳ２にアクセスし、画像データを読み込んで処理を実行し、処理結果をレスポンスとして受付サーバＳ１に返す。受付サーバＳ１は、各処理サーバＷ１〜Ｗｎからの処理結果が全て得られた段階で、処理結果をクライアントに返す。このような分散システムでは、ストレージサーバＳ２がボトルネックとなりやすい。即ち、処理要求を受信した処理サーバＷ１〜Ｗｎが個別にストレージサーバＳ２から画像データを取得する時、ネットワークへの負荷が大きくなる。また、ストレージサーバＳ２が故障するとこの分散システム全体が動作不能となる恐れがある。 For example, image processing for recognizing characters or recognizing barcodes requires a large amount of calculation, and therefore generally requires processing capability of a CPU (Central Processing Unit). Even at the present time when the processing power of computers such as CPUs has increased dramatically, the processing time of these image processing is not so small as to be negligible. One effective method for performing a large amount of computation in a short time is to divide a processing unit into small parts and perform distributed processing with a large number of computers. Specifically, for example, a distributed processing system in which a reception server S1 that receives a processing request from a client, a storage server S2 that stores a processing target image, and a plurality of processing servers W1 to Wn are connected via a network. There is. The reception server S1 takes in image data to be processed from the outside into the storage server S2, and the reception server S1 transmits a processing request for requesting processing to each different part of the image data to each of the processing servers W1 to Wn. . Each of the processing servers W1 to Wn accesses the storage server S2 according to the processing request, reads the image data, executes the processing, and returns the processing result as a response to the receiving server S1. The reception server S1 returns the processing results to the client when all the processing results from the processing servers W1 to Wn are obtained. In such a distributed system, the storage server S2 tends to be a bottleneck. That is, when the processing servers W1 to Wn that have received the processing request individually acquire image data from the storage server S2, the load on the network increases. Also, if the storage server S2 fails, the entire distributed system may become inoperable.
ところで、ネットワークを介して接続された一つの送信装置から複数の受信装置に対して同時にデータを送信する方法としては、UDP（User Datagram Protocol）マルチキャストを用いる方法が知られている。IPネットワークでデータ通信を行うプロトコルではTCP（Transmission Control Protocol）とUDPとが代表的であるが、TCPはコネクション型で送達確認を含む代わりに1対1の通信のみが可能であり、UDPはコネクションレス型で1対多の通信が可能な反面、送達確認の機能を持たない。そのためUDPによるマルチキャスト通信ではデータの欠損が問題となるため、アプリケーションレベルでのプロトコルで送達確認を実装することになる。例えば、すべての受信装置がデータの受信を確認するための送達確認を含むパケット（送達確認パケットという）を送信装置に送信し、送信装置からの送達確認を待って次のパケットを送信するか前のパケットを再送するという方法が考えられる。しかしこの方法では、送信装置への負担が大きくなり、またほとんどの受信装置にとって再送するパケットは無駄となる。 By the way, as a method of simultaneously transmitting data from a single transmission device connected via a network to a plurality of reception devices, a method using UDP (User Datagram Protocol) multicast is known. TCP (Transmission Control Protocol) and UDP are typical protocols for data communication over IP networks. However, TCP is connection-type and only one-to-one communication is possible instead of including delivery confirmation, and UDP is a connection. While it is possible to perform one-to-many communication with the less type, it does not have a delivery confirmation function. For this reason, data loss becomes a problem in multicast communication using UDP, so delivery confirmation is implemented using an application-level protocol. For example, a packet including a delivery confirmation for confirming the reception of data by all the receiving devices (referred to as a delivery confirmation packet) is transmitted to the transmitting device, and the next packet is transmitted after waiting for a delivery confirmation from the transmitting device. It is conceivable to retransmit the packet. However, with this method, the burden on the transmission apparatus becomes large, and packets to be retransmitted are wasted for most reception apparatuses.
近年では、マルチキャストによるデータ通信の効率化を目的とした方法も多く提案されている。しかし、従来の方法では、すべての受信装置に等しくすべてのデータが受信されることを目的としている。例えば、複数のページの画像を表す画像データに対する画像処理をページ毎にそれぞれ最低１つのコンピュータに行わせることを目的とすると、各コンピュータで必要とする画像データはほんの一部分であり、大半の部分の再送は無駄になるという問題があった。上述の分散システムにおいては、受付サーバＳ１で画像データを処理サーバ毎に個別の処理単位に分割することも考えられる。しかし、データ形式によっては分割が容易でなく、受付サーバＳ１が分割のために画像データを変換するなどの処理に時間を要するため、スケールアウトに適しない場合がある。また、例えば、特許文献１には、送達確認と再送とを効率化する目的で、ファイルをブロックに分割し、順序番号をつけて送信し、全体の送信が完了した後に受信装置からの順序番号による指定に基づいて受信できなかった部分を再送する仕組みが開示されている。
In recent years, many methods for improving the efficiency of data communication by multicast have been proposed. However, the conventional method aims to receive all data equally by all receiving apparatuses. For example, if it is intended to cause at least one computer to perform image processing on image data representing images of a plurality of pages for each page, the image data required for each computer is only a part, and most parts There was a problem that retransmission was wasted. In the above-described distributed system, it is conceivable that the receiving server S1 divides the image data into individual processing units for each processing server. However, division may not be easy depending on the data format, and it may not be suitable for scale-out because the reception server S1 requires time for processing such as converting image data for division. Further, for example, in
しかし、従来の技術では、全てのデータが全ての送信装置に到達しなくても良い場合にも、送達確認と再送とを効率化することは困難である。このため、このような場合にも、マルチキャストに基づく1対多の通信において、データの再送を必要最小限とし、より効率化することが望まれていた。 However, with the conventional technology, it is difficult to make delivery confirmation and retransmission more efficient even when all data does not have to reach all transmission apparatuses. For this reason, even in such a case, in one-to-many communication based on multicast, it has been desired to minimize data retransmission and improve efficiency.
本発明は、マルチキャストに基づく1対多の通信において、データの再送を必要最小限とし、より効率化することが可能な通信装置、通信システム、通信方法及び通信プログラムを提供することを目的とする。 An object of the present invention is to provide a communication device, a communication system, a communication method, and a communication program that can minimize data retransmission and improve efficiency in one-to-many communication based on multicast. .
上述した課題を解決し、目的を達成するために、本発明は、通信装置であって、複数のブロックに分割されたデータの一部に対する処理を要求する処理要求を、送達確認のある第１の通信方式で他の通信装置から受信する第１受信手段と、前記データを、送達確認のない第２の通信方式で前記他の通信装置から受信する第２受信手段と、前記処理要求に従って、前記データの一部に対して、前記処理を実行する処理手段と、前記処理手段が前記処理を実行する際に、前記データの一部に該当する前記ブロックの受信が正常に完了していない場合、当該ブロックの再送を要求する再送要求を前記他の通信装置に送信する再送要求手段と、前記再送要求手段が送信した前記再送要求に従って前記他の通信装置から送信された前記ブロックを受信する第３受信手段と、前記処理手段が前記処理を実行した結果を、前記第１の通信方式で前記他の通信装置に送信する送信手段とを備えることを特徴とする。 In order to solve the above-described problems and achieve the object, the present invention is a communication apparatus, which is a communication device that has a delivery confirmation request for a process request for processing a part of data divided into a plurality of blocks. In accordance with the processing request, the first receiving means for receiving from the other communication device in the communication method, the second receiving means for receiving the data from the other communication device in the second communication method without delivery confirmation, A processing unit that executes the process on a part of the data, and the reception of the block corresponding to the part of the data is not normally completed when the processing unit executes the process. A retransmission request means for transmitting a retransmission request for requesting retransmission of the block to the other communication apparatus; and receiving the block transmitted from the other communication apparatus in accordance with the retransmission request transmitted by the retransmission request means. A third receiving means, the result of said processing means executes the processing, characterized by comprising a transmitting means for transmitting to the other communication device in the first communication method.
また、本発明は、第１受信手段と、第２受信手段と、処理手段と、再送要求手段と、第３受信手段と、送信手段とを備える通信装置で実行される通信方法であって、前記第１受信手段が、複数のブロックに分割されたデータの一部に対する処理を要求する処理要求を、送達確認のある第１の通信方式で他の通信装置から受信する第１受信ステップと、前記第２受信手段が、前記データを、送達確認のない第２の通信方式で前記他の通信装置から受信する第２受信ステップと、前記処理手段が、前記処理要求に従って、前記データの一部に対して、前記処理を実行する処理ステップと、前記再送要求手段が、前記処理ステップで前記処理が実行される際に、前記データの一部に該当する前記ブロックの受信が正常に完了していない場合、当該ブロックの再送を要求する再送要求を前記他の通信装置に送信する再送要求ステップと、第３受信手段が、前記再送要求ステップで送信された前記再送要求に従って前記他の通信装置から送信された前記ブロックを受信する第３受信ステップと、前記送信手段が、前記処理ステップで前記処理が実行された結果を、前記第１の通信方式で前記他の通信装置に送信する送信ステップとを含むことを特徴とする。 Further, the present invention is a communication method executed by a communication apparatus including a first receiving unit, a second receiving unit, a processing unit, a retransmission request unit, a third receiving unit, and a transmitting unit, A first receiving step in which the first receiving means receives a processing request for requesting processing of a part of data divided into a plurality of blocks from another communication device in a first communication method with delivery confirmation; A second receiving step in which the second receiving means receives the data from the other communication device in a second communication method without delivery confirmation; and the processing means is configured to receive a part of the data according to the processing request. On the other hand, when the processing step for executing the processing and the retransmission request means execute the processing in the processing step, reception of the block corresponding to a part of the data has been normally completed. If not, A retransmission request step for transmitting a retransmission request for requesting retransmission of a packet to the other communication device, and a third receiving means transmitted from the other communication device according to the retransmission request transmitted in the retransmission request step. A third reception step of receiving the block; and a transmission step of transmitting the result of the execution of the processing by the processing step to the other communication device by the first communication method. It is characterized by.
また、本発明は、上記の通信方法をコンピュータに実行させるためのプログラムである。 Moreover, this invention is a program for making a computer perform said communication method.
本発明によれば、マルチキャストに基づく1対多の通信において、データの再送を必要最小限とし、より効率化することが可能になる。 According to the present invention, in one-to-many communication based on multicast, it is possible to minimize data retransmission and improve efficiency.
以下に添付図面を参照して、この発明にかかる通信装置、通信システム、通信方法及び通信プログラムの実施の形態を詳細に説明する。 Exemplary embodiments of a communication device, a communication system, a communication method, and a communication program according to the present invention will be described below in detail with reference to the accompanying drawings.
図１は、本実施の形態にかかる通信システムの構成を例示する図である。通信システムは、クライアント１００と、受付サーバ２００と、複数の処理サーバ３００とを備える。クライアント１００と受付サーバ２００とはネットワークＮＴ１を介して接続される。受付サーバ２００と複数の処理サーバ３００とはネットワークＮＴ２を介して接続される。ネットワークＮＴ１，ＮＴ２は、例えば、ＬＡＮ（Local Area Network）、イントラネット、又はインターネットなどである。
FIG. 1 is a diagram illustrating a configuration of a communication system according to the present embodiment. The communication system includes a client 100, a
このような通信システムにおいて、クライアント１００が、処理対象の画像データを含み当該画像データに対する処理を要求する処理要求を、ネットワークＮＴ１を介して受付サーバ２００に送信し、受付サーバ２００が、当該処理要求に従って、ネットワークＮＴ２を介して各処理サーバ３００に当該処理要求を各々送信する。各処理サーバ３００は当該処理要求に従って、処理を実行し、その処理結果をネットワークＮＴ２を介して受付サーバ２００に送信する。受付サーバ２００は、各処理サーバ３００から受信した処理結果をネットワークＮＴ１を介してクライアント１００に送信する。
In such a communication system, the client 100 transmits a processing request that includes image data to be processed and requests processing on the image data to the
次に、本実施の形態にかかるクライアント１００、受付サーバ２００及び処理サーバ３００のハードウェア構成について説明する。クライアント１００、受付サーバ２００及び処理サーバ３００はそれぞれ、装置全体を制御するＣＰＵ等の制御部と、各種データや各種プログラムを記憶するＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）等の主記憶部と、各種データや各種プログラムを記憶するＨＤＤ（Hard Disk Drive）やＣＤ（Compact Disk）ドライブ装置等の補助記憶部と、これらを接続するバスとを備えており、通常のコンピュータを利用したハードウェア構成となっている。また、クライアント１００には、情報を表示する表示部と、ユーザの指示入力を受け付けるキーボードやマウス等の操作入力部と、外部装置の通信を制御する通信Ｉ／Ｆ（interface）とが有線又は無線により各々接続される。これらは、クライアント１００と同様に受付サーバ２００及び処理サーバ３００に接続されるようにしても良いし、接続されなくても良い。
Next, the hardware configuration of the client 100, the
次に、このようなハードウェア構成において、受付サーバ２００のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図２は、受付サーバ２００の機能的構成を例示する図である。受付サーバ２００は、HTTPサーバ部２０１と、画像処理制御部２０２と、画像蓄積部２０３とを有する。HTTPサーバ部２０１と、画像処理制御部２０２とは、ＣＰＵのプログラム実行時にＲＡＭなどの主記憶部上に生成されるものである。画像蓄積部２０３は、ＨＤＤなどの補助記憶部に構成されるものである。
Next, in such a hardware configuration, various functions realized by the CPU of the
HTTPサーバ部２０１は、クライアント１００からの処理要求を受け付ける。この機能を細分化した機能として、HTTPサーバ部２０１は、リクエスト処理部２０４と、再送要求処理部２０５とを有する。リクエスト処理部２０４は、処理対象の画像データを含み当該画像データに対する画像処理を要求する処理要求をクライアント１００から受信し、当該処理要求に従った処理結果を当該クライアント１００に送信する。尚、クライアント１００からの処理要求は、例えば、HTTPのプロトコルに従ったHTTPリクエストにより送信される。HTTPのプロトコルに従った通信では、送達確認がある。再送要求処理部２０５は、後述するブロックの再送を要求する再送要求を処理サーバ３００から受信し、要求されたブロックを処理サーバ３００に送信する。尚、要求されたブロックの送信は、TCPによるコネクション型通信で行う。TCPによるコネクション型通信では、送達確認がある。
The
画像処理制御部２０２は、処理要求や処理対象の画像データの処理サーバ３００への送信、処理サーバ３００からの処理結果の取得及び処理対象の画像データを分割したブロックに関する後述のブロック情報の管理を行う。この機能を細分化した機能として、画像処理制御部２０２は、処理要求部２０６と、データ分割部２０７と、データブロック管理部２０８と、データ送信部２０９と、処理結果管理部２１０とを有する。
The image
処理要求部２０６は、後述のブロック情報を含み処理対象の画像データに対する画像処理を要求する処理要求を各処理サーバ３００に送信し、当該処理要求に従って各処理サーバ３００が処理を実行した結果である処理結果を各処理サーバ３００から受信する。尚、処理要求の送信は、TCPによるコネクション型通信で行う。
The
データ分割部２０７は、処理対象の画像データを複数のブロックに分割する。データブロック管理部２０８は、データ分割部２０７が分割した各ブロックについて、処理対象の画像データにおける各ブロックの位置を特定するためのブロック情報を記憶し、これの削除やアクセスを制御することによって、ブロック情報を管理する。本実施の形態においては、ブロックの長さは固定長であるとし、ブロック情報は、ブロックの長さとブロックの開始点（オフセット）とを含む。
The
データ送信部２０９は、データ分割部２０７が処理対象の画像データから分割した複数のブロックをパケット単位で各処理サーバ３００に送信する。各パケットの送信は、UDPのマルチキャストにより行なう。UDPのマルチキャストでは、送達確認がない。尚、各処理サーバ３００のマルチキャストアドレス及び宛先ポートは主記憶部や補助記憶部に予め記憶されているものとする。
The
処理結果管理部２１０は、処理要求部２０６が各処理サーバ３００から受信した処理結果を記憶し、当該処理結果の受信状況に応じて、処理の終了を判断する。具体的には、処理結果管理部２１０は、処理要求部２０６が処理要求を送信した全ての処理サーバ３００から処理結果を受信した場合には、処理が終了したと判断する。そして、この場合、処理結果管理部２１０は、処理サーバ３００から受信した処理結果をクライアント１００に送信する。尚、処理結果の送信は、TCPによるコネクション型通信で行う。画像蓄積部２０３は、リクエスト処理部２０４が受信した処理要求に含まれる処理対象の画像データを記憶する。
The processing
次に、処理サーバ３００のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図３は、処理サーバ３００の機能的構成を例示する図である。処理サーバ３００は、リクエスト処理部３０１と、データ受信処理部３０２と、データ蓄積部３０３と、画像処理部３０４とを有する。リクエスト処理部３０１は、処理要求を受付サーバ２００から受信したり、当該処理要求に従って画像処理部３０４が処理を実行した結果である処理結果を受付サーバ２００に送信したりする。
Next, various functions realized by the CPU of the
データ受信処理部３０２は、処理対象の画像データの受信に関わる処理を行う。この機能を細分化した機能として、データ受信処理部３０２は、データ受信部３０５と、受信完了判定部３０６と、再送要求部３０７とを有する。データ受信部３０５は、受付サーバ２００からマルチキャストで送信された処理対象の画像データをパケット単位で受信し、リクエスト処理部３０１が受信した処理要求に含まれるブロック情報を参照して、受信したパケットをブロック毎に分類し、各ブロックをデータ蓄積部３０３に記憶させる。受信完了判定部３０６は、各ブロックについて受信が正常に完了しているか否かを判定する。再送要求部３０７は、受信が正常に完了していないと受信完了判定部３０６が判定したブロックについてその再送を要求する再送要求を受付サーバ２００に送信し、当該再送要求に従って受付サーバ２００から送信されたブロックを含むパケットを受信する。
The data
データ蓄積部３０３は、受付サーバ２００から受信した処理対象の画像データをブロック毎に記憶する。この機能を細分化した機能として、データ蓄積部３０３は、ブロック管理部３０８と、データ格納部３０９とを有する。ブロック管理部３０８は、処理対象の画像データに属する各ブロックについて、その開始点と、受信が正常に完了しているか否かという受信完了判定部３０６の判定結果とを記憶する。例えば、ブロック管理部３０８は、各ブロックについての受信完了判定部３０６の判定結果を受信状態フラグによって記憶する。受信状態フラグは、受信が完了していると判定された場合は「1」を示し、受信が完了していないと判定された場合は「0」を示す。図４は、ブロック管理部３０８が記憶する情報を例示する図である。同図の例では、10個のブロックから構成される処理対象の画像データの各ブロックについての受信完了フラグ及び開始点が示されている。この例では、先頭からから3〜4番目及び10番目のブロックの受信が未完了であることが示されている。
The
また、ブロック管理部３０８は、画像処理部３０４が処理を実行する際に、処理対象の画像データに属する各ブロックうち処理対象のブロックについて、受信が正常に完了していると受信完了判定部３０６が判定している場合には、当該ブロックをデータ格納部３０９から読み出してこれを画像処理部３０４に渡す。一方、当該ブロックについて、受信が正常に完了していないと受信完了判定部３０６が判定している場合には、ブロック管理部３０８は、再送要求部３０７が送信した再送要求に従って受信したパケットに含まれるブロックを取得してこれを画像処理部３０４に渡す。データ格納部３０９は、処理対象の画像データをブロック単位で記憶する。
In addition, when the
画像処理部３０４は、処理対象の画像データに属する各ブロックのうち処理対象のブロックを、ブロック管理部３０８を介して取得して、当該ブロックを用いて、処理要求によって要求された処理（例えば画像処理である）を実行し、当該処理を実行した結果である処理結果をリクエスト処理部３０１に返す。
The
次に、本実施の形態にかかる通信システムにおいて行う通信処理の手順について説明する。まず、受付サーバ２００が行なう通信処理の手順について図５を用いて説明する。受付サーバ２００は、リクエスト処理部２０４の機能により、処理対象の画像データを含み当該画像データに対して処理を要求する処理要求をクライアント１００から受信する（ステップＳ１）。尚、当該処理要求には、処理の際に用いる処理パラメータを含み得る。次いで、受付サーバ２００は、ステップＳ１で受信した処理要求に含まれる処理対象の画像データを画像蓄積部２０３に記憶する。そして、受付サーバ２００は、データ分割部２０７の機能により、処理対象の画像データを複数のブロックに分割する（ステップＳ２）。
Next, a procedure of communication processing performed in the communication system according to the present embodiment will be described. First, the communication processing procedure performed by the
具体的には、受付サーバ２００は、処理対象の画像データを、予め定められた長さ（固定長）のブロックに分割し、各ブロックに対して先頭から順に「0」から始まるブロック番号を付与する。ところで、UDPにより送信する１つのパケットで送信可能なデータのサイズは60Kb程度である。一次ブロックはこのサイズを超えているため、受付サーバ２００は、UDPによる送信が可能なサイズのパケットに各ブロックを分割し、各パケットに対して先頭から順に「0」から始まるシーケンス番号を付与する。また、受付サーバ２００は、データブロック管理部２０８の機能により、各ブロックの開始点を算出し、各ブロックの開始点と各ブロックの長さと含むブロック情報を記憶する。固定長のブロックの開始点は「0」にブロックの長さを順に足した値となる。
Specifically, the
その後、受付サーバ２００は、処理要求部２０６の機能により、処理対象の画像データに対する処理を要求する処理要求を、TCPによるコネクション型通信により各処理サーバ３００に送信する（ステップＳ３）。例えば、処理対象の画像データが、複数のページの画像を表すものである場合、受付サーバ２００は、各々異なるページに対して各処理サーバ３０が各々処理を実行するよう、各ページに対して処理を要求する処理サーバ３００を決定して、処理対象の画像データ、処理対象のページ及び処理内容を指定すると共にブロック情報を含む処理要求を各処理サーバ３００に送信する。図６は、受付サーバ２００が処理サーバ３００に送信する処理要求のデータ構成を例示する図である。同図に示される処理要求では、プロトコルにはTCP上のアプリケーションプロトコルであるHTTPを用い、データ形式にはJSONを用いている。このデータ形式によって表現される処理要求では、「process_type」により処理内容を指定し、「data_id」により処理対象の画像データを識別するためのIDを指定し、「data_length」により処理対象の画像データの長さを指定し、「page」により処理対象の画像データによって表される画像が複数ページある場合に処理サーバに処理を要求する対象のページ番号を指定し、「chunk_offset」により処理対象の画像データについてブロック毎の開始点を指定する。「data_length」及び「chunk_offset」はブロック情報に相当する。同図では、処理内容として、「ocr」が指定され、処理対象の画像データのデータＩＤとして「fefefefe」が指定され、処理対象のページとして、「2」ページ目が指定され、処理対象の画像データのブロック情報として、ブロックの長さ「589960」と、各ブロックの開始点「0, 65536, 131072, ..., 589824」とが示されている。このブロック情報から、処理対象の画像データは、65536バイトの固定長のブロック9個と136バイトのブロック１つとから構成されていることが認識できる。
Thereafter, the
また、受付サーバ２００は、データ送信部２０９の機能により、ステップＳ２で分割した各ブロックをパケット単位でUDPのマルチキャストにより各処理サーバ３００に送信する（ステップＳ４）。このとき送信されるパケット（UDPパケットという）は、UDPヘッダと、UDPペイロードとを含む。UDPヘッダは、送信元のポート及び送信先のポートと、パケットの長さと、チェックサムとを含む。UDPペイロードは、処理対象の画像データを識別するためのデータＩＤと、当該パケットの属するブロックに付与されたブロック番号と、当該パケットに付与されたシーケンス番号と、処理対象の画像データの一部であって当該パケットに相当するデータ本体とを含む。そして、受付サーバ２００は、処理対象の画像データの全てのブロックについて送信が完了すると、その旨を示す送信完了メッセージを各処理サーバ３００に送信する（ステップＳ５）。そして、受付サーバ２００は、各処理サーバ３００からの処理結果の送信を待機する。この待機中、受付サーバ２００は、ブロックの再送を要求する再送要求をTCPにより処理サーバ３００から受信した場合には、当該再送要求に従って、該当のブロックをTCPにより処理サーバ３００に送信する。
Further, the
尚、ステップＳ３では、受付サーバ２００は、TCPにより処理要求を処理サーバ３００に送信しているため、当該処理要求を受信した旨を示す送達通知を処理サーバ３００から受信し、一定時間内に当該送達通知を受信していない処理サーバ３００に対しては、当該処理要求を再送する。また、受付サーバ２００は、再送要求に従って送信したブロックについても、当該ブロックを受信した旨を示す送達通知を処理サーバ３００から受信し、一定時間内に当該送達通知を受信していない処理サーバ３００に対しては、当該ブロックを再送する。再送要求については、処理サーバ３００の動作の説明と共に後ほど詳しく説明する。
In step S3, since the receiving
次に、各処理サーバ３００が行なう通信処理の詳細な手順について図７を用いて説明する。処理サーバ３００は、リクエスト処理部３０１の機能により、処理要求を受付サーバ２００から受信し（ステップＳ１０）、データ受信処理部３０２の機能により、受付サーバ２００からマルチキャストで送信された処理対象の画像データをパケット単位で受信する（ステップＳ１１）。このとき、処理サーバ３００は、データ受信部３０５の機能により、ステップＳ１０で受信した処理要求に含まれるブロック情報を参照して、受信したパケットをブロック毎に分類すると共に、受信完了判定部３０６の機能により、各パケットのチェックサムを検査し、ブロック毎にシーケンス番号が連続しているか否かを判定することで、受信が正常に完了したか否かをブロック毎に判定し、各ブロックをデータ格納部３０９に記憶させる（ステップＳ１３）。具体的には、処理サーバ３００は、処理対象の画像データ全体の長さと同等の長さの仮ファイルをファイルシステム上に生成し、ブロックに属する全てのパケットについてチェックサムが正常であると判定した場合に当該ブロックの受信が正常に完了したと判定し、当該ブロックのデータを仮ファイルの対応部分に書き込むことで、各ブロックをデータ格納部３０９に記憶させる。そして、処理サーバ３００は、受付サーバ２００から送信された送信完了メッセージを受信すると、ブロック管理部３０８の機能により、各ブロックの開始点と、各ブロックについての受信完了判定部３０６の判定結果を示す受信状態フラグとを記憶する。
Next, a detailed procedure of communication processing performed by each
そして、処理サーバ３００は、画像処理部３０４の機能により、ステップＳ１０で受信した処理要求によって指定された処理対象の画像データのうち指定されたページに対して、指定された処理内容の処理を実行する（ステップＳ１４）。このとき、処理サーバ３００は、処理対象の画像データ全体を一度に読み出すのではなく、処理に必要となった段階でブロック単位でデータを読み出す。
Then, the
ここで、ステップＳ１４で処理を実行する手順について図８を用いて説明する。処理サーバ３００は、指定されたページに対応する少なくとも１つ以上のブロックを特定する。図９は、複数のページの画像を表すTIFF形式の画像データのデータ構成を簡略化して例示する図である。同図に示されるように、TIFF形式の画像データは、TIFFヘッダと、ページ毎にIFD(ImageFile Directory)及びページの画像を表す画像データとを含む。TIFFヘッダは、バイトオーダーと、バージョンと、最初のIFDの開始点とを含み、IFD及び画像データが交互に表れるデータ構成となっている。IFDは、画像の情報を記述するためのTIFF固有のタグと次のIFDの開始点とを含む。このような画像データについて、処理要求によって指定されたページが例えば2ページ目である場合、処理サーバ３００は、TIFFヘッダを含む最初のブロックをデータ格納部３０９から読み出し、1ページ目に対応するIFDの開始点を参照して、1ページ目に対応するIFDを読み出し、1ページ目に対応するIFDに含まれる2ページ目に対応するIFDの開始点を参照して、2ページ目に対応するIFDを含むブロックを読み出す。尚、1ページ目に対応するIFDと2ページ目に対応するIFDとの間には1ページ目の画像データがあるが、このデータは読み取る必要がない。そして、処理サーバ３００は、2ページ目に対応するIFDに含まれる3ページ目に対応するIFDの開始点を参照して、その間の部分に2ページ目の画像データがあることを認識し、当該画像データを含むブロックを特定する。尚、当該画像データが複数のブロックに跨る場合には、処理サーバ３００は、複数のブロックを特定する。
Here, the procedure for executing the processing in step S14 will be described with reference to FIG. The
そして、処理サーバ３００は、特定したブロックについて、ブロック管理部３０８の機能により、図４に例示される受信状態フラグを参照する(ステップＳ２０)。当該ブロックについて受信が正常に完了している場合には(ステップＳ２１：ＹＥＳ)、処理サーバ３００は、当該ブロックをデータ格納部３０９から読み出し(ステップＳ２２)、ステップＳ２５に進む。一方、当該ブロックについて受信が正常に完了していない場合には(ステップＳ２１：ＮＯ)、処理サーバ３００は、再送要求部３０７の機能により、受付サーバ２００との間にTCPコネクションが確立されていない場合にはTCPコネクションを確立した後、当該ブロックの再送を要求する再送要求をTCPにより受付サーバ２００に送信する(ステップＳ２３)。図１０は、再送要求のデータ構成を例示する図である。同図に示される再送要求では、プロトコルにはHTTPを用いている。同図では、URIのパス部分(「GET」で始まる行のGETの次にある固まり)で対象の画像データが指定され、そのデータ内の位置が「Range」で始まる行によって指定されている。即ち、図１０の例では、データＩＤ「54321」の画像データのうち、その開始点が「131072」で終了点が「196607」の範囲、即ち、65536バイトの先頭から３番目のブロックが、再送の対象のブロックとして指定されている。
Then, the
図８の説明に戻る。当該再送要求に従って受付サーバ２００からHTTPのレスポンスとして送信されたパケットを処理サーバ３００は受信する。そして、処理サーバ３００は、当該再送要求によって再送が要求されたブロックに属する全てのパケットを受信すると、ブロック管理部３０８の機能により、当該ブロックについての受信状態フラグを「1」に更新し(ステップＳ２４)、ステップＳ２５に進む。ステップＳ２５では、処理サーバ３００は、画像処理部３０４の機能により、該当のブロックを用いて、画像処理部３０４の機能により、処理を実行する。その後、図７のステップＳ１５に戻り、処理サーバ３００は、リクエスト処理部３０１の機能により、処理結果を受付サーバ２００に送信する。
Returning to the description of FIG. The
尚、ステップＳ１０では、処理サーバ３００は、TCPにより処理要求を受付サーバ２００から受信しているため、当該処理要求を受信した旨を示す送達通知を受付サーバ２００に送信する。また、ステップＳ２４で、処理サーバ３００は、再送要求に従ったブロックを受付サーバ２００から受信した場合にも、当該ブロックを受信した旨を示す送達通知を受付サーバ２００に送信する。ステップＳ１１で受信する画像データについては、送達確認は不要であるため、処理サーバ３００は送達通知を送信しない。
In step S10, since the
以上のように、送信側の受付サーバ２００は、処理対象のデータをブロックに分割して、送達確認のないマルチキャストにより送信する。受信側の処理サーバ３００は、受信が正常に完了していないデータ全ての再送を要求するのではなく、受信が正常に完了していないブロックが処理において必要となった場合にのみ再送を要求する。このように受信側での必要性に応じてデータを再送する構成によれば、1対多のデータ転送において、無駄な送達確認や、データの無駄な再送を抑制することができ、データ転送を効率化することができる。また、受付サーバ２００は、処理対象のデータを解析したり、処理サーバ毎にデータを物理的に分割したりする必要がなく、処理対象のデータのデータ構成を認識する必要がないため、受付サーバ２００の構成の複雑化を回避することができる。
As described above, the receiving
[変形例]
なお、本発明は前記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。また、以下に例示するような種々の変形が可能である。
[Modification]
Note that the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage. Moreover, various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the embodiment. For example, some components may be deleted from all the components shown in the embodiment. Furthermore, constituent elements over different embodiments may be appropriately combined. Further, various modifications as exemplified below are possible.
＜変形例１＞
上述した実施の形態において、受付サーバ２００で実行される各種プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また当該各種プログラムを、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成しても良い。処理サーバ３００についても同様である。
<
In the above-described embodiment, various programs executed by the
上述の実施の形態では、受付サーバ２００，処理サーバ３００はそれぞれ、コピー機能、プリンタ機能、スキャナ機能およびファクシミリ機能のうち少なくとも１つの機能を有し、各機能に応じた画像処理エンジンを備える画像処理装置であっても良い。
In the above-described embodiment, each of the
＜変形例２＞
上述の実施の形態では、処理対象の画像データを分割するブロックの長さは固定長であるとしたが、可変長であっても良い。このような構成において、受付サーバ２００の画像処理制御部２０２は、処理要求部２０６と、データ分割部２０７と、データブロック管理部２０８と、データ送信部２０９と、処理結果管理部２１０とに加え、データ解析部（不図示）を更に有する。データ解析部は、処理対象の画像データを解析して、その種別を判定する。データ分割部２０７は、データ解析部が判定した種別に応じて、処理対象の画像データのうち、２つ以上の処理サーバ３００が必要とする部分のデータは独立したブロックとなるよう、当該画像データを複数のブロックに分割する。例えば、処理対象の画像データが、図９に示されるように、複数ページの画像を表すTIFF形式の画像データである場合、IFDは、複数の処理サーバ３００から参照されるデータである。このため、IFDと画像データとは各々別のブロックとなるようにデータ分割部２０７は分割する。
<
In the above-described embodiment, the length of the block for dividing the image data to be processed is a fixed length, but may be a variable length. In such a configuration, the image
IFDのサイズは画像データに比べて小さいが、このように、IFDを１つのブロックとして取り扱うことで、IFDをUDPにより送信した際にその受信が正常に完了する可能性が高くなる。また、受信が正常に完了しておらず再送することになったとしても、サイズが小さいため、IFDをブロックとして送信する際のネットワーク負荷を小さく抑えることができる。 Although the size of the IFD is smaller than that of the image data, handling the IFD as one block in this way increases the possibility that the reception will be completed normally when the IFD is transmitted by UDP. Even if reception is not completed normally and retransmission is performed, the size is small, so that the network load when transmitting the IFD as a block can be reduced.
＜変形例３＞
上述の実施の形態では、受付サーバ２００が各処理サーバ３００に送信する処理要求に含まれるブロック情報は、ブロック毎のハッシュ値を更に含んでも良い。具体的には、受付サーバ２００の処理要求部２０６は、処理要求を各処理サーバ３００に送信する際に、ブロック毎のMD5メッセージダイジェストによるハッシュ値を算出し、当該ハッシュ値を含むブロック情報を含む処理要求を各処理サーバ３００に送信する。図１１は、本変形例にかかる処理要求のデータ構成を例示する図である。同図に示される処理要求では、「hash_md5」により各ブロックのハッシュ値が示されている。
<
In the above-described embodiment, the block information included in the processing request transmitted from the
一方、処理サーバ３００は、このような処理要求を受信し、処理対象の画像データをパケット単位で受信すると、受信したパケットをブロック毎に分類し、各パケットのチェックサムを検査し、ブロック毎にシーケンス番号が連続しているか否かを判定すると共に、各ブロックについて、ハッシュ値を算出し、当該ハッシュ値と、処理要求に含まれるブロック情報に含まれるハッシュ値とをブロック毎に比較してこれらが一致するか否かを判定することによって、各ブロックのデータの正当性を判定する。そして、処理サーバ３００は、シーケンス番号が連続しているブロック及びハッシュ値が一致したブロックについて、受信が正常に完了したと判定し、当該ブロックをデータ格納部３０９に記憶させる。
On the other hand, when the
以上のような構成によれば、ハッシュ値によりデータの正当性を検証することで、UDPパケットのチェックサムで検出できなかったエラーを検出することができる。 According to the configuration as described above, it is possible to detect an error that could not be detected by the checksum of the UDP packet by verifying the validity of the data by the hash value.
＜変形例４＞
上述の実施の形態においては、処理サーバ３００が再送を一度に要求するブロックは、複数であっても良い。この場合、画像処理部３０４による処理の実行と、再送要求部３０７による再送要求の送信とは順次ではなく、非同期で行なう。また、処理サーバ３００のブロック管理部３０８は、再送要求を蓄積する要求プール（不図示）を有する。要求プールは、例えばＲＡＭなどの主記憶部や補助記憶部に生成される。
<
In the above-described embodiment, there may be a plurality of blocks that the
図１２は、本変形例にかかるステップＳ１４で処理を実行する手順を示すフローチャートである。ここでは、画像処理部３０４による処理の実行と、再送要求部３０７による再送要求の送信と非同期で行なうため、スレッドを２つに分けている。前者を第１スレッドとし、後者を第２スレッドとする。ステップＳ２０〜Ｓ２１は上述の実施の形態と同様である。ステップＳ２１の判定結果が肯定的である場合、ステップＳ３０では、処理サーバ３００は、ブロック管理部３０８の機能により、処理に用いるブロックとして特定し且つ処理がまだ行われておらず且つ受信が正常に完了していると判定したブロックをデータ格納部３０９から読み出す。そして、処理サーバ３００は、該当のブロックを用いて、処理を実行する（ステップＳ３４）。その後、処理サーバ３００は、処理対象の全てのページについて処理を実行したか否かを判定する（ステップＳ３５）。当該判定結果が否定的である場合、ステップＳ２０に戻り、ステップＳ３５の判定結果が肯定的である場合、図７のステップＳ１５に進む。
FIG. 12 is a flowchart showing a procedure for executing the process in step S14 according to the present modification. Here, in order to perform processing asynchronously with the execution of the processing by the
ステップＳ２１の判定結果が否定的である場合、ステップＳ３１では、処理サーバ３００は、ブロック管理部３０８の機能により、処理に用いるブロックとして特定し且つ受信が正常に完了していないと判定したブロックの再送を要求する再送要求を要求プールに蓄積する。次いで、処理サーバ３００は、再送要求によって再送が要求されるブロックについて、ブロック管理部３０８の機能により、図４に例示される受信状態フラグを参照する(ステップＳ３２)。当該ブロックについて受信が正常に完了している場合には(ステップＳ３３：ＹＥＳ)、当該再送要求を削除対象として、ステップＳ３０に進み、当該ブロックについて受信が正常に完了していない場合には(ステップＳ３３：ＮＯ)、ステップＳ３２に戻る。
If the determination result in step S21 is negative, in step S31, the
一方、予め待機している第２スレッドにおいて、ステップＳ４０では、処理サーバ３００は、ブロック管理部３０８の機能により、要求プールに蓄積されている再送要求があるか否かを判定する。当該判定結果が肯定的である場合、ステップＳ４１では、処理サーバ３００は、ブロック管理部３０８の機能により、要求プールに蓄積されている再送要求を読み出す。次いで、処理サーバ３００は、再送要求部３０７の機能により、受付サーバ２００との間にTCPコネクションが確立されていない場合にはTCPコネクションを確立する。このTCPコネクションは、連続するブロックの再送が完了するまで利用する。そして、処理サーバ３００は、要求プールから読み出した再送要求を参照して、再送が要求されているブロックを識別し、当該識別結果に応じて、各ブロックの再送要求をTCPにより受付サーバ２００に送信する。具体的には、要求プールに複数の再送要求が蓄積されており、各再送要求によって再送が要求されているブロックの位置が処理対象の画像データにおいて連続している場合、処理サーバ３００は、連続しているブロックの先頭のブロックの開始点と、最後尾のブロックの終了点とを指定した再送要求をTCPにより受付サーバ２００に送信する。要求プールに複数の再送要求が蓄積されていても、各再送要求によって再送が要求されているブロックの位置が処理対象の画像データにおいて連続していない場合、処理サーバ３００は、各ブロックの再送を要求する再送要求をブロック毎に送信する。
On the other hand, in the second thread waiting in advance, in step S40, the
図１３〜１４は、再送要求のデータ構成を例示する図である。これらの図に示される再送要求では、図６に示される処理要求と同様に、プロトコルにはHTTPを用い、データ形式にはJSONを用いている。各図に示される再送要求によって、データＩＤ「54321」の画像データについて、連続しない２つのブロックの再送が各々要求されている。図１５は、図１３に示される再送要求に従って受付サーバ２００が再送対象のブロックを処理サーバ３０に送信する際のパケットのデータ構成を例示する図である。これらのパケット及び再送要求では、「Connection: Keep-Alive」というコマンドが指定されているので、受付サーバ２００と処理サーバ３００との間のTCPコネクションは再送対象のブロックが送信された後も維持され、当該TCPコネクションを利用して、続く処理サーバ３００からの再送要求が送信され得る。以上のようにして、処理サーバ３００は、再送要求によってブロックを取得してこれをデータ格納部３０９に記憶させ、上述の実施の形態と同様にして、ブロック管理部３０８の機能により、再送要求によって取得したブロックについての受信状態フラグを「1」に更新し、その後、要求プールに蓄積された削除対象の再送要求を削除する。ステップＳ４１の後、ステップＳ４０に戻る。尚、要求プールに蓄積されている再送要求がなくなった場合（ステップＳ４０：ＮＯ）、処理サーバ３００は、受付サーバ２００との間で確立したTCPコネクションをクローズし、要求プールに新たな再送要求が蓄積されるまで待機する。
13 to 14 are diagrams illustrating a data configuration of a retransmission request. In the retransmission request shown in these figures, HTTP is used for the protocol and JSON is used for the data format, as in the processing request shown in FIG. According to the retransmission request shown in each figure, retransmission of two non-consecutive blocks is requested for the image data with the data ID “54321”. FIG. 15 is a diagram exemplifying a data configuration of a packet when the
以上のように、画像処理部３０４による処理の実行と、ブロック管理部３０８によるブロックの読み出し又は再送要求部３０７によるブロックの取得とを非同期で並行して行なうことにより、処理対象のブロックの取得を待機する時間を低減し、処理をスムーズに実行させることができ、全体の処理時間の増加を抑制することができる。また、連続するブロックについては一度にその再送を要求することができ、データの再送をより効率化することができる。
As described above, the execution of the processing by the
また、画像処理部３０４が処理を実行する際に必要となる全てのブロックを予め特定できる場合、各ブロックの読み出しを予め行うことにより、処理の実行とは非同期に該当のブロックの取得を行うことができる。例えば、図９に例示した複数のページの画像を表すTIFF形式の画像データについて、処理対象のページとして2ページと4ページとが処理要求によって指定されている場合、処理サーバ３００は、以下のようにして必要となる全てのブロックを予め認識することができる。
In addition, when all the blocks necessary for the
処理サーバ３００は、まず、画像データのTIFFヘッダに含まれる1ページ目に対応するIFDの開始点を参照して、1ページ目に対応するIFDを読み出し、2ページ目に対応するIFDの開始点を参照する。2ページ目に対応するIFDから3ページ目に対応するIFDまでの間は2ページ目の画像データに相当する。このため、処理サーバ３００は、ブロック管理部３０８の機能により、2ページ目の画像データを含むブロックをデータ格納部３０９から読み出す。このとき、処理サーバ３００は、上述の実施の形態と同様にして、受信状態フラグを参照し、当該ブロックの受信が正常に完了していない場合には、再送要求部３０７の機能により、再送要求を受付サーバ２００に送信して、当該ブロックを受付サーバ２００から取得する。その後、処理サーバ３００は、当該ブロックを用いて、画像処理部３０４の機能により、処理を実行する。
The
更に、処理サーバ３００は、4ページ目に対応するIFDを読み出し、5ページ目に対応するIFDの開始点を参照する。4ページ目に対応するIFDから5ページ目に対応するIFDまでの間は4ページ目の画像データであるので、処理サーバ３００は、画像処理部３０４の機能による2ページ目の画像データを含むブロックを用いた処理の実行と並行して、ブロック管理部３０８の機能により、4ページ目の画像データを含むブロックをデータ格納部３０９から読み出す。このとき、処理サーバ３００は、上述の実施の形態と同様にして、受信状態フラグを参照し、当該ブロックの受信が正常に完了していない場合には、再送要求部３０７の機能により、再送要求を受付サーバ２００に送信して、当該ブロックを受付サーバ２００から取得する。その後、処理サーバ３００は、当該ブロックを用いて、画像処理部３０４の機能により、処理を実行する。
Further, the
このように、処理対象の全てのブロックを予め特定して、ブロック管理部３０８によるブロックの読み出し又は再送要求部３０７によるブロックの取得と、画像処理部３０４による処理の実行とを非同期で並行して行なうことにより、処理対象のブロックの取得を待機する時間をより低減し、処理をよりスムーズに実行させることができ、処理全体の時間をより低減することができる。
In this way, all the blocks to be processed are specified in advance, and the block reading by the
＜変形例５＞
上述の実施の形態においては、複数のブロックに分割する処理対象のデータを画像データであるとし、受付サーバ２００は、処理対象の画像データについて、各々異なるページに対して各処理サーバ３００が各々処理を実行するよう、各ページに対して処理を要求する処理サーバ３００に各々送信した。しかし、処理の単位はページに限らず、また、処理対象のデータは画像データに限らず、受付サーバ２００は、処理対象のデータについて、各々異なる部分に対して各処理サーバ３００が各々処理を実行するよう、当該データの一部に対して処理を要求する処理サーバ３００に各々送信すれば良い。
<
In the above-described embodiment, it is assumed that the processing target data divided into a plurality of blocks is image data, and the receiving
また、当該データに対して分散して実行する処理（分散処理）は、画像処理に限らない。例えば、複数のブロックに分割する処理対象のデータは、音声を表す音声データであって、当該音声データに対する分散処理は、音声を認識する音声認識処理であっても良い。その他、固定長のレコードからなる巨大なデータに対して、分散処理を行う場合に本実施の形態の構成を適用しても良い。 Further, the processing (distributed processing) executed in a distributed manner on the data is not limited to image processing. For example, the processing target data to be divided into a plurality of blocks may be voice data representing voice, and the distributed processing for the voice data may be voice recognition processing for recognizing voice. In addition, the configuration of the present embodiment may be applied when performing distributed processing on huge data composed of fixed-length records.
１００ クライアント
２００ 受付サーバ
２０１ HTTPサーバ部
２０２ 画像処理制御部
２０３ 画像蓄積部
２０４ リクエスト処理部
２０５ 再送要求処理部
２０６ 処理要求部
２０７ データ分割部
２０８ データブロック管理部
２０９ データ送信部
２１０ 処理結果管理部
３００ 処理サーバ
３０１ リクエスト処理部
３０２ データ受信処理部
３０３ データ蓄積部
３０４ 画像処理部
３０５ データ受信部
３０６ 受信完了判定部
３０７ 再送要求部
３０８ ブロック管理部
３０９ データ格納部
ＮＴ１，ＮＴ２ ネットワーク
100
Claims (10)
前記データを、送達確認のない第２の通信方式で前記他の通信装置から受信する第２受信手段と、
前記処理要求に従って、前記データの一部に対して、前記処理を実行する処理手段と、
前記処理手段が前記処理を実行する際に、前記データの一部に該当する前記ブロックの受信が正常に完了していない場合、当該ブロックの再送を要求する再送要求を前記他の通信装置に送信する再送要求手段と、
前記再送要求手段が送信した前記再送要求に従って前記他の通信装置から送信された前記ブロックを受信する第３受信手段と、
前記処理手段が前記処理を実行した結果を、前記第１の通信方式で前記他の通信装置に送信する送信手段とを備える
ことを特徴とする通信装置。 First receiving means for receiving a processing request for requesting processing on a part of data divided into a plurality of blocks from another communication device in a first communication method with delivery confirmation;
Second receiving means for receiving the data from the other communication device in a second communication method without delivery confirmation;
Processing means for executing the processing on a part of the data according to the processing request;
When the processing means executes the processing, if reception of the block corresponding to a part of the data is not normally completed, a retransmission request for requesting retransmission of the block is transmitted to the other communication device. Resending request means to
Third receiving means for receiving the block transmitted from the other communication device in accordance with the retransmission request transmitted by the retransmission request means;
A communication device, comprising: a transmission unit configured to transmit a result of execution of the processing by the processing unit to the other communication device using the first communication method.
ことを特徴とする請求項１に記載の通信装置。 The communication according to claim 1, wherein the retransmission request unit transmits the retransmission request to the other communication device by the first communication method when the processing unit executes the process. apparatus.
ことを特徴とする請求項１又は２に記載の通信装置。 The communication device according to claim 1, wherein the third receiving unit receives the block from the other communication device using the first communication method.
前記ブロック情報を参照して、前記データの一部に該当する少なくとも１つの前記ブロックを特定する特定手段を更に備え、
前記再送要求手段は、前記処理手段が前記処理を実行する際に、前記特定手段が特定した前記ブロックの受信が正常に完了していない場合、当該ブロックの再送を要求する再送要求を前記他の通信装置に送信する
ことを特徴とする請求項１乃至３のいずれか一項に記載の通信装置。 The processing request includes block information for specifying the position of each block in the data,
A specifying means for specifying at least one block corresponding to a part of the data with reference to the block information;
The retransmission request means, when the processing means executes the processing, if the reception of the block specified by the specification means is not normally completed, sends a retransmission request for requesting retransmission of the block to the other The communication apparatus according to claim 1, wherein the communication apparatus transmits to the communication apparatus.
前記再送要求手段は、前記処理手段が前記処理を実行する際に、前記特定手段が特定した前記ブロックについて、受信が正常に完了していないと前記第１判定手段によって判定されている場合、当該ブロックの再送を要求する再送要求を前記他の通信装置に送信する
ことを特徴とする請求項４に記載の通信装置。 Further comprising first determination means for determining whether or not reception has been normally completed for each block belonging to the data;
The retransmission request means, when the first determination means determines that the reception of the block specified by the specification means is not normally completed when the processing means executes the processing, The communication apparatus according to claim 4, wherein a retransmission request for requesting retransmission of a block is transmitted to the other communication apparatus.
前記第２受信手段が受信した前記データに属する各前記ブロックについてハッシュ値を算出する算出手段と、
前記ブロック毎に、前記ブロック情報に含まれる前記ハッシュ値と、前記算出手段が算出した前記ハッシュ値とが一致するか否かを判定する第２判定手段とを更に備え、
前記再送要求手段は、前記処理手段が前記処理を実行する際に、前記特定手段が特定した前記ブロックについて、受信が正常に完了していないと前記第１判定手段によって判定されている場合又は前記ハッシュ値が一致しないと前記第２判定手段によって判定されている場合に、当該ブロックの再送を要求する再送要求を前記他の通信装置に送信する
ことを特徴とする請求項５に記載の通信装置。 The block information includes a hash value of each block,
Calculating means for calculating a hash value for each block belonging to the data received by the second receiving means;
A second determination unit that determines, for each block, whether the hash value included in the block information matches the hash value calculated by the calculation unit;
The retransmission requesting unit is configured such that when the processing unit executes the processing, the first determination unit determines that reception of the block specified by the specifying unit has not been normally completed or 6. The communication apparatus according to claim 5, wherein when the second determination unit determines that the hash values do not match, a retransmission request for requesting retransmission of the block is transmitted to the other communication apparatus. .
前記ブロック情報は、前記ブロックの長さと、各前記ブロックの開始点とを示し、
前記処理要求は、前記処理の対象が前記データのいずれの部分であるかを指定し、
前記特定手段は、前記ブロック情報を参照して、前記処理要求によって指定された前記部分に該当する少なくとも１つの前記ブロックを特定する
ことを特徴とする請求項４乃至６のいずれか一項に記載の通信装置。 The length of the block is fixed length or variable length,
The block information indicates the length of the block and the starting point of each block,
The processing request specifies which part of the data the processing target is,
The said specifying means specifies at least one said block corresponding to the said part designated by the said process request with reference to the said block information, The any one of Claim 4 thru | or 6 characterized by the above-mentioned. Communication equipment.
前記第１の通信装置は、
処理対象のデータを複数のブロックに分割する分割手段と、
前記データの各々異なる部分に対して各前記第３の通信装置が各々処理を実行するよう、当該データの一部に対する処理を要求する処理要求を、送達確認のある第１の通信方式で各前記第３の通信装置に送信する第１送信手段と、
前記データを、送達確認のない第２の通信方式で各前記第２の通信装置に送信する第２送信手段と、
前記ブロックの再送を要求する再送要求を、前記第２の通信装置から受信する第２受信手段と、
前記再送要求に従って、前記ブロックを、前記第２の通信装置に送信する第３送信手段と、
前記処理が実行された結果を、前記第１の通信方式で各前記第３の通信装置から受信する第３受信手段とを備え、
各前記第２の通信装置は、
前記処理要求を、前記第１の通信方式で前記第１の通信装置から受信する第４受信手段と、
前記データを、前記第２の通信方式で前記第１の通信装置から受信する第５受信手段と、
前記処理要求に従って、前記データの一部に対して、前記処理を実行する処理手段と、
前記処理手段が前記処理を実行する際に、前記データの一部に該当する前記ブロックの受信が正常に完了していない場合、当該ブロックの再送を要求する再送要求を前記第１の通信装置に送信する再送要求手段と、
前記再送要求手段が送信した前記再送要求に従って前記第１の通信装置から送信された前記ブロックを受信する第６受信手段と、
前記処理手段が前記処理を実行した結果を、前記第１の通信方式で前記第１の通信装置に送信する第４送信手段とを備える
ことを特徴とする通信システム。 A communication system in which a first communication device and a plurality of second communication devices are connected via a network,
The first communication device is:
A dividing means for dividing the data to be processed into a plurality of blocks;
A processing request for requesting processing for a part of the data is sent to each of the first communication methods with delivery confirmation so that each of the third communication devices executes processing for each different part of the data. First transmission means for transmitting to a third communication device;
Second transmission means for transmitting the data to each of the second communication devices by a second communication method without delivery confirmation;
Second receiving means for receiving a retransmission request for requesting retransmission of the block from the second communication device;
Third transmission means for transmitting the block to the second communication device according to the retransmission request;
A third receiving means for receiving a result of the execution of the processing from each of the third communication devices in the first communication method;
Each of the second communication devices is
Fourth receiving means for receiving the processing request from the first communication device in the first communication method;
Fifth receiving means for receiving the data from the first communication device in the second communication method;
Processing means for executing the processing on a part of the data according to the processing request;
When the processing means executes the processing, if reception of the block corresponding to a part of the data is not normally completed, a retransmission request for requesting retransmission of the block is sent to the first communication device. A retransmission request means for transmitting;
Sixth receiving means for receiving the block transmitted from the first communication device according to the retransmission request transmitted by the retransmission request means;
A communication system, comprising: a fourth transmission unit configured to transmit the result of execution of the processing by the processing unit to the first communication device using the first communication method.
前記第１受信手段が、複数のブロックに分割されたデータの一部に対する処理を要求する処理要求を、送達確認のある第１の通信方式で他の通信装置から受信する第１受信ステップと、
前記第２受信手段が、前記データを、送達確認のない第２の通信方式で前記他の通信装置から受信する第２受信ステップと、
前記処理手段が、前記処理要求に従って、前記データの一部に対して、前記処理を実行する処理ステップと、
前記再送要求手段が、前記処理ステップで前記処理が実行される際に、前記データの一部に該当する前記ブロックの受信が正常に完了していない場合、当該ブロックの再送を要求する再送要求を前記他の通信装置に送信する再送要求ステップと、
第３受信手段が、前記再送要求ステップで送信された前記再送要求に従って前記他の通信装置から送信された前記ブロックを受信する第３受信ステップと、
前記送信手段が、前記処理ステップで前記処理が実行された結果を、前記第１の通信方式で前記他の通信装置に送信する送信ステップとを含む
ことを特徴とする通信方法。 A communication method executed by a communication device including a first reception unit, a second reception unit, a processing unit, a retransmission request unit, a third reception unit, and a transmission unit,
A first receiving step in which the first receiving means receives a processing request for requesting processing of a part of data divided into a plurality of blocks from another communication device in a first communication method with delivery confirmation;
A second receiving step in which the second receiving means receives the data from the other communication device by a second communication method without delivery confirmation;
A processing step in which the processing means executes the processing on a part of the data according to the processing request;
When the retransmission requesting unit does not normally complete reception of the block corresponding to a part of the data when the processing is executed in the processing step, a retransmission request for requesting retransmission of the block is issued. A retransmission request step for transmitting to the other communication device;
A third receiving step in which a third receiving means receives the block transmitted from the other communication device in accordance with the retransmission request transmitted in the retransmission request step;
A communication method, comprising: a transmission step in which the transmission means transmits a result of the execution of the processing in the processing step to the other communication device by the first communication method.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009190429A JP2011044823A (en) | 2009-08-19 | 2009-08-19 | Communication equipment, communication system, communication method and communication program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009190429A JP2011044823A (en) | 2009-08-19 | 2009-08-19 | Communication equipment, communication system, communication method and communication program |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2011044823A true JP2011044823A (en) | 2011-03-03 |
Family
ID=43831937
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2009190429A Pending JP2011044823A (en) | 2009-08-19 | 2009-08-19 | Communication equipment, communication system, communication method and communication program |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2011044823A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2014192689A1 (en) * | 2013-05-27 | 2014-12-04 | オリンパスメディカルシステムズ株式会社 | Wireless communication system and communication method |
| JP2017511089A (en) * | 2015-01-29 | 2017-04-13 | シャオミ・インコーポレイテッド | Method, apparatus, program and recording medium for accessing network |
-
2009
- 2009-08-19 JP JP2009190429A patent/JP2011044823A/en active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2014192689A1 (en) * | 2013-05-27 | 2014-12-04 | オリンパスメディカルシステムズ株式会社 | Wireless communication system and communication method |
| JP5690457B1 (en) * | 2013-05-27 | 2015-03-25 | オリンパスメディカルシステムズ株式会社 | Wireless communication system and communication method |
| JP2017511089A (en) * | 2015-01-29 | 2017-04-13 | シャオミ・インコーポレイテッド | Method, apparatus, program and recording medium for accessing network |
| US9723486B2 (en) | 2015-01-29 | 2017-08-01 | Xiaomi Inc. | Method and apparatus for accessing network |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9906630B2 (en) | Processing data packets in performance enhancing proxy (PEP) environment | |
| US8898311B2 (en) | Data communication method and information processing device | |
| CN107438012B (en) | Load balancing service forwarding method, system, balancing device and host machine | |
| US9794354B1 (en) | System and method for communication between networked applications | |
| JP5175773B2 (en) | Communication apparatus, method and program | |
| JP5696724B2 (en) | Relay device, relay system, relay method, program, and computer-readable recording medium recording the program | |
| WO2016000138A1 (en) | Data transmission method, terminal and server | |
| US20070291782A1 (en) | Acknowledgement filtering | |
| JP2007142582A (en) | Data communication device, data communication method, program, and storage medium | |
| US11336297B2 (en) | DMA transfer apparatus, method of controlling the same, communication apparatus, method of controlling the same, and non-transitory computer-readable storage medium | |
| JP2011044823A (en) | Communication equipment, communication system, communication method and communication program | |
| KR101650829B1 (en) | Method, apparatus, and system for acquiring object | |
| US20140047124A1 (en) | Trivial file transfer protocol (tftp) data transferring prior to file transfer completion | |
| JP2006260543A (en) | Method and apparatus for transmitting data to network, and method and apparatus for receiving data from network | |
| US20070165661A1 (en) | Information-processing system, reception device, and program | |
| US8825890B2 (en) | Image processing device, control method therefor and computer readable medium | |
| JP2006013911A (en) | Stream data transfer method, apparatus and program, and recording medium | |
| JP2001060157A (en) | Inter-application message exchange system | |
| US20210168220A1 (en) | Hybrid proxying with user space hold | |
| KR100900963B1 (en) | Hardware device and method for sending the network protocol packet | |
| JP2017033221A (en) | Api request processing device, api request processing method, and api request processing program | |
| US20170265103A1 (en) | Communication device, communication method, and non-transitory computer readable medium | |
| JP5825940B2 (en) | Distributed processing control system and control method thereof | |
| JP6669382B2 (en) | Device device, information processing method and program | |
| JP4664211B2 (en) | Processing apparatus and control method thereof |