JP2012098838A - データ送信システムおよびデータ送信プログラム - Google Patents

Abstract

【課題】ハードウェアコストを増大させずにホストＣＰＵの処理負担を軽減させて、効率的にデータ転送を行えるようにする。
【解決手段】データ送信システムは、プロセッサ２と、格納されたデータをブロック単位でＩ／Ｏバス上に送信するデータ記録装置４と、Ｉ／Ｏバスに接続されてプロセッサ２に代行して所定の通信プロトコル処理を行うプロトコル処理装置５と、を備える。プロセッサ２は、データ記録装置４から送信されるべきデータをブロック単位で特定するデータ特定部２１と、プロトコル処理装置５のアドレス情報を指定して、データ記録装置４からプロトコル処理装置５へのデータ転送を指示する転送指示部２３と、を有する。プロトコル処理装置５は、データ記録装置４からブロック単位でＩ／Ｏバスに送信されたデータを、主記憶装置を経由せずに直接受け付けるデータ受付部５１と、データ受付部５１で受け付けたブロック単位のデータをパケット単位でネットワークに送信するネットワーク処理部５３と、を有する。
【選択図】図１

Description

本発明の実施形態は、プロセッサに代行して通信プロトコル処理を行うＴＯＥ装置を備えたデータ送信システムおよびデータ送信プログラムに関する。

コンピュータに直接接続されたＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）はＤＡＳ（Direct Attached Storage）と呼ばれているが、これらのストレージをネットワーク経由で接続するネットワークストレージが普及しつつある。ネットワークストレージは、大きく分けるとＳＡＮ（Storage Area Network）とＮＡＳ（Network Attached Storage）に分類できる。ＳＡＮはiSCSIやFiber Channel等が知られており、ストレージ装置はブロックデバイスとしてネットワーク経由でホストマシン（ストレージを利用する側のマシン）と接続して、ホストマシン側にファイルシステムを持っている。一方、ＮＡＳはＮＦＳ（Network File System）等が知られており、ストレージ装置側にファイルシステムまでを組み込んでおり、ホスト装置はファイルシステムの上位からストレージにアクセスできる。これにより、ホストマシンの負荷を軽減できるだけでなく、複数台のホストマシンでストレージ上のファイルシステムを共有できる等のメリットがある。

これらのネットワークストレージでは、その通信手段に主にイーサネット（登録商標）が使われ、また通信プロトコルにはインターネット等で広く使われているTCP/IP等が使われる。これらの広く普及した汎用技術によりネットワークストレージの利用が容易となり、ネットワークストレージは従来のＤＡＳに比べ、ストレージとしての拡張性や保守性等の利便性が向上した。

また、昨今では映像のストリーミング配信が普及しつつある。例えばＶＯＤ（Video On Demand）サーバと呼ばれるコンテンツ配信サーバによってストリーミング配信が行われるが、このようなコンテンツ配信サーバも、自身がもつストレージデバイスから映像コンテンツを読み出し、ネットワーク接続されたユーザの端末に送信する処理を行う。Webサーバも同様にストレージ上のコンテンツをユーザの端末に送信する。通信プロトコルは、TCP/IPベースのＨＴＴＰや、リアルタイム通信向けのＲＴＰ等が使われる。また、ＲＴＰの場合は誤り訂正にＦＥＣ（Forward Error Correction）等が使われる。

このようなネットワークストレージ、ＶＯＤサーバ、Ｗｅｂサーバに用いられるストレージやネットワーク等のデバイスの高速化は著しく進んでいる。イーサネットは現在1Gbpsが主流になりつつあり、データセンター等では10Gbpsが使われている。また、次世代の40Gbps / 100Gbpsイーサネットの仕様策定も完了し、これらについても今後着実に普及していくものと思われる。また、ストレージに関してはＨＤＤのRAIDのストライピング処理（並列化）による高速化に加えて、昨今のＳＳＤの転送性能の向上は著しく、現行製品でも単体で2Gbps超の読み出しレートを出すものがある。ストレージデバイスのＩ／Ｆ規格のSATAに関しても、バンド幅6GbpsのSATA3.0が既に普及している状況である。これらを鑑みるとネットワークストレージに関しても、近い将来に10Gbpsクラスの帯域になるものと予想される。

このようなネットワークストレージの性能向上に伴って、それを制御するホストＣＰＵの処理負荷も増大していく。従来はTCP/IPオフロードエンジン（以下、ＴＯＥ）という技術により、その解決が試みられてきた。ＴＯＥは、ホストＣＰＵに代行して、前述のTCP/IPの処理を行う専用プロセッサや専用回路を設けたものであり、ホストＣＰＵからTCP/IP処理負荷をオフロードするものである。このＴＯＥを用いることによって、従来のソフトウェアによる通信プロトコル処理よりも高速にTCP/IP処理を行うことが可能となり、ネットワークストレージの性能向上に貢献できる。

ストレージデバイスやＴＯＥは、それぞれホストＣＰＵによってスレーブ的に制御され、データはシステムメモリを介して入出力することが想定されている。よって、ストレージ上のデータをネットワークに入出力する際、ストレージデバイス（ＳＳＤ、ＨＤＤ等）とＴＯＥの間のデータ転送は、必ずシステムメモリを介して行われる。

また、ホストＣＰＵ上で動作する、これらの間をブリッジするアプリケーションソフトウェア、あるいは、ＯＳのカーネル空間とユーザ空間のデータの受け渡し処理等により、システムメモリ上で何回分か転送データのコピーが発生する場合もある。さらにＮＡＳの場合はファイルシステム処理も必要であり、通常のファイルシステムの実装では、ストレージから固定バイト長のセクタ単位で読み書きしたデータを、任意バイト長のファイルとして整形するため、ここでもデータのコピーが発生する。

特開2005-316629号公報

このように、ストレージデバイスとＴＯＥの間でデータ転送を行う場合は、ホストＣＰＵのソフトウェア処理が介在することから、少なくとも一回はシステムメモリへの読み書きが必要となり、また、ＯＳやアプリケーション、ファイルシステムの処理により、システムメモリ上で場合によっては複数回分のメモリコピーが発生することになり、システムメモリの負荷が大幅に増大してしまう。

このようなメモリ負荷に対し、従来は十分な処理性能を持つホストＣＰＵと高速のシステムメモリを用意して対応していたが、昨今のネットワークストレージの10Gbpsに迫る転送レートの向上を鑑みると、少なからず問題となってきた。特に、システムメモリの性能を上げるためには、一般にホストＣＰＵのグレードアップも伴い、ＰＣやサーバ等の場合は、付随するチップセットのグレードアップも必要となる。これにより、コストや消費電力の問題が特に顕著となる。

本発明は、ハードウェアコストを増大させずにホストＣＰＵの処理負担を軽減させて、効率的にデータ転送を行うことができるデータ送信システムおよびデータ送信プログラムを提供するものである。

本実施形態に係るデータ送信システムは、主記憶装置に対する読み書きを行うことが可能なプロセッサと、格納されたデータをブロック単位でＩ／Ｏバス上に送信するデータ記録装置と、前記Ｉ／Ｏバスに接続され、前記プロセッサに代行して所定の通信プロトコル処理を行うプロトコル処理装置と、を備えている。前記プロセッサは、前記データ記録装置から送信されるべきデータをブロック単位で特定するデータ特定部と、前記プロトコル処理装置のアドレス情報を指定して、前記データ記録装置から前記プロトコル処理装置へのデータ転送を指示する転送指示部と、を有する。前記プロトコル処理装置は、前記データ記録装置からブロック単位で前記Ｉ／Ｏバスに送信されたデータを、前記主記憶装置を経由せずに直接受け付けるデータ受付部と、前記データ受付部で受け付けたブロック単位のデータをパケット単位でネットワークに送信するネットワーク処理部と、を有する。

第１の実施形態に係るデータ送信システムの概略構成を示すブロック図。 主記憶空間の一例を示す図。 ネットワークに送信するデータの一例を示す図。 転送指示の番号とＴＯＥのアドレス領域との関係を示す図。 第１の実施形態の変形例を示すブロック図。 第２の実施形態に係るデータ送信システムの概略構成を示すブロック図。 コネクション識別子とＴＯＥのアドレス領域との関係を示す図。 第３の実施形態に係るデータ送信システムの概略構成を示すブロック図。

以下、図面を参照しながら、本発明の実施形態を説明する。

（第１の実施形態）
図１は第１の実施形態に係るデータ送信システムの概略構成を示すブロック図である。図１のデータ送信システムの具体的な製品形態としては、ＰＣ、サーバ装置、ＳｏＣ（System on Chip）、またはＦＰＧＡ（Field Programmable Gate Array）等のネットワークストレージ、あるいはＶＯＤ（Video On Demand）サーバ、Webサーバなどが想定されるが、これらに限定されるものではない。

図１のデータ送信システム１は、ホストＣＰＵ（プロセッサ）２と、システムメモリ３と、ストレージデバイス（データ記録装置）４と、ＴＯＥ（プロトコル処理装置）５と、を備えている。ホストＣＰＵ２は、システム全体の制御を行う。ホストＣＰＵ２は、ソフトウェアで実行する主な処理部として、ファイルシステム処理部（データ特定部）２１と、ＴＯＥ５に転送データの有効データ位置を通知する有効位置通知部２２と、ストレージデバイス４に転送データの転送指示を行う転送指示部２３とを有する。もちろん、ホストＣＰＵ２は、他の種々の処理を行うことが可能である。有効位置通知部２２は、ファイルシステム処理部２１が特定した転送データと、この転送データ中の有効データの位置情報とを、ＴＯＥ５が関連付けできるように、ＴＯＥ５に有効データの位置情報を通知する。

システムメモリ３は、ホストＣＰＵ２が主記憶として使用するメモリであり、ホストＣＰＵ２の主記憶空間上にマッピングされる複数のメモリ領域に分かれている。システムメモリ３の具体的な実装形態は、例えばＳＳＤ（Solid State Drive）やＨＤＤ（Hard Disk Drive）等である。

ＴＯＥ５は、ホストＣＰＵ２の代わりにネットワークプロトコル処理を行うものである。ＴＯＥ５は、ストレージデバイス４から送られてきた転送データを受け付けるデータ受付部５１と、受け付けたデータと有効データ位置情報から有効データを抽出するデータ抽出部５２と、抽出したデータをネットワーク１０上に送信するネットワーク処理部５３とを有する。

ホストＣＰＵ２とシステムメモリ３はメインバスＢ１に接続され、ストレージデバイス４とＴＯＥ５はＩ／ＯバスＢ２に接続されている。メインバスＢ１とＩ／ＯバスＢ２の間にはＩ／Ｏブリッジ６が設けられている。ここで、Ｉ／ＯバスＢ２とは、本システムがＰＣやサーバ等の場合はチップセット、あるいはＰＣＩ Ｅｘｐｒｅｓｓバス等を指す。本システムがＳｏＣやＦＰＧＡの場合はチップ内のバスを指す。このように、Ｉ／ＯバスＢ２は、実装形態により種々異なるが、異なる装置間で直接通信でき、そのときシステムメモリのバス帯域を占有しないことが要求される。

通常、ホストＣＰＵ２は、デバイスドライバ等の制御ソフトウェアを実行することで、ストレージデバイス４とＴＯＥ５を制御する。

ＴＯＥ５は、ハードウェアとソフトウェアのどちらで構成してもよく、実装の形態は問わない。また、ＴＯＥ５が処理するプロトコルは、TCP/IPには限定されず、通信プロトコルの種別は問わない。例えば、ＨＴＴＰやＲＴＰ等の他の通信プロトコルを処理するものでもよい。そのようなものも含め、ここでは簡単のためＴＯＥ５と表記する。

ストレージデバイス４は、データをセクタやクラスタやページと呼ばれる単位で管理する。ここでは簡単のため、これらを総称してブロックと呼ぶ。ユーザが扱うデータはブロック単位ではないため、ストレージデバイス４は通常ファイルシステムによりアクセスされる。ファイルシステムは、バイト単位のファイルデータをブロック単位のストレージデバイスの記録領域にマッピングする仕組みである。ファイルシステムは、公知のものを利用するため、その詳細は割愛する。

図１の点線矢印は制御の流れ、太線矢印は転送データの流れを示す。本実施形態では、データをストレージデバイス４から読み出して、Ｉ／ＯバスＢ２を介してＴＯＥ５に直接転送し、ＴＯＥ５からネットワーク１０に送信する。

次に、図１のデータ送信システム１の処理動作を説明する。まず、ホストＣＰＵ２は何らかのアプリケーション処理（不図示）等によって、送信するファイルを特定する。典型的な例としては、ネットワーク１０に接続された他の機器からの要求を受け、ファイルを特定する。この処理は本実施形態とは無関係なので詳細は割愛する。

次に、ファイルシステム処理部２１は、ストレージデバイス４内のファイルシステムを解析し、特定されたファイルのデータが格納されているブロック群を特定する。データは、通常は複数のブロックで構成されており、まずは先頭ブロックを特定する。転送指示部２３は、特定したブロックの転送指示をストレージデバイス４に送る。このとき、システムメモリ３のアドレスを指定して転送指示を出し、ストレージデバイス４はそれに従って自身が持つＤＭＡ機能でブロックデータをシステムメモリ３に転送するのが一般的であるが、本実施形態では異なる動作を行う。

ホストＣＰＵ２は、システムメモリ３を含めて、ストレージデバイス４やＴＯＥ５等の各種の周辺機器を、通常一つのアドレス空間（主記憶空間）で管理している。例えば図２の例では、システムメモリ３として５１２ＭＢ、ストレージデバイス４として２ＭＢ、ＴＯＥ５デバイスとして１ＭＢのアドレス空間がマッピングされている。

ここで、システムメモリ３は、メモリ容量で定まるアドレス空間がそのまま主記憶空間にマッピングされているが、周辺機器は通常、ホストＣＰＵ２がアクセス可能な制御レジスタを内蔵しており、この制御レジスタが主記憶空間にマッピングされている。なお、図２の例では、３２ビットのアドレス空間を示しているが、アドレス空間のサイズは任意である。

通常のＴＯＥ５は、ストレージデバイス４と同様にＤＭＡ機能を持っており、ホストＣＰＵ２からデータを取得する場合は、ホストＣＰＵ２がシステムメモリ３に格納したデータをＤＭＡで読出す。一方、ストレージデバイス４とＴＯＥ５間でデータを送受する場合は、ストレージデバイス４とＴＯＥ５がいずれもＤＭＡを使用すると、結局のところ、システムメモリ３を介してデータをやりとりすることになってしまう。システムメモリ３を介するとなると、システムメモリに大量の読み書きアクセスが発生し、処理のボトルネックとなる。

そこで、本実施形態では、ＴＯＥ５に送信すべきデータの書き込みをスレーブとして受け付けるインタフェースを設ける。ここで、スレーブとは、ＴＯＥ５に送信すべきデータをシステムメモリ３に転送せずに受け付ける（保持する）処理である。このスレーブとして機能するのがデータ受付部５１である。データ受付部５１は、上述した制御レジスタの少なくとも一部に転送対象データを保持してもよいし、データを受け付ける専用のインタフェースを備えていてもよい。

ホストＣＰＵ２は、ストレージデバイス４に対し、ＴＯＥ５のデータ受付部５１のアドレスを指定して転送指示を出す。すると、ストレージデバイス４はＴＯＥ５に対して直接、すなわちシステムメモリ３を介さずに、データを転送するように動作する。これにより、ＴＯＥ５はストレージデバイス４から直接データを受けることができる。

なお、ホストＣＰＵ２からストレージデバイス４への転送指示は、ＴＯＥ５を経由してもよい。すなわち、ホストＣＰＵ２はＴＯＥ５に転送指示（を行う指示）及びそれに付随する情報を送信し、それを受けたＴＯＥ５からストレージデバイス４に転送指示を行う形態でもよい。転送するブロックの決定と大元の転送指示をホストＣＰＵ２から行うところがポイントであり、その情報をもとに実際にストレージデバイス４に転送指示を行うのはＴＯＥ５が行う形態を採用してもよい。

例えばＰＣＩ Ｅｘｐｒｅｓｓの場合、デバイス間にスイッチが存在するが、この場合は例えばこのスイッチが、ストレージデバイス４から出力されたデータがＴＯＥ５のレジスタに向けられたアドレスと判断し、ＴＯＥ５に対してデータを送るように動作する。あるいは、チップセットが同様の動作を行う。

このようにすると、特定のネットワークストレージのように、データをブロックのままネットワーク１０に送信する装置の場合は特に問題ないが、ＮＡＳやＶＯＤサーバ等のように自身にファイルシステムを持つ場合は問題が生じる。

具体的には、ストレージデバイス４はブロック単位でデータを扱うため、ＴＯＥ５が受け取るデータもブロック単位になるが、ＴＯＥ５がネットワーク１０に送信するファイルのデータはファイルとしての転送なので主にはバイト単位であり、転送されたブロックのどのバイト位置が指定されたファイルのデータ（つまりネットワーク１０に送信すべきデータ）かが、そのままではＴＯＥ５はわからないという問題である。

ネットワーク１０に送信すべきデータは、ファイルシステムを解析することによって得られる情報であり、例えば図３のようになる。図３は有効位置情報をオフセットと長さで示しているが、始端バイト位置と終端バイト位置等で表してもよく、有効データの位置が特定できれば表現形式は問わない。

ファイルシステム処理部２１を持つホストＣＰＵ２は、転送するブロックにおける有効位置情報をＴＯＥ５に通知する必要があり、この通知は有効位置通知部２２によりなされる。ＴＯＥ５は、ストレージデバイス４から転送されたブロックデータと有効位置通知部２２から通知された有効位置情報とに基づいて、データ抽出部５２で有効データを抽出する。そして、ネットワーク処理部５３は、この有効データをネットワーク１０上で送受されるパケット単位に分割してネットワーク１０に送信する。これにより、ネットワーク１０に接続された不図示の特定機器は、パケット単位で有効データを受信する。

上述したように一つのファイルは複数のブロックで構成されるため、ファイルシステム処理部２１は、送信すべきファイルを構成する複数のブロックに対して順次転送指示を出す。つまり、送信すべきデータが全て送信し終わるまで、上記の一連の動作がブロックごとに順次繰り返される。

ただし、ストレージデバイス４によるブロックデータの転送は、通常は一定のレイテンシがあるため、ホストＣＰＵ２は転送指示に対するストレージデバイス４からの実行完了応答を毎回待たずに、複数のブロックの転送指示をストレージデバイス４に対してまとめて行う場合がある。その場合、そのままではホストＣＰＵ２とストレージデバイス４とＴＯＥ５の三者の間で同期が取られなくなるので、有効位置情報の通知は例えば以下の手法により行う。

一つ目の手法は、ストレージデバイス４が転送指示を受けた順番と必ず同じ順番で転送を実行する場合に有効な手法で、ホストＣＰＵ２がストレージデバイス４に複数のブロックの転送指示を行うとき、その転送指示を行うのと同じ順番で、対応するブロックの中の有効位置情報をＴＯＥ５に通知する手法である。ＴＯＥ５のデータ抽出部５２は、受け取った有効位置情報を例えばキューイングしておき、ストレージデバイス４からブロックデータを受け取った際、キューイングした有効位置情報をキューイングした順番に一つずつ取り出せば、ブロックデータとの対応付けが出来る。

二つ目の手法は、ストレージデバイス４が、内部処理の効率等を優先する場合等で、転送指示を受けた順番とは異なる順番で転送を実行し得る場合の手法である。この場合、ホストＣＰＵ２とストレージデバイス４間での転送指示とブロックデータとの関連付けがもともと存在し、典型的には、各ブロックの転送先のアドレスとして異なるアドレスを指定する等である。つまり、従来構成において、8つの転送指示をホストＣＰＵ２がストレージデバイス４にまとめて指示する場合、その８個にシステムメモリ３上の異なる転送先アドレスを指定しておく。すると、ホストＣＰＵ２がストレージデバイス４から全ての転送が完了した事を通知された後に、自身が指定した各アドレスのデータを参照すれば、転送された順番に関係なく、対応する各ブロックデータが得られるという具合である。本実施形態では、転送先のアドレスにＴＯＥ５のアドレスを指定するが、この関連付けの仕組みを利用する場合は、例えばホストＣＰＵ２が８つの転送指示を同時に出す場合、各転送指示の転送先アドレスに、それぞれＴＯＥ５アドレス領域のうちの異なるアドレス領域を指定しておく。例えば図２のようにＴＯＥ５のアドレス領域が0x20200000〜0x202fffffの場合、図４のように、0x20280000〜0x202801ffの５１２バイト領域が転送指示０に対応し、0x20280200〜0x202803ffの５１２バイト領域が転送指示１に対応し、0x20280400〜0x202805ffの５１２バイトが転送指示２に対応し、、、という具合に予め対応付けておき、ホストＣＰＵ２は各転送指示にこれらのアドレス領域の先頭を指定しておく。すると、転送されたブロックデータはあくまでＴＯＥ５に転送されるが、それぞれＴＯＥ５の中の異なるアドレス領域に転送されるため、データを受けたＴＯＥ５は、受けたブロックデータが例えば0x20280200から始まるアドレスに書き込まれたデータであれば、それは転送指示１で指定されたブロックデータであることが特定できる。

一方、ホストＣＰＵ２は、ＴＯＥ５に対してデータの有効位置情報を８つ通知するが、その際に、転送指示０に対応する有効位置情報、転送指示１に対応する有効位置情報、転送指示２に対する有効位置情報、、、なとど判るようにＴＯＥ５に通知する。これもＴＯＥ５の有効位置情報を通知するレジスタ領域の異なるアドレスに通知する等の手法でも良い。これらによって、ＴＯＥ５は受けたデータ、及び、有効位置情報がともにどの転送指示に対するものかが判別できるため、データ抽出部５２はこれらの対応付けが可能となる。なお、アドレスを使うことは本実施形態のほんの一例であり、その他にストレージデバイス４からＴＯＥ５に通知できる情報であれば何を利用しても良い。

このように、ブロックデータの転送先のアドレス領域を分けることによって、ＴＯＥ５が受け取ったブロックデータの順番がもとのデータ列の順番（通常はネットワーク１０に送信する順番）と異なる場合でも、転送先のアドレスを確認することで、そのデータがどのオフセットのデータかが判断できるので、データをもとのデータ列の順番に並び替えることが可能となる。

また、以上のようにＴＯＥ５のアドレス領域を分けることによってブロックデータを識別する手法を述べたが、上述したアドレス領域の分け方は一例にすぎず、この限りではない。また、アドレス領域と転送指示との対応付けを静的に行っても良いし、ホストＣＰＵ２から対応付け情報を指示することによって動的に変えても良い。また、図３のように、多くのデータは最初と最後、または、最後のブロックだけ無効データを含むので、これらのブロックのみ有効位置を通知し、途中のブロックの有効位置情報を省略してもよい。

なお、以上の構成によってストレージデバイス４からＴＯＥ５への直接的なデータ転送、すなわちシステムメモリ３を介さないデータ転送が可能となるが、直接的なデータ転送を行うのが望ましくない場合もある。例えば、別のアプリケーション処理等によって、データ転送ではなくホストＣＰＵ２自身でストレージデバイス４の中身のファイルデータを参照したいような場合もある。その場合はストレージデバイス４からのデータは、従来通りシステムメモリ３上に転送指示する必要があるが、本実施形態は、そのような従来通りのストレージデバイス４へのアクセス方式との共存も可能である。すなわち、アプリケーション等の大元の転送指示を決定する処理部が、従来通りのシステムメモリ３への転送を要求しているか、ＴＯＥ５へのダイレクト転送を要求しているかを判別できるＩ／Ｆを設け、転送指示部２３に指示を出すファイルシステム処理部２１がこのＩ／Ｆで判別された情報を転送指示部２３に通知する。転送指示部２３はその通知に応じて転送先のアドレスをシステムメモリ３かＴＯＥ５かいずれかに切り替える。

その他異常系の処理に関して、ホストＣＰＵ２からストレージデバイス４への転送指示に対し、ストレージデバイス４が、内部エラー等何らかの理由により転送が完了できない場合がある。この場合、ストレージデバイス４はホストＣＰＵ２に対して割り込み等でエラー通知を行うが、そのままではＴＯＥ５はこの情報を得られない。すると、例えばひと固まりのデータの転送途中にエラーが発生した場合、ＴＯＥ５はそのことを知らないがために、完了しない転送完了をひたすら待ち続け、次の動作に移れない等の不具合が発生する。それを解決するには、一つはＴＯＥ５にタイムアウトを設ける手法で、もう一つは、エラーが発生した場合は、その通知を受けたホストＣＰＵ２がＴＯＥ５にもその情報を通知することである。

これにより、ストレージデバイス４で転送エラーが発生した場合にも、ＴＯＥ５はその転送をあきらめて次の転送のデータ受付処理に移行する等の適切なエラー処理ができるようになる。この場合のデータ送信システム１の概略構成は図５のようになる。図５は、図１の構成に加えて、ホストＣＰＵ２がソフトウェアで処理するエラー通知部２４を有する場合におけるデータ送信システムの概略構成を示すブロック図である。このエラー通知部２４は、ストレージデバイス４からの通知を受け、ＴＯＥ５のデータ受付部５１に通知する。エラー通知部２４は、ＴＯＥ５にエラーを通知する他に、自身のファイルシステム処理部２１にも転送が失敗した旨を通知し、ファイルシステム処理部２１は次の処理に移行する等の適切なエラー処理を行う。

上述したように、第１の実施形態では、ホストＣＰＵはストレージデバイス４に対して、ＴＯＥ５のデータ受付部５１のアドレスを指定して転送指示を出すため、ストレージデバイス４からＴＯＥ５に、システムメモリ３を介することなく、直接データを転送することが可能となる。これにより、システムメモリ上を大量のデータが通ることがなくなり、データ転送の効率が良くなるため、ネットワークストレージの転送レートの高速化が図れる。あるいは従来と同じ転送レートを実現する場合は、装置の低コスト化と低消費電力化が図れる。また、ホストＣＰＵ２は、転送するブロックにおける有効位置情報をＴＯＥ５に通知するため、ＴＯＥ５内のネットワーク処理部５３は、バイト単位で抽出された有効データをネットワーク１０に送信できる。

（第２の実施形態）
第２の実施形態は、データ転送用に複数のコネクションが論理的に設定される例を示している。図６は第２の実施形態に係るデータ送信システム１ａの概略構成を示すブロック図である。図６は複数のコネクションによるデータ転送を実現するために、第１の実施形態に加えて、ホストＣＰＵ２がソフトウェアで実行する転送コネクション選択部２５およびコネクション通知部２６を有し、かつＴＯＥ５は新しいデータを受け付けられるかどうかを表すフロー制御情報通知部５４を有する。

転送コネクション選択部２５は、データ転送に利用するコネクションを選択する処理を行う。すなわち、転送コネクション選択部２５は、ＴＯＥ５からのコネクション毎のフロー制御情報に基づいて、ＴＯＥ５がデータ受付可能なコネクションの中からコネクションを選択する。コネクション通知部２６は、データ転送用のブロックが属するコネクション識別子をＴＯＥ５に通知する処理を行う。すなわち、コネクション通知部２６は、転送コネクション選択部２５が選択したコネクションの識別子とファイルシステム処理部２１が特定したデータとをＴＯＥ５が関連付け可能なように、転送コネクション選択部２５が選択したコネクションの識別子をＴＯＥ５に通知する。

ＴＯＥ５内のフロー制御情報通知部５４は、コネクションごとのフロー制御情報をホストＣＰＵ２に通知する。ネットワーク処理部５３は、データ抽出部５２が抽出した有効データを、コネクション通知部２６から通知されたコネクションで、パケット単位でネットワーク１０に送信する。 図２において、図１と同じ符号で示した各部は、図１と同様に動作し、ストレージデバイス４からデータを読み出してネットワーク１０に送信する。今回はそれに加え、例えばＮＡＳのようなネットワークストレージやＶＯＤサーバで複数のクライアント端末、あるいは、クライアント端末上の複数のアプリケーションから同時に読み出し要求やコンテンツ配信要求を受けた場合等、複数の独立したコネクションでストレージデバイス４からデータを読み出してネットワーク１０に送信する動作を可能としている。

図２のデータ送信システムの処理手順は次のようになる。まず、先と同様にホストＣＰＵ２は何らかの手法で、送信するファイルを特定する。ただし、本実施形態では、コネクションが複数あるために、ファイルも複数特定される。転送コネクション選択部２５は、ＴＯＥ５のフロー制御情報通知部５４から通知されるフロー制御情報を確認して、この複数のコネクションの中からＴＯＥ５がデータを受け取れる（すなわち転送可能な）コネクションを特定し、さらにその中から一つのコネクションを選択する。

ここで、通信プロトコルがＴＣＰの場合、通信相手先装置とＴＣＰ通信プロトコルでフロー制御を行っているため、通信相手先装置の処理速度によって送信レートが変わってくる。特に、通信相手先装置が一時的にデータを受信しない場合もあり得るが、その場合は転送が一時的に停止する。また、ＴＣＰには輻輳制御機能もあり、パケットロスが発生してネットワーク１０の輻輳が検知された場合等も送信が抑制され、結果的に送信レートが低下する。このＴＣＰフロー制御やＴＣＰ輻輳制御はＴＣＰコネクション（今回はコネクションと同じ意味）毎に独立して制御されるため、結局、コネクションによって送信レートが速くなったり遅くなったりすることになる。また、ＶＯＤサーバの場合等で通信プロトコルがＲＴＰの場合、コネクション毎に異なるコンテンツを送信する場合があり、それぞれ異なるビットレートでのリアルタイム送信であるため、やはりコネクション毎に送信レートが異なる。

このように、コネクション毎に送信レートが異なる場合において、ホストＣＰＵ２がそれを考慮せずに各コネクションで均等にストレージデバイス４からＴＯＥ５に対してデータを転送した場合、場合によっては送信レートの遅い特定コネクションのデータをＴＯＥ５が受け取れない場合が発生する。通常、このような場合はＩ／ＯバスＢ２（ＰＣＩ Ｅｘｐｒｅｓｓ等）の低レベルのフロー制御によってデータ転送が止められることになる。しかしながら、このバスレベルのフロー制御に頼ると、ここでは複数コネクションのデータ転送が多重化されているため、その他のコネクションのデータ転送も併せて止まってしまうことになる。つまり、特定のコネクションの遅延によるデータ転送の遅延が、その他のコネクションのデータ転送の遅延を引き起こすことになり、全体の転送効率が悪くなる。

これを解決するためには、ＴＯＥ５が現在どのコネクションのデータを受け付けられるかをホストＣＰＵ２に対して通知して、ホストＣＰＵ２はそのコネクションのみデータ転送を行うようにすればよい。前述のフロー制御情報通知部５４は、ＴＯＥ５からのコネクション毎のフロー制御情報の通知を行うものであり、転送コネクション選択部２５は、そのフロー制御情報からＴＯＥ５がデータを受け取れるコネクションを特定し、その特定したコネクションのデータ転送をファイルシステム処理部２１に対して指示するものである。

これにより、特定コネクションの転送遅延によって、バスレベルのフロー制御によるデータ転送遅延を発生させることはないので、その他のコネクションの転送速度を低下させることがなくなり、ひいてはマルチコネクション環境において、全体の転送効率を向上させることが出来るようになる。

より具体的には、ＴＯＥ５には転送されたブロックデータをネットワーク１０に送信する前に一時的に蓄えるバッファがあり、これはコネクション毎に独立して存在する。ネットワーク処理部５３は、このバッファからコネクション毎に別々にデータを読み出してネットワーク１０に送出するが、コネクション毎に送信レートが異なるため、あるコネクションは速くバッファが開放されても、送信レートが遅いコネクションではバッファがすぐには開放されない場合等があり、コネクション毎にバッファの空き容量が異なる。そこで、フロー制御情報通知部５４は、コネクション毎にこのバッファの空き容量をホストＣＰＵ２に通知する。ホストＣＰＵ２はこのバッファの空き容量を見て、複数のコネクション間でできるだけ偏りなくデータ転送を実行する。望ましくは、バッファが1ブロック分以上開いているコネクションが複数ある場合は、それらのコネクション間で1ブロックずつ転送を実行する。

ストレージデバイス４の特長により、特定のファイルのデータを連続で読み出した方が転送効率が良い場合はこの限りではなく、特定のコネクションのデータをある程度連続で転送してから次のコネクションの転送、等というようにある程度まとまりをもって転送を行う方が望ましいが、このようにまとまりを持って転送を行うと、後回しになったコネクションへのデータの転送が大きく遅延することになり、バスの全体の転送帯域としては要求性能を満たしていても、特定のコネクションにおいてバッファアンダーフローを起しかねない。よって、データの転送はできるだけ少ないブロック数（理想的には1ブロックずつ）毎に、複数のコネクションで順次転送を行うことが望ましい。

コネクション通知部２６は、転送するブロックが属するコネクション識別子をＴＯＥ５に通知する。この通知は、前述の有効位置情報の通知と同様の手法で行う。

一つ目の手法はストレージデバイス４が転送指示と必ず同じ順番で転送を実行する場合に有効な手法で、転送指示を出す順番と同じ順番でＴＯＥ５にコネクション識別子を通知する手法である。ＴＯＥ５のデータ抽出部５２はホストＣＰＵ２からの識別子情報をキューイングしておき、ストレージデバイス４からデータを受け取った順番と同じ順番でキューイングした識別子情報を取り出せば、転送されたブロックデータと識別子情報を対応付けることができる。

二つ目の手法はストレージデバイス４が転送指示と異なる順番で転送を実行する場合に有効な手法で、コネクション毎に転送指示で指定する転送先アドレスをＴＯＥ５のアドレス領域の異なる領域を指定して転送指示を出す手法である。例えば図７のように割り当て、ホストＣＰＵ２はそれぞれのコネクションのデータの転送先アドレスを図７のように指定すると、データを受け取ったＴＯＥ５は、自身のどのアドレス領域に向けられたデータかを確認することで、そのデータがどのコネクションに属するか特定することが出来、適切なバッファにバッファリングすることができる。なお、図６ではコネクション情報の通知がコネクション通知部２６からデータ抽出部５２に直接点線矢印が延びているが、このようにアドレス等を用いてストレージデバイス４経由でコネクション識別子情報を通知する構成も本実施形態に含む。なお、アドレスを使うことは本実施形態のほんの一例であり、その他にストレージデバイス４からＴＯＥ５に通知できる情報であればなにを利用しても良い。また、アドレスとコネクション識別子のマッピングはほんの一例であり、また動的に変更しても良い。特に、アドレス空間は有限であることから、コネクション識別子空間が大規模な場合は動的割り当てが有効である。

上述したように、第２の実施形態では、複数のコネクションでデータ転送を行う場合に、複数のコネクション間でできるだけ偏りなくデータ転送を実行するため、複数のコネクションを用いても転送効率を落とさずにデータの転送が実現できる。これにより、ホストＣＰＵ２の処理負担を軽減しつつ、より効率的にデータ転送を行うことができる。

（第３の実施形態）
第３の実施形態は、データバッファの削減を図るものである。図８は第３の実施形態に係るデータ送信システム１ｂの概略構成を示すブロック図である。図８は、図６の構成に加えて、ＣＰＵがソフトウェアで実行する処理として再転送位置指定部２７を有するとともに、ＴＯＥ５は再転送要求部５５を有する。

図８のデータ送信システム１ｂは、ストレージデバイス４からＴＯＥ５に、システムメモリ３を介さずに直接的にデータを転送できることに加えて、第２の実施形態で述べたＴＯＥ５の中のデータバッファも削減できることを特徴とする。

例えば、ＴＣＰ通信プロトコルの場合、ネットワーク１０の途中でパケットがロスした場合にパケットの再送が必要になるため、通信相手先装置から確認応答を受けるまでは、送信データを必ず保持しておく必要があり、通常はＴＯＥ５の内部に、送信データ保持用のデータバッファを設けている。

これに対して、本実施形態では、ＴＯＥ５内の再転送要求部５５により、ホストＣＰＵ２に対してブロックデータの再転送を要求する。この要求を受けて、ホストＣＰＵ２は、再転送位置指定部２７により、再送データのファイル上の位置を特定し、必要な分だけのデータ転送をストレージデバイス４に指示する。これにより、上述したデータバッファを削減できる。

具体的には次のようになる。まず、通常のデータ転送とネットワーク１０へのデータ転送は、第２の実施の形態と同様に行う。ただし、本実施形態にはＴＯＥ５の中にデータバッファが無いため、前述のフロー制御情報通知部５４は、ＴＣＰのフロー制御情報である、ネットワーク１０に接続された通信相手先装置のＴＣＰ受信ウィンドウ（送信可能なバイト数）をそのままホストＣＰＵ２に渡す。つまり、ホストＣＰＵ２は通信相手先装置が受け取れるだけＴＯＥ５にデータを渡し、ＴＯＥ５はそのデータをそのままネットワーク１０に送信するように動作する。

そして、ネットワーク１０上等でパケットロスが発生したとき、ネットワーク処理部５３はそれを検知してパケットの再送が必要と判断すると、ホストＣＰＵ２に対してデータを再び転送してもらうべく、再転送要求部５５は、再送が必要なコネクション識別子と、再送データのオフセット位置と長さ情報を指定して、ホストＣＰＵ２にブロックデータの再転送を要求する。ホストＣＰＵ２はこれを受け、再転送位置指定部２７がこのデータのコネクションからファイルを特定し、さらに、データのオフセット位置と長さからファイルにおけるオフセット位置と長さを特定し、そのデータの転送を実施する。その後は第２の実施形態と同様に転送が行われ、ＴＯＥ５はこのデータを受け次第、ネットワーク１０に送信する（これが再送パケットとなる）。

以上はＴＣＰ通信における再送の例であるが、ＶＯＤサーバ等のＲＴＰ通信の場合は再送は存在しない。しかしながら、ネットワーク１０上のパケットロスに対するデータの欠落を補償するためにＦＥＣ等を用いる場合があり、例えばＩＰＴＶではPro-MPEG FECが用いられる。Pro-MPEG FECでは、詳細は割愛するが、ＲＴＰのデータパケットをシーケンス番号順にマトリクス上に並べ、そのマトリクスにおいて縦方向に並ぶパケットのデータ部分のＸＯＲを計算し、対応するＦＥＣパケットのデータ部分を生成するという処理が必要である。ＦＥＣパケットの生成はＲＴＰパケットを送信した後に行うので、このような演算によるＦＥＣパケットの生成を行うためには、送信したパケットのデータを後から再度読み出す必要がある。このような場合も通常はＴＯＥ５の内部にデータバッファを設け、再読み出しを実現するが、本実施形態では前述のような構成により、再読み出しをデータバッファではなくストレージデバイス４から再度読み出すことで実現でき、ひいてはＴＯＥ５内部のデータバッファを削減できる。このようにＦＥＣを用いる場合でも、本実施形態によってＴＯＥ５内部のデータバッファを削減することが可能となる。

以上のような構成によってデータバッファを削減することが可能となるが、ストレージデバイス４から送信されるブロックデータと、ネットワーク１０に送出するパケットのデータサイズは異なるため、このサイズの違いを吸収するための最低限のバッファリングは必要となる。例えば、ブロックデータが５１２バイトで、パケットサイズが1460バイトの場合、ＴＯＥ５が３つのブロックデータをストレージデバイス４から受け取ると合計1536バイトとなり、ここで初めてＴＯＥ５は1つのパケットを送信できるが、送信後に1536 - 1460 = 76バイト余り、これは次のパケットの先頭７６バイトになるため、次のパケット送信までこの７６バイトをバッファリングしておく必要がある。本実施形態によって大きなデータバッファをなくすことは出来ても、このような小さなバッファは必要となる。またこのようなバッファはコネクション毎に必要となる。しかしながら、バッファサイズは大幅に小さく（1コネクションあたり1パケットのデータサイズ未満に）なることから、メモリのコストを大幅に抑えることができ、さらに、例えばＴＯＥ５を構成するＡＳＩＣやＦＰＧＡ等のＬＳＩの外部のメモリ（DRAM等）ではなく内部のメモリ等で実現できる場合もあり、トータルコストを抑えることができるか、または高性能化が実現できるというメリットがある。

このバッファをさらに削減する手法としては、ストレージデバイス４のブロックサイズをネットワーク１０のパケットサイズの自然数倍にする手法である。例えばブロックデータのサイズが５１２バイトのとき、ネットワークパケットのサイズも５１２バイトにすると、ＴＯＥ５はブロックデータを受け取るとそのままパケットを送信でき、送信後にバッファリングしておくデータもなくすことが出来る。ブロックデータのサイズを4096バイトにしてパケットのデータサイズを1024バイトにすれば、ＴＯＥ５は一つのブロックデータを受けると4つのパケットを送信でき、この場合も次のパケット送信までバッファリングしておくデータをなくすことが出来る。このようにすれば、ＴＯＥ５の内部のバッファをさらに削減することができ、本実施形態のメリットをさらに顕著にすることができる。

このように、第３の実施形態によれば、ＴＯＥ５の内部のデータバッファを削減でき、装置をより低コスト、低消費電力にすることができ、本実施形態の効果をより顕著にすることが出来る。

本実施形態の態様は、上述した個々の実施形態に限定されるものではなく、当業者が想到しうる種々の変形も含むものであり、本実施形態の効果も上述した内容に限定されない。すなわち、特許請求の範囲に規定された内容およびその均等物から導き出される本実施形態の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更および部分的削除が可能である。

上述した実施形態で説明したデータ送信システム１ｂの少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、データ送信システム１ｂの少なくとも一部の機能を実現するプログラムをフレキシブルディスクやＣＤ−ＲＯＭ等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリ等の固定型の記録媒体でもよい。

また、データ送信システム１ｂの少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。

１、１ａ、１ｂ データ送信システム
２ ホストＣＰＵ
３ システムメモリ
４ ストレージデバイス（データ記録装置）
５ ＴＯＥ（プロトコル処理装置）
２１ ファイルシステム処理部
２２ 有効位置通知処理部
２３ 転送指示部
２４ エラー通知部
２５ 転送コネクション選択部
２６ 転送コネクション通知部
２７ 再転送位置指定部
５１ データ受付部
５２ データ抽出部
５３ ネットワーク処理部
５４ フロー制御情報通知部

Claims (16)

1. 主記憶装置に対する読み書きを行うことが可能なプロセッサと、
   格納されたデータをブロック単位でＩ／Ｏバス上に送信するデータ記録装置と、
   前記Ｉ／Ｏバスに接続され、前記プロセッサに代行して所定の通信プロトコル処理を行うプロトコル処理装置と、を備えたデータ送信システムであって、
   前記プロセッサは、
   前記データ記録装置から送信されるべきデータをブロック単位で特定するデータ特定部と、
   前記プロトコル処理装置のアドレス情報を指定して、前記データ記録装置から前記プロトコル処理装置へのデータ転送を指示する転送指示部と、を有し、
   前記プロトコル処理装置は、
   前記データ記録装置からブロック単位で前記Ｉ／Ｏバスに送信されたデータを、前記主記憶装置を経由せずに直接受け付けるデータ受付部と、
   前記データ受付部で受け付けたブロック単位のデータをパケット単位でネットワークに送信するネットワーク処理部と、を有することを特徴とするデータ送信システム。
2. 前記プロセッサは、
   前記データ記録装置のファイルシステムに基づいて、ファイルに対応するブロック単位のデータ群と、その中の有効データの位置とを特定するファイルシステム処理部と、
   前記有効データの位置情報と、前記データ特定部が特定したデータを、前記プロトコル処理装置が関連付け可能なように、前記プロトコル処理装置に前記有効データの位置情報を通知する有効位置通知部と、を有し、
   前記プロトコル処理装置は、前記データ受付部で受け付けたブロック単位のデータと前記有効データの位置情報とに基づいて、前記有効データを抽出するデータ抽出部を有し、
   前記ネットワーク処理部は、前記データ抽出部が抽出した前記有効データをパケット単位で前記ネットワークに送信することを特徴とする請求項１に記載のデータ送信システム。
3. ネットワークにデータを送信する際に論理的に設定される複数のコネクションを備え、
   前記プロセッサは、
   前記プロトコル処理装置からの前記コネクション毎のフロー制御情報に基づいて、前記プロトコル処理装置がデータ受付可能なコネクションの中からコネクションを選択するコネクション選択部と、
   前記コネクション選択部で選択したコネクションで送信すべきブロック単位のデータを特定するデータ特定部と、
   前記コネクション選択部が選択したコネクションの識別子と、前記データ特定部が特定したデータを、前記プロトコル処理装置が関連付け可能なように、前記プロトコル処理装置に前記コネクション選択部が選択したコネクションの識別子を通知するコネクション通知部と、を有し、
   前記プロトコル処理装置は、
   前記コネクション毎のフロー制御情報を前記プロセッサに通知するフロー制御情報通知部と、
   前記データ抽出部が抽出した前記有効データを、前記コネクション通知部から通知されたコネクションで、パケット単位で前記ネットワークに送信するネットワーク処理部と、を有することを特徴とする請求項１または２に記載のデータ送信システム。
4. 前記コネクション選択部は、前記複数のコネクション間で偏りなくデータ転送が行えるように、各コネクションごとに公平にコネクションを選択することを特徴とする請求項３に記載のデータ送信システム。
5. 前記プロトコル処理装置は、再転送すべきデータをブロック単位で前記プロセッサに要求する再転送要求部を有し、
   前記プロセッサは、前記要求に応答して、再転送すべきデータのファイルと、該ファイルのオフセット位置および長さと、を指定する再転送位置指定部を有することを特徴とする請求項１乃至４のいずれかに記載のデータ送信システム。
6. 前記ブロック単位のデータサイズは、前記パケット単位のデータサイズの自然数倍であることを特徴とする請求項１乃至５のいずれかに記載のデータ送信システム。
7. 前記転送指示手段は、前記データ記録装置から読出したデータを、前記バスを介して前記主記憶装置に転送するか、あるいは前記バスから前記主記憶装置を経由せずに前記データ受付部に直接送信するかを選択的に指示可能であることを特徴とする請求項１乃至７のいずれかに記載のデータ送信システム。
8. 前記プロセッサは、前記データ記録装置にて発生した転送エラー信号を受信した場合に、転送エラーが発生したことを前記データ受付部に通知するエラー通知部を有し、
   前記データ受付部は、前記エラー通知からの通知を受け付けると、現在受信中のデータを破棄して、後続のブロック単位のデータを受け付けるために待機することを特徴とする請求項１乃至７のいずれかに記載のデータ送信システム。
9. 主記憶装置に対する読み書きを行うことが可能なプロセッサと、
   格納されたデータをブロック単位でＩ／Ｏバス上に送信するデータ記録装置と、
   前記Ｉ／Ｏバスに接続され、前記プロセッサに代行して所定の通信プロトコル処理を行うプロトコル処理装置と、を制御するコンピュータ読み取り可能なプログラムであって、
   前記データ記録装置から送信されるべきデータをブロック単位で特定するステップと、
   前記プロトコル処理装置のアドレス情報を指定して、前記データ記録装置から前記プロトコル処理装置へのデータ転送を指示するステップと、
   前記データ記録装置からブロック単位で前記Ｉ／Ｏバスに送信されたデータを、前記主記憶装置を経由せずに前記プロトコル処理装置にて直接受け付けるステップと、
   前記プロトコル処理装置で受け付けたブロック単位のデータをパケット単位でネットワークに送信するステップと、をコンピュータに実行させるデータ送信プログラム。
10. 前記データ記録装置のファイルシステムに基づいて、ファイルに対応するブロック単位のデータ群と、その中の有効データの位置とを特定するプログラムと、
    前記有効データの位置情報と、前記データ特定部が特定したデータを、前記プロトコル処理装置が関連付け可能なように、前記プロトコル処理装置に前記有効データの位置情報を通知するステップと、
    前記プロトコル処理装置で受け付けたブロック単位のデータと前記有効データの位置情報とに基づいて、前記有効データを抽出するステップと、を有し、
    前記プロトコル処理装置は、抽出された前記有効データをパケット単位で前記ネットワークに送信することを特徴とする請求項９に記載のデータ送信プログラム。
11. ネットワークにデータを送信する際に論理的に複数のコネクションを設定するステップと、
    前記プロトコル処理装置からの前記コネクション毎のフロー制御情報に基づいて、前記プロトコル処理装置がデータ受付可能なコネクションの中からコネクションを選択するステップと、
    選択されたコネクションで送信すべきブロック単位のデータを特定するステップと、
    前記選択したコネクションの識別子と前記特定したデータとを、前記プロトコル処理装置が関連付け可能なように、前記プロトコル処理装置に前記選択したコネクションの識別子を通知するステップと、
    前記コネクション毎のフロー制御情報を前記プロトコル処理装置から前記プロセッサに通知するステップと、
    前記抽出した前記有効データを、前記通知されたコネクションで、パケット単位で前記ネットワークに送信するステップと、
    を有することを特徴とする請求項９または１０に記載のデータ送信プログラム。
12. 前記複数のコネクション間で偏りなくデータ転送が行えるように、各コネクションごとに公平にコネクションを選択することを特徴とする請求項１１に記載のデータ送信プログラム。
13. 再転送すべきデータをブロック単位で前記プロセッサに要求するステップと、
    前記要求に応答して、再転送すべきデータのファイルと、該ファイルのオフセット位置および長さと、を指定するステップと、を有することを特徴とする請求項９乃至１２のいずれかに記載のデータ送信プログラム。
14. 前記ブロック単位のデータサイズは、前記パケット単位のデータサイズの自然数倍であることを特徴とする請求項９乃至１３のいずれかに記載のデータ送信プログラム。
15. 前記データ記録装置から読出したデータを、前記バスを介して前記主記憶装置に転送するか、あるいは前記バスから前記主記憶装置を経由せずに前記データ受付部に直接送信するかを選択的に指示可能としたことを特徴とする請求項９乃至１４のいずれかに記載のデータ送信プログラム。
16. 前記データ記録装置にて発生した転送エラー信号を受信した場合に、転送エラーが発生したことを前記データ受付部に通知するステップと、
    前記エラー通知からの通知を受け付けると、現在受信中のデータを破棄して、後続のブロック単位のデータを受け付けるために待機するステップと、を有することを特徴とする請求項９乃至１５のいずれかに記載のデータ送信プログラム。

Images