(57)【要約】【課題】アプリケーションが利用するデータをネットワークから受信してストレージへ高速に保存するとともに、ストレージに保存したデータをアプリケーションが容易に利用できるようにする。【解決手段】本発明の実施形態としてのデータ受信装置は、受信制御部と読み出し制御部とを備える。前記受信制御部は、ネットワーク上の対向装置との間で形成したセッションを介して受信したデータを、ストレージ上のファイルに書き込むよう、前記ストレージへのデータ書き込みを行うアクセス処理装置を制御する。前記読み出し制御部は、前記ファイルと前記セッションとを対応づけた登録情報を管理し、アプリケーションから前記セッションを指定したデータ受信要求を受けたとき、前記登録情報において前記指定されたセッションに対応するファイルのデータの読み出し要求を、前記ストレージに出力し、前記ストレージから読み出されるデータを受信するよう制御する。【選択図】図２
2015179444.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上の対向装置との間で形成したセッションを介して受信したデータを、ストレージ上のファイルに書き込むよう、前記ストレージへのデータ書き込みを行うアクセス処理装置を制御する受信制御部と、
前記ファイルと前記セッションとを対応づけた登録情報を管理し、アプリケーションから前記セッションを指定したデータ受信要求を受けたとき、前記登録情報において前記指定されたセッションに対応するファイルのデータの読み出し要求を、前記ストレージに出力し、前記ストレージから読み出されるデータを受信するよう制御する読み出し制御部と、
を備えたデータ受信装置。
【請求項２】
前記登録情報は、前記ファイルと前記セッションに加え、プロセス識別子をさらに対応づけており、
前記読み出し制御部は、前記データ受信要求で指定されたセッションと前記アプリケーションのプロセス識別子に対応するファイルを、前記登録情報から特定し、特定したファイルのデータの読み出し要求を行うように制御する
請求項１に記載のデータ受信装置。
【請求項３】
前記アプリケーションの要求に応じて、前記セッションを形成するセッション形成部をさらに備え、
前記読み出し制御部は、前記セッション形成部により形成されたセッションを前記登録情報に登録し、前記受信制御部から前記セッションと前記ファイルとの指定した登録要求を受け、前記登録要求で指定されたセッションを含むエントリを前記登録情報から検索し、検索したエントリに前記指定されたファイルを登録する
請求項１に記載のデータ受信装置。
【請求項４】
前記アプリケーションの要求に応じて、前記セッションを形成するセッション形成部をさらに備え、
前記読み出し制御部は、前記セッション形成部により形成されたセッションと、前記アプリケーションのプロセス識別子を登録し、前記受信制御部から前記セッションと前記ファイルと前記アプリケーションのプロセス識別子を指定した登録要求を受け、前記登録要求で指定されたセッションとプロセス識別子を含むエントリを前記登録情報から検索し、検索したエントリに前記登録要求で指定されたファイルを登録する
請求項２に記載のデータ受信装置。
【請求項５】
前記読み出し制御部は、前記受信制御部から前記セッションと前記ファイルとを指定した登録要求を受け、前記登録要求で指定されたファイルとセッションを対応づけて前記登録情報に登録する
請求項１に記載のデータ受信装置。
【請求項６】
前記アプリケーションの要求に応じて、前記セッションを形成するセッション形成部をさらに備え、
前記読み出し制御部は、前記受信制御部から前記セッションと前記ファイルと前記アプリケーションのプロセス識別子を指定した登録要求を受け、前記登録要求で指定されたファイルとセッションとプロセス識別子を対応づけて前記登録情報に登録する
請求項２に記載のデータ受信装置。
【請求項７】
所定のプロトコルに従って前記対向装置とセッションを形成して通信する通信部を備え、
前記読み出し制御部は、前記データ受信要求が示すセッションが前記登録情報に登録されていないとき、前記通信部に、前記ネットワークから受信したデータを、ダイレクトストレージアクセス処理部とは異なるメモリに書き込むよう指示する情報を出力する
請求項１ないし６のいずれか一項に記載のデータ受信装置。
【請求項８】
前記読み出し制御部の前記読み出し要求は、オペレーティングシステムのシステムコールにより行う
請求項１ないし７のいずれか一項に記載のデータ受信装置。
【請求項９】
ホストCPUをさらに備え、
前記ホストCPUは、前記受信制御部および前記読み出し制御部を含む
請求項１ないし８のいずれか一項に記載のデータ受信装置。
【請求項１０】
ネットワーク上の対向装置との間で形成したセッションを介して受信したデータを、ストレージ上のファイルに書き込むよう、前記ストレージへのデータ書き込みを行うアクセス処理装置を制御する受信制御ステップと、
前記ファイルと前記セッションとを対応づけた登録情報を管理し、アプリケーションから前記セッションを指定したデータ受信要求を受けたとき、前記登録情報において前記指定されたセッションに対応するファイルのデータの読み出し要求を、前記ストレージに出力し、前記ストレージから読み出されるデータを受信するよう制御する読み出し制御ステップと、
をコンピュータが実行するデータ受信方法。
【請求項１１】
ネットワーク上の対向装置との間で形成したセッションを介して受信したデータを、ストレージ上のファイルに書き込むよう、前記ストレージへのデータ書き込みを行うアクセス処理装置を制御する受信制御ステップと、
前記ファイルと前記セッションとを対応づけた登録情報を管理し、アプリケーションから前記セッションを指定したデータ受信要求を受けたとき、前記登録情報において前記指定されたセッションに対応するファイルのデータの読み出し要求を、前記ストレージに出力し、前記ストレージから読み出されるデータを受信するよう制御する読み出し制御ステップと、
をコンピュータが実行するコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、データ受信装置、データ受信方法、およびコンピュータプログラムに関する。
【背景技術】
【０００２】
今般、ネットワークの常時接続性や常時高速通信を実現するためのインフラへの高額投資負担が課題となっている。このため、高速通信環境は、短距離、少ない端末数などの条件がそろっているときにのみ、高速通信が実現できる状況になりつつある。一方、ストレージのデータ記憶単価は低下の一途をたどっている。このため、端末に大容量のストレージを搭載し、高速通信の条件がそろっている短時間に大量のデータを取得してストレージに格納し、アプリケーションは、ストレージ上のデータを読み出して利用する方法が考案されつつある。
【０００３】
この方法の１つとして、端末にプロキシサーバを搭載し、オンライン時に、特定のアプリケーションが利用するデータを、ネットワークから受信して、端末のストレージに一時保存しておく方法が知られている。この方法では、後に、オフライン時に、アプリケーションが、このストレージからデータを読み出して、利用することができる。しかし、この方法を実現するためには、アプリケーションのアーキテクチャが、プロキシサーバに対応する必要があった。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平１０−２１４２１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の実施形態は、アプリケーションが利用するデータをネットワークから受信してストレージへ高速に保存するとともに、ストレージに保存したデータをアプリケーションから容易に利用できるようにすることを目的とする。
【課題を解決するための手段】
【０００６】
本発明の実施形態としてのデータ受信装置は、受信制御部と読み出し制御部とを備える。
【０００７】
前記受信制御部は、ネットワーク上の対向装置との間で形成したセッションを介して受信したデータを、ストレージ上のファイルに書き込むよう、前記ストレージへのデータ書き込みを行うアクセス処理装置を制御する。
【０００８】
前記読み出し制御部は、前記ファイルと前記セッションとを対応づけた登録情報を管理し、アプリケーションから前記セッションを指定したデータ受信要求を受けたとき、前記登録情報において前記指定されたセッションに対応するファイルのデータの読み出し要求を、前記ストレージに出力し、前記ストレージから読み出されるデータを受信するよう制御する。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施形態に従ったデータ受信装置を備えたシステムの全体構成を示す図。
【図２】図１に示したデータ受信装置におけるTCP/IP通信部からストレージまでの詳細なブロック構成を示す図。
【図３】登録表の例を示す図。
【図４】本発明の実施形態に係るデータ受信装置の動作例を説明するための図。
【図５】本発明の実施形態に係る転送処理部およびダイレクトストレージアクセス処理部の詳細構成を示す図。
【図６】エクステントマップを説明する図。
【発明を実施するための形態】
【００１０】
以下、図面を参照しながら、本発明の実施形態について説明する。
【００１１】
図１は、本発明の実施形態に従ったデータ受信装置を備えたシステムの全体構成を示す。図１の下には、データ受信装置１０１の概略機能ブロック図が示されている。
【００１２】
データ受信装置１０１が、ネットワーク２０１に接続されている。ネットワーク２０１は、無線ネットワーク、有線ネットワーク、またはこれらのハイブリッドのネットワークであり、一例として、インターネットである。データ受信装置１０１は、ネットワーク２０１を介して対向装置と通信する。本実施形態では、データ受信装置１０１は、無線によりネットワーク２０１へ接続する。
【００１３】
データ受信装置１０１は、PC、スマートフォン、タブレット、携帯端末等の通信端末に搭載されている。データ受信装置１０１は、無線通信I/F１１、TCP/IP通信部１２、アプリケーション１３、転送処理部１４、ストレージ１５、アンテナ１６、ソケットI/F部（セッション形成部）２１、ファイルI/F部２３を搭載している。転送処理部１４は、ストレージ１５に高速なデータ書き込みを行うハードウェアであるアクセス処理装置としてダイレクトストレージアクセス処理部２４を備える。
【００１４】
データ受信装置１０１は、ネットワーク２０１上の対向装置と、TCP/IP等の通信プロトコルに従って通信し、対向装置からデータを受信する。データ受信装置１０１は、当該対向装置から受信したデータを、ファイルの形式でストレージ１５に保存する。このとき、データ受信装置１０１では、ストレージ１５に保存する処理を、ダイレクトストレージアクセス処理部２４が行う。つまり、ホストCPUによりメインメモリ等の記憶装置を経由してストレージへ書き込むことはなく、ダイレクトストレージアクセス処理部２４によりストレージ１５に直接、受信データを書き込む。これにより、ホストCPUの負荷を低く抑えつつ、高速なデータ受信を可能にする。またストレージ１５に保存したデータを、ホストCPUで動作するアプリケーション１３が、通常のAPI（アプリケーションプログラムインタフェース）、例えばホストCPUで実行されるオペレーティングシステム（OS）が備えるシステムコール（read()関数など）を介して読み出す。これにより、高速なデータ受信と、通常のAPIを利用したデータ読み出しの両方を実現する。
【００１５】
無線通信I/F１１は、任意の通信規格に従って、無線通信を行う無線通信インタフェースである。接続する無線ネットワークは、無線LANでもよいし、３Gネットワーク等の携帯電話の通信ネットワークでもよいし、その他の種類の無線ネットワークでもよい。ここでは、無線通信I/F１１を備える場合を示すが、有線通信I/Fを備えて、有線ネットワークに接続する構成でもよい。
【００１６】
TCP/IP通信部１２は、IETFで策定されているインターネットプロトコル（IP）、およびTransmission Control Protocol（TCP）の手順に従って、対向装置とデータを送受信する処理部である。TCPの詳細はRFC 793（https://www.ietf.org/rfc/rfc793.txt）等に記載されているように一般的に知られているものである。
【００１７】
ストレージ１５は、所定のファイルシステムに従って管理されており、ファイルの形式でデータを記憶する記憶装置である。ストレージ１５は、一般的には、HDDまたはSSD（Solid State Drive）などである。また、SDメモリカードのような、NANDフラッシュメモリカードを用いることもできる。ダイレクトストレージアクセス処理部２４が対応できるストレージインタフェースを有するストレージであれば、任意のものを用いることができる。
【００１８】
アプリケーション１３は、データ受信装置１０１のユーザが使用するアプリケーションプログラムであり、ホストCPUにより実行される。アプリケーション１３には、ゲームやWebブラウザ等のツールなど、様々なものがある。アプリケーション１３は、セッション（ソケット）の生成および削除を管理するソケットI/F部２１を通じて、ネットワーク２０１との間でデータを送受信する。また、ファイルI/F部２３を通じて、OSのシステムコール等を利用することで、ストレージ１５からデータの読み出しを行うことができる。
【００１９】
また、アプリケーション１３は、ネットワーク２０１から受信したデータをストレージ１５へ書き込むことを転送処理部１４に要求する代行受信要求を発行する。アプリケーション１３は、発行した代行受信要求を転送処理部１４に送る。代行受信要求の発行機能をOSに搭載し、アプリケーション１３がこの機能を呼び出すことで、代行受信要求を転送処理部１４に与える形でもよいし、アプリケーション１３が直接、代行受信要求を発行して与える形でも良い。
【００２０】
代行受信要求には、TCP/IP通信部１２におけるTCPのセッション情報と、データの書き込み先情報が含まれている。セッション情報は、例えば自装置のIPアドレス、自装置のTCPポート番号、当該セッションのTCPのシーケンス番号を含む。相手方のIPアドレス、自装置のTCPポート番号や、セッションに関するその他の情報を含んでも良い。また、データの書き込み先情報は、ストレージ１５における書き込み先のファイルの識別子であるファイルディスクリプタ、および当該ファイルのファイルサイズ等を含む。
【００２１】
転送処理部１４は、アプリケーション１３から代行受信要求を受け取ると、ダイレクトストレージアクセス処理部２４を用いて、TCP/IP通信部１２で受信したデータを、ストレージ１５へ書き込む処理を行う。書き込みを行うデータは、代行受信要求に含まれるセッション情報に示されるセッションで受信されるデータである。また、受信したデータを書き込むストレージ１５の記憶領域（書き込み先）は、代行受信要求に含まれる書き込み先情報に示されるファイルである。なお、ダイレクトストレージアクセス処理部２４はストレージ１５へのデータ書き込みに加え、ストレージ１５からのデータ読み出しが可能でも良い。
【００２２】
アプリケーション１３は、ファイルI/F部２３を通じて、ダイレクトストレージアクセス処理部２４によりストレージ１５に書き込まれたファイルのデータを読み出す。アプリケーション１３は、読み出すファイルのファイルディスクリプタをファイルI/F部２３に指示することで、読み出すファイルを指定する。ダイレクトストレージアクセス処理部２４によるストレージ１５へのデータの書き込みと、アプリケーション１３によるストレージ１５からの当該データの読み出しは、同時並行的に行われることもできる。ファイルI/F部２３によるデータ読み出しは、ダイレクトストレージアクセス処理部２４を用いてストレージ１５にアクセスしてデータを読み出しても良いし、ダイレクトストレージアクセス処理部２４とは別のアクセス経路をストレージ１５に対して設け、当該アクセス経路から読み出しを行っても良い。
【００２３】
以上は、本データ受信装置の構成および動作の概要である。以下では、さらに詳細な構成および動作を示す。
【００２４】
図２に、図１に示したデータ受信装置におけるTCP/IP通信部１２からストレージ１５までの詳細なブロック構成を示す。
【００２５】
図１に示した構成に加えて、本実施形態の特徴の１つとなる読み出し制御部２２および代行受信制御部２５が設けられている。なお、無線通信I/Fおよびアンテナの図示は省略している。以下、図１と重複する説明は省略する。
【００２６】
ソケットI/F部２１は、Linux（https://www.kernel.org/）やBSD（http://www.freebsd.org/, http://www.netbsd.org/）等のシステムコールで提供されているソケットインタフェース（http://www.freebsd.org/doc/ja/books/design-44bsd/overview-ipc.html）を提供する処理部である。ソケットインタフェースはBSDソケットインタフェースとも呼ばれる。これらのインタフェースは、例えばOSが一般的に備えているものを利用してもよい。
【００２７】
アプリケーション１３は、ソケットI/F部２１が提供するシステムコールを使って、ソケットの生成、および、生成したソケットの削除を行う。またアプリケーション１３は、生成したソケットを利用して、ネットワーク２０１上の対向装置と、データまたはメッセージ等の送受信を行う。
【００２８】
アプリケーション１３は、socket()システムコールを行うことで、TCPセッションを表すソケットを生成する。生成されたソケットには、ソケットディスクリプタが付与される。ソケットは、ソケットディスクリプタにより識別される。また、アプリケーション１３は、ソケットディスクリプタを指定して、close()システムコールを行うことで、ソケットを閉じる（削除する）。
【００２９】
ここで、ソケットディスクリプタとは、接続状態にあるTCPセッションを示す識別子である。ソケットI/F部２１では、ソケットディスクリプタと、セッション情報（自IPアドレス、自TCPポート番号、自TCPシーケンス番号、相手方IPアドレス、相手方TCPポート番号、相手方TCPシーケンス番号、などを含む）の対応を保持している。ソケットディスクリプタのデータ型は、正数である。ソケットは、ソケットディスクリプタと、セッション情報との組を指す。
【００３０】
また、アプリケーション１３は、ソケットが生成された状態（すなわちセッションが生成された状態）で、send()システムコールを行うことで、データの送信要求を発行する。またrecv()システムコールを行うことで、データの受信要求を発行する。
【００３１】
send()システムコールおよびrecv()システムコールは、共に、ソケットディスクリプタを引数に取る。アプリケーション１３は、ソケットディスクリプタを指定して、send()またはrecv()のシステムコールを行う。send()システムコールでは、送信するデータの指定も行う。送信するデータは、例えばメインメモリ等のメモリに存在する。ストレージ１５に存在してもよい。
【００３２】
ソケットI/F部２１は、socket()システムコールによりソケットを生成すると、所定の登録表にエントリを追加する。登録表は、読み出し制御部２２内に保持されている。ただし、登録表を、読み出し制御部２２内でなく、読み出し制御部２２からアクセス可能な記憶部に保持してもよい。
【００３３】
図３（A）に、登録表の例を示す。登録表は、プロセスID、ファイルディスクリプタ、ソケットディスクリプタの各フィールドを有する。ソケットI/F部２１は、ソケットを生成すると、エントリとして、一部の情報のみ、すなわち、プロセスIDとソケットディスクリプタのみを含むエントリを生成して、登録表に追加する。図３（A）は、このようなエントリを追加した状態を示している。
【００３４】
ソケットI/F部２１は、send()システムコールを介して、アプリケーション１３からデータ送信の要求を受け取ると、TCP/IP通信部１２に送信要求を出力する。この送信要求は、一例として、プロセスID、ソケットディスクリプタ、送信データが格納されている記憶領域の情報（メモリアドレス等）を含む。送信データが格納されている記憶領域は、例えばメインメモリ、あるいはこれとは別のメモリ、ストレージ１５など、任意の記憶部でよい。TCP/IP通信部１２は、ソケットディスクリプタから、ソケットディスクリプタが示すTCPセッション情報にアクセス可能である。なお、TCP/IP通信部１２に、ソケットディスクリプタの代わりに、またはこれに加えて、ソケットディスクリプタが示すTCPセッション情報そのものを渡しても良い。
【００３５】
TCP/IP通信部１２は、ソケットI/F部２１から送信要求を受けると、要求された送信データを、送信要求で指定された記憶領域から読み出す。TCP/IP通信部１２は、読み出したデータを、TCPセッション情報に従って、通信プロトコルに応じたメッセージフォーマットのパケットに成形する。TCP/IP通信部１２は、当該パケットをネットワーク２０１に送信する。送信データの例として、ネットワーク２０１上の相手装置が保有する特定のデータあるいは特定のファイルの送信を要求するGETリクエストメッセージがある。この場合、TCP/IP通信部１２は、GETリクエストメッセージをメモリ等の記憶領域から読み出して、送信することになる。
【００３６】
一方、ソケットI/F部２１は、アプリケーション１３から、recv()システムコールを介して、データ受信の要求を受け取ると、読み出し制御部２２に受信要求を出力する。この受信要求は、一例として、プロセスID、ソケットディスクリプタを含む。受信要求に、ソケットディスクリプタに加えて、ソケットディスクリプタが示すTCPセッション情報を含めても良い。
【００３７】
TCP/IP通信部１２は、読み出し制御部２２または転送処理部１４から、受信要求を受ける。受信要求は、セッション情報と、受信データの転送先のメモリアドレスを含む。TCP/IP通信部１２は、ネットワーク２０１から、セッション情報に示されるセッションのデータを受信し、受信したデータを、受信要求で指定されたメモリアドレスに書き込む。受信要求で指定されるメモリアドレスは、受信要求が転送処理部１４からのものである場合は、ダイレクトストレージアクセス処理部２４内の受信バッファのアドレスである。読み出し制御部２２からのものである場合は、外部のメインメモリ等のアドレスが指定される。
【００３８】
代行受信制御部２５は、転送処理部１４へ代行受信要求を、読み出し制御部２２へ代行受信登録要求を送る。代行受信要求は、ネットワーク２０１から入力されたデータを、（ホストCPUに代わって）ダイレクトストレージアクセス処理部２４によりTCP/IP通信部１２から受信してストレージ１５へ書き込むことの要求である。代行受信登録要求は、ソケットI/F部２１から受信要求されたセッションのデータを、読み出し制御部２２によりストレージ１５から読み出すことの要求である。代行受信制御部２５は、例えばOSの一機能に含まれてもよい。
【００３９】
代行受信要求と代行受信登録要求は、例えば代行受信要求を先に送り、その後に、代行受信登録要求を送ってもよい。あるいは、代行受信登録要求を先に送り、その後に、代行受信要求を送っても良い。あるいは、これらを同時に送っても良い。
【００４０】
代行受信制御部２５は、アプリケーション１３またはソケットI/F部２１によりソケット生成の通知を受けて、代行受信要求および代行受信登録要求を発行および出力してもよい。あるいは、アプリケーション１３によりソケット生成のシステムコールが呼ばれたことを検知して、代行受信要求および代行受信登録要求を発行および出力してもよい。ここで述べた以外の条件が成立したときに、これらの要求を発行および出力してもよい。
【００４１】
代行受信制御部２５から転送処理部１４へ送られる代行受信要求には、上述したように、TCPのセッション情報と、データの書き込み先情報が含まれている。データの書き込み先情報には、上述したように、ファイルディスクリプタ、および当該ファイルのファイルサイズ等が含まれる。ファイルディスクリプタは、例えば代行受信制御部２５が生成して、当該ファイルに割り当てる。
【００４２】
転送処理部１４は、代行受信制御部２５から代行受信要求を受け取ると、TCP/IP通信部１２に、セッション情報が示すセッションに関するデータの受信要求を出力する。ダイレクトストレージアクセス処理部２４は、当該セッションに関するデータをネットワーク２０１から受信して、自身の内部の受信バッファに書き込む。ダイレクトストレージアクセス処理部２４は、受信バッファのデータ格納状況に応じて、当該受信バッファからデータを読み出して（あるいはストレージ１５に読み出させて）、ストレージ１５における、上記ファイルディスクリプタを割り当てられたファイルに書き込む。転送処理部１４の動作の詳細は図５を用いて後述する。
【００４３】
代行受信制御部２５から読み出し制御部２２に渡す代行受信登録要求には、アプリケーション１３が作成したTCPセッションに関する情報と、ストレージ１５上に保存するファイルのファイルディスクリプタが含まれる。TCPセッションに関する情報は、ここでは、アプリケーションのプロセスID、ソケットディスクリプタを含むとする。したがって、代行受信登録は、プロセスID、ファイルディスクリプタおよびソケットディスクリプタを含む。
【００４４】
読み出し制御部２２は、代行受信登録要求を受けると、内部に保持する登録表から、当該要求に含まれるプロセスIDおよびソケットディスクリプタの組を含むエントリを検索する。マッチしたエントリのファイルディスクリプタフィールドに、当該要求に含まれるファイルディスクリプタを登録する。ファイルディスクリプタを登録した状態の例を図３（B）に示す。これら３つのフィールドの値を含むエントリが登録されることで、ソケットディスクリプタに示されるセッションに関する代行受信登録が完了する。
【００４５】
読み出し制御部２２は、ソケットI/F部２１から受信要求を受け取ると、受信要求に含まれるソケットディスクリプタと、アプリケーション１３のプロセスIDとの組を含むエントリを、登録表から検索する。該当するエントリがあり、かつエントリにファイルディスクリプタが登録されている場合は、ダイレクトストレージアクセス処理部２４により、当該ソケットディスクリプタが示すセッションのデータが代行受信されていることを意味する。このため、読み出し制御部２２は、当該エントリに記載されているファイルディスクリプタを用いて、ストレージ１５に記憶されているファイルからデータの読み出しを、ファイルI/F部２３に要求する。ストレージ１５上の当該ファイルからファイルI/F部２３により読み出したデータを、ソケットI/F部２１へ受信要求に対する応答として返す。ソケットI/F部２１は、当該データをアプリケーション１３に渡す。
【００４６】
ここで、仮に、ストレージ１５上のファイルから読み出したデータが空であった場合の動作は、アプリケーション１３の設計に依存する。例えば、データ存在しなかったことを示す応答（空データを示す応答）をする場合や、ストレージ１５上のファイルに受信データが蓄積されるまで待ち、再度、当該ファイルから読み出すなどある。あるいは、TCP/IP通信部１２に受信要求を行うことも可能である。
【００４７】
一方、読み出し制御部２２は、ソケットディスクリプタとプロセスIDの組を含むエントリにファイルディスクリプタが登録されていない場合、あるいは当該エントリが存在しない場合は、TCP/IP通信部１２へ受信要求を出力する（図２の矢印付きの点線によりこれが示される）。この場合、ダイレクトストレージアクセス処理部２４により当該ソケットディスクリプタが示すセッションのデータの代行受信は行われない。このため、通常のTCP/IP通信に基づき、ホストCPUの処理により、データ受信および書き込み（メインメモリ等への書き込み）を行う。この場合、ソケットI/F部２１は、TCP/IP通信部１２からメインメモリ等を介して、受信データを受け取る。
【００４８】
上述した説明では、ソケット生成時に、プロセスIDとソケットディスクリプタを含むエントリを登録表へ追加し、代行受信登録要求の発行に応じて、当該エントリ内にファイルディスクリプタを登録したが、これとは別の方法で、エントリを作成する方法も可能である。
【００４９】
例えばソケット生成時には登録表へのエントリの追加は行わず、代行受信登録要求を読み出し制御部２２が受信した時点で、プロセスIDとファイルディスクリプタとソケットディスクリプタとを含むエントリを、登録表に追加する。この場合、読み出し制御部２２は、ソケットI/F部２１から受信要求を受けたとき、当該受信要求に含まれるソケットディスクリプタとプロセスIDとの組を含むエントリを検索し、マッチするエントリが存在するかを確認する。マッチするエントリが存在すれば、（ファイルディスクリプタの有無を確認せずとも）、ダイレクトストレージアクセス処理部２４により該当セッションのデータが代行受信されていると判断できる。したがって、この場合、読み出し制御部２２は、TCP/IP通信部１２へ受信要求は出力せずに、ファイルI/F部２３にファイルの読み出し要求を行う。一方、マッチするエントリが登録表に存在しなければ、ダイレクトストレージアクセス処理部２４による代行受信は行われていないと判断し、TCP/IP通信部１２へ受信要求を行う。
【００５０】
以下、図４を用いて、本実施形態に係るデータ受信装置の動作の具体例を説明する。転送処理部１４へ代行受信要求が行われ、読み出し制御部２２へ代行受信登録要求が行われた後の動作を説明する。図において矩形の枠で囲まれた「１」、「２」、「３」、「４」、「５」、「６」、「７」は、同じTCPのセッションにおいて、この数字の順番で受信された受信データを表している。
【００５１】
データ「１」と「２」は、すでに受信され、ダイレクトストレージアクセス処理部２４により、ストレージ１５上のファイル（ファイルA）に先頭から順に書き込まれている。
【００５２】
アプリケーション１３は、当該ソケットディスクリプタ（図では、sockAと表現してあるが、実際には、数値でよい）を指定して、ソケットI/F部に受信要求recv()システムコールを発行済みである。
【００５３】
読み出し制御部２２が、ソケットI/F部からrecv()システムコールに起因する受信要求を受け、ファイルディスクリプタfileA（実際には、ファイルディスクリプタは数値でよい）を指定して、ファイルI/F部にファイルの読み出し要求を出している。ストレージ１５上の対応したファイルの先頭から、データ「１」と「２」が順次読み出され、ソケットディスクリプタsockAが示すセッションの受信データとして、アプリケーション１３に返されている。
【００５４】
また、ネットワーク２０１からは、順次、データ「３」、「４」が受信され、ストレージ１５上のファイルに、データ「２」に後続するように書き込まれている。さらに、データ「５」、「６」、「７」も順次受信されており、ファイルAに書き込まれつつある。
【００５５】
ファイルディスクリプタfileAのファイルからの次の読み出し先頭位置は、ファイルI/F部２３におけるファイルI/Oの管理にて実現される。
【００５６】
また、ダイレクトストレージアクセス処理部２４が、次にデータを書き込む先頭位置（つまりファイルの最後（EoF:End of File））の管理は、ダイレクトストレージアクセス処理部２４によって実現される。
【００５７】
図からは省略してあるが、ダイレクトストレージアクセス処理部２４によるファイルの最後（EoF）の更新は、ファイルI/F部２３にもファイルシステムの機構として認識可能である。
【００５８】
次の読み出し先頭位置と、次の書き込み先頭位置（EoF）が重なった状態が、ファイルに、未読み出しの受信データが存在しない状態である。この状態でストレージ１５からデータを読み出そうとすると、上述したように、ファイルからの読み出しデータが空であった場合になる。
【００５９】
以上のような動作により、ネットワーク２０１から受信したデータをダイレクトストレージアクセス処理部２４によりストレージ１５に書き込みつつ、書き込んだデータを、アプリケーションから、一般的なAPI、すなわち、ソケットI/F部とファイルI/F部が提供するAPI（システムコール）を利用して読み出すことができる。
【００６０】
図５に、転送処理部１４およびダイレクトストレージアクセス処理部２４の詳細構成を示している。転送処理部１４は、ダイレクトストレージアクセス処理部２４に加え、メタデータ生成部３１と、エクステントマップ取得部３２と、受信データ書き込み指示部３３を備える。ダイレクトストレージアクセス処理部２４は、コマンド発行部３５、受信処理部３６、通知振り分け部３７、受信バッファ３８を備える。メタデータ生成部３１と、エクステントマップ取得部３２と、受信データ書き込み指示部３３は、ホストCPU（OS）５１によって実現される。代行受信制御部２５もホストCPU（OS）５１によって実現される。図における矢印付きの破線は制御の流れを示し、矢印付きの太い実線は、ネットワーク２０１から受信したデータの流れを示し、矢印付きの細い実線は、受信したデータ以外のデータの流れを示す。
【００６１】
ストレージ１５は、データをブロック単位で管理する。一例として、セクタと呼ばれる単位で管理する。ここでは、抽象化してブロックと呼ぶ。ユーザが扱うデータは、ブロック単位ではないため、ストレージ１５は、通常、ファイルシステムによりアクセスされる。ファイルシステムは、バイト単位のデータを、ストレージ１５のブロック単位の記憶領域にマッピングする。各ブロックは、それぞれ各ブロックのアドレスによって識別される。ファイルシステムは、公知のものを利用すればよい。
【００６２】
典型的には、ファイルシステムでは、ストレージ上の所定領域にメタデータを記憶させる。メタデータには、データとデータが格納された位置とを互いに関連づけたマップ情報およびその他諸々の情報（ファイルディスクリプタ、タイムスタンプなど）を含められている。ストレージにデータを書き込む際は、まず、所定領域に格納されているメタデータ群を読み出し（あるいは事前にメインメモリに読み出したメタデータ群を用いてもよい）、メタデータ群を解析し、解析結果とデータのサイズから、データを書き込む位置（領域）を特定する。書き込む位置を特定すると、データに関するメタデータを生成し、ストレージの所定領域に、生成したメタデータを書き込む。この時、メタデータには、データが実際にどの位置（ブロック）に記憶されるのかを表すマップ情報を含める。また、そのマップ情報に従って、データをストレージに書き込む。本実施形態では、マップ情報として、エクステントマップを用いる例を示す。
【００６３】
図６を用いてエクステントマップを説明する。ここでは、ストレージの１ブロックが５１２バイトであるとする。ブロック２３５〜２３７に、所望のデータのある部分のデータが格納された様子が示される。データはブロック２３５の先頭から書き込みが開始され、ブロック２３５、２３６のすべてと、ブロック２３７の４３４バイト目まで連続して書き込まれている。書き込まれるデータの長さは１４５８バイトである。この場合、エクステントマップは、“ブロック２３５〜２３７、長さ１４５８”などと表される。
【００６４】
ここで述べた例では、ストレージにおいてデータが格納されている位置を、ブロックとデータ長で示したが、データが格納された位置が特定できれば、表現形式は問わない。例えば、始端バイト位置と終端バイト位置等で表しても良い。
【００６５】
また、ここで示した例では、一つのデータが、連続したブロック領域に格納される場合を示したが、エクステントマップは、複数のデータがそれぞれ離散して、各々連続したブロック領域に格納される形態でも良い。例えば、一つのエクステントマップによって、ブロック２３５、２３６と、ブロック２３７の先頭からの一部までに渡って格納されたデータ（１４５８バイト）と、ブロック３４６〜３４９とブロック３５０の先頭から一部までにわたって格納されたデータ（２０００バイト）の２つの離散した領域を表しても良い。
【００６６】
このように、エクステントマップは、データが格納されるブロックを特定する情報と、ブロックのうちの実際に有効データが格納されている位置ないしは範囲を特定する情報（有効データ位置情報）とを含む。これらの情報により、ストレージのどこに所望のデータが格納されているかを特定できる。
【００６７】
ファイルシステムとしては、以上のエクステントベースのファイルシステムのみならず、クラスタ（ブロック）ベースのファイルシステムも可能である。クラスタベースのファイルシステムの場合は、エクステントの代わりにクラスタのリスト（クラスタは離散的に配置されてよい）により、データが格納された領域を特定する。この場合も、これもエクステントの特殊な場合（一つのエクステントの長さをクラスタサイズに固定した物）とみなせば同様に考えることが可能である。以降はエクステントの用語を用いて説明するが、本実施形態は、これら両方を含むものとする。
【００６８】
ストレージ１５にはＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ  Ａｒｒａｙ  ｏｆ  Ｉｎｅｘｐｅｎｓｉｖｅ  Ｄｉｓｋｓ）機能を搭載してもよい。あるいは、ダイレクトストレージアクセス処理部２４内のストレージ１５とのＩ／Ｆに、ＲＡＩＤ機能を備えても良い。いずれの場合も本実施形態の本質とは関係ないので説明では割愛する。
【００６９】
メタデータ生成部３１は、ネットワーク２０１から受信するデータについて、ストレージ１５における当該データの書き込み位置を表すエクステントマップを含むメタデータを生成する。また、メタデータ生成部３１は、生成したメタデータを、ダイレクトストレージアクセス処理部２４を介して、ストレージ１５に書き込むための処理を行う。
【００７０】
より詳細に、メタデータ生成部３１は、代行受信制御部２３からファイルディスクリプタおよびファイルサイズ等を受け取ると、ストレージ１５のデータ格納領域の使用状況を確認するため、ストレージ１５の所定領域に格納されているメタデータ群を取得する。メタデータの取得のため、ダイレクトストレージアクセス処理部２４にメタデータの読み出し要求を送り、コマンド発行部３５が、当該読み出し要求に基づき、メタデータの読み出しコマンドを発行して、ストレージ１５に送る。ストレージ１５は当該メタデータの読み出しコマンドを実行して、所定領域内のメタデータを、メタデータ生成部３１に出力する。あるいは、事前に同様の方法でメインメモリにメタデータ群を読み出しておき、メインメモリからメタデータを取得してもよい。
【００７１】
メタデータ生成部３１は、取得したメタデータ群に基づき、ファイルディスクリプタに示されるファイルを格納するための位置（１つ以上のブロックのアドレスと、必要に応じてブロック内の有効データ位置）を特定し、特定した領域を表すマップ情報（エクステントマップ）やファイルディスクリプタ等を含むメタデータを生成する。メタデータ生成部３１は、生成したメタデータをエクステントマップ取得部３２に渡すとともに、生成したメタデータの書き込み要求を、コマンド発行部３５に送る。コマンド発行部３５は、メタデータの書き込み要求を受けて、メタデータの書き込みコマンドを発行し、ストレージ１５に送る。ストレージ１５は、メタデータの書き込みコマンドを実行して、書き込み要求されたメタデータを、内部の所定領域に格納する。
【００７２】
エクステントマップ取得部３２は、メタデータ生成部３１で生成されたメタデータから、書き込み対象となるファイルのエクステントマップを抽出する。なお、エクステントマップは、メタデータ生成部３１から取得するのではなく、メタデータ生成部３１が生成したメタデータをあらかじめメモリにキャッシュしていたものを参照することで取得してもよい。エクステントマップ取得部３２は、このようにして取得したエクステントマップを、受信データ書き込み指示部３３に渡す。
【００７３】
受信データ書き込み指示部３３は、エクステントマップと、データの受信を指示する情報（受信しようとするデータのセッション情報等）を、ダイレクトストレージアクセス処理部２４に出力する。これにより、ダイレクトストレージアクセス処理部２４に対して、データの受信と、ストレージ１５へのデータの書き込み指示を行う。
【００７４】
ダイレクトストレージアクセス処理部２４は、ホストCPU５１に代行して、ネットワーク２０１からデータを受信し、受信したデータをストレージ１５に書き込む処理を行う。
【００７５】
ダイレクトストレージアクセス処理部２４は、ハードウェアとソフトウェアのどちらで構成しても良く、これらの両方で構成されてもよい。実装の形態は問わないが、処理効率の観点から、ハードウェアベースで構成することが望ましい。ダイレクトストレージアクセス処理部２４の具体的な実装の形態としては、ＦＰＧＡや専用ＬＳＩが想定される。
【００７６】
受信バッファ３８は、TCP/IP通信部１２から入力されたデータを内部に一時的に格納する。図では、受信バッファ３８を示す枠内の領域を、ストレージ１５のブロックサイズごとに縦線で区切って表現している。受信バッファ３８は、TCP/IP通信部１２から入力されたデータを任意の方式で格納する。受信処理部３６から指示されたアドレスに格納する形態や、入力順に格納する（ＦＩＦＯなど）形態などがあり得る。後者の入力順に格納する形態は、例えば対向装置が送信する送信データ（ファイルデータ等）の先頭側のデータから順番に受信バッファ３８に入力されることが確保される場合に有効である。受信バッファ３８は、ストレージ１５からデータの出力指示を受けた場合に、指示されたデータをストレージ１５に出力する。あるいは、受信処理部３６からの出力指示に従って、指定されたデータをストレージ１５に出力する構成も可能である。
【００７７】
受信処理部３６は、TCP/IP通信部１２でフレームからデータが抽出されるごとに、抽出したデータの情報に関する通知を受ける。受信処理部３６は、エクステントマップと、TCP/IP通信部１２からの通知に基づき、データの受信状況を、バッファ情報として管理する。
【００７８】
受信バッファ３８へ、対向装置が送信する送信データ（ファイルデータ等）の先頭側のデータから順にデータが格納される場合、受信処理部３６はTCP/IP通信部１２からの通知に基づき、エクステントマップに示されるブロックのどのブロックまでのデータが受信されたかを把握できる。この場合、受信処理部３６は、例えば、データの先頭側から１ブロック分のデータが格納されるごとに、当該データを格納するブロックをエクステントマップから特定し、コマンド発行部３５に当該データを、特定したブロックへ書き込む要求を送る。複数ブロック分のデータをまとめて、書き込み要求を送っても良い。末尾のブロックではブロックサイズ分のデータが格納されない場合もあり、このときはパディングデータを付加して、ブロックサイズ分のデータとすればよい。コマンド発行部３５は、受信処理部３６からのデータの書き込み要求を受けて、指定されたデータを、ストレージ１５の指定された領域に書き込むためのコマンドを発行する。コマンド発行部３５は、発行したコマンドをストレージ１５に出力する。
【００７９】
また、受信処理部３６は、対向装置の送信データ（ファイルデータ等）におけるどの位置のデータが受信されたかを把握し、当該データを送信データ内の相対位置に応じたアドレスに格納するよう受信バッファ３８に指示してもよい。このことは、例えばTCP/IPの場合、対向装置の送信データ（ファイルデータ等）を構成する各データと、シーケンス番号とを対応付け可能であることから可能である。例えばTCP/IPでは、１バイトが、１シーケンス番号に対応する。この場合、受信バッファ３８は、受信処理部１０４から指示されたアドレスにデータを格納する。受信処理部３６は、受信バッファ３８の書き込み状況に応じて、ストレージ１５に書き込むべきデータを特定し、当該特定したデータをストレージ１５に書き込むことをコマンド発行部３５に要求する。コマンドを実行するストレージ１５からの読み出し要求に応じて、受信バッファ３８はデータを出力する。なお、受信処理部３６が、受信バッファ３８にデータの出力を指示し、ストレージ１５がこのデータを内部に取り込んでも良い。受信処理部３６は、例えば、エクステントマップに示されるブロックの１ブロックごとに、ブロックサイズ分のデータが受信バッファ３８に格納されたら、当該データを該当するブロックへ書き込む要求を、コマンド発行部３５に送る。コマンド発行部３５は、当該書き込み要求を受けて、指定されたデータを、ストレージ１５の指定された領域に書き込むためのコマンドを発行する。コマンド発行部３５は、発行したコマンドをストレージ１５に出力する。
【００８０】
コマンド発行部３５は、受信処理部３６またはメタデータ生成部３１から、書き込み要求、または読み出し要求を受ける。例えば、コマンド発行部３５は、受信処理部３６から、受信データの書き込み要求を受信する。また、メタデータ生成部３１から、メタデータの書き込み要求または読み出し要求を受信する。コマンド発行部３５は、要求された処理を実行するコマンドを発行し、発行したコマンドをストレージ１５に出力する。コマンドには、書き込み先の領域（ブロック）または読み出し先の領域を示す情報も含まれる。
【００８１】
また、コマンド発行部３５は、図２に示したファイルI/F部２３から読み出し要求を受け、要求された処理を実行するコマンドを発行し、発行したコマンドをストレージ１５に出力してもよい。このとき、ファイルI/F部２３は、ファイルディスクリプタから、ファイルが格納されている領域を、ストレージ１５の所定領域内のメタデータ群を解析して特定し、特定した領域からデータを読み出す読み出し要求を、コマンド発行部３５に送ってもよい。
【００８２】
ここで、コマンド発行部３５が発行するコマンドは、ストレージ１５側のＩ／Ｆ仕様に従ったものになる。一度に指定できる書き込みブロック数に限りがあったり、離散的なブロックは同時に指定できなかったり等の制限ある場合がある。この場合、コマンド発行部３５は、受信処理部３６またはメタデータ生成部３１からの１つの指示から、複数のコマンド群を生成する場合もある。
【００８３】
前述した図６の場合を例に、受信処理部３６およびコマンド発行部３５の動作例を示す。図６に示す１４５８バイトのデータがネットワーク２０１から受信され、受信バッファ３８に格納されていると仮定する。この場合、ブロックサイズよりも大きなデータが受信バッファ３８に書き込まれているので、書き込みコマンドを発行する。この時、ストレージ１５の書き込み位置は、エクステントマップから特定する。ここでは、ブロック２３５の先頭からデータを書き込むようにエクステントマップが指定されているとする。ブロック２３５、ブロック２３６については、ブロックサイズ分のデータが受信バッファ３８に書き込まれているので、ブロック２３５およびブロック２３６への書き込みコマンドを発行する。ブロック２３７は、ブロックサイズのデータが受信バッファ３８に書き込まれていないが、受信データの受信は完了しているとする。このため、後半７８バイト分のパディングデータを生成し、当該パディングデータを前半のデータの後ろに付加する。付加後のデータ（ブロックサイズ分のデータ）について、ブロック２３７への書き込みコマンドを発行する。
【００８４】
本実施形態では、コマンド発行部３５は、受信処理部３６からの要求を契機に、受信データの書き込みのコマンドを発行しているが、コマンド発行部３５自身が受信バッファ３８を監視して、ブロックサイズ分のデータが受信バッファ３８に書き込まれたことを検知して、コマンド発行を行っても良い。
【００８５】
通知振り分け部３７は、コマンド発行部３５が発行したコマンドの完了通知をストレージ１５から受けて、通知内容に応じて、書き込み完了通知または読み出し完了通知を、メタデータ生成部３１、受信データ書き込み指示部３３、またはファイルI/F部２３に通知する。
【００８６】
具体的に、通知振り分け部３７は、メタデータの書き込みまたは読み出しのコマンド完了通知を受けた場合は、メタデータ生成部３１に、書き込みまたは読み出しの完了通知を返す。受信データの書き込みのコマンド完了通知を受けた場合は、受信データ書き込み指示部３３に、書き込みの完了通知を返す。受信データ書き込み指示部３３は、書き込み完了通知を受けた場合、アプリケーション１３に、データの受信、および当該データのストレージ１５への書き込みが完了したことを、通知してもよい。また、通知振り分け部３７は、受信データの読み出しのコマンド完了通知を受けた場合は、ファイルI/F部２３に、読み出しの完了通知を返しても良い。
【００８７】
なお、ストレージ１５が、内部エラー等、何らかの理由により、コマンド発行部３５から渡されたコマンドの実行が完了できない場合がある。例えばタイムアウトの発生や、ストレージ１５に書き込むべきデータ（受信データまたはメタデータ）がメモリに格納されていない、その他、種々の理由があり得る。この場合、ストレージ１５は、ダイレクトストレージアクセス処理部２４にエラー通知を行う。このとき、ホストCPU５１にも、このエラーの情報を得られるように、ダイレクトストレージアクセス処理部２４の通知振り分け部３７が、ホストCPU５１にエラー通知を中継して、ホストCPU５１も、エラー情報を知ることができるようにしてもよい。
【００８８】
以上、本実施形態によれば、アプリケーションのアーキテクチャをプロキシ対応に限定することなく、ストレージへダイレクトストレージアクセス処理部により受信データを、ホストCPU５１を介さず、直接、高速に書き込むことができる。
【００８９】
すなわち、メタデータの生成等の複雑な処理のみをホストCPU（ソフトウェア）５１で行い、それ以外の処理、つまり、ネットワーク２０１から受信したデータのストレージへの書き込み処理をダイレクトストレージアクセス処理部（例えば専用のハードウェア装置）で行う。よって、処理効率が向上し、データ転送の速度を向上させることができる。また、本実施形態によれば、アプリケーションは、OS等が提供する通常のAPI（システムコール等）を用いて、ダイレクトストレージアクセス処理部２４がストレージに書き込んだデータを読み出すことができる。よって、アプリケーションのアーキテクチャをプロキシ対応させるといった従来の問題は発生せず、簡易なデータ読み出しが可能となる。
【００９０】
尚、本実施形態のデータ受信装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより、本データ受信装置を実現することができる。このとき、データ受信装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、CD-ROMなどの記憶媒体に記憶して、あるいは通信網を介して上記のプログラムを配布して、このプログラムをコンピュータ装置に配置することで実現出来る。また、ストレージおよび受信バッファは、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスク又はCD-R、CD-RW、DVD-RAM、DVD-R等の記憶媒体などを利用することが出来る。
【００９１】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００９２】
１０１：データ受信装置
２０１：ネットワーク
１１：無線通信I/F
１２：TCP/IP通信部
１３：アプリケーション
１４：転送処理部
１５：ストレージ
１６：アンテナ
２１：ソケットI/F部
２２：読み出し制御部
２３：ファイルI/F部
２４：ダイレクトストレージアクセス処理部
２５：代行受信制御部
３１：メタデータ生成部
３２：エクステントマップ取得部
３３：受信データ書き込み指示部
３５：コマンド発行部
３６：受信処理部
３７：通知振り分け部
３８：受信バッファ
【図１】
2015179444.tif 000003
【図２】
2015179444.tif 000004
【図３】
2015179444.tif 000005
【図４】
2015179444.tif 000006
【図５】
2015179444.tif 000007
【図６】
2015179444.tif 000008