データ転送装置、データ送信システム、データ送信方法およびプログラム
【課題】ホストＣＰＵの処理負担を軽減させて効率的なデータ転送を行う。
【解決手段】データ転送装置は、コマンド発行部と、送信データ抽出部と、通信処理部と、を備える。コマンド発行部は、制御装置から読み出しが指示されたブロックの読み出しコマンドを記憶装置に対して発行する。送信データ抽出部は、読み出しコマンドに応じて記憶装置から読み出されたデータから送信データを抽出する。通信処理部は、予め定められたプロトコルに基づいて、抽出された送信データをネットワークに送信する。
【解決手段】データ転送装置は、コマンド発行部と、送信データ抽出部と、通信処理部と、を備える。コマンド発行部は、制御装置から読み出しが指示されたブロックの読み出しコマンドを記憶装置に対して発行する。送信データ抽出部は、読み出しコマンドに応じて記憶装置から読み出されたデータから送信データを抽出する。通信処理部は、予め定められたプロトコルに基づいて、抽出された送信データをネットワークに送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、データ転送装置、データ送信システム、データ送信方法およびプログラムに関する。
【背景技術】
【０００２】
昨今、映像のストリーミング配信が普及しつつある。例えばＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）サーバと呼ばれるコンテンツ配信サーバによってストリーミング配信が行われている。このようなコンテンツ配信サーバは、自身がもつストレージから映像コンテンツを読み出し、ネットワーク接続されたユーザの端末に送信する処理を行う。通信プロトコルは、ＴＣＰ／ＩＰベースのＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）や、リアルタイム通信向けのＵＤＰ／ＩＰベースのＲＴＰ（Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）等が使われる。また、ＲＴＰの場合は誤り訂正にＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）等が使われる。
【０００３】
このようなＶＯＤサーバに用いられるストレージやネットワーク等のデバイスの高速化は著しく進んでいる。イーサネット（登録商標）は、現在１Ｇｂｐｓが主流になりつつあり、データセンター等では１０Ｇｂｐｓが使われ始めている。また、次世代の４０Ｇｂｐｓ／１００Ｇｂｐｓイーサネットの仕様策定も完了し、これらについても今後着実に普及していくものと思われる。また、ストレージに関してはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）のＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）のストライピング処理（並列化）による高速化に加えて、昨今のＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）の転送性能の向上は著しい。Ｉ／Ｆ（インタフェース）規格のＳＡＴＡ（Ｓｅｒｉａｌ Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｍｅｎｔ）に関しても、バンド幅６ＧｂｐｓのＳＡＴＡ３．０が既に普及している状況であり、単体で実効４Ｇｂｐｓ超の読み出しレートを出す製品も出てきている。
【０００４】
このようなネットワークやストレージのＩ／Ｏ性能向上に伴って、それを制御するホストＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）の処理負荷も増大していく。従来はＴＣＰ／ＩＰオフロードエンジン（以下、ＴＯＥ）という技術により、その解決が試みられてきた。ＴＯＥは、ホストＣＰＵに代行して、前述のＴＣＰ／ＩＰの処理を行う専用プロセッサや専用回路を設けたものであり、ホストＣＰＵからＴＣＰ／ＩＰ処理負荷をオフロードするものである。このＴＯＥを用いることによって、従来のソフトウェアによる通信プロトコル処理よりも高速にＴＣＰ／ＩＰ処理を行うことが可能となり、ネットワークストレージの性能向上に貢献できる。
【０００５】
ストレージやＴＯＥは、それぞれホストＣＰＵによってスレーブ的に制御され、データはメインメモリを介して入出力することが想定されている。よって、ストレージ上のデータをネットワークに入出力する際、ストレージ（ＳＳＤ、ＨＤＤ等）とＴＯＥの間のデータ転送は、通常メインメモリを介して行われる。
【０００６】
また、ホストＣＰＵ上で動作する、これらの間をブリッジするアプリケーションソフトウェア、または、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）のカーネル空間とユーザ空間のデータの受け渡し処理等により、メインメモリ上で何回分か転送データのコピーが発生する場合もある。さらにストレージにはファイルシステム処理も必要である。一般的なファイルシステムの実装では、ストレージから固定バイト長のセクタ単位で読み書きしたデータを一旦メモリ上に保持し、メモリから任意バイト長のファイルとしてのデータをアプリケーションバッファにコピーする形で渡す。このため、ファイルシステム処理でもデータのコピーが発生する。
【０００７】
さらに、コンテンツ配信サーバでは、映像コンテンツのトリックプレイ（早送り再生、巻き戻し再生など、通常再生とは異なる再生形態）に対応した送信を行う必要があり、通常のファイル転送より条件が複雑である。
【０００８】
このように、ストレージとＴＯＥの間でデータ転送を行う場合は、ホストＣＰＵのソフトウェア処理が介在することから、少なくとも一回はメインメモリへの読み書きが必要となる。また、ＯＳ、アプリケーション、および、ファイルシステムの処理により、メインメモリ上で場合によっては複数回分のメモリコピーが発生し、メインメモリの負荷が大幅に増大する。このようなメモリ負荷の増大に対し、従来は十分な処理性能を持つホストＣＰＵと高速のメインメモリを用意して対応していた。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００５−３１６６２９号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、昨今のネットワークストレージの１０Ｇｂｐｓに迫る転送レートの向上を鑑みると、コストや消費電力の増大が少なからず問題となってきた。特に、メインメモリの性能を上げるためには、一般にホストＣＰＵのグレードアップも伴う。ＰＣ（パーソナルコンピュータ）やサーバ等の場合は、付随するチップセットのグレードアップも必要となる。これにより、コストや消費電力の問題が特に顕著となる。
【課題を解決するための手段】
【００１１】
実施形態のデータ転送装置は、コマンド発行部と、送信データ抽出部と、通信処理部と、を備える。コマンド発行部は、制御装置から読み出しが指示されたブロックの読み出しコマンドを記憶装置に対して発行する。送信データ抽出部は、読み出しコマンドに応じて記憶装置から読み出されたデータから送信データを抽出する。通信処理部は、予め定められたプロトコルに基づいて、抽出された送信データをネットワークに送信する。
【図面の簡単な説明】
【００１２】
【図１】第１の実施形態に係るデータ送信システムのブロック図。
【図２】エクステントマップの構成例を示す図。
【図３】第１の実施形態におけるデータ転送処理のフローチャート。
【図４】コマンドとアドレス領域との対応の一例を示す図。
【図５】第２の実施形態に係るデータ送信システムのブロック図。
【図６】第２の実施形態におけるデータ転送処理のフローチャート。
【図７】エクステントマップの構成例を示す図。
【図８】第２の実施形態の通信処理部のブロック図。
【図９】ＴＴＳ０〜ＴＴＳ７のデータの並びを例示する図。
【図１０】トリックプレイ向け送信の動作概要を示す図。
【図１１】第３の実施形態に係るホストＣＰＵのブロック図。
【図１２】第３の実施形態に係る通信処理部のブロック図。
【図１３】第３の実施形態におけるデータ転送処理のフローチャート。
【図１４】Ｉフレームとパケットとの関係の一例を示す図。
【図１５】データパケットのグルーピングの一例を示す図。
【図１６】データパケットのグルーピングの一例を示す図。
【図１７】第３の実施形態の変形例に係るホストＣＰＵのブロック図。
【発明を実施するための形態】
【００１３】
以下に添付図面を参照して、この発明にかかるデータ転送装置、データ送信システム、データ送信方法およびプログラムの好適な実施形態を詳細に説明する。
【００１４】
（第１の実施形態）
図１は、第１の実施形態に係るデータ送信システムの概略構成例を示すブロック図である。破線矢印は制御の流れを示し、実線矢印はストレージから読み出したデータの流れを示し、太い実線矢印は読み出したデータのうち送信するデータ（送信データ）の流れを示す。
【００１５】
第１の実施形態のデータ送信システムは、制御装置としてのホストＣＰＵ（プロセッサ）２００と、記憶装置としてのストレージ３００と、データ転送装置１００とを備えている。ホストＣＰＵ２００の制御に基づき、データ転送装置１００が送信データをストレージ３００から読み出し、ネットワーク４００に送信する。
【００１６】
第１の実施形態のデータ送信システムの具体的な製品形態としては、ＰＣ、サーバ装置、専用ＬＳＩ、およびＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等のネットワークストレージ、ＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）サーバ、並びにＷｅｂサーバなどが想定されるが、これらに限定されるものではない。
【００１７】
ホストＣＰＵ２００は、データ送信システム全体を制御する。ホストＣＰＵ２００は、ソフトウェアで実行する主な処理部として、ファイル指定部２０１と、メタデータ指定部２０２と、メタデータ解析部２０３と、送信データ特定部２０４と、管理情報読み出し指示部２０５と、エクステントマップ取得部２０６と、送信データ読み出し指示部２０７と、を備えている。ホストＣＰＵ２００は、その他の種々の処理を行うことが可能である。
【００１８】
ファイル指定部２０１は、送信データが含まれるファイルを指定する。メタデータ指定部２０２は、ファイル内での送信データの位置の特定に利用する特定情報を含むメタデータを指定する。メタデータ解析部２０３は、指定されたメタデータを解析する。送信データ特定部２０４は、解析されたメタデータの情報をもとに、指定されたファイルの中の送信データの位置を特定する。
【００１９】
管理情報読み出し指示部２０５は、ストレージ３００の管理情報の読み出しを指示する。管理情報とは、ストレージ３００に記憶される実データのメタデータである。管理情報は、例えば実データとストレージ３００の記録領域とのマッピング情報を含む。なお、管理情報はその他諸々の情報も含む。
【００２０】
エクステントマップ取得部２０６は、読み出した管理情報を解析して、送信データのエクステントマップ（マップ情報）を取得する。エクステントマップとは、ストレージ３００内のデータの記憶位置を特定する情報である。エクステントマップの詳細については後述する。
【００２１】
送信データ読み出し指示部２０７は、データ転送装置１００に対して、データの読み出しおよびデータの送信を指示する。
【００２２】
ストレージ３００は、送信データを含む各種データを格納する。ストレージ３００の具体的な実装形態は、例えばＳＳＤ、ＨＤＤおよびＳＤメモリカード等が想定されるが、その限りではない。また、ストレージ３００がＲＡＩＤ機能を備えてもよい。データ転送装置１００内のストレージ３００とのインタフェースにＲＡＩＤ機能を備えてもよい。
【００２３】
データ転送装置１００は、ホストＣＰＵ２００に代行し、ストレージ３００からデータを読み出し、読み出したデータに対して通信処理を行い、読み出したデータをネットワーク４００に送信する。データ転送装置１００は、コマンド発行部１１０と、通知振り分け部１２０と、送信データ抽出部１３０と、通信処理部１４０と、を備えている。
【００２４】
コマンド発行部１１０は、ストレージ３００に対してデータの読み出し等のコマンドを発行する。通知振り分け部１２０は、発行したコマンドの応答通知を受け取り、受け取った応答通知をホストＣＰＵ２００とデータ転送装置１００とのいずれかに振り分ける。送信データ抽出部１３０は、ストレージ３００から読み出されたデータを受け取り、受け取ったデータから必要なデータを抽出する。通信処理部１４０は、抽出されたデータに対して予め定められた通信プロトコルに従った通信処理を行い、抽出されたデータをネットワーク４００に送信する。
【００２５】
通信処理部１４０は、前述したＴＯＥに相当する。データ転送装置１００の具体的な実装の形態としては、ＦＰＧＡおよび専用ＬＳＩなどが想定される。データ転送装置１００をＰＣＩカードおよびＰＣＩ−Ｅｘｐｒｅｓｓカードとして実装してもよい。なお、実装形態はこれらに限られるものではない。
【００２６】
ネットワーク４００は、イーサネットおよび無線ＬＡＮなどのあらゆる無線通信または有線通信により構成できる。
【００２７】
ホストＣＰＵ２００とデータ転送装置１００は、データ送信システムがＰＣやサーバ装置などの場合は例えばチップセットやＰＣＩ Ｅｘｐｒｅｓｓ等で接続されてもよい。データ送信システムがＳｏＣなどの場合は、ホストＣＰＵ２００とデータ転送装置１００は、例えば専用のバスなどで接続されてもよい。ストレージ３００とデータ転送装置１００は、例えばＳＡＴＡ、ＳＡＳ、ＳＣＳＩ、および、ＳＤメモリカード規格などで接続される。これらは一例であり、その他のあらゆる接続方式を適用できる。
【００２８】
データ転送装置１００は、ハードウェアとソフトウェアのいずれにより構成してもよく、実装の形態は問わない。処理効率の観点からは、ハードウェアベースで構成することが望ましい。また、通信処理部１４０による通信処理はどのような処理であってもよい。通信処理部１４０による通信処理としては、例えば、ＴＣＰ／ＩＰベースのプロトコル処理、ＵＤＰ／ＩＰベースのプロトコル処理、ＩＰＴＶ向けＲＴＰ／ＦＥＣベースのプロトコル処理、イーサネット処理、および、無線処理などが挙げられる。
【００２９】
なお、ＴＣＰのような対向装置とコネクションを張るプロトコルの場合、以下の動作説明は、相手とコネクションを張った後のデータ転送の段階での動作になる。
【００３０】
ストレージ３００は、データを例えばセクタ、クラスタまたはページと呼ばれる単位で管理する。ここでは簡単のため、これらを総称してブロックと呼ぶ。ユーザが扱うデータはブロック単位ではないため、ストレージ３００は通常ファイルシステムによりアクセスされる。ファイルシステムは、バイト単位のファイルデータをブロック単位のストレージ３００の記録領域にマッピングする仕組みである。ファイルシステムは、ストレージ３００上の予め定められた領域に、上述の管理情報をデータと併せて記憶する。
【００３１】
ストレージ３００からファイルデータを読み出す際は、まずこの管理情報を読み出し、読み出した管理情報を解析し、所望のファイルデータが実際にどのブロックに記憶されているかを表す情報であるエクステントマップを得る。そして、取得したエクステントマップに従ってブロックごとのデータ（ブロックデータ）を読み出し、ブロックデータから必要部分だけを抽出して所望のデータを得る。
【００３２】
次に、エクステントマップの詳細について説明する。図２は、エクステントマップの構成例を示す図である。図２は、１ブロックが５１２バイトであり、ブロック２３５〜２３８に所望のファイルの一部のデータが格納されている例を示している。データは、ブロック２３５の１２４バイト目から始まっている。このため、データの位置を示す情報（有効データ位置情報）は、オフセット１２４バイト、長さは１４５８バイト、などと表わされる。エクステントマップは、ブロック位置情報と、有効データ位置情報とを含む。ブロック位置情報は、データが格納されているブロックの位置を表す情報である。図２の例では、ブロック２３５〜２３８が、ブロック位置情報に相当する。有効データ位置情報は、ブロック位置情報で示されるブロック内で、有効データが格納されている位置を表す情報である。このように、エクステントマップは、ストレージ３００のどの位置に所望のデータが格納されているかが特定できる情報である。
【００３３】
図２の例では、データが格納されているバイト位置をオフセットと長さで有効データ位置情報を示している。有効データ位置情報は、始端バイト位置と終端バイト位置等で表してもよい。このように、有効データ位置情報は、有効データの位置が特定できれば表現形式は問わない。また、図２の例では１４５８バイトの１つのデータ列の例を示したが、エクステントマップは離散的な複数のデータ列を表わしていてもよい。すなわち、１つのエクステントマップに、例えばブロック２３５〜２３８のうちの１４５８バイトを示す情報と、ブロック３４６〜３５０のうちの２０００バイトを示す情報の２つのデータ列を含んでいてもよい。
【００３４】
なお、以上はエクステントベースのファイルシステムの場合に当てはまる。本実施形態は、ブロック（クラスタ）ベースのファイルシステムにも適用できる。ブロック（クラスタ）ベースのファイルシステムの場合は、エクステントの代わりにブロック（クラスタ）のリストになる。このブロック（クラスタ）のリストをエクステントの特殊な場合（１つのエクステントの長さを５１２バイトに固定したもの）とみなせば、エクステントベースの場合と同様に考えることが可能である。以後はエクステントの用語を用いて説明し、これら両方を含むものとする。
【００３５】
公知の技術では、通常、ホストＣＰＵはアプリケーションのファイルデータ読み出し要求に基づき、デバイスドライバやファイルシステムソフトウェア等の制御ソフトウェアを実行することで、このエクステントマップを取得する。そして、ホストＣＰＵは、エクステントマップに従って所望のデータをストレージから読み出し、アプリケーションに読み出したデータを返す。それに対して本実施形態では、ホストＣＰＵ２００による処理の一部をデータ転送装置１００が代行し、そのままネットワーク４００にデータを送信する。具体的な処理の流れは次のようになる。
【００３６】
図３は、第１の実施形態におけるデータ転送処理の全体の流れを示すフローチャートである。
【００３７】
まず、ファイル指定部２０１が、例えばアプリケーションソフトウェアの処理に従い送信するファイルを特定し、特定したファイルを送信データ特定部２０４に指定する（ステップＳ１０１）。典型的な例としては、ファイル指定部２０１は、ネットワーク４００に接続された他の機器から要求されたファイルを、送信するファイルとして特定する。
【００３８】
さらに、メタデータ指定部２０２が、送信データの特定に利用するメタデータを指定する（ステップＳ１０２）。
【００３９】
メタデータに含まれる特定情報は、単純には指定されたファイルの中の送信データのバイト位置を示すものでもよい。例えば、１０００バイトのファイルのうち、１０バイト目から９９バイト目、２００バイト目から２９９バイト目、および、５００バイト目から６９９バイト目の３つのデータの固まりを送信する場合を考える。この場合、特定情報は、（先頭位置，長さ）の形式の３つのデータ（１０，９０）（２００，１００）（５００，２００）を含むリストデータ形式、または、テーブル形式で表される。データが映像や音声コンテンツのストリーミングのデータである場合、特定情報は、再生時間を表わすものであってもよい。例えば、全長が２時間のコンテンツで、そのうち、開始から１０分後の時点から１５分間、および、開始から３０分後の時点から２０分間のデータを送信する場合を考える。この場合、特定情報は、（開始時間［ｓｅｃ］、時間の長さ［ｓｅｃ］）の形式の２つのデータ（６００，９００）（１８００，１２００）で表記してもよい。
【００４０】
特定情報は、例えば対向装置で視聴するユーザが指定した位置そのものでもよい。また、特定情報は、コンテンツのうちの特定の俳優が映っているシーンなどを自動抽出したような、データ送信システム側からユーザに対して視聴を推奨する位置のようなものであってもよい。
【００４１】
次に、メタデータ解析部２０３が、指定されたメタデータを解析する（ステップＳ１０３）。
【００４２】
次に、送信データ特定部２０４が、解析されたメタデータの情報をもとに、指定されたファイルから、送信データを特定する（ステップＳ１０４）。送信データ特定部２０４は、特定した送信データの位置と、送信データの長さとを含む情報、または当該情報の集合を、管理情報読み出し指示部２０５に渡す。
【００４３】
管理情報読み出し指示部２０５は、渡された送信データの情報に基づき、ストレージ３００からファイルシステムの管理情報を読み出すコマンドの発行を、データ転送装置１００のコマンド発行部１１０に指示する（ステップＳ１０５）。
【００４４】
ストレージ３００は、この指示に応じてコマンド発行部１１０から発行されたコマンドに基づき、管理情報を読み出してエクステントマップ取得部２０６に渡す（ステップＳ１０６）。
【００４５】
エクステントマップ取得部２０６は、読み出された管理情報を解析し、読み出す送信データのエクステントマップを取得する（ステップＳ１０７）。なお、エクステントマップ取得部２０６が、予めキャッシュしたエクステントマップを取得するように構成してもよい。この場合は、エクステントマップ取得部２０６が同様の手順で予めエクステントマップを読み出しておく必要がある。
【００４６】
次に、送信データ読み出し指示部２０７が、取得したエクステントマップを、データ転送装置１００に渡し、データ転送装置１００に対してそのデータの読み出しと送信を指示する（ステップＳ１０８）。
【００４７】
データ転送装置１００のコマンド発行部１１０が、送信されたエクステントマップを受け取り、受け取ったエクステントマップに従って、実際に送信データを含むブロックを読み出すべく、ストレージ３００にコマンドを発行する（ステップＳ１０９）。
【００４８】
コマンド発行部１１０は、ストレージ３００側のＩ／Ｆ仕様に従ったコマンドを発行する。通常、一度に指定できる読み出しブロック数に限りがあったり、離散的なブロックは同時に指定できなかったりなどの制限がある場合がある。このため、１つのエクステントマップが複数のコマンド群に分割される場合もある。このように、コマンド発行部１１０は、必要に応じて１つのエクステントマップに対するコマンドを分割する処理も行う。
【００４９】
コマンド発行部１１０がコマンドを順次ストレージ３００に対して発行すると、ストレージ３００からコマンドに対する応答として送信データが含まれたブロックデータが返ってくる。送信データ抽出部１３０が、ストレージ３００から返された送信データを受け取る。
【００５０】
なお、送信データ読み出し指示部２０７は、ステップＳ１０８でコマンド発行部１１０に指示を出す一方、送信データ抽出部１３０に対して、個々のコマンドで読み出されるブロックデータのどの部分に送信データが含まれているかを表す情報を渡す。すなわち、前述の図２の例では、送信データ読み出し指示部２０７は、ブロック２３５〜２３８というブロック位置情報をコマンド発行部１１０に渡し、オフセット１２４バイトおよび長さ１４５８バイトという有効データ位置情報を送信データ抽出部１３０に渡す。
【００５１】
送信データ抽出部１３０は、受け取ったブロックデータから、有効データ位置情報に従い所望のバイト数（図２の例では１４５８バイト）のデータ列を抽出し、通信処理部１４０に渡す（ステップＳ１１０）。通信処理部１４０は、必要に応じて対向装置と制御情報を送受信しながら、ネットワーク４００上に、抽出された送信データを送信する（ステップＳ１１１）。
【００５２】
次に、ストレージ３００とのＩ／Ｆ処理についてより詳しく説明する。まず、ストレージ３００が典型的なＳＳＤやＨＤＤなどのＳＡＴＡ Ｉ／Ｆを備え、さらにバスマスターとしての機能（ＤＭＡ機能）を備える場合について説明する。この場合、コマンド発行部１１０は、例えばストレージ３００へのコマンドとして、デスクリプタと呼ばれるコマンドを記述したデータを、所定のメモリ上に用意しておく。ストレージ３００はコマンドを当該メモリから読み出す。このようにしてコマンド発行部１１０が発行したコマンドがストレージ３００に受け渡される。
【００５３】
デスクリプタは通常リングバッファ形式になっており、典型的な公知の技術ではホストＣＰＵ２００が使用するメインメモリ（主記憶装置、不図示）上に置かれる。本実施形態でも同じ形態をとってもよいが、データ転送装置１００内のメモリ、または、データ転送装置１００に直接接続されるメモリを用いることが、メインメモリやホストＣＰＵ２００に負荷を与えないという点で望ましい。
【００５４】
ストレージ３００が読み出したブロックデータをＤＭＡで書き込む宛先アドレスも、それぞれのデスクリプタに予め指定される。ストレージ３００から読み出した管理情報はホストＣＰＵ２００に渡し、送信データは通信処理部１４０に渡すといった振り分けは、このアドレス指定によって実現する。すなわち、管理情報をホストＣＰＵ２００に渡す場合は、通常はメインメモリを介して行うので、デスクリプタに記載する宛先アドレスにメインメモリのアドレスを記載する。送信データを送信データ抽出部１３０に渡す場合は、宛先アドレスに送信データ抽出部１３０のアドレスを記載する。これによって、ストレージ３００がデスクリプタによって指定された宛先アドレスに読み出したデータを書き込むだけで、読み出したデータをそれぞれに振り分けることができる。
【００５５】
ストレージ３００は、コマンドを実行してデータを読み出した後に、通知振り分け部１２０に対してコマンド完了通知を行う。ストレージ３００は、例えば割り込みなどによって完了通知を行う。より具体的には、ストレージ３００は、例えばどこまでコマンドを処理したか、すなわち、リングバッファのデスクリプタ群のどのデスクリプタまで処理したかを、各デスクリプタの処理完了を示すＤＯＮＥビットをセットするなどにより通知する。
【００５６】
通知振り分け部１２０は、割り込み通知を受けると、このＤＯＮＥビットが書かれているデスクリプタを順次読み出し（読み出した後はＤＯＮＥビットをリセットする）、そのデスクリプタまで処理が完了していることを判断できる。なお、一度に複数のデスクリプタの処理が完了している場合もあり得る。
【００５７】
通知振り分け部１２０は、管理情報の読み出しに用いられるデスクリプタの完了通知を受けた場合は、管理情報読み出し指示部２０５に完了通知を振分ける。また、通知振り分け部１２０は、送信データの読み出しに用いられるデスクリプタの完了通知を受けた場合は、送信データ読み出し指示部２０７に完了通知を通知する。このようにして通知振り分け部１２０は完了通知をそれぞれに振り分ける。
【００５８】
管理情報読み出し指示部２０５は、通知振り分け部１２０から完了通知を受けると、管理情報の読み出しが完了したと判断し、エクステントマップ取得部２０６にエクステントマップの取得を指示する。
【００５９】
ストレージ３００によるブロックデータの転送には、通常は一定のレイテンシが存在する。このため、ホストＣＰＵ２００は、転送指示に対するストレージ３００からの完了通知を毎回待たずに、複数のブロックの読み出しをまとめて指示する場合がある。その場合、そのままでは送信データ読み出し指示部２０７（および管理情報読み出し指示部２０５）とストレージ３００と送信データ抽出部１３０との３者の間で同期が取られなくなる。このため、例えば以下の手法により同期を行う。
【００６０】
１つ目の手法は、ストレージ３００がコマンドを受けた順番と必ず同じ順番で読み出しを実行する場合に有効な手法である。この手法では、送信データ読み出し指示部２０７がストレージ３００からの複数のブロックの読み出しを指示するとき、その指示と同じ順番で、対応するブロックの中の有効データ位置情報を送信データ抽出部１３０に通知する。送信データ抽出部１３０は、受け取った有効データ位置情報を例えばキューイングしておく。送信データ抽出部１３０は、ストレージ３００からブロックデータを受け取った際、キューイングした有効データ位置情報をキューイングした順番に１つずつ取り出せば、ブロックデータとの対応付けができる。
【００６１】
２つ目の手法は、ストレージ３００が、内部処理の効率等を優先する場合等で、コマンドを受けた順番とは異なる順番で読み出しを実行し得る場合の手法である。この場合は、例えば各ブロックの宛先アドレスとして異なるアドレスを指定する手法等が考えられる。
【００６２】
例えば８個の読み出しコマンドをストレージ３００にまとめて指示する場合、送信データ読み出し指示部２０７は、８個のコマンドごとに異なる転送先アドレスを指定しておく。上述のように本実施形態では、転送先のアドレスに送信データ抽出部１３０のアドレスを指定する。２つ目の手法を適用する場合は、例えば１つのコマンドで最大４つのブロックの読み出し指示を出す場合、各コマンドに対応する転送先アドレスとして、それぞれ送信データ抽出部１３０のアドレス領域のうちの異なるアドレス領域を指定しておく。
【００６３】
図４は、コマンドとアドレス領域との対応の一例を示す図である。図４は、送信データ抽出部１３０のアドレス領域が０ｘ２０２０００００〜０ｘ２０２ｆｆｆｆｆの場合の例を示している。コマンド番号は、コマンドを識別する情報である。図４に示すように、０ｘ２０２０００００〜０ｘ２０２００７ｆｆの５１２×４バイト領域がコマンド０に対応し、０ｘ２０２００８００〜０ｘ２０２００ｆｆｆの５１２×４バイト領域がコマンド１に対応し、０ｘ２０２０１０００〜０ｘ２０２０１７ｆｆの５１２×４バイト領域がコマンド２に対応するというように、コマンドとアドレス領域とを予め対応付けておく。送信データ読み出し指示部２０７は、発行するコマンドに対して、対応するアドレス領域の先頭を指定するようにコマンド発行部１１０に指示する。
【００６４】
これにより、転送されたブロックデータは、送信データ抽出部１３０の中の異なるアドレス領域に転送される。送信データ抽出部１３０は、受けたブロックデータが例えば０ｘ２０２０１２００から始まるアドレスに書き込まれたデータであれば、当該データはコマンド２の先頭から２番目のブロックデータであることが特定できる。また、例えばコマンド２で読み出されるブロックデータに対して図２に示す有効データ位置情報が通知されている場合、このブロックデータは有効データの３８９バイト目から９００バイト目のデータであることが分かる。
【００６５】
送信データ読み出し指示部２０７は、送信データ抽出部１３０に対して８個の有効データ位置情報を通知する。その際、送信データ読み出し指示部２０７は、コマンド０に対応する有効データ位置情報、コマンド１に対応する有効データ位置情報、コマンド２に対する有効データ位置情報・・・、などのように、有効データ位置情報がいずれのコマンドに対応するかを特定できるように通知する。
【００６６】
このような構成により、送信データ抽出部１３０は、受けたブロックデータ、および、有効データ位置情報がともに、いずれのコマンドに対するものかを判別できる。すなわち、送信データ抽出部１３０は、コマンドと、ブロックデータおよび有効データ位置情報との対応付けが可能となる。
【００６７】
このように、ブロックデータの宛先アドレス領域を分けることによって、送信データ抽出部１３０が受け取ったブロックデータの順番がもとのデータ列の順番（通常はネットワークに送信する順番）と異なる場合でも、ブロックデータの宛先アドレスを確認することで、そのデータがどのコマンドに基づくデータかが判断できるので、それをもとにデータ列を元の順番に並び替えることが可能となる。
【００６８】
なお、アドレスを使うことは本実施形態の一例である。ブロックデータを特定可能な情報であれば、アドレス以外のどのような情報を用いてもよい。また、以上のストレージ３００Ｉ／Ｆの詳細は一例であり、これに限られるものではない。
【００６９】
ストレージ３００が内部エラー等の何らかの理由により、要求されたコマンドの実行を完了できない場合がある。この場合、ストレージ３００は、データ転送装置１００にエラー通知を行う。このままではホストＣＰＵ２００はエラーの情報を得られないので、このような場合に、データ転送装置１００がホストＣＰＵ２００にエラー通知を中継して従来通りホストＣＰＵ２００も異常を知ることができるように構成してもよい。
【００７０】
また、通知振り分け部１２０は必ずしもデータ転送装置１００上に構成する必要はなく、ホストＣＰＵ２００上に構成してもよい。また、コマンド発行部１１０もその一部の処理をホストＣＰＵ２００側で行ってもよい。ただし、１つの送信データ読み出し指示を複数のコマンドに分割する処理はデータ転送装置１００上で行う方が処理効率の面で望ましい。
【００７１】
このように、第１の実施形態にかかるデータ転送装置では、アプリケーションからの要求に基づき、ホストＣＰＵ２００にデータ転送処理の負荷を与えることなくストレージ３００上のデータをネットワーク４００に送信することができる。従って、処理効率が向上し、データ転送速度を向上させることができる。また、ホストＣＰＵ２００、ホストＣＰＵ２００に付随するチップセット、メモリ、およびマザーボードなどのグレードを下げることができるので、装置の低コスト化を図ることができる。また、データ転送の大部分の処理をホストＣＰＵ２００のソフトウェア処理ではなくデータ転送装置１００のハードウェア処理で実行することが可能となるので、低消費電力化を図ることができる。
【００７２】
（第２の実施形態）
第２の実施形態は、データ転送用に複数の通信コネクションが設定され、コネクションごとに独立してフロー制御を行う例を示している。例えばＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）のようなネットワークストレージ、ＶＯＤサーバに接続される複数のクライアント端末、または、クライアント端末上の複数のアプリケーションから、同時に読み出し要求やコンテンツ配信要求を受けた場合などに、複数の独立したコネクションでストレージからデータを読み出してネットワークに送信する動作を可能とする。
【００７３】
図５は、第２の実施形態に係るデータ送信システムの概略構成例を示すブロック図である。
【００７４】
図５に示すように、第２の実施形態のホストＣＰＵ２００−２は、ファイル指定部２０１と、メタデータ指定部２０２と、メタデータ解析部２０３と、送信データ特定部２０４−２と、管理情報読み出し指示部２０５−２と、エクステントマップ取得部２０６と、送信データ読み出し指示部２０７−２と、を備えている。
【００７５】
第２の実施形態では、送信データ特定部２０４−２、管理情報読み出し指示部２０５−２、および送信データ読み出し指示部２０７−２の機能が第１の実施形態と異なっている。その他の構成および機能は、第１の実施形態のブロック図である図１と同様であるので、同一符号を付し、ここでの説明は省略する。
【００７６】
送信データ特定部２０４−２および管理情報読み出し指示部２０５−２は、コネクションごとに処理を実行する点が、第１の実施形態と異なっている。送信データ読み出し指示部２０７−２は、コネクションを識別するコネクション識別情報とともに、データの読み出しを指示する点が、第１の実施形態と異なっている。
【００７７】
第２の実施形態のデータ転送装置１００−２は、コマンド発行部１１０と、通知振り分け部１２０と、送信データ抽出部１３０−２と、通信処理部１４０−２と、フロー制御部１５０−２と、バッファ管理部１６０−２と、データバッファ１７０−２と、を備えている。
【００７８】
第２の実施形態では、フロー制御部１５０−２とバッファ管理部１６０−２とデータバッファ１７０−２とを追加したこと、および、送信データ抽出部１３０−２と通信処理部１４０−２の機能が第１の実施形態と異なっている。その他の構成および機能は、第１の実施形態のブロック図である図１と同様であるので、同一符号を付し、ここでの説明は省略する。
【００７９】
データバッファ１７０−２は、送信データ抽出部１３０−２と通信処理部１４０−２との間のデータの受け渡しのためにコネクションごとにデータをバッファリングする。以下では、データバッファ１７０−２内のコネクションごとのデータを記憶する領域を、単にバッファという場合がある。
【００８０】
バッファ管理部１６０−２は、データバッファ１７０−２のコネクションごとの状態（バッファ状態）を管理する。フロー制御部１５０−２は、バッファ管理部１６０−２からの通知に基づいてコネクションごとのデータのフロー制御を行う。図５では、フロー制御情報の伝達は太い破線で表わしている。
【００８１】
送信データ抽出部１３０−２は、抽出した送信データをデータバッファ１７０−２に記憶する点が、第１の実施形態と異なっている。通信処理部１４０−２は、バッファ管理部１６０−２により管理されるバッファ状態に応じて、データバッファ１７０−２から送信データを読み出す点が、第１の実施形態と異なっている。
【００８２】
図６は、第２の実施形態におけるデータ転送処理の全体の流れを示すフローチャートである。
【００８３】
ステップＳ２０１からステップＳ２０７までは、第１の実施形態のデータ転送処理を示す図３のステップＳ１０１からステップＳ１０７までと同様の処理なので、その説明を省略する。
【００８４】
本実施形態では、送信データ読み出し指示部２０７−２が、取得したエクステントマップとともに、コネクション識別情報をデータ転送装置１００−２に渡し、データ転送装置１００−２に対してそのデータの読み出しと送信を指示する（ステップＳ２０８）。送信データ読み出し指示部２０７−２は、例えば、アプリケーションから受け取ったコネクション識別情報をデータ転送装置１００−２に渡す。
【００８５】
データ転送装置１００−２では、フロー制御部１５０−２がデータの読み出しの指示を受ける。フロー制御部１５０−２は、コネクションごとにエクステントマップを保持する。すなわち、フロー制御部１５０−２は、複数のコネクションのデータ読み出し要求を一旦保持しておく。そして、バッファ管理部１６０−２からバッファに空きがあるコネクションの通知を受けると、フロー制御部１５０−２は、通知を受けたコネクションの送信データの読み出しコマンドの発行をコマンド発行部１１０に対して指示する。
【００８６】
コマンド発行部１１０は、フロー制御部１５０−２から受け取ったエクステントマップに従って、送信データを含むブロックを読み出すための読み出しコマンドを発行する（ステップＳ２０９）。ステップＳ２１０は、第１の実施形態のステップＳ１１０と同様の処理なので、その説明を省略する。
【００８７】
第２の実施形態では、送信データ抽出部１３０−２は、ブロックデータから抽出した送信データを、データバッファ１７０−２に記憶する（ステップＳ２１１）。また、通信処理部１４０−２は、データバッファ１７０−２から送信データを読み出してネットワーク４００に送信する（ステップＳ２１２）。
【００８８】
初期状態では全てのコネクションのバッファは空いているので、フロー制御部１５０−２は、そのままコマンド発行部１１０に送信データの読み出しを指示することになる。同じコネクションのデータの送信が連続して要求されると、フロー制御部１５０−２が要求を一旦保持し、バッファ管理部１６０−２からのバッファ空き通知を待つ状況になる場合がある。
【００８９】
コマンド発行部１１０に一度にコマンド発行を要求するデータのサイズは、バッファの空きサイズ（空き容量）以下でなければならない。一例として、データバッファ１７０−２のコネクションごとのバッファが１２８ＫＢずつ確保され、バッファ管理部１６０−２がいずれかのコネクションで６４ＫＢ以上バッファに空きが生じたら、そのコネクションのバッファ空きをフロー制御部１５０−２に通知するものとする。
【００９０】
ホストＣＰＵから渡されたエクステントマップが、これより大きいサイズのデータを示している場合も当然ながらあり得る。しかし、フロー制御部１５０−２が一度にコマンド発行を要求可能なデータのサイズは空いた分の６４ＫＢ以下のサイズの部分データである。このため、フロー制御部１５０−２は、この部分データの読み出しをコマンド発行部１１０に要求する。同時にフロー制御部１５０−２は、この部分データの中の有効データ位置情報を送信データ抽出部１３０−２に渡す。そして、フロー制御部１５０−２は、読み出し処理を完了した部分データの位置を進捗情報としてコネクションごとに保持し、一旦コマンド発行要求を終える。
【００９１】
以上の処理を、図７を用いて説明する。図７は、エクステントマップの構成例を示す図である。図７は、ブロック位置情報としてブロック２３５〜１０００、有効データ位置情報としてオフセット１２４バイト、長さ３９１６０２バイトを表すエクステントマップをホストＣＰＵ２００−２から与えられた例を示している。この場合、最初の部分データは、例えば６４ＫＢ以下の切りの良いところとしてブロック２３５〜３６２の６５４１２バイトとなる。そして、この部分データの有効データ位置情報は、オフセット１２４バイト、長さ６５４１２バイトである。フロー制御部１５０−２は、ブロック２３５〜３６２の読み出しコマンドの発行をコマンド発行部１１０に要求する。フロー制御部１５０−２は、同時に送信データ抽出部１３０−２にオフセット１２４バイト、長さ６５４１２バイトという有効データ位置情報を渡す。フロー制御部１５０−２は、進捗情報として次回処理するブロックはブロック３６３、または、６５４１３バイト目、という情報を保持し、一旦処理を終える。フロー制御部１５０−２は、バッファ管理部１６０−２からの次のバッファ空き通知を待つ。
【００９２】
なお、以上で述べた６４ＫＢなどの各種データサイズは一例であり、この例に限られるものではない。また、データサイズは一定である必要もなく、サイズが毎回変わる場合も本実施形態を適用できる。
【００９３】
一旦部分データの処理を終え、その後に他のコネクションのデータバッファが空いたという通知をバッファ管理部１６０−２から受けると、フロー制御部１５０−２は、通知を受けたコネクションに対して同様に部分データの読み出し要求処理を行う。そして、あるコネクションに関して与えられたエクステントマップが示すデータの全てを送信し終える（図７の場合は６番目の部分データの読み出し要求を完了する）と、そのコネクションの与えられたエクステントマップが示すすべてのデータの送信が完了となる。フロー制御部１５０−２は、すべてのデータの送信が完了した旨をホストＣＰＵ２００−２に通知する。
【００９４】
ホストＣＰＵ２００−２では、例えば管理情報読み出し指示部２０５−２がこの通知を受け取り、次のアプリケーションからのデータ送信処理、すなわち管理情報読み出し指示部２０５−２から始まる一連の処理を実行可能とする。逆に、この通知を受けるまで、管理情報読み出し指示部２０５−２が次の管理情報の読み出しを一旦保留することで、送信データ特定部２０４−２との間のフロー制御を実現する。
【００９５】
なお、ホストＣＰＵ２００−２がこの通知を受けるのは必ずしも管理情報読み出し指示部２０５−２である必要はない。例えば、エクステントマップ取得部２０６、または、送信データ読み出し指示部２０７−２でもよい。すなわち、最終的にアプリケーションに対してバックプレッシャが伝達されるようになっていれば、いずれの構成部が通知を受けてもよい。
【００９６】
また、以上の例ではデータ転送装置１００−２がコネクションごとに同時に１つしかエクステントマップを受け付けない例を示したが、２つ以上のエクステントマップを受け付けるように構成してもよい。複数のエクステントマップを受け付ける構成であっても、エクステントマップは必ず有限個になる。従って、エクステントマップの最大個数を受け付けた際にそれ以上のエクステントマップを受けられないような仕組みを備えることにより、前述の方式を適用できる。
【００９７】
送信データ抽出部１３０−２は、前述のとおり有効データ位置情報をフロー制御部１５０−２から受け取り、有効データ位置情報に従って抽出した送信データをデータバッファ１７０−２に書き込む。データバッファ１７０−２に書き込む際の宛先アドレスは、フロー制御部１５０−２が生成し、送信データ抽出部１３０−２に渡す。
【００９８】
例えば、データバッファ１７０−２が前述の説明同様にコネクションごとに１２８ＫＢ確保されており、コネクションごとのバッファの先頭アドレスが以下のように割り当てられているものとする。
コネクション０のバッファの先頭アドレス＝０ｘ００００００００
コネクション１のバッファの先頭アドレス＝０ｘ０００２００００
コネクション２のバッファの先頭アドレス＝０ｘ０００４００００
【００９９】
また、現在コネクション１を処理しており、図７に示すデータの読み出しが初めて要求されたとする。この場合、最初の部分データの宛先アドレスは０ｘ０００２００００となり、次の部分データの宛先アドレスは６５４１３バイト加えた０ｘ０００２ｆｆ８５となる。
【０１００】
このように宛先アドレスを部分データのサイズごとに増加させていくと、データバッファ１７０−２にはもとの通り一連のデータとして展開される。また、バッファが例えばバイト単位のリングバッファであるとすると、０ｘ０００３ｆｆｆｆの次のバイトは０ｘ０００２００００に書き込むことになる。
【０１０１】
フロー制御部１５０−２は、送信データ抽出部１３０−２に対し、有効データ位置情報と共に、このような宛先アドレスを渡す。送信データ抽出部１３０−２は、抽出した送信データを、宛先アドレスに従ったアドレスから書き込む。これにより、データバッファ１７０−２にコネクションごとに適切に送信データを展開することができる。
【０１０２】
バッファ管理部１６０−２は、データバッファ１７０−２のコネクションごとのバッファのデータの供給側の書き込み位置と、データの消費側の読み出し位置と、コネクションごとのバッファの空き状態とを管理する。
【０１０３】
例えば、コマンド発行部１１０に部分データの読み出し要求を行い、ストレージ３００から読み出し要求に対する応答通知が返ってくると、フロー制御部１５０−２は、当該コネクションのバッファのどの位置までデータが書き込まれたかを判別できる。このため、フロー制御部１５０−２は、データが書き込まれた位置を進捗情報としてバッファ管理部１６０−２に通知する。
【０１０４】
例えば、図７の最初の部分データを書きこみ終わった際、フロー制御部１５０−２は、６５４１３バイトという情報をコネクション識別情報とともにバッファ管理部１６０−２に通知する。この通知によって、バッファ管理部１６０−２は、コネクション１のバッファのデータの供給側の位置は６５４１３バイトであると把握できる。
【０１０５】
一方、通信処理部１４０−２がデータを送信するためにデータバッファ１７０−２からデータを読み出すと、データの消費側の読み出し位置が移動する。このため、通信処理部１４０−２は、読み出し終わったバイト位置（正確には次に読み出し始めるバイト位置）をコネクションごとにバッファ管理部１６０−２に通知する。
【０１０６】
初期状態では、バッファは１２８ＫＢ（正確には２の１７乗の１３１０７２バイト）空いている。最初にデータを書き込まれると６５４１３バイト減って空きサイズが６５６５９バイトになる。これは６４ＫＢ（正確には２の１６乗上の６５５３６バイト）より大きいので、バッファ管理部１６０−２は、バッファ空き通知をフロー制御部１５０−２に送信する。
【０１０７】
これにより、フロー制御部１５０−２は、次の部分データ（図７の例では６５５３６バイト）の読み出し要求を出す。読み出し要求に応じてデータが書き込まれると、バッファサイズがさらに減って２３バイトになる。これは６４ＫＢより少ないので、バッファ管理部１６０−２はバッファ空き通知を行わない。
【０１０８】
従って、フロー制御部１５０−２は、次の部分データの読み出しを保留する。その後、通信処理部１４０−２がデータを例えば１ＫＢ（１０２４Ｂ）読み出すと、空きバッファサイズは１０４７バイトに増加する。引き続き通信処理部１４０−２がデータを読み出していき、空きサイズが６５５３６バイト以上になると、その段階でバッファ管理部１６０−２はフロー制御部１５０−２にバッファ空き通知を行う。
【０１０９】
通信処理部１４０−２は、処理している通信プロトコル仕様やネットワークの帯域などによって送信速度が制限される。例えばＴＣＰプロトコルのようにフロー制御や輻輳制御を行うような場合は、対向装置やネットワークの込み具合によって送信速度が低下し、データバッファ１７０−２からのデータの読み出しの進み具合が遅くなる。本実施形態によれば、その場合でも、適切に最上位のアプリケーションまでのフロー制御を実現することができる。逆に、対向装置が十分なデータを受け入れられる場合でも、本実施形態では、通信処理部１４０−２が現在のデータ供給側の位置を参照して、どの位置までデータを送信可能か判断する。これにより、適切にバッファに充填されている分だけデータを送信するという適切な制御が可能となる。
【０１１０】
次に、通信処理部１４０−２がＲＴＰのようなリアルタイム通信プロトコルを用いる場合の具体的な構成例を説明する。図８は、第２の実施形態の通信処理部１４０−２の構成例を示すブロック図である。
【０１１１】
図８に示すように、通信処理部１４０−２は、送信開始指示部１４１と、パケット送信指示部１４２と、送信判定部１４３と、ヘッダ生成部１４４と、データ読み出し部１４５と、パケット生成部１４６と、送信時刻生成部１４７と、を備えている。
【０１１２】
送信開始指示部１４１は、ホストＣＰＵ２００−２からのデータ送信開始指示を受け付け、受付けた指示に応じてデータの送信開始要求をパケット送信指示部１４２に送信する。パケット送信指示部１４２は、送信開始要求を受けると、その後のパケットごとの送信指示を行う。送信判定部１４３は、送信処理の各種判定処理を行う。ヘッダ生成部１４４は、パケットのヘッダを生成する。データ読み出し部１４５は、データバッファ１７０−２からパケットのデータ部分（ペイロード）を読み出す。パケット生成部１４６は、
生成されたヘッダと読み出されたデータに基づきパケットを生成する。送信時刻生成部１４７は、読み出されたデータを含むパケットの次に送信するパケット（次パケット）の送信時刻を生成する。
【０１１３】
具体的な動作は次のようになる。まず、ホストＣＰＵ２００−２は、パケット送信を開始するコネクションのコネクション識別情報を指定して、送信開始指示を送信開始指示部１４１に対して通知する。送信開始指示部１４１は、パケット送信指示部１４２に対して最初のパケットの生成を要求する。
【０１１４】
パケット送信指示部１４２は、内部にタイマーを持ち、例えば２７ＭＨｚ・３２ビットの現在のタイマーカウント値（すなわち現在時刻）を常に更新している。パケット送信指示部１４２は、コネクションごとに次パケットの送信時刻を例えばテーブル形式で保持する。パケット送信指示部１４２は、テーブルから送信時刻を順次読み出して現在のタイマーカウント値と比較し、現在時刻を越えていたらそのコネクションのパケット生成を指示する。
【０１１５】
例えばコネクション１とコネクション３が存在し、コネクション１のパケットの送信時刻として０ｘ４０００００００が保持され、コネクション３のパケットの送信時刻として０ｘ４００００１００が保持されているものとする。この場合、現在のタイマーカウント値が０ｘ３ｆｆｆｆｆｆｆまでのときは、パケット送信指示部１４２は、パケット生成を指示しない。現在のタイマーカウント値が０ｘ４０００００００になったときに、パケット送信指示部１４２は、コネクション１のパケット送信を指示する。現在のタイマーカウント値が０ｘ４００００１００になったときに、パケット送信指示部１４２は、コネクション３のパケット送信を指示する。
【０１１６】
送信判定部１４３は、パケット送信の指示に基づいてパケットの送信判定を行う。例えば、送信判定部１４３は、バッファ管理部１６０−２から現在のデータの供給側の書き込み位置を取得し、その位置が今回のパケット送信で読み出されるデータの終端を超えているか否かを判断する。超えている場合は、送信判定部１４３は、送信すべきデータが既に準備できているということを意味するので送信可能であると判定する。送信可能であると判定された場合、後段のヘッダ生成部１４４とデータ読み出し部１４５とパケット生成部１４６が動作して、パケットが送信される。
【０１１７】
送信時刻生成部１４７は、例えばデータを読み出した後に、次パケットの送信時刻を生成して、生成した送信時刻をパケット送信指示部１４２に伝える。このときに生成するパケット送信時刻は、例えば、現在送信しているデータストリームのパケット送信間隔（Ｐ［ｓｅｃ］とする）と、送信開始時点の時刻（Ｔ０［ｓｅｃ］とする）とから算出する。例えば、Ｎ番目のパケットの送信時刻はＴ０＋（Ｎ−１）×Ｐとなる。
【０１１８】
送信時刻生成部１４７が、次に送信するパケットに格納するデータの先頭バイトの、送信開始バイトからのバイトオフセット（ＯＦＳ［Ｂｙｔｅ］とする）と、データストリームのビットレート（ＢＲ［Ｂｙｔｅ／ｓｅｃ］とする）とから、Ｔ０＋ＯＦＳ／ＢＲにより送信時刻を算出してもよい。
【０１１９】
これらは本質的に同等の算出方法である。また、以上の例では簡単のため時間の単位を［ｓｅｃ］としたが、前述した２７ＭＨｚのクロックカウンタの単位で扱ってもよい。
【０１２０】
一方で、バッファ管理部１６０−２から現在のデータの供給側の書き込み位置が今回のパケット送信で読み出されるデータの終端を超えていない場合は、送信判定部１４３は、送信すべきデータが未だ準備されていないということを意味するので送信できないと判定する。この場合、送信が指示されたパケットの送信は取りやめる。
【０１２１】
そして、送信判定部１４３は、送信時刻生成部１４７に対して次パケットの送信時刻を生成するように指示を出す。このときに生成するパケット送信時刻は、例えば、現在の時刻に対し、前述のパケット送信間隔Ｐを足した時刻としてよいし、それ以外の所定の時刻としてもよい。さらに、ホストＣＰＵ２００−２からの設定によっては、この送信データが準備できていないいわゆるバッファアンダーフロー状態を、異常状態としてホストＣＰＵ２００−２に通知する処理を行ってもよい。この場合、ホストＣＰＵ２００−２は、例えば通知されたエラーをログに出力するなど異常系の処理を行ってもよい。
【０１２２】
また、送信しているデータが例えばＭＰＥＧのＴＴＳ（Ｔｉｍｅｓｔａｍｐｅｄ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）パケット（４バイトタイムスタンプ値＋１８８バイトＴＳパケットの合計１９２バイト）を含む送信パケットの場合、送信パケットの送信時刻は、その送信パケットに格納されている先頭のＴＴＳパケットのタイムスタンプ値を用いる。
【０１２３】
例えば１つの送信パケットに７つのＴＴＳパケットを格納して送信し、送信を開始するＴＴＳパケットをＴＴＳ０とするものとする。この場合、ＴＴＳ０〜６が１つ目の送信パケットに格納され、ＴＴＳ７〜１３が２つ目の送信パケットに格納され、ＴＴＳ１４〜２０が３つ目の送信パケットに格納され、各送信パケットが送信される。このときの各送信パケットの送信時刻は、１つ目の送信パケットはＴＴＳ０のタイムスタンプ値、２つ目の送信パケットはＴＴＳ７のタイムスタンプ値、３つ目の送信パケットはＴＴＳ１４のタイムスタンプ値、にそれぞれ基づいた値となる。
【０１２４】
具体的には、１つ目のパケットの送信時刻をＴ０、Ｎ番目のＴＴＳパケットのタイムスタンプ値をＴＭＳ（Ｎ）と表わすと、２つ目の送信パケットの送信時刻はＴ０＋ＴＭＳ（７）−ＴＭＳ（０）、３つ目の送信パケットの送信時刻はＴ０＋ＴＭＳ（１４）−ＴＭＳ（０）となる。
【０１２５】
従って、例えば２つ目の送信パケットの送信時刻を生成するときは、送信時刻生成部１４７は、１つ目のパケットのデータであるＴＴＳ０〜ＴＴＳ６のデータ（１９２バイト×７＝１３４４バイト）を読み出した後にさらにＴＴＳ７の先頭のタイムスタンプ値（４バイト）も読み出す。また、例えば３つ目の送信パケットの送信時刻を生成するときは、送信時刻生成部１４７は、２つ目の送信パケットのデータであるＴＴＳ７〜ＴＴＳ１３を読み出した後にさらにＴＴＳ１４の先頭のタイムスタンプ値も読み出す。送信時刻生成部１４７は、このようにして読み出したタイムスタンプ値をもとに次のパケット送信時刻を求める。
【０１２６】
さらに、このタイムスタンプ値の読み出しは、直前のデータ読み出しと隙間なく連続して行うように構成してもよい。例えば、１３４４バイト＋４バイト＝１３４８バイトを一括して読み出すように構成してもよい。これにより、バッファへのメモリアクセスのオーバーヘッドを軽減することができる。
【０１２７】
図９は、ＴＴＳ０〜ＴＴＳ７のデータの並びを例示する図である。図９の斜線部分は、各ＴＴＳの４バイトのタイムスタンプ値の部分を表す。ＴＴＳ０〜ＴＴＳ６と次のＴＴＳ７のタイムスタンプ値を併せた部分は図の矢印部分である。データ読み出し部１４５は、１つ目の送信パケットのデータ読み出し時に、この矢印で占められた領域を一括して読み出す。これにより、１つ目の送信パケットのデータ読み出しと併せて次の送信パケットの送信時刻生成に必要なＴＴＳ７のタイムスタンプ値を読み出すことができるため、処理の効率化が図れる。
【０１２８】
なお、以上のＲＴＰ系の通信プロトコルの場合においても、例えばデータ読み出し部１４５がデータの読み出しを完了した時点で、前述の通り読み出し終わった部分を進捗情報としてバッファ管理部１６０−２に伝える。例えば、データ読み出し部１４５は、読み出しの最後のタイムスタンプ値の部分は含めない位置を通知する。図９の場合は、データ読み出し部１４５は、ＴＴＳ６の終端位置を通知する。データ読み出し部１４５が読み出しの最後のタイムスタンプ値の部分を含めた位置を読み出し済みとして通知するように構成してもよい。ただし、タイムスタンプ値はもう読み出せないことを意味する。従って、この構成の場合、例えば図９の例では、次の送信パケットのデータ読み出しまで、読み出した最後のタイムスタンプ値を保持しておく必要がある。そして、データ読み出し部１４５は、２つ目の送信パケットのデータを読み出すとき、保持したタイムスタンプ値の次のデータから読み出しを行い、保持したタイムスタンプ値と読み出したデータとをマージしてパケット生成部１４６に渡すことになる。
【０１２９】
このように、第２の実施形態にかかるデータ転送装置では、第１の実施形態の効果に加えて、通信速度が遅くなっても適切にフロー制御を行うことができるようになる。また、第２の実施形態では通信コネクションごとにフロー制御を行うことができる。このため、あるコネクションのデータフローが止まっていても、それ以外のコネクションのデータフローには影響を与えないように動作することが可能である。
【０１３０】
（第３の実施形態）
第３の実施形態では、より複雑な動作例として、トリックプレイ向け送信とＦＥＣパケット送信について説明する。トリックプレイとは、早送り、巻き戻しなど通常再生とは異なる再生のことを指す。例えばＲＴＰを用いたリアルタイム通信ベースのＩＰＴＶ向けＶＯＤサーバでは、トリックプレイによる再生に対応したストリームの送信が必要となる。
【０１３１】
図１０は、トリックプレイ向け送信の動作概要を示す図である。図１０の１段目は標準的なＭＰＥＧのＧＯＰ構造（Ｉフレーム、Ｂフレーム、Ｐフレームの並び）の一例を示している。２段目はＧＯＰの並びの一例を示している。図１０の例では、０．５ｓｅｃごとにＧＯＰが構成されている。
【０１３２】
トリックプレイでは、早送りなどにより速い速度での再生が指定されたときに、コンテンツの加工等を行わずにそのまま速く再生すると、機器自体の処理速度をその分だけ速くしなくてはならず、コストが高くなる。このため、実際には再生する映像を間引くということを行っている。
【０１３３】
具体的には、ＭＰＥＧストリームデータのＩフレームだけを抽出して再生する。例えばＩフレームが０．５ｓｅｃ間隔で登場する場合、０．２５秒間隔で再生すると２倍速になる。さらに、Ｉフレーム自体を２つのうち１つだけを再生する（１つおきに再生する）ように間引くことで４倍速となる。さらに間引くと８倍速および１６倍速などが実現できる。また、再生するＩフレームの順番を逆順にすると巻き戻し再生が可能となる。早送りと同様の方式で巻き戻しの２倍速、４倍速、８倍速および１６倍速などが実現できる。図１０の下半分は、１倍速（ｘ１）から３２倍速（ｘ３２）までのＩフレームの抽出規則の例を示している。トリックプレイ中、クライアント端末はこのように再生を行う。従って、ＶＯＤサーバは、Ｉフレームを抽出して、指定された通りのタイミングでクライアント端末に対して送信する必要がある。
【０１３４】
図１１は、第３の実施形態に係るホストＣＰＵ２００−３の概略構成例を示すブロック図である。図１２は、第３の実施形態に係る通信処理部１４０−３の概略構成例を示すブロック図である。データ転送装置およびストレージの構成および機能は、第２の実施形態と同様であるため説明を省略する。
【０１３５】
図１１に示すように、第３の実施形態のホストＣＰＵ２００−３は、送信要求受付部２０８−３と、コンテンツメタデータ読み出し部２０９−３と、ファイル指定部２０１−３と、コンテンツメタ―データ解析部２１０−３と、送信データ特定部２０４−３と、管理情報読み出し指示部２０５−２と、エクステントマップ取得部２０６と、送信データ読み出し指示部２０７−２と、を備えている。
【０１３６】
第３の実施形態では、送信要求受付部２０８−３とコンテンツメタデータ読み出し部２０９−３とコンテンツメタ―データ解析部２１０−３を追加したこと、メタデータ指定部２０２とメタデータ解析部２０３が削除されたこと、および、ファイル指定部２０１−３と送信データ特定部２０４−３の機能が第２の実施形態と異なっている。その他の構成および機能は、第２の実施形態のブロック図である図５と同様であるので、同一符号を付し、ここでの説明は省略する。
【０１３７】
送信要求受付部２０８−３は、クライアント端末からのトリックプレイ向け送信要求を受け付ける。送信要求には、例えば、再生するコンテンツを特定するための情報、トリックプレイの再生モード（何倍速の早送りか巻き戻しかなど）、および、再生開始位置（コンテンツの開始時からの相対時間など）などが含まれる。
【０１３８】
本実施形態では、例えば、再生開始位置やトリックプレイの再生モードが特定情報に相当する。したがって、送信要求受付部２０８−３が、特定情報を含むメタデータを指定するメタデータ指定部２０２に相当する。
【０１３９】
ファイル指定部２０１−３は、送信要求をもとに、トリックプレイを行うファイル（以下、コンテンツともいう）を特定する。なお、コンテンツの特定方法はこれに限られるものではない。例えば、ファイル指定部２０１−３が、データ送信システムの動作状態などに応じて再生するコンテンツを特定するように構成してもよい。
【０１４０】
コンテンツメタデータ読み出し部２０９−３は、トリックプレイを行うコンテンツのコンテンツメタ―データをストレージ３００から読み出す。このように、本実施形態では、コンテンツメタデータをストレージ３００に記憶する。なお、ストレージ３００以外の記憶装置にコンテンツメタデータを記憶してもよい。コンテンツメタデータは、例えばコンテンツの全てのＩフレームの開始バイト位置と長さとを含む。
【０１４１】
コンテンツメタ―データ解析部２１０−３は、読み出されたコンテンツメタデータを参照し、コンテンツのＩフレームのバイト位置を解析する。送信データ特定部２０４−３は、解析されたバイト位置の情報をもとに、特定されたコンテンツの中の送信データ（送信するＩフレーム）を特定する。
【０１４２】
図１２に示すように、第３の実施形態の通信処理部１４０−３は、送信開始指示部１４１と、パケット送信指示部１４２と、送信判定部１４３と、ヘッダ生成部１４４と、データ読み出し部１４５と、パケット生成部１４６と、送信時刻生成部１４７と、先頭判定部１４８−３と、を備えている。
【０１４３】
第３の実施形態では、先頭判定部１４８−３を追加したことが第２の実施形態と異なっている。その他の構成および機能は、第２の実施形態の通信処理部１４０−２のブロック図である図８と同様であるので、同一符号を付し、ここでの説明は省略する。
【０１４４】
先頭判定部１４８−３は、次に送信するパケットがＩフレームの先頭か否かを判定する。
【０１４５】
図１３は、第３の実施形態におけるデータ転送処理の全体の流れを示すフローチャートである。
【０１４６】
まず、送信要求受付部２０８−３が、クライアント端末からトリックプレイ送信の要求を受ける（ステップＳ３０１）。送信要求の受付は、例えばＩＰＴＶ仕様ではＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）などで実現される。送信要求受付部２０８−３は、クライアント端末から指定されたトリックプレイの再生モード、再生開始位置を送信データ特定部２０４−３に渡す。
【０１４７】
ファイル指定部２０１−３は、受付けられた送信要求をもとに、いずれのコンテンツのトリックプレイを行うか特定し、特定したコンテンツの情報を送信データ特定部２０４−３に指定する（ステップＳ３０２）。
【０１４８】
コンテンツメタデータ読み出し部２０９−３は、特定されたコンテンツに対応するコンテンツメタデータを読み出す（ステップＳ３０３）。コンテンツメタ―データ解析部２１０−３は、読み出されたコンテンツメタデータを解析して、コンテンツ中の全Ｉフレームのバイト位置を取得する（ステップＳ３０４）。コンテンツメタ―データ解析部２１０−３は、取得したバイト位置を送信データ特定部２０４−３に渡す。
【０１４９】
送信データ特定部２０４−３は、特定されたコンテンツ、および、バイト位置の情報を利用し、実際にどのＩフレームを送信するか特定する（ステップＳ３０５）。例えば、再生開始時間が１０分１５秒のとき、ＧＯＰ間隔が０．５ｓｅｃとすると、送信データ特定部２０４−３は、（６０ｘ１０＋１５）／０．５＝１２３０個目のＧＯＰから再生すると特定できる。トリックプレイの再生モードが４倍速早送りであった場合、図１０の抽出規則に従ったとすると、Ｉフレームを１つおきに送信することになる。従って、送信データ特定部２０４−３は、１２３０個目、１２３２個目、１２３４個目、１２３６個目・・・のＩフレームを送信すると特定できる。また、送信データ特定部２０４−３は、コンテンツメタ―データ解析部２１０−３による解析結果から、特定したＩフレームそれぞれのコンテンツ中のバイト位置（先頭位置と先頭位置からの長さ）を特定できる。
【０１５０】
ステップＳ３０６からステップＳ３１３までは、第２の実施形態のデータ転送処理を示す図６のステップＳ２０５からステップＳ２１２までと同様の処理なので、その説明を省略する。
【０１５１】
なお、通信処理部１４０−３の動作は第２の実施形態と基本的には同じであるが、トリックプレイではＩフレームを０．５ｓｅｃ間隔で送信しなければならないので、そのための処理が異なる。以下に詳細を説明する。
【０１５２】
まず、送信データに相当するＩフレームは複数の送信パケットで構成される。また、前述の通り、送信パケットは例えば７個などのＭＰＥＧのＴＳパケットまたはＴＴＳパケット（単位パケット）で構成される。なお、以下では主にＴＴＳパケットを用いる例を説明するが、ＴＳパケットを用いる場合にも同様に適用できる。
【０１５３】
図１４は、Ｉフレームとパケットとの関係の一例を示す図である。図１４の上段は、抽出したＩフレームがデータバッファ１７０−２上に展開されている様子を示している。先ほどの例では、Ｉフレーム０が１２３０個目のＩフレームとなり、Ｉフレーム１が１２３２個目のＩフレームとなり、Ｉフレーム２が１２３４個目のＩフレームとなる。中段は、送信パケットの構成例を示している。例えばＩフレーム０はＰＫＴ０〜ＰＫＴｎ−１のｎ個の送信パケットに分割されて送信される。下段は、ＭＰＥＧ ＴＴＳパケットの構成例を示している。例えばＰＫＴ０はＴＴＳ０〜ＴＴＳ６で構成されている。
【０１５４】
各ＴＴＳは、第２の実施形態で述べたとおり、先頭４バイトにタイムスタンプ値を格納する。同じＩフレーム内の送信パケットを送信する場合は、第２の実施形態と同様にデータ読み出し部１４５が、タイムスタンプ値を読み出す。そして、送信時刻生成部１４７が、次パケットの送信時刻を求めるように動作する。
【０１５５】
一方、前述の通り、次のＩフレームは例えば０．２５ｓｅｃ後という時刻に定められている。従って、次パケットがＩフレームの先頭であった場合、送信時刻生成部１４７は、読み出したタイムスタンプ値とは関係なく、次パケットの送信時刻を、先のＩフレームの先頭となる送信パケット（図１４の場合はＰＫＴ０）を送信した時刻から、０．２５ｓｅｃ後に設定する。
【０１５６】
先頭判定部１４８−３は、このような動作を実現するために、次に送信するパケットがＩフレームの先頭か否かを判定するために用いられる。具体的には、まず、データ読み出し部１４５が、タイムスタンプ値にさらに続いてＴＳパケットのヘッダ（ＴＳヘッダ）を読み出すように構成する。先頭判定部１４８−３は、例えば読み出されたＴＳヘッダのＰＥＳの先頭を示すｐａｙｌｏａｄ＿ｕｎｉｔ＿ｓｔａｒｔ＿ｉｎｄｉｃａｔｏｒが１になっているかを確認する。コンテンツに映像以外のＴＳパケットも含んでいる場合は、先頭判定部１４８−３が、さらにＰＩＤがＶＩＤＥＯを示していることも併せて確認してもよい。
【０１５７】
図１４ではＴＴＳｘにてＩフレームの先頭が現れることが示されている。以上のＩフレーム先頭判定によって、同じＩフレーム内では通常再生と同様の短い間隔で送信パケットを送信しながら、次のＩフレームは０．２５ｓｅｃなど所定の長い時間間隔を空けて送信するという機能が実現できる。従って、例えばＩＰＴＶトリックプレイ向け送信に必要な断続的なＩフレームの送信が可能となる。なお、Ｉフレーム間隔はシステム仕様やコンテンツなどに依存する。従って、上記のＩフレーム間隔の０．５ｓｅｃという時間は一例でありこれに限られるものではない。
【０１５８】
以上のように、本実施形態では、ホストＣＰＵ２００−３が、図１０のようなＭＰＥＧデータから、再生に必要なＩフレームだけを抽出して、図１４で示したようなデータを、データ転送装置１００に渡す。したがって、データ転送装置１００は、トリックプレイを実現するために、Ｉフレームの先頭を検出して、パケットを送信するという処理をするだけでよい。すなわち、トリックプレイをする場合にも、データ転送装置１００は非常にシンプルな処理だけをすればよく、データ転送装置１００の構成をシンプルにできるという効果がある。
【０１５９】
次に、ＦＥＣパケットの送信を行う場合について説明する。ＦＥＣとは、送信するデータパケットに冗長データパケットを付加して、一部のデータパケットがネットワークの途中経路で損失した場合に、損失しなかった残りのデータパケットとその冗長データパケットを用いて、損失したデータパケットを復元する手法である。具体的には、データパケットＡ、Ｂ、Ｃを送信する場合、例えばＸ＝Ａ ｘｏｒ Ｂ ｘｏｒ Ｃのようにデータのペイロードをビット単位でＸＯＲして求めたデータパケットＸも併せて送信する。送信した結果、データパケットＢが損失した場合、受信側では、残りのデータパケットＡ、Ｃ、およびＸからＢ＝Ａ ｘｏｒ Ｃ ｘｏｒ ＸとしてデータパケットＢを復元することができる。ただし、データパケットＢとデータパケットＡなどのように２つのデータパケットを損失した場合などは復元することができない。
【０１６０】
ＩＰＴＶの場合もこのＦＥＣを応用してデータ（映像および音声データ）の損失を補うことがＰｒｏ−ＭＰＥＧ仕様により定められている。Ｐｒｏ−ＭＰＥＧでは、データパケットはＲＴＰパケットで送信される。例えば上記データパケットＡ、Ｂ、ＣがそのＲＴＰパケットに相当する。パケット長は一定であると定められており、上記のｘｏｒ演算はそれぞれのデータパケットの同じオフセットのビット同士で行われる。また、実際のデータはストリームとして伝送されるので、データパケットが次々と送信される。Ｐｒｏ−ＭＰＥＧでは所定数のデータパケットをグルーピングし、グルーピングしたデータパケットごとに順次ＦＥＣパケットを生成する。
【０１６１】
図１５および図１６は、ＦＥＣパケットを生成するためのデータパケットのグルーピングの一例を示す図である。図１５および図１６は、送信されるデータパケットを１０×１０のマトリクス上に並べて表示した様子を示している。図１５および図１６は、それぞれ縦方向、横方向にデータパケットをグルーピングしてＦＥＣパケットを生成する様子を示している。図１５のＦＥＣをＣｏｌｕｍｎ ＦＥＣ、図１６のＦＥＣをＲｏｗ ＦＥＣと呼ぶ。前述のように、これらのグルーピングされたデータパケットのうち、１つだけロスト（損失）した場合に受信側での復元が可能となる。
【０１６２】
Ｃｏｌｕｍｎ ＦＥＣは縦方向にグルーピングしていることから、横方向に連続したロスト、すなわち、バーストロストに強いという特徴を持つ。Ｒｏｗ ＦＥＣはＣｏｌｕｍｎ ＦＥＣを補うものであり、ランダムロストに対する耐性を高めるものである。
【０１６３】
以上のＦＥＣパケットは、本実施形態では次のように生成される。例えば、図１６の１つ目のＲｏｗ ＦＥＣの場合、データパケット１〜１０が送信された後に最初のＲｏｗ ＦＥＣであるＦ１が送信される。送信判定部１４３は、データパケットの送信後に、データパケットの現在のマトリクス中における位置を把握し、Ｃｏｌｕｍｎ ＦＥＣとＲｏｗ ＦＥＣを送るかどうかを判定する。例えばマトリクスが１０×１０で、この中のデータパケットを０〜９９で表したとき、データパケットが９、１９、２９、・・・、９９のときにＲｏｗ ＦＥＣを送信すると判定するなどのように構成できる。
【０１６４】
Ｒｏｗ ＦＥＣを送信すると判定された場合、ヘッダ生成部１４４は、ＦＥＣパケットのヘッダを生成する。また、データ読み出し部１４５は、当該ＦＥＣが保護する全てのデータパケット０〜９のデータを読み出す。そしてパケット生成部１４６は、生成されたヘッダと、読み出された全てのデータをＸＯＲしたデータをペイロードとして、ＦＥＣパケットを生成して出力する。
【０１６５】
ところで、以上のＦＥＣパケットは、トリックプレイ中、すなわち、Ｉフレーム送信を行っている場合も同様に送信される。しかし、そのままでは次のような問題が生じる。まず、Ｉフレームのデータ長は任意であるため、例えば先に例示した送信パケットの長さである１３４４バイト（＝１９２バイト（ＭＰＥＧ ＴＴＳパケットのサイズ）×７）の倍数にならない場合も存在する。より具体的には、Ｉフレームを構成するＴＴＳ数が必ずしも７の倍数にならない場合がある。
【０１６６】
一方、ＩＰＴＶ向けトリックプレイ方式では、１つの送信パケットの中に複数のＩフレームが混在してはいけないという仕様が定められている。
【０１６７】
前述のように本実施形態では、ホストＣＰＵ２００−３がＩフレームの位置を特定し、データ転送装置内のデータバッファ１７０−２にＩフレームのデータが一旦蓄えられ、Ｉフレームが送信パケットに分割されて送信される。また、データバッファ１７０−２上には異なるＩフレームが隙間なく詰められている。従って、あるＩフレームの終端となる送信パケットを生成したとき、そのＩフレームのＴＴＳ数が７の倍数ではない場合、その終端となる送信パケットに次のＩフレームの先頭部分が含まれることになる。すなわち、１つの送信パケットに複数のＩフレームが含まれることになり、仕様違反になる。
【０１６８】
これを防ぐためには、簡単には次のような方式が考えられる。例えばパケット生成部１４６などによりＩフレームの終端となる送信パケットを生成するときに、端数の部分にＮＵＬＬ ＴＴＳを挿入し、続きのデータ（すなわち次のＩフレームの先頭データ）は次の送信パケットから送信するように構成する方式である。なお、ＮＵＬＬ ＴＴＳとは、空のデータを含むＴＴＳパケットを意味する。しかし、この方式ではＦＥＣパケットを送信する場合には依然として次のような問題が残る。
【０１６９】
ＦＥＣパケットを生成するとき、データ読み出し部１４５は、保護対象のデータを読み出す。例えば先の１つ目のＲｏｗ ＦＥＣの例では、データ読み出し部１４５は、データパケット０〜９のデータを読み出す。具体的には、データバッファ１７０−２におけるデータパケット０の先頭データのアドレスをＢＡＳＥとすると、ＢＡＳＥ＋１３４４×０、ＢＡＳＥ＋１３４４×１、ＢＡＳＥ＋１３４４×２、・・・、１３４４×９のアドレスから、それぞれ１３４４バイトずつ読み出すという動作になる。
【０１７０】
同様に、１つ目のＣｏｌｕｍｎ ＦＥＣの例では、データ読み出し部１４５は、データパケット０、１０、２０、・・・、９０のデータを読み出すことになる。すなわち、データ読み出し部１４５は、ＢＡＳＥ＋１３４４×０、ＢＡＳＥ＋１３４４×１０、ＢＡＳＥ＋１３４４×２０、・・・、ＢＡＳＥ＋１３４４×９０のアドレスからそれぞれ１３４４バイトずつ読み出す。ただし、この処理は、各データパケットが必ずデータバッファ１７０−２の１３４４バイト固定長のデータに割り当てられていることが前提である。Ｉフレームの終端でＮＵＬＬ ＴＴＳが挿入されるとその前提が崩れるため、このような簡単な計算ではデータパケットの位置が求められなくなる。例えば、データパケット５が含まれるＩフレームの終端でＮＵＬＬ ＴＴＳが２つ挿入されている場合、データパケット６以降の先頭は、ＢＡＳＥ＋１３４４×６−１９２×２となる。
【０１７１】
従って、その場合でも正しく計算するためには、ＮＵＬＬ ＴＴＳを挿入した位置を全て記憶しておき、アドレス計算時にこれを鑑みて計算する必要がある。さらに、ＦＥＣパケット生成時に読み出したＩフレームの終端となる送信パケットの長さが、（ＴＴＳのサイズ）×７の倍数ではない場合、ＮＵＬＬ ＴＴＳを付加してパケット生成部１４６に渡す必要がある。しかし、このような構成は、処理が複雑になるという問題がある。
【０１７２】
そこでホストＣＰＵを図１７のように構成することが望ましい。図１７は、このように構成した第３の実施形態の変形例に係るホストＣＰＵ２００−３Ｂの構成例を示すブロック図である。
【０１７３】
本変形例では、ホストＣＰＵ２００−３Ｂは、パケット特定部２１１−３Ｂを備える。パケット特定部２１１−３Ｂは、特定されたＩフレームの長さから、Ｉフレーム長が、（データパケットを構成するＴＴＳ数）の倍数ではない場合に、倍数となるように終端に埋めるＮＵＬＬ ＴＴＳを特定する。なお、以下では、ＴＴＳを単位としてＩフレーム長を表す。例えば、１００個のＴＴＳからなるＩフレームの長さ（Ｉフレーム長）を１００ＴＴＳと表す。Ｉフレーム長の単位はこれに限られるものではなく、例えばバイトを単位として表してもよい。
【０１７４】
例えば、Ｉフレームの長さが１００ＴＴＳであった場合、１００は７で割り切れないが、５ＴＴＳを足して１０５ＴＴＳとすることで１０５／７＝１５と割り切れるようになる。このため、パケット特定部２１１−３Ｂは、５つのＴＴＳを送信すると特定する。
【０１７５】
例えばストレージ３００上にデータパケットを構成するＴＴＳ数−１（今回は６）個分の長さのＮＵＬＬ ＴＴＳファイルを用意しておく。パケット特定部２１１−３Ｂは、読み出すデータの先頭および長さを、それぞれ、ＮＵＬＬ ＴＴＳファイルの先頭、および、必要なＴＴＳ個数分の長さ（上記例では１９２×５＝９６０バイト）として、後段のエクステントマップ取得部２０６に指定する。
【０１７６】
エクステントマップ取得部２０６は、送信するＩフレームの後にこのＮＵＬＬ ＴＴＳファイルを処理する。これにより、データバッファ１７０−２上には７ＴＴＳで割り切れないＩフレームの終端にはＮＵＬＬ ＴＴＳが挿入される。すなわち、データ転送装置は、常にＩフレームが７ＴＴＳで割り切れるものとして扱うことができる。従って、ＮＵＬＬ ＴＴＳを挿入する必要がなくなるだけでなく、ＦＥＣパケット生成の際のデータ読み出しアドレスの計算処理も容易にすることができる。
【０１７７】
なお、ＮＵＬＬ ＴＴＳの挿入は、以上の方法に限られない。例えば、ホストＣＰＵ２００−３Ｂが直接データバッファに書き込む、あるいは、ＮＵＬＬ ＴＴＳを生成する処理部をデータ転送装置内に別途設け、それによって書き込むような形態でもよい。本変形例のポイントは、Ｉフレームが７×ＴＴＳの長さで割り切れないとき、データ抽出部が、パケット特定部が特定した個数×ＴＴＳの長さを空けて、次のＩフレームのデータを書き込むことである。これによって、ＦＥＣの計算が前述のように容易になる。よって、さらにいうと必ずしもＮＵＬＬ ＴＴＳをデータバッファに書き込む必要はなく、データ抽出部が間を空けるだけ空けておき、データ読み出し部がデータを読み出した後に、空けられたところのデータ（不定値が入っている）をＮＵＬＬ ＴＴＳで置換するような形態でもよい。
【０１７８】
以上説明したとおり、第１から第３の実施形態によれば、ホストＣＰＵの処理負担を軽減させて、効率的なデータ転送が可能となる。また、コンテンツ配信サーバの主要機能であるトリックプレイ向け送信での効率的な処理が実現できる。
【０１７９】
上述した各実施形態で説明したデータ送信システムの少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、データ送信システムの少なくとも一部の機能を実現するプログラムをフレキシブルディスクやＣＤ−ＲＯＭ等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリ等の固定型の記録媒体でもよい。
【０１８０】
また、データ送信システムの少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、または記録媒体に収納して頒布してもよい。
【０１８１】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１８２】
１００ データ転送装置
１１０ コマンド発行部
１２０ 通知振り分け部
１３０ 送信データ抽出部
１４０ 通信処理部
１５０−２ フロー制御部
１６０−２ バッファ管理部
１７０−２ データバッファ
２００ ホストＣＰＵ
２０１ ファイル指定部
２０２ メタデータ指定部
２０３ メタデータ解析部
２０４ 送信データ特定部
２０５ 管理情報読み出し指示部
２０６ エクステントマップ取得部
２０７ 送信データ読み出し指示部
３００ ストレージ
４００ ネットワーク
【技術分野】
【０００１】
本発明の実施形態は、データ転送装置、データ送信システム、データ送信方法およびプログラムに関する。
【背景技術】
【０００２】
昨今、映像のストリーミング配信が普及しつつある。例えばＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）サーバと呼ばれるコンテンツ配信サーバによってストリーミング配信が行われている。このようなコンテンツ配信サーバは、自身がもつストレージから映像コンテンツを読み出し、ネットワーク接続されたユーザの端末に送信する処理を行う。通信プロトコルは、ＴＣＰ／ＩＰベースのＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）や、リアルタイム通信向けのＵＤＰ／ＩＰベースのＲＴＰ（Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）等が使われる。また、ＲＴＰの場合は誤り訂正にＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）等が使われる。
【０００３】
このようなＶＯＤサーバに用いられるストレージやネットワーク等のデバイスの高速化は著しく進んでいる。イーサネット（登録商標）は、現在１Ｇｂｐｓが主流になりつつあり、データセンター等では１０Ｇｂｐｓが使われ始めている。また、次世代の４０Ｇｂｐｓ／１００Ｇｂｐｓイーサネットの仕様策定も完了し、これらについても今後着実に普及していくものと思われる。また、ストレージに関してはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）のＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）のストライピング処理（並列化）による高速化に加えて、昨今のＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）の転送性能の向上は著しい。Ｉ／Ｆ（インタフェース）規格のＳＡＴＡ（Ｓｅｒｉａｌ Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｍｅｎｔ）に関しても、バンド幅６ＧｂｐｓのＳＡＴＡ３．０が既に普及している状況であり、単体で実効４Ｇｂｐｓ超の読み出しレートを出す製品も出てきている。
【０００４】
このようなネットワークやストレージのＩ／Ｏ性能向上に伴って、それを制御するホストＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）の処理負荷も増大していく。従来はＴＣＰ／ＩＰオフロードエンジン（以下、ＴＯＥ）という技術により、その解決が試みられてきた。ＴＯＥは、ホストＣＰＵに代行して、前述のＴＣＰ／ＩＰの処理を行う専用プロセッサや専用回路を設けたものであり、ホストＣＰＵからＴＣＰ／ＩＰ処理負荷をオフロードするものである。このＴＯＥを用いることによって、従来のソフトウェアによる通信プロトコル処理よりも高速にＴＣＰ／ＩＰ処理を行うことが可能となり、ネットワークストレージの性能向上に貢献できる。
【０００５】
ストレージやＴＯＥは、それぞれホストＣＰＵによってスレーブ的に制御され、データはメインメモリを介して入出力することが想定されている。よって、ストレージ上のデータをネットワークに入出力する際、ストレージ（ＳＳＤ、ＨＤＤ等）とＴＯＥの間のデータ転送は、通常メインメモリを介して行われる。
【０００６】
また、ホストＣＰＵ上で動作する、これらの間をブリッジするアプリケーションソフトウェア、または、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）のカーネル空間とユーザ空間のデータの受け渡し処理等により、メインメモリ上で何回分か転送データのコピーが発生する場合もある。さらにストレージにはファイルシステム処理も必要である。一般的なファイルシステムの実装では、ストレージから固定バイト長のセクタ単位で読み書きしたデータを一旦メモリ上に保持し、メモリから任意バイト長のファイルとしてのデータをアプリケーションバッファにコピーする形で渡す。このため、ファイルシステム処理でもデータのコピーが発生する。
【０００７】
さらに、コンテンツ配信サーバでは、映像コンテンツのトリックプレイ（早送り再生、巻き戻し再生など、通常再生とは異なる再生形態）に対応した送信を行う必要があり、通常のファイル転送より条件が複雑である。
【０００８】
このように、ストレージとＴＯＥの間でデータ転送を行う場合は、ホストＣＰＵのソフトウェア処理が介在することから、少なくとも一回はメインメモリへの読み書きが必要となる。また、ＯＳ、アプリケーション、および、ファイルシステムの処理により、メインメモリ上で場合によっては複数回分のメモリコピーが発生し、メインメモリの負荷が大幅に増大する。このようなメモリ負荷の増大に対し、従来は十分な処理性能を持つホストＣＰＵと高速のメインメモリを用意して対応していた。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００５−３１６６２９号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、昨今のネットワークストレージの１０Ｇｂｐｓに迫る転送レートの向上を鑑みると、コストや消費電力の増大が少なからず問題となってきた。特に、メインメモリの性能を上げるためには、一般にホストＣＰＵのグレードアップも伴う。ＰＣ（パーソナルコンピュータ）やサーバ等の場合は、付随するチップセットのグレードアップも必要となる。これにより、コストや消費電力の問題が特に顕著となる。
【課題を解決するための手段】
【００１１】
実施形態のデータ転送装置は、コマンド発行部と、送信データ抽出部と、通信処理部と、を備える。コマンド発行部は、制御装置から読み出しが指示されたブロックの読み出しコマンドを記憶装置に対して発行する。送信データ抽出部は、読み出しコマンドに応じて記憶装置から読み出されたデータから送信データを抽出する。通信処理部は、予め定められたプロトコルに基づいて、抽出された送信データをネットワークに送信する。
【図面の簡単な説明】
【００１２】
【図１】第１の実施形態に係るデータ送信システムのブロック図。
【図２】エクステントマップの構成例を示す図。
【図３】第１の実施形態におけるデータ転送処理のフローチャート。
【図４】コマンドとアドレス領域との対応の一例を示す図。
【図５】第２の実施形態に係るデータ送信システムのブロック図。
【図６】第２の実施形態におけるデータ転送処理のフローチャート。
【図７】エクステントマップの構成例を示す図。
【図８】第２の実施形態の通信処理部のブロック図。
【図９】ＴＴＳ０〜ＴＴＳ７のデータの並びを例示する図。
【図１０】トリックプレイ向け送信の動作概要を示す図。
【図１１】第３の実施形態に係るホストＣＰＵのブロック図。
【図１２】第３の実施形態に係る通信処理部のブロック図。
【図１３】第３の実施形態におけるデータ転送処理のフローチャート。
【図１４】Ｉフレームとパケットとの関係の一例を示す図。
【図１５】データパケットのグルーピングの一例を示す図。
【図１６】データパケットのグルーピングの一例を示す図。
【図１７】第３の実施形態の変形例に係るホストＣＰＵのブロック図。
【発明を実施するための形態】
【００１３】
以下に添付図面を参照して、この発明にかかるデータ転送装置、データ送信システム、データ送信方法およびプログラムの好適な実施形態を詳細に説明する。
【００１４】
（第１の実施形態）
図１は、第１の実施形態に係るデータ送信システムの概略構成例を示すブロック図である。破線矢印は制御の流れを示し、実線矢印はストレージから読み出したデータの流れを示し、太い実線矢印は読み出したデータのうち送信するデータ（送信データ）の流れを示す。
【００１５】
第１の実施形態のデータ送信システムは、制御装置としてのホストＣＰＵ（プロセッサ）２００と、記憶装置としてのストレージ３００と、データ転送装置１００とを備えている。ホストＣＰＵ２００の制御に基づき、データ転送装置１００が送信データをストレージ３００から読み出し、ネットワーク４００に送信する。
【００１６】
第１の実施形態のデータ送信システムの具体的な製品形態としては、ＰＣ、サーバ装置、専用ＬＳＩ、およびＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等のネットワークストレージ、ＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）サーバ、並びにＷｅｂサーバなどが想定されるが、これらに限定されるものではない。
【００１７】
ホストＣＰＵ２００は、データ送信システム全体を制御する。ホストＣＰＵ２００は、ソフトウェアで実行する主な処理部として、ファイル指定部２０１と、メタデータ指定部２０２と、メタデータ解析部２０３と、送信データ特定部２０４と、管理情報読み出し指示部２０５と、エクステントマップ取得部２０６と、送信データ読み出し指示部２０７と、を備えている。ホストＣＰＵ２００は、その他の種々の処理を行うことが可能である。
【００１８】
ファイル指定部２０１は、送信データが含まれるファイルを指定する。メタデータ指定部２０２は、ファイル内での送信データの位置の特定に利用する特定情報を含むメタデータを指定する。メタデータ解析部２０３は、指定されたメタデータを解析する。送信データ特定部２０４は、解析されたメタデータの情報をもとに、指定されたファイルの中の送信データの位置を特定する。
【００１９】
管理情報読み出し指示部２０５は、ストレージ３００の管理情報の読み出しを指示する。管理情報とは、ストレージ３００に記憶される実データのメタデータである。管理情報は、例えば実データとストレージ３００の記録領域とのマッピング情報を含む。なお、管理情報はその他諸々の情報も含む。
【００２０】
エクステントマップ取得部２０６は、読み出した管理情報を解析して、送信データのエクステントマップ（マップ情報）を取得する。エクステントマップとは、ストレージ３００内のデータの記憶位置を特定する情報である。エクステントマップの詳細については後述する。
【００２１】
送信データ読み出し指示部２０７は、データ転送装置１００に対して、データの読み出しおよびデータの送信を指示する。
【００２２】
ストレージ３００は、送信データを含む各種データを格納する。ストレージ３００の具体的な実装形態は、例えばＳＳＤ、ＨＤＤおよびＳＤメモリカード等が想定されるが、その限りではない。また、ストレージ３００がＲＡＩＤ機能を備えてもよい。データ転送装置１００内のストレージ３００とのインタフェースにＲＡＩＤ機能を備えてもよい。
【００２３】
データ転送装置１００は、ホストＣＰＵ２００に代行し、ストレージ３００からデータを読み出し、読み出したデータに対して通信処理を行い、読み出したデータをネットワーク４００に送信する。データ転送装置１００は、コマンド発行部１１０と、通知振り分け部１２０と、送信データ抽出部１３０と、通信処理部１４０と、を備えている。
【００２４】
コマンド発行部１１０は、ストレージ３００に対してデータの読み出し等のコマンドを発行する。通知振り分け部１２０は、発行したコマンドの応答通知を受け取り、受け取った応答通知をホストＣＰＵ２００とデータ転送装置１００とのいずれかに振り分ける。送信データ抽出部１３０は、ストレージ３００から読み出されたデータを受け取り、受け取ったデータから必要なデータを抽出する。通信処理部１４０は、抽出されたデータに対して予め定められた通信プロトコルに従った通信処理を行い、抽出されたデータをネットワーク４００に送信する。
【００２５】
通信処理部１４０は、前述したＴＯＥに相当する。データ転送装置１００の具体的な実装の形態としては、ＦＰＧＡおよび専用ＬＳＩなどが想定される。データ転送装置１００をＰＣＩカードおよびＰＣＩ−Ｅｘｐｒｅｓｓカードとして実装してもよい。なお、実装形態はこれらに限られるものではない。
【００２６】
ネットワーク４００は、イーサネットおよび無線ＬＡＮなどのあらゆる無線通信または有線通信により構成できる。
【００２７】
ホストＣＰＵ２００とデータ転送装置１００は、データ送信システムがＰＣやサーバ装置などの場合は例えばチップセットやＰＣＩ Ｅｘｐｒｅｓｓ等で接続されてもよい。データ送信システムがＳｏＣなどの場合は、ホストＣＰＵ２００とデータ転送装置１００は、例えば専用のバスなどで接続されてもよい。ストレージ３００とデータ転送装置１００は、例えばＳＡＴＡ、ＳＡＳ、ＳＣＳＩ、および、ＳＤメモリカード規格などで接続される。これらは一例であり、その他のあらゆる接続方式を適用できる。
【００２８】
データ転送装置１００は、ハードウェアとソフトウェアのいずれにより構成してもよく、実装の形態は問わない。処理効率の観点からは、ハードウェアベースで構成することが望ましい。また、通信処理部１４０による通信処理はどのような処理であってもよい。通信処理部１４０による通信処理としては、例えば、ＴＣＰ／ＩＰベースのプロトコル処理、ＵＤＰ／ＩＰベースのプロトコル処理、ＩＰＴＶ向けＲＴＰ／ＦＥＣベースのプロトコル処理、イーサネット処理、および、無線処理などが挙げられる。
【００２９】
なお、ＴＣＰのような対向装置とコネクションを張るプロトコルの場合、以下の動作説明は、相手とコネクションを張った後のデータ転送の段階での動作になる。
【００３０】
ストレージ３００は、データを例えばセクタ、クラスタまたはページと呼ばれる単位で管理する。ここでは簡単のため、これらを総称してブロックと呼ぶ。ユーザが扱うデータはブロック単位ではないため、ストレージ３００は通常ファイルシステムによりアクセスされる。ファイルシステムは、バイト単位のファイルデータをブロック単位のストレージ３００の記録領域にマッピングする仕組みである。ファイルシステムは、ストレージ３００上の予め定められた領域に、上述の管理情報をデータと併せて記憶する。
【００３１】
ストレージ３００からファイルデータを読み出す際は、まずこの管理情報を読み出し、読み出した管理情報を解析し、所望のファイルデータが実際にどのブロックに記憶されているかを表す情報であるエクステントマップを得る。そして、取得したエクステントマップに従ってブロックごとのデータ（ブロックデータ）を読み出し、ブロックデータから必要部分だけを抽出して所望のデータを得る。
【００３２】
次に、エクステントマップの詳細について説明する。図２は、エクステントマップの構成例を示す図である。図２は、１ブロックが５１２バイトであり、ブロック２３５〜２３８に所望のファイルの一部のデータが格納されている例を示している。データは、ブロック２３５の１２４バイト目から始まっている。このため、データの位置を示す情報（有効データ位置情報）は、オフセット１２４バイト、長さは１４５８バイト、などと表わされる。エクステントマップは、ブロック位置情報と、有効データ位置情報とを含む。ブロック位置情報は、データが格納されているブロックの位置を表す情報である。図２の例では、ブロック２３５〜２３８が、ブロック位置情報に相当する。有効データ位置情報は、ブロック位置情報で示されるブロック内で、有効データが格納されている位置を表す情報である。このように、エクステントマップは、ストレージ３００のどの位置に所望のデータが格納されているかが特定できる情報である。
【００３３】
図２の例では、データが格納されているバイト位置をオフセットと長さで有効データ位置情報を示している。有効データ位置情報は、始端バイト位置と終端バイト位置等で表してもよい。このように、有効データ位置情報は、有効データの位置が特定できれば表現形式は問わない。また、図２の例では１４５８バイトの１つのデータ列の例を示したが、エクステントマップは離散的な複数のデータ列を表わしていてもよい。すなわち、１つのエクステントマップに、例えばブロック２３５〜２３８のうちの１４５８バイトを示す情報と、ブロック３４６〜３５０のうちの２０００バイトを示す情報の２つのデータ列を含んでいてもよい。
【００３４】
なお、以上はエクステントベースのファイルシステムの場合に当てはまる。本実施形態は、ブロック（クラスタ）ベースのファイルシステムにも適用できる。ブロック（クラスタ）ベースのファイルシステムの場合は、エクステントの代わりにブロック（クラスタ）のリストになる。このブロック（クラスタ）のリストをエクステントの特殊な場合（１つのエクステントの長さを５１２バイトに固定したもの）とみなせば、エクステントベースの場合と同様に考えることが可能である。以後はエクステントの用語を用いて説明し、これら両方を含むものとする。
【００３５】
公知の技術では、通常、ホストＣＰＵはアプリケーションのファイルデータ読み出し要求に基づき、デバイスドライバやファイルシステムソフトウェア等の制御ソフトウェアを実行することで、このエクステントマップを取得する。そして、ホストＣＰＵは、エクステントマップに従って所望のデータをストレージから読み出し、アプリケーションに読み出したデータを返す。それに対して本実施形態では、ホストＣＰＵ２００による処理の一部をデータ転送装置１００が代行し、そのままネットワーク４００にデータを送信する。具体的な処理の流れは次のようになる。
【００３６】
図３は、第１の実施形態におけるデータ転送処理の全体の流れを示すフローチャートである。
【００３７】
まず、ファイル指定部２０１が、例えばアプリケーションソフトウェアの処理に従い送信するファイルを特定し、特定したファイルを送信データ特定部２０４に指定する（ステップＳ１０１）。典型的な例としては、ファイル指定部２０１は、ネットワーク４００に接続された他の機器から要求されたファイルを、送信するファイルとして特定する。
【００３８】
さらに、メタデータ指定部２０２が、送信データの特定に利用するメタデータを指定する（ステップＳ１０２）。
【００３９】
メタデータに含まれる特定情報は、単純には指定されたファイルの中の送信データのバイト位置を示すものでもよい。例えば、１０００バイトのファイルのうち、１０バイト目から９９バイト目、２００バイト目から２９９バイト目、および、５００バイト目から６９９バイト目の３つのデータの固まりを送信する場合を考える。この場合、特定情報は、（先頭位置，長さ）の形式の３つのデータ（１０，９０）（２００，１００）（５００，２００）を含むリストデータ形式、または、テーブル形式で表される。データが映像や音声コンテンツのストリーミングのデータである場合、特定情報は、再生時間を表わすものであってもよい。例えば、全長が２時間のコンテンツで、そのうち、開始から１０分後の時点から１５分間、および、開始から３０分後の時点から２０分間のデータを送信する場合を考える。この場合、特定情報は、（開始時間［ｓｅｃ］、時間の長さ［ｓｅｃ］）の形式の２つのデータ（６００，９００）（１８００，１２００）で表記してもよい。
【００４０】
特定情報は、例えば対向装置で視聴するユーザが指定した位置そのものでもよい。また、特定情報は、コンテンツのうちの特定の俳優が映っているシーンなどを自動抽出したような、データ送信システム側からユーザに対して視聴を推奨する位置のようなものであってもよい。
【００４１】
次に、メタデータ解析部２０３が、指定されたメタデータを解析する（ステップＳ１０３）。
【００４２】
次に、送信データ特定部２０４が、解析されたメタデータの情報をもとに、指定されたファイルから、送信データを特定する（ステップＳ１０４）。送信データ特定部２０４は、特定した送信データの位置と、送信データの長さとを含む情報、または当該情報の集合を、管理情報読み出し指示部２０５に渡す。
【００４３】
管理情報読み出し指示部２０５は、渡された送信データの情報に基づき、ストレージ３００からファイルシステムの管理情報を読み出すコマンドの発行を、データ転送装置１００のコマンド発行部１１０に指示する（ステップＳ１０５）。
【００４４】
ストレージ３００は、この指示に応じてコマンド発行部１１０から発行されたコマンドに基づき、管理情報を読み出してエクステントマップ取得部２０６に渡す（ステップＳ１０６）。
【００４５】
エクステントマップ取得部２０６は、読み出された管理情報を解析し、読み出す送信データのエクステントマップを取得する（ステップＳ１０７）。なお、エクステントマップ取得部２０６が、予めキャッシュしたエクステントマップを取得するように構成してもよい。この場合は、エクステントマップ取得部２０６が同様の手順で予めエクステントマップを読み出しておく必要がある。
【００４６】
次に、送信データ読み出し指示部２０７が、取得したエクステントマップを、データ転送装置１００に渡し、データ転送装置１００に対してそのデータの読み出しと送信を指示する（ステップＳ１０８）。
【００４７】
データ転送装置１００のコマンド発行部１１０が、送信されたエクステントマップを受け取り、受け取ったエクステントマップに従って、実際に送信データを含むブロックを読み出すべく、ストレージ３００にコマンドを発行する（ステップＳ１０９）。
【００４８】
コマンド発行部１１０は、ストレージ３００側のＩ／Ｆ仕様に従ったコマンドを発行する。通常、一度に指定できる読み出しブロック数に限りがあったり、離散的なブロックは同時に指定できなかったりなどの制限がある場合がある。このため、１つのエクステントマップが複数のコマンド群に分割される場合もある。このように、コマンド発行部１１０は、必要に応じて１つのエクステントマップに対するコマンドを分割する処理も行う。
【００４９】
コマンド発行部１１０がコマンドを順次ストレージ３００に対して発行すると、ストレージ３００からコマンドに対する応答として送信データが含まれたブロックデータが返ってくる。送信データ抽出部１３０が、ストレージ３００から返された送信データを受け取る。
【００５０】
なお、送信データ読み出し指示部２０７は、ステップＳ１０８でコマンド発行部１１０に指示を出す一方、送信データ抽出部１３０に対して、個々のコマンドで読み出されるブロックデータのどの部分に送信データが含まれているかを表す情報を渡す。すなわち、前述の図２の例では、送信データ読み出し指示部２０７は、ブロック２３５〜２３８というブロック位置情報をコマンド発行部１１０に渡し、オフセット１２４バイトおよび長さ１４５８バイトという有効データ位置情報を送信データ抽出部１３０に渡す。
【００５１】
送信データ抽出部１３０は、受け取ったブロックデータから、有効データ位置情報に従い所望のバイト数（図２の例では１４５８バイト）のデータ列を抽出し、通信処理部１４０に渡す（ステップＳ１１０）。通信処理部１４０は、必要に応じて対向装置と制御情報を送受信しながら、ネットワーク４００上に、抽出された送信データを送信する（ステップＳ１１１）。
【００５２】
次に、ストレージ３００とのＩ／Ｆ処理についてより詳しく説明する。まず、ストレージ３００が典型的なＳＳＤやＨＤＤなどのＳＡＴＡ Ｉ／Ｆを備え、さらにバスマスターとしての機能（ＤＭＡ機能）を備える場合について説明する。この場合、コマンド発行部１１０は、例えばストレージ３００へのコマンドとして、デスクリプタと呼ばれるコマンドを記述したデータを、所定のメモリ上に用意しておく。ストレージ３００はコマンドを当該メモリから読み出す。このようにしてコマンド発行部１１０が発行したコマンドがストレージ３００に受け渡される。
【００５３】
デスクリプタは通常リングバッファ形式になっており、典型的な公知の技術ではホストＣＰＵ２００が使用するメインメモリ（主記憶装置、不図示）上に置かれる。本実施形態でも同じ形態をとってもよいが、データ転送装置１００内のメモリ、または、データ転送装置１００に直接接続されるメモリを用いることが、メインメモリやホストＣＰＵ２００に負荷を与えないという点で望ましい。
【００５４】
ストレージ３００が読み出したブロックデータをＤＭＡで書き込む宛先アドレスも、それぞれのデスクリプタに予め指定される。ストレージ３００から読み出した管理情報はホストＣＰＵ２００に渡し、送信データは通信処理部１４０に渡すといった振り分けは、このアドレス指定によって実現する。すなわち、管理情報をホストＣＰＵ２００に渡す場合は、通常はメインメモリを介して行うので、デスクリプタに記載する宛先アドレスにメインメモリのアドレスを記載する。送信データを送信データ抽出部１３０に渡す場合は、宛先アドレスに送信データ抽出部１３０のアドレスを記載する。これによって、ストレージ３００がデスクリプタによって指定された宛先アドレスに読み出したデータを書き込むだけで、読み出したデータをそれぞれに振り分けることができる。
【００５５】
ストレージ３００は、コマンドを実行してデータを読み出した後に、通知振り分け部１２０に対してコマンド完了通知を行う。ストレージ３００は、例えば割り込みなどによって完了通知を行う。より具体的には、ストレージ３００は、例えばどこまでコマンドを処理したか、すなわち、リングバッファのデスクリプタ群のどのデスクリプタまで処理したかを、各デスクリプタの処理完了を示すＤＯＮＥビットをセットするなどにより通知する。
【００５６】
通知振り分け部１２０は、割り込み通知を受けると、このＤＯＮＥビットが書かれているデスクリプタを順次読み出し（読み出した後はＤＯＮＥビットをリセットする）、そのデスクリプタまで処理が完了していることを判断できる。なお、一度に複数のデスクリプタの処理が完了している場合もあり得る。
【００５７】
通知振り分け部１２０は、管理情報の読み出しに用いられるデスクリプタの完了通知を受けた場合は、管理情報読み出し指示部２０５に完了通知を振分ける。また、通知振り分け部１２０は、送信データの読み出しに用いられるデスクリプタの完了通知を受けた場合は、送信データ読み出し指示部２０７に完了通知を通知する。このようにして通知振り分け部１２０は完了通知をそれぞれに振り分ける。
【００５８】
管理情報読み出し指示部２０５は、通知振り分け部１２０から完了通知を受けると、管理情報の読み出しが完了したと判断し、エクステントマップ取得部２０６にエクステントマップの取得を指示する。
【００５９】
ストレージ３００によるブロックデータの転送には、通常は一定のレイテンシが存在する。このため、ホストＣＰＵ２００は、転送指示に対するストレージ３００からの完了通知を毎回待たずに、複数のブロックの読み出しをまとめて指示する場合がある。その場合、そのままでは送信データ読み出し指示部２０７（および管理情報読み出し指示部２０５）とストレージ３００と送信データ抽出部１３０との３者の間で同期が取られなくなる。このため、例えば以下の手法により同期を行う。
【００６０】
１つ目の手法は、ストレージ３００がコマンドを受けた順番と必ず同じ順番で読み出しを実行する場合に有効な手法である。この手法では、送信データ読み出し指示部２０７がストレージ３００からの複数のブロックの読み出しを指示するとき、その指示と同じ順番で、対応するブロックの中の有効データ位置情報を送信データ抽出部１３０に通知する。送信データ抽出部１３０は、受け取った有効データ位置情報を例えばキューイングしておく。送信データ抽出部１３０は、ストレージ３００からブロックデータを受け取った際、キューイングした有効データ位置情報をキューイングした順番に１つずつ取り出せば、ブロックデータとの対応付けができる。
【００６１】
２つ目の手法は、ストレージ３００が、内部処理の効率等を優先する場合等で、コマンドを受けた順番とは異なる順番で読み出しを実行し得る場合の手法である。この場合は、例えば各ブロックの宛先アドレスとして異なるアドレスを指定する手法等が考えられる。
【００６２】
例えば８個の読み出しコマンドをストレージ３００にまとめて指示する場合、送信データ読み出し指示部２０７は、８個のコマンドごとに異なる転送先アドレスを指定しておく。上述のように本実施形態では、転送先のアドレスに送信データ抽出部１３０のアドレスを指定する。２つ目の手法を適用する場合は、例えば１つのコマンドで最大４つのブロックの読み出し指示を出す場合、各コマンドに対応する転送先アドレスとして、それぞれ送信データ抽出部１３０のアドレス領域のうちの異なるアドレス領域を指定しておく。
【００６３】
図４は、コマンドとアドレス領域との対応の一例を示す図である。図４は、送信データ抽出部１３０のアドレス領域が０ｘ２０２０００００〜０ｘ２０２ｆｆｆｆｆの場合の例を示している。コマンド番号は、コマンドを識別する情報である。図４に示すように、０ｘ２０２０００００〜０ｘ２０２００７ｆｆの５１２×４バイト領域がコマンド０に対応し、０ｘ２０２００８００〜０ｘ２０２００ｆｆｆの５１２×４バイト領域がコマンド１に対応し、０ｘ２０２０１０００〜０ｘ２０２０１７ｆｆの５１２×４バイト領域がコマンド２に対応するというように、コマンドとアドレス領域とを予め対応付けておく。送信データ読み出し指示部２０７は、発行するコマンドに対して、対応するアドレス領域の先頭を指定するようにコマンド発行部１１０に指示する。
【００６４】
これにより、転送されたブロックデータは、送信データ抽出部１３０の中の異なるアドレス領域に転送される。送信データ抽出部１３０は、受けたブロックデータが例えば０ｘ２０２０１２００から始まるアドレスに書き込まれたデータであれば、当該データはコマンド２の先頭から２番目のブロックデータであることが特定できる。また、例えばコマンド２で読み出されるブロックデータに対して図２に示す有効データ位置情報が通知されている場合、このブロックデータは有効データの３８９バイト目から９００バイト目のデータであることが分かる。
【００６５】
送信データ読み出し指示部２０７は、送信データ抽出部１３０に対して８個の有効データ位置情報を通知する。その際、送信データ読み出し指示部２０７は、コマンド０に対応する有効データ位置情報、コマンド１に対応する有効データ位置情報、コマンド２に対する有効データ位置情報・・・、などのように、有効データ位置情報がいずれのコマンドに対応するかを特定できるように通知する。
【００６６】
このような構成により、送信データ抽出部１３０は、受けたブロックデータ、および、有効データ位置情報がともに、いずれのコマンドに対するものかを判別できる。すなわち、送信データ抽出部１３０は、コマンドと、ブロックデータおよび有効データ位置情報との対応付けが可能となる。
【００６７】
このように、ブロックデータの宛先アドレス領域を分けることによって、送信データ抽出部１３０が受け取ったブロックデータの順番がもとのデータ列の順番（通常はネットワークに送信する順番）と異なる場合でも、ブロックデータの宛先アドレスを確認することで、そのデータがどのコマンドに基づくデータかが判断できるので、それをもとにデータ列を元の順番に並び替えることが可能となる。
【００６８】
なお、アドレスを使うことは本実施形態の一例である。ブロックデータを特定可能な情報であれば、アドレス以外のどのような情報を用いてもよい。また、以上のストレージ３００Ｉ／Ｆの詳細は一例であり、これに限られるものではない。
【００６９】
ストレージ３００が内部エラー等の何らかの理由により、要求されたコマンドの実行を完了できない場合がある。この場合、ストレージ３００は、データ転送装置１００にエラー通知を行う。このままではホストＣＰＵ２００はエラーの情報を得られないので、このような場合に、データ転送装置１００がホストＣＰＵ２００にエラー通知を中継して従来通りホストＣＰＵ２００も異常を知ることができるように構成してもよい。
【００７０】
また、通知振り分け部１２０は必ずしもデータ転送装置１００上に構成する必要はなく、ホストＣＰＵ２００上に構成してもよい。また、コマンド発行部１１０もその一部の処理をホストＣＰＵ２００側で行ってもよい。ただし、１つの送信データ読み出し指示を複数のコマンドに分割する処理はデータ転送装置１００上で行う方が処理効率の面で望ましい。
【００７１】
このように、第１の実施形態にかかるデータ転送装置では、アプリケーションからの要求に基づき、ホストＣＰＵ２００にデータ転送処理の負荷を与えることなくストレージ３００上のデータをネットワーク４００に送信することができる。従って、処理効率が向上し、データ転送速度を向上させることができる。また、ホストＣＰＵ２００、ホストＣＰＵ２００に付随するチップセット、メモリ、およびマザーボードなどのグレードを下げることができるので、装置の低コスト化を図ることができる。また、データ転送の大部分の処理をホストＣＰＵ２００のソフトウェア処理ではなくデータ転送装置１００のハードウェア処理で実行することが可能となるので、低消費電力化を図ることができる。
【００７２】
（第２の実施形態）
第２の実施形態は、データ転送用に複数の通信コネクションが設定され、コネクションごとに独立してフロー制御を行う例を示している。例えばＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）のようなネットワークストレージ、ＶＯＤサーバに接続される複数のクライアント端末、または、クライアント端末上の複数のアプリケーションから、同時に読み出し要求やコンテンツ配信要求を受けた場合などに、複数の独立したコネクションでストレージからデータを読み出してネットワークに送信する動作を可能とする。
【００７３】
図５は、第２の実施形態に係るデータ送信システムの概略構成例を示すブロック図である。
【００７４】
図５に示すように、第２の実施形態のホストＣＰＵ２００−２は、ファイル指定部２０１と、メタデータ指定部２０２と、メタデータ解析部２０３と、送信データ特定部２０４−２と、管理情報読み出し指示部２０５−２と、エクステントマップ取得部２０６と、送信データ読み出し指示部２０７−２と、を備えている。
【００７５】
第２の実施形態では、送信データ特定部２０４−２、管理情報読み出し指示部２０５−２、および送信データ読み出し指示部２０７−２の機能が第１の実施形態と異なっている。その他の構成および機能は、第１の実施形態のブロック図である図１と同様であるので、同一符号を付し、ここでの説明は省略する。
【００７６】
送信データ特定部２０４−２および管理情報読み出し指示部２０５−２は、コネクションごとに処理を実行する点が、第１の実施形態と異なっている。送信データ読み出し指示部２０７−２は、コネクションを識別するコネクション識別情報とともに、データの読み出しを指示する点が、第１の実施形態と異なっている。
【００７７】
第２の実施形態のデータ転送装置１００−２は、コマンド発行部１１０と、通知振り分け部１２０と、送信データ抽出部１３０−２と、通信処理部１４０−２と、フロー制御部１５０−２と、バッファ管理部１６０−２と、データバッファ１７０−２と、を備えている。
【００７８】
第２の実施形態では、フロー制御部１５０−２とバッファ管理部１６０−２とデータバッファ１７０−２とを追加したこと、および、送信データ抽出部１３０−２と通信処理部１４０−２の機能が第１の実施形態と異なっている。その他の構成および機能は、第１の実施形態のブロック図である図１と同様であるので、同一符号を付し、ここでの説明は省略する。
【００７９】
データバッファ１７０−２は、送信データ抽出部１３０−２と通信処理部１４０−２との間のデータの受け渡しのためにコネクションごとにデータをバッファリングする。以下では、データバッファ１７０−２内のコネクションごとのデータを記憶する領域を、単にバッファという場合がある。
【００８０】
バッファ管理部１６０−２は、データバッファ１７０−２のコネクションごとの状態（バッファ状態）を管理する。フロー制御部１５０−２は、バッファ管理部１６０−２からの通知に基づいてコネクションごとのデータのフロー制御を行う。図５では、フロー制御情報の伝達は太い破線で表わしている。
【００８１】
送信データ抽出部１３０−２は、抽出した送信データをデータバッファ１７０−２に記憶する点が、第１の実施形態と異なっている。通信処理部１４０−２は、バッファ管理部１６０−２により管理されるバッファ状態に応じて、データバッファ１７０−２から送信データを読み出す点が、第１の実施形態と異なっている。
【００８２】
図６は、第２の実施形態におけるデータ転送処理の全体の流れを示すフローチャートである。
【００８３】
ステップＳ２０１からステップＳ２０７までは、第１の実施形態のデータ転送処理を示す図３のステップＳ１０１からステップＳ１０７までと同様の処理なので、その説明を省略する。
【００８４】
本実施形態では、送信データ読み出し指示部２０７−２が、取得したエクステントマップとともに、コネクション識別情報をデータ転送装置１００−２に渡し、データ転送装置１００−２に対してそのデータの読み出しと送信を指示する（ステップＳ２０８）。送信データ読み出し指示部２０７−２は、例えば、アプリケーションから受け取ったコネクション識別情報をデータ転送装置１００−２に渡す。
【００８５】
データ転送装置１００−２では、フロー制御部１５０−２がデータの読み出しの指示を受ける。フロー制御部１５０−２は、コネクションごとにエクステントマップを保持する。すなわち、フロー制御部１５０−２は、複数のコネクションのデータ読み出し要求を一旦保持しておく。そして、バッファ管理部１６０−２からバッファに空きがあるコネクションの通知を受けると、フロー制御部１５０−２は、通知を受けたコネクションの送信データの読み出しコマンドの発行をコマンド発行部１１０に対して指示する。
【００８６】
コマンド発行部１１０は、フロー制御部１５０−２から受け取ったエクステントマップに従って、送信データを含むブロックを読み出すための読み出しコマンドを発行する（ステップＳ２０９）。ステップＳ２１０は、第１の実施形態のステップＳ１１０と同様の処理なので、その説明を省略する。
【００８７】
第２の実施形態では、送信データ抽出部１３０−２は、ブロックデータから抽出した送信データを、データバッファ１７０−２に記憶する（ステップＳ２１１）。また、通信処理部１４０−２は、データバッファ１７０−２から送信データを読み出してネットワーク４００に送信する（ステップＳ２１２）。
【００８８】
初期状態では全てのコネクションのバッファは空いているので、フロー制御部１５０−２は、そのままコマンド発行部１１０に送信データの読み出しを指示することになる。同じコネクションのデータの送信が連続して要求されると、フロー制御部１５０−２が要求を一旦保持し、バッファ管理部１６０−２からのバッファ空き通知を待つ状況になる場合がある。
【００８９】
コマンド発行部１１０に一度にコマンド発行を要求するデータのサイズは、バッファの空きサイズ（空き容量）以下でなければならない。一例として、データバッファ１７０−２のコネクションごとのバッファが１２８ＫＢずつ確保され、バッファ管理部１６０−２がいずれかのコネクションで６４ＫＢ以上バッファに空きが生じたら、そのコネクションのバッファ空きをフロー制御部１５０−２に通知するものとする。
【００９０】
ホストＣＰＵから渡されたエクステントマップが、これより大きいサイズのデータを示している場合も当然ながらあり得る。しかし、フロー制御部１５０−２が一度にコマンド発行を要求可能なデータのサイズは空いた分の６４ＫＢ以下のサイズの部分データである。このため、フロー制御部１５０−２は、この部分データの読み出しをコマンド発行部１１０に要求する。同時にフロー制御部１５０−２は、この部分データの中の有効データ位置情報を送信データ抽出部１３０−２に渡す。そして、フロー制御部１５０−２は、読み出し処理を完了した部分データの位置を進捗情報としてコネクションごとに保持し、一旦コマンド発行要求を終える。
【００９１】
以上の処理を、図７を用いて説明する。図７は、エクステントマップの構成例を示す図である。図７は、ブロック位置情報としてブロック２３５〜１０００、有効データ位置情報としてオフセット１２４バイト、長さ３９１６０２バイトを表すエクステントマップをホストＣＰＵ２００−２から与えられた例を示している。この場合、最初の部分データは、例えば６４ＫＢ以下の切りの良いところとしてブロック２３５〜３６２の６５４１２バイトとなる。そして、この部分データの有効データ位置情報は、オフセット１２４バイト、長さ６５４１２バイトである。フロー制御部１５０−２は、ブロック２３５〜３６２の読み出しコマンドの発行をコマンド発行部１１０に要求する。フロー制御部１５０−２は、同時に送信データ抽出部１３０−２にオフセット１２４バイト、長さ６５４１２バイトという有効データ位置情報を渡す。フロー制御部１５０−２は、進捗情報として次回処理するブロックはブロック３６３、または、６５４１３バイト目、という情報を保持し、一旦処理を終える。フロー制御部１５０−２は、バッファ管理部１６０−２からの次のバッファ空き通知を待つ。
【００９２】
なお、以上で述べた６４ＫＢなどの各種データサイズは一例であり、この例に限られるものではない。また、データサイズは一定である必要もなく、サイズが毎回変わる場合も本実施形態を適用できる。
【００９３】
一旦部分データの処理を終え、その後に他のコネクションのデータバッファが空いたという通知をバッファ管理部１６０−２から受けると、フロー制御部１５０−２は、通知を受けたコネクションに対して同様に部分データの読み出し要求処理を行う。そして、あるコネクションに関して与えられたエクステントマップが示すデータの全てを送信し終える（図７の場合は６番目の部分データの読み出し要求を完了する）と、そのコネクションの与えられたエクステントマップが示すすべてのデータの送信が完了となる。フロー制御部１５０−２は、すべてのデータの送信が完了した旨をホストＣＰＵ２００−２に通知する。
【００９４】
ホストＣＰＵ２００−２では、例えば管理情報読み出し指示部２０５−２がこの通知を受け取り、次のアプリケーションからのデータ送信処理、すなわち管理情報読み出し指示部２０５−２から始まる一連の処理を実行可能とする。逆に、この通知を受けるまで、管理情報読み出し指示部２０５−２が次の管理情報の読み出しを一旦保留することで、送信データ特定部２０４−２との間のフロー制御を実現する。
【００９５】
なお、ホストＣＰＵ２００−２がこの通知を受けるのは必ずしも管理情報読み出し指示部２０５−２である必要はない。例えば、エクステントマップ取得部２０６、または、送信データ読み出し指示部２０７−２でもよい。すなわち、最終的にアプリケーションに対してバックプレッシャが伝達されるようになっていれば、いずれの構成部が通知を受けてもよい。
【００９６】
また、以上の例ではデータ転送装置１００−２がコネクションごとに同時に１つしかエクステントマップを受け付けない例を示したが、２つ以上のエクステントマップを受け付けるように構成してもよい。複数のエクステントマップを受け付ける構成であっても、エクステントマップは必ず有限個になる。従って、エクステントマップの最大個数を受け付けた際にそれ以上のエクステントマップを受けられないような仕組みを備えることにより、前述の方式を適用できる。
【００９７】
送信データ抽出部１３０−２は、前述のとおり有効データ位置情報をフロー制御部１５０−２から受け取り、有効データ位置情報に従って抽出した送信データをデータバッファ１７０−２に書き込む。データバッファ１７０−２に書き込む際の宛先アドレスは、フロー制御部１５０−２が生成し、送信データ抽出部１３０−２に渡す。
【００９８】
例えば、データバッファ１７０−２が前述の説明同様にコネクションごとに１２８ＫＢ確保されており、コネクションごとのバッファの先頭アドレスが以下のように割り当てられているものとする。
コネクション０のバッファの先頭アドレス＝０ｘ００００００００
コネクション１のバッファの先頭アドレス＝０ｘ０００２００００
コネクション２のバッファの先頭アドレス＝０ｘ０００４００００
【００９９】
また、現在コネクション１を処理しており、図７に示すデータの読み出しが初めて要求されたとする。この場合、最初の部分データの宛先アドレスは０ｘ０００２００００となり、次の部分データの宛先アドレスは６５４１３バイト加えた０ｘ０００２ｆｆ８５となる。
【０１００】
このように宛先アドレスを部分データのサイズごとに増加させていくと、データバッファ１７０−２にはもとの通り一連のデータとして展開される。また、バッファが例えばバイト単位のリングバッファであるとすると、０ｘ０００３ｆｆｆｆの次のバイトは０ｘ０００２００００に書き込むことになる。
【０１０１】
フロー制御部１５０−２は、送信データ抽出部１３０−２に対し、有効データ位置情報と共に、このような宛先アドレスを渡す。送信データ抽出部１３０−２は、抽出した送信データを、宛先アドレスに従ったアドレスから書き込む。これにより、データバッファ１７０−２にコネクションごとに適切に送信データを展開することができる。
【０１０２】
バッファ管理部１６０−２は、データバッファ１７０−２のコネクションごとのバッファのデータの供給側の書き込み位置と、データの消費側の読み出し位置と、コネクションごとのバッファの空き状態とを管理する。
【０１０３】
例えば、コマンド発行部１１０に部分データの読み出し要求を行い、ストレージ３００から読み出し要求に対する応答通知が返ってくると、フロー制御部１５０−２は、当該コネクションのバッファのどの位置までデータが書き込まれたかを判別できる。このため、フロー制御部１５０−２は、データが書き込まれた位置を進捗情報としてバッファ管理部１６０−２に通知する。
【０１０４】
例えば、図７の最初の部分データを書きこみ終わった際、フロー制御部１５０−２は、６５４１３バイトという情報をコネクション識別情報とともにバッファ管理部１６０−２に通知する。この通知によって、バッファ管理部１６０−２は、コネクション１のバッファのデータの供給側の位置は６５４１３バイトであると把握できる。
【０１０５】
一方、通信処理部１４０−２がデータを送信するためにデータバッファ１７０−２からデータを読み出すと、データの消費側の読み出し位置が移動する。このため、通信処理部１４０−２は、読み出し終わったバイト位置（正確には次に読み出し始めるバイト位置）をコネクションごとにバッファ管理部１６０−２に通知する。
【０１０６】
初期状態では、バッファは１２８ＫＢ（正確には２の１７乗の１３１０７２バイト）空いている。最初にデータを書き込まれると６５４１３バイト減って空きサイズが６５６５９バイトになる。これは６４ＫＢ（正確には２の１６乗上の６５５３６バイト）より大きいので、バッファ管理部１６０−２は、バッファ空き通知をフロー制御部１５０−２に送信する。
【０１０７】
これにより、フロー制御部１５０−２は、次の部分データ（図７の例では６５５３６バイト）の読み出し要求を出す。読み出し要求に応じてデータが書き込まれると、バッファサイズがさらに減って２３バイトになる。これは６４ＫＢより少ないので、バッファ管理部１６０−２はバッファ空き通知を行わない。
【０１０８】
従って、フロー制御部１５０−２は、次の部分データの読み出しを保留する。その後、通信処理部１４０−２がデータを例えば１ＫＢ（１０２４Ｂ）読み出すと、空きバッファサイズは１０４７バイトに増加する。引き続き通信処理部１４０−２がデータを読み出していき、空きサイズが６５５３６バイト以上になると、その段階でバッファ管理部１６０−２はフロー制御部１５０−２にバッファ空き通知を行う。
【０１０９】
通信処理部１４０−２は、処理している通信プロトコル仕様やネットワークの帯域などによって送信速度が制限される。例えばＴＣＰプロトコルのようにフロー制御や輻輳制御を行うような場合は、対向装置やネットワークの込み具合によって送信速度が低下し、データバッファ１７０−２からのデータの読み出しの進み具合が遅くなる。本実施形態によれば、その場合でも、適切に最上位のアプリケーションまでのフロー制御を実現することができる。逆に、対向装置が十分なデータを受け入れられる場合でも、本実施形態では、通信処理部１４０−２が現在のデータ供給側の位置を参照して、どの位置までデータを送信可能か判断する。これにより、適切にバッファに充填されている分だけデータを送信するという適切な制御が可能となる。
【０１１０】
次に、通信処理部１４０−２がＲＴＰのようなリアルタイム通信プロトコルを用いる場合の具体的な構成例を説明する。図８は、第２の実施形態の通信処理部１４０−２の構成例を示すブロック図である。
【０１１１】
図８に示すように、通信処理部１４０−２は、送信開始指示部１４１と、パケット送信指示部１４２と、送信判定部１４３と、ヘッダ生成部１４４と、データ読み出し部１４５と、パケット生成部１４６と、送信時刻生成部１４７と、を備えている。
【０１１２】
送信開始指示部１４１は、ホストＣＰＵ２００−２からのデータ送信開始指示を受け付け、受付けた指示に応じてデータの送信開始要求をパケット送信指示部１４２に送信する。パケット送信指示部１４２は、送信開始要求を受けると、その後のパケットごとの送信指示を行う。送信判定部１４３は、送信処理の各種判定処理を行う。ヘッダ生成部１４４は、パケットのヘッダを生成する。データ読み出し部１４５は、データバッファ１７０−２からパケットのデータ部分（ペイロード）を読み出す。パケット生成部１４６は、
生成されたヘッダと読み出されたデータに基づきパケットを生成する。送信時刻生成部１４７は、読み出されたデータを含むパケットの次に送信するパケット（次パケット）の送信時刻を生成する。
【０１１３】
具体的な動作は次のようになる。まず、ホストＣＰＵ２００−２は、パケット送信を開始するコネクションのコネクション識別情報を指定して、送信開始指示を送信開始指示部１４１に対して通知する。送信開始指示部１４１は、パケット送信指示部１４２に対して最初のパケットの生成を要求する。
【０１１４】
パケット送信指示部１４２は、内部にタイマーを持ち、例えば２７ＭＨｚ・３２ビットの現在のタイマーカウント値（すなわち現在時刻）を常に更新している。パケット送信指示部１４２は、コネクションごとに次パケットの送信時刻を例えばテーブル形式で保持する。パケット送信指示部１４２は、テーブルから送信時刻を順次読み出して現在のタイマーカウント値と比較し、現在時刻を越えていたらそのコネクションのパケット生成を指示する。
【０１１５】
例えばコネクション１とコネクション３が存在し、コネクション１のパケットの送信時刻として０ｘ４０００００００が保持され、コネクション３のパケットの送信時刻として０ｘ４００００１００が保持されているものとする。この場合、現在のタイマーカウント値が０ｘ３ｆｆｆｆｆｆｆまでのときは、パケット送信指示部１４２は、パケット生成を指示しない。現在のタイマーカウント値が０ｘ４０００００００になったときに、パケット送信指示部１４２は、コネクション１のパケット送信を指示する。現在のタイマーカウント値が０ｘ４００００１００になったときに、パケット送信指示部１４２は、コネクション３のパケット送信を指示する。
【０１１６】
送信判定部１４３は、パケット送信の指示に基づいてパケットの送信判定を行う。例えば、送信判定部１４３は、バッファ管理部１６０−２から現在のデータの供給側の書き込み位置を取得し、その位置が今回のパケット送信で読み出されるデータの終端を超えているか否かを判断する。超えている場合は、送信判定部１４３は、送信すべきデータが既に準備できているということを意味するので送信可能であると判定する。送信可能であると判定された場合、後段のヘッダ生成部１４４とデータ読み出し部１４５とパケット生成部１４６が動作して、パケットが送信される。
【０１１７】
送信時刻生成部１４７は、例えばデータを読み出した後に、次パケットの送信時刻を生成して、生成した送信時刻をパケット送信指示部１４２に伝える。このときに生成するパケット送信時刻は、例えば、現在送信しているデータストリームのパケット送信間隔（Ｐ［ｓｅｃ］とする）と、送信開始時点の時刻（Ｔ０［ｓｅｃ］とする）とから算出する。例えば、Ｎ番目のパケットの送信時刻はＴ０＋（Ｎ−１）×Ｐとなる。
【０１１８】
送信時刻生成部１４７が、次に送信するパケットに格納するデータの先頭バイトの、送信開始バイトからのバイトオフセット（ＯＦＳ［Ｂｙｔｅ］とする）と、データストリームのビットレート（ＢＲ［Ｂｙｔｅ／ｓｅｃ］とする）とから、Ｔ０＋ＯＦＳ／ＢＲにより送信時刻を算出してもよい。
【０１１９】
これらは本質的に同等の算出方法である。また、以上の例では簡単のため時間の単位を［ｓｅｃ］としたが、前述した２７ＭＨｚのクロックカウンタの単位で扱ってもよい。
【０１２０】
一方で、バッファ管理部１６０−２から現在のデータの供給側の書き込み位置が今回のパケット送信で読み出されるデータの終端を超えていない場合は、送信判定部１４３は、送信すべきデータが未だ準備されていないということを意味するので送信できないと判定する。この場合、送信が指示されたパケットの送信は取りやめる。
【０１２１】
そして、送信判定部１４３は、送信時刻生成部１４７に対して次パケットの送信時刻を生成するように指示を出す。このときに生成するパケット送信時刻は、例えば、現在の時刻に対し、前述のパケット送信間隔Ｐを足した時刻としてよいし、それ以外の所定の時刻としてもよい。さらに、ホストＣＰＵ２００−２からの設定によっては、この送信データが準備できていないいわゆるバッファアンダーフロー状態を、異常状態としてホストＣＰＵ２００−２に通知する処理を行ってもよい。この場合、ホストＣＰＵ２００−２は、例えば通知されたエラーをログに出力するなど異常系の処理を行ってもよい。
【０１２２】
また、送信しているデータが例えばＭＰＥＧのＴＴＳ（Ｔｉｍｅｓｔａｍｐｅｄ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）パケット（４バイトタイムスタンプ値＋１８８バイトＴＳパケットの合計１９２バイト）を含む送信パケットの場合、送信パケットの送信時刻は、その送信パケットに格納されている先頭のＴＴＳパケットのタイムスタンプ値を用いる。
【０１２３】
例えば１つの送信パケットに７つのＴＴＳパケットを格納して送信し、送信を開始するＴＴＳパケットをＴＴＳ０とするものとする。この場合、ＴＴＳ０〜６が１つ目の送信パケットに格納され、ＴＴＳ７〜１３が２つ目の送信パケットに格納され、ＴＴＳ１４〜２０が３つ目の送信パケットに格納され、各送信パケットが送信される。このときの各送信パケットの送信時刻は、１つ目の送信パケットはＴＴＳ０のタイムスタンプ値、２つ目の送信パケットはＴＴＳ７のタイムスタンプ値、３つ目の送信パケットはＴＴＳ１４のタイムスタンプ値、にそれぞれ基づいた値となる。
【０１２４】
具体的には、１つ目のパケットの送信時刻をＴ０、Ｎ番目のＴＴＳパケットのタイムスタンプ値をＴＭＳ（Ｎ）と表わすと、２つ目の送信パケットの送信時刻はＴ０＋ＴＭＳ（７）−ＴＭＳ（０）、３つ目の送信パケットの送信時刻はＴ０＋ＴＭＳ（１４）−ＴＭＳ（０）となる。
【０１２５】
従って、例えば２つ目の送信パケットの送信時刻を生成するときは、送信時刻生成部１４７は、１つ目のパケットのデータであるＴＴＳ０〜ＴＴＳ６のデータ（１９２バイト×７＝１３４４バイト）を読み出した後にさらにＴＴＳ７の先頭のタイムスタンプ値（４バイト）も読み出す。また、例えば３つ目の送信パケットの送信時刻を生成するときは、送信時刻生成部１４７は、２つ目の送信パケットのデータであるＴＴＳ７〜ＴＴＳ１３を読み出した後にさらにＴＴＳ１４の先頭のタイムスタンプ値も読み出す。送信時刻生成部１４７は、このようにして読み出したタイムスタンプ値をもとに次のパケット送信時刻を求める。
【０１２６】
さらに、このタイムスタンプ値の読み出しは、直前のデータ読み出しと隙間なく連続して行うように構成してもよい。例えば、１３４４バイト＋４バイト＝１３４８バイトを一括して読み出すように構成してもよい。これにより、バッファへのメモリアクセスのオーバーヘッドを軽減することができる。
【０１２７】
図９は、ＴＴＳ０〜ＴＴＳ７のデータの並びを例示する図である。図９の斜線部分は、各ＴＴＳの４バイトのタイムスタンプ値の部分を表す。ＴＴＳ０〜ＴＴＳ６と次のＴＴＳ７のタイムスタンプ値を併せた部分は図の矢印部分である。データ読み出し部１４５は、１つ目の送信パケットのデータ読み出し時に、この矢印で占められた領域を一括して読み出す。これにより、１つ目の送信パケットのデータ読み出しと併せて次の送信パケットの送信時刻生成に必要なＴＴＳ７のタイムスタンプ値を読み出すことができるため、処理の効率化が図れる。
【０１２８】
なお、以上のＲＴＰ系の通信プロトコルの場合においても、例えばデータ読み出し部１４５がデータの読み出しを完了した時点で、前述の通り読み出し終わった部分を進捗情報としてバッファ管理部１６０−２に伝える。例えば、データ読み出し部１４５は、読み出しの最後のタイムスタンプ値の部分は含めない位置を通知する。図９の場合は、データ読み出し部１４５は、ＴＴＳ６の終端位置を通知する。データ読み出し部１４５が読み出しの最後のタイムスタンプ値の部分を含めた位置を読み出し済みとして通知するように構成してもよい。ただし、タイムスタンプ値はもう読み出せないことを意味する。従って、この構成の場合、例えば図９の例では、次の送信パケットのデータ読み出しまで、読み出した最後のタイムスタンプ値を保持しておく必要がある。そして、データ読み出し部１４５は、２つ目の送信パケットのデータを読み出すとき、保持したタイムスタンプ値の次のデータから読み出しを行い、保持したタイムスタンプ値と読み出したデータとをマージしてパケット生成部１４６に渡すことになる。
【０１２９】
このように、第２の実施形態にかかるデータ転送装置では、第１の実施形態の効果に加えて、通信速度が遅くなっても適切にフロー制御を行うことができるようになる。また、第２の実施形態では通信コネクションごとにフロー制御を行うことができる。このため、あるコネクションのデータフローが止まっていても、それ以外のコネクションのデータフローには影響を与えないように動作することが可能である。
【０１３０】
（第３の実施形態）
第３の実施形態では、より複雑な動作例として、トリックプレイ向け送信とＦＥＣパケット送信について説明する。トリックプレイとは、早送り、巻き戻しなど通常再生とは異なる再生のことを指す。例えばＲＴＰを用いたリアルタイム通信ベースのＩＰＴＶ向けＶＯＤサーバでは、トリックプレイによる再生に対応したストリームの送信が必要となる。
【０１３１】
図１０は、トリックプレイ向け送信の動作概要を示す図である。図１０の１段目は標準的なＭＰＥＧのＧＯＰ構造（Ｉフレーム、Ｂフレーム、Ｐフレームの並び）の一例を示している。２段目はＧＯＰの並びの一例を示している。図１０の例では、０．５ｓｅｃごとにＧＯＰが構成されている。
【０１３２】
トリックプレイでは、早送りなどにより速い速度での再生が指定されたときに、コンテンツの加工等を行わずにそのまま速く再生すると、機器自体の処理速度をその分だけ速くしなくてはならず、コストが高くなる。このため、実際には再生する映像を間引くということを行っている。
【０１３３】
具体的には、ＭＰＥＧストリームデータのＩフレームだけを抽出して再生する。例えばＩフレームが０．５ｓｅｃ間隔で登場する場合、０．２５秒間隔で再生すると２倍速になる。さらに、Ｉフレーム自体を２つのうち１つだけを再生する（１つおきに再生する）ように間引くことで４倍速となる。さらに間引くと８倍速および１６倍速などが実現できる。また、再生するＩフレームの順番を逆順にすると巻き戻し再生が可能となる。早送りと同様の方式で巻き戻しの２倍速、４倍速、８倍速および１６倍速などが実現できる。図１０の下半分は、１倍速（ｘ１）から３２倍速（ｘ３２）までのＩフレームの抽出規則の例を示している。トリックプレイ中、クライアント端末はこのように再生を行う。従って、ＶＯＤサーバは、Ｉフレームを抽出して、指定された通りのタイミングでクライアント端末に対して送信する必要がある。
【０１３４】
図１１は、第３の実施形態に係るホストＣＰＵ２００−３の概略構成例を示すブロック図である。図１２は、第３の実施形態に係る通信処理部１４０−３の概略構成例を示すブロック図である。データ転送装置およびストレージの構成および機能は、第２の実施形態と同様であるため説明を省略する。
【０１３５】
図１１に示すように、第３の実施形態のホストＣＰＵ２００−３は、送信要求受付部２０８−３と、コンテンツメタデータ読み出し部２０９−３と、ファイル指定部２０１−３と、コンテンツメタ―データ解析部２１０−３と、送信データ特定部２０４−３と、管理情報読み出し指示部２０５−２と、エクステントマップ取得部２０６と、送信データ読み出し指示部２０７−２と、を備えている。
【０１３６】
第３の実施形態では、送信要求受付部２０８−３とコンテンツメタデータ読み出し部２０９−３とコンテンツメタ―データ解析部２１０−３を追加したこと、メタデータ指定部２０２とメタデータ解析部２０３が削除されたこと、および、ファイル指定部２０１−３と送信データ特定部２０４−３の機能が第２の実施形態と異なっている。その他の構成および機能は、第２の実施形態のブロック図である図５と同様であるので、同一符号を付し、ここでの説明は省略する。
【０１３７】
送信要求受付部２０８−３は、クライアント端末からのトリックプレイ向け送信要求を受け付ける。送信要求には、例えば、再生するコンテンツを特定するための情報、トリックプレイの再生モード（何倍速の早送りか巻き戻しかなど）、および、再生開始位置（コンテンツの開始時からの相対時間など）などが含まれる。
【０１３８】
本実施形態では、例えば、再生開始位置やトリックプレイの再生モードが特定情報に相当する。したがって、送信要求受付部２０８−３が、特定情報を含むメタデータを指定するメタデータ指定部２０２に相当する。
【０１３９】
ファイル指定部２０１−３は、送信要求をもとに、トリックプレイを行うファイル（以下、コンテンツともいう）を特定する。なお、コンテンツの特定方法はこれに限られるものではない。例えば、ファイル指定部２０１−３が、データ送信システムの動作状態などに応じて再生するコンテンツを特定するように構成してもよい。
【０１４０】
コンテンツメタデータ読み出し部２０９−３は、トリックプレイを行うコンテンツのコンテンツメタ―データをストレージ３００から読み出す。このように、本実施形態では、コンテンツメタデータをストレージ３００に記憶する。なお、ストレージ３００以外の記憶装置にコンテンツメタデータを記憶してもよい。コンテンツメタデータは、例えばコンテンツの全てのＩフレームの開始バイト位置と長さとを含む。
【０１４１】
コンテンツメタ―データ解析部２１０−３は、読み出されたコンテンツメタデータを参照し、コンテンツのＩフレームのバイト位置を解析する。送信データ特定部２０４−３は、解析されたバイト位置の情報をもとに、特定されたコンテンツの中の送信データ（送信するＩフレーム）を特定する。
【０１４２】
図１２に示すように、第３の実施形態の通信処理部１４０−３は、送信開始指示部１４１と、パケット送信指示部１４２と、送信判定部１４３と、ヘッダ生成部１４４と、データ読み出し部１４５と、パケット生成部１４６と、送信時刻生成部１４７と、先頭判定部１４８−３と、を備えている。
【０１４３】
第３の実施形態では、先頭判定部１４８−３を追加したことが第２の実施形態と異なっている。その他の構成および機能は、第２の実施形態の通信処理部１４０−２のブロック図である図８と同様であるので、同一符号を付し、ここでの説明は省略する。
【０１４４】
先頭判定部１４８−３は、次に送信するパケットがＩフレームの先頭か否かを判定する。
【０１４５】
図１３は、第３の実施形態におけるデータ転送処理の全体の流れを示すフローチャートである。
【０１４６】
まず、送信要求受付部２０８−３が、クライアント端末からトリックプレイ送信の要求を受ける（ステップＳ３０１）。送信要求の受付は、例えばＩＰＴＶ仕様ではＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）などで実現される。送信要求受付部２０８−３は、クライアント端末から指定されたトリックプレイの再生モード、再生開始位置を送信データ特定部２０４−３に渡す。
【０１４７】
ファイル指定部２０１−３は、受付けられた送信要求をもとに、いずれのコンテンツのトリックプレイを行うか特定し、特定したコンテンツの情報を送信データ特定部２０４−３に指定する（ステップＳ３０２）。
【０１４８】
コンテンツメタデータ読み出し部２０９−３は、特定されたコンテンツに対応するコンテンツメタデータを読み出す（ステップＳ３０３）。コンテンツメタ―データ解析部２１０−３は、読み出されたコンテンツメタデータを解析して、コンテンツ中の全Ｉフレームのバイト位置を取得する（ステップＳ３０４）。コンテンツメタ―データ解析部２１０−３は、取得したバイト位置を送信データ特定部２０４−３に渡す。
【０１４９】
送信データ特定部２０４−３は、特定されたコンテンツ、および、バイト位置の情報を利用し、実際にどのＩフレームを送信するか特定する（ステップＳ３０５）。例えば、再生開始時間が１０分１５秒のとき、ＧＯＰ間隔が０．５ｓｅｃとすると、送信データ特定部２０４−３は、（６０ｘ１０＋１５）／０．５＝１２３０個目のＧＯＰから再生すると特定できる。トリックプレイの再生モードが４倍速早送りであった場合、図１０の抽出規則に従ったとすると、Ｉフレームを１つおきに送信することになる。従って、送信データ特定部２０４−３は、１２３０個目、１２３２個目、１２３４個目、１２３６個目・・・のＩフレームを送信すると特定できる。また、送信データ特定部２０４−３は、コンテンツメタ―データ解析部２１０−３による解析結果から、特定したＩフレームそれぞれのコンテンツ中のバイト位置（先頭位置と先頭位置からの長さ）を特定できる。
【０１５０】
ステップＳ３０６からステップＳ３１３までは、第２の実施形態のデータ転送処理を示す図６のステップＳ２０５からステップＳ２１２までと同様の処理なので、その説明を省略する。
【０１５１】
なお、通信処理部１４０−３の動作は第２の実施形態と基本的には同じであるが、トリックプレイではＩフレームを０．５ｓｅｃ間隔で送信しなければならないので、そのための処理が異なる。以下に詳細を説明する。
【０１５２】
まず、送信データに相当するＩフレームは複数の送信パケットで構成される。また、前述の通り、送信パケットは例えば７個などのＭＰＥＧのＴＳパケットまたはＴＴＳパケット（単位パケット）で構成される。なお、以下では主にＴＴＳパケットを用いる例を説明するが、ＴＳパケットを用いる場合にも同様に適用できる。
【０１５３】
図１４は、Ｉフレームとパケットとの関係の一例を示す図である。図１４の上段は、抽出したＩフレームがデータバッファ１７０−２上に展開されている様子を示している。先ほどの例では、Ｉフレーム０が１２３０個目のＩフレームとなり、Ｉフレーム１が１２３２個目のＩフレームとなり、Ｉフレーム２が１２３４個目のＩフレームとなる。中段は、送信パケットの構成例を示している。例えばＩフレーム０はＰＫＴ０〜ＰＫＴｎ−１のｎ個の送信パケットに分割されて送信される。下段は、ＭＰＥＧ ＴＴＳパケットの構成例を示している。例えばＰＫＴ０はＴＴＳ０〜ＴＴＳ６で構成されている。
【０１５４】
各ＴＴＳは、第２の実施形態で述べたとおり、先頭４バイトにタイムスタンプ値を格納する。同じＩフレーム内の送信パケットを送信する場合は、第２の実施形態と同様にデータ読み出し部１４５が、タイムスタンプ値を読み出す。そして、送信時刻生成部１４７が、次パケットの送信時刻を求めるように動作する。
【０１５５】
一方、前述の通り、次のＩフレームは例えば０．２５ｓｅｃ後という時刻に定められている。従って、次パケットがＩフレームの先頭であった場合、送信時刻生成部１４７は、読み出したタイムスタンプ値とは関係なく、次パケットの送信時刻を、先のＩフレームの先頭となる送信パケット（図１４の場合はＰＫＴ０）を送信した時刻から、０．２５ｓｅｃ後に設定する。
【０１５６】
先頭判定部１４８−３は、このような動作を実現するために、次に送信するパケットがＩフレームの先頭か否かを判定するために用いられる。具体的には、まず、データ読み出し部１４５が、タイムスタンプ値にさらに続いてＴＳパケットのヘッダ（ＴＳヘッダ）を読み出すように構成する。先頭判定部１４８−３は、例えば読み出されたＴＳヘッダのＰＥＳの先頭を示すｐａｙｌｏａｄ＿ｕｎｉｔ＿ｓｔａｒｔ＿ｉｎｄｉｃａｔｏｒが１になっているかを確認する。コンテンツに映像以外のＴＳパケットも含んでいる場合は、先頭判定部１４８−３が、さらにＰＩＤがＶＩＤＥＯを示していることも併せて確認してもよい。
【０１５７】
図１４ではＴＴＳｘにてＩフレームの先頭が現れることが示されている。以上のＩフレーム先頭判定によって、同じＩフレーム内では通常再生と同様の短い間隔で送信パケットを送信しながら、次のＩフレームは０．２５ｓｅｃなど所定の長い時間間隔を空けて送信するという機能が実現できる。従って、例えばＩＰＴＶトリックプレイ向け送信に必要な断続的なＩフレームの送信が可能となる。なお、Ｉフレーム間隔はシステム仕様やコンテンツなどに依存する。従って、上記のＩフレーム間隔の０．５ｓｅｃという時間は一例でありこれに限られるものではない。
【０１５８】
以上のように、本実施形態では、ホストＣＰＵ２００−３が、図１０のようなＭＰＥＧデータから、再生に必要なＩフレームだけを抽出して、図１４で示したようなデータを、データ転送装置１００に渡す。したがって、データ転送装置１００は、トリックプレイを実現するために、Ｉフレームの先頭を検出して、パケットを送信するという処理をするだけでよい。すなわち、トリックプレイをする場合にも、データ転送装置１００は非常にシンプルな処理だけをすればよく、データ転送装置１００の構成をシンプルにできるという効果がある。
【０１５９】
次に、ＦＥＣパケットの送信を行う場合について説明する。ＦＥＣとは、送信するデータパケットに冗長データパケットを付加して、一部のデータパケットがネットワークの途中経路で損失した場合に、損失しなかった残りのデータパケットとその冗長データパケットを用いて、損失したデータパケットを復元する手法である。具体的には、データパケットＡ、Ｂ、Ｃを送信する場合、例えばＸ＝Ａ ｘｏｒ Ｂ ｘｏｒ Ｃのようにデータのペイロードをビット単位でＸＯＲして求めたデータパケットＸも併せて送信する。送信した結果、データパケットＢが損失した場合、受信側では、残りのデータパケットＡ、Ｃ、およびＸからＢ＝Ａ ｘｏｒ Ｃ ｘｏｒ ＸとしてデータパケットＢを復元することができる。ただし、データパケットＢとデータパケットＡなどのように２つのデータパケットを損失した場合などは復元することができない。
【０１６０】
ＩＰＴＶの場合もこのＦＥＣを応用してデータ（映像および音声データ）の損失を補うことがＰｒｏ−ＭＰＥＧ仕様により定められている。Ｐｒｏ−ＭＰＥＧでは、データパケットはＲＴＰパケットで送信される。例えば上記データパケットＡ、Ｂ、ＣがそのＲＴＰパケットに相当する。パケット長は一定であると定められており、上記のｘｏｒ演算はそれぞれのデータパケットの同じオフセットのビット同士で行われる。また、実際のデータはストリームとして伝送されるので、データパケットが次々と送信される。Ｐｒｏ−ＭＰＥＧでは所定数のデータパケットをグルーピングし、グルーピングしたデータパケットごとに順次ＦＥＣパケットを生成する。
【０１６１】
図１５および図１６は、ＦＥＣパケットを生成するためのデータパケットのグルーピングの一例を示す図である。図１５および図１６は、送信されるデータパケットを１０×１０のマトリクス上に並べて表示した様子を示している。図１５および図１６は、それぞれ縦方向、横方向にデータパケットをグルーピングしてＦＥＣパケットを生成する様子を示している。図１５のＦＥＣをＣｏｌｕｍｎ ＦＥＣ、図１６のＦＥＣをＲｏｗ ＦＥＣと呼ぶ。前述のように、これらのグルーピングされたデータパケットのうち、１つだけロスト（損失）した場合に受信側での復元が可能となる。
【０１６２】
Ｃｏｌｕｍｎ ＦＥＣは縦方向にグルーピングしていることから、横方向に連続したロスト、すなわち、バーストロストに強いという特徴を持つ。Ｒｏｗ ＦＥＣはＣｏｌｕｍｎ ＦＥＣを補うものであり、ランダムロストに対する耐性を高めるものである。
【０１６３】
以上のＦＥＣパケットは、本実施形態では次のように生成される。例えば、図１６の１つ目のＲｏｗ ＦＥＣの場合、データパケット１〜１０が送信された後に最初のＲｏｗ ＦＥＣであるＦ１が送信される。送信判定部１４３は、データパケットの送信後に、データパケットの現在のマトリクス中における位置を把握し、Ｃｏｌｕｍｎ ＦＥＣとＲｏｗ ＦＥＣを送るかどうかを判定する。例えばマトリクスが１０×１０で、この中のデータパケットを０〜９９で表したとき、データパケットが９、１９、２９、・・・、９９のときにＲｏｗ ＦＥＣを送信すると判定するなどのように構成できる。
【０１６４】
Ｒｏｗ ＦＥＣを送信すると判定された場合、ヘッダ生成部１４４は、ＦＥＣパケットのヘッダを生成する。また、データ読み出し部１４５は、当該ＦＥＣが保護する全てのデータパケット０〜９のデータを読み出す。そしてパケット生成部１４６は、生成されたヘッダと、読み出された全てのデータをＸＯＲしたデータをペイロードとして、ＦＥＣパケットを生成して出力する。
【０１６５】
ところで、以上のＦＥＣパケットは、トリックプレイ中、すなわち、Ｉフレーム送信を行っている場合も同様に送信される。しかし、そのままでは次のような問題が生じる。まず、Ｉフレームのデータ長は任意であるため、例えば先に例示した送信パケットの長さである１３４４バイト（＝１９２バイト（ＭＰＥＧ ＴＴＳパケットのサイズ）×７）の倍数にならない場合も存在する。より具体的には、Ｉフレームを構成するＴＴＳ数が必ずしも７の倍数にならない場合がある。
【０１６６】
一方、ＩＰＴＶ向けトリックプレイ方式では、１つの送信パケットの中に複数のＩフレームが混在してはいけないという仕様が定められている。
【０１６７】
前述のように本実施形態では、ホストＣＰＵ２００−３がＩフレームの位置を特定し、データ転送装置内のデータバッファ１７０−２にＩフレームのデータが一旦蓄えられ、Ｉフレームが送信パケットに分割されて送信される。また、データバッファ１７０−２上には異なるＩフレームが隙間なく詰められている。従って、あるＩフレームの終端となる送信パケットを生成したとき、そのＩフレームのＴＴＳ数が７の倍数ではない場合、その終端となる送信パケットに次のＩフレームの先頭部分が含まれることになる。すなわち、１つの送信パケットに複数のＩフレームが含まれることになり、仕様違反になる。
【０１６８】
これを防ぐためには、簡単には次のような方式が考えられる。例えばパケット生成部１４６などによりＩフレームの終端となる送信パケットを生成するときに、端数の部分にＮＵＬＬ ＴＴＳを挿入し、続きのデータ（すなわち次のＩフレームの先頭データ）は次の送信パケットから送信するように構成する方式である。なお、ＮＵＬＬ ＴＴＳとは、空のデータを含むＴＴＳパケットを意味する。しかし、この方式ではＦＥＣパケットを送信する場合には依然として次のような問題が残る。
【０１６９】
ＦＥＣパケットを生成するとき、データ読み出し部１４５は、保護対象のデータを読み出す。例えば先の１つ目のＲｏｗ ＦＥＣの例では、データ読み出し部１４５は、データパケット０〜９のデータを読み出す。具体的には、データバッファ１７０−２におけるデータパケット０の先頭データのアドレスをＢＡＳＥとすると、ＢＡＳＥ＋１３４４×０、ＢＡＳＥ＋１３４４×１、ＢＡＳＥ＋１３４４×２、・・・、１３４４×９のアドレスから、それぞれ１３４４バイトずつ読み出すという動作になる。
【０１７０】
同様に、１つ目のＣｏｌｕｍｎ ＦＥＣの例では、データ読み出し部１４５は、データパケット０、１０、２０、・・・、９０のデータを読み出すことになる。すなわち、データ読み出し部１４５は、ＢＡＳＥ＋１３４４×０、ＢＡＳＥ＋１３４４×１０、ＢＡＳＥ＋１３４４×２０、・・・、ＢＡＳＥ＋１３４４×９０のアドレスからそれぞれ１３４４バイトずつ読み出す。ただし、この処理は、各データパケットが必ずデータバッファ１７０−２の１３４４バイト固定長のデータに割り当てられていることが前提である。Ｉフレームの終端でＮＵＬＬ ＴＴＳが挿入されるとその前提が崩れるため、このような簡単な計算ではデータパケットの位置が求められなくなる。例えば、データパケット５が含まれるＩフレームの終端でＮＵＬＬ ＴＴＳが２つ挿入されている場合、データパケット６以降の先頭は、ＢＡＳＥ＋１３４４×６−１９２×２となる。
【０１７１】
従って、その場合でも正しく計算するためには、ＮＵＬＬ ＴＴＳを挿入した位置を全て記憶しておき、アドレス計算時にこれを鑑みて計算する必要がある。さらに、ＦＥＣパケット生成時に読み出したＩフレームの終端となる送信パケットの長さが、（ＴＴＳのサイズ）×７の倍数ではない場合、ＮＵＬＬ ＴＴＳを付加してパケット生成部１４６に渡す必要がある。しかし、このような構成は、処理が複雑になるという問題がある。
【０１７２】
そこでホストＣＰＵを図１７のように構成することが望ましい。図１７は、このように構成した第３の実施形態の変形例に係るホストＣＰＵ２００−３Ｂの構成例を示すブロック図である。
【０１７３】
本変形例では、ホストＣＰＵ２００−３Ｂは、パケット特定部２１１−３Ｂを備える。パケット特定部２１１−３Ｂは、特定されたＩフレームの長さから、Ｉフレーム長が、（データパケットを構成するＴＴＳ数）の倍数ではない場合に、倍数となるように終端に埋めるＮＵＬＬ ＴＴＳを特定する。なお、以下では、ＴＴＳを単位としてＩフレーム長を表す。例えば、１００個のＴＴＳからなるＩフレームの長さ（Ｉフレーム長）を１００ＴＴＳと表す。Ｉフレーム長の単位はこれに限られるものではなく、例えばバイトを単位として表してもよい。
【０１７４】
例えば、Ｉフレームの長さが１００ＴＴＳであった場合、１００は７で割り切れないが、５ＴＴＳを足して１０５ＴＴＳとすることで１０５／７＝１５と割り切れるようになる。このため、パケット特定部２１１−３Ｂは、５つのＴＴＳを送信すると特定する。
【０１７５】
例えばストレージ３００上にデータパケットを構成するＴＴＳ数−１（今回は６）個分の長さのＮＵＬＬ ＴＴＳファイルを用意しておく。パケット特定部２１１−３Ｂは、読み出すデータの先頭および長さを、それぞれ、ＮＵＬＬ ＴＴＳファイルの先頭、および、必要なＴＴＳ個数分の長さ（上記例では１９２×５＝９６０バイト）として、後段のエクステントマップ取得部２０６に指定する。
【０１７６】
エクステントマップ取得部２０６は、送信するＩフレームの後にこのＮＵＬＬ ＴＴＳファイルを処理する。これにより、データバッファ１７０−２上には７ＴＴＳで割り切れないＩフレームの終端にはＮＵＬＬ ＴＴＳが挿入される。すなわち、データ転送装置は、常にＩフレームが７ＴＴＳで割り切れるものとして扱うことができる。従って、ＮＵＬＬ ＴＴＳを挿入する必要がなくなるだけでなく、ＦＥＣパケット生成の際のデータ読み出しアドレスの計算処理も容易にすることができる。
【０１７７】
なお、ＮＵＬＬ ＴＴＳの挿入は、以上の方法に限られない。例えば、ホストＣＰＵ２００−３Ｂが直接データバッファに書き込む、あるいは、ＮＵＬＬ ＴＴＳを生成する処理部をデータ転送装置内に別途設け、それによって書き込むような形態でもよい。本変形例のポイントは、Ｉフレームが７×ＴＴＳの長さで割り切れないとき、データ抽出部が、パケット特定部が特定した個数×ＴＴＳの長さを空けて、次のＩフレームのデータを書き込むことである。これによって、ＦＥＣの計算が前述のように容易になる。よって、さらにいうと必ずしもＮＵＬＬ ＴＴＳをデータバッファに書き込む必要はなく、データ抽出部が間を空けるだけ空けておき、データ読み出し部がデータを読み出した後に、空けられたところのデータ（不定値が入っている）をＮＵＬＬ ＴＴＳで置換するような形態でもよい。
【０１７８】
以上説明したとおり、第１から第３の実施形態によれば、ホストＣＰＵの処理負担を軽減させて、効率的なデータ転送が可能となる。また、コンテンツ配信サーバの主要機能であるトリックプレイ向け送信での効率的な処理が実現できる。
【０１７９】
上述した各実施形態で説明したデータ送信システムの少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、データ送信システムの少なくとも一部の機能を実現するプログラムをフレキシブルディスクやＣＤ−ＲＯＭ等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリ等の固定型の記録媒体でもよい。
【０１８０】
また、データ送信システムの少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、または記録媒体に収納して頒布してもよい。
【０１８１】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１８２】
１００ データ転送装置
１１０ コマンド発行部
１２０ 通知振り分け部
１３０ 送信データ抽出部
１４０ 通信処理部
１５０−２ フロー制御部
１６０−２ バッファ管理部
１７０−２ データバッファ
２００ ホストＣＰＵ
２０１ ファイル指定部
２０２ メタデータ指定部
２０３ メタデータ解析部
２０４ 送信データ特定部
２０５ 管理情報読み出し指示部
２０６ エクステントマップ取得部
２０７ 送信データ読み出し指示部
３００ ストレージ
４００ ネットワーク
【特許請求の範囲】
【請求項１】
制御装置と接続され、記憶装置にブロック単位で記憶されているデータをネットワークに送信するデータ転送装置であって、
前記制御装置から読み出しが指示されたブロックの読み出しコマンドを前記記憶装置に対して発行するコマンド発行部と、
前記読み出しコマンドに応じて前記記憶装置から読み出されたデータから送信データを抽出する送信データ抽出部と、
予め定められたプロトコルに基づいて、抽出された前記送信データをネットワークに送信する通信処理部と、
を備えることを特徴とするデータ転送装置。
【請求項２】
制御装置と、記憶装置にブロック単位で記憶されているデータをネットワークに送信するデータ転送装置と、を備えるデータ送信システムであって、
前記制御装置は、
前記記憶装置に記憶されたデータのうち送信するデータを表す送信データを含むファイルを指定するファイル指定部と、
前記ファイル内での前記送信データの位置の特定に用いる特定情報を含むメタデータを指定するメタデータ指定部と、
前記特定情報に基づいて、前記ファイル内での前記送信データの位置を特定する送信データ特定部と、
特定された位置の前記送信データを含むブロックの読み出しを前記データ転送装置に対して指示する送信データ読み出し指示部と、を備え、
前記データ転送装置は、
読み出しが指示されたブロックの読み出しコマンドを前記記憶装置に対して発行するコマンド発行部と、
前記読み出しコマンドに応じて前記記憶装置から読み出されたデータから前記送信データを抽出する送信データ抽出部と、
予め定められたプロトコルに基づいて、抽出された前記送信データをネットワークに送信する通信処理部と、を備える、
ことを特徴とするデータ送信システム。
【請求項３】
前記ファイルは、ＭＰＥＧストリームデータであり、
前記ＭＰＥＧストリームデータのＩフレームの位置を特定するコンテンツメタデータを取得するコンテンツメタデータ取得部を更に備え、
前記特定情報は、トリックプレイの再生方向および再生速度の少なくとも一方を含み、
前記送信データ特定部は、前記特定情報と、前記コンテンツメタデータとに基づいて、送信する前記Ｉフレームと、前記ファイル内での該Ｉフレームのバイト位置とを特定すること、
を特徴とする請求項２に記載のデータ送信システム。
【請求項４】
前記制御装置は、
特定された前記送信データと前記ブロックとの対応を表すマップ情報を前記記憶装置から取得するマップ取得部をさらに備え、
前記送信データ読み出し指示部は、さらに、前記マップ情報に基づいて、前記ブロック内の前記送信データの位置を示す位置情報を前記データ転送装置に対して送信し、
前記送信データ抽出部は、前記位置情報に基づいて、前記読み出しコマンドに応じて前記記憶装置から読み出されたデータから前記送信データを抽出すること、
を特徴とする請求項２に記載のデータ送信システム。
【請求項５】
抽出された前記送信データを記憶するバッファ部と、
前記送信データ読み出し指示部により読み出しが指示されたブロックのうち、前記バッファ部の空き容量以下のサイズのブロックの読み出しを前記コマンド発行部に指示するフロー制御部と、をさらに備え、
前記通信処理部は、前記プロトコルに基づいて、前記バッファ部に記憶された前記送信データをネットワークに送信すること、
を特徴とする請求項２に記載のデータ送信システム。
【請求項６】
前記通信処理部は、
前記送信データの送信単位となる送信パケットの送信時刻を生成する時刻生成部と、
前記送信時刻に達したときに、前記送信パケットのペイロードを前記バッファ部から読み出すデータ読み出し部と、
読み出された前記ペイロードに付加するヘッダを生成するヘッダ生成部と、
読み出された前記ペイロードに前記ヘッダを付加した前記送信パケットを生成してネットワークに送信するパケット生成部と、を備えること、
を特徴とする請求項５に記載のデータ送信システム。
【請求項７】
前記時刻生成部は、前記送信データのビットレートに基づいて前記送信時刻を生成すること、
を特徴とする請求項６に記載のデータ送信システム。
【請求項８】
前記送信パケットの構成単位である単位パケットはタイムスタンプを含み、
前記データ読み出し部は、さらに、読み出した前記ペイロードの次に送信する前記ペイロードの先頭の単位パケットに含まれる前記タイムスタンプを前記バッファ部から読み出し、
前記時刻生成部は、読み出された前記タイムスタンプに基づいて前記送信時刻を生成すること、
を特徴とする請求項６に記載のデータ送信システム。
【請求項９】
前記単位パケットは前記タイムスタンプを先頭に含み、
前記バッファ部は、前記単位パケットを送信する順序で前記単位パケットを連続して記憶し、
前記データ読み出し部は、前記送信時刻に達した前記送信パケットと、前記送信時刻に達した前記送信パケットの次に送信する前記送信パケットの先頭の前記単位パケットに含まれる前記タイムスタンプと、を一括して読み出すこと、
を特徴とする請求項８に記載のデータ送信システム。
【請求項１０】
前記送信データは、ＭＰＥＧストリームデータのＩフレームであり、
前記送信パケットは、ＭＰＥＧのＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）パケットまたはＴＴＳ（Ｔｉｍｅｓｔａｍｐｅｄ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）パケットである複数の単位パケットを含み、
前記単位パケットは、前記Ｉフレームの先頭の単位パケットであるか否かを判定する判定情報を含み、
前記データ読み出し部は、さらに、読み出した前記送信パケットの次に送信する前記送信パケットの先頭の単位パケットに含まれる前記判定情報を前記バッファ部から読み出し、
前記判定情報に基づいて、次に送信する前記送信パケットの先頭の単位パケットがＩフレームの先頭の単位パケットであるか否かを判定する先頭判定部をさらに備え、
前記時刻生成部は、次に送信する前記送信パケットの先頭の単位パケットがＩフレームの先頭の単位パケットであると判定された場合、Ｉフレームの送信間隔に応じた前記送信時刻を生成すること、
を特徴とする請求項６に記載のデータ送信システム。
【請求項１１】
前記送信パケットは、予め定められた規定数の前記単位パケットを含み、
前記制御装置は、
送信するＩフレームに含まれる単位パケットの個数が、前記規定数の倍数でない場合に、送信するＩフレームに含まれる単位パケットの個数が、前記規定数の倍数となるように、送信するＩフレームに付加する単位パケットの個数を特定するパケット特定部をさらに備え、
前記送信データ読み出し指示部は、特定された前記送信データを含むブロックの読み出しと、特定された個数の単位パケットの読み出しと、を前記データ転送装置に対して指示すること、
を特徴とする請求項１０に記載のデータ送信システム。
【請求項１２】
前記送信パケットは、予め定められた規定数の前記単位パケットを含み、
前記制御装置は、
送信するＩフレームに含まれる単位パケットの個数が、前記規定数の倍数でない場合に、送信するＩフレームに含まれる単位パケットの個数が、前記規定数の倍数となるように、送信するＩフレームに付加する単位パケットの個数を特定するパケット特定部をさらに備え、
前記バッファ部は、抽出された前記送信データを、特定された個数の単位パケットのオフセットをつけた位置に記憶すること、
を特徴とする請求項１０に記載のデータ送信システム
【請求項１３】
前記データ転送装置は、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）−Ｅｘｐｒｅｓｓカードとして構成されること、
を特徴とする請求項２に記載のデータ送信システム。
【請求項１４】
制御装置と、記憶装置にブロック単位で記憶されているデータをネットワークに送信するデータ転送装置と、を備えるデータ送信システムで実行されるデータ送信方法であって、
前記制御装置が、前記記憶装置に記憶されたデータのうち送信するデータを表す送信データを含むファイルを指定するファイル指定ステップと、
前記制御装置が、前記ファイル内での前記送信データの位置の特定に用いる特定情報を含むメタデータを指定するメタデータ指定ステップと、
前記制御装置が、前記特定情報に基づいて、前記ファイル内での前記送信データの位置を特定する送信データ特定ステップと、
前記制御装置が、特定された位置の前記送信データを含むブロックの読み出しを前記データ転送装置に対して指示する送信データ読み出し指示ステップと、
前記データ転送装置が、読み出しが指示されたブロックの読み出しコマンドを前記記憶装置に対して発行するコマンド発行ステップと、
前記データ転送装置が、前記読み出しコマンドに応じて前記記憶装置から読み出されたデータから前記送信データを抽出する送信データ抽出ステップと、
前記データ転送装置が、予め定められたプロトコルに基づいて、抽出された前記送信データをネットワークに送信する通信処理ステップと、
を含むことを特徴とするデータ送信方法。
【請求項１５】
コンピュータを、
記憶装置に記憶されたデータのうち送信するデータを表す送信データを含むファイルを指定するファイル指定部と、
前記ファイル内での前記送信データの位置の特定に用いる特定情報を含むメタデータを指定するメタデータ指定部と、
前記特定情報に基づいて、前記ファイル内での前記送信データの位置を特定する送信データ特定部と、
特定された位置の前記送信データを含むブロックの読み出しを指示する送信データ読み出し指示部と
読み出しが指示されたブロックの読み出しコマンドを前記記憶装置に対して発行するコマンド発行部と、
前記読み出しコマンドに応じて前記記憶装置から読み出されたデータから前記送信データを抽出する送信データ抽出部と、
予め定められたプロトコルに基づいて、抽出された前記送信データをネットワークに送信する通信処理部、
として機能させるためのデータ転送プログラム。
【請求項１】
制御装置と接続され、記憶装置にブロック単位で記憶されているデータをネットワークに送信するデータ転送装置であって、
前記制御装置から読み出しが指示されたブロックの読み出しコマンドを前記記憶装置に対して発行するコマンド発行部と、
前記読み出しコマンドに応じて前記記憶装置から読み出されたデータから送信データを抽出する送信データ抽出部と、
予め定められたプロトコルに基づいて、抽出された前記送信データをネットワークに送信する通信処理部と、
を備えることを特徴とするデータ転送装置。
【請求項２】
制御装置と、記憶装置にブロック単位で記憶されているデータをネットワークに送信するデータ転送装置と、を備えるデータ送信システムであって、
前記制御装置は、
前記記憶装置に記憶されたデータのうち送信するデータを表す送信データを含むファイルを指定するファイル指定部と、
前記ファイル内での前記送信データの位置の特定に用いる特定情報を含むメタデータを指定するメタデータ指定部と、
前記特定情報に基づいて、前記ファイル内での前記送信データの位置を特定する送信データ特定部と、
特定された位置の前記送信データを含むブロックの読み出しを前記データ転送装置に対して指示する送信データ読み出し指示部と、を備え、
前記データ転送装置は、
読み出しが指示されたブロックの読み出しコマンドを前記記憶装置に対して発行するコマンド発行部と、
前記読み出しコマンドに応じて前記記憶装置から読み出されたデータから前記送信データを抽出する送信データ抽出部と、
予め定められたプロトコルに基づいて、抽出された前記送信データをネットワークに送信する通信処理部と、を備える、
ことを特徴とするデータ送信システム。
【請求項３】
前記ファイルは、ＭＰＥＧストリームデータであり、
前記ＭＰＥＧストリームデータのＩフレームの位置を特定するコンテンツメタデータを取得するコンテンツメタデータ取得部を更に備え、
前記特定情報は、トリックプレイの再生方向および再生速度の少なくとも一方を含み、
前記送信データ特定部は、前記特定情報と、前記コンテンツメタデータとに基づいて、送信する前記Ｉフレームと、前記ファイル内での該Ｉフレームのバイト位置とを特定すること、
を特徴とする請求項２に記載のデータ送信システム。
【請求項４】
前記制御装置は、
特定された前記送信データと前記ブロックとの対応を表すマップ情報を前記記憶装置から取得するマップ取得部をさらに備え、
前記送信データ読み出し指示部は、さらに、前記マップ情報に基づいて、前記ブロック内の前記送信データの位置を示す位置情報を前記データ転送装置に対して送信し、
前記送信データ抽出部は、前記位置情報に基づいて、前記読み出しコマンドに応じて前記記憶装置から読み出されたデータから前記送信データを抽出すること、
を特徴とする請求項２に記載のデータ送信システム。
【請求項５】
抽出された前記送信データを記憶するバッファ部と、
前記送信データ読み出し指示部により読み出しが指示されたブロックのうち、前記バッファ部の空き容量以下のサイズのブロックの読み出しを前記コマンド発行部に指示するフロー制御部と、をさらに備え、
前記通信処理部は、前記プロトコルに基づいて、前記バッファ部に記憶された前記送信データをネットワークに送信すること、
を特徴とする請求項２に記載のデータ送信システム。
【請求項６】
前記通信処理部は、
前記送信データの送信単位となる送信パケットの送信時刻を生成する時刻生成部と、
前記送信時刻に達したときに、前記送信パケットのペイロードを前記バッファ部から読み出すデータ読み出し部と、
読み出された前記ペイロードに付加するヘッダを生成するヘッダ生成部と、
読み出された前記ペイロードに前記ヘッダを付加した前記送信パケットを生成してネットワークに送信するパケット生成部と、を備えること、
を特徴とする請求項５に記載のデータ送信システム。
【請求項７】
前記時刻生成部は、前記送信データのビットレートに基づいて前記送信時刻を生成すること、
を特徴とする請求項６に記載のデータ送信システム。
【請求項８】
前記送信パケットの構成単位である単位パケットはタイムスタンプを含み、
前記データ読み出し部は、さらに、読み出した前記ペイロードの次に送信する前記ペイロードの先頭の単位パケットに含まれる前記タイムスタンプを前記バッファ部から読み出し、
前記時刻生成部は、読み出された前記タイムスタンプに基づいて前記送信時刻を生成すること、
を特徴とする請求項６に記載のデータ送信システム。
【請求項９】
前記単位パケットは前記タイムスタンプを先頭に含み、
前記バッファ部は、前記単位パケットを送信する順序で前記単位パケットを連続して記憶し、
前記データ読み出し部は、前記送信時刻に達した前記送信パケットと、前記送信時刻に達した前記送信パケットの次に送信する前記送信パケットの先頭の前記単位パケットに含まれる前記タイムスタンプと、を一括して読み出すこと、
を特徴とする請求項８に記載のデータ送信システム。
【請求項１０】
前記送信データは、ＭＰＥＧストリームデータのＩフレームであり、
前記送信パケットは、ＭＰＥＧのＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）パケットまたはＴＴＳ（Ｔｉｍｅｓｔａｍｐｅｄ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）パケットである複数の単位パケットを含み、
前記単位パケットは、前記Ｉフレームの先頭の単位パケットであるか否かを判定する判定情報を含み、
前記データ読み出し部は、さらに、読み出した前記送信パケットの次に送信する前記送信パケットの先頭の単位パケットに含まれる前記判定情報を前記バッファ部から読み出し、
前記判定情報に基づいて、次に送信する前記送信パケットの先頭の単位パケットがＩフレームの先頭の単位パケットであるか否かを判定する先頭判定部をさらに備え、
前記時刻生成部は、次に送信する前記送信パケットの先頭の単位パケットがＩフレームの先頭の単位パケットであると判定された場合、Ｉフレームの送信間隔に応じた前記送信時刻を生成すること、
を特徴とする請求項６に記載のデータ送信システム。
【請求項１１】
前記送信パケットは、予め定められた規定数の前記単位パケットを含み、
前記制御装置は、
送信するＩフレームに含まれる単位パケットの個数が、前記規定数の倍数でない場合に、送信するＩフレームに含まれる単位パケットの個数が、前記規定数の倍数となるように、送信するＩフレームに付加する単位パケットの個数を特定するパケット特定部をさらに備え、
前記送信データ読み出し指示部は、特定された前記送信データを含むブロックの読み出しと、特定された個数の単位パケットの読み出しと、を前記データ転送装置に対して指示すること、
を特徴とする請求項１０に記載のデータ送信システム。
【請求項１２】
前記送信パケットは、予め定められた規定数の前記単位パケットを含み、
前記制御装置は、
送信するＩフレームに含まれる単位パケットの個数が、前記規定数の倍数でない場合に、送信するＩフレームに含まれる単位パケットの個数が、前記規定数の倍数となるように、送信するＩフレームに付加する単位パケットの個数を特定するパケット特定部をさらに備え、
前記バッファ部は、抽出された前記送信データを、特定された個数の単位パケットのオフセットをつけた位置に記憶すること、
を特徴とする請求項１０に記載のデータ送信システム
【請求項１３】
前記データ転送装置は、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）−Ｅｘｐｒｅｓｓカードとして構成されること、
を特徴とする請求項２に記載のデータ送信システム。
【請求項１４】
制御装置と、記憶装置にブロック単位で記憶されているデータをネットワークに送信するデータ転送装置と、を備えるデータ送信システムで実行されるデータ送信方法であって、
前記制御装置が、前記記憶装置に記憶されたデータのうち送信するデータを表す送信データを含むファイルを指定するファイル指定ステップと、
前記制御装置が、前記ファイル内での前記送信データの位置の特定に用いる特定情報を含むメタデータを指定するメタデータ指定ステップと、
前記制御装置が、前記特定情報に基づいて、前記ファイル内での前記送信データの位置を特定する送信データ特定ステップと、
前記制御装置が、特定された位置の前記送信データを含むブロックの読み出しを前記データ転送装置に対して指示する送信データ読み出し指示ステップと、
前記データ転送装置が、読み出しが指示されたブロックの読み出しコマンドを前記記憶装置に対して発行するコマンド発行ステップと、
前記データ転送装置が、前記読み出しコマンドに応じて前記記憶装置から読み出されたデータから前記送信データを抽出する送信データ抽出ステップと、
前記データ転送装置が、予め定められたプロトコルに基づいて、抽出された前記送信データをネットワークに送信する通信処理ステップと、
を含むことを特徴とするデータ送信方法。
【請求項１５】
コンピュータを、
記憶装置に記憶されたデータのうち送信するデータを表す送信データを含むファイルを指定するファイル指定部と、
前記ファイル内での前記送信データの位置の特定に用いる特定情報を含むメタデータを指定するメタデータ指定部と、
前記特定情報に基づいて、前記ファイル内での前記送信データの位置を特定する送信データ特定部と、
特定された位置の前記送信データを含むブロックの読み出しを指示する送信データ読み出し指示部と
読み出しが指示されたブロックの読み出しコマンドを前記記憶装置に対して発行するコマンド発行部と、
前記読み出しコマンドに応じて前記記憶装置から読み出されたデータから前記送信データを抽出する送信データ抽出部と、
予め定められたプロトコルに基づいて、抽出された前記送信データをネットワークに送信する通信処理部、
として機能させるためのデータ転送プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２０１３−６２６８３（Ｐ２０１３−６２６８３Ａ）
【公開日】平成２５年４月４日（２０１３．４．４）
【国際特許分類】
【出願番号】特願２０１１−１９９８１４（Ｐ２０１１−１９９８１４）
【出願日】平成２３年９月１３日（２０１１．９．１３）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２５年４月４日（２０１３．４．４）
【国際特許分類】
【出願日】平成２３年９月１３日（２０１１．９．１３）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]