データ配信ネットワークシステム及びデータ配信方法
【課題】ブロードキャスト、或いはマルチキャストによるデータ配信に関する問題、及びユニキャストによるデータ配信に関する問題という、相反する２つの問題を解決する。
【解決手段】サーバ１０のデータ送信制御モジュール１５は、送信用データの一部を先行送信データとして切り出すと、当該送信用データの残りの部分を遅延配信データとして遅延配信データ保持部１６に保持すると共に、当該先行送信データをデバイスドライバ１３及びネットワークインタフェース１４を介してブロードキャスト、或いはマルチキャストする。クライアントは、サーバ１０からの先行送信データを受信し、かつ当該先行送信データに対応する遅延配信データを必要とする場合、サーバ１０に対して遅延配信データの送信を要求する。するとサーバ１０のデータ送信制御モジュール１５は、遅延配信データ保持部１６に保持されている遅延配信データを要求元に送信する。
【解決手段】サーバ１０のデータ送信制御モジュール１５は、送信用データの一部を先行送信データとして切り出すと、当該送信用データの残りの部分を遅延配信データとして遅延配信データ保持部１６に保持すると共に、当該先行送信データをデバイスドライバ１３及びネットワークインタフェース１４を介してブロードキャスト、或いはマルチキャストする。クライアントは、サーバ１０からの先行送信データを受信し、かつ当該先行送信データに対応する遅延配信データを必要とする場合、サーバ１０に対して遅延配信データの送信を要求する。するとサーバ１０のデータ送信制御モジュール１５は、遅延配信データ保持部１６に保持されている遅延配信データを要求元に送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ブロードキャスト、マルチキャストまたはユニキャストによりサーバコンピュータからクライアント端末にデータを配信するデータ配信ネットワークシステム及びデータ配信方法に関する。
【背景技術】
【０００２】
従来から、サーバコンピュータが不特定多数、或いは特定多数のクライアント端末に対して同一データを配信するようなデータ配信ネットワークシステムが知られている。このようなデータ配信ネットワークシステムにおいて、データの配信には、以下に述べるように、ブロードキャスト、マルチキャスト、或いはユニキャストが用いられる。
【０００３】
・ブロードキャスト、或いはマルチキャストを使用する場合
サーバコンピュータは、クライアント端末側がデータを所望しているか否かに関わらず、ヘッダ及びペイロードを含む送信用データ全体をブロードキャスト、或いはマルチキャストするのが一般的である。
【０００４】
・ユニキャストを使用する場合
サーバコンピュータは、データを所望するクライアント端末にのみヘッダ及びペイロードを含む送信用データ全体を配信する。
【０００５】
一方、例えば特許文献１には、コンピュータ上で動作するアプリケーションプログラムが特定の仮想アドレス（ＩＯ空間）を参照した場合にページフォルトを発生させ、ページフォルトハンドラの処理にて、データをネットワークに送信し、それに対する応答を受信すると、ページフォルトハンドラからアプリケーションプログラムに復帰する仮想分散制御システムが開示されている。
また、例えば特許文献２には、ネットワークを仮想ネットワークにより構築する技術が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−１２７０８３号公報
【特許文献１】特開２００８−０４２６６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述したように、従来のデータ配信ネットワークシステムに関する技術（以下、先行技術と称する）では、ブロードキャスト、或いは、マルチキャストを使用する場合、サーバコンピュータは、クライアント端末側がデータを所望しているか否かに関わらず、ヘッダ及びペイロードを含む送信用データ全体をブロードキャスト、或いはマルチキャストする。このため先行技術では、サーバコンピュータによって配信されるデータを受信するクライアント端末が存在しない状態で、当該データがネットワーク上を流れる可能性がある。また、大多数のクライアント端末が受信を所望しないようなデータがネットワーク上を流れる可能性もある。したがって先行技術には、サーバコンピュータによるデータのブロードキャスト、或いはマルチキャストにより、ネットワークリソースを浪費するといった問題がある。この問題は、ペイロードのサイズが大きい場合、特に顕著となる。なお、ネットワークリソースは、回線の帯域やネットワーク装置のリソースだけでなく、サーバコンピュータやクライアント端末のネットワークインタフェース、ＣＰＵ及びメモリリソースも含む。
【０００８】
これに対し、先行技術においてユニキャストを使用する場合、サーバコンピュータはデータを所望するクライアント端末にのみ送信用データ全体を送信する。このため先行技術であっても、ユニキャストを使用する場合には、上記ブロードキャスト、或いはマルチキャストを使用する場合のような問題は生じない。しかし先行技術では、少なくともサーバコンピュータ（或いはネットワークノード）は、データ受信を所望するクライアント端末を何らかの方法で特定する必要があり、データ配信ネットワークシステムを構築、管理することが高コストとなってしまう。
【０００９】
本発明は上記事情を考慮してなされたものでその目的は、ブロードキャスト、或いはマルチキャストによるデータ配信に関する問題、及びユニキャストによるデータ配信に関する問題という、相反する２つの問題を解決することができるデータ配信ネットワークシステム及びデータ配信方法を提供することにある。
【課題を解決するための手段】
【００１０】
本発明の１つの観点によれば、サーバコンピュータと複数のクライアント端末とがネットワークによって接続されたデータ配信ネットワークシステムが提供される。このデータ配信ネットワークシステムにおいて、前記サーバコンピュータは、前記ネットワークを介してデータを送受信する第１の送受信手段と、前記ネットワークを介して送信されるべき送信用データの一部を先行送信データとして切り出して、当該先行送信データを前記第１の送受信手段によりブロードキャスト、或いはマルチキャストするデータ送受信制御手段と、前記送信用データの前記先行送信データを除く部分を遅延配信データとして保持する遅延配信データ保持手段とを含む。一方、前記複数のクライアント端末の各々は、前記ネットワークを介してデータを送受信する第２の送受信手段と、前記サーバコンピュータからブロードキャスト、或いはマルチキャストされた前記先行送信データが前記第２の送受信手段によって受信され、かつ当該先行送信データに対応する前記遅延配信データを必要とする場合、前記第２の送受信手段により前記サーバコンピュータに対して前記遅延配信データの送信を要求する遅延配信データ送信要求手段とを含む。前記サーバコンピュータの前記データ送受信制御手段は、前記複数のクライアント端末のいずれかのクライアント端末から、前記遅延配信データの送信が要求された場合に、前記遅延配信データ保持手段に保持されている前記遅延配信データを前記第１の送受信手段により当該遅延配信データの送信を要求したクライアント端末宛てに送信する。
【発明の効果】
【００１１】
本発明によれば、サーバコンピュータから、送信用データの一部のみが先行送信データとしてブロードキャスト、或いはマルチキャストされると、この先行送信データを受信し、かつ当該先行送信データに対応する未受信の残りのデータである遅延配信データを必要とするクライアント端末だけから、サーバコンピュータに遅延配信データの送信が要求され、この遅延配信データの送信を要求したクライアント端末だけに、サーバコンピュータから遅延配信データ（つまり残りのデータ）が送信される。これにより、ブロードキャスト、或いはマルチキャストによるデータ配信に関する問題、及びユニキャストによるデータ配信に関する問題という、相反する２つの問題を解決して、ネットワークリソースの浪費を防止し、かつクライアント管理の低コスト化を図ることができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の第１の実施形態に係るデータ配信ネットワークシステムの全体構成を示すブロック図。
【図２】第１の実施形態におけるクライアントの構成を示すブロック図。
【図３】第１の実施形態におけるサーバの構成を示すブロック図。
【図４】第１の実施形態で適用される受信バッファのデータ構造例を示す図。
【図５】送信用データ、先行送信データ及び遅延配信データの関係を、一般的な表現形式と、具体的な表現形式とでそれぞれ示す図。
【図６】受信バッファの初期データ構造例を示す図。
【図７】サーバにおける先行送信データ送信処理の手順を示すフローチャート。
【図８】クライアントにおける先行送信データ受信処理の手順を示すフローチャート。
【図９】ページフォルトハンドラによる遅延配信データ送信要求処理の手順を示すフローチャート。
【図１０】サーバにおける遅延配信データ送信処理の手順を示すフローチャート。
【図１１】クライアントにおける遅延配信データ受信処理の手順を示すフローチャート。
【図１２】本発明の第２の実施形態で適用される一般的なＯＳによる仮想ネットワークインタフェースの実装例を示す図。
【図１３】第２の実施形態で適用される一般的なＯＳによる仮想ネットワークインタフェースの実装例を示す図。
【図１４】第２の実施形態におけるクライアントの構成を示すブロック図。
【図１５】第２の実施形態におけるサーバの構成を示すブロック図。
【発明を実施するための形態】
【００１３】
以下、本発明の実施の形態につき図面を参照して説明する。
＜第１の実施形態＞
［全体構成］
図１は本発明の第１の実施形態に係るデータ配信ネットワークシステムの全体構成を示すブロック図である。
【００１４】
図１のデータ配信ネットワークシステムにおいて、サーバコンピュータ（以下、サーバと称する）１０と、複数のクライアント端末、例えばｎ台（ｎは１より大きい整数）のクライアント端末（以下、クライアントと称する）２０-1，２０-2，…２０-nは、ネットワーク３０によって相互に接続されている。このネットワーク３０が、単一のブロードキャストドメインをなしても、或いはルータ等により構成された複数ブロードキャストドメインをなしても構わない。
【００１５】
サーバ１０は、クライアント２０-i（ｉ＝１，２，…ｎ）に対して単一のサービス（データ配信）または複数のサービスを提供する。なお、図１の例では、単一のサーバ１０がネットワーク３０に接続されているが、サーバ１０を含む複数のサーバがネットワーク３０に接続されていてもよい。また、この複数のサーバが単一のサービスを提供するものであっても構わない。また、あるクライアント２０-iが享受するサービスは単一とは限らず、単一のサーバ１０から複数のサービスを享受する構成であっても構わない。また、サーバ１０を含む複数のサーバがネットワーク３０に接続されている場合、クライアント２０-iが、当該複数のサーバから複数のサービスを享受する構成であっても構わない。
【００１６】
［クライアント２０-iの構成］
図２はクライアント２０-iの構成を示すブロック図である。クライアント２０-iは、バッファ管理モジュール２１、ネットワークインタフェース２２、デバイスドライバ２３、ネットワークプロトコルモジュール２４、ページフォルトハンドラ２５、及びデータ処理モジュール２６を有している。クライアント２０-iは更に、遅延配信データ待ちバッファテーブル２７及び定義情報記憶部２８を有する。
【００１７】
バッファ管理モジュール２１は、デバイスドライバ２３、ネットワークプロトコルモジュール２４及びデータ処理モジュール２６がデータ送受信に使用するバッファを管理する。バッファ管理モジュール２１はまた、遅延配信データ待ちバッファテーブル２７を管理する。
【００１８】
ネットワークインタフェース２２は、データ送受信を行う周知のデバイスである。ネットワークインタフェース２２は、デバイスドライバ２３によって制御される。
デバイスドライバ２３は、ネットワークインタフェース２２を制御する、例えばソフトウェアモジュールである。デバイスドライバ２３は、通常の送受信処理に加え、サーバ１０から受信した遅延配信データを、遅延配信データ待ちバッファテーブル２７に保持されている受信バッファのバッファ制御情報に基づき、該当するページに格納する処理等も行う。
【００１９】
ネットワークプロトコルモジュール２４は、各通信レイヤに依存したデータ送受信を行うネットワークプロトコル群を有する。このネットワークプロトコルモジュール２４が有するネットワークプロトコル群は、サーバ１０からブロードキャスト、或いはマルチキャストされる後述する先行送信データが、通常の送信データ（以下、送信用データと称する）の先頭からどこまでを含むかにより変わる。ネットワークプロトコルモジュール２４に含まれないネットワークプロトコルは、データ処理モジュール２６に含まれて、当該データ処理モジュール２６で処理される。
【００２０】
ページフォルトハンドラ２５は、ページフォルトが発生した場合に呼び出される機能モジュールである。ページフォルトハンドラ２５は、サーバ１０への遅延配信データの要求、及び遅延配信データ待ちバッファテーブル２７への情報登録等を行う。
【００２１】
データ処理モジュール２６は、サーバ１０によって配信されるデータを処理する処理主体をなす。データ処理モジュール２６は、このデータに係わる処理に加えて、上記ネットワークプロトコルに含まれない部分のネットワークプロトコルに係わる処理を行う。
【００２２】
遅延配信データ待ちバッファテーブル２７は、後述する遅延配信データの待ち状態にある受信バッファの一覧（更に詳細に述べるならば受信バッファのバッファ制御情報の一覧）を保持するのに用いられるバッファ制御情報保持手段である。定義情報記憶部２８については後述する。
【００２３】
［サーバ１０の構成］
図３はサーバ１０の構成を示すブロック図である。サーバ１０は、データ配信モジュール１１、ネットワークプロトコルモジュール１２、デバイスドライバ１３、ネットワークインタフェース１４及びデータ送信制御モジュール１５を有する。サーバ１０は更に、遅延配信データ保持部１６及び定義情報記憶部１７を有する。
【００２４】
データ配信モジュール１１は、サーバ１０におけるデータ配信の処理主体をなす。ネットワークプロトコルモジュール１２は、クライアント２０-i内のネットワークプロトコルモジュール２４と同様に、各通信レイヤに依存したデータ送受信を行うネットワークプロトコル群を有する。
【００２５】
デバイスドライバ１３は、ネットワークインタフェース１４を制御する、例えばソフトウェアモジュールである。ネットワークインタフェース１４は、クライアント２０-i内のネットワークインタフェース２２と同様に、データ送受信を行う周知のデバイスである。ネットワークインタフェース１４は、デバイスドライバ１３によって制御される。
【００２６】
データ送信制御モジュール１５は、先行技術であればブロードキャスト、或いはマルチキャストされる送信データ（以下、送信用データと称する）からの、本実施形態においてブロードキャスト、或いはマルチキャストすべきデータ（以下、先行送信データと称する）の切り出しと当該先行送信データの送信とを制御する。データ送信制御モジュール１５はまた、送信用データから切り出されなかった残りのデータである遅延配信データを遅延配信データ保持部１６に保持する。データ送信制御モジュール１５は更に、先行送信データのブロードキャスト、或いはマルチキャストに応じてクライアント２０-iから送られる未受信部分の送信要求に対する応答としての遅延配信データの送信を制御する。
【００２７】
遅延配信データ保持部１６は、データ送信制御モジュール１５によって送信用データから切り出されなかったデータを、クライアント２０-iからの未受信部分の送信要求に対して当該クライアント２０-iに送信されるべき遅延配信データとして保持するのに用いられる。定義情報記憶部１７については後述する。
【００２８】
本実施形態において、サーバ１０によりブロードキャスト、或いは、マルチキャストされる先行送信データに関する定義情報が、予めサーバ１０と各クライアント２０-iとの間で共有されているものとする。この定義情報は、送信用データのうち、ネットワークプロトコルヘッダ、或いは、ペイロードのどこまでが先行送信データに含まれるかを示すもので、先行送信データ長情報を含む。この先行送信データ長情報は、先行送信データのデータ長を示す。サーバ１０が有する定義情報記憶部１７及びクライアント２０-iが有する定義情報記憶部２８は、この定義情報を格納するのに用いられる。
【００２９】
更に、サーバ１０によるブロードキャスト、或いはマルチキャストで使用される宛先アドレスも、予め、サーバ１０と各クライアント２０-iとの間で共有されており、当該アドレスを宛先アドレスとして持つデータはクライアント２０-iのネットワークインタフェース２２により受信されるものとする。
【００３０】
［受信バッファのデータ構造］
図４は、受信バッファのデータ構造例を示す。受信バッファはデータ（実体）を格納するためのメモリページ（以下、単にページと称する）とバッファ制御情報とから構成される。このページは仮想アドレス空間内の仮想ページであり、データを格納するのに用いられる場合、このページに物理ページが割り当てられる。
【００３１】
バッファ制御情報は、対応する受信バッファを識別するための識別子（以下、配信データ識別子と称する）を含む。この配信データ識別子には、対応する遅延配信データを含む送信用データに固有のシーケンス番号、或いはサーバ１０にて遅延配信データから算出されるハッシュ値等を用いることができる。
【００３２】
バッファ制御情報はまた、対応する先行送信データ及び遅延配信データを合わせたデータ長を示す全データ長情報を含む。バッファ制御情報は更に、先行送信データの一部または全部を保持するのに用いられる受信バッファ内のページと、遅延配信データの一部または全部を保持するのに用いられる受信バッファ内のページの各々について、そのページを管理するためのページ情報を含む。ページ情報は、オフセット情報とデータ長情報と仮想アドレスとを含む。オフセット情報は、対応するページに格納されるデータ部分の始端の、送信用データにおける位置、つまりオフセット位置を示す。データ長情報は、上記データ部分のデータ長を示す。仮想アドレスは、対応するページの仮想アドレス空間におけるアドレス（ページアドレス）を示す。
【００３３】
なお、以降の説明では、説明の簡略化のために、先行送信データ及び遅延配信データを格納するのに用いられるページは１ページのみであるとする。
【００３４】
［送信用データ、先行送信データ及び遅延配信データの関係］
図５は送信用データ、先行送信データ及び遅延配信データの関係を、一般的な表現形式と、具体的な表現形式とでそれぞれ示す。
【００３５】
図５（ａ）は一般的な表現形式の例を示しており、送信用データは、Ｎ個のネットワークプロトコルヘッダ＃１〜＃Ｎと、ペイロードとから構成されている。図５（ａ）の例では、先行送信データは、先頭のネットワークプロトコルヘッダ＃１と、後続のネットワークプロトコルヘッダ＃２の一部とから構成されている。しかし、先行送信データが、複数のネットワークプロトコルヘッダと、当該複数のネットワークプロトコルヘッダに後続するネットワークプロトコルヘッダ（つまり複数のネットワークプロトコルよりも上位の階層のネットワークプロトコルのヘッダ）の一部とから構成されていてもよい。また、先行送信データが、全てのネットワークプロトコルヘッダから構成されていても、或いは全てのネットワークプロトコルヘッダと、ペイロードの一部とから構成されていてもよい。
【００３６】
ネットワークプロトコルヘッダは、標準化されたネットワークプロトコルのヘッダであり、システムによっては、プロトコル階層の中で複数回現れることもある。標準化されたネットワークプロトコルのヘッダとしては、例えば、イーサネット（登録商標）、ＰＰＰ（Point to Point Protocol）等のリンク層プロトコルのヘッダ、ＩＰ（Internet Protocol）、ＡＲＰ（Address Resolution Protocol）等のネットワーク層プロトコルのヘッダ、ＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）、ＳＣＴＰ（Stream Control Transmission Protocol）、ＲＴＰ（Real-time Transport Protocol）、ＲＴＣＰ（RTP Control Protocol）等のトランスポート層以上のプロトコルのヘッダが知られている。
【００３７】
ペイロードとは、ある層のプロトコルから見た場合の上位層のデータのことであり、プロトコル層が変わればペイロードが意味する部分も異なる。ペイロードは、ある層のプロトコルから見た場合の上位層のプロトコルのヘッダ、アプリケーションのヘッダ（制御情報）、アプリケーションのデータ等である。
【００３８】
図５（ｂ）は具体的な表現形式の例を示しており、送信用データは、３つのネットワークプロトコルヘッダである、イーサネットヘッダ、ＩＰヘッダ及びＵＤＰヘッダと、ペイロードをなすアプリケーション制御情報及びアプリケーションデータとから構成されている。図５（ｂ）の例では、先行送信データは、全てのネットワークプロトコルヘッダと、後続のアプリケーション制御情報の一部とから構成されている。
【００３９】
本実施形態において、先行送信データに属する先頭のネットワークプロトコルヘッダは、送信用データの全データ長を示す全データ長情報を含むものとする。なお、送信用データ中の先頭のネットワークプロトコルヘッダの始端側の一部だけを、先行送信データとしても構わない。但し、先行送信データを構成する先頭のネットワークプロトコルヘッダの一部に、先行送信データがサーバからクライアントへ到達するために必要な情報が含まれている必要がある。
【００４０】
［動作］
次に、図１に示されるデータ配信ネットワークシステムにおける動作について説明する。
まずクライアント２０-iのバッファ管理モジュール２１は、定義情報記憶部２８に記憶されている定義情報に基づき、受信バッファを用意する。この受信バッファは初期化されたバッファ制御情報を含む。
【００４１】
図６は、このときの受信バッファのデータ構造例を示す。図６に示すように、バッファ制御情報（初期バッファ制御情報）は、有効な配信データ識別子及び全データ長情報を含んでいない点に注意されるべきである。また、このバッファ制御情報は、図６の例では、２つのページ情報６１及び６２を含む。
【００４２】
ページ情報６１は、有効なオフセット情報、有効なデータ長情報及び有効な仮想アドレスを含む。ページ情報６１中のオフセット情報、データ長情報は、それぞれ、オフセット０、先行送信データ長を示す。また、ページ情報６１中の仮想アドレスは、先行送信データを格納するための受信バッファ内のページ６３を指し示す。本実施形態において、このページ６３には、当該ページ６３を含む受信バッファが用意される際に、物理ページが割り当てられる。つまり受信バッファが用意される際、ページ（第１のメモリページ）６３を指定するページ情報６１中の仮想アドレス（第１の仮想アドレス）には、物理ページが割り当てられる。
【００４３】
これに対し、ページ情報６２は、有効なオフセット情報及び有効な仮想アドレスを含む一方、有効なデータ長情報を含んでいない。ページ情報６２中のオフセット情報は先行送信データ長を示す。また、ページ情報６２中の仮想アドレスは、遅延配信データを格納するための受信バッファ内のページ６４を指し示す。本実施形態において受信バッファが用意される際、このページ情報６２中の仮想アドレスによって指定されるページ６４には、物理ページが割り当てられていない点に注意すべきである。つまり本実施形態では、受信バッファが用意される際、ページ（第２のメモリページ）６４を指定するページ情報６２中の仮想アドレス（第２の仮想アドレス）には、物理ページが割り当てられていない。ページ情報６２に有効なデータ長情報が設定され、ページ６４に物理ページが割り当てられるのは、クライアント２０-iがサーバ１０から遅延配信データを受信した場合である。
【００４４】
さて、クライアント２０-iのバッファ管理モジュール２１によって図６に示されるような構造の受信バッファが用意されている状態で、サーバ１０のデータ配信モジュール１１が、不特定多数、或いは、特定多数のクライアント２０-iに配信するデータを準備したものとする。これ以降のデータ配信ネットワークシステムにおける動作について、先行送信データ送信処理、先行送信データ受信処理、遅延配信データ送信要求処理、遅延配信データ送信処理及び遅延配信データ受信処理を例に順に説明する。
【００４５】
・先行送信データ送信処理
まず、サーバ１０における先行送信データ送信処理について、図７のフローチャートを参照して説明する。
サーバ１０のデータ配信モジュール１１は、準備したデータの送信をネットワークプロトコルモジュール１２に依頼する。
【００４６】
ネットワークプロトコルモジュール１２は、データ配信モジュール１１からのデータ送信の依頼を受け取ると、個々のプロトコル依存の処理を行うことにより、例えば図５に示されるような複数のネットワークプロトコルヘッダが付加された送信用データを生成する（ステップ７０１）。ネットワークプロトコルモジュール１２は、生成した送信用データをデータ送信制御モジュール１５に渡す。
【００４７】
データ送信制御モジュール１５は、ネットワークプロトコルモジュール１２から送信用データを受け取ると、当該データの一部を先行送信データとして切り出す（ステップ７０２）。ここではデータ送信制御モジュール１５は、送信用データの始端から、定義情報記憶部１７に格納されている定義情報で示されるデータ長だけ、先行送信データとして切り出す。データ送信制御モジュール１５は、送信用データから切り出した先行送信データのみの送信をデバイスドライバ１３に依頼する。
【００４８】
次にデータ送信制御モジュール１５は、送信用データから切り出されなかった残りのデータ、つまり送信用データのうちの先行送信データの終端以降のデータを、遅延配信データとして遅延配信データ保持部１６に保持する（ステップ７０３）。データ送信制御モジュール１５は、この遅延配信データ保持部１６における遅延配信データの保持期間を管理する。
【００４９】
本実施形態では、遅延配信データ保持部１６に保持されてから一定期間が経過した遅延配信データは、データ送信制御モジュール１５によって廃棄される。なお、遅延配信データ保持部１６に保持されている遅延配信データに対する送信要求を、データ送信制御モジュール１５が一定数受信するまで、当該遅延配信データが遅延配信データ保持部１６に保持される構成であっても構わない。また、廃棄されるべき遅延配信データがＬＲＵ（Least Recently Used）アルゴリズムにより決定される構成であっても構わない。また、遅延配信データ保持部１６における遅延配信データの保持期間が、データ送信制御モジュール１５とは別の専用の管理モジュール（遅延配信データ保持管理モジュール）によって管理されても構わない。
【００５０】
本実施形態において、先行送信データの送信時と、遅延配信データの遅延配信データ保持部１６への保持時には、当該データに配信データ識別子が付加される。この配信データ識別子には、前述したように、送信用データを構成する先行送信データ及び遅延配信データに固有のシーケンス番号、或いは遅延配信データのハッシュ値等、先行送信データと遅延配信データとの対応を取るための情報が用いられる。
【００５１】
デバイスドライバ１３は、データ送信制御モジュール１５から依頼された、配信データ識別子が付加された先行送信データを、前述の予め決められたブロードキャストアドレス、或いはマルチキャストアドレスを宛先アドレスとして、ネットワークインタフェース１４により送信する（ステップ７０４）。つまり先行送信データは、第１のデータ送受信手段として機能する、デバイスドライバ１３及びネットワークインタフェース１４によって、ブロードキャスト、或いはマルチキャストされる。
【００５２】
・先行送信データ受信処理
次に、クライアント２０-iにおける先行送信データ受信処理について、図８のフローチャートを参照して説明する。
上述のように、予め決められたブロードキャストアドレス、或いは、マルチキャストアドレスを宛先アドレスとして、サーバ１０から先行送信データが送信されると、当該宛先アドレスを持つデータを受信するように設定されたクライアント２０-iのデバイスドライバ２３は、ネットワークインタフェース２２により当該先行送信データを受信する（ステップ８０１）。つまりサーバ１０からブロードキャスト、或いはマルチキャストされた先行送信データが、第２のデータ送受信手段として機能する、ネットワークインタフェース２２及びデバイスドライバ２３によって受信される。
【００５３】
デバイスドライバ２３は先行送信データを受信すると格納処理手段として機能して、バッファ管理モジュール２１によって用意されている受信バッファのバッファ制御情報を参照する（ステップ８０２）。そしてデバイスドライバ２３は、バッファ制御情報中のページ情報６１に基づき、受信バッファ内の先行送信データ用のページ６３、つまり物理ページが割り当てられているページ６３を特定する（ステップ８０３）。
【００５４】
デバイスドライバ２３は、特定したページ６３に、受信した先行送信データを格納する（ステップ８０４）。またデバイスドライバ２３は、受信した先行送信データに付加されている配信データ識別子を、受信バッファのバッファ制御情報中に追加設定する（ステップ８０５）。
【００５５】
またデバイスドライバ２３は、受信した先行送信データに含まれている全データ長情報を受信バッファのバッファ制御情報中に追加設定する（ステップ８０６）。デバイスドライバ２３は更に、この全データ長情報の示す送信用データの全データ長と、先行送信データのデータ長とから、未受信の遅延配信データのデータ長を算出する（ステップ８０７）。次にデバイスドライバ２３は、遅延配信データがあたかも遅延配信データ用のページ６４に格納されているかのように、上記算出した遅延配信データのデータ長を示すデータ長情報と、オフセット情報（先行送信データのデータ長と等価）とを、受信バッファのバッファ制御情報のページ情報６２中に追加設定する（ステップ８０８）。このページ情報６２は、前述したように遅延配信データ用のページ６４を管理するための情報である。デバイスドライバ２３はステップ８０８を実行すると、ステップ８０４〜８０６，８０８の処理が行われた受信バッファ（更に詳細に述べるならば受信バッファのバッファ制御情報）をネットワークプロトコルモジュール２４に渡す。
【００５６】
ネットワークプロトコルモジュール２４は、デバイスドライバ２３から受信バッファのバッファ制御情報を受け取ると、次のような処理を実行する。即ちネットワークプロトコルモジュール２４は、バッファ制御情報のページ情報６１によって示される受信バッファ内のページ６３に格納されている受信データ（つまり先行送信データ）に対して個々のプロトコル依存の処理を行い、処理されたデータを、受信バッファのバッファ制御情報と共にデータ処理モジュール２６に渡す（ステップ８０９）。なお、ここでは、ネットワークプロトコルの処理に必要なデータは全て先行送信データに含まれているものとする。もし、そのようなデータが含まれていない場合、そのデータ部分に関するネットワークプロトコルの処理をデータ処理モジュール２６が受け持てばよい。つまり、先行送信データの内容（長さ）により、ネットワークプロトコルモジュール２４とデータ処理モジュール２６の役割分担（境界）は可変となることを意味する。
【００５７】
データ処理モジュール２６は、ネットワークプロトコルモジュール２４からプロトコル処理済みの先行送信データ及びバッファ制御情報を受け取ると、当該データが所望のデータ（更に詳細には所望のデータの一部）であるかを判定する（ステップ８１０）。もし、所望のデータであるならば、データ処理モジュール２６は所望の処理を行うために、バッファ制御情報中のページ情報６２に基づいて、受信バッファ内の遅延配信データ用のページ６４にアクセスする（ステップ８１１）。このとき、遅延配信データ用のページ６４には物理ページが割り当てられていない。つまりデータ処理モジュール２６は、ページ情報６２中の物理アドレスが未割り当ての仮想アドレスの指し示すページ６４にアクセスする。このため、遅延配信データ用のページ６４へのアクセスに応じてページフォルトが発生し、ページフォルトハンドラ２５が呼び出される。
【００５８】
・遅延配信データ送信要求処理
次に、ページフォルトハンドラ２５による遅延配信データ送信要求処理について、図９のフローチャートを参照して説明する。
ページフォルトハンドラ２５はページフォルトの発生に応じて呼び出されると、当該ページフォルト発生の原因となった受信バッファ内の遅延配信データ用のページ６４に対して物理ページを割り当てる（ステップ９０１）。つまりページフォルトハンドラ２５は、物理ページ未割り当ての遅延配信データ用のページ６４を指定する仮想アドレスに、物理ページを割り当てる。このことは、ページフォルトハンドラ２５が、受信バッファ内に遅延配信データ用の物理ページを追加したことと等価である。
【００５９】
次にページフォルトハンドラ２５は、物理ページが割り当てられたページ６４を含む遅延配信データの待ち状態にある受信バッファ（更に詳細には受信バッファのバッファ制御情報）を、遅延配信データ待ちバッファテーブル２７に追加する（ステップ９０２）。
【００６０】
次にページフォルトハンドラ２５は遅延配信データ送信要求手段として機能して、遅延配信データ待ちバッファテーブル２７に追加された受信バッファのバッファ制御情報によって示される当該受信バッファ内のページ６３に格納されている先行送信データに対応する遅延配信データ、即ち送信用データ中の先行送信データを除く未受信のデータ部分の送信をサーバ１０に対して要求する（ステップ９０３）。本実施形態では、このページフォルトハンドラ２５からの遅延配信データの送信要求が、ネットワークプロトコルモジュール２４及びデバイスドライバ２３を用いて、ネットワークインタフェース２２から送出されるものとする。この送信要求には、遅延配信データ待ちバッファテーブル２７に追加された受信バッファのバッファ制御情報中の配信データ識別子が付加される。ページフォルトハンドラ２５は、サーバ１０に対して遅延配信データを要求すると、データ処理モジュール２６を停止状態にして（ステップ９０４）、処理を終了する。
【００６１】
・遅延配信データ送信処理
次に、サーバ１０における遅延配信データ送信処理について、図１０のフローチャートを参照して説明する。
クライアント２０-iからサーバ１０宛てに遅延配信データの送信要求が送信されると、、サーバ１０のデータ送信制御モジュール１５は、ネットワークインタフェース１４及びデバイスドライバ１３を介して、当該遅延配信データの送信要求を受信する（ステップ１００１）。するとデータ送信制御モジュール１５は、受信した遅延配信データの送信要求に付加されている配信データ識別子に基づき、要求された遅延配信データが遅延配信データ保持部１６に存在するかを判定する（ステップ１００２）。即ちデータ送信制御モジュール１５は、クライアント２０-iからの送信要求に付加されているのと同一の配信データ識別子が付加されている遅延配信データが遅延配信データ保持部１６に存在するかを判定する。もし、要求された遅延配信データが存在するならば、データ送信制御モジュール１５は、当該遅延配信データを、クライアント２０-iからの送信要求に対する応答として、配信データ識別子が付加されている状態で、デバイスドライバ１３及びネットワークインタフェース１４を介して当該クライアント２０-i宛てに送信する（ステップ１００３）。ここでデータ送信制御モジュール１５によってクライアント２０-iに送信される遅延配信データの始端側には、当該遅延配信データがクライアント２０-iで受信可能なように、当該クライアント２０-iを宛先とし、サーバ１０を送信元として指定するネットワークプロトコルヘッダが付加される。
【００６２】
・遅延配信データ受信処理
次にクライアント２０-iにおける遅延配信データ受信処理について、図１１のフローチャートを参照して説明する。
クライアント２０-iのデバイスドライバ２３は、サーバ１０からクライアント２０-i宛てに遅延配信データが送信されると、当該遅延配信データをネットワークインタフェース２２を介して受信する（ステップ１１０１）。するとデバイスドライバ２３は、受信した遅延配信データに付加されているのと同一の配信データ識別子を含むバッファ制御情報が遅延配信データ待ちバッファテーブル２７に保持されているかを判定する（ステップ１１０２）。
【００６３】
もし、該当するバッファ制御情報が保持されているならば、デバイスドライバ２３は、当該バッファ制御情報中のページ情報６２に基づき、対応する受信バッファ内の遅延配信データ用のページ６４を特定する（ステップ１１０３）。そしてデバイスドライバ２３は、受信した遅延配信データを、ステップ１１０３で特定したページ６４に格納し（ステップ１１０４）、停止状態に設定されているデータ処理モジュール２６を動作状態にする（ステップ１１０５）。データ処理モジュール２６は動作状態になると、ページフォルトが発生した時点から処理を再開する。
【００６４】
デバイスドライバ２３は、データ処理モジュール２６を動作状態に設定すると、受信した遅延配信データに付加されているのと同一の配信データ識別子を含むバッファ制御情報を遅延配信データ待ちバッファテーブル２７から削除する（ステップ１１０６）。このことは、遅延配信データ待ちバッファテーブル２７によって遅延配信データの待ち状態にあるとして管理されていた受信バッファを、当該遅延配信データの待ち状態から解放したことと等価である。
【００６５】
このように、本実施形態においてサーバ１０は、送信用データの一部のみを先行送信データとして切り出して、当該先行送信データをブロードキャスト、或いはマルチキャストする。先行送信データは、送信用データ中の全ネットワークプロトコルのヘッダ、或いは、一部のネットワークプロトコルのヘッダと後続のネットワークプロトコルのヘッダの一部、或いは全ネットワークプロトコルのヘッダと後続のペイロードの一部、或いは先頭のネットワークプロトコルのヘッダの一部である。
【００６６】
サーバ１０からの先行送信データを受信したクライアント２０-iは、当該受信したデータが所望のデータであるかを判定し、所望のデータである場合にのみ、サーバ１０に対して残りのデータ（つまり未受信のデータ）である遅延配信データの送信を要求する。
【００６７】
サーバ１０は、クライアント２０-iからの送信要求を受信することにより、当該クライアント２０-iが、送信用データのうち、先行送信データとして切り出されなかった残りのデータを要求していることを検出する。そこでサーバ１０は、送信用データのうちの残りのデータを要求しているクライアント２０-iに対してのみ、当該残りのデータを遅延配信データとして送信する。
【００６８】
これにより本実施形態においては、ブロードキャスト、或いはマルチキャストによるデータ配信に関する問題、及びユニキャストによるデータ配信に関する問題という、相反する２つの問題を解決し、ネットワークリソースの浪費を防止し、かつクライアント管理の低コスト化を図ることができる。
【００６９】
［先行送信データ長の決定］
次に、定義情報記憶部２８に格納されている定義情報によって定義される先行送信データ長について説明する。
【００７０】
前述したように、第１の実施形態では、先行送信データに関する定義情報は、予めサーバ１０と各クライアント２０-iとの間で共有されている。つまり第１の実施形態では、定義情報によって定義される先行送信データ長は、サーバ１０と各クライアント２０-iに、静的に設定される。この先行送信データ長を決定し、運用する方法として、例えば次のような「コンフィグレーション」または「アナウンス」による方法が適用可能である。
【００７１】
・コンフィグレーション
コンフィグレーションによる方法では、先行送信データ長が、サーバ１０のデータ配信モジュール１１及びクライアント２０-iのデータ処理モジュール２６の仕様、つまり、データ配信ネットワークシステム及びアプリケーションの仕様に従って予め決定される。この決定に従い、対応する先行送信データ長を含む定義情報が、サーバ１０の定義情報記憶部１７及び各クライアント２０-iの定義情報記憶部２８に、予め静的に設定される。
【００７２】
・アナウンス
サーバ１０のデータ配信モジュール１１が、データ配信のサービス開始時、或いは定期的に、予め定められた手段、例えば、データ配信に使用するものと同じアドレスを使用して、先行送信データ長を含む定義情報をブロードキャスト、或いはマルチキャストする。各クライアント２０-iは、サーバ１０から定義情報がブロードキャスト、或いはマルチキャストされると、その定義情報を受信して、その受信した定義情報を定義情報記憶部２８に格納する。クライアント２０-iは、前述したように、定義情報記憶部２８に格納されている定義情報に従い、処理を行う。この方法も、先行送信データ長が静的に設定される。
【００７３】
・先行データ長の動的設定
しかし、以下に述べるように、サーバ１０が動的に先行送信データ長を決定して、運用する方法を適用することも可能である。
【００７４】
まず、サーバ１０によって提供されるサービスを享受する各クライアント２０-iは、先行送信データ長としてＫ、Ｌ、Ｍのいずれかを使用するものとする。Ｋ、Ｌ、Ｍは、０＜Ｋ＜Ｌ＜Ｍであるものとする。ここで、先行送信データと遅延配信データとを合わせたデータ、つまり送信用データの全体長がＮであるとすると、Ｎ、Ｋ、Ｌ、Ｍは、０＜Ｋ＜Ｌ＜Ｍ＜Ｎのような関係を有する。
【００７５】
サーバ１０の例えばデータ送信制御モジュール１５は、各クライアント２０-iに送信される先行送信データのデータ長である先行送信データ長を、例えばＮ、Ｍ、Ｌ、Ｋと変化させる。なお、Ｍ、Ｌ、Ｋ以外の長さでもよい。
サーバ１０が、先行送信データ長を変化させると、各クライアント２０-iが先行送信データ長として認識する長さの違いにより、以下のクライアントにてページフォルトが発生する。結果的にサーバ１０は、ページフォルトが発生したクライアントから遅延配信データの送信要求を受け取ることになる。
【００７６】
・先行送信データ長がＮの場合
ページフォルトが発生するクライアントはない。
【００７７】
・先行送信データ長がＭの場合
先行送信データ長をＭと認識しており、かつ、遅延配信データを所望するクライアントと、
先行送信データ長をＬと認識しており、かつ、遅延配信データを所望するクライアントと、
先行送信データ長をＫと認識しており、かつ、遅延配信データを所望するクライアントと
でページフォルトが発生。
【００７８】
・先行送信データ長がＬの場合
先行送信データ長をＭと認識している全てのクライアントと、
先行送信データ長をＬと認識しており、かつ、遅延配信データを所望するクライアントと、
先行送信データ長をＫと認識しており、かつ、遅延配信データを所望するクライアントと
でページフォルトが発生。
【００７９】
・先行送信データ長がＫの場合
先行送信データ長をＭと認識している全てのクライアントと、
先行送信データ長をＬと認識している全てのクライアントと、
先行送信データ長をＫと認識しており、かつ、遅延配信データを所望するクライアントと
でページフォルトが発生。
【００８０】
・先行送信データ長“ｌｅｎ”が０＜ｌｅｎ＜Ｋの場合
先行送信データ長をＭと認識している全てのクライアントと、
先行送信データ長をＬと認識している全てのクライアントと、
先行送信データ長をＫと認識している全てのクライアントと
でページフォルトが発生。
【００８１】
このように、図１に示されるデータ配信ネットワークシステムにおいて、ページフォルトが発生するクライアント２０-iの数、すなわち、サーバ１０がクライアントから受け取る遅延配信データの送信要求の数（遅延配信データ送信要求数）は、先行送信データ長としてＭ、Ｌ、Ｋを使用しているクライアント２０-iの割合、及び、更にその中で遅延配信データを所望するクライアント２０-iの割合に依存する。
【００８２】
そこでサーバ１０の例えばデータ送信制御モジュール１５は、上述のクライアント２０-iの割合を前もって認識できない場合、先行送信データ長を逐次変化させることにより、先行送信データ長毎に、当該サーバ１０が実際に受け取ることが期待される遅延配信データ送信要求数を調査することができる。
【００８３】
ここで、遅延配信データ送信要求数は、上述の先行送信データ長とページフォルトが発生するクライアントとの関係から、先行送信データ長が短くなるほど多くなる傾向にある。もし、遅延配信データ送信要求数がより多くなるように、先行送信データ長が設定されるならば、ネットワークリソースを効率的に使用することができる。但し、遅延配信データ送信要求数が多くなると、サーバ１０が処理しきれなくなるおそれもある。
【００８４】
そこでサーバ１０は、当該サーバ１０自身の処理能力で決まる、予め定められた単位時間内に処理可能な遅延配信データ送信要求数をＱとすると、先行送信データ長毎の遅延配信データ送信要求数（つまり遅延配信データの送信を要求するクライアントの数）に基づき、Ｑ以下に収まる最小の先行送信データ長を、新たに適用する送信データ長として選択する。最小の先行送信データ長を選択する理由は、サーバ１０が処理可能な範囲で、ネットワークリソースを最も効率的に使用するためである。
【００８５】
サーバ１０が単位時間内に処理可能な遅延配信データ送信要求数は、当該サーバ１０自身の処理能力以外に、以下の情報
・ネットワーク帯域、ネットワーク使用状況（輻輳発生の有無等）
・データ配信の遅延時間
・データ配信の頻度
によっても変わる。
このため、これらの情報とサーバ１０自身の処理能力のうちの少なくとも１つに基づいて、上記Ｑが決定されてもよい。
【００８６】
＜第２の実施形態＞
次に、本発明の第２の実施形態について説明する。
前記第１の実施形態では、クライアント２０-iのデバイスドライバ２３が、サーバ１０からの先行送信データと遅延配信データとを区別して受信し、先行受信データを受信バッファ内の先行送信データ用のページ６３に格納する処理（ステップ８０１〜８０４）、遅延配信データを受信バッファ内の遅延配信データ用のページ６４に格納する処理（ステップ１１０１〜１１０４）を実行している。
【００８７】
しかし近年は、ネットワークインタフェースがＤＭＡ（Direct Memory Access）により、デバイスドライバの介入なしに直接受信データを受信バッファに格納することが一般的である。このためデバイスドライバは、受信バッファにデータが既に格納されていることを前提として以後の処理を行うことが通常である。
【００８８】
しかも、通常、ネットワークインタフェースは、第１の実施形態で適用されるような先行送信データや遅延配信データを意識してＤＭＡする仕組みを持たない。このため、第１の実施形態で適用されるような処理手順を実現するには、受信バッファ内のページ（メモリページ）とは別に用意されるメモリ領域にネットワークインタフェースがＤＭＡにてデータを一旦格納した後、改めてデバイスドライバが、ステップ８０１〜８０４及びステップ１１０１〜１１０４のような処理を行う必要がある。この場合、メモリコピーが２度発生することとなり、性能上、非効率的である。
【００８９】
このような問題を回避するために、先行送信データ及び遅延配信データを区別して、受信バッファの適切なページにＤＭＡするような仕組みをネットワークインタフェースに実装することも可能である。しかし、開発コストが高くなる可能性がある。
【００９０】
一方、今日では、仮想ネットワークが普及し始めている。このため、通常のネットワークインタフェースに対してはコストその他の要因で導入が困難である様々な仕組みを、仮想ネットワークがソフトウェアエミュレートで実現されるメリットを生かし、仮想ネットワークインタフェースに導入することが可能となってきている。例えば仮想イーサネットは、ソフトウェアによりエミュレートされる仮想的なスイッチングノードである仮想ハブと、同じくソフトウェアによりエミュレートされる仮想ネットワークインタフェース（クライアント上で動作）により構成される。
【００９１】
第２の実施形態の特徴は、第１の実施形態においてクライアント２０-iのデバイスドライバ２３が担っていた役割を仮想ネットワークの仮想ネットワークインタフェースに持たせることにある。第２の実施形態によれば、仮想ネットワークインタフェースの上位層に特別な仕組みを導入する必要がなくなるという格別な効果を奏することができる。
【００９２】
（仮想ネットワークインタフェースの実装例）
仮想ネットワークインタフェースの実装方法は、例えば前記特許文献２の段落０１１０〜０１２８、図１３及び図１４に記載されている。
図１２及び図１３は、第２の実施形態で適用される一般的なＯＳ（オペレーティングシステム）による仮想ネットワークインタフェースの実装例を示す。図１２及び図１３は、それぞれ特許文献２の図１３及び図１４に相当する。
【００９３】
図１２に示す仮想ネットワークインタフェースの実装例は、一般的なＩＰトンネリングの仕組みを利用したものである。図１２において、仮想ネットワークインタフェース１２０８はＯＳのカーネル１２０２の内部に実装される。ユーザプロセス１２０１内には、制御アプリケーションプログラム（以下、制御アプリケーションと称する）１２０３、及びその他のアプリケーションプログラム（以下、アプリケーションと称する）１２０４が存在する。仮想ネットワークインタフェース１２０８は、上位層であるイーサネット層１２０７からは単なるネットワークインタフェースとして見えるが、一方、下位層であるＩＰ（アウターＩＰ）層１２０９からは、ＴＣＰ／ＵＤＰ層１２０５と同様のトランスポート層として見える。仮想ネットワークインタフェース１２０８よりも下位のＩＰ（アウターＩＰ）層１２０９、イーサネット層１２１０及びネットワークインタフェース１２１１は、アンダーレイネットワーク１２１２を構成する。
【００９４】
図１３に示す仮想ネットワークインタフェースの実装例は、トンネルインタフェースの仕組みを利用したものである。図１３（ａ）及び図１３（ｂ）において、仮想ネットワークインタフェース１３０３はユーザプロセス１３０１の一部として実装される。仮想ネットワークインタフェース１３０３とＯＳのカーネル１３０２内の通信プロトコルとのデータのやりとりは、トンネルインタフェース１３１１を介して行われる。
【００９５】
図１３（ａ）は、トンネルインタフェース１３１１がＩＰデータグラムを処理する（ユーザランドのプログラムとＩＰデータグラムをやりとりする）タイプである。一方、図１３（ｂ）は、トンネルインタフェース１３１１がイーサネットフレームを処理する（ユーザランドのプログラムとイーサネットフレームをやりとりする）タイプである。
【００９６】
図１３（ａ），（ｂ）に示されるように、ユーザプロセス１３０１には、仮想ネットワークインタフェース１３０３の他に、制御アプリケーション１３０４、ＨＴＴＰ（Hyper Text Transfer Protocol）１３０６及びアプリケーション１３０７が実装される。一方、カーネル１３０２には、ＴＣＰ／ＵＤＰ層１３０９、ＩＰ層１３１０、トンネルインタフェース１３１１、イーサネット層１３１２、及びネットワークインタフェース１３１３が実装される。仮想ネットワークインタフェース１３０３よりも下位のＨＴＴＰ１３０６、ＴＣＰ／ＵＤＰ層１３０９、ＩＰ層１３１０、イーサネット層１３１２、及びネットワークインタフェース１３１３は、アンダーレイネットワーク１３０８を構成する。
【００９７】
いずれの実装方法でも、仮想ネットワークインタフェース（仮想ネットワークインタフェース１２０８または１３０３）は、受信データを何らかの形で（通常は第１の実施形態と同様に受信バッファを介して）上位層、例えば、イーサネット層、或いはＩＰ層に渡す。このときに、仮想ネットワークインタフェースは、第１の実施形態においてクライアント２０-iのデバイスドライバ２３が実施している処理を行う。
【００９８】
図１４は、第２の実施形態で適用されるクライアント２００-iの構成を示すブロック図である。なお、図１４において、図２に示すクライアント２０-iと等価な部分には便宜的に同一参照符号を付してある。第２の実施形態では、第１の実施形態におけるクライアント２０-iに代えてクライアント２００-iが用いられる。必要ならば、図１において、クライアント２０-1〜２０-nを、クライアント２００-1〜２００-nに置き換えられたい。
【００９９】
図１４に示すクライアント２００-iでは、第１の実施形態におけるデバイスドライバ２３に代えて、図１２の仮想ネットワークインタフェース１２０８、または図１３の仮想ネットワークインタフェース１３０３に相当する仮想ネットワークインタフェース２３０が用いられる。またクライアント２００-iでは、第１の実施形態におけるネットワークインタフェース２２に代えて、図１２のアンダーレイネットワーク１２１２、または図１３のアンダーレイネットワーク１３０８に相当するアンダーレイネットワーク２２０が用いられる。
【０１００】
図１４のクライアント２００-iでは、当該クライアント２００-iに適用される仮想ネットワークインタフェース２３０の実装方法により、ネットワークプロトコルモジュール２４に含まれる機能が異なる（例えば、イーサネット層の有無等）。なお、アンダーレイネットワーク２２０とは、仮想ネットワークインタフェース２３０が使用するネットワークプロトコル群、物理的なネットワークインタフェースとそのデバイスドライバ全てを総称したものである。
【０１０１】
クライアント２００-iの処理手順は第１の実施形態におけるクライアント２０-iと同様である。必要ならば、第１の実施形態で適用される図８、図９及び図１１のフローチャートに従う処理手順についての説明において、クライアント２０-iをクライアント２００-iに、デバイスドライバ２３を仮想ネットワークインタフェース２３０に、そしてネットワークインタフェース２２をアンダーレイネットワーク２２０に、それぞれ読み替えられたい。
【０１０２】
上述の説明では、クライアント側に仮想ネットワークの仮想ネットワークインタフェースの仕組みを適用したが、更に、サーバ側にも仮想ネットワークの仮想ネットワークインタフェースの仕組みを適用することも可能である。
【０１０３】
図１５は、第２の実施形態で適用されるサーバ１００の構成を示すブロック図である。なお、図１５において、図３に示すサーバ１０と等価な部分には便宜的に同一参照符号を付してある。第２の実施形態では、第１の実施形態におけるサーバ１０に代えてサーバ１００が用いられる。必要ならば、図１において、サーバ１０を、サーバ１００に置き換えられたい。
【０１０４】
図１５に示すサーバ１００では、第１の実施形態におけるデバイスドライバ１３に代えて、図１２の仮想ネットワークインタフェース１２０８、または図１３の仮想ネットワークインタフェース１３０３に相当する仮想ネットワークインタフェース１３０が用いられる。またサーバ１００では、第１の実施形態におけるネットワークインタフェース１４に代えて、図１２のアンダーレイネットワーク１２１２、または図１３のアンダーレイネットワーク１３０８に相当するアンダーレイネットワーク１４０が用いられる。またサーバ１００では、仮想ネットワークインタフェース１３０に、データ送信制御モジュール１５が配置される。これにより第２の実施形態においては、仮想ネットワークインタフェース１３０を適用することによる上述の効果に加えて、仮想ネットワークインタフェース１３０の上位層に特別な仕組みを導入する必要がなくなるという効果をも奏することができる。
【０１０５】
サーバ１００の処理手順は第１の実施形態におけるサーバ１０と同様である。必要ならば、第１の実施形態で適用される図７及び図１０のフローチャートに従う処理手順についての説明において、サーバ１０をサーバ１００に、デバイスドライバ１３を仮想ネットワークインタフェース１３０に、そしてネットワークインタフェース１４をアンダーレイネットワーク１４０に、それぞれ読み替えられたい。
第１の実施形態において適用される先行送信データ長の決定手法は、第２の実施形態においても適用可能である。
【０１０６】
なお、本発明は、上記実施形態（第１または第２の実施形態）そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。
【符号の説明】
【０１０７】
１０，１００…サーバ（サーバコンピュータ）、１１…データ配信モジュール、１２…ネットワークプロトコルモジュール、１３…デバイスドライバ（第１の送受信手段）、１４…ネットワークインタフェース（第１の送受信手段）、１５…データ送信制御モジュール、１６…遅延配信データ保持部、１７…定義情報記憶部（第１の定義情報記憶手段）、２０-1〜２０-n，２０-i，２００-i…クライアント（クライアント端末）、２１…バッファ管理モジュール、２２…ネットワークインタフェース（第２の送受信手段）、２３…デバイスドライバ（第２の送受信手段、格納処理手段）、２４…ネットワークプロトコルモジュール、２５…ページフォルトハンドラ（遅延配信データ送信要求手段）、２６…データ処理モジュール、２７…遅延配信データ待ちバッファテーブル（バッファ制御情報保持手段）、２８…定義情報記憶部（第２の定義情報記憶手段）、６１，６２…ページ情報、６３…ページ（第１のメモリページ），６４…ページ（第２のメモリページ）、１３０…仮想ネットワークインタフェース、２３０…仮想ネットワークインタフェース（格納処理手段）、１４０…アンダーレイネットワーク（第１の送受信手段）、２２０…アンダーレイネットワーク（第２の送受信手段）。
【技術分野】
【０００１】
本発明は、ブロードキャスト、マルチキャストまたはユニキャストによりサーバコンピュータからクライアント端末にデータを配信するデータ配信ネットワークシステム及びデータ配信方法に関する。
【背景技術】
【０００２】
従来から、サーバコンピュータが不特定多数、或いは特定多数のクライアント端末に対して同一データを配信するようなデータ配信ネットワークシステムが知られている。このようなデータ配信ネットワークシステムにおいて、データの配信には、以下に述べるように、ブロードキャスト、マルチキャスト、或いはユニキャストが用いられる。
【０００３】
・ブロードキャスト、或いはマルチキャストを使用する場合
サーバコンピュータは、クライアント端末側がデータを所望しているか否かに関わらず、ヘッダ及びペイロードを含む送信用データ全体をブロードキャスト、或いはマルチキャストするのが一般的である。
【０００４】
・ユニキャストを使用する場合
サーバコンピュータは、データを所望するクライアント端末にのみヘッダ及びペイロードを含む送信用データ全体を配信する。
【０００５】
一方、例えば特許文献１には、コンピュータ上で動作するアプリケーションプログラムが特定の仮想アドレス（ＩＯ空間）を参照した場合にページフォルトを発生させ、ページフォルトハンドラの処理にて、データをネットワークに送信し、それに対する応答を受信すると、ページフォルトハンドラからアプリケーションプログラムに復帰する仮想分散制御システムが開示されている。
また、例えば特許文献２には、ネットワークを仮想ネットワークにより構築する技術が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−１２７０８３号公報
【特許文献１】特開２００８−０４２６６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述したように、従来のデータ配信ネットワークシステムに関する技術（以下、先行技術と称する）では、ブロードキャスト、或いは、マルチキャストを使用する場合、サーバコンピュータは、クライアント端末側がデータを所望しているか否かに関わらず、ヘッダ及びペイロードを含む送信用データ全体をブロードキャスト、或いはマルチキャストする。このため先行技術では、サーバコンピュータによって配信されるデータを受信するクライアント端末が存在しない状態で、当該データがネットワーク上を流れる可能性がある。また、大多数のクライアント端末が受信を所望しないようなデータがネットワーク上を流れる可能性もある。したがって先行技術には、サーバコンピュータによるデータのブロードキャスト、或いはマルチキャストにより、ネットワークリソースを浪費するといった問題がある。この問題は、ペイロードのサイズが大きい場合、特に顕著となる。なお、ネットワークリソースは、回線の帯域やネットワーク装置のリソースだけでなく、サーバコンピュータやクライアント端末のネットワークインタフェース、ＣＰＵ及びメモリリソースも含む。
【０００８】
これに対し、先行技術においてユニキャストを使用する場合、サーバコンピュータはデータを所望するクライアント端末にのみ送信用データ全体を送信する。このため先行技術であっても、ユニキャストを使用する場合には、上記ブロードキャスト、或いはマルチキャストを使用する場合のような問題は生じない。しかし先行技術では、少なくともサーバコンピュータ（或いはネットワークノード）は、データ受信を所望するクライアント端末を何らかの方法で特定する必要があり、データ配信ネットワークシステムを構築、管理することが高コストとなってしまう。
【０００９】
本発明は上記事情を考慮してなされたものでその目的は、ブロードキャスト、或いはマルチキャストによるデータ配信に関する問題、及びユニキャストによるデータ配信に関する問題という、相反する２つの問題を解決することができるデータ配信ネットワークシステム及びデータ配信方法を提供することにある。
【課題を解決するための手段】
【００１０】
本発明の１つの観点によれば、サーバコンピュータと複数のクライアント端末とがネットワークによって接続されたデータ配信ネットワークシステムが提供される。このデータ配信ネットワークシステムにおいて、前記サーバコンピュータは、前記ネットワークを介してデータを送受信する第１の送受信手段と、前記ネットワークを介して送信されるべき送信用データの一部を先行送信データとして切り出して、当該先行送信データを前記第１の送受信手段によりブロードキャスト、或いはマルチキャストするデータ送受信制御手段と、前記送信用データの前記先行送信データを除く部分を遅延配信データとして保持する遅延配信データ保持手段とを含む。一方、前記複数のクライアント端末の各々は、前記ネットワークを介してデータを送受信する第２の送受信手段と、前記サーバコンピュータからブロードキャスト、或いはマルチキャストされた前記先行送信データが前記第２の送受信手段によって受信され、かつ当該先行送信データに対応する前記遅延配信データを必要とする場合、前記第２の送受信手段により前記サーバコンピュータに対して前記遅延配信データの送信を要求する遅延配信データ送信要求手段とを含む。前記サーバコンピュータの前記データ送受信制御手段は、前記複数のクライアント端末のいずれかのクライアント端末から、前記遅延配信データの送信が要求された場合に、前記遅延配信データ保持手段に保持されている前記遅延配信データを前記第１の送受信手段により当該遅延配信データの送信を要求したクライアント端末宛てに送信する。
【発明の効果】
【００１１】
本発明によれば、サーバコンピュータから、送信用データの一部のみが先行送信データとしてブロードキャスト、或いはマルチキャストされると、この先行送信データを受信し、かつ当該先行送信データに対応する未受信の残りのデータである遅延配信データを必要とするクライアント端末だけから、サーバコンピュータに遅延配信データの送信が要求され、この遅延配信データの送信を要求したクライアント端末だけに、サーバコンピュータから遅延配信データ（つまり残りのデータ）が送信される。これにより、ブロードキャスト、或いはマルチキャストによるデータ配信に関する問題、及びユニキャストによるデータ配信に関する問題という、相反する２つの問題を解決して、ネットワークリソースの浪費を防止し、かつクライアント管理の低コスト化を図ることができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の第１の実施形態に係るデータ配信ネットワークシステムの全体構成を示すブロック図。
【図２】第１の実施形態におけるクライアントの構成を示すブロック図。
【図３】第１の実施形態におけるサーバの構成を示すブロック図。
【図４】第１の実施形態で適用される受信バッファのデータ構造例を示す図。
【図５】送信用データ、先行送信データ及び遅延配信データの関係を、一般的な表現形式と、具体的な表現形式とでそれぞれ示す図。
【図６】受信バッファの初期データ構造例を示す図。
【図７】サーバにおける先行送信データ送信処理の手順を示すフローチャート。
【図８】クライアントにおける先行送信データ受信処理の手順を示すフローチャート。
【図９】ページフォルトハンドラによる遅延配信データ送信要求処理の手順を示すフローチャート。
【図１０】サーバにおける遅延配信データ送信処理の手順を示すフローチャート。
【図１１】クライアントにおける遅延配信データ受信処理の手順を示すフローチャート。
【図１２】本発明の第２の実施形態で適用される一般的なＯＳによる仮想ネットワークインタフェースの実装例を示す図。
【図１３】第２の実施形態で適用される一般的なＯＳによる仮想ネットワークインタフェースの実装例を示す図。
【図１４】第２の実施形態におけるクライアントの構成を示すブロック図。
【図１５】第２の実施形態におけるサーバの構成を示すブロック図。
【発明を実施するための形態】
【００１３】
以下、本発明の実施の形態につき図面を参照して説明する。
＜第１の実施形態＞
［全体構成］
図１は本発明の第１の実施形態に係るデータ配信ネットワークシステムの全体構成を示すブロック図である。
【００１４】
図１のデータ配信ネットワークシステムにおいて、サーバコンピュータ（以下、サーバと称する）１０と、複数のクライアント端末、例えばｎ台（ｎは１より大きい整数）のクライアント端末（以下、クライアントと称する）２０-1，２０-2，…２０-nは、ネットワーク３０によって相互に接続されている。このネットワーク３０が、単一のブロードキャストドメインをなしても、或いはルータ等により構成された複数ブロードキャストドメインをなしても構わない。
【００１５】
サーバ１０は、クライアント２０-i（ｉ＝１，２，…ｎ）に対して単一のサービス（データ配信）または複数のサービスを提供する。なお、図１の例では、単一のサーバ１０がネットワーク３０に接続されているが、サーバ１０を含む複数のサーバがネットワーク３０に接続されていてもよい。また、この複数のサーバが単一のサービスを提供するものであっても構わない。また、あるクライアント２０-iが享受するサービスは単一とは限らず、単一のサーバ１０から複数のサービスを享受する構成であっても構わない。また、サーバ１０を含む複数のサーバがネットワーク３０に接続されている場合、クライアント２０-iが、当該複数のサーバから複数のサービスを享受する構成であっても構わない。
【００１６】
［クライアント２０-iの構成］
図２はクライアント２０-iの構成を示すブロック図である。クライアント２０-iは、バッファ管理モジュール２１、ネットワークインタフェース２２、デバイスドライバ２３、ネットワークプロトコルモジュール２４、ページフォルトハンドラ２５、及びデータ処理モジュール２６を有している。クライアント２０-iは更に、遅延配信データ待ちバッファテーブル２７及び定義情報記憶部２８を有する。
【００１７】
バッファ管理モジュール２１は、デバイスドライバ２３、ネットワークプロトコルモジュール２４及びデータ処理モジュール２６がデータ送受信に使用するバッファを管理する。バッファ管理モジュール２１はまた、遅延配信データ待ちバッファテーブル２７を管理する。
【００１８】
ネットワークインタフェース２２は、データ送受信を行う周知のデバイスである。ネットワークインタフェース２２は、デバイスドライバ２３によって制御される。
デバイスドライバ２３は、ネットワークインタフェース２２を制御する、例えばソフトウェアモジュールである。デバイスドライバ２３は、通常の送受信処理に加え、サーバ１０から受信した遅延配信データを、遅延配信データ待ちバッファテーブル２７に保持されている受信バッファのバッファ制御情報に基づき、該当するページに格納する処理等も行う。
【００１９】
ネットワークプロトコルモジュール２４は、各通信レイヤに依存したデータ送受信を行うネットワークプロトコル群を有する。このネットワークプロトコルモジュール２４が有するネットワークプロトコル群は、サーバ１０からブロードキャスト、或いはマルチキャストされる後述する先行送信データが、通常の送信データ（以下、送信用データと称する）の先頭からどこまでを含むかにより変わる。ネットワークプロトコルモジュール２４に含まれないネットワークプロトコルは、データ処理モジュール２６に含まれて、当該データ処理モジュール２６で処理される。
【００２０】
ページフォルトハンドラ２５は、ページフォルトが発生した場合に呼び出される機能モジュールである。ページフォルトハンドラ２５は、サーバ１０への遅延配信データの要求、及び遅延配信データ待ちバッファテーブル２７への情報登録等を行う。
【００２１】
データ処理モジュール２６は、サーバ１０によって配信されるデータを処理する処理主体をなす。データ処理モジュール２６は、このデータに係わる処理に加えて、上記ネットワークプロトコルに含まれない部分のネットワークプロトコルに係わる処理を行う。
【００２２】
遅延配信データ待ちバッファテーブル２７は、後述する遅延配信データの待ち状態にある受信バッファの一覧（更に詳細に述べるならば受信バッファのバッファ制御情報の一覧）を保持するのに用いられるバッファ制御情報保持手段である。定義情報記憶部２８については後述する。
【００２３】
［サーバ１０の構成］
図３はサーバ１０の構成を示すブロック図である。サーバ１０は、データ配信モジュール１１、ネットワークプロトコルモジュール１２、デバイスドライバ１３、ネットワークインタフェース１４及びデータ送信制御モジュール１５を有する。サーバ１０は更に、遅延配信データ保持部１６及び定義情報記憶部１７を有する。
【００２４】
データ配信モジュール１１は、サーバ１０におけるデータ配信の処理主体をなす。ネットワークプロトコルモジュール１２は、クライアント２０-i内のネットワークプロトコルモジュール２４と同様に、各通信レイヤに依存したデータ送受信を行うネットワークプロトコル群を有する。
【００２５】
デバイスドライバ１３は、ネットワークインタフェース１４を制御する、例えばソフトウェアモジュールである。ネットワークインタフェース１４は、クライアント２０-i内のネットワークインタフェース２２と同様に、データ送受信を行う周知のデバイスである。ネットワークインタフェース１４は、デバイスドライバ１３によって制御される。
【００２６】
データ送信制御モジュール１５は、先行技術であればブロードキャスト、或いはマルチキャストされる送信データ（以下、送信用データと称する）からの、本実施形態においてブロードキャスト、或いはマルチキャストすべきデータ（以下、先行送信データと称する）の切り出しと当該先行送信データの送信とを制御する。データ送信制御モジュール１５はまた、送信用データから切り出されなかった残りのデータである遅延配信データを遅延配信データ保持部１６に保持する。データ送信制御モジュール１５は更に、先行送信データのブロードキャスト、或いはマルチキャストに応じてクライアント２０-iから送られる未受信部分の送信要求に対する応答としての遅延配信データの送信を制御する。
【００２７】
遅延配信データ保持部１６は、データ送信制御モジュール１５によって送信用データから切り出されなかったデータを、クライアント２０-iからの未受信部分の送信要求に対して当該クライアント２０-iに送信されるべき遅延配信データとして保持するのに用いられる。定義情報記憶部１７については後述する。
【００２８】
本実施形態において、サーバ１０によりブロードキャスト、或いは、マルチキャストされる先行送信データに関する定義情報が、予めサーバ１０と各クライアント２０-iとの間で共有されているものとする。この定義情報は、送信用データのうち、ネットワークプロトコルヘッダ、或いは、ペイロードのどこまでが先行送信データに含まれるかを示すもので、先行送信データ長情報を含む。この先行送信データ長情報は、先行送信データのデータ長を示す。サーバ１０が有する定義情報記憶部１７及びクライアント２０-iが有する定義情報記憶部２８は、この定義情報を格納するのに用いられる。
【００２９】
更に、サーバ１０によるブロードキャスト、或いはマルチキャストで使用される宛先アドレスも、予め、サーバ１０と各クライアント２０-iとの間で共有されており、当該アドレスを宛先アドレスとして持つデータはクライアント２０-iのネットワークインタフェース２２により受信されるものとする。
【００３０】
［受信バッファのデータ構造］
図４は、受信バッファのデータ構造例を示す。受信バッファはデータ（実体）を格納するためのメモリページ（以下、単にページと称する）とバッファ制御情報とから構成される。このページは仮想アドレス空間内の仮想ページであり、データを格納するのに用いられる場合、このページに物理ページが割り当てられる。
【００３１】
バッファ制御情報は、対応する受信バッファを識別するための識別子（以下、配信データ識別子と称する）を含む。この配信データ識別子には、対応する遅延配信データを含む送信用データに固有のシーケンス番号、或いはサーバ１０にて遅延配信データから算出されるハッシュ値等を用いることができる。
【００３２】
バッファ制御情報はまた、対応する先行送信データ及び遅延配信データを合わせたデータ長を示す全データ長情報を含む。バッファ制御情報は更に、先行送信データの一部または全部を保持するのに用いられる受信バッファ内のページと、遅延配信データの一部または全部を保持するのに用いられる受信バッファ内のページの各々について、そのページを管理するためのページ情報を含む。ページ情報は、オフセット情報とデータ長情報と仮想アドレスとを含む。オフセット情報は、対応するページに格納されるデータ部分の始端の、送信用データにおける位置、つまりオフセット位置を示す。データ長情報は、上記データ部分のデータ長を示す。仮想アドレスは、対応するページの仮想アドレス空間におけるアドレス（ページアドレス）を示す。
【００３３】
なお、以降の説明では、説明の簡略化のために、先行送信データ及び遅延配信データを格納するのに用いられるページは１ページのみであるとする。
【００３４】
［送信用データ、先行送信データ及び遅延配信データの関係］
図５は送信用データ、先行送信データ及び遅延配信データの関係を、一般的な表現形式と、具体的な表現形式とでそれぞれ示す。
【００３５】
図５（ａ）は一般的な表現形式の例を示しており、送信用データは、Ｎ個のネットワークプロトコルヘッダ＃１〜＃Ｎと、ペイロードとから構成されている。図５（ａ）の例では、先行送信データは、先頭のネットワークプロトコルヘッダ＃１と、後続のネットワークプロトコルヘッダ＃２の一部とから構成されている。しかし、先行送信データが、複数のネットワークプロトコルヘッダと、当該複数のネットワークプロトコルヘッダに後続するネットワークプロトコルヘッダ（つまり複数のネットワークプロトコルよりも上位の階層のネットワークプロトコルのヘッダ）の一部とから構成されていてもよい。また、先行送信データが、全てのネットワークプロトコルヘッダから構成されていても、或いは全てのネットワークプロトコルヘッダと、ペイロードの一部とから構成されていてもよい。
【００３６】
ネットワークプロトコルヘッダは、標準化されたネットワークプロトコルのヘッダであり、システムによっては、プロトコル階層の中で複数回現れることもある。標準化されたネットワークプロトコルのヘッダとしては、例えば、イーサネット（登録商標）、ＰＰＰ（Point to Point Protocol）等のリンク層プロトコルのヘッダ、ＩＰ（Internet Protocol）、ＡＲＰ（Address Resolution Protocol）等のネットワーク層プロトコルのヘッダ、ＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）、ＳＣＴＰ（Stream Control Transmission Protocol）、ＲＴＰ（Real-time Transport Protocol）、ＲＴＣＰ（RTP Control Protocol）等のトランスポート層以上のプロトコルのヘッダが知られている。
【００３７】
ペイロードとは、ある層のプロトコルから見た場合の上位層のデータのことであり、プロトコル層が変わればペイロードが意味する部分も異なる。ペイロードは、ある層のプロトコルから見た場合の上位層のプロトコルのヘッダ、アプリケーションのヘッダ（制御情報）、アプリケーションのデータ等である。
【００３８】
図５（ｂ）は具体的な表現形式の例を示しており、送信用データは、３つのネットワークプロトコルヘッダである、イーサネットヘッダ、ＩＰヘッダ及びＵＤＰヘッダと、ペイロードをなすアプリケーション制御情報及びアプリケーションデータとから構成されている。図５（ｂ）の例では、先行送信データは、全てのネットワークプロトコルヘッダと、後続のアプリケーション制御情報の一部とから構成されている。
【００３９】
本実施形態において、先行送信データに属する先頭のネットワークプロトコルヘッダは、送信用データの全データ長を示す全データ長情報を含むものとする。なお、送信用データ中の先頭のネットワークプロトコルヘッダの始端側の一部だけを、先行送信データとしても構わない。但し、先行送信データを構成する先頭のネットワークプロトコルヘッダの一部に、先行送信データがサーバからクライアントへ到達するために必要な情報が含まれている必要がある。
【００４０】
［動作］
次に、図１に示されるデータ配信ネットワークシステムにおける動作について説明する。
まずクライアント２０-iのバッファ管理モジュール２１は、定義情報記憶部２８に記憶されている定義情報に基づき、受信バッファを用意する。この受信バッファは初期化されたバッファ制御情報を含む。
【００４１】
図６は、このときの受信バッファのデータ構造例を示す。図６に示すように、バッファ制御情報（初期バッファ制御情報）は、有効な配信データ識別子及び全データ長情報を含んでいない点に注意されるべきである。また、このバッファ制御情報は、図６の例では、２つのページ情報６１及び６２を含む。
【００４２】
ページ情報６１は、有効なオフセット情報、有効なデータ長情報及び有効な仮想アドレスを含む。ページ情報６１中のオフセット情報、データ長情報は、それぞれ、オフセット０、先行送信データ長を示す。また、ページ情報６１中の仮想アドレスは、先行送信データを格納するための受信バッファ内のページ６３を指し示す。本実施形態において、このページ６３には、当該ページ６３を含む受信バッファが用意される際に、物理ページが割り当てられる。つまり受信バッファが用意される際、ページ（第１のメモリページ）６３を指定するページ情報６１中の仮想アドレス（第１の仮想アドレス）には、物理ページが割り当てられる。
【００４３】
これに対し、ページ情報６２は、有効なオフセット情報及び有効な仮想アドレスを含む一方、有効なデータ長情報を含んでいない。ページ情報６２中のオフセット情報は先行送信データ長を示す。また、ページ情報６２中の仮想アドレスは、遅延配信データを格納するための受信バッファ内のページ６４を指し示す。本実施形態において受信バッファが用意される際、このページ情報６２中の仮想アドレスによって指定されるページ６４には、物理ページが割り当てられていない点に注意すべきである。つまり本実施形態では、受信バッファが用意される際、ページ（第２のメモリページ）６４を指定するページ情報６２中の仮想アドレス（第２の仮想アドレス）には、物理ページが割り当てられていない。ページ情報６２に有効なデータ長情報が設定され、ページ６４に物理ページが割り当てられるのは、クライアント２０-iがサーバ１０から遅延配信データを受信した場合である。
【００４４】
さて、クライアント２０-iのバッファ管理モジュール２１によって図６に示されるような構造の受信バッファが用意されている状態で、サーバ１０のデータ配信モジュール１１が、不特定多数、或いは、特定多数のクライアント２０-iに配信するデータを準備したものとする。これ以降のデータ配信ネットワークシステムにおける動作について、先行送信データ送信処理、先行送信データ受信処理、遅延配信データ送信要求処理、遅延配信データ送信処理及び遅延配信データ受信処理を例に順に説明する。
【００４５】
・先行送信データ送信処理
まず、サーバ１０における先行送信データ送信処理について、図７のフローチャートを参照して説明する。
サーバ１０のデータ配信モジュール１１は、準備したデータの送信をネットワークプロトコルモジュール１２に依頼する。
【００４６】
ネットワークプロトコルモジュール１２は、データ配信モジュール１１からのデータ送信の依頼を受け取ると、個々のプロトコル依存の処理を行うことにより、例えば図５に示されるような複数のネットワークプロトコルヘッダが付加された送信用データを生成する（ステップ７０１）。ネットワークプロトコルモジュール１２は、生成した送信用データをデータ送信制御モジュール１５に渡す。
【００４７】
データ送信制御モジュール１５は、ネットワークプロトコルモジュール１２から送信用データを受け取ると、当該データの一部を先行送信データとして切り出す（ステップ７０２）。ここではデータ送信制御モジュール１５は、送信用データの始端から、定義情報記憶部１７に格納されている定義情報で示されるデータ長だけ、先行送信データとして切り出す。データ送信制御モジュール１５は、送信用データから切り出した先行送信データのみの送信をデバイスドライバ１３に依頼する。
【００４８】
次にデータ送信制御モジュール１５は、送信用データから切り出されなかった残りのデータ、つまり送信用データのうちの先行送信データの終端以降のデータを、遅延配信データとして遅延配信データ保持部１６に保持する（ステップ７０３）。データ送信制御モジュール１５は、この遅延配信データ保持部１６における遅延配信データの保持期間を管理する。
【００４９】
本実施形態では、遅延配信データ保持部１６に保持されてから一定期間が経過した遅延配信データは、データ送信制御モジュール１５によって廃棄される。なお、遅延配信データ保持部１６に保持されている遅延配信データに対する送信要求を、データ送信制御モジュール１５が一定数受信するまで、当該遅延配信データが遅延配信データ保持部１６に保持される構成であっても構わない。また、廃棄されるべき遅延配信データがＬＲＵ（Least Recently Used）アルゴリズムにより決定される構成であっても構わない。また、遅延配信データ保持部１６における遅延配信データの保持期間が、データ送信制御モジュール１５とは別の専用の管理モジュール（遅延配信データ保持管理モジュール）によって管理されても構わない。
【００５０】
本実施形態において、先行送信データの送信時と、遅延配信データの遅延配信データ保持部１６への保持時には、当該データに配信データ識別子が付加される。この配信データ識別子には、前述したように、送信用データを構成する先行送信データ及び遅延配信データに固有のシーケンス番号、或いは遅延配信データのハッシュ値等、先行送信データと遅延配信データとの対応を取るための情報が用いられる。
【００５１】
デバイスドライバ１３は、データ送信制御モジュール１５から依頼された、配信データ識別子が付加された先行送信データを、前述の予め決められたブロードキャストアドレス、或いはマルチキャストアドレスを宛先アドレスとして、ネットワークインタフェース１４により送信する（ステップ７０４）。つまり先行送信データは、第１のデータ送受信手段として機能する、デバイスドライバ１３及びネットワークインタフェース１４によって、ブロードキャスト、或いはマルチキャストされる。
【００５２】
・先行送信データ受信処理
次に、クライアント２０-iにおける先行送信データ受信処理について、図８のフローチャートを参照して説明する。
上述のように、予め決められたブロードキャストアドレス、或いは、マルチキャストアドレスを宛先アドレスとして、サーバ１０から先行送信データが送信されると、当該宛先アドレスを持つデータを受信するように設定されたクライアント２０-iのデバイスドライバ２３は、ネットワークインタフェース２２により当該先行送信データを受信する（ステップ８０１）。つまりサーバ１０からブロードキャスト、或いはマルチキャストされた先行送信データが、第２のデータ送受信手段として機能する、ネットワークインタフェース２２及びデバイスドライバ２３によって受信される。
【００５３】
デバイスドライバ２３は先行送信データを受信すると格納処理手段として機能して、バッファ管理モジュール２１によって用意されている受信バッファのバッファ制御情報を参照する（ステップ８０２）。そしてデバイスドライバ２３は、バッファ制御情報中のページ情報６１に基づき、受信バッファ内の先行送信データ用のページ６３、つまり物理ページが割り当てられているページ６３を特定する（ステップ８０３）。
【００５４】
デバイスドライバ２３は、特定したページ６３に、受信した先行送信データを格納する（ステップ８０４）。またデバイスドライバ２３は、受信した先行送信データに付加されている配信データ識別子を、受信バッファのバッファ制御情報中に追加設定する（ステップ８０５）。
【００５５】
またデバイスドライバ２３は、受信した先行送信データに含まれている全データ長情報を受信バッファのバッファ制御情報中に追加設定する（ステップ８０６）。デバイスドライバ２３は更に、この全データ長情報の示す送信用データの全データ長と、先行送信データのデータ長とから、未受信の遅延配信データのデータ長を算出する（ステップ８０７）。次にデバイスドライバ２３は、遅延配信データがあたかも遅延配信データ用のページ６４に格納されているかのように、上記算出した遅延配信データのデータ長を示すデータ長情報と、オフセット情報（先行送信データのデータ長と等価）とを、受信バッファのバッファ制御情報のページ情報６２中に追加設定する（ステップ８０８）。このページ情報６２は、前述したように遅延配信データ用のページ６４を管理するための情報である。デバイスドライバ２３はステップ８０８を実行すると、ステップ８０４〜８０６，８０８の処理が行われた受信バッファ（更に詳細に述べるならば受信バッファのバッファ制御情報）をネットワークプロトコルモジュール２４に渡す。
【００５６】
ネットワークプロトコルモジュール２４は、デバイスドライバ２３から受信バッファのバッファ制御情報を受け取ると、次のような処理を実行する。即ちネットワークプロトコルモジュール２４は、バッファ制御情報のページ情報６１によって示される受信バッファ内のページ６３に格納されている受信データ（つまり先行送信データ）に対して個々のプロトコル依存の処理を行い、処理されたデータを、受信バッファのバッファ制御情報と共にデータ処理モジュール２６に渡す（ステップ８０９）。なお、ここでは、ネットワークプロトコルの処理に必要なデータは全て先行送信データに含まれているものとする。もし、そのようなデータが含まれていない場合、そのデータ部分に関するネットワークプロトコルの処理をデータ処理モジュール２６が受け持てばよい。つまり、先行送信データの内容（長さ）により、ネットワークプロトコルモジュール２４とデータ処理モジュール２６の役割分担（境界）は可変となることを意味する。
【００５７】
データ処理モジュール２６は、ネットワークプロトコルモジュール２４からプロトコル処理済みの先行送信データ及びバッファ制御情報を受け取ると、当該データが所望のデータ（更に詳細には所望のデータの一部）であるかを判定する（ステップ８１０）。もし、所望のデータであるならば、データ処理モジュール２６は所望の処理を行うために、バッファ制御情報中のページ情報６２に基づいて、受信バッファ内の遅延配信データ用のページ６４にアクセスする（ステップ８１１）。このとき、遅延配信データ用のページ６４には物理ページが割り当てられていない。つまりデータ処理モジュール２６は、ページ情報６２中の物理アドレスが未割り当ての仮想アドレスの指し示すページ６４にアクセスする。このため、遅延配信データ用のページ６４へのアクセスに応じてページフォルトが発生し、ページフォルトハンドラ２５が呼び出される。
【００５８】
・遅延配信データ送信要求処理
次に、ページフォルトハンドラ２５による遅延配信データ送信要求処理について、図９のフローチャートを参照して説明する。
ページフォルトハンドラ２５はページフォルトの発生に応じて呼び出されると、当該ページフォルト発生の原因となった受信バッファ内の遅延配信データ用のページ６４に対して物理ページを割り当てる（ステップ９０１）。つまりページフォルトハンドラ２５は、物理ページ未割り当ての遅延配信データ用のページ６４を指定する仮想アドレスに、物理ページを割り当てる。このことは、ページフォルトハンドラ２５が、受信バッファ内に遅延配信データ用の物理ページを追加したことと等価である。
【００５９】
次にページフォルトハンドラ２５は、物理ページが割り当てられたページ６４を含む遅延配信データの待ち状態にある受信バッファ（更に詳細には受信バッファのバッファ制御情報）を、遅延配信データ待ちバッファテーブル２７に追加する（ステップ９０２）。
【００６０】
次にページフォルトハンドラ２５は遅延配信データ送信要求手段として機能して、遅延配信データ待ちバッファテーブル２７に追加された受信バッファのバッファ制御情報によって示される当該受信バッファ内のページ６３に格納されている先行送信データに対応する遅延配信データ、即ち送信用データ中の先行送信データを除く未受信のデータ部分の送信をサーバ１０に対して要求する（ステップ９０３）。本実施形態では、このページフォルトハンドラ２５からの遅延配信データの送信要求が、ネットワークプロトコルモジュール２４及びデバイスドライバ２３を用いて、ネットワークインタフェース２２から送出されるものとする。この送信要求には、遅延配信データ待ちバッファテーブル２７に追加された受信バッファのバッファ制御情報中の配信データ識別子が付加される。ページフォルトハンドラ２５は、サーバ１０に対して遅延配信データを要求すると、データ処理モジュール２６を停止状態にして（ステップ９０４）、処理を終了する。
【００６１】
・遅延配信データ送信処理
次に、サーバ１０における遅延配信データ送信処理について、図１０のフローチャートを参照して説明する。
クライアント２０-iからサーバ１０宛てに遅延配信データの送信要求が送信されると、、サーバ１０のデータ送信制御モジュール１５は、ネットワークインタフェース１４及びデバイスドライバ１３を介して、当該遅延配信データの送信要求を受信する（ステップ１００１）。するとデータ送信制御モジュール１５は、受信した遅延配信データの送信要求に付加されている配信データ識別子に基づき、要求された遅延配信データが遅延配信データ保持部１６に存在するかを判定する（ステップ１００２）。即ちデータ送信制御モジュール１５は、クライアント２０-iからの送信要求に付加されているのと同一の配信データ識別子が付加されている遅延配信データが遅延配信データ保持部１６に存在するかを判定する。もし、要求された遅延配信データが存在するならば、データ送信制御モジュール１５は、当該遅延配信データを、クライアント２０-iからの送信要求に対する応答として、配信データ識別子が付加されている状態で、デバイスドライバ１３及びネットワークインタフェース１４を介して当該クライアント２０-i宛てに送信する（ステップ１００３）。ここでデータ送信制御モジュール１５によってクライアント２０-iに送信される遅延配信データの始端側には、当該遅延配信データがクライアント２０-iで受信可能なように、当該クライアント２０-iを宛先とし、サーバ１０を送信元として指定するネットワークプロトコルヘッダが付加される。
【００６２】
・遅延配信データ受信処理
次にクライアント２０-iにおける遅延配信データ受信処理について、図１１のフローチャートを参照して説明する。
クライアント２０-iのデバイスドライバ２３は、サーバ１０からクライアント２０-i宛てに遅延配信データが送信されると、当該遅延配信データをネットワークインタフェース２２を介して受信する（ステップ１１０１）。するとデバイスドライバ２３は、受信した遅延配信データに付加されているのと同一の配信データ識別子を含むバッファ制御情報が遅延配信データ待ちバッファテーブル２７に保持されているかを判定する（ステップ１１０２）。
【００６３】
もし、該当するバッファ制御情報が保持されているならば、デバイスドライバ２３は、当該バッファ制御情報中のページ情報６２に基づき、対応する受信バッファ内の遅延配信データ用のページ６４を特定する（ステップ１１０３）。そしてデバイスドライバ２３は、受信した遅延配信データを、ステップ１１０３で特定したページ６４に格納し（ステップ１１０４）、停止状態に設定されているデータ処理モジュール２６を動作状態にする（ステップ１１０５）。データ処理モジュール２６は動作状態になると、ページフォルトが発生した時点から処理を再開する。
【００６４】
デバイスドライバ２３は、データ処理モジュール２６を動作状態に設定すると、受信した遅延配信データに付加されているのと同一の配信データ識別子を含むバッファ制御情報を遅延配信データ待ちバッファテーブル２７から削除する（ステップ１１０６）。このことは、遅延配信データ待ちバッファテーブル２７によって遅延配信データの待ち状態にあるとして管理されていた受信バッファを、当該遅延配信データの待ち状態から解放したことと等価である。
【００６５】
このように、本実施形態においてサーバ１０は、送信用データの一部のみを先行送信データとして切り出して、当該先行送信データをブロードキャスト、或いはマルチキャストする。先行送信データは、送信用データ中の全ネットワークプロトコルのヘッダ、或いは、一部のネットワークプロトコルのヘッダと後続のネットワークプロトコルのヘッダの一部、或いは全ネットワークプロトコルのヘッダと後続のペイロードの一部、或いは先頭のネットワークプロトコルのヘッダの一部である。
【００６６】
サーバ１０からの先行送信データを受信したクライアント２０-iは、当該受信したデータが所望のデータであるかを判定し、所望のデータである場合にのみ、サーバ１０に対して残りのデータ（つまり未受信のデータ）である遅延配信データの送信を要求する。
【００６７】
サーバ１０は、クライアント２０-iからの送信要求を受信することにより、当該クライアント２０-iが、送信用データのうち、先行送信データとして切り出されなかった残りのデータを要求していることを検出する。そこでサーバ１０は、送信用データのうちの残りのデータを要求しているクライアント２０-iに対してのみ、当該残りのデータを遅延配信データとして送信する。
【００６８】
これにより本実施形態においては、ブロードキャスト、或いはマルチキャストによるデータ配信に関する問題、及びユニキャストによるデータ配信に関する問題という、相反する２つの問題を解決し、ネットワークリソースの浪費を防止し、かつクライアント管理の低コスト化を図ることができる。
【００６９】
［先行送信データ長の決定］
次に、定義情報記憶部２８に格納されている定義情報によって定義される先行送信データ長について説明する。
【００７０】
前述したように、第１の実施形態では、先行送信データに関する定義情報は、予めサーバ１０と各クライアント２０-iとの間で共有されている。つまり第１の実施形態では、定義情報によって定義される先行送信データ長は、サーバ１０と各クライアント２０-iに、静的に設定される。この先行送信データ長を決定し、運用する方法として、例えば次のような「コンフィグレーション」または「アナウンス」による方法が適用可能である。
【００７１】
・コンフィグレーション
コンフィグレーションによる方法では、先行送信データ長が、サーバ１０のデータ配信モジュール１１及びクライアント２０-iのデータ処理モジュール２６の仕様、つまり、データ配信ネットワークシステム及びアプリケーションの仕様に従って予め決定される。この決定に従い、対応する先行送信データ長を含む定義情報が、サーバ１０の定義情報記憶部１７及び各クライアント２０-iの定義情報記憶部２８に、予め静的に設定される。
【００７２】
・アナウンス
サーバ１０のデータ配信モジュール１１が、データ配信のサービス開始時、或いは定期的に、予め定められた手段、例えば、データ配信に使用するものと同じアドレスを使用して、先行送信データ長を含む定義情報をブロードキャスト、或いはマルチキャストする。各クライアント２０-iは、サーバ１０から定義情報がブロードキャスト、或いはマルチキャストされると、その定義情報を受信して、その受信した定義情報を定義情報記憶部２８に格納する。クライアント２０-iは、前述したように、定義情報記憶部２８に格納されている定義情報に従い、処理を行う。この方法も、先行送信データ長が静的に設定される。
【００７３】
・先行データ長の動的設定
しかし、以下に述べるように、サーバ１０が動的に先行送信データ長を決定して、運用する方法を適用することも可能である。
【００７４】
まず、サーバ１０によって提供されるサービスを享受する各クライアント２０-iは、先行送信データ長としてＫ、Ｌ、Ｍのいずれかを使用するものとする。Ｋ、Ｌ、Ｍは、０＜Ｋ＜Ｌ＜Ｍであるものとする。ここで、先行送信データと遅延配信データとを合わせたデータ、つまり送信用データの全体長がＮであるとすると、Ｎ、Ｋ、Ｌ、Ｍは、０＜Ｋ＜Ｌ＜Ｍ＜Ｎのような関係を有する。
【００７５】
サーバ１０の例えばデータ送信制御モジュール１５は、各クライアント２０-iに送信される先行送信データのデータ長である先行送信データ長を、例えばＮ、Ｍ、Ｌ、Ｋと変化させる。なお、Ｍ、Ｌ、Ｋ以外の長さでもよい。
サーバ１０が、先行送信データ長を変化させると、各クライアント２０-iが先行送信データ長として認識する長さの違いにより、以下のクライアントにてページフォルトが発生する。結果的にサーバ１０は、ページフォルトが発生したクライアントから遅延配信データの送信要求を受け取ることになる。
【００７６】
・先行送信データ長がＮの場合
ページフォルトが発生するクライアントはない。
【００７７】
・先行送信データ長がＭの場合
先行送信データ長をＭと認識しており、かつ、遅延配信データを所望するクライアントと、
先行送信データ長をＬと認識しており、かつ、遅延配信データを所望するクライアントと、
先行送信データ長をＫと認識しており、かつ、遅延配信データを所望するクライアントと
でページフォルトが発生。
【００７８】
・先行送信データ長がＬの場合
先行送信データ長をＭと認識している全てのクライアントと、
先行送信データ長をＬと認識しており、かつ、遅延配信データを所望するクライアントと、
先行送信データ長をＫと認識しており、かつ、遅延配信データを所望するクライアントと
でページフォルトが発生。
【００７９】
・先行送信データ長がＫの場合
先行送信データ長をＭと認識している全てのクライアントと、
先行送信データ長をＬと認識している全てのクライアントと、
先行送信データ長をＫと認識しており、かつ、遅延配信データを所望するクライアントと
でページフォルトが発生。
【００８０】
・先行送信データ長“ｌｅｎ”が０＜ｌｅｎ＜Ｋの場合
先行送信データ長をＭと認識している全てのクライアントと、
先行送信データ長をＬと認識している全てのクライアントと、
先行送信データ長をＫと認識している全てのクライアントと
でページフォルトが発生。
【００８１】
このように、図１に示されるデータ配信ネットワークシステムにおいて、ページフォルトが発生するクライアント２０-iの数、すなわち、サーバ１０がクライアントから受け取る遅延配信データの送信要求の数（遅延配信データ送信要求数）は、先行送信データ長としてＭ、Ｌ、Ｋを使用しているクライアント２０-iの割合、及び、更にその中で遅延配信データを所望するクライアント２０-iの割合に依存する。
【００８２】
そこでサーバ１０の例えばデータ送信制御モジュール１５は、上述のクライアント２０-iの割合を前もって認識できない場合、先行送信データ長を逐次変化させることにより、先行送信データ長毎に、当該サーバ１０が実際に受け取ることが期待される遅延配信データ送信要求数を調査することができる。
【００８３】
ここで、遅延配信データ送信要求数は、上述の先行送信データ長とページフォルトが発生するクライアントとの関係から、先行送信データ長が短くなるほど多くなる傾向にある。もし、遅延配信データ送信要求数がより多くなるように、先行送信データ長が設定されるならば、ネットワークリソースを効率的に使用することができる。但し、遅延配信データ送信要求数が多くなると、サーバ１０が処理しきれなくなるおそれもある。
【００８４】
そこでサーバ１０は、当該サーバ１０自身の処理能力で決まる、予め定められた単位時間内に処理可能な遅延配信データ送信要求数をＱとすると、先行送信データ長毎の遅延配信データ送信要求数（つまり遅延配信データの送信を要求するクライアントの数）に基づき、Ｑ以下に収まる最小の先行送信データ長を、新たに適用する送信データ長として選択する。最小の先行送信データ長を選択する理由は、サーバ１０が処理可能な範囲で、ネットワークリソースを最も効率的に使用するためである。
【００８５】
サーバ１０が単位時間内に処理可能な遅延配信データ送信要求数は、当該サーバ１０自身の処理能力以外に、以下の情報
・ネットワーク帯域、ネットワーク使用状況（輻輳発生の有無等）
・データ配信の遅延時間
・データ配信の頻度
によっても変わる。
このため、これらの情報とサーバ１０自身の処理能力のうちの少なくとも１つに基づいて、上記Ｑが決定されてもよい。
【００８６】
＜第２の実施形態＞
次に、本発明の第２の実施形態について説明する。
前記第１の実施形態では、クライアント２０-iのデバイスドライバ２３が、サーバ１０からの先行送信データと遅延配信データとを区別して受信し、先行受信データを受信バッファ内の先行送信データ用のページ６３に格納する処理（ステップ８０１〜８０４）、遅延配信データを受信バッファ内の遅延配信データ用のページ６４に格納する処理（ステップ１１０１〜１１０４）を実行している。
【００８７】
しかし近年は、ネットワークインタフェースがＤＭＡ（Direct Memory Access）により、デバイスドライバの介入なしに直接受信データを受信バッファに格納することが一般的である。このためデバイスドライバは、受信バッファにデータが既に格納されていることを前提として以後の処理を行うことが通常である。
【００８８】
しかも、通常、ネットワークインタフェースは、第１の実施形態で適用されるような先行送信データや遅延配信データを意識してＤＭＡする仕組みを持たない。このため、第１の実施形態で適用されるような処理手順を実現するには、受信バッファ内のページ（メモリページ）とは別に用意されるメモリ領域にネットワークインタフェースがＤＭＡにてデータを一旦格納した後、改めてデバイスドライバが、ステップ８０１〜８０４及びステップ１１０１〜１１０４のような処理を行う必要がある。この場合、メモリコピーが２度発生することとなり、性能上、非効率的である。
【００８９】
このような問題を回避するために、先行送信データ及び遅延配信データを区別して、受信バッファの適切なページにＤＭＡするような仕組みをネットワークインタフェースに実装することも可能である。しかし、開発コストが高くなる可能性がある。
【００９０】
一方、今日では、仮想ネットワークが普及し始めている。このため、通常のネットワークインタフェースに対してはコストその他の要因で導入が困難である様々な仕組みを、仮想ネットワークがソフトウェアエミュレートで実現されるメリットを生かし、仮想ネットワークインタフェースに導入することが可能となってきている。例えば仮想イーサネットは、ソフトウェアによりエミュレートされる仮想的なスイッチングノードである仮想ハブと、同じくソフトウェアによりエミュレートされる仮想ネットワークインタフェース（クライアント上で動作）により構成される。
【００９１】
第２の実施形態の特徴は、第１の実施形態においてクライアント２０-iのデバイスドライバ２３が担っていた役割を仮想ネットワークの仮想ネットワークインタフェースに持たせることにある。第２の実施形態によれば、仮想ネットワークインタフェースの上位層に特別な仕組みを導入する必要がなくなるという格別な効果を奏することができる。
【００９２】
（仮想ネットワークインタフェースの実装例）
仮想ネットワークインタフェースの実装方法は、例えば前記特許文献２の段落０１１０〜０１２８、図１３及び図１４に記載されている。
図１２及び図１３は、第２の実施形態で適用される一般的なＯＳ（オペレーティングシステム）による仮想ネットワークインタフェースの実装例を示す。図１２及び図１３は、それぞれ特許文献２の図１３及び図１４に相当する。
【００９３】
図１２に示す仮想ネットワークインタフェースの実装例は、一般的なＩＰトンネリングの仕組みを利用したものである。図１２において、仮想ネットワークインタフェース１２０８はＯＳのカーネル１２０２の内部に実装される。ユーザプロセス１２０１内には、制御アプリケーションプログラム（以下、制御アプリケーションと称する）１２０３、及びその他のアプリケーションプログラム（以下、アプリケーションと称する）１２０４が存在する。仮想ネットワークインタフェース１２０８は、上位層であるイーサネット層１２０７からは単なるネットワークインタフェースとして見えるが、一方、下位層であるＩＰ（アウターＩＰ）層１２０９からは、ＴＣＰ／ＵＤＰ層１２０５と同様のトランスポート層として見える。仮想ネットワークインタフェース１２０８よりも下位のＩＰ（アウターＩＰ）層１２０９、イーサネット層１２１０及びネットワークインタフェース１２１１は、アンダーレイネットワーク１２１２を構成する。
【００９４】
図１３に示す仮想ネットワークインタフェースの実装例は、トンネルインタフェースの仕組みを利用したものである。図１３（ａ）及び図１３（ｂ）において、仮想ネットワークインタフェース１３０３はユーザプロセス１３０１の一部として実装される。仮想ネットワークインタフェース１３０３とＯＳのカーネル１３０２内の通信プロトコルとのデータのやりとりは、トンネルインタフェース１３１１を介して行われる。
【００９５】
図１３（ａ）は、トンネルインタフェース１３１１がＩＰデータグラムを処理する（ユーザランドのプログラムとＩＰデータグラムをやりとりする）タイプである。一方、図１３（ｂ）は、トンネルインタフェース１３１１がイーサネットフレームを処理する（ユーザランドのプログラムとイーサネットフレームをやりとりする）タイプである。
【００９６】
図１３（ａ），（ｂ）に示されるように、ユーザプロセス１３０１には、仮想ネットワークインタフェース１３０３の他に、制御アプリケーション１３０４、ＨＴＴＰ（Hyper Text Transfer Protocol）１３０６及びアプリケーション１３０７が実装される。一方、カーネル１３０２には、ＴＣＰ／ＵＤＰ層１３０９、ＩＰ層１３１０、トンネルインタフェース１３１１、イーサネット層１３１２、及びネットワークインタフェース１３１３が実装される。仮想ネットワークインタフェース１３０３よりも下位のＨＴＴＰ１３０６、ＴＣＰ／ＵＤＰ層１３０９、ＩＰ層１３１０、イーサネット層１３１２、及びネットワークインタフェース１３１３は、アンダーレイネットワーク１３０８を構成する。
【００９７】
いずれの実装方法でも、仮想ネットワークインタフェース（仮想ネットワークインタフェース１２０８または１３０３）は、受信データを何らかの形で（通常は第１の実施形態と同様に受信バッファを介して）上位層、例えば、イーサネット層、或いはＩＰ層に渡す。このときに、仮想ネットワークインタフェースは、第１の実施形態においてクライアント２０-iのデバイスドライバ２３が実施している処理を行う。
【００９８】
図１４は、第２の実施形態で適用されるクライアント２００-iの構成を示すブロック図である。なお、図１４において、図２に示すクライアント２０-iと等価な部分には便宜的に同一参照符号を付してある。第２の実施形態では、第１の実施形態におけるクライアント２０-iに代えてクライアント２００-iが用いられる。必要ならば、図１において、クライアント２０-1〜２０-nを、クライアント２００-1〜２００-nに置き換えられたい。
【００９９】
図１４に示すクライアント２００-iでは、第１の実施形態におけるデバイスドライバ２３に代えて、図１２の仮想ネットワークインタフェース１２０８、または図１３の仮想ネットワークインタフェース１３０３に相当する仮想ネットワークインタフェース２３０が用いられる。またクライアント２００-iでは、第１の実施形態におけるネットワークインタフェース２２に代えて、図１２のアンダーレイネットワーク１２１２、または図１３のアンダーレイネットワーク１３０８に相当するアンダーレイネットワーク２２０が用いられる。
【０１００】
図１４のクライアント２００-iでは、当該クライアント２００-iに適用される仮想ネットワークインタフェース２３０の実装方法により、ネットワークプロトコルモジュール２４に含まれる機能が異なる（例えば、イーサネット層の有無等）。なお、アンダーレイネットワーク２２０とは、仮想ネットワークインタフェース２３０が使用するネットワークプロトコル群、物理的なネットワークインタフェースとそのデバイスドライバ全てを総称したものである。
【０１０１】
クライアント２００-iの処理手順は第１の実施形態におけるクライアント２０-iと同様である。必要ならば、第１の実施形態で適用される図８、図９及び図１１のフローチャートに従う処理手順についての説明において、クライアント２０-iをクライアント２００-iに、デバイスドライバ２３を仮想ネットワークインタフェース２３０に、そしてネットワークインタフェース２２をアンダーレイネットワーク２２０に、それぞれ読み替えられたい。
【０１０２】
上述の説明では、クライアント側に仮想ネットワークの仮想ネットワークインタフェースの仕組みを適用したが、更に、サーバ側にも仮想ネットワークの仮想ネットワークインタフェースの仕組みを適用することも可能である。
【０１０３】
図１５は、第２の実施形態で適用されるサーバ１００の構成を示すブロック図である。なお、図１５において、図３に示すサーバ１０と等価な部分には便宜的に同一参照符号を付してある。第２の実施形態では、第１の実施形態におけるサーバ１０に代えてサーバ１００が用いられる。必要ならば、図１において、サーバ１０を、サーバ１００に置き換えられたい。
【０１０４】
図１５に示すサーバ１００では、第１の実施形態におけるデバイスドライバ１３に代えて、図１２の仮想ネットワークインタフェース１２０８、または図１３の仮想ネットワークインタフェース１３０３に相当する仮想ネットワークインタフェース１３０が用いられる。またサーバ１００では、第１の実施形態におけるネットワークインタフェース１４に代えて、図１２のアンダーレイネットワーク１２１２、または図１３のアンダーレイネットワーク１３０８に相当するアンダーレイネットワーク１４０が用いられる。またサーバ１００では、仮想ネットワークインタフェース１３０に、データ送信制御モジュール１５が配置される。これにより第２の実施形態においては、仮想ネットワークインタフェース１３０を適用することによる上述の効果に加えて、仮想ネットワークインタフェース１３０の上位層に特別な仕組みを導入する必要がなくなるという効果をも奏することができる。
【０１０５】
サーバ１００の処理手順は第１の実施形態におけるサーバ１０と同様である。必要ならば、第１の実施形態で適用される図７及び図１０のフローチャートに従う処理手順についての説明において、サーバ１０をサーバ１００に、デバイスドライバ１３を仮想ネットワークインタフェース１３０に、そしてネットワークインタフェース１４をアンダーレイネットワーク１４０に、それぞれ読み替えられたい。
第１の実施形態において適用される先行送信データ長の決定手法は、第２の実施形態においても適用可能である。
【０１０６】
なお、本発明は、上記実施形態（第１または第２の実施形態）そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。
【符号の説明】
【０１０７】
１０，１００…サーバ（サーバコンピュータ）、１１…データ配信モジュール、１２…ネットワークプロトコルモジュール、１３…デバイスドライバ（第１の送受信手段）、１４…ネットワークインタフェース（第１の送受信手段）、１５…データ送信制御モジュール、１６…遅延配信データ保持部、１７…定義情報記憶部（第１の定義情報記憶手段）、２０-1〜２０-n，２０-i，２００-i…クライアント（クライアント端末）、２１…バッファ管理モジュール、２２…ネットワークインタフェース（第２の送受信手段）、２３…デバイスドライバ（第２の送受信手段、格納処理手段）、２４…ネットワークプロトコルモジュール、２５…ページフォルトハンドラ（遅延配信データ送信要求手段）、２６…データ処理モジュール、２７…遅延配信データ待ちバッファテーブル（バッファ制御情報保持手段）、２８…定義情報記憶部（第２の定義情報記憶手段）、６１，６２…ページ情報、６３…ページ（第１のメモリページ），６４…ページ（第２のメモリページ）、１３０…仮想ネットワークインタフェース、２３０…仮想ネットワークインタフェース（格納処理手段）、１４０…アンダーレイネットワーク（第１の送受信手段）、２２０…アンダーレイネットワーク（第２の送受信手段）。
【特許請求の範囲】
【請求項１】
サーバコンピュータと複数のクライアント端末とがネットワークによって接続されたデータ配信ネットワークシステムであって、
前記サーバコンピュータは、
前記ネットワークを介してデータを送受信する第１の送受信手段と、
前記ネットワークを介して送信されるべき送信用データの一部を先行送信データとして切り出して、当該先行送信データを前記第１の送受信手段によりブロードキャスト、或いはマルチキャストするデータ送受信制御手段と、
前記送信用データの前記先行送信データを除く部分を遅延配信データとして保持する遅延配信データ保持手段とを含み、
前記複数のクライアント端末の各々は、
前記ネットワークを介してデータを送受信する第２の送受信手段と、
前記サーバコンピュータからブロードキャスト、或いはマルチキャストされた前記先行送信データが前記第２の送受信手段によって受信され、かつ当該先行送信データに対応する前記遅延配信データを必要とする場合、前記第２の送受信手段により前記サーバコンピュータに対して前記遅延配信データの送信を要求する遅延配信データ送信要求手段とを含み、
前記サーバコンピュータの前記データ送受信制御手段は、前記複数のクライアント端末のいずれかのクライアント端末から、前記遅延配信データの送信が要求された場合に、前記遅延配信データ保持手段に保持されている前記遅延配信データを前記第１の送受信手段により当該遅延配信データの送信を要求したクライアント端末宛てに送信する
ことを特徴とするデータ配信ネットワークシステム。
【請求項２】
前記複数のクライアント端末の各々は、
初期状態において物理ページ割り当て済みの第１の仮想アドレスで指定される第１のメモリページ、及び初期状態において物理ページ未割り当ての第２の仮想アドレスで指定される第２のメモリページを含む受信バッファと、
前記第２の送受信手段によって受信された前記先行送信データを前記第１のメモリページに格納する格納処理手段と、
前記第１のメモリページに格納された前記先行送信データに対応する前記遅延配信データを必要とする場合、前記第２のメモリページにアクセスするデータ処理手段と、
前記データ処理手段による前記第２のメモリページへのアクセスに応じてページフォルトが発生した場合、前記第２の仮想アドレスに対して物理ページを割り当てるページフォルトハンドラであって、前記遅延配信データ送信要求手段を含むページフォルトハンドラとを更に含み、
前記格納処理手段は、前記第２の送受信手段によって受信された前記遅延配信データを、前記物理ページが割り当てられた前記第２の仮想アドレスで指定される前記第２のメモリページに格納する
ことを特徴とする請求項１記載のデータ配信ネットワークシステム。
【請求項３】
前記送信用データは、複数のネットワークプロトコルヘッダとペイロードとから構成され、
前記先行送信データは、前記送信用データ中の前記複数のネットワークプロトコルヘッダの少なくとも先頭のネットワークプロトコルヘッダの始端側の一部を含み、
前記遅延配信データは、前記送信用データ中の少なくとも前記ペイロードの終端側の一部を含む
ことを特徴とする請求項１または２に記載のデータ配信ネットワークシステム。
【請求項４】
前記サーバコンピュータは、前記先行送信データの長さを含む当該先行送信データに関する定義情報を記憶するための第１の定義情報記憶手段を更に含み、
前記複数のクライアント端末の各々は、
前記定義情報を記憶するための第２の定義情報記憶手段と、
前記遅延配信データの待ち状態にある前記受信バッファのバッファ制御情報であって、前記第１の仮想アドレス及び前記第２の仮想アドレスを含むバッファ制御情報を保持するためのバッファ制御情報保持手段と、
前記第２の定義情報記憶手段に記憶されている前記定義情報に基づいて前記受信バッファを確保するバッファ管理手段とを更に含み、
前記サーバコンピュータの前記データ送受信制御手段は、前記第１の定義情報記憶手段に記憶されている前記定義情報に基づいて、前記送信用データから前記先行送信データを切り出し、
前記複数のクライアント端末の各々の前記遅延配信データ送信要求手段は、前記第２の仮想アドレスに対して前記物理ページが割り当てられた際に、当該第２の仮想アドレスで指定される第２のメモリページを含む受信バッファの前記バッファ制御情報を前記バッファ制御情報保持手段に追加する ことを特徴とする請求項１乃至３のいずれかに記載のデータ配信ネットワークシステム。
【請求項５】
前記サーバコンピュータの前記データ送受信制御手段は、前記先行送信データを、当該先行送信データの長さを逐次変化させながら、前記複数のクライアント端末に送信することにより、当該先行送信データの長さ毎に、前記遅延配信データの送信を要求するクライアント端末の数を計測し、計測された数が、予め定められた単位時間内に前記サーバコンピュータで処理可能な遅延配信データの送信要求の数以下となる最小の長さを、新たに適用する前記送信データの長さとして決定することを特徴とする請求項１乃至４のいずれかに記載のデータ配信ネットワークシステム。
【請求項６】
前記複数のクライアント端末の各々に含まれる前記格納処理手段が、ネットワークインタフェースのデバイスドライバまたは仮想ネットワークの仮想ネットワークインタフェースから構成されることを特徴とする請求項２記載のデータ配信ネットワークシステム。
【請求項７】
第１の送受信手段、データ送受信制御手段及び遅延配信データ保持手段を含むサーバコンピュータと、第２の送受信手段及び遅延配信データ送信要求手段をそれぞれ含む複数のクライアント端末とがネットワークによって接続されたデータ配信ネットワークシステムにおいて、前記サーバコンピュータからデータを配信するためのデータ配信方法であって、
前記サーバコンピュータの前記データ送受信制御手段が、前記ネットワークを介して送信されるべき送信用データの一部を先行送信データとして切り出すステップと、
前記サーバコンピュータの前記データ送受信制御手段が、前記送信用データの前記先行送信データを除く部分を遅延配信データとして前記遅延配信データ保持手段に保持するステップと、
前記サーバコンピュータの前記データ送受信制御手段が、前記先行送信データを前記第１の送受信手段によりブロードキャスト、或いはマルチキャストするステップと、
前記ブロードキャスト、或いはマルチキャストされた前記先行送信データが、前記複数のクライアント端末のいずれかのクライアント端末の前記第２の送受信手段で受信され、かつ当該クライアント端末が当該先行送信データに対応する前記遅延配信データを必要とする場合、当該クライアント端末の前記遅延配信データ送信要求手段が、前記第２の送受信手段により前記サーバコンピュータに対して前記遅延配信データの送信を要求するステップと、
前記複数のクライアント端末のいずれかのクライアント端末から前記サーバコンピュータに対して前記遅延配信データの送信が要求された場合に、当該サーバコンピュータの前記データ送受信制御手段が、前記遅延配信データ保持手段に保持されている前記遅延配信データを前記第１の送受信手段により当該遅延配信データの送信を要求したクライアント端末宛てに送信するステップと
を具備することを特徴とするデータ配信方法。
【請求項１】
サーバコンピュータと複数のクライアント端末とがネットワークによって接続されたデータ配信ネットワークシステムであって、
前記サーバコンピュータは、
前記ネットワークを介してデータを送受信する第１の送受信手段と、
前記ネットワークを介して送信されるべき送信用データの一部を先行送信データとして切り出して、当該先行送信データを前記第１の送受信手段によりブロードキャスト、或いはマルチキャストするデータ送受信制御手段と、
前記送信用データの前記先行送信データを除く部分を遅延配信データとして保持する遅延配信データ保持手段とを含み、
前記複数のクライアント端末の各々は、
前記ネットワークを介してデータを送受信する第２の送受信手段と、
前記サーバコンピュータからブロードキャスト、或いはマルチキャストされた前記先行送信データが前記第２の送受信手段によって受信され、かつ当該先行送信データに対応する前記遅延配信データを必要とする場合、前記第２の送受信手段により前記サーバコンピュータに対して前記遅延配信データの送信を要求する遅延配信データ送信要求手段とを含み、
前記サーバコンピュータの前記データ送受信制御手段は、前記複数のクライアント端末のいずれかのクライアント端末から、前記遅延配信データの送信が要求された場合に、前記遅延配信データ保持手段に保持されている前記遅延配信データを前記第１の送受信手段により当該遅延配信データの送信を要求したクライアント端末宛てに送信する
ことを特徴とするデータ配信ネットワークシステム。
【請求項２】
前記複数のクライアント端末の各々は、
初期状態において物理ページ割り当て済みの第１の仮想アドレスで指定される第１のメモリページ、及び初期状態において物理ページ未割り当ての第２の仮想アドレスで指定される第２のメモリページを含む受信バッファと、
前記第２の送受信手段によって受信された前記先行送信データを前記第１のメモリページに格納する格納処理手段と、
前記第１のメモリページに格納された前記先行送信データに対応する前記遅延配信データを必要とする場合、前記第２のメモリページにアクセスするデータ処理手段と、
前記データ処理手段による前記第２のメモリページへのアクセスに応じてページフォルトが発生した場合、前記第２の仮想アドレスに対して物理ページを割り当てるページフォルトハンドラであって、前記遅延配信データ送信要求手段を含むページフォルトハンドラとを更に含み、
前記格納処理手段は、前記第２の送受信手段によって受信された前記遅延配信データを、前記物理ページが割り当てられた前記第２の仮想アドレスで指定される前記第２のメモリページに格納する
ことを特徴とする請求項１記載のデータ配信ネットワークシステム。
【請求項３】
前記送信用データは、複数のネットワークプロトコルヘッダとペイロードとから構成され、
前記先行送信データは、前記送信用データ中の前記複数のネットワークプロトコルヘッダの少なくとも先頭のネットワークプロトコルヘッダの始端側の一部を含み、
前記遅延配信データは、前記送信用データ中の少なくとも前記ペイロードの終端側の一部を含む
ことを特徴とする請求項１または２に記載のデータ配信ネットワークシステム。
【請求項４】
前記サーバコンピュータは、前記先行送信データの長さを含む当該先行送信データに関する定義情報を記憶するための第１の定義情報記憶手段を更に含み、
前記複数のクライアント端末の各々は、
前記定義情報を記憶するための第２の定義情報記憶手段と、
前記遅延配信データの待ち状態にある前記受信バッファのバッファ制御情報であって、前記第１の仮想アドレス及び前記第２の仮想アドレスを含むバッファ制御情報を保持するためのバッファ制御情報保持手段と、
前記第２の定義情報記憶手段に記憶されている前記定義情報に基づいて前記受信バッファを確保するバッファ管理手段とを更に含み、
前記サーバコンピュータの前記データ送受信制御手段は、前記第１の定義情報記憶手段に記憶されている前記定義情報に基づいて、前記送信用データから前記先行送信データを切り出し、
前記複数のクライアント端末の各々の前記遅延配信データ送信要求手段は、前記第２の仮想アドレスに対して前記物理ページが割り当てられた際に、当該第２の仮想アドレスで指定される第２のメモリページを含む受信バッファの前記バッファ制御情報を前記バッファ制御情報保持手段に追加する ことを特徴とする請求項１乃至３のいずれかに記載のデータ配信ネットワークシステム。
【請求項５】
前記サーバコンピュータの前記データ送受信制御手段は、前記先行送信データを、当該先行送信データの長さを逐次変化させながら、前記複数のクライアント端末に送信することにより、当該先行送信データの長さ毎に、前記遅延配信データの送信を要求するクライアント端末の数を計測し、計測された数が、予め定められた単位時間内に前記サーバコンピュータで処理可能な遅延配信データの送信要求の数以下となる最小の長さを、新たに適用する前記送信データの長さとして決定することを特徴とする請求項１乃至４のいずれかに記載のデータ配信ネットワークシステム。
【請求項６】
前記複数のクライアント端末の各々に含まれる前記格納処理手段が、ネットワークインタフェースのデバイスドライバまたは仮想ネットワークの仮想ネットワークインタフェースから構成されることを特徴とする請求項２記載のデータ配信ネットワークシステム。
【請求項７】
第１の送受信手段、データ送受信制御手段及び遅延配信データ保持手段を含むサーバコンピュータと、第２の送受信手段及び遅延配信データ送信要求手段をそれぞれ含む複数のクライアント端末とがネットワークによって接続されたデータ配信ネットワークシステムにおいて、前記サーバコンピュータからデータを配信するためのデータ配信方法であって、
前記サーバコンピュータの前記データ送受信制御手段が、前記ネットワークを介して送信されるべき送信用データの一部を先行送信データとして切り出すステップと、
前記サーバコンピュータの前記データ送受信制御手段が、前記送信用データの前記先行送信データを除く部分を遅延配信データとして前記遅延配信データ保持手段に保持するステップと、
前記サーバコンピュータの前記データ送受信制御手段が、前記先行送信データを前記第１の送受信手段によりブロードキャスト、或いはマルチキャストするステップと、
前記ブロードキャスト、或いはマルチキャストされた前記先行送信データが、前記複数のクライアント端末のいずれかのクライアント端末の前記第２の送受信手段で受信され、かつ当該クライアント端末が当該先行送信データに対応する前記遅延配信データを必要とする場合、当該クライアント端末の前記遅延配信データ送信要求手段が、前記第２の送受信手段により前記サーバコンピュータに対して前記遅延配信データの送信を要求するステップと、
前記複数のクライアント端末のいずれかのクライアント端末から前記サーバコンピュータに対して前記遅延配信データの送信が要求された場合に、当該サーバコンピュータの前記データ送受信制御手段が、前記遅延配信データ保持手段に保持されている前記遅延配信データを前記第１の送受信手段により当該遅延配信データの送信を要求したクライアント端末宛てに送信するステップと
を具備することを特徴とするデータ配信方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１１−６１７１６（Ｐ２０１１−６１７１６Ａ）
【公開日】平成２３年３月２４日（２０１１．３．２４）
【国際特許分類】
【出願番号】特願２００９−２１２１６６（Ｐ２００９−２１２１６６）
【出願日】平成２１年９月１４日（２００９．９．１４）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
【公開日】平成２３年３月２４日（２０１１．３．２４）
【国際特許分類】
【出願日】平成２１年９月１４日（２００９．９．１４）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
[ Back to top ]