データ送信装置及び方法
【課題】データ送信装置及び方法を提供すること。
【解決手段】データ送信装置は、ディスクリーダと通信部を備える。ディスクリーダは、ファイルブロックを一つ又は複数のマイクロブロックに区分し、一つ又は複数のマイクロブロックの各々のサイズに対応するデータを複数のファイルから読み出して、複数のマイクロブロックに順次に記録し、通信部は、一つ又は複数のマイクロブロックにデータが記録されると、ファイルブロックをデータ受信装置に送信する。
【解決手段】データ送信装置は、ディスクリーダと通信部を備える。ディスクリーダは、ファイルブロックを一つ又は複数のマイクロブロックに区分し、一つ又は複数のマイクロブロックの各々のサイズに対応するデータを複数のファイルから読み出して、複数のマイクロブロックに順次に記録し、通信部は、一つ又は複数のマイクロブロックにデータが記録されると、ファイルブロックをデータ受信装置に送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ送信装置及び方法に関し、さらに詳細には、ファイルのパッケージ送信及びレジュームダウンロード送信が可能なデータ送信装置及び方法に関する。
【背景技術】
【０００２】
従来、多数のファイルを送信する場合、送信しようとする一つのファイルに対するコントロールメッセージを送信し、その一つのファイルの送信が完了したというコントロールメッセージを受信した後、次のファイルを順次に送信する。このような送信方式は、サーバとクライアントとの間で一つのＴＣＰ（Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）接続を確立して該当チャネルを介してデータを送受信する動作を行う場合でも多数のＴＣＰストリームをオープンしてデータを並列に送信する場合でもすべて同様である。
【０００３】
しかしながら、従来の方式によってファイルを送信する場合に、コントロールメッセージの送信時には、実際のデータを送信することができず、これによってパケットロスが多く発生したり、ＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）が長いネットワーク上では送信効率が急激に落ちるという結果がもたらされる。また、ネットワークＢＤＰ（Ｂａｎｄｗｉｄｔｈ Ｄｅｌａｙ Ｐｒｏｄｕｃｔ）より小さなサイズのファイル一つを送信する場合、ネットワークを効率的に使用することができないので、非効率的な送信がなされるという問題がある。このような問題を解決するために、多数のファイルを圧縮しパック（ｐａｃｋ）して一つのファイルで送信する方法がある。しかし、このような場合に圧縮及び圧縮の解除に時間が長くかかるという不便が発生し、その結果、圧縮によりデータのサイズを減らして短くした送信時間より、圧縮・復元にかかる時間の方が長くなり、送信がより遅くなる現象が発生する。
【０００４】
また、並列ＴＣＰストリーム送信方式を使用する場合に、単一ＴＣＰストリーム送信では発生しない送信の逆転現象が発生する。これは、単一ＴＣＰストリーム送信の場合では、先に送信されたデータが必ず先に到着することが保証されることに対し、並列ＴＣＰストリーム送信方式の場合では、第１番目のストリームを介して送信されるデータが第２番目のストリームを介して送信されるデータより先に送信されても、第２番目のストリームのデータより先に到着することが保証されないためである。
【０００５】
また、従来の並列ＴＣＰストリーム送信の場合、上述したようにデータの順次的な送信が保証されないので、ファイルのレジュームダウンロードを適用することが困難である。また、多量のファイルを並列ＴＣＰストリーム送信方式で送信する場合に、レジュームダウンロードが不可能であるか、既に送信されたデータに対しても再送信が起きるので、送信効率が低下する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の例示的な実施形態によれば、多数のファイルをリアルタイムでパッケージ送信することによって、ファイルを個別に送信する時に発生するコントロールメッセージの回数を最小化し、ＴＣＰ効率性を改善できるデータ送信装置及び方法を提供することである。
【０００７】
また、本発明の例示的な実施形態によれば、多数のファイルをパッケージ送信する際に一部のデータの送信が欠落されるか、又は送信が停止される場合に、レジュームダウンロード機能を保証できるデータ送信装置及び方法を提供することにある。
【課題を解決するための手段】
【０００８】
本発明の例示的な一実施形態におけるデータ送信装置は、複数のファイルを送信するデータ送信装置であって、ファイルブロックを一つ又は複数のマイクロブロックに区分し、前記一つ又は複数のマイクロブロックの各々のサイズに対応するデータを前記複数のファイルから読み出して、前記一つ又は複数のマイクロブロックに順次に記録するディスクリーダと、前記ファイルブロックに含まれる一つ又は複数のマイクロブロックにデータが記録されると、前記ファイルブロックをデータ受信装置に送信する通信部と、を備える。
【０００９】
一方、本発明の他の例示的な実施形態におけるデータ受信装置は、データ送信装置から送信されるファイルブロック（データ送信単位）を受信する通信部と、前記受信されたファイルブロックが一つ又は複数のマイクロブロック（少なくとも一つ以上のファイルのデータが記録される単位）を含む場合に、マイクロブロック単位でデータを読み出して格納媒体に記録するディスクライターと、を備える。
【００１０】
一方、本発明の他の例示的な実施形態におけるデータ送信方法は、複数のファイルを送信するデータ送信方法であって、ファイルブロックを一つ又は複数のマイクロブロックに区分し、前記一つ又は複数のマイクロブロックの各々のサイズに対応するデータを前記複数のファイルから読み出して、前記一つ又は複数のマイクロブロックに順次に記録するステップと、前記ファイルブロックに含まれる一つ又は複数のマイクロブロックにデータが記録されると、前記ファイルブロックをデータ受信装置に送信するステップと、を含む。
【００１１】
一方、本発明の他の例示的な実施形態におけるデータ受信方法は、データ送信装置から送信されるファイルブロック（データ送信単位）を受信するステップと、前記受信されたファイルブロックが一つ又は複数のマイクロブロック（少なくとも一つ以上のファイルのデータが記録される単位）を含む場合に、マイクロブロック単位でデータを読み出して格納媒体に記録するステップと、を含む。
【発明の効果】
【００１２】
本発明の例示的な実施形態におけるデータ送受信装置及び方法の少なくとも１つは、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋｓ）環境で使用される場合に通信効率が高い。ＷＡＮ環境の場合に、パケットロス（Ｐａｃｋｅｔ Ｌｏｓｓ）やＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）が大きいので、ＴＣＰプロトコルの特性上、ネットワークの帯域幅の少なくとも一部を使用できない場合が発生する。すなわち、パケットロスが発生するため、ウィンドウサイズを減らすことにより、送信できるパケットの量が減るか、又はアクナリッジメントを受信することができなくてウィンドウを空けることができないことにより、送信速度が顕著に落ちる状況が発生することがある。これを解決するために、本実施形態では、多数のファイルをリアルタイムでパック（ｐａｃｋ）して送信することによって、ファイルを順次に送信する際に送信開始と終了において発生するコントロールメッセージを減らすことができる。コントロールメッセージが送信される間にファイルのデータは送信されないので、コントロールメッセージを減らすことによって、ＴＣＰのデータの送信効率を大きく改善できる。また、アプリケーション層でファイルをパックしてＴＣＰ層にフォワードすることによって、ＴＣＰウィンドウより小さなデータを送信する場合を最小とし、ＴＣＰウィンドウより大きさが小さいデータを送信する際に発生するＴＣＰプロトコルの非効率的な動作を改善し、その結果、ファイルの送信時間を大きく減少させることができる。また、並列ＴＣＰストリームを使用することによって、ＴＣＰストリームが有するウィンドウを足し合せた分だけのデータを一度に送ることができ、その結果、データの送信時に衝突状況が発生しても、単一ＴＣＰストリームを利用した送信より、より多くのデータを送信することができる。
【００１３】
また、本発明の例示的な実施形態におけるデータ送受信装置及び方法の少なくとも１つは、オフセットとファイルの全体サイズに対する情報を利用することによって、並列ＴＣＰストリーム送信においてファイルの逆転現象無しにレジュームダウンロードを実現することができる。また、送信されたファイルのオフセットを利用してレジュームダウンロードを行うことによって、既に送信されたデータの重複送信を防止し、その結果、重複送信時に発生する送信の無駄を減らすことができる。また、多数のファイルをグループに分けてリストをまず送信して、レジュームダウンロードするファイルを比較決定する動作と、レジュームダウンロードするファイルのデータを送信する動作とを同時に行うことによって、データの送信効率を上げることができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の例示的な実施形態に係るデータの並列送信のための送受信システムを示す図である。
【図２】本発明の例示的な第１の実施形態に係るデータの並列送信のための第１データ送信装置及び第１データ受信装置を示すブロック図である。
【図３】本発明の例示的な実施形態に係るファイルブロックの構造を示す図である。
【図４Ａ】本発明の例示的な実施形態に係る一つのマイクロブロックを含むファイルブロックの構造を示す図である。
【図４Ｂ】本発明の例示的な実施形態に係る一つのマイクロブロックを含むファイルブロックの構造を示す図である。
【図５】本発明の例示的な第２の実施形態に係るデータの並列送信のための第２データ送信装置及び第２データ受信装置を示すブロック図である。
【図６】本発明の例示的な実施形態に係る送信ファイルリストの構造を示す図である。
【図７】本発明の例示的な実施形態に係るメタファイルの構造を示す図である。
【図８】本発明の例示的な実施形態に係るレジュームダウンロードリストの構造を示す図である。
【図９】本発明の例示的な第１の実施形態に係るデータの並列送信方法を説明するためのフローチャートである。
【図１０】図９に示すデータの並列送信方法をさらに詳細に説明するためのフローチャートである。
【図１１】本発明の例示的な実施形態に係るデータの並列受信方法を説明するためのフローチャートである。
【図１２】本発明の例示的な他の実施形態に係るデータの並列送受信方法を説明するためのフローチャートである。
【図１３】図１２のステップＳ１２３０をさらに詳細に示すフローチャートである。
【発明を実施するための形態】
【００１５】
以上の本発明の目的、他の目的、特徴及び利点は、添付された図面と関連した以下の好ましい実施形態により容易に理解されるはずである。しかしながら、本発明は、ここで説明される実施形態に限定されず、他の形態で具体化されてもよい。むしろ、ここで紹介される実施形態は、開示された内容が徹底かつ完全になるように、そして当業者に、本発明の思想を十分に理解してもらうために提供されるものである。
【００１６】
本明細書において、ある構成要素が他の構成要素上にあると言及される場合には、それは、他の構成要素上に直接形成される場合もあり、それらの間に第３の構成要素が介在される場合もあることを意味する。
【００１７】
本明細書において第１、第２などの用語が構成要素を述べるために使用された場合、これらの構成要素がこのような用語により限定されてはならない。これらの用語は、単にある構成要素を他の構成要素と区別させるために使用されたものに過ぎない。ここで説明され例示される実施形態は、それの相補的な実施形態も含む。
【００１８】
また、あるエレメント（または構成要素）が他のエレメント（または構成要素）上で動作または実行されると言及されるとき、そのエレメント（または構成要素）は、他のエレメント（または構成要素）が動作または実行される環境で動作または実行されるか、または他のエレメント（または構成要素）と直接または間接的に相互作用により動作または実行されると理解されなければならない。
【００１９】
あるエレメント、構成要素、装置、またはシステムが、プログラム若しくはソフトウェアからなる構成要素を含むと言及される場合には、明示的な言及がなくても、そのエレメント、構成要素、装置、またはシステムは、そのプログラム若しくはソフトウェアが実行または動作するのに必要なハードウェア（例えば、メモリ、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等）や他のプログラムまたはソフトウェア（例えば、オペレーティングシステム（ＯＳ）やハードウェアを駆動するのに必要なドライバ等）を含むと理解されなければならない。
【００２０】
また、あるエレメント（または構成要素）が具現化されるに当たって、特別な言及がない限り、そのエレメント（または構成要素）は、ソフトウェア、ハードウェア、またはソフトウェア及びハードウェアのうち、如何なる形態によっても具現化可能であると理解されなければならない。
【００２１】
本明細書で使用された用語は、実施形態を説明するためのものであって、本発明を限定するものではない。本明細書において、単数形は、特に言及しない限り、複数形も含む。明細書で使用される「含む」と言及された構成要素は、一つ以上の他の構成要素の存在又は追加を排除しない。
【００２２】
以下、図面を参照して本発明を詳細に説明する。以下の特定の実施形態を述べるにおいて、様々に特定された内容は、発明をさらに具体的に説明し、理解を助けるために作成された。しかしながら、本発明を理解することができる程度のこの分野における知識を有した読者は、このような様々に特定された内容がなくても、本発明が実施可能であることを認知できる。ある場合には、周知で発明と大きく関連のない技術的内容は、本発明を説明するにあたって、特別な理由がなくでも、読者の混乱を引き起こさないようにあえて述べないこともあることを予め言及しておく。
【００２３】
図１は、本発明の例示的な実施形態に係るデータの並列送信のための送受信システムを示す図である。
【００２４】
図１に示すように、データの並列送信のための送受信システムは、データ送信装置１０とデータ受信装置２０とを備えることができる。データ送信装置１０は、後述する第１データ送信装置１００又は第２データ送信装置５００である。また、データ受信装置２０は、第１データ受信装置２００又は第２データ受信装置６００である。
【００２５】
データ送信装置１０は、ファイルの送信リクエストを受信すると、ｉ）ファイルの属性情報を含む基本制御情報とｉｉ）ファイルを送信するソケット（ｓｏｃｋｅｔ）を一つ以上生成できる。
【００２６】
ソケットは、ファイルの送信のためにデータ送信装置１０とデータ受信装置２０とを接続するソフトウェアであって、一つのソケットは、一つのストリームを構成できる。データ送信装置１０とデータ受信装置２０との間には、データの並列送信のための複数のストリーム（Ｓ１、Ｓ２、．．．、ＳＮ、Ｎは、整数）が提供される。複数のストリーム（Ｓ１、Ｓ２、．．．、ＳＮ）は、少なくとも一つの通信ポートに割り当てられてもよく、各ストリームは、互いに異なる帯域幅を有するマルチチャネルにより具現化されてもよい。一例として、データ送信装置１０とデータ受信装置２０とは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）チャネルを介して、ファイルを並列ストリーミング送信方式で送受信できるが、これに限定されない。
【００２７】
基本制御情報は、ファイルの送信のために最初に第１データ送信装置１０と第１データ受信装置２０との間で共有される情報である。基本制御情報は、送信するファイルのファイル名、ファイルサイズ、ストリームの個数、ディスクバッファサイズ、全体ブロック個数、ソケットバッファサイズ、ＩＰアドレス、ポート情報及びセッションＩＤ（Ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）などの情報を含むことができる。ストリームの個数は、ファイル送信に使用することができるストリームの最大接続個数で、ディスクバッファサイズは、ディスク（例えば、第２格納媒体２５０（図２参照））にデータを書き込むためにバッファに割り当てられたブロックのサイズであり、ソケットバッファサイズは、送信プロトコルのカーネル（Ｋｅｒｎｅｌ）端で使用するバッファのサイズであり、ＩＰアドレスは、データ送信に用いられるＩＰのアドレスであり、ポート情報は、データ送信に用いられるポートの情報であり、セッションＩＤは、各ストリームのＩＤである。
【００２８】
図２は、本発明の例示的な第１の実施形態に係るデータの並列送信のための第１データ送信装置１００、及び第１データ受信装置２００を示す機能ブロック図である。
【００２９】
図２に示すように、第１データ送信装置１００は、第１格納媒体１１０、第１インアクティブブロックプール１２０、第１ディスクリーダ（Ｄｉｓｋ Ｒｅａｄｅｒ）１３０、第１アクティブブロックプール１４０、第１通信部１５０及び第１制御部１６０を備えることができる。
【００３０】
第１格納媒体１１０には、第１データ受信装置２００に送信する複数のファイルが格納されるとよい。第１格納媒体１１０は、ハードディスクドライブのような大容量格納装置であってもよい。
【００３１】
第１インアクティブブロックプール（ｉｎａｃｔｉｖｅ ｂｌｏｃｋ ｐｏｏｌ）１２０は、データが記録されていない複数のファイルブロックをメモリの効率的な使用のために格納（又は保管）する。ファイルブロックは、第１ディスクリーダ１３０が第１格納媒体１１０に格納された複数のファイルのうち、送信するファイルを記録する時に使用されるとよい。第１インアクティブブロックプール１２０は、例えばメモリのような格納装置から構成されてもよく、後述する第１アクティブブロックプール１４０、第２インアクティブブロックプール２２０、第２アクティブブロックプール２３０、第３インアクティブブロックプール５３０、第３アクティブブロックプール５５０、第４インアクティブブロックプール６３０、及び第４アクティブブロックプール５５０もやはり、メモリのような格納装置から構成されてもよい。一方、第１インアクティブブロックプール１２０と第１アクティブブロックプール１４０とが図２で各々別途の機能ブロックとして示されている。しかし、これらは、それぞれ物理的に別途のメモリとして具現化されることと制限的に解釈されてはならず、第１インアクティブブロックプール１２０と第１アクティブブロックプール１４０は、１つ又は３つ以上のメモリによっても具現化されてもよい。そして、ｉ）第２インアクティブブロックプール２２０と第２アクティブブロックプール２３０、ｉｉ）第３インアクティブブロックプール５３０と第３アクティブブロックプール５５０、及びｉｉｉ）第４インアクティブブロックプール６３０と第４アクティブブロックプール５５０も、やはり、物理的なメモリの個数に限定されて具現化されるものではない。
【００３２】
以下、複数のファイルのうち、第１データ受信装置２００にパッケージ送信するファイルを「送信対象ファイル」とし、送信対象ファイルの一例として第１ファイルと第２ファイルとを例に挙げて説明する。
【００３３】
「パッケージ送信」は、一つのファイルブロックに第１ファイルを記録した後にもファイルブロックに他のファイルを記録できる空き空間がある場合に、第２ファイルの全体又は一部を空き空間に記録することによって、第１ファイルと第２ファイルとを一つのファイルブロックに送信することを意味する。パッケージ送信時に、一つのファイルブロックには、第１ファイルの全体と第２ファイルの全体が記録されたり、第１ファイルの全体と第２ファイルの一部が記録されたり、第１ファイルの一部と第２ファイルの一部が記録されたり、第１ファイルの一部と第２ファイルの全体が記録されたりしてもよい。
【００３４】
図３は、本発明の例示的な実施形態に係るファイルブロックの構造を示す図である。
【００３５】
図３に示すように、ファイルブロック（ＦＢ：Ｆｉｌｅ Ｂｌｏｃｋ）は、ファイルブロックヘッダ（ＦＨ：Ｆｉｌｅｂｌｏｃｋ Ｈｅａｄｅｒ）とファイルブロックペイロード（ＦＰ：Ｆｉｌｅｂｌｏｃｋ Ｐａｙｌｏａｄ）とに区分される。ＦＨには、ファイルブロックがデータを記録していることを表すタグ情報、ＦＰのサイズ、ファイルブロックの圧縮有無を表すフラグが記録されるとよい。ＦＰには、ＦＰのサイズに相当するデータと、記録されたデータの属性情報が記録されるとよい。図３に示すように、データが記録されていない空きファイルブロックは、第１インアクティブブロックプール１２０に格納されるとよい。
【００３６】
第１ディスクリーダ１３０は、第１インアクティブブロックプール１２０から空きファイルブロックを読み出してファイルブロックを一つ又は複数のマイクロブロックに区分できる。
【００３７】
ここで、マイクロブロックは、マイクロブロックヘッダ（ＭＨ：Ｍｉｃｒｏｂｌｏｃｋ Ｈｅａｄｅｒ）とマイクロブロックペイロード（ＭＰ：Ｍｉｃｒｏｂｌｏｃｋ Ｐａｙｌｏａｄ）とを備えるとよい。そして、第１ディスクリーダ１３０は、各々のマイクロブロックのサイズに対応するデータを送信対象ファイルから読み出して、該当するマイクロブロックに順次に記録することができる。すなわち、第１ディスクリーダ１３０は、ＦＰのサイズと第１ファイルのサイズとを比較して、一個のマイクロブロック又は複数のマイクロブロックを生成することによってファイルブロックを分割することができる。マイクロブロックは、少なくとも一つ以上のファイルのデータが記録される単位であって、データが記録されるサイズは自在に変化する。
【００３８】
詳細に説明すれば、第１ディスクリーダ１３０は、ＦＰのサイズと第１ファイルのサイズとに応じて、ＦＰに一つ以上の論理的なマイクロブロックを生成できる。例えば、一つのファイルブロックに記録できるデータのサイズが第１ファイルより小さいか、又は同じであると、第１ディスクリーダ１３０は、ファイルブロックに図４Ａのように、一つのマイクロブロックをファイルブロックに生成できる。また、一つのファイルブロックに記録できるデータのサイズが第１ファイルより大きいと、第１ディスクリーダ１３０は、ファイルブロックに図４Ｂのように少なくとも２つのマイクロブロックを生成してファイルブロックに記録するとよい。
【００３９】
図４Ａは、本発明の例示的な実施形態に係る一つのマイクロブロックを備えるファイルブロックの構造を示す図である。
【００４０】
図４Ａに示すように、ファイルブロックは、ＦＨとＦＰとに区分され、ＦＰは、一つのＭＨと一つのＭＰとに区分される。ＭＨには、ＭＨ ｓｉｚｅ、ｏｆｆｓｅｔ、ｌｅｎｇｔｈ、Ｆｉｌｅ ｓｉｚｅ及びｆｉｌｅｐａｔｈが記録されてもよい。ＭＨ ｓｉｚｅは、ＭＨのサイズであり、ｏｆｆｓｅｔは、第１格納媒体１１０から読み出してＭＰに記録されたデータが第１ファイルのどの位置に属するかを表すデータアドレスであり、ｌｅｎｇｔｈは、ＭＰのサイズ（すなわち、ＭＰに記録されたデータの実際のサイズ）であり、Ｆｉｌｅ ｓｉｚｅは、データが属する第１ファイルの全体のサイズであり、ｆｉｌｅｐａｔｈは、第１ファイルが第１格納媒体１１０に格納されたディレクトリとファイル名を含むとよい。ＭＰには、ＭＰのサイズ以下のサイズのデータが記録されるとよい。
【００４１】
図４Ｂは、本発明の例示的な実施形態に係る一つのマイクロブロックを含むファイルブロックの構造を示す図である。
【００４２】
図４Ｂに示すように、ファイルブロックは、ＦＨとＦＰとに区分され、ＦＰは、複数のマイクロブロックヘッダＭＨ１、ＭＨ２、ＭＨ３と複数のマイクロブロックペイロードＭＰ１、ＭＰ２、ＭＰ３とに区分される。図４Ｂには、３個のマイクロブロックＭＢ１、ＭＢ２、ＭＢ３が示されているが、これは、一例に過ぎず、２個もしくは４個以上のマイクロブロックにより、ファイルブロックが形成されてもよい。
【００４３】
各ＭＨ１、ＭＨ２、ＭＨ３には、図４Ａを参照して説明されたＭＨ ｓｉｚｅ、ｏｆｆｓｅｔ、ｌｅｎｇｔｈ、Ｆｉｌｅ ｓｉｚｅ及びｆｉｌｅｐａｔｈが記録される。例えば、ＭＨ１には、ＭＰ１に対して説明したＭＨ ｓｉｚｅ、ｏｆｆｓｅｔ、ｌｅｎｇｔｈ、Ｆｉｌｅ ｓｉｚｅ及びｆｉｌｅｐａｔｈが記録される。図４Ｂのように一つのファイルブロックが３個のＭＢ１、ＭＢ２、ＭＢ３に区分されることは、一つのファイルブロックに第１ないし第３ファイルが記録されてパッケージ送信されることを意味する。ここで、ＭＢ１には、第１ファイルの一部又は全体のデータが記録され、ＭＢ２には、第２ファイルの全体のデータが記録され、ＭＢ３には、第３ファイルの一部又は全体のデータが記録されてもよい。
【００４４】
第１ディスクリーダ１３０が少なくとも一つ以上のマイクロブロックを生成する動作を説明すると、以下の通りである。例えば、ユーザが第１ファイルと第２ファイルとのパッケージ送信をリクエストしたと仮定する。
【００４５】
１．第１ディスクリーダ１３０は、第１ファイルの全体のデータサイズとＦＰの最大サイズとを比較して第１ファイルの全体をＦＰにすべて記録できる場合に、一つのＭＢ１を生成し、ＭＰ１に第１ファイルの全体のデータを記録する。一方、ＦＰのＭＰにデータが記録されるので、ＭＰのサイズと第１ファイルの全体のデータのサイズとを比較することが正確な表現であるが、本願発明の説明において、ＦＰのサイズを比較するという表現とＭＰのサイズを比較するという表現とを、特に区別する実益がない限り、互いに同じ意味として混用して使用するようにする。
【００４６】
２．また、第１ディスクリーダ１３０は、第１ファイルの全体のデータがＦＰの最大サイズより大きな場合、ＦＰの最大サイズと一致するデータを第１ファイルから読み出して一つのＭＢ１を生成し、第１ファイルの残ったデータは、次のファイルブロックに記録することができる。したがって、ＦＰに他のデータを記録できる空き空間がない場合に、第１ディスクリーダ１３０は、図４Ａに示すように、一つの第１マイクロブロックを生成し、このとき、ＭＰ１には、第１ファイルの全体のデータ又は一部のデータのみが記録される。
【００４７】
３．これに対し、ＦＰに第１ファイルのデータを記録した後、他のデータを記録できる空き空間がある場合、第１ディスクリーダ１３０は、次に送信する第２ファイルを読み込んでＭＢ２をさらに生成してファイルブロックを一杯にすることができる。すなわち、第１ディスクリーダ１３０は、ＦＰの空き空間と第２ファイルの全体のデータのサイズとを比較して、ＦＰの空き空間にＭＢ２を生成し、ＭＰ２に第２ファイルの全体又は一部のデータを記録するとよい。これにより、ファイルブロックには、２つのマイクロブロックＭＢ１、ＭＢ２が生成される。
【００４８】
４．仮に、ＦＰの空き空間のサイズより第２ファイルのサイズが大きい場合、第１ディスクリーダ１３０は、ＦＰの空き空間に相当するだけのデータを第２ファイルから読み出して記録し、次のファイルブロックに第２ファイルの残りのデータを記録するとよい。
【００４９】
第１アクティブブロックプール１４０は、少なくとも一つ以上のマイクロブロックが生成されたファイルブロックを一時的に保管できる。すなわち、第１アクティブブロックプール１４０は、少なくとも一つ以上の送信対象ファイルが記録されたファイルブロックを一時的に保管できる。
【００５０】
第１通信部１５０は、図４Ａ又は図４Ｂに示すように、データが記録された複数のファイルブロックが第１アクティブブロックプール１４０に保管されると、複数のファイルブロックを第１データ受信装置２００に送信できる。第１通信部１５０は、複数のファイルブロックを並列ＴＣＰストリーム方式で第１データ受信装置２００に送信できる。このために、第１通信部１５０は、複数の第１ソケットライター１５１を含み、第１ソケットライター１５１は、第１アクティブブロックプール１４０に未送信のファイルブロックがあるかどうかを確認し、未送信のファイルブロックを第１データ受信装置２００に送信できる。第１ソケットライター１５１は、各々一つのＴＣＰストリームに対応して、ファイルブロックを同時に並列送信できる。第１ソケットライター１５１は、送信が完了したファイルブロックを第１インアクティブブロックプール１２０に送信することができる。
【００５１】
第１制御部１６０は、少なくとも一つ以上のプロセッサを利用して、上述した第１データ送信装置１００の動作を制御できる。
【００５２】
一方、第１データ受信装置２００は、第２通信部２１０、第２インアクティブブロックプール２２０、第２アクティブブロックプール２３０、第１ディスクライター（Ｄｉｓｋ Ｗｒｉｔｅｒ）２４０、第２格納媒体２５０及び第２制御部２６０を備えることができる。
【００５３】
第２通信部２１０は、第１データ送信装置１００から並列ＴＣＰストリームを介してファイルブロックを受信することができる。このために、第２通信部２１０は、複数の第１ソケットリーダ２１１を含み、第１ソケットリーダ２１１は、第１ソケットライター１５１と各々一つのＴＣＰストリームを確立することができる。
【００５４】
第２インアクティブブロックプール２２０は、図３のように空きファイルブロックを保管できる。保管されたファイルブロックは、第２通信部２１０を介して受信されたファイルブロックのデータを記録する時に使用される。
【００５５】
第１ソケットリーダ２１１は、ファイルブロックが受信されるたびに第２インアクティブブロックプール２２０から空きファイルブロックを取得し、受信されたファイルブロックのデータを空きファイルブロックに記録するとよい。そして、第１ソケットリーダ２１１は、受信されたデータが記録されたファイルブロックを第２アクティブブロックプール２３０に保管するとよい。例えば、受信されたファイルブロックが図４Ｂのように３個のＭＢ１、ＭＢ２、ＭＢ３を含む場合に、第１ソケットリーダ２１１は、空きファイルブロックに図４Ｂと同じ形態でヘッダ情報とファイルのデータを記録するとよい。第１ソケットリーダ２１１は、ファイルのパッケージ送信が完了するまで、上述した動作を繰り返す。
【００５６】
第１ディスクライター２４０は、受信されたファイルブロックが各々少なくとも一つ以上のマイクロブロックを含む場合、マイクロブロック単位でデータを読み込んで第２格納媒体２５０に記録するとよい。
【００５７】
詳細に説明すれば、第１ソケットリーダ２１１が上述した動作を行う間に、第１ディスクライター２４０は、第２アクティブブロックプール２３０にファイルブロックがあるかどうかを確認する。第１ディスクライター２４０は、第２アクティブブロックプール２３０にファイルブロックがあると、ファイルブロックのＭＨに記録された情報を参照して、ＭＰに記録されたデータを第２格納媒体２５０に記録できる。ファイルブロック、すなわち、ＭＰに記録されたデータが第２格納媒体２５０に記録されると、第１ディスクライター２４０は、空きファイルブロックを第２インアクティブブロックプール２２０に伝達できる。
【００５８】
第１ディスクライター２４０が少なくとも一つ以上のマイクロブロックに記録されたデータを第２格納媒体２５０に記録する動作について説明すると、以下のとおりである。
【００５９】
まず、ファイルブロックが図４Ａのように一つのマイクロブロックを含む場合、第１ディスクライター２４０は、ＭＨのオフセットを確認し、第２格納媒体２５０のうち、オフセットに対応する位置にＭＰに記録されたデータを記録できる。例えば、ＭＰに記録されたデータが第１ファイルのデータで、オフセットが「０」である場合に第１ディスクライター２４０は、データが第１ファイルの最初の部分に位置すると判定し、第２格納媒体２５０のうち、第１ファイルが記録される領域のうち、最初の部分に記録できる。第１ディスクライター２４０は、ＭＨのＦｉｌｅｓｉｚｅから第１ファイルの全体サイズが分かるので、第１ファイルが第２格納媒体２５０で占める大きさが分かり、第１ファイルが記録される領域を予め割り当てることができる。
【００６０】
また、ファイルブロックが図４Ｂのように３個のＭＢ１、ＭＢ２、ＭＢ３を含む場合に、第１ディスクライター２４０は、ＭＨ１のｆｉｌｅｐａｔｈからファイル名を確認し、確認されたファイル名が第１ファイルであると、第１ファイルをＭＨ１に記録されたオフセットを参照してＭＰ１に記録されたデータを第２格納媒体２５０に記録できる。以後、第１ディスクライター２４０は、ＭＨ２のｆｉｌｅｐａｔｈからファイル名を確認し、確認されたファイル名が第２ファイルであると、第２ファイルをＭＨ２に記録されたオフセットを参照してＭＰ２に記録されたデータを第２格納媒体２５０に記録できる。ＭＢ３に記録されたデータを記録する過程も上述したとおりである。
【００６１】
第２制御部２６０は、少なくとも一つ以上のプロセッサを利用して上述した第１データ受信装置２００の動作を制御できる。
【００６２】
図５は、本発明の例示的な第２の実施形態に係るデータの並列送信のための第２データ送信装置５００及び第２データ受信装置６００を示すブロック図である。
【００６３】
第２データ送信装置５００及び第２データ受信装置６００は、送信対象ファイルをパッケージ送信しながらレジュームダウンロード送信をすることができる。このために、第２データ送信装置５００は、第３格納媒体５１０、リスト管理部５２０、第３インアクティブブロックプール５３０、第２ディスクリーダ５４０、第３アクティブブロックプール５５０、第３通信部５６０及び第３制御部５７０を備えることができる。
【００６４】
図５に示す第３格納媒体５１０、第３インアクティブブロックプール５３０、第２ディスクリーダ５４０、第３アクティブブロックプール５５０、第３通信部５６０及び第３制御部５７０の全般的な動作は、図２を参照して説明された第１格納媒体１１０、第１インアクティブブロックプール１２０、第１ディスクリーダ５４０、第１アクティブブロックプール１４０、第１通信部１５０及び第１制御部１６０の動作とそれぞれ同一又は類似しているので、これらについての詳細な説明を省略する。
【００６５】
リスト管理部５２０は、第２データ受信装置６００にパッケージ送信する送信対象ファイルにインデックスを割り当て、送信対象ファイルのインデックス、ファイル名及びファイルサイズに対する情報を送信ファイルリストに加えることによって、１又は複数の送信ファイルリストを作成できる。例えば、リスト管理部５２０は、１００個の送信対象ファイルを第２データ受信装置６００に送信しようとする場合に、１００個のファイルに０〜９９までのインデックスを割り当て、１００個のファイルを例えば２０個ずつ分類して５個の第１ないし第５送信ファイルリストを作ることができる。リスト管理部５２０は、第２データ受信装置６００に作成した送信対象ファイルを送信する。
【００６６】
また、リスト管理部５２０は、複数の送信ファイルリストを第２データ受信装置６００に送信してもよい。また、リスト管理部５２０は、先に送信した送信ファイルリストに対して第２データ受信装置６００のリスト確認部６２０から応答（例えば、レジュームダウンロードリスト）があると、次に送信ファイルリストを送信してもよい。
【００６７】
図６は、本発明の例示的な実施形態に係る送信ファイルリストの構造を示す図である。
【００６８】
図６に示すように、リスト管理部５２０は、第１〜第ｎインデックス、第１〜第ｎファイル名、第１〜第ｎファイルサイズ、及び終了識別子を含む送信ファイルリストを作成することができる。第１〜第ｎインデックスは、送信ファイルリストに含まれるｎ個のファイルに割り当てられたインデックスである。第１〜第ｎファイル名は、第１ないし第ｎインデックスに対応する各ファイルのファイル名である。第１〜第ｎファイルサイズは、第１〜第ｎインデックスに対応する各ファイルのサイズである。終了識別子は、もうこれ以上送信するファイルがない場合を表示するための終結文字（ｅｎｄ ｄｅｌｉｍｉｔｅｒ）であって、最後の送信ファイルリストに追加で記載されるとよい。
【００６９】
リスト管理部５２０は、送信するファイルが全部でｍ個（ｍ＞ｎ）ある場合に、図６のような送信ファイルリストを２つ以上作成することができる。
【００７０】
図６に示す送信ファイルリストの例を参照すれば、送信ファイルリストは、第１〜第ｎファイルに対するファイル情報を含んでいる。詳細には、送信ファイルリストは、第１〜第ｎファイルのインデックスとして０，１，．．．，ｎ−１と、第１〜第ｎファイルのファイル名としてａ，ｓｏ．ｔｘｔ，．．．，ｂ．ｊｐｇと、第１〜第ｎファイルのサイズとして１０ｂｙｔｅｓ，３０００ｂｙｔｅｓ，．．．，１０００ｂｙｔｅｓを含んでいる。
【００７１】
また、図５に示すように、第３通信部５６０は、複数の送信ファイルリストを順次に、並列ＴＣＰストリームとは異なる独立的なチャネルを介して第２データ受信装置６００に送信できる。また、第３通信部５６０は、複数の送信ファイルリストを順次に第２データ受信装置６００に送信する間に、ファイルブロックを並列ＴＣＰストリームを介して第２データ受信装置６００に送信できる。
【００７２】
第２ディスクリーダ５４０は、レジュームダウンロードリストが第２データ受信装置６００から受信されると、レジュームダウンロードリストに含まれたインデックスに対応するファイルを送信対象ファイルから確認し、該確認されたファイルのうち、レジュームダウンロードリストに含まれたオフセットに対応する位置からのデータをファイルブロックに記録してレジュームダウンロード送信を試みることができる。第２ディスクリーダ５４０は、図４Ａ又は図４Ｂを参照して説明されたファイルブロック（又はマイクロブロック）を利用して、レジュームダウンロードするファイルのデータをファイルブロックに記録できる。
【００７３】
一方、第２データ受信装置６００は、第４通信部６１０、リスト確認部６２０、第４インアクティブブロックプール６３０、第４アクティブブロックプール６４０、第２ディスクライター６５０、第４格納媒体６６０及び第４制御部６７０を備えることができる。図５に示す第４通信部６１０、第４インアクティブブロックプール６３０、第４アクティブブロックプール６４０、第２ディスクライター６５０、第４格納媒体６６０、及び第４制御部６７０の全般的な動作は、図２を参照して説明された第２通信部２１０、第２インアクティブブロックプール２２０、第２アクティブブロックプール２３０、第１ディスクライター２４０、第２格納媒体２５０、及び第２制御部２６０の動作を含むので、詳細な説明を省略する。
【００７４】
第４通信部６１０は、第２データ送信装置５００から送信ファイルリストを順次に受信し、各送信ファイルリストに対する応答であるレジュームダウンロードリスト（後述するリスト確認部６２０により作成されたものである）を第２データ送信装置５００に送信できる。また、送信ファイルリストが受信される間に、第４通信部６１０は、第２データ送信装置５００からファイルブロックを並列ＴＣＰストリームを介してファイルブロックを受信することができる。送信ファイルリストは、第２データ送信装置５００の送信対象ファイルのインデックス、ファイル名及びファイルサイズに対する情報を含む。
【００７５】
リスト確認部６２０は、第２データ送信装置５００から受信された送信ファイルリストとファイルブロックを利用して既に受信された複数のファイルを比較して、既受信の複数のファイルのうち、レジュームダウンロードするファイルを決定し、決定されたファイルのインデックスとオフセット（決定されたファイルのうち、レジュームダウンロードするデータのスタートアドレスを表す）を含むレジュームダウンロードリストを作成して、第２データ送信装置５００に送信できる。リスト確認部６２０によって作成されるレジュームダウンロードリストを、図８を参照して説明する。
【００７６】
リスト確認部６２０は、送信ファイルリストに含まれたファイルが第４格納媒体６６０に格納されていない場合、すなわち、送信ファイルリストを先に受信した場合、送信ファイルリストに含まれたファイルの全体送信をリクエストするレジュームダウンロードリストを作成することができる。
【００７７】
図７は、本発明の例示的な実施形態に係るメタファイルの構造を示す図である。
【００７８】
図７に示すように、第２ディスクライター６５０は、ＦＢの最大送信サイズ、受信された累積ファイルサイズ、第１番目のＭＢ（又はＦＢ）のサイズ、ｉ番目のＭＢ（又はＦＢ）のフラグ及び終了識別子を含むメタファイルを作成することができる。
【００７９】
第１ファイルが受信された場合、「ＦＢの最大送信サイズ」は、第１ファイルを送信するファイルブロックに割り当てられた最大送信量である。「受信された累積ファイルサイズ」は、少なくとも一つ以上のファイルブロックを介して受信された第１ファイルの累積サイズ（累積量）である。例えば、「受信された累積ファイルサイズ」は、第１ファイルが３個のファイルブロックを介して受信された場合、３個のファイルブロックに記録された第１ファイルのサイズを足し合せたものである。第１ファイルを送信するファイルブロックのうち、一つが未だ受信されていない場合に、第１ファイルの受信された累積ファイルサイズは、第１ファイルの実際のサイズより小さくなる。
【００８０】
「第１番目のＭＢのサイズ」は、第１ファイルを最初に送信したマイクロブロックのサイズであって、「第１番目のＭＢのサイズ」は、ＦＰの最大ＭＰサイズと同一であるか、又はＦＰの最大ＭＰサイズより小さいとよい。「第１番目のＭＢのサイズ」がＦＰより小さい場合は、一つのファイルブロックに少なくとも２つのファイルが記録されている場合である。ｉ番目のＭＢのフラグは、第１ファイルを連続的に送信した後、ＭＢの受信有無を表す情報である。ｉ＝２，３，．．．，ｍ（ｍは、正数）である。ｆｉ＝０は、第１ファイルのデータを記録したｉ番目のＭＢが受信されていないことを意味し、ｆｉ＝１は、ｉ番目のＭＢが受信されたことを意味する。
【００８１】
図７に示すメタファイルの例を参照すれば、一つのＦＢが最大１Ｍｂｙｔｅｓのデータを送信できる場合に、第２ディスクライター６５０は、「ＦＢの最大送信サイズ」に１Ｍｂｙｔｅｓを記録する。第１ファイルが４個の第１ないし第４ファイルブロックを介して受信された場合、第２ディスクライター６５０は、受信された累積ファイルサイズ」に４個のファイルブロックに記録された第１ファイルのサイズを合せた２．５Ｍｂｙｔｅｓを記録する。第１ファイルを最初に送信したファイルブロックが第１ファイルブロックである場合、第２ディスクライター６５０は、「１ＳＴ ＭＢのサイズ」に第１ファイルブロックに記録された第１ファイルのデータのサイズ、すなわち、第１ファイルのデータを記録したＭＢのサイズを記録する。第１ファイルの残ったデータを記録した第２ファイルブロックと第４ファイルブロックとは、正常に受信され、第３ファイルブロックは、受信されない場合、第２ディスクライター６５０は、ｆ２に「１」を記録し、ｆ３に「０」を記録し、ｆ４に「１」を記録する。
【００８２】
第２ディスクライター６５０は、メタファイルを作成しながら、それと同時にＭＰに記録されたデータをＭＨに記録されたオフセットを参照して第４格納媒体６６０に格納することができる。作成されたメタファイルは、第２ディスクライター６５０が使用するメモリ（図示せず）に格納されるとよい。したがって、メモリには、第２データ送信装置５００から受信されたファイルのメタファイルが格納されるとよい。
【００８３】
第２ディスクライター６５０は、少なくとも一つのファイルブロックを介して受信された少なくとも一つの以上のファイルごとにメタファイルを作成することができる。また、第２ディスクライター６５０は、受信されたファイルの途中からの欠落又は受信されたファイルの中間の欠落がない状態ですべて送信されたと確認されると、メタファイルを削除できる。第２ディスクライター６５０は、メタファイルのフラグがすべて１で、第１番目のＭＢのサイズが０でないと、ファイルがすべて受信されて第４格納媒体６６０に格納されたと判定できる。
【００８４】
以下、リスト確認部６２０がメモリに格納されたメタファイルを参照してレジュームダウンロードリストを作成し、リスト管理部５２０がレジュームダウンロードファイルのデータを再送信する動作について説明する。
【００８５】
第２データ送信装置５００から受信された送信ファイルリストに含まれたファイル名に対応するファイルが、既に受信された複数のファイルのうちの一つである第１ファイルであり、第１ファイルのメタファイルが存在すると、リスト確認部６２０は、第１ファイルをレジュームダウンロードするファイルと決定できる。すなわち、リスト確認部６２０は、送信ファイルリストに含まれたファイルを確認し、確認されたファイルのうち、メタファイルが存在するファイルは、すべてレジュームダウンロードするファイルと決定できる。リスト確認部６２０は、レジュームダウンロードするファイルの情報を利用して、レジュームダウンロードリストを作成することができる。
【００８６】
図８は、本発明の例示的な実施形態に係るレジュームダウンロードリストの構造を示す図である。
【００８７】
図８に示すように、リスト確認部６２０は、レジュームダウンロードするファイルのインデックス、オフセット及び終了識別子を含むレジュームダウンロードリストを作成することができる。リスト確認部６２０は、データ送信量を最小化するためにレジュームダウンロードするファイルのファイル名をレジュームダウンロードリストに含めなくてもよく、これは選択事項である。
【００８８】
「レジュームダウンロードするファイルのインデックス」は、レジュームダウンロードするファイルに割り当てられた固有識別子であって、図６の送信ファイルリストから取得できる。「オフセット」は、レジュームダウンロードするファイルのうち、レジュームダウンロードするデータのスタートアドレスを表す。「終了識別子」は、送信ファイルリストに含まれたファイルのうち、レジュームダウンロードするファイルの情報をレジュームダウンロードリストにすべて記録した後に、現在の送信ファイルリストに対してもうこれ以上レジュームダウンロードするファイルがないことを通知する終結文字である。
【００８９】
図８に示すレジュームダウンロードリストの例を参照すれば、リスト確認部６２０は、一つの送信ファイルリストに含まれたファイルのうち、レジュームダウンロードするファイルとして決定されたファイルのインデックスがそれぞれ「０」と「３」である場合に、「０」と「３」をインデックス領域に記録する。
【００９０】
リスト確認部６２０は、該当するメタファイルの「１ＳＴ ＭＢのサイズ」とフラグ情報を参照してオフセット（レジュームダウンロードするデータのスタートアドレス）を算出できる。
【００９１】
詳細に説明すれば、レジュームダウンロードするファイルとして決定されたファイルが第１ファイルで、第１ファイルが複数のファイルブロックを介して受信された場合に、リスト確認部６２０は、第１ファイルのメタファイルに第１ファイルを最初に送信した第１番目のファイルブロック（ｉ＝１）の送信量（１ＳＴ ＭＢのサイズ）が０と記録されていると、第１ファイルのオフセットを０とするレジュームダウンロードリストを作成することができる。このような場合、第２データ送信装置５００は、第１ファイルを始めから再送信する。
【００９２】
また、リスト確認部６２０は、第１ファイルが複数のファイルブロックを介して受信された場合、メタファイルに第１ファイルを最初に送信した第１番目のファイルブロック（ｉ＝１）の送信量がｋバイト（ｋは、正数）と記録されており、第１ファイルをｉ（ｉ＝２，３，．．．，ｍ）番目に送信したファイルブロックのフラグが０であると、「ｋバイト＋（ｉ−２）＊ｎバイト」を第１ファイルのオフセットとして算出できる。ｎバイトは、図７に示す「ＦＢの最大送信サイズ」である。
【００９３】
図８に示すレジュームダウンロードリストの例を参照すれば、リスト確認部６２０は、一つの送信ファイルリストに含まれたファイルのうち、レジュームダウンロードするファイルとして決定された第１ファイルと第２ファイルのインデックスがそれぞれ「０」と「３」である場合に、「０」と「３」とをインデックス領域に記録する。図７に示すメタファイルの例が第１ファイルのメタファイルである場合に、リスト確認部６２０は、次のように第１ファイルのオフセットを算出する。
【００９４】
オフセット＝ｋバイト＋（ｉ−２）＊ｎバイト＝０．５Ｍｂｙｔｅｓ＋（３−２）＊１Ｍｂｙｔｅｓ＝１．５Ｍｂｙｔｅｓ
したがって、リスト確認部６２０は、第１ファイルのインデックスである「０」とオフセットである「１．５Ｍｂｙｔｅｓ」をレジュームダウンロードリストに図８のように記録できる。これと同じ方法によって、リスト確認部６２０は、第２ファイルのインデックスである「３」とオフセットである「１５３０ｂｙｔｅｓ」とをレジュームダウンロードリストに図８のように記録できる。図８のようにレジュームダウンロードリストを受信した第２データ送信装置５００は、レジュームダウンロードリストに含まれたインデックスに対応するファイルを確認し、確認されたファイルのうち、オフセットに対応する位置（又はその次の位置）からのデータを第２データ受信装置６００にファイルブロックを利用してパッケージ方式で再送信できる。
【００９５】
上述した本発明の例示的な第２の実施形態に係るリスト管理部５２０、リスト確認部６２０、第２ディスクリーダ５４０、第２ディスクライター６５０、第２ソケットライター５６１及び第２ソケットリーダ６１１は、スレッド（ｔｈｒｅａｄ）として動作して同時に実行されてもよい。
【００９６】
図９は、本発明の例示的な第１の実施形態に係るデータの並列送信方法を説明するためのフローチャートである。
【００９７】
図９のデータの並列送信方法を行う第１データ送信装置は、図２を参照して説明した第１データ送信装置１００であるとよい。
【００９８】
図９に示すように、第１データ送信装置は、ユーザから複数のファイルのパッケージ送信リクエストを受信する（Ｓ９１０）。以下、第１及び第２ファイルのパッケージ送信を例に挙げて説明する。
【００９９】
第１データ送信装置は、パッケージ送信がリクエストされたファイルのうち、第１ファイルのデータを格納媒体から読み出して、ＭＢを生成する（Ｓ９２０）。ステップＳ９２０にて、第１データ送信装置は、第１ファイルのデータを読み出す前にインアクティブブロックプールから持ってきたＦＰの最大サイズと第１ファイルの全体サイズとを比較してＭＢを生成できる。これに対しては、図１０を参照して詳細に説明する。
【０１００】
第１データ送信装置は、生成されたＭＢの中のＭＰに、読み出したデータを記録した後、ＦＰにＭＢを格納する（Ｓ９３０）。
【０１０１】
第１データ送信装置は、ＦＰにデータをさらに記録できる領域が残っていているかどうかを確認する（Ｓ９４０）。
【０１０２】
残った領域がないと（Ｓ９４０−Ｎ）、第１データ送信装置は、ＦＰ全体にデータが記録されたＦＢを第１データ受信装置に並列ＴＣＰストリーム方式を介して送信する（Ｓ９５０）。
【０１０３】
これに対し、残った領域があると（Ｓ９４０−Ｙ）、パッケージ送信する全てのファイルがＦＢに記録されたかどうかを確認する（Ｓ９６０）。ステップＳ９６０にて、第１データ送信装置は、第１ファイルの全てがＦＢに記載されたと判定し、さらに送信する第２ファイルがあるかどうかを確認する。
【０１０４】
パッケージ送信する全てのファイルが記録されていると（Ｓ９６０−Ｙ）、第１データ送信装置は、ＦＰの一部が空いているＦＢを第１データ受信装置に送信する（Ｓ９７０）。
【０１０５】
パッケージ送信するファイルが残っていると（Ｓ９６０−Ｎ）、第１データ送信装置は、ステップＳ９２０に進んで第２ファイルのデータを読み出し、ステップＳ９２０ないしステップＳ９７０を繰り返す。
【０１０６】
図１０は、図９に示すデータの並列送信方法をさらに詳細に説明するためのフローチャートである。
【０１０７】
図１０に示すように、第１データ送信装置は、ユーザから複数のファイルのパッケージ送信リクエストを受信する（Ｓ１０００）。以下、第ｎファイル及び第ｎ＋１ファイルのパッケージ送信を例に挙げて説明する。
【０１０８】
第１データ送信装置は、ＦＢに割り当て可能なＭＰの最大サイズと第ｎファイルのデータのサイズとを比較する（Ｓ１００５）。ステップＳ１００５にて、第１データ送信装置は、インアクティブブロックプールからＦＢを持ってきて第１格納媒体から第ｎファイルを読み出して、サイズを比較する。
【０１０９】
ＭＰの最大サイズが第ｎファイルのデータのサイズより大きいと（Ｓ１０１０−Ｙ）、第１データ送信装置は、第ｎファイルのデータのサイズに相当するＭＢ（以下、ＭＢｎとする）を生成する（Ｓ１０１５）。
【０１１０】
そして、第１データ送信装置は、ＭＢｎのＭＨｎとＭＰｎにそれぞれヘッダ情報と第ｎファイルのデータとを記録する（Ｓ１０２０）。ステップＳ１０２０にて記録されるヘッダ情報は、図４Ａを参照して説明された情報であるとよい。
【０１１１】
第１データ送信装置は、パッケージ送信がリクエストされた第ｎ＋１ファイルが記録されたかどうかを確認し、記録されていないと（Ｓ１０２５−Ｎ）、第１データ送信装置は、ＦＰのうちＭＢｎを除いて残ったＭＰの最大サイズと第ｎ＋１ファイルのデータのサイズを比較する（Ｓ１０３０）。
【０１１２】
そして、第１データ送信装置は、「ｎ＝ｎ＋１」と定めた後（Ｓ１０３５）、ステップＳ１０１０に進んでステップＳ１０１５ないしステップＳ１０２０を繰り返し行う。
【０１１３】
これに対して、第１データ送信装置は、第ｎ＋１ファイルが記録されたことが確認されると（Ｓ１０２５−Ｙ）、ＦＰの一部が空いているＦＢを第１データ受信装置に送信する（Ｓ１０４０）。ステップＳ１０４０にて送信されるＦＢには、第ｎファイルと第ｎ＋１ファイルとが記録されてパッケージ送信される。
【０１１４】
一方、ステップＳ１０１０にて、ＭＰの最大サイズと第ｎファイルのデータのサイズが同一であると（Ｓ１０４５−Ｙ）、第１データ送信装置は、第ｎファイルのデータのサイズに相当するＭＢｎを生成する（Ｓ１０５０）。
【０１１５】
そして、第１データ送信装置は、ＭＢｎのＭＨｎとＭＰｎにそれぞれヘッダ情報と第ｎファイルのデータとを記録する（Ｓ１０５５）。
【０１１６】
第ｎファイルのデータが記録されると、第１データ送信装置は、パッケージ送信がリクエストされた第ｎ＋１ファイルが記録されたかどうかを確認し、記録されていないと（Ｓ１０６０−Ｎ）、第１データ送信装置は、「ｎ＝ｎ＋１」と定めた後（Ｓ１０６５）、ステップＳ１００５に進む。
【０１１７】
これに対し、第１データ送信装置は、第ｎ＋１ファイルが記録されたことが確認されると（Ｓ１０６０−Ｙ）、ＦＰ全体にデータが記録されたＦＢ（ＭＢｎを含むＦＢ）を含む複数のＦＢを第１データ受信装置に送信する（Ｓ１０７０）。ステップＳ１０７０にて送信されるＦＢには、第ｎファイルと第ｎ＋１ファイルとが記録されて、当該ＦＢがパッケージ送信される。
【０１１８】
一方、ＭＰの最大サイズと第ｎファイルのデータのサイズが同一でなく（Ｓ１０４５−Ｎ）、ＭＰの最大サイズより第ｎファイルのデータのサイズが大きな場合（Ｓ１０７５）、第１データ送信装置は、ＭＰの最大サイズに相当するＭＢｎを生成する（Ｓ１０８０）。
【０１１９】
第１データ送信装置は、ＭＢｎのＭＨｎとＭＰｎにそれぞれヘッダ情報と第ｎファイルのデータを記録する（Ｓ１０８５）。
【０１２０】
そして、第１データ送信装置は、次のＦＢのＭＰの最大サイズと第ｎファイルの残ったデータのサイズとを比較する（Ｓ１０９０）。
【０１２１】
これと共に、第１データ送信装置は、「ＦＢ＝次のＦＢ」と定め、「第ｎファイルのサイズ＝第ｎファイルの残ったデータのサイズ」と定めた後（Ｓ１０９５）、Ｓ１０１０ステップに進む。これにより、第１データ送信装置は、ステップＳ１０１０ないしステップＳ１０９５を繰り返し行って、第ｎファイルの残ったデータを次のＦＢに記録する。
【０１２２】
図１１は、本発明の例示的な実施形態に係るデータの並列受信方法を説明するためのフローチャートである。
【０１２３】
図１１のデータの並列受信方法を行う第１データ受信装置は、図２を参照して説明された第１データ受信装置２００である。
【０１２４】
図１１に示すように、第１データ受信装置は、第１データ送信装置から受信されたＦＢのヘッダ情報とデータを、空いているＦＢに記録する（Ｓ１１１０）。ステップＳ１１１０において、第１データ受信装置は、受信されたＦＢが複数のＭＢを含む場合、空いているＦＢを複数のＭＢに区分して同様にデータを記録してもよい。
【０１２５】
第１データ受信装置は、ヘッダ情報とデータが記録されたＦＢをアクティブブロックプールに保管する（Ｓ１１２０）。
【０１２６】
第１データ受信装置は、アクティブブロックプールに保管されたＦＢからデータをＭＢ単位で読み出して、第２格納媒体に記録する（Ｓ１１３０）。ステップＳ１１３０において、第１データ受信装置は、ＭＨに記録されたオフセットを参照して、ＭＰに記録されたデータを第２格納媒体に記録する。
【０１２７】
第１データ受信装置は、ＦＢに残ったＭＢがあると（Ｓ１１４０−Ｙ）、ステップＳ１１３０を繰り返し行う。
【０１２８】
これに対し、ＦＢに残ったマイクロブロックがないと（Ｓ１１４０−Ｎ）、すなわち、ＦＰに記録されたデータがすべて第２格納媒体に記録されると、アクティブブロックプールに他のＦＢがあるかどうかを確認する（Ｓ１１５０）。
【０１２９】
アクティブブロックプールに他のＦＢがあると（Ｓ１１５０−Ｙ）、第１データ受信装置は、ステップＳ１１１０に進む。
【０１３０】
これに対し、アクティブブロックプールに他のＦＢがないと（Ｓ１１５０−Ｎ）、第１データ受信装置は、パッケージ送信がリクエストされたファイルの格納が完了したかどうかを確認する（Ｓ１１６０）。ステップＳ１１６０にて、第１データ受信装置は、ＭＨのＦｉｌｅ ｓｉｚｅに記録されたサイズと実際に受信されたデータのサイズとが同じ場合に、ファイルの格納が完了したと確認することができる。
【０１３１】
格納が完了した場合（Ｓ１１６０−Ｙ）に、第１データ受信装置は、パッケージファイルの受信が完了したことを報告する受信完了メッセージを第１データ送信装置に送信する（Ｓ１１７０）。
【０１３２】
格納が完了しない場合（Ｓ１１６０−Ｎ）、第１データ受信装置は、ステップＳ１１５０に進む。
【０１３３】
図１２は、本発明の例示的な他の実施形態に係るデータの並列送受信方法を説明するためのフローチャートである。
【０１３４】
図１２のデータの並列送受信方法を行う第２データ送信装置と第２データ受信装置とは、図５を参照して説明された第２データ送信装置５００と第２データ受信装置６００である。
【０１３５】
図１２に示すように、第２データ送信装置は、ユーザから複数のファイルのパッケージ送信リクエストを受信する（Ｓ１２０５）。
【０１３６】
第２データ送信装置は、パッケージ送信する送信対象ファイルを分割して、複数のグループを作る（Ｓ１２１０）。
【０１３７】
第２データ送信装置は、各グループに属するファイルの情報に基づき、図６のような送信ファイルリストを作成する（Ｓ１２１５）。すなわち、第２データ送信装置は、一つのグループに対して一つの送信ファイルリストを作成する。送信ファイルリストは、一つのグループに属したファイルのインデックス、ファイル名及び全体ファイルサイズに対する情報を含む。
【０１３８】
第２データ送信装置は、ステップＳ１２１５にて作成された送信ファイルリストを第２データ受信装置に送信する（Ｓ１２２０）。
【０１３９】
第２データ送信装置は、作成された送信ファイルリストを送信する間に、残りのグループに対する送信ファイルリストの作成が完了したかどうかを確認する（Ｓ１２２５）。
【０１４０】
作成が完了していない場合（Ｓ１２２５−Ｎ）、第２データ送信装置は、残りのグループに対する送信ファイルリストを作成して送信するステップＳ１２１５及びステップＳ１２２０を繰り返し行う。
【０１４１】
第２データ受信装置は、ステップＳ１２２０において受信された送信ファイルリストと、ＦＢを介して既に受信された複数のファイルとを比較して、既に受信された複数のファイルのうち、レジュームダウンロードするファイルを決定し、決定されたファイルのインデックスとオフセット（決定されたファイルのうち、レジュームダウンロードするデータのスタートアドレスを表す）を含むレジュームダウンロードリストを作成する（Ｓ１２３０）。ステップＳ１２３０を、図１３を参照してさらに詳細に説明する。
【０１４２】
第２データ受信装置は、作成されたレジュームダウンロードリストを第２データ送信装置に送信する（Ｓ１２３５）。
【０１４３】
第２データ送信装置は、受信されたレジュームダウンロードリストを参照して、パッケージ送信するファイルのデータを少なくとも一つ以上のＦＢに記録する（Ｓ１２４０）。ステップＳ１２４０において、第２データ送信装置は、図９及び図１０を参照して説明したように、ＭＢ単位でデータをＦＢに記録する。
【０１４４】
第２データ送信装置は、ステップＳ１２４０においてデータが記録された少なくとも一つ以上のＦＢを第２データ受信装置に送信する（Ｓ１２４５）。ステップＳ１２４０及びステップＳ１２４５において、第２データ送信装置は、レジュームダウンロードリストに含まれたインデックスに相当するファイルを第３格納媒体から確認し、該確認されたファイルのうち、オフセットに対応する位置（又はその次の位置）からのデータを、第２データ受信装置にＦＢを利用してパッケージ方式で初期送信又は再送信する。例えば、第２データ送信装置は、レジュームダウンロードリストのオフセットが「０」である場合に、ファイルを始めから送信し、オフセットが「０」でないｍｂｙｔｅｓ（ｍは、正数）である場合に、ファイルのうち、ｍｂｙｔｅｓに対応する位置からのデータを送信する。
【０１４５】
第２データ受信装置は、受信された少なくとも一つ以上のＦＢのヘッダ情報とデータとを空いている少なくとも一つ以上のＦＢに記録する（Ｓ１２５０）。ステップＳ１２５０において、第２データ受信装置は、受信されたＦＢが複数のＭＢを含む場合に、ＦＢを複数のＭＢに区分して同様にデータを記録できる。
【０１４６】
第２データ受信装置は、ヘッダ情報とデータが記録された少なくとも一つのＦＢをアクティブブロックプールに順次に保管する（Ｓ１２５５）。
【０１４７】
第２データ受信装置は、アクティブブロックプールに保管されたＦＢのうち、ＭＰに記録されたファイル（以下では、「第１ファイル」とする）のメタファイルが存在しているかどうかを確認する（Ｓ１２６０）。
【０１４８】
第１ファイルのメタファイルが第２データ受信装置に存在しないと（Ｓ１２６０−Ｎ）、第２データ受信装置は、第１ファイルのメタファイルを作成する（Ｓ１２６５）。ステップＳ１２６５において、第２データ受信装置は、図７のような形態のメタファイルを作成することができる。
【０１４９】
第２データ受信装置は、ＦＢのＭＰに記録された第１ファイルのデータを第４格納媒体に格納する（Ｓ１２７０）。
【０１５０】
第１ファイルが複数のＦＢを介して受信される場合、第２データ受信装置は、ＦＢが受信されるごとにメタファイルをアップデートする（Ｓ１２７５）。
【０１５１】
第２データ受信装置は、ＦＢに記録されたデータがすべて第４格納媒体に記録されていると、アクティブブロックプールに他のＦＢがあるかどうかを確認する（Ｓ１２８０）。
【０１５２】
アクティブブロックプールに他のＦＢがあると（Ｓ１２８０−Ｙ）、第２データ受信装置は、ステップＳ１２６０に進む。
【０１５３】
反面、アクティブブロックプールに他のＦＢがないと（Ｓ１２８０−Ｎ）、第２データ受信装置は、ファイルの格納が完了したかどうかを確認し、パッケージファイルの受信又はレジュームダウンロード受信が完了したことを報告する受信完了メッセージを第２データ送信装置に送信する（Ｓ１２８５）。
【０１５４】
上述したデータ並列送受信方法において、第２データ送信装置は、第２データ受信装置がレジュームダウンロードリストを作成する間に、ステップＳ１２１５〜ステップＳ１２２５を並列実行することができ、ステップＳ１２１５〜ステップＳ１２３５が行われる間にステップＳ１２４０〜ステップＳ１２４５を並列実行してもよい。
【０１５５】
図１３は、図１２のステップＳ１２３０をさらに詳細に示すフローチャートである。
【０１５６】
図１３に示すように、第２データ受信装置は、第２データ送信装置から送信ファイルリストを受信する（Ｓ１３００）。
【０１５７】
第２データ受信装置は、受信された送信ファイルリストに含まれたファイルのうち、現在処理する第１ファイルが第４格納媒体に格納されているかどうかを確認する（Ｓ１３１０）。第２データ受信装置は、送信ファイルリストに記録された第１ファイルのファイル名又はインデックスと第４格納媒体に格納されたファイル名又はインデックスを比較して、第１ファイルの格納有無を確認することができる。
【０１５８】
第１ファイルが第４格納媒体に格納されていると（Ｓ１３１０−Ｙ）、第２データ受信装置は、送信ファイルリストに記録された第１ファイルのサイズと第４格納媒体に格納された第１ファイルのサイズとが同一であるかどうか、第１ファイルのメタファイルがメモリに格納されていないかどうかを確認する（Ｓ１３２０）。
【０１５９】
互いにサイズが同一であり、かつ第１ファイルのメタファイルが格納されていないと（Ｓ１３２０−Ｙ）、第２データ受信装置は、第１ファイルの送信が完了したと判定し、レジュームダウンロードをしない（Ｓ１３３０）。
【０１６０】
これに対し、互いにサイズが同一でないか、又はメタファイルが格納されていると（Ｓ１３２０−Ｎ）、第２データ受信装置は、メタファイルの第１番目のＭＢ（１ＳＴ ＭＢ）のサイズが「０」であるかどうかを確認する（Ｓ１３４０）。
【０１６１】
メタファイルの第１番目のＭＢのサイズが０でないと（Ｓ１３４０−Ｎ）、第２データ受信装置は、第１ファイルを初めて送信したＦＢ（又はＭＢ）が受信されているのでｉ＝２（ｉは、第１ファイルをｉ番目に送信したＭＢである）に設定する（Ｓ１３５０）。
【０１６２】
そして、第２データ受信装置は、第２番目のＭＢ（ｉ＝２）のフラグであるｆｉが「０」であるかどうかを確認する（Ｓ１３６０）。
【０１６３】
ステップＳ１３６０にてｆｉ＝０（ｉ＝２）であると（Ｓ１３６０−Ｙ）、第２データ受信装置は、第１ファイルを送信した第２番目のＦＢが受信されていないと判定し、レジュームダウンロードするアドレスであるオフセットを算出する（Ｓ１３７０）。ステップＳ１３７０において、第２データ受信装置は、「オフセット＝ｋバイト＋（ｉ−２）＊ｎバイト」を利用して、第１ファイルのオフセットを算出する。算出されたオフセットは、第１ファイルのメタファイルに記録された受信された累積ファイルサイズと同じであってもよい。
【０１６４】
ステップＳ１３６０にてｆｉ＝０（ｉ＝２）でないと（Ｓ１３６０−Ｎ）、第２データ受信装置は、ｉに１を加え（Ｓ１３９０）、再度ステップＳ１３６０を実行する。第２データ受信装置は、最後のｉまでこの処理を繰り返す。
【０１６５】
第２データ受信装置は、第１ファイルのインデックスとステップＳ１３７０にて算出されたオフセットをレジュームダウンロードリストに記録する（Ｓ１３８０）。
【０１６６】
図１３は、一つの送信ファイルリストに含まれた複数のファイルのうち、第１ファイルのオフセットを求める過程に対して示すものであって、第２データ受信装置は、送信ファイルリストに含まれたすべてのファイルに対してステップＳ１３２０〜ステップＳ１３８０を繰り返し行うことができる。これにより、第２データ受信装置は、一つの送信ファイルリストに対する応答であるレジュームダウンロードリストを最終的に作成して、第２データ送信装置に送信する（Ｓ１２３５）。
【０１６７】
以上、本発明は、限定された実施形態と図面により説明されたが、本発明は、上記の実施形態に限定されるものではなく、本発明が属する分野における通常の知識を有した者であれば、このような記載から多様な修正及び変形が可能である。したがって、本発明の範囲は、説明された実施形態に限定されてはならず、後述する特許請求の範囲だけでなく、この特許請求の範囲と均等なものによって定められなけばならない。
【符号の説明】
【０１６８】
１００ 第１データ送信装置
１１０ 第１格納媒体
１２０ 第１インアクティブブロックプール
１３０ 第１ディスクリーダ
１４０ 第１アクティブブロックプール
１５０ 第１通信部
１６０ 第１制御部
２００ 第１データ受信装置
２１０ 第２通信部
２２０ 第２インアクティブブロックプール
２３０ 第２アクティブブロックプール
２４０ 第１ディスクライター
２５０ 第２格納媒体
２６０ 第２制御部
【技術分野】
【０００１】
本発明は、データ送信装置及び方法に関し、さらに詳細には、ファイルのパッケージ送信及びレジュームダウンロード送信が可能なデータ送信装置及び方法に関する。
【背景技術】
【０００２】
従来、多数のファイルを送信する場合、送信しようとする一つのファイルに対するコントロールメッセージを送信し、その一つのファイルの送信が完了したというコントロールメッセージを受信した後、次のファイルを順次に送信する。このような送信方式は、サーバとクライアントとの間で一つのＴＣＰ（Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）接続を確立して該当チャネルを介してデータを送受信する動作を行う場合でも多数のＴＣＰストリームをオープンしてデータを並列に送信する場合でもすべて同様である。
【０００３】
しかしながら、従来の方式によってファイルを送信する場合に、コントロールメッセージの送信時には、実際のデータを送信することができず、これによってパケットロスが多く発生したり、ＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）が長いネットワーク上では送信効率が急激に落ちるという結果がもたらされる。また、ネットワークＢＤＰ（Ｂａｎｄｗｉｄｔｈ Ｄｅｌａｙ Ｐｒｏｄｕｃｔ）より小さなサイズのファイル一つを送信する場合、ネットワークを効率的に使用することができないので、非効率的な送信がなされるという問題がある。このような問題を解決するために、多数のファイルを圧縮しパック（ｐａｃｋ）して一つのファイルで送信する方法がある。しかし、このような場合に圧縮及び圧縮の解除に時間が長くかかるという不便が発生し、その結果、圧縮によりデータのサイズを減らして短くした送信時間より、圧縮・復元にかかる時間の方が長くなり、送信がより遅くなる現象が発生する。
【０００４】
また、並列ＴＣＰストリーム送信方式を使用する場合に、単一ＴＣＰストリーム送信では発生しない送信の逆転現象が発生する。これは、単一ＴＣＰストリーム送信の場合では、先に送信されたデータが必ず先に到着することが保証されることに対し、並列ＴＣＰストリーム送信方式の場合では、第１番目のストリームを介して送信されるデータが第２番目のストリームを介して送信されるデータより先に送信されても、第２番目のストリームのデータより先に到着することが保証されないためである。
【０００５】
また、従来の並列ＴＣＰストリーム送信の場合、上述したようにデータの順次的な送信が保証されないので、ファイルのレジュームダウンロードを適用することが困難である。また、多量のファイルを並列ＴＣＰストリーム送信方式で送信する場合に、レジュームダウンロードが不可能であるか、既に送信されたデータに対しても再送信が起きるので、送信効率が低下する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の例示的な実施形態によれば、多数のファイルをリアルタイムでパッケージ送信することによって、ファイルを個別に送信する時に発生するコントロールメッセージの回数を最小化し、ＴＣＰ効率性を改善できるデータ送信装置及び方法を提供することである。
【０００７】
また、本発明の例示的な実施形態によれば、多数のファイルをパッケージ送信する際に一部のデータの送信が欠落されるか、又は送信が停止される場合に、レジュームダウンロード機能を保証できるデータ送信装置及び方法を提供することにある。
【課題を解決するための手段】
【０００８】
本発明の例示的な一実施形態におけるデータ送信装置は、複数のファイルを送信するデータ送信装置であって、ファイルブロックを一つ又は複数のマイクロブロックに区分し、前記一つ又は複数のマイクロブロックの各々のサイズに対応するデータを前記複数のファイルから読み出して、前記一つ又は複数のマイクロブロックに順次に記録するディスクリーダと、前記ファイルブロックに含まれる一つ又は複数のマイクロブロックにデータが記録されると、前記ファイルブロックをデータ受信装置に送信する通信部と、を備える。
【０００９】
一方、本発明の他の例示的な実施形態におけるデータ受信装置は、データ送信装置から送信されるファイルブロック（データ送信単位）を受信する通信部と、前記受信されたファイルブロックが一つ又は複数のマイクロブロック（少なくとも一つ以上のファイルのデータが記録される単位）を含む場合に、マイクロブロック単位でデータを読み出して格納媒体に記録するディスクライターと、を備える。
【００１０】
一方、本発明の他の例示的な実施形態におけるデータ送信方法は、複数のファイルを送信するデータ送信方法であって、ファイルブロックを一つ又は複数のマイクロブロックに区分し、前記一つ又は複数のマイクロブロックの各々のサイズに対応するデータを前記複数のファイルから読み出して、前記一つ又は複数のマイクロブロックに順次に記録するステップと、前記ファイルブロックに含まれる一つ又は複数のマイクロブロックにデータが記録されると、前記ファイルブロックをデータ受信装置に送信するステップと、を含む。
【００１１】
一方、本発明の他の例示的な実施形態におけるデータ受信方法は、データ送信装置から送信されるファイルブロック（データ送信単位）を受信するステップと、前記受信されたファイルブロックが一つ又は複数のマイクロブロック（少なくとも一つ以上のファイルのデータが記録される単位）を含む場合に、マイクロブロック単位でデータを読み出して格納媒体に記録するステップと、を含む。
【発明の効果】
【００１２】
本発明の例示的な実施形態におけるデータ送受信装置及び方法の少なくとも１つは、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋｓ）環境で使用される場合に通信効率が高い。ＷＡＮ環境の場合に、パケットロス（Ｐａｃｋｅｔ Ｌｏｓｓ）やＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）が大きいので、ＴＣＰプロトコルの特性上、ネットワークの帯域幅の少なくとも一部を使用できない場合が発生する。すなわち、パケットロスが発生するため、ウィンドウサイズを減らすことにより、送信できるパケットの量が減るか、又はアクナリッジメントを受信することができなくてウィンドウを空けることができないことにより、送信速度が顕著に落ちる状況が発生することがある。これを解決するために、本実施形態では、多数のファイルをリアルタイムでパック（ｐａｃｋ）して送信することによって、ファイルを順次に送信する際に送信開始と終了において発生するコントロールメッセージを減らすことができる。コントロールメッセージが送信される間にファイルのデータは送信されないので、コントロールメッセージを減らすことによって、ＴＣＰのデータの送信効率を大きく改善できる。また、アプリケーション層でファイルをパックしてＴＣＰ層にフォワードすることによって、ＴＣＰウィンドウより小さなデータを送信する場合を最小とし、ＴＣＰウィンドウより大きさが小さいデータを送信する際に発生するＴＣＰプロトコルの非効率的な動作を改善し、その結果、ファイルの送信時間を大きく減少させることができる。また、並列ＴＣＰストリームを使用することによって、ＴＣＰストリームが有するウィンドウを足し合せた分だけのデータを一度に送ることができ、その結果、データの送信時に衝突状況が発生しても、単一ＴＣＰストリームを利用した送信より、より多くのデータを送信することができる。
【００１３】
また、本発明の例示的な実施形態におけるデータ送受信装置及び方法の少なくとも１つは、オフセットとファイルの全体サイズに対する情報を利用することによって、並列ＴＣＰストリーム送信においてファイルの逆転現象無しにレジュームダウンロードを実現することができる。また、送信されたファイルのオフセットを利用してレジュームダウンロードを行うことによって、既に送信されたデータの重複送信を防止し、その結果、重複送信時に発生する送信の無駄を減らすことができる。また、多数のファイルをグループに分けてリストをまず送信して、レジュームダウンロードするファイルを比較決定する動作と、レジュームダウンロードするファイルのデータを送信する動作とを同時に行うことによって、データの送信効率を上げることができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の例示的な実施形態に係るデータの並列送信のための送受信システムを示す図である。
【図２】本発明の例示的な第１の実施形態に係るデータの並列送信のための第１データ送信装置及び第１データ受信装置を示すブロック図である。
【図３】本発明の例示的な実施形態に係るファイルブロックの構造を示す図である。
【図４Ａ】本発明の例示的な実施形態に係る一つのマイクロブロックを含むファイルブロックの構造を示す図である。
【図４Ｂ】本発明の例示的な実施形態に係る一つのマイクロブロックを含むファイルブロックの構造を示す図である。
【図５】本発明の例示的な第２の実施形態に係るデータの並列送信のための第２データ送信装置及び第２データ受信装置を示すブロック図である。
【図６】本発明の例示的な実施形態に係る送信ファイルリストの構造を示す図である。
【図７】本発明の例示的な実施形態に係るメタファイルの構造を示す図である。
【図８】本発明の例示的な実施形態に係るレジュームダウンロードリストの構造を示す図である。
【図９】本発明の例示的な第１の実施形態に係るデータの並列送信方法を説明するためのフローチャートである。
【図１０】図９に示すデータの並列送信方法をさらに詳細に説明するためのフローチャートである。
【図１１】本発明の例示的な実施形態に係るデータの並列受信方法を説明するためのフローチャートである。
【図１２】本発明の例示的な他の実施形態に係るデータの並列送受信方法を説明するためのフローチャートである。
【図１３】図１２のステップＳ１２３０をさらに詳細に示すフローチャートである。
【発明を実施するための形態】
【００１５】
以上の本発明の目的、他の目的、特徴及び利点は、添付された図面と関連した以下の好ましい実施形態により容易に理解されるはずである。しかしながら、本発明は、ここで説明される実施形態に限定されず、他の形態で具体化されてもよい。むしろ、ここで紹介される実施形態は、開示された内容が徹底かつ完全になるように、そして当業者に、本発明の思想を十分に理解してもらうために提供されるものである。
【００１６】
本明細書において、ある構成要素が他の構成要素上にあると言及される場合には、それは、他の構成要素上に直接形成される場合もあり、それらの間に第３の構成要素が介在される場合もあることを意味する。
【００１７】
本明細書において第１、第２などの用語が構成要素を述べるために使用された場合、これらの構成要素がこのような用語により限定されてはならない。これらの用語は、単にある構成要素を他の構成要素と区別させるために使用されたものに過ぎない。ここで説明され例示される実施形態は、それの相補的な実施形態も含む。
【００１８】
また、あるエレメント（または構成要素）が他のエレメント（または構成要素）上で動作または実行されると言及されるとき、そのエレメント（または構成要素）は、他のエレメント（または構成要素）が動作または実行される環境で動作または実行されるか、または他のエレメント（または構成要素）と直接または間接的に相互作用により動作または実行されると理解されなければならない。
【００１９】
あるエレメント、構成要素、装置、またはシステムが、プログラム若しくはソフトウェアからなる構成要素を含むと言及される場合には、明示的な言及がなくても、そのエレメント、構成要素、装置、またはシステムは、そのプログラム若しくはソフトウェアが実行または動作するのに必要なハードウェア（例えば、メモリ、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等）や他のプログラムまたはソフトウェア（例えば、オペレーティングシステム（ＯＳ）やハードウェアを駆動するのに必要なドライバ等）を含むと理解されなければならない。
【００２０】
また、あるエレメント（または構成要素）が具現化されるに当たって、特別な言及がない限り、そのエレメント（または構成要素）は、ソフトウェア、ハードウェア、またはソフトウェア及びハードウェアのうち、如何なる形態によっても具現化可能であると理解されなければならない。
【００２１】
本明細書で使用された用語は、実施形態を説明するためのものであって、本発明を限定するものではない。本明細書において、単数形は、特に言及しない限り、複数形も含む。明細書で使用される「含む」と言及された構成要素は、一つ以上の他の構成要素の存在又は追加を排除しない。
【００２２】
以下、図面を参照して本発明を詳細に説明する。以下の特定の実施形態を述べるにおいて、様々に特定された内容は、発明をさらに具体的に説明し、理解を助けるために作成された。しかしながら、本発明を理解することができる程度のこの分野における知識を有した読者は、このような様々に特定された内容がなくても、本発明が実施可能であることを認知できる。ある場合には、周知で発明と大きく関連のない技術的内容は、本発明を説明するにあたって、特別な理由がなくでも、読者の混乱を引き起こさないようにあえて述べないこともあることを予め言及しておく。
【００２３】
図１は、本発明の例示的な実施形態に係るデータの並列送信のための送受信システムを示す図である。
【００２４】
図１に示すように、データの並列送信のための送受信システムは、データ送信装置１０とデータ受信装置２０とを備えることができる。データ送信装置１０は、後述する第１データ送信装置１００又は第２データ送信装置５００である。また、データ受信装置２０は、第１データ受信装置２００又は第２データ受信装置６００である。
【００２５】
データ送信装置１０は、ファイルの送信リクエストを受信すると、ｉ）ファイルの属性情報を含む基本制御情報とｉｉ）ファイルを送信するソケット（ｓｏｃｋｅｔ）を一つ以上生成できる。
【００２６】
ソケットは、ファイルの送信のためにデータ送信装置１０とデータ受信装置２０とを接続するソフトウェアであって、一つのソケットは、一つのストリームを構成できる。データ送信装置１０とデータ受信装置２０との間には、データの並列送信のための複数のストリーム（Ｓ１、Ｓ２、．．．、ＳＮ、Ｎは、整数）が提供される。複数のストリーム（Ｓ１、Ｓ２、．．．、ＳＮ）は、少なくとも一つの通信ポートに割り当てられてもよく、各ストリームは、互いに異なる帯域幅を有するマルチチャネルにより具現化されてもよい。一例として、データ送信装置１０とデータ受信装置２０とは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）チャネルを介して、ファイルを並列ストリーミング送信方式で送受信できるが、これに限定されない。
【００２７】
基本制御情報は、ファイルの送信のために最初に第１データ送信装置１０と第１データ受信装置２０との間で共有される情報である。基本制御情報は、送信するファイルのファイル名、ファイルサイズ、ストリームの個数、ディスクバッファサイズ、全体ブロック個数、ソケットバッファサイズ、ＩＰアドレス、ポート情報及びセッションＩＤ（Ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）などの情報を含むことができる。ストリームの個数は、ファイル送信に使用することができるストリームの最大接続個数で、ディスクバッファサイズは、ディスク（例えば、第２格納媒体２５０（図２参照））にデータを書き込むためにバッファに割り当てられたブロックのサイズであり、ソケットバッファサイズは、送信プロトコルのカーネル（Ｋｅｒｎｅｌ）端で使用するバッファのサイズであり、ＩＰアドレスは、データ送信に用いられるＩＰのアドレスであり、ポート情報は、データ送信に用いられるポートの情報であり、セッションＩＤは、各ストリームのＩＤである。
【００２８】
図２は、本発明の例示的な第１の実施形態に係るデータの並列送信のための第１データ送信装置１００、及び第１データ受信装置２００を示す機能ブロック図である。
【００２９】
図２に示すように、第１データ送信装置１００は、第１格納媒体１１０、第１インアクティブブロックプール１２０、第１ディスクリーダ（Ｄｉｓｋ Ｒｅａｄｅｒ）１３０、第１アクティブブロックプール１４０、第１通信部１５０及び第１制御部１６０を備えることができる。
【００３０】
第１格納媒体１１０には、第１データ受信装置２００に送信する複数のファイルが格納されるとよい。第１格納媒体１１０は、ハードディスクドライブのような大容量格納装置であってもよい。
【００３１】
第１インアクティブブロックプール（ｉｎａｃｔｉｖｅ ｂｌｏｃｋ ｐｏｏｌ）１２０は、データが記録されていない複数のファイルブロックをメモリの効率的な使用のために格納（又は保管）する。ファイルブロックは、第１ディスクリーダ１３０が第１格納媒体１１０に格納された複数のファイルのうち、送信するファイルを記録する時に使用されるとよい。第１インアクティブブロックプール１２０は、例えばメモリのような格納装置から構成されてもよく、後述する第１アクティブブロックプール１４０、第２インアクティブブロックプール２２０、第２アクティブブロックプール２３０、第３インアクティブブロックプール５３０、第３アクティブブロックプール５５０、第４インアクティブブロックプール６３０、及び第４アクティブブロックプール５５０もやはり、メモリのような格納装置から構成されてもよい。一方、第１インアクティブブロックプール１２０と第１アクティブブロックプール１４０とが図２で各々別途の機能ブロックとして示されている。しかし、これらは、それぞれ物理的に別途のメモリとして具現化されることと制限的に解釈されてはならず、第１インアクティブブロックプール１２０と第１アクティブブロックプール１４０は、１つ又は３つ以上のメモリによっても具現化されてもよい。そして、ｉ）第２インアクティブブロックプール２２０と第２アクティブブロックプール２３０、ｉｉ）第３インアクティブブロックプール５３０と第３アクティブブロックプール５５０、及びｉｉｉ）第４インアクティブブロックプール６３０と第４アクティブブロックプール５５０も、やはり、物理的なメモリの個数に限定されて具現化されるものではない。
【００３２】
以下、複数のファイルのうち、第１データ受信装置２００にパッケージ送信するファイルを「送信対象ファイル」とし、送信対象ファイルの一例として第１ファイルと第２ファイルとを例に挙げて説明する。
【００３３】
「パッケージ送信」は、一つのファイルブロックに第１ファイルを記録した後にもファイルブロックに他のファイルを記録できる空き空間がある場合に、第２ファイルの全体又は一部を空き空間に記録することによって、第１ファイルと第２ファイルとを一つのファイルブロックに送信することを意味する。パッケージ送信時に、一つのファイルブロックには、第１ファイルの全体と第２ファイルの全体が記録されたり、第１ファイルの全体と第２ファイルの一部が記録されたり、第１ファイルの一部と第２ファイルの一部が記録されたり、第１ファイルの一部と第２ファイルの全体が記録されたりしてもよい。
【００３４】
図３は、本発明の例示的な実施形態に係るファイルブロックの構造を示す図である。
【００３５】
図３に示すように、ファイルブロック（ＦＢ：Ｆｉｌｅ Ｂｌｏｃｋ）は、ファイルブロックヘッダ（ＦＨ：Ｆｉｌｅｂｌｏｃｋ Ｈｅａｄｅｒ）とファイルブロックペイロード（ＦＰ：Ｆｉｌｅｂｌｏｃｋ Ｐａｙｌｏａｄ）とに区分される。ＦＨには、ファイルブロックがデータを記録していることを表すタグ情報、ＦＰのサイズ、ファイルブロックの圧縮有無を表すフラグが記録されるとよい。ＦＰには、ＦＰのサイズに相当するデータと、記録されたデータの属性情報が記録されるとよい。図３に示すように、データが記録されていない空きファイルブロックは、第１インアクティブブロックプール１２０に格納されるとよい。
【００３６】
第１ディスクリーダ１３０は、第１インアクティブブロックプール１２０から空きファイルブロックを読み出してファイルブロックを一つ又は複数のマイクロブロックに区分できる。
【００３７】
ここで、マイクロブロックは、マイクロブロックヘッダ（ＭＨ：Ｍｉｃｒｏｂｌｏｃｋ Ｈｅａｄｅｒ）とマイクロブロックペイロード（ＭＰ：Ｍｉｃｒｏｂｌｏｃｋ Ｐａｙｌｏａｄ）とを備えるとよい。そして、第１ディスクリーダ１３０は、各々のマイクロブロックのサイズに対応するデータを送信対象ファイルから読み出して、該当するマイクロブロックに順次に記録することができる。すなわち、第１ディスクリーダ１３０は、ＦＰのサイズと第１ファイルのサイズとを比較して、一個のマイクロブロック又は複数のマイクロブロックを生成することによってファイルブロックを分割することができる。マイクロブロックは、少なくとも一つ以上のファイルのデータが記録される単位であって、データが記録されるサイズは自在に変化する。
【００３８】
詳細に説明すれば、第１ディスクリーダ１３０は、ＦＰのサイズと第１ファイルのサイズとに応じて、ＦＰに一つ以上の論理的なマイクロブロックを生成できる。例えば、一つのファイルブロックに記録できるデータのサイズが第１ファイルより小さいか、又は同じであると、第１ディスクリーダ１３０は、ファイルブロックに図４Ａのように、一つのマイクロブロックをファイルブロックに生成できる。また、一つのファイルブロックに記録できるデータのサイズが第１ファイルより大きいと、第１ディスクリーダ１３０は、ファイルブロックに図４Ｂのように少なくとも２つのマイクロブロックを生成してファイルブロックに記録するとよい。
【００３９】
図４Ａは、本発明の例示的な実施形態に係る一つのマイクロブロックを備えるファイルブロックの構造を示す図である。
【００４０】
図４Ａに示すように、ファイルブロックは、ＦＨとＦＰとに区分され、ＦＰは、一つのＭＨと一つのＭＰとに区分される。ＭＨには、ＭＨ ｓｉｚｅ、ｏｆｆｓｅｔ、ｌｅｎｇｔｈ、Ｆｉｌｅ ｓｉｚｅ及びｆｉｌｅｐａｔｈが記録されてもよい。ＭＨ ｓｉｚｅは、ＭＨのサイズであり、ｏｆｆｓｅｔは、第１格納媒体１１０から読み出してＭＰに記録されたデータが第１ファイルのどの位置に属するかを表すデータアドレスであり、ｌｅｎｇｔｈは、ＭＰのサイズ（すなわち、ＭＰに記録されたデータの実際のサイズ）であり、Ｆｉｌｅ ｓｉｚｅは、データが属する第１ファイルの全体のサイズであり、ｆｉｌｅｐａｔｈは、第１ファイルが第１格納媒体１１０に格納されたディレクトリとファイル名を含むとよい。ＭＰには、ＭＰのサイズ以下のサイズのデータが記録されるとよい。
【００４１】
図４Ｂは、本発明の例示的な実施形態に係る一つのマイクロブロックを含むファイルブロックの構造を示す図である。
【００４２】
図４Ｂに示すように、ファイルブロックは、ＦＨとＦＰとに区分され、ＦＰは、複数のマイクロブロックヘッダＭＨ１、ＭＨ２、ＭＨ３と複数のマイクロブロックペイロードＭＰ１、ＭＰ２、ＭＰ３とに区分される。図４Ｂには、３個のマイクロブロックＭＢ１、ＭＢ２、ＭＢ３が示されているが、これは、一例に過ぎず、２個もしくは４個以上のマイクロブロックにより、ファイルブロックが形成されてもよい。
【００４３】
各ＭＨ１、ＭＨ２、ＭＨ３には、図４Ａを参照して説明されたＭＨ ｓｉｚｅ、ｏｆｆｓｅｔ、ｌｅｎｇｔｈ、Ｆｉｌｅ ｓｉｚｅ及びｆｉｌｅｐａｔｈが記録される。例えば、ＭＨ１には、ＭＰ１に対して説明したＭＨ ｓｉｚｅ、ｏｆｆｓｅｔ、ｌｅｎｇｔｈ、Ｆｉｌｅ ｓｉｚｅ及びｆｉｌｅｐａｔｈが記録される。図４Ｂのように一つのファイルブロックが３個のＭＢ１、ＭＢ２、ＭＢ３に区分されることは、一つのファイルブロックに第１ないし第３ファイルが記録されてパッケージ送信されることを意味する。ここで、ＭＢ１には、第１ファイルの一部又は全体のデータが記録され、ＭＢ２には、第２ファイルの全体のデータが記録され、ＭＢ３には、第３ファイルの一部又は全体のデータが記録されてもよい。
【００４４】
第１ディスクリーダ１３０が少なくとも一つ以上のマイクロブロックを生成する動作を説明すると、以下の通りである。例えば、ユーザが第１ファイルと第２ファイルとのパッケージ送信をリクエストしたと仮定する。
【００４５】
１．第１ディスクリーダ１３０は、第１ファイルの全体のデータサイズとＦＰの最大サイズとを比較して第１ファイルの全体をＦＰにすべて記録できる場合に、一つのＭＢ１を生成し、ＭＰ１に第１ファイルの全体のデータを記録する。一方、ＦＰのＭＰにデータが記録されるので、ＭＰのサイズと第１ファイルの全体のデータのサイズとを比較することが正確な表現であるが、本願発明の説明において、ＦＰのサイズを比較するという表現とＭＰのサイズを比較するという表現とを、特に区別する実益がない限り、互いに同じ意味として混用して使用するようにする。
【００４６】
２．また、第１ディスクリーダ１３０は、第１ファイルの全体のデータがＦＰの最大サイズより大きな場合、ＦＰの最大サイズと一致するデータを第１ファイルから読み出して一つのＭＢ１を生成し、第１ファイルの残ったデータは、次のファイルブロックに記録することができる。したがって、ＦＰに他のデータを記録できる空き空間がない場合に、第１ディスクリーダ１３０は、図４Ａに示すように、一つの第１マイクロブロックを生成し、このとき、ＭＰ１には、第１ファイルの全体のデータ又は一部のデータのみが記録される。
【００４７】
３．これに対し、ＦＰに第１ファイルのデータを記録した後、他のデータを記録できる空き空間がある場合、第１ディスクリーダ１３０は、次に送信する第２ファイルを読み込んでＭＢ２をさらに生成してファイルブロックを一杯にすることができる。すなわち、第１ディスクリーダ１３０は、ＦＰの空き空間と第２ファイルの全体のデータのサイズとを比較して、ＦＰの空き空間にＭＢ２を生成し、ＭＰ２に第２ファイルの全体又は一部のデータを記録するとよい。これにより、ファイルブロックには、２つのマイクロブロックＭＢ１、ＭＢ２が生成される。
【００４８】
４．仮に、ＦＰの空き空間のサイズより第２ファイルのサイズが大きい場合、第１ディスクリーダ１３０は、ＦＰの空き空間に相当するだけのデータを第２ファイルから読み出して記録し、次のファイルブロックに第２ファイルの残りのデータを記録するとよい。
【００４９】
第１アクティブブロックプール１４０は、少なくとも一つ以上のマイクロブロックが生成されたファイルブロックを一時的に保管できる。すなわち、第１アクティブブロックプール１４０は、少なくとも一つ以上の送信対象ファイルが記録されたファイルブロックを一時的に保管できる。
【００５０】
第１通信部１５０は、図４Ａ又は図４Ｂに示すように、データが記録された複数のファイルブロックが第１アクティブブロックプール１４０に保管されると、複数のファイルブロックを第１データ受信装置２００に送信できる。第１通信部１５０は、複数のファイルブロックを並列ＴＣＰストリーム方式で第１データ受信装置２００に送信できる。このために、第１通信部１５０は、複数の第１ソケットライター１５１を含み、第１ソケットライター１５１は、第１アクティブブロックプール１４０に未送信のファイルブロックがあるかどうかを確認し、未送信のファイルブロックを第１データ受信装置２００に送信できる。第１ソケットライター１５１は、各々一つのＴＣＰストリームに対応して、ファイルブロックを同時に並列送信できる。第１ソケットライター１５１は、送信が完了したファイルブロックを第１インアクティブブロックプール１２０に送信することができる。
【００５１】
第１制御部１６０は、少なくとも一つ以上のプロセッサを利用して、上述した第１データ送信装置１００の動作を制御できる。
【００５２】
一方、第１データ受信装置２００は、第２通信部２１０、第２インアクティブブロックプール２２０、第２アクティブブロックプール２３０、第１ディスクライター（Ｄｉｓｋ Ｗｒｉｔｅｒ）２４０、第２格納媒体２５０及び第２制御部２６０を備えることができる。
【００５３】
第２通信部２１０は、第１データ送信装置１００から並列ＴＣＰストリームを介してファイルブロックを受信することができる。このために、第２通信部２１０は、複数の第１ソケットリーダ２１１を含み、第１ソケットリーダ２１１は、第１ソケットライター１５１と各々一つのＴＣＰストリームを確立することができる。
【００５４】
第２インアクティブブロックプール２２０は、図３のように空きファイルブロックを保管できる。保管されたファイルブロックは、第２通信部２１０を介して受信されたファイルブロックのデータを記録する時に使用される。
【００５５】
第１ソケットリーダ２１１は、ファイルブロックが受信されるたびに第２インアクティブブロックプール２２０から空きファイルブロックを取得し、受信されたファイルブロックのデータを空きファイルブロックに記録するとよい。そして、第１ソケットリーダ２１１は、受信されたデータが記録されたファイルブロックを第２アクティブブロックプール２３０に保管するとよい。例えば、受信されたファイルブロックが図４Ｂのように３個のＭＢ１、ＭＢ２、ＭＢ３を含む場合に、第１ソケットリーダ２１１は、空きファイルブロックに図４Ｂと同じ形態でヘッダ情報とファイルのデータを記録するとよい。第１ソケットリーダ２１１は、ファイルのパッケージ送信が完了するまで、上述した動作を繰り返す。
【００５６】
第１ディスクライター２４０は、受信されたファイルブロックが各々少なくとも一つ以上のマイクロブロックを含む場合、マイクロブロック単位でデータを読み込んで第２格納媒体２５０に記録するとよい。
【００５７】
詳細に説明すれば、第１ソケットリーダ２１１が上述した動作を行う間に、第１ディスクライター２４０は、第２アクティブブロックプール２３０にファイルブロックがあるかどうかを確認する。第１ディスクライター２４０は、第２アクティブブロックプール２３０にファイルブロックがあると、ファイルブロックのＭＨに記録された情報を参照して、ＭＰに記録されたデータを第２格納媒体２５０に記録できる。ファイルブロック、すなわち、ＭＰに記録されたデータが第２格納媒体２５０に記録されると、第１ディスクライター２４０は、空きファイルブロックを第２インアクティブブロックプール２２０に伝達できる。
【００５８】
第１ディスクライター２４０が少なくとも一つ以上のマイクロブロックに記録されたデータを第２格納媒体２５０に記録する動作について説明すると、以下のとおりである。
【００５９】
まず、ファイルブロックが図４Ａのように一つのマイクロブロックを含む場合、第１ディスクライター２４０は、ＭＨのオフセットを確認し、第２格納媒体２５０のうち、オフセットに対応する位置にＭＰに記録されたデータを記録できる。例えば、ＭＰに記録されたデータが第１ファイルのデータで、オフセットが「０」である場合に第１ディスクライター２４０は、データが第１ファイルの最初の部分に位置すると判定し、第２格納媒体２５０のうち、第１ファイルが記録される領域のうち、最初の部分に記録できる。第１ディスクライター２４０は、ＭＨのＦｉｌｅｓｉｚｅから第１ファイルの全体サイズが分かるので、第１ファイルが第２格納媒体２５０で占める大きさが分かり、第１ファイルが記録される領域を予め割り当てることができる。
【００６０】
また、ファイルブロックが図４Ｂのように３個のＭＢ１、ＭＢ２、ＭＢ３を含む場合に、第１ディスクライター２４０は、ＭＨ１のｆｉｌｅｐａｔｈからファイル名を確認し、確認されたファイル名が第１ファイルであると、第１ファイルをＭＨ１に記録されたオフセットを参照してＭＰ１に記録されたデータを第２格納媒体２５０に記録できる。以後、第１ディスクライター２４０は、ＭＨ２のｆｉｌｅｐａｔｈからファイル名を確認し、確認されたファイル名が第２ファイルであると、第２ファイルをＭＨ２に記録されたオフセットを参照してＭＰ２に記録されたデータを第２格納媒体２５０に記録できる。ＭＢ３に記録されたデータを記録する過程も上述したとおりである。
【００６１】
第２制御部２６０は、少なくとも一つ以上のプロセッサを利用して上述した第１データ受信装置２００の動作を制御できる。
【００６２】
図５は、本発明の例示的な第２の実施形態に係るデータの並列送信のための第２データ送信装置５００及び第２データ受信装置６００を示すブロック図である。
【００６３】
第２データ送信装置５００及び第２データ受信装置６００は、送信対象ファイルをパッケージ送信しながらレジュームダウンロード送信をすることができる。このために、第２データ送信装置５００は、第３格納媒体５１０、リスト管理部５２０、第３インアクティブブロックプール５３０、第２ディスクリーダ５４０、第３アクティブブロックプール５５０、第３通信部５６０及び第３制御部５７０を備えることができる。
【００６４】
図５に示す第３格納媒体５１０、第３インアクティブブロックプール５３０、第２ディスクリーダ５４０、第３アクティブブロックプール５５０、第３通信部５６０及び第３制御部５７０の全般的な動作は、図２を参照して説明された第１格納媒体１１０、第１インアクティブブロックプール１２０、第１ディスクリーダ５４０、第１アクティブブロックプール１４０、第１通信部１５０及び第１制御部１６０の動作とそれぞれ同一又は類似しているので、これらについての詳細な説明を省略する。
【００６５】
リスト管理部５２０は、第２データ受信装置６００にパッケージ送信する送信対象ファイルにインデックスを割り当て、送信対象ファイルのインデックス、ファイル名及びファイルサイズに対する情報を送信ファイルリストに加えることによって、１又は複数の送信ファイルリストを作成できる。例えば、リスト管理部５２０は、１００個の送信対象ファイルを第２データ受信装置６００に送信しようとする場合に、１００個のファイルに０〜９９までのインデックスを割り当て、１００個のファイルを例えば２０個ずつ分類して５個の第１ないし第５送信ファイルリストを作ることができる。リスト管理部５２０は、第２データ受信装置６００に作成した送信対象ファイルを送信する。
【００６６】
また、リスト管理部５２０は、複数の送信ファイルリストを第２データ受信装置６００に送信してもよい。また、リスト管理部５２０は、先に送信した送信ファイルリストに対して第２データ受信装置６００のリスト確認部６２０から応答（例えば、レジュームダウンロードリスト）があると、次に送信ファイルリストを送信してもよい。
【００６７】
図６は、本発明の例示的な実施形態に係る送信ファイルリストの構造を示す図である。
【００６８】
図６に示すように、リスト管理部５２０は、第１〜第ｎインデックス、第１〜第ｎファイル名、第１〜第ｎファイルサイズ、及び終了識別子を含む送信ファイルリストを作成することができる。第１〜第ｎインデックスは、送信ファイルリストに含まれるｎ個のファイルに割り当てられたインデックスである。第１〜第ｎファイル名は、第１ないし第ｎインデックスに対応する各ファイルのファイル名である。第１〜第ｎファイルサイズは、第１〜第ｎインデックスに対応する各ファイルのサイズである。終了識別子は、もうこれ以上送信するファイルがない場合を表示するための終結文字（ｅｎｄ ｄｅｌｉｍｉｔｅｒ）であって、最後の送信ファイルリストに追加で記載されるとよい。
【００６９】
リスト管理部５２０は、送信するファイルが全部でｍ個（ｍ＞ｎ）ある場合に、図６のような送信ファイルリストを２つ以上作成することができる。
【００７０】
図６に示す送信ファイルリストの例を参照すれば、送信ファイルリストは、第１〜第ｎファイルに対するファイル情報を含んでいる。詳細には、送信ファイルリストは、第１〜第ｎファイルのインデックスとして０，１，．．．，ｎ−１と、第１〜第ｎファイルのファイル名としてａ，ｓｏ．ｔｘｔ，．．．，ｂ．ｊｐｇと、第１〜第ｎファイルのサイズとして１０ｂｙｔｅｓ，３０００ｂｙｔｅｓ，．．．，１０００ｂｙｔｅｓを含んでいる。
【００７１】
また、図５に示すように、第３通信部５６０は、複数の送信ファイルリストを順次に、並列ＴＣＰストリームとは異なる独立的なチャネルを介して第２データ受信装置６００に送信できる。また、第３通信部５６０は、複数の送信ファイルリストを順次に第２データ受信装置６００に送信する間に、ファイルブロックを並列ＴＣＰストリームを介して第２データ受信装置６００に送信できる。
【００７２】
第２ディスクリーダ５４０は、レジュームダウンロードリストが第２データ受信装置６００から受信されると、レジュームダウンロードリストに含まれたインデックスに対応するファイルを送信対象ファイルから確認し、該確認されたファイルのうち、レジュームダウンロードリストに含まれたオフセットに対応する位置からのデータをファイルブロックに記録してレジュームダウンロード送信を試みることができる。第２ディスクリーダ５４０は、図４Ａ又は図４Ｂを参照して説明されたファイルブロック（又はマイクロブロック）を利用して、レジュームダウンロードするファイルのデータをファイルブロックに記録できる。
【００７３】
一方、第２データ受信装置６００は、第４通信部６１０、リスト確認部６２０、第４インアクティブブロックプール６３０、第４アクティブブロックプール６４０、第２ディスクライター６５０、第４格納媒体６６０及び第４制御部６７０を備えることができる。図５に示す第４通信部６１０、第４インアクティブブロックプール６３０、第４アクティブブロックプール６４０、第２ディスクライター６５０、第４格納媒体６６０、及び第４制御部６７０の全般的な動作は、図２を参照して説明された第２通信部２１０、第２インアクティブブロックプール２２０、第２アクティブブロックプール２３０、第１ディスクライター２４０、第２格納媒体２５０、及び第２制御部２６０の動作を含むので、詳細な説明を省略する。
【００７４】
第４通信部６１０は、第２データ送信装置５００から送信ファイルリストを順次に受信し、各送信ファイルリストに対する応答であるレジュームダウンロードリスト（後述するリスト確認部６２０により作成されたものである）を第２データ送信装置５００に送信できる。また、送信ファイルリストが受信される間に、第４通信部６１０は、第２データ送信装置５００からファイルブロックを並列ＴＣＰストリームを介してファイルブロックを受信することができる。送信ファイルリストは、第２データ送信装置５００の送信対象ファイルのインデックス、ファイル名及びファイルサイズに対する情報を含む。
【００７５】
リスト確認部６２０は、第２データ送信装置５００から受信された送信ファイルリストとファイルブロックを利用して既に受信された複数のファイルを比較して、既受信の複数のファイルのうち、レジュームダウンロードするファイルを決定し、決定されたファイルのインデックスとオフセット（決定されたファイルのうち、レジュームダウンロードするデータのスタートアドレスを表す）を含むレジュームダウンロードリストを作成して、第２データ送信装置５００に送信できる。リスト確認部６２０によって作成されるレジュームダウンロードリストを、図８を参照して説明する。
【００７６】
リスト確認部６２０は、送信ファイルリストに含まれたファイルが第４格納媒体６６０に格納されていない場合、すなわち、送信ファイルリストを先に受信した場合、送信ファイルリストに含まれたファイルの全体送信をリクエストするレジュームダウンロードリストを作成することができる。
【００７７】
図７は、本発明の例示的な実施形態に係るメタファイルの構造を示す図である。
【００７８】
図７に示すように、第２ディスクライター６５０は、ＦＢの最大送信サイズ、受信された累積ファイルサイズ、第１番目のＭＢ（又はＦＢ）のサイズ、ｉ番目のＭＢ（又はＦＢ）のフラグ及び終了識別子を含むメタファイルを作成することができる。
【００７９】
第１ファイルが受信された場合、「ＦＢの最大送信サイズ」は、第１ファイルを送信するファイルブロックに割り当てられた最大送信量である。「受信された累積ファイルサイズ」は、少なくとも一つ以上のファイルブロックを介して受信された第１ファイルの累積サイズ（累積量）である。例えば、「受信された累積ファイルサイズ」は、第１ファイルが３個のファイルブロックを介して受信された場合、３個のファイルブロックに記録された第１ファイルのサイズを足し合せたものである。第１ファイルを送信するファイルブロックのうち、一つが未だ受信されていない場合に、第１ファイルの受信された累積ファイルサイズは、第１ファイルの実際のサイズより小さくなる。
【００８０】
「第１番目のＭＢのサイズ」は、第１ファイルを最初に送信したマイクロブロックのサイズであって、「第１番目のＭＢのサイズ」は、ＦＰの最大ＭＰサイズと同一であるか、又はＦＰの最大ＭＰサイズより小さいとよい。「第１番目のＭＢのサイズ」がＦＰより小さい場合は、一つのファイルブロックに少なくとも２つのファイルが記録されている場合である。ｉ番目のＭＢのフラグは、第１ファイルを連続的に送信した後、ＭＢの受信有無を表す情報である。ｉ＝２，３，．．．，ｍ（ｍは、正数）である。ｆｉ＝０は、第１ファイルのデータを記録したｉ番目のＭＢが受信されていないことを意味し、ｆｉ＝１は、ｉ番目のＭＢが受信されたことを意味する。
【００８１】
図７に示すメタファイルの例を参照すれば、一つのＦＢが最大１Ｍｂｙｔｅｓのデータを送信できる場合に、第２ディスクライター６５０は、「ＦＢの最大送信サイズ」に１Ｍｂｙｔｅｓを記録する。第１ファイルが４個の第１ないし第４ファイルブロックを介して受信された場合、第２ディスクライター６５０は、受信された累積ファイルサイズ」に４個のファイルブロックに記録された第１ファイルのサイズを合せた２．５Ｍｂｙｔｅｓを記録する。第１ファイルを最初に送信したファイルブロックが第１ファイルブロックである場合、第２ディスクライター６５０は、「１ＳＴ ＭＢのサイズ」に第１ファイルブロックに記録された第１ファイルのデータのサイズ、すなわち、第１ファイルのデータを記録したＭＢのサイズを記録する。第１ファイルの残ったデータを記録した第２ファイルブロックと第４ファイルブロックとは、正常に受信され、第３ファイルブロックは、受信されない場合、第２ディスクライター６５０は、ｆ２に「１」を記録し、ｆ３に「０」を記録し、ｆ４に「１」を記録する。
【００８２】
第２ディスクライター６５０は、メタファイルを作成しながら、それと同時にＭＰに記録されたデータをＭＨに記録されたオフセットを参照して第４格納媒体６６０に格納することができる。作成されたメタファイルは、第２ディスクライター６５０が使用するメモリ（図示せず）に格納されるとよい。したがって、メモリには、第２データ送信装置５００から受信されたファイルのメタファイルが格納されるとよい。
【００８３】
第２ディスクライター６５０は、少なくとも一つのファイルブロックを介して受信された少なくとも一つの以上のファイルごとにメタファイルを作成することができる。また、第２ディスクライター６５０は、受信されたファイルの途中からの欠落又は受信されたファイルの中間の欠落がない状態ですべて送信されたと確認されると、メタファイルを削除できる。第２ディスクライター６５０は、メタファイルのフラグがすべて１で、第１番目のＭＢのサイズが０でないと、ファイルがすべて受信されて第４格納媒体６６０に格納されたと判定できる。
【００８４】
以下、リスト確認部６２０がメモリに格納されたメタファイルを参照してレジュームダウンロードリストを作成し、リスト管理部５２０がレジュームダウンロードファイルのデータを再送信する動作について説明する。
【００８５】
第２データ送信装置５００から受信された送信ファイルリストに含まれたファイル名に対応するファイルが、既に受信された複数のファイルのうちの一つである第１ファイルであり、第１ファイルのメタファイルが存在すると、リスト確認部６２０は、第１ファイルをレジュームダウンロードするファイルと決定できる。すなわち、リスト確認部６２０は、送信ファイルリストに含まれたファイルを確認し、確認されたファイルのうち、メタファイルが存在するファイルは、すべてレジュームダウンロードするファイルと決定できる。リスト確認部６２０は、レジュームダウンロードするファイルの情報を利用して、レジュームダウンロードリストを作成することができる。
【００８６】
図８は、本発明の例示的な実施形態に係るレジュームダウンロードリストの構造を示す図である。
【００８７】
図８に示すように、リスト確認部６２０は、レジュームダウンロードするファイルのインデックス、オフセット及び終了識別子を含むレジュームダウンロードリストを作成することができる。リスト確認部６２０は、データ送信量を最小化するためにレジュームダウンロードするファイルのファイル名をレジュームダウンロードリストに含めなくてもよく、これは選択事項である。
【００８８】
「レジュームダウンロードするファイルのインデックス」は、レジュームダウンロードするファイルに割り当てられた固有識別子であって、図６の送信ファイルリストから取得できる。「オフセット」は、レジュームダウンロードするファイルのうち、レジュームダウンロードするデータのスタートアドレスを表す。「終了識別子」は、送信ファイルリストに含まれたファイルのうち、レジュームダウンロードするファイルの情報をレジュームダウンロードリストにすべて記録した後に、現在の送信ファイルリストに対してもうこれ以上レジュームダウンロードするファイルがないことを通知する終結文字である。
【００８９】
図８に示すレジュームダウンロードリストの例を参照すれば、リスト確認部６２０は、一つの送信ファイルリストに含まれたファイルのうち、レジュームダウンロードするファイルとして決定されたファイルのインデックスがそれぞれ「０」と「３」である場合に、「０」と「３」をインデックス領域に記録する。
【００９０】
リスト確認部６２０は、該当するメタファイルの「１ＳＴ ＭＢのサイズ」とフラグ情報を参照してオフセット（レジュームダウンロードするデータのスタートアドレス）を算出できる。
【００９１】
詳細に説明すれば、レジュームダウンロードするファイルとして決定されたファイルが第１ファイルで、第１ファイルが複数のファイルブロックを介して受信された場合に、リスト確認部６２０は、第１ファイルのメタファイルに第１ファイルを最初に送信した第１番目のファイルブロック（ｉ＝１）の送信量（１ＳＴ ＭＢのサイズ）が０と記録されていると、第１ファイルのオフセットを０とするレジュームダウンロードリストを作成することができる。このような場合、第２データ送信装置５００は、第１ファイルを始めから再送信する。
【００９２】
また、リスト確認部６２０は、第１ファイルが複数のファイルブロックを介して受信された場合、メタファイルに第１ファイルを最初に送信した第１番目のファイルブロック（ｉ＝１）の送信量がｋバイト（ｋは、正数）と記録されており、第１ファイルをｉ（ｉ＝２，３，．．．，ｍ）番目に送信したファイルブロックのフラグが０であると、「ｋバイト＋（ｉ−２）＊ｎバイト」を第１ファイルのオフセットとして算出できる。ｎバイトは、図７に示す「ＦＢの最大送信サイズ」である。
【００９３】
図８に示すレジュームダウンロードリストの例を参照すれば、リスト確認部６２０は、一つの送信ファイルリストに含まれたファイルのうち、レジュームダウンロードするファイルとして決定された第１ファイルと第２ファイルのインデックスがそれぞれ「０」と「３」である場合に、「０」と「３」とをインデックス領域に記録する。図７に示すメタファイルの例が第１ファイルのメタファイルである場合に、リスト確認部６２０は、次のように第１ファイルのオフセットを算出する。
【００９４】
オフセット＝ｋバイト＋（ｉ−２）＊ｎバイト＝０．５Ｍｂｙｔｅｓ＋（３−２）＊１Ｍｂｙｔｅｓ＝１．５Ｍｂｙｔｅｓ
したがって、リスト確認部６２０は、第１ファイルのインデックスである「０」とオフセットである「１．５Ｍｂｙｔｅｓ」をレジュームダウンロードリストに図８のように記録できる。これと同じ方法によって、リスト確認部６２０は、第２ファイルのインデックスである「３」とオフセットである「１５３０ｂｙｔｅｓ」とをレジュームダウンロードリストに図８のように記録できる。図８のようにレジュームダウンロードリストを受信した第２データ送信装置５００は、レジュームダウンロードリストに含まれたインデックスに対応するファイルを確認し、確認されたファイルのうち、オフセットに対応する位置（又はその次の位置）からのデータを第２データ受信装置６００にファイルブロックを利用してパッケージ方式で再送信できる。
【００９５】
上述した本発明の例示的な第２の実施形態に係るリスト管理部５２０、リスト確認部６２０、第２ディスクリーダ５４０、第２ディスクライター６５０、第２ソケットライター５６１及び第２ソケットリーダ６１１は、スレッド（ｔｈｒｅａｄ）として動作して同時に実行されてもよい。
【００９６】
図９は、本発明の例示的な第１の実施形態に係るデータの並列送信方法を説明するためのフローチャートである。
【００９７】
図９のデータの並列送信方法を行う第１データ送信装置は、図２を参照して説明した第１データ送信装置１００であるとよい。
【００９８】
図９に示すように、第１データ送信装置は、ユーザから複数のファイルのパッケージ送信リクエストを受信する（Ｓ９１０）。以下、第１及び第２ファイルのパッケージ送信を例に挙げて説明する。
【００９９】
第１データ送信装置は、パッケージ送信がリクエストされたファイルのうち、第１ファイルのデータを格納媒体から読み出して、ＭＢを生成する（Ｓ９２０）。ステップＳ９２０にて、第１データ送信装置は、第１ファイルのデータを読み出す前にインアクティブブロックプールから持ってきたＦＰの最大サイズと第１ファイルの全体サイズとを比較してＭＢを生成できる。これに対しては、図１０を参照して詳細に説明する。
【０１００】
第１データ送信装置は、生成されたＭＢの中のＭＰに、読み出したデータを記録した後、ＦＰにＭＢを格納する（Ｓ９３０）。
【０１０１】
第１データ送信装置は、ＦＰにデータをさらに記録できる領域が残っていているかどうかを確認する（Ｓ９４０）。
【０１０２】
残った領域がないと（Ｓ９４０−Ｎ）、第１データ送信装置は、ＦＰ全体にデータが記録されたＦＢを第１データ受信装置に並列ＴＣＰストリーム方式を介して送信する（Ｓ９５０）。
【０１０３】
これに対し、残った領域があると（Ｓ９４０−Ｙ）、パッケージ送信する全てのファイルがＦＢに記録されたかどうかを確認する（Ｓ９６０）。ステップＳ９６０にて、第１データ送信装置は、第１ファイルの全てがＦＢに記載されたと判定し、さらに送信する第２ファイルがあるかどうかを確認する。
【０１０４】
パッケージ送信する全てのファイルが記録されていると（Ｓ９６０−Ｙ）、第１データ送信装置は、ＦＰの一部が空いているＦＢを第１データ受信装置に送信する（Ｓ９７０）。
【０１０５】
パッケージ送信するファイルが残っていると（Ｓ９６０−Ｎ）、第１データ送信装置は、ステップＳ９２０に進んで第２ファイルのデータを読み出し、ステップＳ９２０ないしステップＳ９７０を繰り返す。
【０１０６】
図１０は、図９に示すデータの並列送信方法をさらに詳細に説明するためのフローチャートである。
【０１０７】
図１０に示すように、第１データ送信装置は、ユーザから複数のファイルのパッケージ送信リクエストを受信する（Ｓ１０００）。以下、第ｎファイル及び第ｎ＋１ファイルのパッケージ送信を例に挙げて説明する。
【０１０８】
第１データ送信装置は、ＦＢに割り当て可能なＭＰの最大サイズと第ｎファイルのデータのサイズとを比較する（Ｓ１００５）。ステップＳ１００５にて、第１データ送信装置は、インアクティブブロックプールからＦＢを持ってきて第１格納媒体から第ｎファイルを読み出して、サイズを比較する。
【０１０９】
ＭＰの最大サイズが第ｎファイルのデータのサイズより大きいと（Ｓ１０１０−Ｙ）、第１データ送信装置は、第ｎファイルのデータのサイズに相当するＭＢ（以下、ＭＢｎとする）を生成する（Ｓ１０１５）。
【０１１０】
そして、第１データ送信装置は、ＭＢｎのＭＨｎとＭＰｎにそれぞれヘッダ情報と第ｎファイルのデータとを記録する（Ｓ１０２０）。ステップＳ１０２０にて記録されるヘッダ情報は、図４Ａを参照して説明された情報であるとよい。
【０１１１】
第１データ送信装置は、パッケージ送信がリクエストされた第ｎ＋１ファイルが記録されたかどうかを確認し、記録されていないと（Ｓ１０２５−Ｎ）、第１データ送信装置は、ＦＰのうちＭＢｎを除いて残ったＭＰの最大サイズと第ｎ＋１ファイルのデータのサイズを比較する（Ｓ１０３０）。
【０１１２】
そして、第１データ送信装置は、「ｎ＝ｎ＋１」と定めた後（Ｓ１０３５）、ステップＳ１０１０に進んでステップＳ１０１５ないしステップＳ１０２０を繰り返し行う。
【０１１３】
これに対して、第１データ送信装置は、第ｎ＋１ファイルが記録されたことが確認されると（Ｓ１０２５−Ｙ）、ＦＰの一部が空いているＦＢを第１データ受信装置に送信する（Ｓ１０４０）。ステップＳ１０４０にて送信されるＦＢには、第ｎファイルと第ｎ＋１ファイルとが記録されてパッケージ送信される。
【０１１４】
一方、ステップＳ１０１０にて、ＭＰの最大サイズと第ｎファイルのデータのサイズが同一であると（Ｓ１０４５−Ｙ）、第１データ送信装置は、第ｎファイルのデータのサイズに相当するＭＢｎを生成する（Ｓ１０５０）。
【０１１５】
そして、第１データ送信装置は、ＭＢｎのＭＨｎとＭＰｎにそれぞれヘッダ情報と第ｎファイルのデータとを記録する（Ｓ１０５５）。
【０１１６】
第ｎファイルのデータが記録されると、第１データ送信装置は、パッケージ送信がリクエストされた第ｎ＋１ファイルが記録されたかどうかを確認し、記録されていないと（Ｓ１０６０−Ｎ）、第１データ送信装置は、「ｎ＝ｎ＋１」と定めた後（Ｓ１０６５）、ステップＳ１００５に進む。
【０１１７】
これに対し、第１データ送信装置は、第ｎ＋１ファイルが記録されたことが確認されると（Ｓ１０６０−Ｙ）、ＦＰ全体にデータが記録されたＦＢ（ＭＢｎを含むＦＢ）を含む複数のＦＢを第１データ受信装置に送信する（Ｓ１０７０）。ステップＳ１０７０にて送信されるＦＢには、第ｎファイルと第ｎ＋１ファイルとが記録されて、当該ＦＢがパッケージ送信される。
【０１１８】
一方、ＭＰの最大サイズと第ｎファイルのデータのサイズが同一でなく（Ｓ１０４５−Ｎ）、ＭＰの最大サイズより第ｎファイルのデータのサイズが大きな場合（Ｓ１０７５）、第１データ送信装置は、ＭＰの最大サイズに相当するＭＢｎを生成する（Ｓ１０８０）。
【０１１９】
第１データ送信装置は、ＭＢｎのＭＨｎとＭＰｎにそれぞれヘッダ情報と第ｎファイルのデータを記録する（Ｓ１０８５）。
【０１２０】
そして、第１データ送信装置は、次のＦＢのＭＰの最大サイズと第ｎファイルの残ったデータのサイズとを比較する（Ｓ１０９０）。
【０１２１】
これと共に、第１データ送信装置は、「ＦＢ＝次のＦＢ」と定め、「第ｎファイルのサイズ＝第ｎファイルの残ったデータのサイズ」と定めた後（Ｓ１０９５）、Ｓ１０１０ステップに進む。これにより、第１データ送信装置は、ステップＳ１０１０ないしステップＳ１０９５を繰り返し行って、第ｎファイルの残ったデータを次のＦＢに記録する。
【０１２２】
図１１は、本発明の例示的な実施形態に係るデータの並列受信方法を説明するためのフローチャートである。
【０１２３】
図１１のデータの並列受信方法を行う第１データ受信装置は、図２を参照して説明された第１データ受信装置２００である。
【０１２４】
図１１に示すように、第１データ受信装置は、第１データ送信装置から受信されたＦＢのヘッダ情報とデータを、空いているＦＢに記録する（Ｓ１１１０）。ステップＳ１１１０において、第１データ受信装置は、受信されたＦＢが複数のＭＢを含む場合、空いているＦＢを複数のＭＢに区分して同様にデータを記録してもよい。
【０１２５】
第１データ受信装置は、ヘッダ情報とデータが記録されたＦＢをアクティブブロックプールに保管する（Ｓ１１２０）。
【０１２６】
第１データ受信装置は、アクティブブロックプールに保管されたＦＢからデータをＭＢ単位で読み出して、第２格納媒体に記録する（Ｓ１１３０）。ステップＳ１１３０において、第１データ受信装置は、ＭＨに記録されたオフセットを参照して、ＭＰに記録されたデータを第２格納媒体に記録する。
【０１２７】
第１データ受信装置は、ＦＢに残ったＭＢがあると（Ｓ１１４０−Ｙ）、ステップＳ１１３０を繰り返し行う。
【０１２８】
これに対し、ＦＢに残ったマイクロブロックがないと（Ｓ１１４０−Ｎ）、すなわち、ＦＰに記録されたデータがすべて第２格納媒体に記録されると、アクティブブロックプールに他のＦＢがあるかどうかを確認する（Ｓ１１５０）。
【０１２９】
アクティブブロックプールに他のＦＢがあると（Ｓ１１５０−Ｙ）、第１データ受信装置は、ステップＳ１１１０に進む。
【０１３０】
これに対し、アクティブブロックプールに他のＦＢがないと（Ｓ１１５０−Ｎ）、第１データ受信装置は、パッケージ送信がリクエストされたファイルの格納が完了したかどうかを確認する（Ｓ１１６０）。ステップＳ１１６０にて、第１データ受信装置は、ＭＨのＦｉｌｅ ｓｉｚｅに記録されたサイズと実際に受信されたデータのサイズとが同じ場合に、ファイルの格納が完了したと確認することができる。
【０１３１】
格納が完了した場合（Ｓ１１６０−Ｙ）に、第１データ受信装置は、パッケージファイルの受信が完了したことを報告する受信完了メッセージを第１データ送信装置に送信する（Ｓ１１７０）。
【０１３２】
格納が完了しない場合（Ｓ１１６０−Ｎ）、第１データ受信装置は、ステップＳ１１５０に進む。
【０１３３】
図１２は、本発明の例示的な他の実施形態に係るデータの並列送受信方法を説明するためのフローチャートである。
【０１３４】
図１２のデータの並列送受信方法を行う第２データ送信装置と第２データ受信装置とは、図５を参照して説明された第２データ送信装置５００と第２データ受信装置６００である。
【０１３５】
図１２に示すように、第２データ送信装置は、ユーザから複数のファイルのパッケージ送信リクエストを受信する（Ｓ１２０５）。
【０１３６】
第２データ送信装置は、パッケージ送信する送信対象ファイルを分割して、複数のグループを作る（Ｓ１２１０）。
【０１３７】
第２データ送信装置は、各グループに属するファイルの情報に基づき、図６のような送信ファイルリストを作成する（Ｓ１２１５）。すなわち、第２データ送信装置は、一つのグループに対して一つの送信ファイルリストを作成する。送信ファイルリストは、一つのグループに属したファイルのインデックス、ファイル名及び全体ファイルサイズに対する情報を含む。
【０１３８】
第２データ送信装置は、ステップＳ１２１５にて作成された送信ファイルリストを第２データ受信装置に送信する（Ｓ１２２０）。
【０１３９】
第２データ送信装置は、作成された送信ファイルリストを送信する間に、残りのグループに対する送信ファイルリストの作成が完了したかどうかを確認する（Ｓ１２２５）。
【０１４０】
作成が完了していない場合（Ｓ１２２５−Ｎ）、第２データ送信装置は、残りのグループに対する送信ファイルリストを作成して送信するステップＳ１２１５及びステップＳ１２２０を繰り返し行う。
【０１４１】
第２データ受信装置は、ステップＳ１２２０において受信された送信ファイルリストと、ＦＢを介して既に受信された複数のファイルとを比較して、既に受信された複数のファイルのうち、レジュームダウンロードするファイルを決定し、決定されたファイルのインデックスとオフセット（決定されたファイルのうち、レジュームダウンロードするデータのスタートアドレスを表す）を含むレジュームダウンロードリストを作成する（Ｓ１２３０）。ステップＳ１２３０を、図１３を参照してさらに詳細に説明する。
【０１４２】
第２データ受信装置は、作成されたレジュームダウンロードリストを第２データ送信装置に送信する（Ｓ１２３５）。
【０１４３】
第２データ送信装置は、受信されたレジュームダウンロードリストを参照して、パッケージ送信するファイルのデータを少なくとも一つ以上のＦＢに記録する（Ｓ１２４０）。ステップＳ１２４０において、第２データ送信装置は、図９及び図１０を参照して説明したように、ＭＢ単位でデータをＦＢに記録する。
【０１４４】
第２データ送信装置は、ステップＳ１２４０においてデータが記録された少なくとも一つ以上のＦＢを第２データ受信装置に送信する（Ｓ１２４５）。ステップＳ１２４０及びステップＳ１２４５において、第２データ送信装置は、レジュームダウンロードリストに含まれたインデックスに相当するファイルを第３格納媒体から確認し、該確認されたファイルのうち、オフセットに対応する位置（又はその次の位置）からのデータを、第２データ受信装置にＦＢを利用してパッケージ方式で初期送信又は再送信する。例えば、第２データ送信装置は、レジュームダウンロードリストのオフセットが「０」である場合に、ファイルを始めから送信し、オフセットが「０」でないｍｂｙｔｅｓ（ｍは、正数）である場合に、ファイルのうち、ｍｂｙｔｅｓに対応する位置からのデータを送信する。
【０１４５】
第２データ受信装置は、受信された少なくとも一つ以上のＦＢのヘッダ情報とデータとを空いている少なくとも一つ以上のＦＢに記録する（Ｓ１２５０）。ステップＳ１２５０において、第２データ受信装置は、受信されたＦＢが複数のＭＢを含む場合に、ＦＢを複数のＭＢに区分して同様にデータを記録できる。
【０１４６】
第２データ受信装置は、ヘッダ情報とデータが記録された少なくとも一つのＦＢをアクティブブロックプールに順次に保管する（Ｓ１２５５）。
【０１４７】
第２データ受信装置は、アクティブブロックプールに保管されたＦＢのうち、ＭＰに記録されたファイル（以下では、「第１ファイル」とする）のメタファイルが存在しているかどうかを確認する（Ｓ１２６０）。
【０１４８】
第１ファイルのメタファイルが第２データ受信装置に存在しないと（Ｓ１２６０−Ｎ）、第２データ受信装置は、第１ファイルのメタファイルを作成する（Ｓ１２６５）。ステップＳ１２６５において、第２データ受信装置は、図７のような形態のメタファイルを作成することができる。
【０１４９】
第２データ受信装置は、ＦＢのＭＰに記録された第１ファイルのデータを第４格納媒体に格納する（Ｓ１２７０）。
【０１５０】
第１ファイルが複数のＦＢを介して受信される場合、第２データ受信装置は、ＦＢが受信されるごとにメタファイルをアップデートする（Ｓ１２７５）。
【０１５１】
第２データ受信装置は、ＦＢに記録されたデータがすべて第４格納媒体に記録されていると、アクティブブロックプールに他のＦＢがあるかどうかを確認する（Ｓ１２８０）。
【０１５２】
アクティブブロックプールに他のＦＢがあると（Ｓ１２８０−Ｙ）、第２データ受信装置は、ステップＳ１２６０に進む。
【０１５３】
反面、アクティブブロックプールに他のＦＢがないと（Ｓ１２８０−Ｎ）、第２データ受信装置は、ファイルの格納が完了したかどうかを確認し、パッケージファイルの受信又はレジュームダウンロード受信が完了したことを報告する受信完了メッセージを第２データ送信装置に送信する（Ｓ１２８５）。
【０１５４】
上述したデータ並列送受信方法において、第２データ送信装置は、第２データ受信装置がレジュームダウンロードリストを作成する間に、ステップＳ１２１５〜ステップＳ１２２５を並列実行することができ、ステップＳ１２１５〜ステップＳ１２３５が行われる間にステップＳ１２４０〜ステップＳ１２４５を並列実行してもよい。
【０１５５】
図１３は、図１２のステップＳ１２３０をさらに詳細に示すフローチャートである。
【０１５６】
図１３に示すように、第２データ受信装置は、第２データ送信装置から送信ファイルリストを受信する（Ｓ１３００）。
【０１５７】
第２データ受信装置は、受信された送信ファイルリストに含まれたファイルのうち、現在処理する第１ファイルが第４格納媒体に格納されているかどうかを確認する（Ｓ１３１０）。第２データ受信装置は、送信ファイルリストに記録された第１ファイルのファイル名又はインデックスと第４格納媒体に格納されたファイル名又はインデックスを比較して、第１ファイルの格納有無を確認することができる。
【０１５８】
第１ファイルが第４格納媒体に格納されていると（Ｓ１３１０−Ｙ）、第２データ受信装置は、送信ファイルリストに記録された第１ファイルのサイズと第４格納媒体に格納された第１ファイルのサイズとが同一であるかどうか、第１ファイルのメタファイルがメモリに格納されていないかどうかを確認する（Ｓ１３２０）。
【０１５９】
互いにサイズが同一であり、かつ第１ファイルのメタファイルが格納されていないと（Ｓ１３２０−Ｙ）、第２データ受信装置は、第１ファイルの送信が完了したと判定し、レジュームダウンロードをしない（Ｓ１３３０）。
【０１６０】
これに対し、互いにサイズが同一でないか、又はメタファイルが格納されていると（Ｓ１３２０−Ｎ）、第２データ受信装置は、メタファイルの第１番目のＭＢ（１ＳＴ ＭＢ）のサイズが「０」であるかどうかを確認する（Ｓ１３４０）。
【０１６１】
メタファイルの第１番目のＭＢのサイズが０でないと（Ｓ１３４０−Ｎ）、第２データ受信装置は、第１ファイルを初めて送信したＦＢ（又はＭＢ）が受信されているのでｉ＝２（ｉは、第１ファイルをｉ番目に送信したＭＢである）に設定する（Ｓ１３５０）。
【０１６２】
そして、第２データ受信装置は、第２番目のＭＢ（ｉ＝２）のフラグであるｆｉが「０」であるかどうかを確認する（Ｓ１３６０）。
【０１６３】
ステップＳ１３６０にてｆｉ＝０（ｉ＝２）であると（Ｓ１３６０−Ｙ）、第２データ受信装置は、第１ファイルを送信した第２番目のＦＢが受信されていないと判定し、レジュームダウンロードするアドレスであるオフセットを算出する（Ｓ１３７０）。ステップＳ１３７０において、第２データ受信装置は、「オフセット＝ｋバイト＋（ｉ−２）＊ｎバイト」を利用して、第１ファイルのオフセットを算出する。算出されたオフセットは、第１ファイルのメタファイルに記録された受信された累積ファイルサイズと同じであってもよい。
【０１６４】
ステップＳ１３６０にてｆｉ＝０（ｉ＝２）でないと（Ｓ１３６０−Ｎ）、第２データ受信装置は、ｉに１を加え（Ｓ１３９０）、再度ステップＳ１３６０を実行する。第２データ受信装置は、最後のｉまでこの処理を繰り返す。
【０１６５】
第２データ受信装置は、第１ファイルのインデックスとステップＳ１３７０にて算出されたオフセットをレジュームダウンロードリストに記録する（Ｓ１３８０）。
【０１６６】
図１３は、一つの送信ファイルリストに含まれた複数のファイルのうち、第１ファイルのオフセットを求める過程に対して示すものであって、第２データ受信装置は、送信ファイルリストに含まれたすべてのファイルに対してステップＳ１３２０〜ステップＳ１３８０を繰り返し行うことができる。これにより、第２データ受信装置は、一つの送信ファイルリストに対する応答であるレジュームダウンロードリストを最終的に作成して、第２データ送信装置に送信する（Ｓ１２３５）。
【０１６７】
以上、本発明は、限定された実施形態と図面により説明されたが、本発明は、上記の実施形態に限定されるものではなく、本発明が属する分野における通常の知識を有した者であれば、このような記載から多様な修正及び変形が可能である。したがって、本発明の範囲は、説明された実施形態に限定されてはならず、後述する特許請求の範囲だけでなく、この特許請求の範囲と均等なものによって定められなけばならない。
【符号の説明】
【０１６８】
１００ 第１データ送信装置
１１０ 第１格納媒体
１２０ 第１インアクティブブロックプール
１３０ 第１ディスクリーダ
１４０ 第１アクティブブロックプール
１５０ 第１通信部
１６０ 第１制御部
２００ 第１データ受信装置
２１０ 第２通信部
２２０ 第２インアクティブブロックプール
２３０ 第２アクティブブロックプール
２４０ 第１ディスクライター
２５０ 第２格納媒体
２６０ 第２制御部
【特許請求の範囲】
【請求項１】
複数のファイルを送信するデータ送信装置であって、
ファイルブロックを一つ又は複数のマイクロブロックに区分し、前記一つ又は複数のマイクロブロックの各々のサイズに対応するデータを前記複数のファイルから読み出して、前記一つ又は複数のマイクロブロックに順次に記録するディスクリーダと、
前記ファイルブロックに含まれる一つ又は複数のマイクロブロックにデータが記録されると、前記ファイルブロックをデータ受信装置に送信する通信部と、を備え、
前記一つ又は複数のマイクロブロックは、各々マイクロブロックヘッダ及びマイクロブロックペイロードに区分され、
前記ディスクリーダは、前記マイクロブロックヘッダに、前記マイクロブロックペイロードに記録されるデータのアドレスを表すオフセットを記録し、前記マイクロブロックペイロードに、前記データを記録することを特徴とするデータ送信装置。
【請求項２】
前記ディスクリーダは、前記複数のファイルのうち、第１ファイルのデータを前記複数のマイクロブロックに記録し、前記ファイルブロックに前記第１ファイルのデータを記録したマイクロブロック以外の空き領域があると、追加のマイクロブロックを生成し、前記複数のファイルのうち、第２ファイルのデータを前記追加のマイクロブロックに記録することを特徴とする請求項１に記載のデータ送信装置。
【請求項３】
前記ディスクリーダは、前記ファイルブロック全体に、前記複数のファイルのうちの第１ファイルのデータが記録される場合に、前記ファイルブロックを一つのマイクロブロックヘッダと一つのマイクロブロックペイロードに区分することを特徴とする請求項１に記載のデータ送信装置。
【請求項４】
前記データ受信装置に送信するファイルの全てをもとに送信ファイルリストを生成し、前記送信ファイルリストを前記データ受信装置に送信するリスト管理部、をさらに備え、
前記送信ファイルリストは、ファイルのインデックス、ファイル名及びファイルサイズに対する情報を含むことを特徴とする請求項１に記載のデータ送信装置。
【請求項５】
前記通信部は、前記送信ファイルリストが前記データ受信装置に順次に送信される間に、前記データが記録された複数のマイクロブロックを含む前記ファイルブロックを並列ストリームを利用して送信することを特徴とする請求項４に記載のデータ送信装置。
【請求項６】
前記ディスクリーダは、前記複数のファイルのうち、前記データ受信装置から受信したレジュームダウンロードリストに含まれたインデックスに対応するファイルを確認し、前記確認されたファイルのうち、前記レジュームダウンロードリストに含まれたオフセットに対応する位置からのデータを前記ファイルブロックに記録してレジュームダウンロード送信を行い、
前記レジュームダウンロードリストは、レジュームダウンロードすることと決定されたファイルのインデックスと、前記決定されたファイルにおいて、レジュームダウンロードするデータのスタートアドレスを表すオフセットとを含むことを特徴とする請求項４に記載のデータ送信装置。
【請求項７】
データ送信装置から送信されるファイルブロックを受信する通信部と、
前記受信されたファイルブロックが一つ又は複数のマイクロブロックを含む場合に、マイクロブロック単位でデータを読み出して格納媒体に記録するディスクライターと、を備え、
前記ファイルブロックは、データ送信単位であって、
前記マイクロブロックは、少なくとも一つ以上のファイルのデータが記録される単位であって、
前記一つ又は複数のマイクロブロックの各々は、マイクロブロックヘッダ及びマイクロブロックペイロードを含み、 前記ディスクライターは、前記マイクロブロックヘッダに記録され、前記マイクロブロックペイロードに記録されたデータのアドレスを表すオフセットを参照して、前記マイクロブロックペイロードに記録されたデータを前記格納媒体に記録することを特徴とするデータ受信装置。
【請求項８】
前記ディスクライターは、前記マイクロブロックヘッダに記録されたファイルパス（ｆｉｌｅｐａｔｈ）を参照して、前記ファイルブロックを介して受信された前記少なくとも一つ以上のファイルを前記格納媒体に各々記録することを特徴とする請求項７に記載のデータ受信装置。
【請求項９】
前記通信部が前記データ送信装置から受信した送信ファイルリストを利用して、既受信の複数のファイルのうち、レジュームダウンロードするファイルを決定し、前記決定されたファイルのインデックスと、前記決定されたファイルのうち、レジュームダウンロードするデータのスタートアドレスを表すオフセットとを含むレジュームダウンロードリストを作成して、前記データ送信装置に送信するリスト確認部をさらに備え、
前記送信ファイルリストは、送信対象となるファイルのインデックス、ファイル名及びファイルサイズに対する情報を含むことを特徴とする請求項７に記載のデータ受信装置。
【請求項１０】
前記リスト確認部は、前記受信された送信ファイルリストに含まれたファイル名に対応するファイルが前記既受信の複数のファイルのうちの一つの第１ファイルであり、前記第１ファイルのメタファイルが存在すると、前記第１ファイルを前記レジュームダウンロードするファイルとして決定し、
前記メタファイルは、前記第１ファイルの送信完了有無に関する情報を表すフラグを含むことを特徴とする請求項９に記載のデータ受信装置。
【請求項１１】
前記リスト確認部は、前記第１ファイルが前記ファイルブロックを介して受信された場合、前記メタファイルに、前記第１ファイルを最初に送信した第１番目の前記ファイルブロックの送信量が０に記録されていると、前記第１ファイルのオフセットを０とするレジュームダウンロードリストを作成し、
前記データ送信装置は、前記第１ファイルを始めから再度送信することを特徴とする請求項１０に記載のデータ受信装置。
【請求項１２】
前記リスト確認部は、前記第１ファイルが前記ファイルブロックを介して受信された場合に、前記メタファイルに、前記第１ファイルを最初に送信した第１番目の前記ファイルブロック（ｉ＝１）の送信量がｋバイト（ｋは、正数）として記録されており、前記第１ファイルをｉ（ｉ＝２，３，．．．，ｍ）番目に送信したファイルブロックのフラグが０であると、前記第１ファイルのオフセットをｋバイト＋（ｉ−２）＊ｎバイトにするレジュームダウンロードリストを作成し、
前記ｎバイトは、前記ファイルブロックの最大送信サイズであることを特徴とする請求項１０に記載のデータ受信装置。
【請求項１３】
前記ディスクライターは、前記ファイルブロックを介して受信された第１ファイルのメタファイルを作成し、
前記第１ファイルのメタファイルは、前記ファイルブロックの最大送信サイズ、前記第１ファイルの受信された累積ファイルサイズ、前記第１ファイルを最初に送信した第１番目の前記ファイルブロックのサイズ、及び前記第１ファイルを引き続いて送信した次のファイルブロックの受信有無を表すフラグを含むことを特徴とする請求項１０に記載のデータ受信装置。
【請求項１４】
複数のファイルを送信するデータ送信方法であって、
ファイルブロックを一つ又は複数のマイクロブロックに区分し、前記一つ又は複数のマイクロブロックの各々のサイズに対応するデータを前記複数のファイルから読み出して、前記一つ又は複数のマイクロブロックに順次に記録するステップと、
前記ファイルブロックに含まれる一つ又は複数のマイクロブロックにデータが記録されると、前記ファイルブロックをデータ受信装置に送信するステップと、を含み、
前記一つ又は複数のマイクロブロックは、各々マイクロブロックヘッダ及びマイクロブロックペイロードに区分され、
前記記録するステップは、前記マイクロブロックヘッダに、前記マイクロブロックペイロードに記録されるデータのアドレスを表すオフセットを記録し、前記マイクロブロックペイロードに、前記データを記録することを特徴とするデータ送信方法。
【請求項１５】
前記記録するステップは、前記複数のファイルのうち、第１ファイルのデータを前記複数のマイクロブロックに記録し、前記ファイルブロックに前記第１ファイルのデータを記録したマイクロブロック以外の空き領域があると、追加のマイクロブロックを生成し、前記複数のファイルのうち、第２ファイルのデータを前記追加のマイクロブロックに記録することを特徴とする請求項１４に記載のデータ送信方法。
【請求項１６】
前記記録するステップは、前記ファイルブロック全体に、前記複数のファイルのうちの第１ファイルのデータが記録される場合に、前記ファイルブロックを一つのマイクロブロックヘッダと一つのマイクロブロックペイロードとに区分することを特徴とする請求項１４に記載のデータ送信方法。
【請求項１７】
前記データ受信装置に送信するファイルの全てをもとに送信ファイルリストを生成するステップと、
前記生成された送信ファイルリストを前記データ受信装置に送信するステップと、をさらに含み、
前記送信ファイルリストは、ファイルのインデックス、ファイル名及びファイルサイズに対する情報を含むことを特徴とする請求項１４に記載のデータ送信方法。
【請求項１８】
レジュームダウンロードリストを前記データ受信装置から受信するステップと、
前記複数のファイルのうち、前記受信されたレジュームダウンロードリストに含まれたインデックスに対応するファイルを確認するステップと、
前記確認されたファイルのうち、前記レジュームダウンロードリストに含まれたオフセットに対応する位置からのデータを前記ファイルブロックに記録してレジュームダウンロード送信を開始するステップと、をさらに含み、
前記レジュームダウンロードリストは、レジュームダウンロードすることと決定されたファイルのインデックスと、前記決定されたファイルにおいて、レジュームダウンロードするデータのスタートアドレスを表すオフセットとを含むことを特徴とする請求項１７に記載のデータ送信方法。
【請求項１９】
データ送信装置から送信されるファイルブロックを受信するステップと、
前記受信されたファイルブロックが一つ又は複数のマイクロブロックを含む場合に、マイクロブロック単位でデータを読み出して格納媒体に記録するステップと、を含み、
前記ファイルブロックは、データ送信単位であって、
前記マイクロブロックは、少なくとも一つ以上のファイルのデータが記録される単位であって、
前記一つ又は複数のマイクロブロックの各々は、マイクロブロックヘッダ及びマイクロブロックペイロードを含み、
前記記録するステップは、前記マイクロブロックヘッダに記録され、前記マイクロブロックペイロードに記録されたデータのアドレスを表すオフセットを参照して、前記マイクロブロックペイロードに記録されたデータを前記格納媒体に記録し、前記マイクロブロックヘッダに記録されたファイルパス（ｆｉｌｅｐａｔｈ）を参照して、前記ファイルブロックを介して受信された前記少なくとも一つ以上のファイルを前記格納媒体に各々記録することを特徴とするデータ受信方法。
【請求項２０】
送信ファイルリストを前記データ送信装置から受信するステップと、
前記受信された送信ファイルリストを利用して、既受信の複数のファイルのうち、レジュームダウンロードするファイルを決定するステップと、
前記決定されたファイルのインデックスと、前記決定されたファイルのうち、レジュームダウンロードするデータのスタートアドレスを表すオフセットとを含むレジュームダウンロードリストを作成するステップと、
前記作成されたレジュームダウンロードリストを前記データ送信装置に送信するステップと、をさらに含み、
前記送信ファイルリストは、送信対象となるファイルのインデックス、ファイル名及び全体ファイルサイズに対する情報を含むことを特徴とする請求項１９に記載のデータ受信方法。
【請求項２１】
前記決定するステップは、前記受信された送信ファイルリストに含まれたファイル名に対応するファイルが前記既受信の複数のファイルのうちの何れか一つである第１ファイルであり、前記第１ファイルのメタファイルが存在すると、前記第１ファイルを前記レジュームダウンロードするファイルとして決定し、
前記メタファイルは、前記第１ファイルの送信完了有無に関する情報を表すフラグを含むことを特徴とする請求項２０に記載のデータ受信方法。
【請求項２２】
前記レジュームダウンロードリストを作成するステップは、前記第１ファイルが前記ファイルブロックを介して受信された場合、前記メタファイルに、前記第１ファイルを最初に送信した第１番目の前記ファイルブロックの送信量が０に記録されていると、前記第１ファイルのオフセットを０とするレジュームダウンロードリストを作成し、
前記データ送信装置は、前記第１ファイルを始めから再送信することを特徴とする請求項２１に記載のデータ受信方法。
【請求項２３】
前記レジュームダウンロードリストを作成するステップは、前記第１ファイルが前記ファイルブロックを介して受信された場合に、前記メタファイルに、前記第１ファイルを最初に送信した第１番目の前記ファイルブロック（ｉ＝１）の送信量がｋバイト（ｋは、正数）として記録されており、前記第１ファイルをｉ（ｉ＝２，３，．．．，ｍ）番目に送信したファイルブロックのフラグが０であると、前記第１ファイルのオフセットをｋバイト＋（ｉ−２）＊ｎバイトにするレジュームダウンロードリストを作成し、
前記ｎバイトは、前記ファイルブロックの最大送信サイズであり、
前記データ送信装置は、前記第１ファイルのオフセットに対応する位置からのデータを再送信することを特徴とする請求項２１に記載のデータ受信方法。
【請求項２４】
前記ファイルブロックを介して受信された第１ファイルのメタファイルを作成するステップをさらに含み、
前記第１ファイルのメタファイルは、前記ファイルブロックの最大送信サイズ、前記第１ファイルの受信された累積ファイルサイズ、前記第１ファイルを最初に送信した第１番目の前記ファイルブロックのサイズ、及び前記第１ファイルを引き続いて送信した次のファイルブロックの受信有無を表すフラグを含むことを特徴とする請求項２１に記載のデータ受信方法。
【請求項１】
複数のファイルを送信するデータ送信装置であって、
ファイルブロックを一つ又は複数のマイクロブロックに区分し、前記一つ又は複数のマイクロブロックの各々のサイズに対応するデータを前記複数のファイルから読み出して、前記一つ又は複数のマイクロブロックに順次に記録するディスクリーダと、
前記ファイルブロックに含まれる一つ又は複数のマイクロブロックにデータが記録されると、前記ファイルブロックをデータ受信装置に送信する通信部と、を備え、
前記一つ又は複数のマイクロブロックは、各々マイクロブロックヘッダ及びマイクロブロックペイロードに区分され、
前記ディスクリーダは、前記マイクロブロックヘッダに、前記マイクロブロックペイロードに記録されるデータのアドレスを表すオフセットを記録し、前記マイクロブロックペイロードに、前記データを記録することを特徴とするデータ送信装置。
【請求項２】
前記ディスクリーダは、前記複数のファイルのうち、第１ファイルのデータを前記複数のマイクロブロックに記録し、前記ファイルブロックに前記第１ファイルのデータを記録したマイクロブロック以外の空き領域があると、追加のマイクロブロックを生成し、前記複数のファイルのうち、第２ファイルのデータを前記追加のマイクロブロックに記録することを特徴とする請求項１に記載のデータ送信装置。
【請求項３】
前記ディスクリーダは、前記ファイルブロック全体に、前記複数のファイルのうちの第１ファイルのデータが記録される場合に、前記ファイルブロックを一つのマイクロブロックヘッダと一つのマイクロブロックペイロードに区分することを特徴とする請求項１に記載のデータ送信装置。
【請求項４】
前記データ受信装置に送信するファイルの全てをもとに送信ファイルリストを生成し、前記送信ファイルリストを前記データ受信装置に送信するリスト管理部、をさらに備え、
前記送信ファイルリストは、ファイルのインデックス、ファイル名及びファイルサイズに対する情報を含むことを特徴とする請求項１に記載のデータ送信装置。
【請求項５】
前記通信部は、前記送信ファイルリストが前記データ受信装置に順次に送信される間に、前記データが記録された複数のマイクロブロックを含む前記ファイルブロックを並列ストリームを利用して送信することを特徴とする請求項４に記載のデータ送信装置。
【請求項６】
前記ディスクリーダは、前記複数のファイルのうち、前記データ受信装置から受信したレジュームダウンロードリストに含まれたインデックスに対応するファイルを確認し、前記確認されたファイルのうち、前記レジュームダウンロードリストに含まれたオフセットに対応する位置からのデータを前記ファイルブロックに記録してレジュームダウンロード送信を行い、
前記レジュームダウンロードリストは、レジュームダウンロードすることと決定されたファイルのインデックスと、前記決定されたファイルにおいて、レジュームダウンロードするデータのスタートアドレスを表すオフセットとを含むことを特徴とする請求項４に記載のデータ送信装置。
【請求項７】
データ送信装置から送信されるファイルブロックを受信する通信部と、
前記受信されたファイルブロックが一つ又は複数のマイクロブロックを含む場合に、マイクロブロック単位でデータを読み出して格納媒体に記録するディスクライターと、を備え、
前記ファイルブロックは、データ送信単位であって、
前記マイクロブロックは、少なくとも一つ以上のファイルのデータが記録される単位であって、
前記一つ又は複数のマイクロブロックの各々は、マイクロブロックヘッダ及びマイクロブロックペイロードを含み、 前記ディスクライターは、前記マイクロブロックヘッダに記録され、前記マイクロブロックペイロードに記録されたデータのアドレスを表すオフセットを参照して、前記マイクロブロックペイロードに記録されたデータを前記格納媒体に記録することを特徴とするデータ受信装置。
【請求項８】
前記ディスクライターは、前記マイクロブロックヘッダに記録されたファイルパス（ｆｉｌｅｐａｔｈ）を参照して、前記ファイルブロックを介して受信された前記少なくとも一つ以上のファイルを前記格納媒体に各々記録することを特徴とする請求項７に記載のデータ受信装置。
【請求項９】
前記通信部が前記データ送信装置から受信した送信ファイルリストを利用して、既受信の複数のファイルのうち、レジュームダウンロードするファイルを決定し、前記決定されたファイルのインデックスと、前記決定されたファイルのうち、レジュームダウンロードするデータのスタートアドレスを表すオフセットとを含むレジュームダウンロードリストを作成して、前記データ送信装置に送信するリスト確認部をさらに備え、
前記送信ファイルリストは、送信対象となるファイルのインデックス、ファイル名及びファイルサイズに対する情報を含むことを特徴とする請求項７に記載のデータ受信装置。
【請求項１０】
前記リスト確認部は、前記受信された送信ファイルリストに含まれたファイル名に対応するファイルが前記既受信の複数のファイルのうちの一つの第１ファイルであり、前記第１ファイルのメタファイルが存在すると、前記第１ファイルを前記レジュームダウンロードするファイルとして決定し、
前記メタファイルは、前記第１ファイルの送信完了有無に関する情報を表すフラグを含むことを特徴とする請求項９に記載のデータ受信装置。
【請求項１１】
前記リスト確認部は、前記第１ファイルが前記ファイルブロックを介して受信された場合、前記メタファイルに、前記第１ファイルを最初に送信した第１番目の前記ファイルブロックの送信量が０に記録されていると、前記第１ファイルのオフセットを０とするレジュームダウンロードリストを作成し、
前記データ送信装置は、前記第１ファイルを始めから再度送信することを特徴とする請求項１０に記載のデータ受信装置。
【請求項１２】
前記リスト確認部は、前記第１ファイルが前記ファイルブロックを介して受信された場合に、前記メタファイルに、前記第１ファイルを最初に送信した第１番目の前記ファイルブロック（ｉ＝１）の送信量がｋバイト（ｋは、正数）として記録されており、前記第１ファイルをｉ（ｉ＝２，３，．．．，ｍ）番目に送信したファイルブロックのフラグが０であると、前記第１ファイルのオフセットをｋバイト＋（ｉ−２）＊ｎバイトにするレジュームダウンロードリストを作成し、
前記ｎバイトは、前記ファイルブロックの最大送信サイズであることを特徴とする請求項１０に記載のデータ受信装置。
【請求項１３】
前記ディスクライターは、前記ファイルブロックを介して受信された第１ファイルのメタファイルを作成し、
前記第１ファイルのメタファイルは、前記ファイルブロックの最大送信サイズ、前記第１ファイルの受信された累積ファイルサイズ、前記第１ファイルを最初に送信した第１番目の前記ファイルブロックのサイズ、及び前記第１ファイルを引き続いて送信した次のファイルブロックの受信有無を表すフラグを含むことを特徴とする請求項１０に記載のデータ受信装置。
【請求項１４】
複数のファイルを送信するデータ送信方法であって、
ファイルブロックを一つ又は複数のマイクロブロックに区分し、前記一つ又は複数のマイクロブロックの各々のサイズに対応するデータを前記複数のファイルから読み出して、前記一つ又は複数のマイクロブロックに順次に記録するステップと、
前記ファイルブロックに含まれる一つ又は複数のマイクロブロックにデータが記録されると、前記ファイルブロックをデータ受信装置に送信するステップと、を含み、
前記一つ又は複数のマイクロブロックは、各々マイクロブロックヘッダ及びマイクロブロックペイロードに区分され、
前記記録するステップは、前記マイクロブロックヘッダに、前記マイクロブロックペイロードに記録されるデータのアドレスを表すオフセットを記録し、前記マイクロブロックペイロードに、前記データを記録することを特徴とするデータ送信方法。
【請求項１５】
前記記録するステップは、前記複数のファイルのうち、第１ファイルのデータを前記複数のマイクロブロックに記録し、前記ファイルブロックに前記第１ファイルのデータを記録したマイクロブロック以外の空き領域があると、追加のマイクロブロックを生成し、前記複数のファイルのうち、第２ファイルのデータを前記追加のマイクロブロックに記録することを特徴とする請求項１４に記載のデータ送信方法。
【請求項１６】
前記記録するステップは、前記ファイルブロック全体に、前記複数のファイルのうちの第１ファイルのデータが記録される場合に、前記ファイルブロックを一つのマイクロブロックヘッダと一つのマイクロブロックペイロードとに区分することを特徴とする請求項１４に記載のデータ送信方法。
【請求項１７】
前記データ受信装置に送信するファイルの全てをもとに送信ファイルリストを生成するステップと、
前記生成された送信ファイルリストを前記データ受信装置に送信するステップと、をさらに含み、
前記送信ファイルリストは、ファイルのインデックス、ファイル名及びファイルサイズに対する情報を含むことを特徴とする請求項１４に記載のデータ送信方法。
【請求項１８】
レジュームダウンロードリストを前記データ受信装置から受信するステップと、
前記複数のファイルのうち、前記受信されたレジュームダウンロードリストに含まれたインデックスに対応するファイルを確認するステップと、
前記確認されたファイルのうち、前記レジュームダウンロードリストに含まれたオフセットに対応する位置からのデータを前記ファイルブロックに記録してレジュームダウンロード送信を開始するステップと、をさらに含み、
前記レジュームダウンロードリストは、レジュームダウンロードすることと決定されたファイルのインデックスと、前記決定されたファイルにおいて、レジュームダウンロードするデータのスタートアドレスを表すオフセットとを含むことを特徴とする請求項１７に記載のデータ送信方法。
【請求項１９】
データ送信装置から送信されるファイルブロックを受信するステップと、
前記受信されたファイルブロックが一つ又は複数のマイクロブロックを含む場合に、マイクロブロック単位でデータを読み出して格納媒体に記録するステップと、を含み、
前記ファイルブロックは、データ送信単位であって、
前記マイクロブロックは、少なくとも一つ以上のファイルのデータが記録される単位であって、
前記一つ又は複数のマイクロブロックの各々は、マイクロブロックヘッダ及びマイクロブロックペイロードを含み、
前記記録するステップは、前記マイクロブロックヘッダに記録され、前記マイクロブロックペイロードに記録されたデータのアドレスを表すオフセットを参照して、前記マイクロブロックペイロードに記録されたデータを前記格納媒体に記録し、前記マイクロブロックヘッダに記録されたファイルパス（ｆｉｌｅｐａｔｈ）を参照して、前記ファイルブロックを介して受信された前記少なくとも一つ以上のファイルを前記格納媒体に各々記録することを特徴とするデータ受信方法。
【請求項２０】
送信ファイルリストを前記データ送信装置から受信するステップと、
前記受信された送信ファイルリストを利用して、既受信の複数のファイルのうち、レジュームダウンロードするファイルを決定するステップと、
前記決定されたファイルのインデックスと、前記決定されたファイルのうち、レジュームダウンロードするデータのスタートアドレスを表すオフセットとを含むレジュームダウンロードリストを作成するステップと、
前記作成されたレジュームダウンロードリストを前記データ送信装置に送信するステップと、をさらに含み、
前記送信ファイルリストは、送信対象となるファイルのインデックス、ファイル名及び全体ファイルサイズに対する情報を含むことを特徴とする請求項１９に記載のデータ受信方法。
【請求項２１】
前記決定するステップは、前記受信された送信ファイルリストに含まれたファイル名に対応するファイルが前記既受信の複数のファイルのうちの何れか一つである第１ファイルであり、前記第１ファイルのメタファイルが存在すると、前記第１ファイルを前記レジュームダウンロードするファイルとして決定し、
前記メタファイルは、前記第１ファイルの送信完了有無に関する情報を表すフラグを含むことを特徴とする請求項２０に記載のデータ受信方法。
【請求項２２】
前記レジュームダウンロードリストを作成するステップは、前記第１ファイルが前記ファイルブロックを介して受信された場合、前記メタファイルに、前記第１ファイルを最初に送信した第１番目の前記ファイルブロックの送信量が０に記録されていると、前記第１ファイルのオフセットを０とするレジュームダウンロードリストを作成し、
前記データ送信装置は、前記第１ファイルを始めから再送信することを特徴とする請求項２１に記載のデータ受信方法。
【請求項２３】
前記レジュームダウンロードリストを作成するステップは、前記第１ファイルが前記ファイルブロックを介して受信された場合に、前記メタファイルに、前記第１ファイルを最初に送信した第１番目の前記ファイルブロック（ｉ＝１）の送信量がｋバイト（ｋは、正数）として記録されており、前記第１ファイルをｉ（ｉ＝２，３，．．．，ｍ）番目に送信したファイルブロックのフラグが０であると、前記第１ファイルのオフセットをｋバイト＋（ｉ−２）＊ｎバイトにするレジュームダウンロードリストを作成し、
前記ｎバイトは、前記ファイルブロックの最大送信サイズであり、
前記データ送信装置は、前記第１ファイルのオフセットに対応する位置からのデータを再送信することを特徴とする請求項２１に記載のデータ受信方法。
【請求項２４】
前記ファイルブロックを介して受信された第１ファイルのメタファイルを作成するステップをさらに含み、
前記第１ファイルのメタファイルは、前記ファイルブロックの最大送信サイズ、前記第１ファイルの受信された累積ファイルサイズ、前記第１ファイルを最初に送信した第１番目の前記ファイルブロックのサイズ、及び前記第１ファイルを引き続いて送信した次のファイルブロックの受信有無を表すフラグを含むことを特徴とする請求項２１に記載のデータ受信方法。
【図１】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１３−９７８０４（Ｐ２０１３−９７８０４Ａ）
【公開日】平成２５年５月２０日（２０１３．５．２０）
【国際特許分類】
【出願番号】特願２０１２−２３７７５３（Ｐ２０１２−２３７７５３）
【出願日】平成２４年１０月２９日（２０１２．１０．２９）
【出願人】（５１０２９４１９５）サムソン エスディーエス カンパニー リミテッド (33)
【Ｆターム（参考）】
【公開日】平成２５年５月２０日（２０１３．５．２０）
【国際特許分類】
【出願日】平成２４年１０月２９日（２０１２．１０．２９）
【出願人】（５１０２９４１９５）サムソン エスディーエス カンパニー リミテッド (33)
【Ｆターム（参考）】
[ Back to top ]