ブロック単位でデータを管理するストレージ装置に記憶されているファイルのデータをネットワークに転送するデータ転送装置であって、外部のホストCPUからの要求を受けて、第一ファイルのデータが前記ストレージ装置上のどの位置に記憶されているかを示す第一マップ情報を含むメタデータの読み出しコマンドを生成し、前記読み出しコマンドを前記ストレージ装置に送る第一発行部と、前記ストレージ装置から返される前記メタデータを取得した前記外部のホストCPUから、前記第一ファイルのデータの読み出し指示を受け、前記第一ファイルのデータを格納したブロックの読み出しコマンドを生成し、前記読み出しコマンドを前記ストレージ装置に送る第二発行部と、前記読み出しコマンドに応じて前記ストレージ装置から読み出されるブロックデータを受け取り、前記外部のホストCPUから前記第一マップ情報を受け取り、前記第一マップ情報に基づき、前記ブロックデータから前記第一ファイルのデータを抽出する送信データ抽出部と、前記送信データ抽出部により抽出された前記第一ファイルのデータを、前記ネットワークに送信する通信処理部と、を備えたデータ転送装置。PCIPeripheralComponentInterconnect-Expressカードとして構成されたことを特徴とする請求項1に記載のデータ転送装置。ブロック単位でデータを管理するストレージ装置に記憶されているファイルのデータをネットワークに送信するデータ送信システムであって、前記ストレージ装置に格納された第一ファイルのデータの送信指示を生成する第一アプリ処理部と、前記送信指示に基づき、前記第一ファイルのデータが前記ストレージ装置上のどの位置に記憶されているかを示す第一マップ情報を含むメタデータの読み出し指示を生成するメタデータ読み出し指示部と、前記メタデータの読み出し指示に基づき、前記メタデータの読み出しコマンドを生成し、前記ストレージ装置に送る第一発行部と、前記ストレージ装置から返される前記メタデータに含まれる第一マップ情報に基づき、前記第一ファイルのデータの読み出し指示を生成する送信データ読み出し指示部と、前記第一ファイルのデータの読み出し指示に基づき、前記第一ファイルのデータを格納したブロックの読み出しコマンドを生成し、前記読み出しコマンドを前記ストレージ装置に送る第二発行部と、前記読み出しコマンドに応じて前記ストレージ装置から読み出されるブロックデータを受け取り、前記第一マップ情報に基づき、前記ブロックデータから前記第一ファイルのデータを抽出する送信データ抽出部と、前記送信データ抽出部により抽出された前記第一ファイルデータを、前記ネットワークに送信する通信処理部と、を備えたデータ送信システム。第二アプリ処理部と、アプリデータ読み出し指示部と、アプリデータ抽出部と、をさらに備え、前記第二アプリ処理部は、第二ファイルのデータの取得指示を生成し、前記第一発行部は、前記取得指示に基づき、前記第二ファイルのデータが前記ストレージ装置上のどの位置に記憶されているかを示す第二マップ情報を含むメタデータの読み出しコマンドを生成して、前記ストレージ装置に送り、前記アプリデータ読み出し指示部は、前記ストレージ装置から返される前記メタデータに含まれる第二マップ情報に基づき、前記第二ファイルのデータの読み出し指示を生成し、前記第二発行部は、前記第二ファイルのデータの読み出し指示に基づき、前記第二ファイルのデータを格納したブロックの読み出しコマンドを生成し、前記読み出しコマンドを前記ストレージ装置に送り、前記アプリデータ抽出部は、前記ストレージ装置から読み出されるブロックデータを受け取り、前記第二マップ情報に基づき、前記ブロックデータから前記第二ファイルのデータを抽出し、抽出したデータを前記第二アプリ処理部に渡すことを特徴とする請求項3に記載のデータ送信システム。フロー制御部と、データバッファ部と、バッファ管理部をさらに備え、前記第一アプリ処理部は、前記第一ファイルのデータを送信するコネクションを指定し、前記データバッファ部は、コネクション毎のバッファを有し、前記送信データ抽出部により抽出されたデータを、前記第一アプリ処理部により指定されたコネクションに対応するバッファにバッファリングし、前記通信処理部は、前記データバッファにおける前記バッファから前記データを読み出して送信し、前記バッファ管理部は、前記指定されたコネクションに対応する前記バッファの空き状態を把握し、前記フロー制御部は、前記送信データ読み出し指示部による前記送信データ読み出し指示を受け、読み出し指示された前記第一ファイルのデータのうち、まだ読み出されていない、前記空き状態に応じたサイズ分のデータの読み出し指示を生成して、前記第二発行部に送る、ことを特徴とする請求項3に記載のデータ送信システム。第三アプリ処理部と、アプリデータ書き込み要求部と、アプリデータ書き込み部と、をさらに備え、前記第三アプリ処理部は、前記ストレージ装置上に存在しないアプリデータの送信指示を生成し、前記アプリデータを送信するコネクションを指定し、前記バッファ管理部は、前記第三アプリ処理部により指定されたコネクションに対応するバッファの空き状態を把握し、前記フロー制御部は、前記バッファの空き状態に応じたサイズ分のデータの書き込み許可信号を生成し、前記アプリデータ書き込み部は、前記書き込み許可信号に基づいて、前記アプリデータのうち、まだ書き込んでいない前記サイズ分のデータを特定して、前記バッファに書き込み、前記通信処理部は、前記コネクションに対応するバッファからデータを読み出して送信する、ことを特徴とする請求項5に記載のデータ送信システム。前記第三アプリ処理部は、前記第一アプリ処理部と同じコネクションを指定することを特徴とする請求項6に記載のデータ送信システム。ブロック単位でデータを管理するストレージ装置に記憶されているファイルデータをネットワークに送信するデータ送信方法であって、前記ストレージ装置に格納された第一ファイルのデータの送信指示を生成するステップと、前記送信指示に基づき、前記第一ファイルのデータが前記ストレージ装置上のどの位置に記憶されているかを示す第一マップ情報を含むメタデータの読み出し指示を生成するステップと、前記メタデータの読み出し指示に基づき、前記メタデータの読み出しコマンドを生成し、前記ストレージ装置に送るステップと、前記ストレージ装置から返される前記メタデータに含まれる第一マップ情報に基づき、前記第一ファイルのデータの読み出し指示を生成するステップと、前記第一ファイルのデータの読み出し指示に基づき、前記第一ファイルのデータを格納したブロックの読み出しコマンドを生成し、前記読み出しコマンドを前記ストレージ装置に送るステップと、前記読み出しコマンドに応じて前記ストレージ装置から読み出されるブロックデータを受け取り、前記第一マップ情報に基づき、前記ブロックデータから前記第一ファイルのデータを抽出するステップと、前記送信データ抽出部により抽出された前記第一ファイルデータを、前記ネットワークに送信するステップと、を備えたデータ送信方法。このように、ストレージ装置とTOEの間でデータ転送を行う場合は、ホストCPUのソフトウェア処理が介在することから、少なくとも一回はメインメモリへの読み書きが必要となり、また、OSやアプリケーション、ファイルシステムの処理により、メインメモリ上で場合によっては複数回分のメモリコピーが発生することになり、メインメモリの負荷が大幅に増大してしまう。このようなメモリ負荷に対し、従来は十分な処理性能を持つホストCPUと高速のメインメモリを用意して対応していたが、昨今のネットワークストレージの10Gbpsに迫る転送レートの向上を鑑みると、少なからず問題となってきた。特に、メインメモリの性能を上げるためには、一般にホストCPUのグレードアップも伴い、PCやサーバ等の場合は、付随するチップセットのグレードアップも必要となる。これにより、コストや消費電力の問題が特に顕著となる。本発明の一側面は、このようなホストCPUの処理負担を軽減させて、効率的にデータ転送を行うことができるデータ転送装置、データ送信システムおよびデータ送信方法を提供するものである。本発明の一実施形態としてのデータ転送装置は、ブロック単位でデータを管理するストレージ装置に記憶されているファイルのデータをネットワークに転送するデータ転送装置であって、第一発行部と、第二発行部と、送信データ抽出部と、通信処理部とを備える。前記第一発行部は、外部のホストCPUからの要求を受けて、第一ファイルのデータが前記ストレージ装置上のどの位置に記憶されているかを示す第一マップ情報を含むメタデータの読み出しコマンドを生成し、前記読み出しコマンドを前記ストレージ装置に送る。前記第二発行部は、前記ストレージ装置から返される前記メタデータを取得した前記外部のホストCPUから、前記第一ファイルのデータの読み出し指示を受け、前記第一ファイルのデータを格納したブロックの読み出しコマンドを生成し、前記読み出しコマンドを前記ストレージ装置に送る。前記送信データ抽出部は、前記読み出しコマンドに応じて前記ストレージ装置から読み出されるブロックデータを受け取り、前記外部のホストCPUから前記第一マップ情報を受け取り、前記第一マップ情報に基づき、前記ブロックデータから前記第一ファイルのデータを抽出する。前記通信処理部は、前記送信データ抽出部により抽出された前記第一ファイルのデータを、前記ネットワークに送信する。以下、図面を参照しながら、本発明の実施形態を説明する。第1の実施形態図1は第1の実施形態に係るデータ送信システムの概略構成を示すブロック図である。点線矢印は制御の流れ、実線矢印はストレージから読み出したデータの流れ、太線矢印はそのうちの送信データの流れを示す。図1のデータ送信システムは、データ転送装置11と、ホストCPUプロセッサ12と、ストレージ装置13と、を備えている。ホストCPU12の制御に基づき、データ転送装置11がデータをストレージ装置13から読み出し、ネットワーク14に送信する。図1のデータ送信システムの具体的な製品形態としては、PC、サーバ装置、専用LSI、またはFPGAFieldProgrammableGateArray等のネットワークストレージ、あるいはVODVideoOnDemandサーバ、Webサーバなどが想定されるが、これらに限定されるものではない。ホストCPU12は、システム全体の制御を行う。ホストCPU12は、ソフトウェアで実行する主な処理部として、データ送信アプリケーション処理を行う第一アプリ処理部201と、ストレージ装置13のメタデータの読み出しを指示するメタデータ読み出し指示部202と、読み出したメタデータを解析してエクステントマップ情報を取得するエクステントマップ取得部203と、データ転送装置11にデータの読み出し及びデータ送信指示を行う送信データ読み出し指示部204とを有する。もちろんホストCPU12は、その他の種々の処理を行うことが可能である。ストレージ装置13には送信するデータが格納されている。ストレージ装置13の具体的な実装形態は、例えばSSDSolidStateDriveやHDDHardDiskDrive、SDメモリカード等が想定されるが、その限りではない。データ転送装置11は、ホストCPU12に代行し、ストレージ装置13からデータを読み出し、さらに、通信処理を行い、読み出したデータをネットワーク14に送信する。データ転送装置11は、ストレージ装置13に対してコマンドを発行するコマンド発行部101第一発行部、第二発行部、発行したコマンドの応答通知を受け取り、ホストCPU内の該当構成要素図1の構成例ではメタデータ読み出し指示部202、送信データ読み出し指示部204に振り分ける通知振り分け部102、ストレージ装置13から読み出されたデータを受け取り必要なデータを抽出する送信データ抽出部103、抽出されたデータをネットワーク14に送信する通信処理部104を有する。通信処理部104は、前述したTOEに相当する。データ転送装置11の具体的な実装の形態としては、FPGA、専用LSIなどが想定され、PCIカード、またはPCIPeripheralComponentInterconnect-Expressカードとして実装してもよいが、その限りではない。ストレージ装置13にはRAIDRedundantArraysofInexpensiveDisks機能を備えてもよいし、あるいは、データ転送装置11内のストレージ装置13とのI/FにRAID機能を備えてもよい。いずれの場合も本発明の本質とは関係ないので説明では割愛する。ネットワーク14は、イーサネット、無線LAN、あるいは、その他のあらゆる無線通信、有線通信を含む。ホストCPU12とデータ転送装置11は、本装置がPCやサーバ装置などの場合は例えばチップセットやPCIExpress等で接続され、SoCなどの場合は例えば専用のバスなどで接続されてもよい。ストレージ装置13とデータ転送装置11は例えばSATA、SAS、SCSI、SDメモリカード規格などで接続される。以上はほんの一例であり、この限りではない。データ転送装置11は、ハードウェアとソフトウェアのどちらで構成してもよく、実装の形態は問わないが、処理効率の観点からハードウェアベースで構成することが望ましい。また、通信処理部104が処理する通信処理はなんでもよく、例えばTCP/IPベースのプロトコル処理、UDP/IPベースのプロトコル処理、イーサネット処理、無線処理などが挙げられる。なお、TCPのような対向装置とコネクションを張るようなプロトコルの場合、以下の動作説明は、相手とコネクションを張った後のデータ転送の段階での動作になる。ストレージ装置13は、データをたとえばセクタと呼ばれる単位で管理する。ここでは抽象化してブロックと呼ぶ。ユーザが扱うデータはブロック単位ではないため、ストレージ装置13は通常ファイルシステムによりアクセスされる。ファイルシステムは、バイト単位のファイルデータをブロック単位のストレージ装置13の記録領域にマッピングする仕組みである。ファイルシステムは、公知のものを利用するため詳細は割愛するが、簡単に説明すると、ストレージ上のある領域に、そのマッピング情報を含むメタデータメタデータ自体はその他諸々の情報を含むを、データと併せて記憶する。ストレージからファイルデータを読み出す際は、まずこのメタデータを読み出し、それを解析し、所望のファイルデータが実際にどのブロックに記憶されているかを表す情報第一マップ情報、すなわちエクステントマップを得る。そして、そのエクステントマップ情報に従ってブロックデータを読み出し、必要部分だけを抽出して所望のデータを得る。エクステントマップは具体的には図2のようになる。図2は1ブロックが512バイトで、ブロック235~238に所望のファイルのとある部分のデータが格納されている様子を示している。データはブロック235の124バイト目から始まっているので、オフセット124バイト、長さは1458バイト、などと表わされる。このように、エクステントマップは、データが格納されているブロック位置情報、そのうちの有効データが格納されている有効データ位置情報で構成され、つまりはストレージのどこに所望のデータが格納されているかが特定できる情報である。この例ではデータが格納されているバイト位置をオフセットと長さで示しているが、始端バイト位置と終端バイト位置等で表してもよく、有効データの位置が特定できれば表現形式は問わない。また、この例では1458バイトの一つのデータ列の例を示したが、エクステントマップ情報は離散的な複数のデータ列を表わしていてもよい。すなわち、一つのエクステントマップ情報に、例えばブロック235~238のうちの1458バイトを示す情報と、ブロック346~250のうちの2000バイトを示す情報の二つのデータ列を含んでいてもよい。なお、以上のエクステントベースのファイルシステムの場合に当てはまるが、本発明はブロッククラスタベースのファイルシステムも含む。ブロッククラスタベースのファイルシステムの場合は、エクステントの代わりにブロッククラスタのリストになるが、これもエクステントの特殊な場合一つのエクステントの長さを512バイトに固定したものとみなせば同様に考えることが可能である。以降はエクステントの用語を用いて説明し、これら両方を含むものとする。公知の技術では、通常、ホストCPU12はアプリケーションのファイルデータ読み出し要求に基づき、デバイスドライバやファイルシステムソフトウェア等の制御ソフトウェアを実行することで、このエクステントマップの取得を行い、それに従って所望のデータストレージから読み出し、アプリケーションに読み出したデータを返す。それに対して本実施形態では、そのうち一部の処理をデータ転送装置11が代行し、ストレージから読み出されたデータをホストCPU12に返すことなく、そのままネットワーク14にデータを送信する。具体的な処理の流れは次のようになる。まず、第一アプリ処理部201が何らかのアプリケーションソフトウェアの処理によって、送信するファイル第一ファイル、及び、必要に応じてそのファイルの中のデータ位置を特定する。典型的な例としては、ネットワーク14に接続された他の機器からの要求に基づき、ファイルを特定する。そして、メタデータ読み出し指示部202に、当該ファイルの送信指示とともに、ファイル情報ファイル識別子、および必要に応じてファイルの中のデータ位置を送る。メタデータ読み出し指示部202は、渡された情報に基づき、ストレージ装置13からファイルシステムのメタデータを読み出すべく、データ転送装置11のコマンド発行部101にコマンド発行の指示を行う。コマンド発行の指示は、ファイル識別子および必要に応じてデータ位置を含む。コマンド発行部101は、メタデータの読み出しコマンド第一コマンドを発行し、ストレージ装置13に送る。コマンド発行部101が備える機能のうち、第一コマンドを発行する機能は、第一発行部に相当する。ストレージ装置13はこのコマンドに基づき、該当メタデータを読み出してエクステントマップ取得部203に渡す。エクステントマップ取得部203は、このメタデータ情報を解析し、読み出したいファイルのデータのエクステントマップを取得する。なおエクステントマップ情報の取得は、予めキャッシュしていたものを参照して取得する形態でもよいが、同様の手順で予め読み出しておく必要がある。そして取得したエクステントマップ情報を、送信データ読み出し指示部204がデータ転送装置11に渡し、データ転送装置11に対してそのデータの読み出しと送信の指示を行う。データ転送装置11では、コマンド発行部101がそのエクステントマップ情報を受け取り、その情報を元に、送信したいデータを格納したブロックを読み出すべく、ブロックの読み出しコマンド第二コマンドの発行を行う。コマンド発行部101が備える機能のうち、第二コマンドを発行する機能は、第二発行部に相当する。コマンドはストレージ装置13側のI/F仕様に従ったものになるが、通常、一度に指定できる読み出しブロック数に限りがあったり、離散的なブロックは同時に指定できなかったり等制限がある場合があるので、一つのエクステントマップ情報が複数のコマンド群に分割される場合もあるので、その分割処理も行う。そしてコマンド発行部101がそのコマンドを順次ストレージ装置13に対して発行すると、ほどなくストレージ装置13からその応答としてデータが含まれたブロックが返ってくるので、送信データ抽出部103がそのブロックデータを受け取る。一方、送信データ読み出し指示部204がコマンド発行部101に指示を出すときに、送信データ抽出部103に、個々のコマンドに対応するブロックのどの部分に送信したいデータが含まれているかの情報を渡す。すなわち、前述の図2の例だと、送信データ読み出し指示部204は、ブロック235~238というブロック位置情報をコマンド発行部101に渡し、オフセット124バイト長さ1458バイトという有効データ位置情報を送信データ抽出部103に渡す。送信データ抽出部103は受け取ったブロックデータからこの情報をもとに所望の1458バイトのデータ列を抽出し、通信処理部104に渡す。そして通信処理部104は必要に応じて対向装置と制御情報をやりとりしながら、ネットワーク14上にそのデータを送信する。ストレージ装置13とのI/F処理についてより詳しく説明する。まず、ストレージ装置13が典型的なSSDやHDDなどのSATAI/Fを備え、さらにバスマスターとしての機能DMA機能を備える場合、ストレージ装置13へのコマンドはデスクリプタと呼ばれるコマンドを記述したデータを、所定のメモリ上に用意しておき、ストレージ装置13がそれを読み出すことでコマンドがストレージ装置13に受け渡される。前述のコマンド発行部101はこのような処理を行う。デスクリブタは通常リングバッファ形式になっており、典型的な公知の技術ではホストCPU12が使用するメインメモリ主記憶装置、不図示上に置かれる。本実施形態でも同じ形態をとってもよいが、データ転送装置11内のメモリ、あるいは、データ転送装置11に直接接続されるメモリを用いることが、メインメモリやホストCPU12に負荷を与えないという点で望ましい。また、ストレージ装置13が読み出したブロックデータをDMAで書き込む宛先アドレスも、このそれぞれのデスクリブタにあらかじめ指定するが、読み出したメタデータはホストCPU12に渡し、送信データは通信処理部104に渡すといった振り分けは、このアドレス指定によって実現する。すなわち、メタデータをホストCPU12に渡す場合は、通常はメインメモリを介して行うので、デスクリプタに記載する宛先アドレスにメインメモリのアドレスを記載する。送信データを通信処理部104に渡す場合は、宛先アドレスに通信処理部104のアドレスを記載する。これによって、ストレージ装置13がデスクリプタによって指定された宛先アドレスに読み出したデータを書き込むだけで、読み出したデータをそれぞれに振り分けることができる。また、ストレージ装置13はコマンドを実行してデータを読み出した後にコマンド完了通知応答通知を行うが、これは割り込みなどによってその通知が行われ、どこまでコマンドを処理したか、すなわち、リングバッファのデスクリプタ群のどのデスクリプタまで処理したかを、各デスクリプタの処理完了を示すDONEビットをセットするなどして通知する。つまり、ホストCPU12は割り込み通知を受けると、このDONEビットが書かれているデスクリプタを順次読み出し読み出した後はビットをリセットする、そこまで処理が完了していることを判断できる。これは一度に複数のデスクリプタの処理が完了している場合もあり得る。通知振り分け部102は、これによって完了と判断されたデスクリプタがメタデータ読み出しのものであった場合はメタデータ読み出し指示部202に、送信データ読み出しのものであった場合は送信データ読み出し指示部204に通知する形で、完了通知をそれぞれに振り分ける。メタデータ読み出し指示部202はこの通知を受けるとメタデータの読み出しが完了したと判断し、エクステントマップ取得部203にエクステントマップの取得を指示する。また、ストレージ装置13によるブロックデータの転送は、通常は一定のレイテンシがあるため、ホストCPU12は転送指示に対するストレージ装置13からの実行完了を毎回待たずに、複数のブロックの読み出しコマンドをストレージ装置13に対してまとめて発行する場合がある。その場合、そのままでは送信データ読み出し指示部204及びメタデータ読み出し指示部202とストレージ装置13と送信データ抽出部103の三者の間で同期が取られなくなるので、例えば以下の手法により同期を行う。一つ目の手法は、ストレージ装置13がコマンドを受けた順番と必ず同じ順番で読み出しを実行する場合に有効な手法で、送信データ読み出し指示部204がストレージ装置13に複数のコマンドの読み出し指示を行うとき、その指示を行うのと同じ順番で、対応するブロックの中の有効データ位置情報を送信データ抽出部103に通知する手法である。送信データ抽出部103は、受け取った有効データ位置情報を例えばキューイングしておき、ストレージ装置13からブロックデータを受け取った際、キューイングした有効データ位置情報をキューイングした順番に一つずつ取り出せば、ブロックデータとの対応付けが出来る。二つ目の手法は、ストレージ装置13が、内部処理の効率等を優先する場合等で、コマンドを受けた順番とは異なる順番で読み出しを実行し得る場合の手法である。この場合は、例えば各ブロックの宛先アドレスとして異なるアドレスを指定する等が考えられる。つまり、例えば4つの読み出しコマンドをストレージ装置13にまとめて指示する場合、その4個に異なる転送先アドレスを指定しておく。本実施形態では、転送先のアドレスに送信データ抽出部103のアドレスを指定するが、この仕組みを利用する場合は、例えば1つのコマンドで最大4つのブロックの読み出し指示を出す場合、各コマンドに対応する転送先アドレスに、それぞれ送信データ抽出部103のアドレス領域のうちの異なるアドレス領域を指定しておく。例えば送信データ抽出部103のアドレス領域が0x20200000~0x202fffffの場合、図3のように、0x20200000~0x202007ffの512×4バイト領域がコマンド0に対応し、0x20200800~0x20200fffの512×4バイト領域がコマンド1に対応し、0x20201000~0x202017ffの512×4バイト領域がコマンド2に対応し、という具合に予め対応付けておき、送信データ読み出し指示部204は各コマンドにこれらのアドレス領域の先頭を指定するようにコマンド発行部101に指示を出す。すると、転送されたブロックデータはあくまで送信データ抽出部103に転送されるが、それぞれ送信データ抽出部103の中の異なるアドレス領域に転送されるため、データを受けた送信データ抽出部103は、受けたブロックデータが例えば0x20201200から始まるアドレスに書き込まれたデータであれば、それはコマンド2の先頭から2番目のブロックデータであることが特定できる。このコマンド2の有効データ位置情報が図2のような場合、このブロックデータは有効データの389バイト目から900バイト目のデータであることが分かる。一方、送信データ読み出し指示部204は、送信データ抽出部103に対して有効データ位置情報を8つ通知するが、その際に、コマンド0に対応する有効データ位置情報、コマンド1に対応する有効データ位置情報、コマンド2に対する有効データ位置情報、なとど判るように送信データ抽出部103に通知する。これらによって、送信データ抽出部103は受けたデータ、及び、有効データ位置情報がともにどのコマンドに対するものかが判別できるため、送信データ抽出部103はこれらの対応付けが可能となる。なお、アドレスを使うことは本発明のほんの一例であり、その他にストレージ装置13から送信データ抽出部103に通知できる情報であれば何を利用しても良い。このように、ブロックデータの宛先アドレス領域を分けることによって、送信データ抽出部103が受け取ったブロックデータの順番がもとのデータ列の順番通常はネットワーク14に送信する順番と異なる場合でも、ブロックデータの宛先アドレスを確認することで、そのデータがどのコマンドに基づくデータかが判断できるので、それをもとにデータ列を元の順番に並び替えることが可能となる。以上のストレージI/Fの詳細はほんの一例であり、本発明はこれに限るものではない。また、ストレージ装置13が内部エラー等何らかの理由により要求されたコマンドが完了できない場合がある。この場合、ストレージ装置13はデータ転送装置11にエラー通知を行うが、そのままではホストCPU12はこの情報を得られないので、このような場合はデータ転送装置11がホストCPU12にエラー通知を中継して従来通りホストCPU12も異常を知ることができるようにする。以上、本発明の第一の実施の形態を説明した。以上のような形態をとることで、アプリケーションからの要求に基づき、ホストCPU12と不図示のメインメモリにデータ転送処理の負荷を与えることなくストレージ装置13上のデータをネットワーク14に送信することができるので、処理効率が向上し、データ転送の速度を向上させることができる。または、ホストCPU12、または、それに付随するチップセット、メモリ、マザーボードなどのグレードを下げることができるので、装置の低コスト化を図ることができる。または、データ転送の大部分の処理をホストCPU12のソフトウェア処理ではなくデータ転送装置11のハードウェア処理で実行することが可能となるので、装置の低消費電力化を図ることができる。なお、以上のうち、通知振り分け部102は必ずしもデータ転送装置11上に構成する必要はなく、ホストCPU12上に構成してもよい。また、コマンド発行部101もその一部の処理をホストCPU12側で行ってもよいが、一つの送信データ読み出し指示を複数のコマンドに分割する処理はデータ転送装置11上で行う方が処理効率の面で望ましい。また逆に、メタデータ読み出し指示部、エクステントマップ取得部、送信データ読み出し指示部をデータ転送装置11上に構成してもよい。また、第一アプリ処理部201によって特定されたファイルの情報を後段の処理部に渡す処理は、例えばLinuxOSなどで実装されているsendfile関数のような標準システムコールでI/Fし、この関数内の処理を前述の動作を実現できるようにするような実施の形態が望ましい。このような標準関数でアプリケーションとI/Fすることにより、既存のアプリケーションに改変を加える必要がなくなり、本発明の実施を容易にすることができる。以上の構成によってストレージ装置13からネットワーク14へのホストCPU12を介さないデータ転送が可能となるが、この形態が望ましくない場合もある。例えば、別のアプリケーション処理等によって、データ転送ではなくホストCPU12自身でストレージ装置13の中身のファイル第二ファイルのデータを参照したいような場合もある。その場合の構成は図4のようになる。図4の第二アプリ処理部301は、データ送信ではなく単純にストレージ上のデータを読み出したいアプリケーションの処理部である。さらに、図4は図1に加えて、当該データの読み出しをデータ転送装置11に指示するアプリデータ読み出し指示部303、読み出された当該データを取得して有効データを抽出するアプリデータ抽出部302を備える。図4の形態の動作は次のようになる。まず、第一アプリ処理部201によるデータ送信要求に基づく処理は図1と同様である。一方、第二アプリ処理部301が、ファイル第二ファイルのデータ読み出し要求取得指示を行うと、第一アプリ処理の場合と同様にメタデータを読み出し、読み出したいデータのエクステントマップ情報第二マップ情報を取得するが、それに基づくデータ読み出し指示を行う場合、アプリデータ読み出し指示部303によって、読み出したデータの宛先アドレスをメインメモリ不図示に設定した読み出し指示を出す。すると、ストレージ装置13から読み出されたデータはメインメモリに書き込まれるので、アプリデータ抽出部302がそのデータを読み出す。ここで、送信データの抽出と同様、アプリデータのエクステントマップ情報のうち、有効データ位置情報をアプリデータ読み出し指示部303がアプリデータ抽出部302に渡すので、アプリデータ抽出部302はその情報を元に有効データを抽出して、アプリケーションに渡す。通知振り分け部102は、アプリデータの読み出しコマンドに対する応答通知をアプリデータ読み出し指示部303に振り分けて通知する。以上のように動作することで、データ転送装置11による効率的なデータ送信と、従来のアプリケーションによるデータ読み出しを共存することが可能となり、ひいては本発明の実施を容易にすることができる。また、第二アプリ処理部301によるデータの読み出し要求は、例えばLinuxOSなどで実装されているread関数のような標準システムコールでI/Fし、この関数内の処理を前述の動作を実現できるようにするような実施の形態が望ましい。このような標準関数でアプリケーションとI/Fすることにより、既存のアプリケーションに改変を加える必要がなくなり、本発明の実施を容易にすることができる。第2の実施形態第2の実施形態は、データ転送用に複数の通信コネクションが設定され、コネクション毎に独立してフロー制御を行う例を示している。例えばNASのようなネットワークストレージやVODサーバで複数のクライアント端末、あるいは、クライアント端末上の複数のアプリケーションから同時に読み出し要求やコンテンツ配信要求を受けた場合等、複数の独立したコネクションでストレージ装置13からデータを読み出してネットワーク14に送信する動作を可能とする。図5は第2の実施形態に係るデータ送信システムの概略構成を示すブロック図である。図5のデータ転送装置11は第1の実施形態に加えて、送信データ抽出部103と通信処理部104の間のデータの受け渡しのためにコネクション毎にデータをバッファリングするデータバッファ部106と、データバッファ部106のコネクション毎のバッファ状態を管理するバッファ管理部107と、バッファ管理部107からの通知に基づいてコネクション毎のデータのフロー制御を行うフロー制御部105とを備える。図5において、図1と同じ符号で示した各部は、少なくとも図1と同様の動作を行い、さらにフロー制御のための動作が加わる。フロー制御情報の伝達は太い点線で表わしている。図5のデータ送信システムの処理手順は次のようになる。まず、図1と同様に第一アプリ処理部201が何らかのアプリケーションソフトウェアの処理によって、送信するファイル、及び、必要に応じてそのファイルの中のデータ位置を特定する。典型的な例としては、ネットワーク14に接続された他の機器からの要求に基づき、ファイルを特定する。そして、メタデータ読み出し指示部202にその情報を渡す。ただし、今回はアプリケーションが複数のコネクションを扱うので、第一アプリ処理部201はコネクションを識別するコネクション識別子とともに、特定したファイルデータの情報を渡す。メタデータ読み出し指示部202は、渡されたファイル情報に基づき、ストレージ装置13からファイルシステムのメタデータを読み出すべく、データ転送装置11のコマンド発行部101にコマンド発行の指示を行う。ストレージ装置13はこのコマンドに基づき、メタデータを読み出してエクステントマップ取得部203に渡す。エクステントマップ取得部203は、このメタデータ情報を解析し、読み出したいファイルのデータのエクステントマップを取得する。そして取得したエクステントマップ情報を、送信データ読み出し指示部204がデータ転送装置11に渡し、データ転送装置11に対してそのデータの読み出しと、前述のアプリケーションから渡されたコネクション識別子との情報を併せて渡し、送信の指示を行う。データ転送装置11では、まずフロー制御部105がその指示を受ける。フロー制御部105は、コネクション毎にエクステントマップ情報を保持する。つまり、複数のコネクションのデータ読み出し要求を一旦保持しておく。そして、バッファ管理部107からバッファに空きがあるコネクションの通知を受けると、そのコネクションの送信データの読み出し指示をコマンド発行部101に対して行う。初期状態では全てのコネクションのバッファは空いているので、そのままコマンド発行部101に送信データ読み出し指示を出すことになるが、同じコネクションのデータ送信要求が連続してくると、やがて一旦待ってからバッファ管理部107からの空き通知を待つ形になる場合がある。コマンド発行部101に一度にコマンド発行要求するのはあくまでバッファが空いているサイズ以下でなければならない。一例として、データバッファ部106のコネクション毎のバッファが128KBずつ確保されているとして、バッファ管理部107がいずれかのコネクションで64KB以上バッファに空きが生じたら、そのコネクションのバッファ空きをフロー制御部105に通知するものとする。ホストCPU12から渡されたエクステントマップはこれより大きいサイズのデータを示している場合も当然ながらあり得るが、フロー制御部105が一度にコマンド発行部101に要求可能なのは空いた分の64KB以下のサイズの部分データなので、この部分データすなわち送信したいデータのうち、まだ読み出していない、当該サイズ以下のデータの読み出しをコマンド発行部101に要求する。同時に、この部分データの中の有効データ位置を送信データ抽出部103に渡す。そして、処理をし終えた部分データの位置を進捗情報としてコネクション毎に保持し、一旦コマンド発行要求を終える。以上の処理を判り易く説明するため、データの一例を図6に示す。図6はホストCPU12からブロック235~1000、有効位置データ情報としてオフセット124バイト、長さ391602バイトのエクステントマップを与えられた例を示している。この場合、最初の部分データは例えば64KB以下の切りの良いところとしてブロック235~362の65412バイトとなる。そして、この部分データの有効データ位置はオフセット124バイト、長さ65412バイトである。フロー制御部105はブロック235~362の読み出しコマンドの発行をコマンド発行部101に要求し、同時に送信データ抽出部103にオフセット124、長さ65412バイトという情報を渡し、進捗情報として次回処理するブロックはブロック363、あるいは、65413バイト目、という情報を保持し、一旦処理を終え、バッファ管理部107からの次のバッファ空き通知を待つ。なお、以上で述べた64KBなどの各種データサイズはあくまで一例であり、この限りではない。また、データサイズは一定である必要もなく、サイズが毎回変わる場合も本発明に含まれる。一旦部分データの処理を終え、その後に他のコネクションのデータバッファが空いたという通知をバッファ管理部107から受けると、フロー制御部105は、今度はそのコネクションに対して同様に部分データの読み出し要求処理を行う。そして、あるコネクションに関して与えられたエクステントマップが示すデータの全てを送信し終える図6の場合は六番目の部分データの読み出し要求を完了すると、そのコネクションの与えられたエクステントマップが示すすべてのデータの送信の完了となり、ホストCPU12にその旨通知する。ホストCPU12では例えばメタデータ読み出し指示部202がこの通知を受け取り、次のアプリケーションからのデータ送信処理、すなわちメタデータ読み出し指示部202から始まる一連の処理を実行可能とする。逆に、この通知を受けるまで、次のメタデータ読み出しをいったん保留することで、第一アプリ処理部201とのフロー制御を実現する。なお、ホストCPU12がこの通知を受けるのは必ずしもメタデータ読み出し指示部202である必要はなく、エクステントマップ取得部203、あるいは、送信データ読み出し指示部204でもよく、最終的にアプリケーションに対してバックプレッシャが伝達されるようになっていれば、どこが通知を受ける形でもよい。また、以上の例ではデータ転送装置11がコネクション毎に同時に一つしかエクステントマップを受け付けない例を示したが、二つ以上受け付ける形でもよい。いくつ受け付けるにしても必ず有限個にはなるので、その最大個数を受け付けた際にそれ以上受けられないような仕組みとして前述の方式が適用される。コマンド発行部101と送信データ抽出部103の処理は図1と基本的に同様だが、送信データ抽出部103は、前述のとおりデータ有効位置情報をフロー制御部105から受け取り、その情報をもとに抽出したデータをデータバッファ部106に書き込む。データバッファ部106に書き込む際の宛先アドレスは、フロー制御部105が生成し、送信データ抽出部103に渡す。例えば、データバッファ部106が前述の説明同様にコネクション毎に128KB確保されており、コネクション0のバッファの先頭アドレスが0x00000000、コネクション1のバッファの先頭アドレスがアドレス0x00020000、コネクション2のバッファの先頭アドレスが0x00040000、のようにアサインされているとき、現在処理しているのはコネクション1で、初めて図6のデータ読み出しを要求されたとすると、最初の部分データの宛先アドレスは0x00020000、次の部分データの宛先アドレスは65413バイト加えた0x0002ff85となる。このように宛先アドレスを部分データのサイズごとに増加させていくと、データバッファ部106にはもとの通りひとつながりのデータとして展開される。また、バッファが例えばバイト単位のリングバッファだとすると、0x0003ffffの次のバイトは0x00020000に書き込むことになる。フロー制御部105は、送信データ抽出部103に対し、有効データ位置情報と共に、このような宛先アドレス情報を渡し、送信データ抽出部103がそれに従ったアドレスから抽出したデータを書き込むことで、データバッファ部106にコネクション毎に適切に送信データを展開することができる。バッファ管理部107は、データバッファ部106のコネクション毎のデータバッファのデータの供給側の書き込み位置と、データの消費側の読み出し位置の常に把握し、コネクション毎にバッファの空き状態を把握する。具体的には、フロー制御部105がコマンド発行部101に部分データの読み出し要求を行い、ストレージ装置103からその応答通知が返ってくると、フロー制御部105は当該コネクションのバッファにどこまでデータが書き込まれたか判るので、その位置を進捗としてバッファ管理部107に通知する。例えば図6の最初の部分データを書きこみ終わった際、65413バイトという情報をコネクション識別子と添えて通知する。この通知によって、バッファ管理部107はコネクション1のバッファのデータの供給側の位置は65413バイトと把握できる。一方、通信処理部104がデータを送信すべくデータバッファ部106から読み出すと、その読み出し位置が移動するので、通信処理部104は、同様に読み出し終わったバイト位置正確には次に読み出し始めるバイト位置をコネクション毎にバッファ管理部107に通知する。初期状態では、バッファは128KB正確には2の17乗の131072バイト空いているが、最初にデータを書き込まれると65413バイト減って空きサイズが65659バイトになり、これは64KB正確には2の16乗の65536バイトより大きいので、バッファ空き通知をフロー制御部105に行う。すると、フロー制御部105は次の部分データ図6の例では65536バイトの読み出し要求を出すので、そのデータが書き込まれると、バッファサイズがさらに減って23バイトになり、これは64KBより少ないので、バッファ管理部107は空き通知を行わず、フロー制御部105は次の部分データの読み出しを保留する。その後、通信処理部104がデータを例えば1KB1024B読み出すと、空きバッファサイズは1047バイトに増加する。引き続き通信処理部104がデータを読み出していき、空きサイズが65536バイト以上になると、その段階でバッファ管理部107はフロー制御部105に空き通知を行う。通信処理部104は、処理している通信プロトコル仕様やネットワーク14の帯域などによって送信速度が制限される。例えばTCPプロトコルのようにフロー制御や輻輳制御を行うような場合は、対向機やネットワーク14の込み具合によって送信速度が低下し、データバッファ部106からのデータの読み出しの進み具合が遅くなるが、その場合でも、このような構成によって適切に最上位のアプリケーションまでのフロー制御を実現することができる。以上、本発明の第二の実施の形態を説明した。以上のような形態をとることで、第一の実施の形態の効果に加えて、通信速度が遅くなっても適切にフロー制御を行うことができるようになる。また、通信コネクション毎にフロー制御を行うことができるので、あるコネクションのデータフローが止まっていても、それ以外のコネクションのデータフローには影響を与えないように動作することが可能である。以上の実施の形態によりストレージ装置13にあるデータを効率よく送信する例を示したが、アプリケーションによってはストレージ装置13にないデータを、ストレージ装置13のデータを送信するコネクションと同じコネクションで送信したくなる場合もある。例えば通信処理部104がTCP/IPプロトコルより下位層の通信処理を行うときに、アプリケーションはそれより上位層のHTTPプロトコルに基づいた通信を行いたい場合に、ストレージ装置13にあるデータとは別の制御情報をやりとりしたい場合や、あるいは、ストレージ装置13にあるデータを送信する際にもデータのHTTPヘッダを送信する必要があるので、その場合はまずHTTPヘッダだけを送信してから、その次にボディとしてストレージ装置13のデータを送信するように動作する必要がある。そのような動作を実現する構成を図7に示す。図7は図6に加えて、HTTPヘッダなどストレージ装置13にないデータ以下、アプリデータの送信を要求する第三アプリ処理部401と、その要求を受け付けアプリデータの書き込みをデータ転送装置11に要求するアプリデータ書き込み要求部402と、アプリデータの書き込みを行うアプリデータ書き込み部403とを備える。アプリデータの流れは実線で示している。具体的には次のように動作する。まず、第三アプリ処理部401が何らかの方法でアプリデータを用意する。これは例えばHTTP通信を行っている場合だと通信手順やアプリケーションの状態やその他諸々の条件によって定められ、生成される。そして、そのアプリデータをデータ転送装置11で送信すべく、アプリデータと送信するコネクション識別子を併せてアプリデータ書き込み要求部402に渡す形で送信を要求する。アプリデータ書き込み要求部402はそれを受けると、フロー制御部105にそのアプリデータのサイズとともにデータの書き込みの要求を行う。フロー制御部105はそれを受けると、その書き込み要求を一旦保持し、バッファ管理部107からの空き通知を待ち、バッファ管理部107からバッファの空き通知が来次第、書き込み許可を意味する応答をアプリデータ書き込み要求部402に返す。するとアプリデータ書き込み要求部402はアプリデータ書き込み部403に書き込みを指示し、アプリデータ書き込み部403は実際にデータバッファにアプリデータの書き込みを行う。書き込みが終わると、フロー制御部105がストレージ装置13のデータを読み出してデータバッファ部106に書き込む際と同様に、書き込んだ位置を進捗としてバッファ管理部107に対して通知する。以上の一連の処理を完了すると、第三アプリ処理部401に送信完了を通知する。通信処理部104はストレージからのデータと同様にこのデータを読み出し、送信する。アプリデータのサイズがバッファ管理部107のバッファ空き通知を行うサイズ先程の例だと64KBより大きい場合は、64KBだけ書き込めることになるので、その場合はアプリデータ書き込み部403はそのサイズまでの書き込みを行い、さらにまだ書き込んでいないデータがある場合は、再度アプリデータ書き込み要求部402がフロー制御部105に書き込み要求を出し、以下、書き込みたいデータがなくなるまで同様に処理を繰り返す。また、通信ヘッダなどアプリデータの書き込みサイズが非常に小さい場合は、バッファ管理部107から通知してもらう空きサイズを、例えばアプリデータのサイズにしてもらうべく、フロー制御部105からバッファ管理部107にサイズ変更の指示を行ってもよい。例えば20バイトのアプリデータを送信したい場合、フロー制御部105はバッファ管理部107に対し、次に20バイトの空きが生じたら通知するように指示を行い、バッファ管理部107はそれに従う。これによって無駄にバッファが空くのを待つ必要がなくなる。以上のように動作することにより、ストレージ装置13のデータを送信する通信コネクションと同じ通信コネクションで任意のアプリケーションデータを送信することができる。また、第三アプリ処理部401によって行われるアプリデータの送信要求処理は、例えばLinuxOSなどで実装されているsend関数のような標準システムコールでI/Fし、この関数内の処理を前述の動作を実現できるようにするような実施の形態が望ましい。このような標準関数でアプリケーションとI/Fすることにより、既存のアプリケーションに改変を加える必要がなくなり、本発明の実施を容易にすることができる。本発明の態様は、上述した個々の実施形態に限定されるものではなく、当業者が想到しうる種々の変形も含むものであり、本実施形態の効果も上述した内容に限定されない。すなわち、特許請求の範囲に規定された内容およびその均等物から導き出される本実施形態の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更および部分的削除が可能である。上述した実施形態で説明したデータ送信システムの少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、データ送信システムの少なくとも一部の機能を実現するプログラムをフレキシブルディスクやCD-ROM等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリ等の固定型の記録媒体でもよい。また、データ送信システムの少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線無線通信も含むを介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。