(57)【要約】【課題】マルチキャストに基づく1対多の通信において、データの再送を必要最小限とし、より効率化することが可能な通信技術を提供する。【解決手段】リクエスト処理部３０１は、TCPにより、処理要求を受付サーバ２００から受信したり、画像処理部３０４の処理結果を受付サーバ２００に送信したりする。データ受信部３０５は、受付サーバ２００からUDPのマルチキャストで送信された処理対象の画像データをブロック毎にデータ蓄積部３０３に記憶させる。受信完了判定部３０６は、各ブロックの受信完了を判定する。画像処理部３０４は、処理対象の画像データのうち処理対象のブロックを用いて、処理を実行する。再送要求部３０７は、画像処理部３０４が処理を実行する際に、処理対象のブロックについて受信が正常に完了していないと判定された場合、再送要求をTCPにより受付サーバ２００に送信し、当該再送要求に従って送信されたブロックを受信する。【選択図】図３
2011044823.tif 000002
【特許請求の範囲】
【請求項１】
複数のブロックに分割されたデータの一部に対する処理を要求する処理要求を、送達確認のある第１の通信方式で他の通信装置から受信する第１受信手段と、
前記データを、送達確認のない第２の通信方式で前記他の通信装置から受信する第２受信手段と、
前記処理要求に従って、前記データの一部に対して、前記処理を実行する処理手段と、
前記処理手段が前記処理を実行する際に、前記データの一部に該当する前記ブロックの受信が正常に完了していない場合、当該ブロックの再送を要求する再送要求を前記他の通信装置に送信する再送要求手段と、
前記再送要求手段が送信した前記再送要求に従って前記他の通信装置から送信された前記ブロックを受信する第３受信手段と、
前記処理手段が前記処理を実行した結果を、前記第１の通信方式で前記他の通信装置に送信する送信手段とを備える
ことを特徴とする通信装置。
【請求項２】
前記再送要求手段は、前記処理手段が前記処理を実行する際に、前記再送要求を、前記第１の通信方式で前記他の通信装置に送信する
ことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記第３受信手段は、前記ブロックを前記第１の通信方式で前記他の通信装置から受信する
ことを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
前記処理要求は、前記データにおける各前記ブロックの位置を特定するためのブロック情報を含み、
前記ブロック情報を参照して、前記データの一部に該当する少なくとも１つの前記ブロックを特定する特定手段を更に備え、
前記再送要求手段は、前記処理手段が前記処理を実行する際に、前記特定手段が特定した前記ブロックの受信が正常に完了していない場合、当該ブロックの再送を要求する再送要求を前記他の通信装置に送信する
ことを特徴とする請求項１乃至３のいずれか一項に記載の通信装置。
【請求項５】
前記データに属する各ブロックについて受信が正常に完了したか否かを判定する第１判定手段を更に備え、
前記再送要求手段は、前記処理手段が前記処理を実行する際に、前記特定手段が特定した前記ブロックについて、受信が正常に完了していないと前記第１判定手段によって判定されている場合、当該ブロックの再送を要求する再送要求を前記他の通信装置に送信する
ことを特徴とする請求項４に記載の通信装置。
【請求項６】
前記ブロック情報は、各前記ブロックのハッシュ値を含み、
前記第２受信手段が受信した前記データに属する各前記ブロックについてハッシュ値を算出する算出手段と、
前記ブロック毎に、前記ブロック情報に含まれる前記ハッシュ値と、前記算出手段が算出した前記ハッシュ値とが一致するか否かを判定する第２判定手段とを更に備え、
前記再送要求手段は、前記処理手段が前記処理を実行する際に、前記特定手段が特定した前記ブロックについて、受信が正常に完了していないと前記第１判定手段によって判定されている場合又は前記ハッシュ値が一致しないと前記第２判定手段によって判定されている場合に、当該ブロックの再送を要求する再送要求を前記他の通信装置に送信する
ことを特徴とする請求項５に記載の通信装置。
【請求項７】
前記ブロックの長さは、固定長又は可変長であり、
前記ブロック情報は、前記ブロックの長さと、各前記ブロックの開始点とを示し、
前記処理要求は、前記処理の対象が前記データのいずれの部分であるかを指定し、
前記特定手段は、前記ブロック情報を参照して、前記処理要求によって指定された前記部分に該当する少なくとも１つの前記ブロックを特定する
ことを特徴とする請求項４乃至６のいずれか一項に記載の通信装置。
【請求項８】
第１の通信装置と、複数の第２の通信装置とがネットワークを介して接続される通信システムであって、
前記第１の通信装置は、
処理対象のデータを複数のブロックに分割する分割手段と、
前記データの各々異なる部分に対して各前記第３の通信装置が各々処理を実行するよう、当該データの一部に対する処理を要求する処理要求を、送達確認のある第１の通信方式で各前記第３の通信装置に送信する第１送信手段と、
前記データを、送達確認のない第２の通信方式で各前記第２の通信装置に送信する第２送信手段と、
前記ブロックの再送を要求する再送要求を、前記第２の通信装置から受信する第２受信手段と、
前記再送要求に従って、前記ブロックを、前記第２の通信装置に送信する第３送信手段と、
前記処理が実行された結果を、前記第１の通信方式で各前記第３の通信装置から受信する第３受信手段とを備え、
各前記第２の通信装置は、
前記処理要求を、前記第１の通信方式で前記第１の通信装置から受信する第４受信手段と、
前記データを、前記第２の通信方式で前記第１の通信装置から受信する第５受信手段と、
前記処理要求に従って、前記データの一部に対して、前記処理を実行する処理手段と、
前記処理手段が前記処理を実行する際に、前記データの一部に該当する前記ブロックの受信が正常に完了していない場合、当該ブロックの再送を要求する再送要求を前記第１の通信装置に送信する再送要求手段と、
前記再送要求手段が送信した前記再送要求に従って前記第１の通信装置から送信された前記ブロックを受信する第６受信手段と、
前記処理手段が前記処理を実行した結果を、前記第１の通信方式で前記第１の通信装置に送信する第４送信手段とを備える
ことを特徴とする通信システム。
【請求項９】
第１受信手段と、第２受信手段と、処理手段と、再送要求手段と、第３受信手段と、送信手段とを備える通信装置で実行される通信方法であって、
前記第１受信手段が、複数のブロックに分割されたデータの一部に対する処理を要求する処理要求を、送達確認のある第１の通信方式で他の通信装置から受信する第１受信ステップと、
前記第２受信手段が、前記データを、送達確認のない第２の通信方式で前記他の通信装置から受信する第２受信ステップと、
前記処理手段が、前記処理要求に従って、前記データの一部に対して、前記処理を実行する処理ステップと、
前記再送要求手段が、前記処理ステップで前記処理が実行される際に、前記データの一部に該当する前記ブロックの受信が正常に完了していない場合、当該ブロックの再送を要求する再送要求を前記他の通信装置に送信する再送要求ステップと、
第３受信手段が、前記再送要求ステップで送信された前記再送要求に従って前記他の通信装置から送信された前記ブロックを受信する第３受信ステップと、
前記送信手段が、前記処理ステップで前記処理が実行された結果を、前記第１の通信方式で前記他の通信装置に送信する送信ステップとを含む
ことを特徴とする通信方法。
【請求項１０】
請求項９に記載の通信方法をコンピュータに実行させるための通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信システム、通信方法及び通信プログラムに関する。
【背景技術】
【０００２】
例えば、文字を認識したりバーコードを認識したりする画像処理は大量の計算を必要とするため、一般にCPU（Central Processing Unit）の処理能力を必要とする。CPUなどのコンピュータの処理能力が飛躍的に増大する現在においても、これらの画像処理の処理時間は無視できるほど小さな時間とはなっていない。大量の計算を短時間で行うために有効な方法の一つは、処理単位を小さく分割して、多数のコンピュータで分散処理させることである。具体的には、例えば、クライアントからの処理要求を受け付ける受付サーバＳ１と、処理対象の画像を記憶するストレージサーバＳ２と、複数の処理サーバＷ１〜Ｗｎとがネットワークを介して接続される分散処理システムがある。受付サーバＳ１は、外部から処理対象の画像データをストレージサーバＳ２に取り込み、受付サーバＳ１は、各処理サーバＷ１〜Ｗｎに対して当該画像データの各々異なる部分に対する処理を要求する処理要求を送信する。各処理サーバＷ１〜Ｗｎはそれぞれ、当該処理要求に従って、ストレージサーバＳ２にアクセスし、画像データを読み込んで処理を実行し、処理結果をレスポンスとして受付サーバＳ１に返す。受付サーバＳ１は、各処理サーバＷ１〜Ｗｎからの処理結果が全て得られた段階で、処理結果をクライアントに返す。このような分散システムでは、ストレージサーバＳ２がボトルネックとなりやすい。即ち、処理要求を受信した処理サーバＷ１〜Ｗｎが個別にストレージサーバＳ２から画像データを取得する時、ネットワークへの負荷が大きくなる。また、ストレージサーバＳ２が故障するとこの分散システム全体が動作不能となる恐れがある。
【０００３】
ところで、ネットワークを介して接続された一つの送信装置から複数の受信装置に対して同時にデータを送信する方法としては、UDP（User Datagram Protocol）マルチキャストを用いる方法が知られている。IPネットワークでデータ通信を行うプロトコルではTCP（Transmission Control Protocol）とUDPとが代表的であるが、TCPはコネクション型で送達確認を含む代わりに1対1の通信のみが可能であり、UDPはコネクションレス型で1対多の通信が可能な反面、送達確認の機能を持たない。そのためUDPによるマルチキャスト通信ではデータの欠損が問題となるため、アプリケーションレベルでのプロトコルで送達確認を実装することになる。例えば、すべての受信装置がデータの受信を確認するための送達確認を含むパケット（送達確認パケットという）を送信装置に送信し、送信装置からの送達確認を待って次のパケットを送信するか前のパケットを再送するという方法が考えられる。しかしこの方法では、送信装置への負担が大きくなり、またほとんどの受信装置にとって再送するパケットは無駄となる。
【０００４】
近年では、マルチキャストによるデータ通信の効率化を目的とした方法も多く提案されている。しかし、従来の方法では、すべての受信装置に等しくすべてのデータが受信されることを目的としている。例えば、複数のページの画像を表す画像データに対する画像処理をページ毎にそれぞれ最低１つのコンピュータに行わせることを目的とすると、各コンピュータで必要とする画像データはほんの一部分であり、大半の部分の再送は無駄になるという問題があった。上述の分散システムにおいては、受付サーバＳ１で画像データを処理サーバ毎に個別の処理単位に分割することも考えられる。しかし、データ形式によっては分割が容易でなく、受付サーバＳ１が分割のために画像データを変換するなどの処理に時間を要するため、スケールアウトに適しない場合がある。また、例えば、特許文献１には、送達確認と再送とを効率化する目的で、ファイルをブロックに分割し、順序番号をつけて送信し、全体の送信が完了した後に受信装置からの順序番号による指定に基づいて受信できなかった部分を再送する仕組みが開示されている。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、従来の技術では、全てのデータが全ての送信装置に到達しなくても良い場合にも、送達確認と再送とを効率化することは困難である。このため、このような場合にも、マルチキャストに基づく1対多の通信において、データの再送を必要最小限とし、より効率化することが望まれていた。
【０００６】
本発明は、マルチキャストに基づく1対多の通信において、データの再送を必要最小限とし、より効率化することが可能な通信装置、通信システム、通信方法及び通信プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上述した課題を解決し、目的を達成するために、本発明は、通信装置であって、複数のブロックに分割されたデータの一部に対する処理を要求する処理要求を、送達確認のある第１の通信方式で他の通信装置から受信する第１受信手段と、前記データを、送達確認のない第２の通信方式で前記他の通信装置から受信する第２受信手段と、前記処理要求に従って、前記データの一部に対して、前記処理を実行する処理手段と、前記処理手段が前記処理を実行する際に、前記データの一部に該当する前記ブロックの受信が正常に完了していない場合、当該ブロックの再送を要求する再送要求を前記他の通信装置に送信する再送要求手段と、前記再送要求手段が送信した前記再送要求に従って前記他の通信装置から送信された前記ブロックを受信する第３受信手段と、前記処理手段が前記処理を実行した結果を、前記第１の通信方式で前記他の通信装置に送信する送信手段とを備えることを特徴とする。
【０００８】
また、本発明は、第１受信手段と、第２受信手段と、処理手段と、再送要求手段と、第３受信手段と、送信手段とを備える通信装置で実行される通信方法であって、前記第１受信手段が、複数のブロックに分割されたデータの一部に対する処理を要求する処理要求を、送達確認のある第１の通信方式で他の通信装置から受信する第１受信ステップと、前記第２受信手段が、前記データを、送達確認のない第２の通信方式で前記他の通信装置から受信する第２受信ステップと、前記処理手段が、前記処理要求に従って、前記データの一部に対して、前記処理を実行する処理ステップと、前記再送要求手段が、前記処理ステップで前記処理が実行される際に、前記データの一部に該当する前記ブロックの受信が正常に完了していない場合、当該ブロックの再送を要求する再送要求を前記他の通信装置に送信する再送要求ステップと、第３受信手段が、前記再送要求ステップで送信された前記再送要求に従って前記他の通信装置から送信された前記ブロックを受信する第３受信ステップと、前記送信手段が、前記処理ステップで前記処理が実行された結果を、前記第１の通信方式で前記他の通信装置に送信する送信ステップとを含むことを特徴とする。
【０００９】
また、本発明は、上記の通信方法をコンピュータに実行させるためのプログラムである。
【発明の効果】
【００１０】
本発明によれば、マルチキャストに基づく1対多の通信において、データの再送を必要最小限とし、より効率化することが可能になる。
【図面の簡単な説明】
【００１１】
【図１】図１は、本実施の形態にかかる通信システムの構成を例示する図である。
【図２】図２は、受付サーバ２００の機能的構成を例示する図である。
【図３】図３は、処理サーバ３００の機能的構成を例示する図である。
【図４】図４は、ブロック管理部３０８が記憶する情報を例示する図である。
【図５】図５は、受付サーバ２００が行なう通信処理の手順を示すフローチャートである。
【図６】図６は、受付サーバ２００が処理サーバ３００に送信する処理要求のデータ構成を例示する図である。
【図７】図７は、各処理サーバ３００が行なう通信処理の手順を示すフローチャートである。
【図８】図８は、図７のステップＳ１４で処理を実行する手順を示すフローチャートである。
【図９】図９は、複数のページの画像を表すTIFF形式の画像データのデータ構成を簡略化して例示する図である。
【図１０】図１０は、再送要求のデータ構成を例示する図である。
【図１１】図１１は、一変形例にかかる処理要求のデータ構成を例示する図である。
【図１２】図１２は、一変形例にかかるステップＳ１４で処理を実行する手順を示すフローチャートである。
【図１３】図１３は、再送要求のデータ構成を例示する図である。
【図１４】図１４は、再送要求のデータ構成を例示する図である。
【図１５】図１５は、図１３に示される再送要求に従って受付サーバ２００が再送対象のブロックを処理サーバ３００に送信する際のパケットのデータ構成を例示する図である。
【発明を実施するための形態】
【００１２】
以下に添付図面を参照して、この発明にかかる通信装置、通信システム、通信方法及び通信プログラムの実施の形態を詳細に説明する。
【００１３】
図１は、本実施の形態にかかる通信システムの構成を例示する図である。通信システムは、クライアント１００と、受付サーバ２００と、複数の処理サーバ３００とを備える。クライアント１００と受付サーバ２００とはネットワークＮＴ１を介して接続される。受付サーバ２００と複数の処理サーバ３００とはネットワークＮＴ２を介して接続される。ネットワークＮＴ１，ＮＴ２は、例えば、ＬＡＮ（Local Area Network）、イントラネット、又はインターネットなどである。
【００１４】
このような通信システムにおいて、クライアント１００が、処理対象の画像データを含み当該画像データに対する処理を要求する処理要求を、ネットワークＮＴ１を介して受付サーバ２００に送信し、受付サーバ２００が、当該処理要求に従って、ネットワークＮＴ２を介して各処理サーバ３００に当該処理要求を各々送信する。各処理サーバ３００は当該処理要求に従って、処理を実行し、その処理結果をネットワークＮＴ２を介して受付サーバ２００に送信する。受付サーバ２００は、各処理サーバ３００から受信した処理結果をネットワークＮＴ１を介してクライアント１００に送信する。
【００１５】
次に、本実施の形態にかかるクライアント１００、受付サーバ２００及び処理サーバ３００のハードウェア構成について説明する。クライアント１００、受付サーバ２００及び処理サーバ３００はそれぞれ、装置全体を制御するＣＰＵ等の制御部と、各種データや各種プログラムを記憶するＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）等の主記憶部と、各種データや各種プログラムを記憶するＨＤＤ（Hard Disk Drive）やＣＤ（Compact Disk）ドライブ装置等の補助記憶部と、これらを接続するバスとを備えており、通常のコンピュータを利用したハードウェア構成となっている。また、クライアント１００には、情報を表示する表示部と、ユーザの指示入力を受け付けるキーボードやマウス等の操作入力部と、外部装置の通信を制御する通信Ｉ／Ｆ（interface）とが有線又は無線により各々接続される。これらは、クライアント１００と同様に受付サーバ２００及び処理サーバ３００に接続されるようにしても良いし、接続されなくても良い。
【００１６】
次に、このようなハードウェア構成において、受付サーバ２００のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図２は、受付サーバ２００の機能的構成を例示する図である。受付サーバ２００は、HTTPサーバ部２０１と、画像処理制御部２０２と、画像蓄積部２０３とを有する。HTTPサーバ部２０１と、画像処理制御部２０２とは、ＣＰＵのプログラム実行時にＲＡＭなどの主記憶部上に生成されるものである。画像蓄積部２０３は、ＨＤＤなどの補助記憶部に構成されるものである。
【００１７】
HTTPサーバ部２０１は、クライアント１００からの処理要求を受け付ける。この機能を細分化した機能として、HTTPサーバ部２０１は、リクエスト処理部２０４と、再送要求処理部２０５とを有する。リクエスト処理部２０４は、処理対象の画像データを含み当該画像データに対する画像処理を要求する処理要求をクライアント１００から受信し、当該処理要求に従った処理結果を当該クライアント１００に送信する。尚、クライアント１００からの処理要求は、例えば、HTTPのプロトコルに従ったHTTPリクエストにより送信される。HTTPのプロトコルに従った通信では、送達確認がある。再送要求処理部２０５は、後述するブロックの再送を要求する再送要求を処理サーバ３００から受信し、要求されたブロックを処理サーバ３００に送信する。尚、要求されたブロックの送信は、TCPによるコネクション型通信で行う。TCPによるコネクション型通信では、送達確認がある。
【００１８】
画像処理制御部２０２は、処理要求や処理対象の画像データの処理サーバ３００への送信、処理サーバ３００からの処理結果の取得及び処理対象の画像データを分割したブロックに関する後述のブロック情報の管理を行う。この機能を細分化した機能として、画像処理制御部２０２は、処理要求部２０６と、データ分割部２０７と、データブロック管理部２０８と、データ送信部２０９と、処理結果管理部２１０とを有する。
【００１９】
処理要求部２０６は、後述のブロック情報を含み処理対象の画像データに対する画像処理を要求する処理要求を各処理サーバ３００に送信し、当該処理要求に従って各処理サーバ３００が処理を実行した結果である処理結果を各処理サーバ３００から受信する。尚、処理要求の送信は、TCPによるコネクション型通信で行う。
【００２０】
データ分割部２０７は、処理対象の画像データを複数のブロックに分割する。データブロック管理部２０８は、データ分割部２０７が分割した各ブロックについて、処理対象の画像データにおける各ブロックの位置を特定するためのブロック情報を記憶し、これの削除やアクセスを制御することによって、ブロック情報を管理する。本実施の形態においては、ブロックの長さは固定長であるとし、ブロック情報は、ブロックの長さとブロックの開始点（オフセット）とを含む。
【００２１】
データ送信部２０９は、データ分割部２０７が処理対象の画像データから分割した複数のブロックをパケット単位で各処理サーバ３００に送信する。各パケットの送信は、UDPのマルチキャストにより行なう。UDPのマルチキャストでは、送達確認がない。尚、各処理サーバ３００のマルチキャストアドレス及び宛先ポートは主記憶部や補助記憶部に予め記憶されているものとする。
【００２２】
処理結果管理部２１０は、処理要求部２０６が各処理サーバ３００から受信した処理結果を記憶し、当該処理結果の受信状況に応じて、処理の終了を判断する。具体的には、処理結果管理部２１０は、処理要求部２０６が処理要求を送信した全ての処理サーバ３００から処理結果を受信した場合には、処理が終了したと判断する。そして、この場合、処理結果管理部２１０は、処理サーバ３００から受信した処理結果をクライアント１００に送信する。尚、処理結果の送信は、TCPによるコネクション型通信で行う。画像蓄積部２０３は、リクエスト処理部２０４が受信した処理要求に含まれる処理対象の画像データを記憶する。
【００２３】
次に、処理サーバ３００のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図３は、処理サーバ３００の機能的構成を例示する図である。処理サーバ３００は、リクエスト処理部３０１と、データ受信処理部３０２と、データ蓄積部３０３と、画像処理部３０４とを有する。リクエスト処理部３０１は、処理要求を受付サーバ２００から受信したり、当該処理要求に従って画像処理部３０４が処理を実行した結果である処理結果を受付サーバ２００に送信したりする。
【００２４】
データ受信処理部３０２は、処理対象の画像データの受信に関わる処理を行う。この機能を細分化した機能として、データ受信処理部３０２は、データ受信部３０５と、受信完了判定部３０６と、再送要求部３０７とを有する。データ受信部３０５は、受付サーバ２００からマルチキャストで送信された処理対象の画像データをパケット単位で受信し、リクエスト処理部３０１が受信した処理要求に含まれるブロック情報を参照して、受信したパケットをブロック毎に分類し、各ブロックをデータ蓄積部３０３に記憶させる。受信完了判定部３０６は、各ブロックについて受信が正常に完了しているか否かを判定する。再送要求部３０７は、受信が正常に完了していないと受信完了判定部３０６が判定したブロックについてその再送を要求する再送要求を受付サーバ２００に送信し、当該再送要求に従って受付サーバ２００から送信されたブロックを含むパケットを受信する。
【００２５】
データ蓄積部３０３は、受付サーバ２００から受信した処理対象の画像データをブロック毎に記憶する。この機能を細分化した機能として、データ蓄積部３０３は、ブロック管理部３０８と、データ格納部３０９とを有する。ブロック管理部３０８は、処理対象の画像データに属する各ブロックについて、その開始点と、受信が正常に完了しているか否かという受信完了判定部３０６の判定結果とを記憶する。例えば、ブロック管理部３０８は、各ブロックについての受信完了判定部３０６の判定結果を受信状態フラグによって記憶する。受信状態フラグは、受信が完了していると判定された場合は「1」を示し、受信が完了していないと判定された場合は「0」を示す。図４は、ブロック管理部３０８が記憶する情報を例示する図である。同図の例では、10個のブロックから構成される処理対象の画像データの各ブロックについての受信完了フラグ及び開始点が示されている。この例では、先頭からから3〜4番目及び10番目のブロックの受信が未完了であることが示されている。
【００２６】
また、ブロック管理部３０８は、画像処理部３０４が処理を実行する際に、処理対象の画像データに属する各ブロックうち処理対象のブロックについて、受信が正常に完了していると受信完了判定部３０６が判定している場合には、当該ブロックをデータ格納部３０９から読み出してこれを画像処理部３０４に渡す。一方、当該ブロックについて、受信が正常に完了していないと受信完了判定部３０６が判定している場合には、ブロック管理部３０８は、再送要求部３０７が送信した再送要求に従って受信したパケットに含まれるブロックを取得してこれを画像処理部３０４に渡す。データ格納部３０９は、処理対象の画像データをブロック単位で記憶する。
【００２７】
画像処理部３０４は、処理対象の画像データに属する各ブロックのうち処理対象のブロックを、ブロック管理部３０８を介して取得して、当該ブロックを用いて、処理要求によって要求された処理（例えば画像処理である）を実行し、当該処理を実行した結果である処理結果をリクエスト処理部３０１に返す。
【００２８】
次に、本実施の形態にかかる通信システムにおいて行う通信処理の手順について説明する。まず、受付サーバ２００が行なう通信処理の手順について図５を用いて説明する。受付サーバ２００は、リクエスト処理部２０４の機能により、処理対象の画像データを含み当該画像データに対して処理を要求する処理要求をクライアント１００から受信する（ステップＳ１）。尚、当該処理要求には、処理の際に用いる処理パラメータを含み得る。次いで、受付サーバ２００は、ステップＳ１で受信した処理要求に含まれる処理対象の画像データを画像蓄積部２０３に記憶する。そして、受付サーバ２００は、データ分割部２０７の機能により、処理対象の画像データを複数のブロックに分割する（ステップＳ２）。
【００２９】
具体的には、受付サーバ２００は、処理対象の画像データを、予め定められた長さ（固定長）のブロックに分割し、各ブロックに対して先頭から順に「0」から始まるブロック番号を付与する。ところで、UDPにより送信する１つのパケットで送信可能なデータのサイズは60Kb程度である。一次ブロックはこのサイズを超えているため、受付サーバ２００は、UDPによる送信が可能なサイズのパケットに各ブロックを分割し、各パケットに対して先頭から順に「0」から始まるシーケンス番号を付与する。また、受付サーバ２００は、データブロック管理部２０８の機能により、各ブロックの開始点を算出し、各ブロックの開始点と各ブロックの長さと含むブロック情報を記憶する。固定長のブロックの開始点は「0」にブロックの長さを順に足した値となる。
【００３０】
その後、受付サーバ２００は、処理要求部２０６の機能により、処理対象の画像データに対する処理を要求する処理要求を、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バイトのブロック１つとから構成されていることが認識できる。
【００３１】
また、受付サーバ２００は、データ送信部２０９の機能により、ステップＳ２で分割した各ブロックをパケット単位でUDPのマルチキャストにより各処理サーバ３００に送信する（ステップＳ４）。このとき送信されるパケット（UDPパケットという）は、UDPヘッダと、UDPペイロードとを含む。UDPヘッダは、送信元のポート及び送信先のポートと、パケットの長さと、チェックサムとを含む。UDPペイロードは、処理対象の画像データを識別するためのデータＩＤと、当該パケットの属するブロックに付与されたブロック番号と、当該パケットに付与されたシーケンス番号と、処理対象の画像データの一部であって当該パケットに相当するデータ本体とを含む。そして、受付サーバ２００は、処理対象の画像データの全てのブロックについて送信が完了すると、その旨を示す送信完了メッセージを各処理サーバ３００に送信する（ステップＳ５）。そして、受付サーバ２００は、各処理サーバ３００からの処理結果の送信を待機する。この待機中、受付サーバ２００は、ブロックの再送を要求する再送要求をTCPにより処理サーバ３００から受信した場合には、当該再送要求に従って、該当のブロックをTCPにより処理サーバ３００に送信する。
【００３２】
尚、ステップＳ３では、受付サーバ２００は、TCPにより処理要求を処理サーバ３００に送信しているため、当該処理要求を受信した旨を示す送達通知を処理サーバ３００から受信し、一定時間内に当該送達通知を受信していない処理サーバ３００に対しては、当該処理要求を再送する。また、受付サーバ２００は、再送要求に従って送信したブロックについても、当該ブロックを受信した旨を示す送達通知を処理サーバ３００から受信し、一定時間内に当該送達通知を受信していない処理サーバ３００に対しては、当該ブロックを再送する。再送要求については、処理サーバ３００の動作の説明と共に後ほど詳しく説明する。
【００３３】
次に、各処理サーバ３００が行なう通信処理の詳細な手順について図７を用いて説明する。処理サーバ３００は、リクエスト処理部３０１の機能により、処理要求を受付サーバ２００から受信し（ステップＳ１０）、データ受信処理部３０２の機能により、受付サーバ２００からマルチキャストで送信された処理対象の画像データをパケット単位で受信する（ステップＳ１１）。このとき、処理サーバ３００は、データ受信部３０５の機能により、ステップＳ１０で受信した処理要求に含まれるブロック情報を参照して、受信したパケットをブロック毎に分類すると共に、受信完了判定部３０６の機能により、各パケットのチェックサムを検査し、ブロック毎にシーケンス番号が連続しているか否かを判定することで、受信が正常に完了したか否かをブロック毎に判定し、各ブロックをデータ格納部３０９に記憶させる（ステップＳ１３）。具体的には、処理サーバ３００は、処理対象の画像データ全体の長さと同等の長さの仮ファイルをファイルシステム上に生成し、ブロックに属する全てのパケットについてチェックサムが正常であると判定した場合に当該ブロックの受信が正常に完了したと判定し、当該ブロックのデータを仮ファイルの対応部分に書き込むことで、各ブロックをデータ格納部３０９に記憶させる。そして、処理サーバ３００は、受付サーバ２００から送信された送信完了メッセージを受信すると、ブロック管理部３０８の機能により、各ブロックの開始点と、各ブロックについての受信完了判定部３０６の判定結果を示す受信状態フラグとを記憶する。
【００３４】
そして、処理サーバ３００は、画像処理部３０４の機能により、ステップＳ１０で受信した処理要求によって指定された処理対象の画像データのうち指定されたページに対して、指定された処理内容の処理を実行する（ステップＳ１４）。このとき、処理サーバ３００は、処理対象の画像データ全体を一度に読み出すのではなく、処理に必要となった段階でブロック単位でデータを読み出す。
【００３５】
ここで、ステップＳ１４で処理を実行する手順について図８を用いて説明する。処理サーバ３００は、指定されたページに対応する少なくとも１つ以上のブロックを特定する。図９は、複数のページの画像を表す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ページ目の画像データがあることを認識し、当該画像データを含むブロックを特定する。尚、当該画像データが複数のブロックに跨る場合には、処理サーバ３００は、複数のブロックを特定する。
【００３６】
そして、処理サーバ３００は、特定したブロックについて、ブロック管理部３０８の機能により、図４に例示される受信状態フラグを参照する(ステップＳ２０)。当該ブロックについて受信が正常に完了している場合には(ステップＳ２１：ＹＥＳ)、処理サーバ３００は、当該ブロックをデータ格納部３０９から読み出し(ステップＳ２２)、ステップＳ２５に進む。一方、当該ブロックについて受信が正常に完了していない場合には(ステップＳ２１：ＮＯ)、処理サーバ３００は、再送要求部３０７の機能により、受付サーバ２００との間にTCPコネクションが確立されていない場合にはTCPコネクションを確立した後、当該ブロックの再送を要求する再送要求をTCPにより受付サーバ２００に送信する(ステップＳ２３)。図１０は、再送要求のデータ構成を例示する図である。同図に示される再送要求では、プロトコルにはHTTPを用いている。同図では、URIのパス部分(「GET」で始まる行のGETの次にある固まり)で対象の画像データが指定され、そのデータ内の位置が「Range」で始まる行によって指定されている。即ち、図１０の例では、データＩＤ「54321」の画像データのうち、その開始点が「131072」で終了点が「196607」の範囲、即ち、65536バイトの先頭から３番目のブロックが、再送の対象のブロックとして指定されている。
【００３７】
図８の説明に戻る。当該再送要求に従って受付サーバ２００からHTTPのレスポンスとして送信されたパケットを処理サーバ３００は受信する。そして、処理サーバ３００は、当該再送要求によって再送が要求されたブロックに属する全てのパケットを受信すると、ブロック管理部３０８の機能により、当該ブロックについての受信状態フラグを「1」に更新し(ステップＳ２４)、ステップＳ２５に進む。ステップＳ２５では、処理サーバ３００は、画像処理部３０４の機能により、該当のブロックを用いて、画像処理部３０４の機能により、処理を実行する。その後、図７のステップＳ１５に戻り、処理サーバ３００は、リクエスト処理部３０１の機能により、処理結果を受付サーバ２００に送信する。
【００３８】
尚、ステップＳ１０では、処理サーバ３００は、TCPにより処理要求を受付サーバ２００から受信しているため、当該処理要求を受信した旨を示す送達通知を受付サーバ２００に送信する。また、ステップＳ２４で、処理サーバ３００は、再送要求に従ったブロックを受付サーバ２００から受信した場合にも、当該ブロックを受信した旨を示す送達通知を受付サーバ２００に送信する。ステップＳ１１で受信する画像データについては、送達確認は不要であるため、処理サーバ３００は送達通知を送信しない。
【００３９】
以上のように、送信側の受付サーバ２００は、処理対象のデータをブロックに分割して、送達確認のないマルチキャストにより送信する。受信側の処理サーバ３００は、受信が正常に完了していないデータ全ての再送を要求するのではなく、受信が正常に完了していないブロックが処理において必要となった場合にのみ再送を要求する。このように受信側での必要性に応じてデータを再送する構成によれば、1対多のデータ転送において、無駄な送達確認や、データの無駄な再送を抑制することができ、データ転送を効率化することができる。また、受付サーバ２００は、処理対象のデータを解析したり、処理サーバ毎にデータを物理的に分割したりする必要がなく、処理対象のデータのデータ構成を認識する必要がないため、受付サーバ２００の構成の複雑化を回避することができる。
【００４０】
[変形例]
なお、本発明は前記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。また、以下に例示するような種々の変形が可能である。
【００４１】
＜変形例１＞
上述した実施の形態において、受付サーバ２００で実行される各種プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また当該各種プログラムを、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成しても良い。処理サーバ３００についても同様である。
【００４２】
上述の実施の形態では、受付サーバ２００，処理サーバ３００はそれぞれ、コピー機能、プリンタ機能、スキャナ機能およびファクシミリ機能のうち少なくとも１つの機能を有し、各機能に応じた画像処理エンジンを備える画像処理装置であっても良い。
【００４３】
＜変形例２＞
上述の実施の形態では、処理対象の画像データを分割するブロックの長さは固定長であるとしたが、可変長であっても良い。このような構成において、受付サーバ２００の画像処理制御部２０２は、処理要求部２０６と、データ分割部２０７と、データブロック管理部２０８と、データ送信部２０９と、処理結果管理部２１０とに加え、データ解析部（不図示）を更に有する。データ解析部は、処理対象の画像データを解析して、その種別を判定する。データ分割部２０７は、データ解析部が判定した種別に応じて、処理対象の画像データのうち、２つ以上の処理サーバ３００が必要とする部分のデータは独立したブロックとなるよう、当該画像データを複数のブロックに分割する。例えば、処理対象の画像データが、図９に示されるように、複数ページの画像を表すTIFF形式の画像データである場合、IFDは、複数の処理サーバ３００から参照されるデータである。このため、IFDと画像データとは各々別のブロックとなるようにデータ分割部２０７は分割する。
【００４４】
IFDのサイズは画像データに比べて小さいが、このように、IFDを１つのブロックとして取り扱うことで、IFDをUDPにより送信した際にその受信が正常に完了する可能性が高くなる。また、受信が正常に完了しておらず再送することになったとしても、サイズが小さいため、IFDをブロックとして送信する際のネットワーク負荷を小さく抑えることができる。
【００４５】
＜変形例３＞
上述の実施の形態では、受付サーバ２００が各処理サーバ３００に送信する処理要求に含まれるブロック情報は、ブロック毎のハッシュ値を更に含んでも良い。具体的には、受付サーバ２００の処理要求部２０６は、処理要求を各処理サーバ３００に送信する際に、ブロック毎のMD5メッセージダイジェストによるハッシュ値を算出し、当該ハッシュ値を含むブロック情報を含む処理要求を各処理サーバ３００に送信する。図１１は、本変形例にかかる処理要求のデータ構成を例示する図である。同図に示される処理要求では、「hash_md5」により各ブロックのハッシュ値が示されている。
【００４６】
一方、処理サーバ３００は、このような処理要求を受信し、処理対象の画像データをパケット単位で受信すると、受信したパケットをブロック毎に分類し、各パケットのチェックサムを検査し、ブロック毎にシーケンス番号が連続しているか否かを判定すると共に、各ブロックについて、ハッシュ値を算出し、当該ハッシュ値と、処理要求に含まれるブロック情報に含まれるハッシュ値とをブロック毎に比較してこれらが一致するか否かを判定することによって、各ブロックのデータの正当性を判定する。そして、処理サーバ３００は、シーケンス番号が連続しているブロック及びハッシュ値が一致したブロックについて、受信が正常に完了したと判定し、当該ブロックをデータ格納部３０９に記憶させる。
【００４７】
以上のような構成によれば、ハッシュ値によりデータの正当性を検証することで、UDPパケットのチェックサムで検出できなかったエラーを検出することができる。
【００４８】
＜変形例４＞
上述の実施の形態においては、処理サーバ３００が再送を一度に要求するブロックは、複数であっても良い。この場合、画像処理部３０４による処理の実行と、再送要求部３０７による再送要求の送信とは順次ではなく、非同期で行なう。また、処理サーバ３００のブロック管理部３０８は、再送要求を蓄積する要求プール（不図示）を有する。要求プールは、例えばＲＡＭなどの主記憶部や補助記憶部に生成される。
【００４９】
図１２は、本変形例にかかるステップＳ１４で処理を実行する手順を示すフローチャートである。ここでは、画像処理部３０４による処理の実行と、再送要求部３０７による再送要求の送信と非同期で行なうため、スレッドを２つに分けている。前者を第１スレッドとし、後者を第２スレッドとする。ステップＳ２０〜Ｓ２１は上述の実施の形態と同様である。ステップＳ２１の判定結果が肯定的である場合、ステップＳ３０では、処理サーバ３００は、ブロック管理部３０８の機能により、処理に用いるブロックとして特定し且つ処理がまだ行われておらず且つ受信が正常に完了していると判定したブロックをデータ格納部３０９から読み出す。そして、処理サーバ３００は、該当のブロックを用いて、処理を実行する（ステップＳ３４）。その後、処理サーバ３００は、処理対象の全てのページについて処理を実行したか否かを判定する（ステップＳ３５）。当該判定結果が否定的である場合、ステップＳ２０に戻り、ステップＳ３５の判定結果が肯定的である場合、図７のステップＳ１５に進む。
【００５０】
ステップＳ２１の判定結果が否定的である場合、ステップＳ３１では、処理サーバ３００は、ブロック管理部３０８の機能により、処理に用いるブロックとして特定し且つ受信が正常に完了していないと判定したブロックの再送を要求する再送要求を要求プールに蓄積する。次いで、処理サーバ３００は、再送要求によって再送が要求されるブロックについて、ブロック管理部３０８の機能により、図４に例示される受信状態フラグを参照する(ステップＳ３２)。当該ブロックについて受信が正常に完了している場合には(ステップＳ３３：ＹＥＳ)、当該再送要求を削除対象として、ステップＳ３０に進み、当該ブロックについて受信が正常に完了していない場合には(ステップＳ３３：ＮＯ)、ステップＳ３２に戻る。
【００５１】
一方、予め待機している第２スレッドにおいて、ステップＳ４０では、処理サーバ３００は、ブロック管理部３０８の機能により、要求プールに蓄積されている再送要求があるか否かを判定する。当該判定結果が肯定的である場合、ステップＳ４１では、処理サーバ３００は、ブロック管理部３０８の機能により、要求プールに蓄積されている再送要求を読み出す。次いで、処理サーバ３００は、再送要求部３０７の機能により、受付サーバ２００との間にTCPコネクションが確立されていない場合にはTCPコネクションを確立する。このTCPコネクションは、連続するブロックの再送が完了するまで利用する。そして、処理サーバ３００は、要求プールから読み出した再送要求を参照して、再送が要求されているブロックを識別し、当該識別結果に応じて、各ブロックの再送要求をTCPにより受付サーバ２００に送信する。具体的には、要求プールに複数の再送要求が蓄積されており、各再送要求によって再送が要求されているブロックの位置が処理対象の画像データにおいて連続している場合、処理サーバ３００は、連続しているブロックの先頭のブロックの開始点と、最後尾のブロックの終了点とを指定した再送要求をTCPにより受付サーバ２００に送信する。要求プールに複数の再送要求が蓄積されていても、各再送要求によって再送が要求されているブロックの位置が処理対象の画像データにおいて連続していない場合、処理サーバ３００は、各ブロックの再送を要求する再送要求をブロック毎に送信する。
【００５２】
図１３〜１４は、再送要求のデータ構成を例示する図である。これらの図に示される再送要求では、図６に示される処理要求と同様に、プロトコルにはHTTPを用い、データ形式にはJSONを用いている。各図に示される再送要求によって、データＩＤ「54321」の画像データについて、連続しない２つのブロックの再送が各々要求されている。図１５は、図１３に示される再送要求に従って受付サーバ２００が再送対象のブロックを処理サーバ３０に送信する際のパケットのデータ構成を例示する図である。これらのパケット及び再送要求では、「Connection: Keep-Alive」というコマンドが指定されているので、受付サーバ２００と処理サーバ３００との間のTCPコネクションは再送対象のブロックが送信された後も維持され、当該TCPコネクションを利用して、続く処理サーバ３００からの再送要求が送信され得る。以上のようにして、処理サーバ３００は、再送要求によってブロックを取得してこれをデータ格納部３０９に記憶させ、上述の実施の形態と同様にして、ブロック管理部３０８の機能により、再送要求によって取得したブロックについての受信状態フラグを「1」に更新し、その後、要求プールに蓄積された削除対象の再送要求を削除する。ステップＳ４１の後、ステップＳ４０に戻る。尚、要求プールに蓄積されている再送要求がなくなった場合（ステップＳ４０：ＮＯ）、処理サーバ３００は、受付サーバ２００との間で確立したTCPコネクションをクローズし、要求プールに新たな再送要求が蓄積されるまで待機する。
【００５３】
以上のように、画像処理部３０４による処理の実行と、ブロック管理部３０８によるブロックの読み出し又は再送要求部３０７によるブロックの取得とを非同期で並行して行なうことにより、処理対象のブロックの取得を待機する時間を低減し、処理をスムーズに実行させることができ、全体の処理時間の増加を抑制することができる。また、連続するブロックについては一度にその再送を要求することができ、データの再送をより効率化することができる。
【００５４】
また、画像処理部３０４が処理を実行する際に必要となる全てのブロックを予め特定できる場合、各ブロックの読み出しを予め行うことにより、処理の実行とは非同期に該当のブロックの取得を行うことができる。例えば、図９に例示した複数のページの画像を表すTIFF形式の画像データについて、処理対象のページとして2ページと4ページとが処理要求によって指定されている場合、処理サーバ３００は、以下のようにして必要となる全てのブロックを予め認識することができる。
【００５５】
処理サーバ３００は、まず、画像データのTIFFヘッダに含まれる1ページ目に対応するIFDの開始点を参照して、1ページ目に対応するIFDを読み出し、2ページ目に対応するIFDの開始点を参照する。2ページ目に対応するIFDから3ページ目に対応するIFDまでの間は2ページ目の画像データに相当する。このため、処理サーバ３００は、ブロック管理部３０８の機能により、2ページ目の画像データを含むブロックをデータ格納部３０９から読み出す。このとき、処理サーバ３００は、上述の実施の形態と同様にして、受信状態フラグを参照し、当該ブロックの受信が正常に完了していない場合には、再送要求部３０７の機能により、再送要求を受付サーバ２００に送信して、当該ブロックを受付サーバ２００から取得する。その後、処理サーバ３００は、当該ブロックを用いて、画像処理部３０４の機能により、処理を実行する。
【００５６】
更に、処理サーバ３００は、4ページ目に対応するIFDを読み出し、5ページ目に対応するIFDの開始点を参照する。4ページ目に対応するIFDから5ページ目に対応するIFDまでの間は4ページ目の画像データであるので、処理サーバ３００は、画像処理部３０４の機能による2ページ目の画像データを含むブロックを用いた処理の実行と並行して、ブロック管理部３０８の機能により、4ページ目の画像データを含むブロックをデータ格納部３０９から読み出す。このとき、処理サーバ３００は、上述の実施の形態と同様にして、受信状態フラグを参照し、当該ブロックの受信が正常に完了していない場合には、再送要求部３０７の機能により、再送要求を受付サーバ２００に送信して、当該ブロックを受付サーバ２００から取得する。その後、処理サーバ３００は、当該ブロックを用いて、画像処理部３０４の機能により、処理を実行する。
【００５７】
このように、処理対象の全てのブロックを予め特定して、ブロック管理部３０８によるブロックの読み出し又は再送要求部３０７によるブロックの取得と、画像処理部３０４による処理の実行とを非同期で並行して行なうことにより、処理対象のブロックの取得を待機する時間をより低減し、処理をよりスムーズに実行させることができ、処理全体の時間をより低減することができる。
【００５８】
＜変形例５＞
上述の実施の形態においては、複数のブロックに分割する処理対象のデータを画像データであるとし、受付サーバ２００は、処理対象の画像データについて、各々異なるページに対して各処理サーバ３００が各々処理を実行するよう、各ページに対して処理を要求する処理サーバ３００に各々送信した。しかし、処理の単位はページに限らず、また、処理対象のデータは画像データに限らず、受付サーバ２００は、処理対象のデータについて、各々異なる部分に対して各処理サーバ３００が各々処理を実行するよう、当該データの一部に対して処理を要求する処理サーバ３００に各々送信すれば良い。
【００５９】
また、当該データに対して分散して実行する処理（分散処理）は、画像処理に限らない。例えば、複数のブロックに分割する処理対象のデータは、音声を表す音声データであって、当該音声データに対する分散処理は、音声を認識する音声認識処理であっても良い。その他、固定長のレコードからなる巨大なデータに対して、分散処理を行う場合に本実施の形態の構成を適用しても良い。
【符号の説明】
【００６０】
１００  クライアント
２００  受付サーバ
２０１  HTTPサーバ部
２０２  画像処理制御部
２０３  画像蓄積部
２０４  リクエスト処理部
２０５  再送要求処理部
２０６  処理要求部
２０７  データ分割部
２０８  データブロック管理部
２０９  データ送信部
２１０  処理結果管理部
３００  処理サーバ
３０１  リクエスト処理部
３０２  データ受信処理部
３０３  データ蓄積部
３０４  画像処理部
３０５  データ受信部
３０６  受信完了判定部
３０７  再送要求部
３０８  ブロック管理部
３０９  データ格納部
ＮＴ１，ＮＴ２  ネットワーク
【先行技術文献】
【特許文献】
【００６１】
【特許文献１】特開２００２−１６９７３８号公報
【図１】
2011044823.tif 000003
【図２】
2011044823.tif 000004
【図３】
2011044823.tif 000005
【図４】
2011044823.tif 000006
【図５】
2011044823.tif 000007
【図６】
2011044823.tif 000008
【図７】
2011044823.tif 000009
【図８】
2011044823.tif 000010
【図９】
2011044823.tif 000011
【図１０】
2011044823.tif 000012
【図１１】
2011044823.tif 000013
【図１２】
2011044823.tif 000014
【図１３】
2011044823.tif 000015
【図１４】
2011044823.tif 000016
【図１５】
2011044823.tif 000017