(57)【要約】【課題】ソフトウェアのオーバーヘッドの低減を簡便に実現する。【解決手段】送信すべきデータを格納する第１バッファのアドレス及び送信すべきデータの長さの情報を含むアドレス情報を生成し、第２バッファに格納するステップと、アドレス情報を第２バッファから第３バッファにコピーすると共に、第１制御ヘッダを付加し、第１パケットを生成するステップと、第１パケットを第３バッファから通信装置内の第４バッファにプロセッサを介さずにコピーするステップと、アドレス情報に基づき、送信すべきデータを第１バッファから第４バッファにプロセッサを介さずにコピーすると共に、第２制御ヘッダを付加し、第２パケットを生成するステップと、第４バッファに格納された第１パケット及び第２パケットを送信先端末に送信する送信ステップとを含む。このようにすれば、プロセッサを介さずにコピーを行うので、ソフトウェアのオーバーヘッドを低減できる。【選択図】図３
2008148181.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサと通信装置とを有するコンピュータにより実行される通信制御方法であって、
送信すべきデータを格納する第１バッファのアドレス及び前記送信すべきデータの長さの情報を含むアドレス情報を生成し、第２バッファに格納するアドレス情報生成ステップと、
前記アドレス情報を前記第２バッファから第３バッファにコピーすると共に、第１制御ヘッダを付加し、第１パケットを生成する第１パケット生成ステップと、
前記第１パケットを前記第３バッファから前記通信装置内の第４バッファに前記プロセッサを介さずにコピーするコピー処理ステップと、
前記アドレス情報に基づき、前記送信すべきデータを前記第１バッファから前記第４バッファに前記プロセッサを介さずにコピーすると共に、第２制御ヘッダを付加し、第２パケットを生成する第２パケット生成ステップと、
前記第４バッファに格納された前記第１パケット及び前記第２パケットを送信先端末に送信する送信ステップと、
を含む通信制御方法。
【請求項２】
プロセッサと通信装置とを有するコンピュータにより実行される通信制御方法であって、
送信すべきデータを格納する第１バッファのアドレス及び前記送信すべきデータの長さの情報を含むアドレス情報を生成し、第２バッファに格納するアドレス情報生成ステップと、
前記アドレス情報を前記第２バッファから第３バッファにコピーすると共に、第１制御ヘッダを付加し、第１パケットを生成する第１パケット生成ステップと、
前記第１パケットを前記第３バッファから前記通信装置内の第４バッファに前記プロセッサを介さずにコピーするコピー処理ステップと、
前記アドレス情報に基づき、前記第１バッファから前記送信すべきデータを前記プロセッサを介さずに読み出し、前記第４バッファに格納された前記第１パケットの最後尾に付加して、統合パケットを生成する第２パケット生成ステップと、
前記第４バッファに格納された前記統合パケットを送信先端末に送信する送信ステップと、
を含む通信制御方法。
【請求項３】
前記コンピュータのオペレーティング・システムに対するデータ送信要求をフックするフック処理ステップ
をさらに含み、
前記フック処理ステップの後に、前記アドレス情報生成ステップを実施する
請求項１又は２記載の通信制御方法。
【請求項４】
前記第１パケット生成ステップが、前記コンピュータのオペレーティング・システムにより実行される
請求項１又は２記載の通信制御方法。
【請求項５】
前記コピー処理ステップ、前記第２パケット生成ステップ及び前記送信ステップが、前記通信装置により実行される
請求項１又は２記載の通信制御方法。
【請求項６】
プロセッサを有するコンピュータに接続される通信装置であって、
受信したパケットを格納する記憶装置と、
送信元端末からパケットを受信し、前記記憶装置に格納する手段と、
受信した前記パケットが、所定のアドレスの情報及び前記所定のアドレスの示す領域に格納される特定のデータの長さの情報を含む第１パケットである場合、当該第１パケットとの対応付けを表す情報及び前記特定のデータを含む第２パケットを既に受信しているか否か判定する第１判定手段と、
受信した前記パケットが、前記第２パケットである場合、当該第２パケットに対応する前記第１パケットを既に受信しているか否か判定する第２判定手段と、
前記第１判定手段により前記第２パケットを既に受信していると判定された場合、又は前記第２判定手段により前記第２パケットに対応する前記第１パケットを既に受信していると判定された場合、前記第２パケットに含まれる前記特定のデータを前記記憶装置から第１バッファに前記プロセッサを介さずにコピーし、前記第１パケットを前記記憶装置から第２バッファに前記プロセッサを介さずにコピーする手段と、
を有する通信装置。
【請求項７】
プロセッサを有するコンピュータに接続される通信装置であって、
受信したパケットを格納する記憶装置と、
送信元端末から、所定のアドレスの情報、前記所定のアドレスの示す領域に格納される特定のデータの長さの情報及び前記特定のデータを含む統合パケットを受信し、前記記憶装置に格納する手段と、
前記統合パケットに含まれる前記特定のデータを前記記憶装置から第１バッファに前記プロセッサを介さずにコピーし、前記統合パケットから前記特定のデータを除いたデータを第１パケットとして前記記憶装置から第２バッファに前記プロセッサを介さずにコピーする手段と、
を有する通信装置。
【請求項８】
前記第１バッファのアドレスの情報を受信し、前記記憶装置に格納する手段
をさらに有する請求項６又は７記載の通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信制御技術に関し、より詳しくはソフトウェアのオーバーヘッドを低減するための通信技術に関する。
【背景技術】
【０００２】
複数の計算機をネットワークに接続する計算機システムにおいて、データを送信する際、途中でデータが欠損する場合がある。この場合、データが確実に送信されたか否か、ネットワーク上の信頼性を保証する機構が必要となる。例えば、受信したデータからエラーを検出した場合にはデータを破棄又は訂正したり、データが送信先に届いていない場合にはデータを再送したりすることによって、ネットワーク上の信頼性を保証する。この信頼性保証を実現する方式としては、ハードウェアによって実現する方式と、ソフトウェアによって実現する方式とに大別される。ハードウェアによって信頼性保証を実現する方式では、ＩｎｆｉｎｉＢａｎｄ（登録商標）やＦｉｂｒｅＣｈａｎｎｅｌ等が用いられる。しかし、これらは、ハードウェアが複雑で、高価になってしまうという課題がある。
【０００３】
一方、信頼性が保証されないハードウェア（例えば、イーサネット（登録商標）等）を用いる場合には、ソフトウェアによって通信の信頼性保証を実現する。ソフトウェアによって通信の信頼性保証を実現する方式では、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）等のプロトコルが広く用いられている。ＴＣＰ／ＩＰ等では、データが届いた場合、送信先から送信元に確認応答（ＡＣＫパケット）を返すようになっており、所定の時間内にＡＣＫパケットが返ってこない場合には、データを再送して、通信の信頼性保証を実現する。なお、通信の信頼性は保証されないが、イーサネットは、ＩｎｆｉｎｉＢａｎｄ等に比べ、安価になるという利点がある。しかし、以下で述べるように、ソフトウェアによって通信の信頼性保証を実現する従来の方式では、ソフトウェアのオーバーヘッドが大きくなるという問題がある。
【０００４】
図１及び図２を用いて、ソフトウェアによって通信の信頼性保証を実現する従来の方式を簡単に説明する。図１に、従来のパケット送受信の処理概要を示す。図１において、送信側計算機と受信側計算機とは、例えばイーサネットで接続されているものとする。また、送信側計算機及び受信側計算機は、それぞれユーザプログラムとＯＳ（Operating System）とＮＩＣ（Network Interface Card）とから構成される。なお、送信側計算機におけるユーザプログラム、ＯＳ及びＮＩＣをそれぞれ送信側ユーザプログラム、送信側ＯＳ及び送信側ＮＩＣと呼ぶ。また、受信側計算機におけるユーザプログラム、ＯＳ及びＮＩＣをそれぞれ受信側ユーザプログラム、受信側ＯＳ及び受信側ＮＩＣと呼ぶ。図１では、ＯＳに実装されたＴＣＰ／ＩＰプロトコルにより、通信の信頼性保証が実現されているものとする。
【０００５】
まず、従来のパケット送信の処理概要を説明する。送信側ユーザプログラムは、ユーザデータの送信を送信側ＯＳに対して要求する（図１：ステップ（１））。この際、送信側ユーザプログラムは、送信すべきユーザデータが格納された領域を指すアドレス、ユーザデータの長さ及びエンドポイントを指定する。そして、送信側ＯＳは、送信すべきユーザデータを送信側ＯＳの内部バッファにコピーしてパケットフレームを生成する（ステップ（２））。この際、送信側ＯＳは、制御ヘッダを付加する。
【０００６】
図２（ａ）及び（ｂ）に、イーサネット上で送受信されるパケットフレームのフォーマットの一例を示す。図２（ａ）は、イーサネット上で送受信されるパケットフレームの基本的なフォーマットの一例を示す。図２（ａ）において、パケットフレームは、イーサネットヘッダとデータ部とから構成されており、イーサネットヘッダには、送信先、送信元及びプロトコル種別の情報が含まれ、データ部には、データ部の先頭からユーザデータが含まれる。また、図２（ａ）の例では、送信先、送信元及びプロトコル種別を総称して制御ヘッダと呼ぶ。一方、図２（ｂ）は、イーサネットヘッダのプロトコル種別に「ＩＰ」が設定された場合のパケットフレームのフォーマットの一例を示す。イーサネットヘッダとデータ部とから構成される点は図２（ａ）の例と同じであるが、データ部の先頭にＩＰヘッダとＴＣＰヘッダとが含まれる点が図２（ａ）と異なる。また、図２（ｂ）の例では、送信先、送信元、プロトコル種別、ＩＰヘッダ及びＴＣＰヘッダを総称して制御ヘッダと呼ぶ。なお、図２（ｂ）は、ＴＣＰヘッダを含む場合の一例であり、ＴＣＰ以外のプロトコルに関するヘッダを含む場合もある。
【０００７】
送信側ＯＳは、パケットフレームを生成した後、送信側ＮＩＣにパケット送信要求を通知する。送信側ＮＩＣは、送信側ＯＳからの送信要求を受信すると、ＤＭＡ転送により、送信側ＯＳの内部バッファからパケットフレームを読み出す（ステップ（３））。そして、送信側ＮＩＣは、パケットフレームを送信する（ステップ（４））。
【０００８】
次に、従来のパケット受信の処理概要を説明する。受信側ユーザプログラムは、ユーザデータの受信を受信側ＯＳに対して要求する（ステップ（５））。この際、受信側ユーザプログラムは、データ受信用バッファのアドレス、データの長さ及びエンドポイントを指定する。そして、受信側ＯＳは、受信側ＮＩＣからの受信通知を待つ。また、受信側ＮＩＣは、パケットフレームを受信すると、ＤＭＡ転送により、受信側ＯＳの内部バッファにパケットフレームを書き込み、パケットフレームを受信した旨を受信側ＯＳに通知する（ステップ（６））。受信側ＯＳは、受信側ＮＩＣから受信通知を受信すると、受信側ＯＳの内部バッファに格納されたパケットフレームから制御ヘッダを除いたデータ（すなわち、ユーザデータ）をデータ受信用バッファにコピーする（ステップ（７））。
【０００９】
また、受信側ＯＳは、ＡＣＫパケットフレームを生成して受信側ＯＳの内部バッファに格納し、受信側ＮＩＣにパケット送信要求を通知する（ステップ（８））。受信側ＮＩＣは、受信側ＯＳから送信要求を受信すると、ＤＭＡ転送により、受信側ＯＳの内部バッファからパケットフレーム（ＡＣＫ）を読み出す（ステップ（９））。そして、受信側ＮＩＣは、パケットフレーム（ＡＣＫ）を送信する（ステップ（１０））。送信側ＮＩＣは、パケットフレーム（ＡＣＫ）を受信すると、ＤＭＡ転送により、送信側ＯＳの内部バッファにパケットフレーム（ＡＣＫ）を書き込み、パケットフレーム（ＡＣＫ）を受信した旨を送信側ＯＳに通知する（ステップ（１１））。送信側ＯＳは、送信側ＮＩＣから受信通知を受信すると、ＡＣＫパケットフレームを確認する（ステップ（１２））。送信側ＯＳは、パケットフレームが問題なく送信先に到達したことを確認できたので、当該パケットフレームを送信側ＯＳの内部バッファから削除する等の処理を実施する。
【００１０】
以上のように、ソフトウェアによって通信の信頼性保証を実現する従来の方式では、ユーザプログラムとＯＳとの間において、ユーザデータのコピー（ステップ（２）及びステップ（７））が発生するので、ソフトウェアのオーバーヘッドが大きくなる。特に、大量のユーザデータを送信する場合には、コピー処理によるＣＰＵ（Central Processing Unit）負荷が大きくなる。近年、ネットワーク上の通信速度は大きく向上しているが、ソフトウェアのオーバーヘッドが大きいため、ネットワーク本来の性能を発揮できていない。
【００１１】
このような問題に対応する従来技術として、例えば、ＴＯＥ（TCP Offload Engine）がある。ＴＯＥでは、コピー処理をＮＩＣで行うため、コピー処理によるＣＰＵ負荷を軽減させることができる。しかし、ＴＯＥは、ユーザプログラムを一切変更する必要はないが、ＯＳをＴＯＥに対応するように変更しなければならない。さらに、ＮＩＣが複雑で、高価になってしまうという課題がある。
【００１２】
さらに、上記問題に対応する他の従来技術として、例えば、ＲＤＭＡ（Remote Direct Memory Access）がある。ＲＤＭＡは、ＮＩＣがユーザデータを直接読み出すので、コピー処理を削減することができる。しかし、ユーザプログラムをＲＤＭＡに対応するように変更しなければならない。さらに、ＲＤＭＡでは、通信の信頼性が保証されないため、ＮＩＣに通信の信頼性を保証する機構を実装しなければならず、やはりＮＩＣが複雑で、高価になってしまうという課題がある。
【００１３】
また、例えば、特開２００５−１００２３０号公報には、物理層、リンク層、トランスポート層及びアプリケーション層を備え、ホストとの間でシリアル伝送によりコマンド及びデータをパケット形式により転送するデバイス用のインターフェース装置であって、トランスポート層に設けられ、物理層及びリンク層を介してホストから受信されたコマンドパケット又はデータパケットを先入れ先出しにより格納する受信用ＦＩＦＯと、データ転送中に受信用ＦＩＦＯに格納されたコマンドを検出してコマンド検出信号を出力するコマンド検出回路と、アプリケーション層に設けられ、受信用ＦＩＦＯのコマンド内容をロードする受信用タスクファイルレジスタと、トランスポート層に設けられ、パケット送信用のコマンド又はデータをロードする送信用タスクファイルレジスタと、トランスポート層に設けられ、送信用タスクファイルレジスタの内容を先入れ先出しで格納し、リンク層及び物理層を介してコマンドパケット又はデータパケットをホストに送信させる送信用ＦＩＦＯと、データ転送中に、ホストから別のコマンドパケットを受信するための空き時間を生成する空き時間生成部と、空き時間にホストからコマンドパケットを受信した場合、データ転送を一時停止して受信コマンドを解読して処理を実行した後に、データ転送を再開する転送中コマンド処理部とを備えたインターフェース装置が開示されている。しかし、上記問題を解決するような技術は開示されていない。
【００１４】
また、例えば、特表平１０−５０５７００号公報には、ローカルエリアネットワークとネットワーク周辺装置間をインタフェースするネットワーク装置であって、 物理ネットワークレイヤから、割込駆動のデータリンクレイヤを介し、周辺装置にサービスするアプリケーションレイヤにまで伸びるプロトコルスタックを具備し、 データリンクレイヤは、固有のダンプ／デバッグパケットヘッダによって起動され、パケットのデータ部内に含まれる専用のデバッグコマンドを解釈し、割込消勢モードにおいてダンプ／デバッグコマンドを実行するモジュールを有するネットワーク装置が開示されている。しかし、やはり上記問題を解決するような技術は開示されていない。
【特許文献１】特開２００５−１００２３０号公報
【特許文献２】特表平１０−５０５７００号公報
【発明の開示】
【発明が解決しようとする課題】
【００１５】
このように、従来技術によれば、ソフトウェアによって通信の信頼性保証を実現する際に生じるソフトウェアのオーバーヘッドの低減を実現できる。しかし、従来技術では、ＮＩＣが複雑で、高価になってしまうという問題がある。さらに、従来技術では、従来のＯＳをそのまま利用することはできないため、専用の構成に変更する必要がある。一般的に、ＯＳを変更することは容易ではなく、手間及び知識が必要となってしまう。
【００１６】
従って、本発明の目的は、ソフトウェアによって通信の信頼性保証を実現する際に生じるソフトウェアのオーバーヘッドの低減を簡便に実現するための技術を提供することである。
【００１７】
また、本発明の他の目的は、従来のＯＳを変更することなく、ソフトウェアによって通信の信頼性保証を実現する際に生じるソフトウェアのオーバーヘッドの低減を実現するための技術を提供することである。
【課題を解決するための手段】
【００１８】
本発明の第１の態様に係る通信制御方法は、プロセッサと通信装置とを有するコンピュータにより実行される通信制御方法であって、送信すべきデータを格納する第１バッファのアドレス及び送信すべきデータの長さの情報を含むアドレス情報を生成し、第２バッファに格納するアドレス情報生成ステップと、アドレス情報を第２バッファから第３バッファにコピーすると共に、第１制御ヘッダを付加し、第１パケットを生成する第１パケット生成ステップと、第１パケットを第３バッファから通信装置内の第４バッファにプロセッサを介さずにコピーするコピー処理ステップと、アドレス情報に基づき、送信すべきデータを第１バッファから第４バッファにプロセッサを介さずにコピーすると共に、第２制御ヘッダを付加し、第２パケットを生成する第２パケット生成ステップと、第４バッファに格納された第１パケット及び第２パケットを送信先端末に送信する送信ステップとを含む。
【００１９】
このようにすれば、例えば、大きなデータを送信する場合であっても、第３バッファにコピーされるのはアドレス情報であるため、コピー処理によるＣＰＵ負荷を低減することができる。また、送信すべきデータは、第１バッファから通信装置内の第４バッファにプロセッサ（例えば、ＣＰＵ）を介さずにコピーされるため、ＣＰＵに負荷はかからない。さらに、通信装置（例えばＮＩＣ）は、通信の信頼性を保証する機構を持たないため、通信装置が複雑になることを抑えることができる。従って、ソフトウェアのオーバーヘッドの低減を簡便に実現できるようになる。
【００２０】
また、第２パケット生成ステップが、第１パケットをコピーして第２パケットに付加するステップを含むようにしても良い。このようにすれば、送信先端末は、第１パケットに対応する第２パケット又は第２パケットに対応する第１パケットを検出することができるようになる。
【００２１】
本発明の第２の態様に係る通信制御方法は、プロセッサと通信装置とを有するコンピュータにより実行される通信制御方法であって、送信すべきデータを格納する第１バッファのアドレス及び送信すべきデータの長さの情報を含むアドレス情報を生成し、第２バッファに格納するアドレス情報生成ステップと、アドレス情報を第２バッファから第３バッファにコピーすると共に、第１制御ヘッダを付加し、第１パケットを生成する第１パケット生成ステップと、第１パケットを第３バッファから通信装置内の第４バッファにプロセッサを介さずにコピーするコピー処理ステップと、アドレス情報に基づき、第１バッファから送信すべきデータをプロセッサを介さずに読み出し、第４バッファに格納された第１パケットの最後尾に付加して、統合パケットを生成する第２パケット生成ステップと、第４バッファに格納された統合パケットを送信先端末に送信する送信ステップとを含む。
【００２２】
このようにすれば、例えば、大きなデータを送信する場合であっても、第３バッファにコピーされるのはアドレス情報であるため、コピー処理によるＣＰＵ負荷を低減することができる。また、送信すべきデータは、第１バッファから通信装置内の第４バッファにプロセッサ（例えば、ＣＰＵ）を介さずにコピーされるため、ＣＰＵに負荷はかからない。さらに、通信装置（例えばＮＩＣ）は、通信の信頼性を保証する機構を持たないため、通信装置が複雑になることを抑えることができる。従って、本発明の第１の態様と同様に、ソフトウェアのオーバーヘッドの低減を簡便に実現できるようになる。
【００２３】
また、本発明の第１又は第２の態様において、コンピュータのオペレーティング・システムに対するデータ送信要求をフックするフック処理ステップをさらに含むようにしても良い。そして、フック処理ステップの後に、アドレス情報生成ステップを実施するようにしても良い。このようにすれば、例えばデータ送信要求の要求元である従来のプログラム及び従来のＯＳに対する変更が不要になる。従って、従来のＯＳを変更することなく、ソフトウェアのオーバーヘッドの低減を実現できるようになる。
【００２４】
さらに、本発明の第１又は第２の態様において、第１パケット生成ステップが、コンピュータのオペレーティング・システムにより実行されるようにしても良い。また、オペレーティング・システムにより、第１パケットの送信要求を通信装置に通知するステップをさらに含むようにしても良い。さらに、コピー処理ステップ、第２パケット生成ステップ及び送信ステップが、通信装置により実行されるようにしても良い。第１パケット生成ステップの処理は、従来のＯＳの処理と変わらないため、従来のＯＳが有する通信の信頼性保証機構（例えば、ＴＣＰ／ＩＰプロトコル）をそのまま利用することができる。
【００２５】
本発明の第３の態様に係る通信制御方法は、プロセッサと通信装置とを有するコンピュータにより実行される通信制御方法であって、送信元端末からパケットを受信し、通信装置内の第１バッファに格納する受信ステップと、受信したパケットが、所定のアドレスの情報と所定のアドレスの示す領域に格納される特定のデータの長さの情報とを含む第１パケットである場合、当該第１パケットとの対応付けを表す情報と特定のデータとを含む第２パケットを既に受信しているか否か判定する第１判定ステップと、受信したパケットが、第２パケットである場合、当該第２パケットに対応する第１パケットを既に受信しているか否か判定する第２判定ステップと、第１判定ステップにおいて第２パケットを既に受信していると判定された場合、又は第２判定ステップにおいて第２パケットに対応する第１パケットを既に受信していると判定された場合、第２パケットに含まれる特定のデータを第１バッファから第２バッファにプロセッサを介さずにコピーし、第１パケットを第１バッファから第３バッファにプロセッサを介さずにコピーするコピー処理ステップと、第１パケットに含まれる所定のアドレスの情報と特定のデータの長さの情報とを第３バッファから第４バッファにコピーすると共に、第１パケットに対する確認応答を送信元端末に送信する応答ステップとを含む。
【００２６】
このようにすれば、例えば、大きなデータを受信した場合であっても、第４バッファにコピーされるのは所定のアドレスの情報と特定のデータの長さの情報とであるため、コピー処理によるＣＰＵ負荷を低減することができる。また、特定のデータは、通信装置内の第１バッファから第２バッファにプロセッサ（例えば、ＣＰＵ）を介さずにコピーされるため、ＣＰＵに負荷はかからない。さらに、通信装置（例えばＮＩＣ）は、通信の信頼性を保証する機構を持たないため、通信装置が複雑になることを抑えることができる。従って、ソフトウェアのオーバーヘッドの低減を簡便に実現できるようになる。
【００２７】
また、本発明の第３の態様において、受信ステップ、第１判定ステップ、第２判定ステップ及びコピー処理ステップが、通信装置により実行されるようにしても良い。さらに、応答ステップが、コンピュータのオペレーティング・システムにより実行されるようにしても良い。応答ステップの処理は、従来のＯＳの処理と変わらないため、従来のＯＳが有する通信の信頼性保証機構（例えば、ＴＣＰ／ＩＰプロトコル）をそのまま利用することができる。
【００２８】
さらに、本発明の第３の態様において、第１パケットとの対応付けを表す情報が、対応する第１パケットをコピーした情報である場合もある。この場合、第１パケットに対応する第２パケット又は第２パケットに対応する第１パケットを検出することができるようになる。
【００２９】
本発明の第４の態様に係る通信制御方法は、プロセッサと通信装置とを有するコンピュータにより実行される通信制御方法であって、送信元端末から、所定のアドレスの情報と所定のアドレスの示す領域に格納される特定のデータの長さの情報と特定のデータとを含む統合パケットを受信し、通信装置内の第１バッファに格納する受信ステップと、統合パケットに含まれる特定のデータを第１バッファから第２バッファにプロセッサを介さずにコピーし、統合パケットから特定のデータを除いたデータを第１パケットとして第１バッファから第３バッファにプロセッサを介さずにコピーするコピー処理ステップと、第１パケットに含まれる所定のアドレスの情報と特定のデータの長さの情報とを第３バッファから第４バッファにコピーすると共に、第１パケットに対する確認応答を送信元端末に送信する応答ステップとを含む。
【００３０】
このようにすれば、例えば、大きなデータを受信した場合であっても、第４バッファにコピーされるのは所定のアドレスの情報と特定のデータの長さの情報とであるため、コピー処理によるＣＰＵ負荷を低減することができる。また、特定のデータは、通信装置内の第１バッファから第２バッファにプロセッサ（例えば、ＣＰＵ）を介さずにコピーされるため、ＣＰＵに負荷はかからない。さらに、通信装置（例えばＮＩＣ）は、通信の信頼性を保証する機構を持たないため、通信装置が複雑になることを抑えることができる。従って、本発明の第３の態様と同様に、ソフトウェアのオーバーヘッドの低減を簡便に実現できるようになる。
【００３１】
また、本発明の第４の態様において、受信ステップ及びコピー処理ステップが、通信装置により実行されるようにしても良い。さらに、応答ステップが、コンピュータのオペレーティング・システムにより実行されるようにしても良い。
【００３２】
さらに、本発明の第３又は第４の態様において、コンピュータのオペレーティング・システムに対するデータ受信要求をフックし、第２バッファのアドレスを通信装置に通知するステップをさらに含むようにしても良い。さらに、第４バッファに格納された所定のアドレスの情報と特定のデータの長さの情報とを破棄するステップをさらに含むようにしても良い。このようにすれば、例えばデータ受信要求の要求元である従来のプログラム及び従来のＯＳに対する変更が不要になる。従って、従来のＯＳを変更することなく、ソフトウェアのオーバーヘッドの低減を実現できるようになる。
【００３３】
なお、本発明に係る通信制御方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。
【発明の効果】
【００３４】
本発明によれば、ソフトウェアによって通信の信頼性保証を実現する際に生じるソフトウェアのオーバーヘッドの低減を簡便に実現できる。
【００３５】
また、本発明の他の側面によれば、従来のＯＳを変更することなく、ソフトウェアによって通信の信頼性保証を実現する際に生じるソフトウェアのオーバーヘッドの低減を実現できる。
【発明を実施するための最良の形態】
【００３６】
［実施の形態１］
図３乃至図１０を用いて本発明の第１の実施の形態を説明する。まず、図３に本発明の実施の形態に係るシステム概要を示す。図３において、計算機３Ａと計算機３Ｂとは、例えばイーサネット等のインターフェース１で接続されている。なお、図３では、計算機３Ａ及び計算機３Ｂの２台の例を示しているが、２台に限定するものではなく、例えばルータ等を介して３台以上の計算機３が接続される場合もある。本実施の形態では、計算機３Ａと計算機３Ｂとが、インターフェース１を介してパケット通信を行う場面を想定する。
【００３７】
各計算機３は、ソフトウェアレベルとハードウェアレベルとに分かれており、ソフトウェアレベルには、ユーザデータの送受信を要求するユーザプログラム３１と、ユーザプログラム３１からの所定の命令をフックするフックライブラリ３３と、ＯＳ３５とが含まれ、ハードウェアレベルには、インターフェース１と接続し、パケットフレームの生成及び送受信を行うＮＩＣ３７が含まれる。なお、図示していないが、ユーザプログラム３１、フックライブラリ３３及びＯＳ３５は記憶装置に格納されており、ＣＰＵにより実行される際には記憶装置からメインメモリに読み出される。
【００３８】
図４に、第１の実施の形態におけるＮＩＣ３７の機能ブロック図を示す。第１の実施の形態におけるＮＩＣ３７は、パケットフレームを格納するメモリバッファ３７１と、パケット送信時にパケットフレームの内容を判定する送信判定部３７２と、以下で詳細に述べるゼロコピーパケットフレームを生成するゼロコピーパケット構築部３７３と、ＤＭＡ（Direct Memory Access）によりデータ転送を行うＤＭＡ処理部３７４と、メモリバッファ３７１に格納されたパケットフレームを送信する送信部３７５と、受信したパケットフレームをメモリバッファ３７１に格納する受信部３７６と、パケット受信時にパケットフレームの内容を判定する受信判定部３７７と、ゼロコピーパケットフレームに含まれるユーザデータをデータ受信用バッファへ書き込むようにＤＭＡ処理部３７４に通知するゼロコピーパケット処理部３７８とを有する。
【００３９】
第１の実施の形態におけるパケット送信の処理概要を図５乃至図７を用いて説明する。なお、送信側計算機におけるユーザプログラム３１、フックライブラリ３３、ＯＳ３５及びＮＩＣ３７をそれぞれ送信側ユーザプログラム、送信側フックライブラリ、送信側ＯＳ及び送信側ＮＩＣと呼ぶ。また、受信側計算機におけるユーザプログラム３１、フックライブラリ３３、ＯＳ３５、ＮＩＣ３７をそれぞれ受信側ユーザプログラム、受信側フックライブラリ、受信側ＯＳ、受信側ＮＩＣと呼ぶ。
【００４０】
まず、送信側ユーザプログラムは、ユーザデータの送信を送信側ＯＳに対して要求する（図５：ステップ（２１））。送信側ユーザプログラムは、従来と同様に、送信すべきユーザデータが格納された領域を指すアドレス、ユーザデータの長さ及びエンドポイントを指定する。この際、本実施の形態では、送信側フックライブラリが、送信側ユーザプログラムから送信側ＯＳに対する要求をフックし、以下のような処理を行う。すなわち、送信側フックライブラリは、送信側ユーザプログラムにより指定されたアドレス及び長さを含むアドレス情報を生成し、送信側フックライブラリの内部バッファに格納する（ステップ（２２））。そして、送信側フックライブラリは、アドレス情報の送信を送信側ＯＳに対して要求する。すなわち、送信側ユーザプログラムは、従来と同様にユーザデータの送信を要求しているが、送信側ＯＳは、ユーザデータではなく、アドレス情報の送信を行うことになる。送信側ＯＳは、アドレス情報を送信側ＯＳの内部バッファにコピーしてパケットフレームを生成する（ステップ（２３））。なお、ここでは、説明の便宜上、アドレス情報を含むパケットフレームをアドレス情報パケットフレームと呼ぶが、実際、送信側ＯＳでは、従来のパケットフレームとアドレス情報パケットフレームとの区別はなく、いずれも同様に扱われる。
【００４１】
図６に、アドレス情報パケットフレームのフォーマットの一例を示す。図６の例では、アドレス情報パケットフレームは、制御ヘッダ（すなわち、送信先、送信元、プロトコル種別（ＩＰ）、ＩＰヘッダ及びＴＣＰヘッダ）とアドレス情報（すなわち、ユーザデータが格納された領域を指すアドレス及びユーザデータの長さ）とから構成される。ユーザデータの代わりにアドレス情報が設定される点が、従来のパケットフレーム（図２（ｂ））と異なる。
【００４２】
送信側ＯＳは、アドレス情報パケットフレームを生成した後、送信側ＮＩＣにパケット送信要求を通知する。送信側ＮＩＣは、送信側ＯＳからの送信要求を受信すると、ＤＭＡ転送により、送信側ＯＳの内部バッファからパケットフレームを読み出す（ステップ（２４））。そして、送信側ＮＩＣは、読み出したパケットフレームが、アドレス情報パケットフレームか否か判定する（ステップ（２５））。なお、パケットフレームの中身をチェックするような処理は、従来と同様であるため、詳細な説明は省略する。もし、読み出したパケットフレームが従来のパケットフレームと判定された場合には、従来と同様に、送信側ＮＩＣはパケットフレームを送信する。一方、読み出したパケットフレームがアドレス情報パケットフレームと判定された場合には、送信側ＮＩＣは、ＤＭＡ転送により、アドレス情報に含まれるアドレスの指す領域からユーザデータを読み出し、ゼロコピーパケットフレームを生成する（ステップ（２６））。この際、送信側ＮＩＣは、制御ヘッダ及び対応するアドレス情報パケットフレームのコピーを付加する。
【００４３】
図７に、ゼロコピーパケットフレームのフォーマットの一例を示す。図７の例では、ゼロコピーパケットフレームは、制御ヘッダ（すなわち、送信先、送信元、プロトコル種別（専用番号）及びゼロコピー情報）と、対応するアドレス情報パケットフレームのコピー（すなわち、送信先、送信元、プロトコル種別（ＩＰ）、ＩＰヘッダ、ＴＣＰヘッダ、ユーザデータが格納された領域を指すアドレス及びユーザデータの長さ）と、ユーザデータとから構成される。制御ヘッダに含まれるプロトコル種別には、ゼロコピーパケットフレームであることが分かるような専用番号を設定する。また、制御ヘッダに含まれるゼロコピー情報には、ゼロコピーパケットフレームの送受信において必要となる制御情報を設定する。例えば、イーサネットでは、送信できるパケットフレームのサイズには限りがあるため、大きなユーザデータを送信する場合には、複数のパケットフレームに分割して送信する必要がある。なお、従来のパケット送信においては送信側ＯＳにより分割等が行われるが、本実施の形態では、送信側ＯＳは、ユーザデータではなくアドレス情報（すなわち、小さなデータ）を送信することになるので、送信側ＯＳによる分割は必要ないものとする。従って、本実施の形態では、送信側ＮＩＣがユーザデータを複数のパケットフレームに分割し、複数のゼロコピーパケットフレームを送信する必要がある。この場合、ゼロコピーパケットフレームが全体の何番目に位置するかを示す情報（すなわち、シーケンス番号に相当する情報）を、ゼロコピー情報に設定する。なお、分割等の処理については本実施の形態の主要部ではないので、ここでは説明しない。
【００４４】
送信側ＮＩＣは、ゼロコピーパケットフレームを生成した後、アドレス情報パケットフレームとゼロコピーパケットフレームとを送信する（ステップ（２７））。また、本実施の形態におけるパケット受信の処理概要については、後で説明するが、アドレス情報パケットフレームとゼロコピーパケットフレームとが受信側計算機に到達した場合、送信側ＮＩＣは、受信側計算機からのパケットフレーム（ＡＣＫ）を受信する（ステップ（２８））。そして、送信側ＮＩＣは、ＤＭＡ転送により、送信側ＯＳの内部バッファにパケットフレーム（ＡＣＫ）を書き込み、パケットフレーム（ＡＣＫ）を受信した旨を送信側ＯＳに通知する（ステップ（２９））。送信側ＯＳは、送信側ＮＩＣからの受信通知を受信すると、ＡＣＫパケットフレームを確認する（ステップ（３０））。送信側ＯＳは、パケットフレームが問題なく送信先に到達したことを確認できたので、当該パケットフレームを送信側ＯＳの内部バッファから削除する等の処理を実施する。この際、送信側ＯＳは、実際には、アドレス情報パケットフレームを内部バッファから削除することになる。
【００４５】
このようにすれば、送信側ＮＩＣが、ＤＭＡ転送により、ユーザデータを直接読み出すので、ソフトウェアレベルにおいて、ユーザデータのコピーは発生しない。また、送信側ＯＳが、内部バッファにコピーするのはアドレス及び長さの情報だけであり、例えば、大量のユーザデータを送信する場合でも、コピー処理によるＣＰＵ負荷を最小限に抑えることができる。さらに、送信側ユーザプログラム及び送信側ＯＳを変更しなくても実現することができる。
【００４６】
次に、第１の実施の形態におけるパケット受信の処理概要を図８を用いて説明する。まず、受信側ユーザプログラムは、ユーザデータの受信を受信側ＯＳに対して要求する（図８：ステップ（３１））。受信側ユーザプログラムは、従来と同様に、データ受信用バッファのアドレス、データの長さ及びエンドポイントを指定する。この際、本実施の形態では、受信側フックライブラリが、受信側ユーザプログラムから受信側ＯＳに対する要求をフックし、以下のような処理を行う。すなわち、受信側フックライブラリは、受信側ユーザプログラムにより指定されたデータ受信用バッファのアドレスを受信側ＮＩＣに通知する（ステップ（３２））。これにより、後で説明するが、受信側ＮＩＣは、ＤＭＡ転送により、ユーザデータをデータ受信用バッファに書き込むことができるようになる。また、受信側フックライブラリは、受信側フックライブラリの内部バッファに、アドレス情報を格納するための領域（以下、アドレス情報受信用バッファと呼ぶ）を確保する。後で説明するが、アドレス情報受信用バッファには、受信側ＯＳによりアドレス情報がコピーされる。そして、受信側フックライブラリは、アドレス情報の受信を受信側ＯＳに対して要求する。すなわち、受信側ユーザプログラムは、従来と同様にユーザデータの受信を要求しているが、受信側ＯＳは、ユーザデータではなく、アドレス情報の受信を行うことになる。そして、受信側ＯＳは、受信側ＮＩＣからの受信通知を待つ。
【００４７】
また、受信側ＮＩＣは、パケットフレームを受信すると、受信したパケットフレームが、アドレス情報パケットフレーム、ゼロコピーパケットフレーム及びその他のパケットフレーム（すなわち、従来のパケットフレーム）のいずれかであるか判定する（ステップ（３３））。もし、受信したパケットフレームが従来のパケットフレームと判定された場合には、従来通りの処理を実施する。一方、受信したパケットフレームがアドレス情報パケットフレーム又はゼロコピーパケットフレームと判定された場合、対応するゼロコピーパケットフレーム又は対応するアドレス情報パケットフレームを既に受信しているか判定する。まだ対応するゼロコピーパケットフレーム又は対応するアドレス情報パケットフレームを受信していなければ、以降の処理を保留する。なお、所定時間以上、対応するゼロコピーパケットフレーム又は対応するアドレス情報パケットフレームを受信しない場合には、受信済みのアドレス情報パケットフレーム又はゼロコピーパケットフレームを内部バッファから削除する。
【００４８】
一方、対応するゼロコピーパケットフレーム又は対応するアドレス情報パケットフレームを既に受信している場合には、受信側ＮＩＣは、ＤＭＡ転送により、ゼロコピーパケットフレームに含まれるユーザデータをデータ受信用バッファに書き込む（ステップ（３４））。また、受信側ＮＩＣは、ＤＭＡ転送により、受信側ＯＳの内部バッファにアドレス情報パケットフレームを書き込み、パケットフレームを受信した旨を受信側ＯＳに通知する（ステップ（３５））。受信側ＯＳは、受信側ＮＩＣから受信通知を受信すると、受信側ＯＳの内部バッファに格納されたアドレス情報パケットフレームから制御ヘッダを除いたデータ（すなわち、アドレス情報）をアドレス情報受信用バッファにコピーする（ステップ（３６））。
【００４９】
また、受信側ＯＳは、ＡＣＫパケットフレームを生成して受信側ＯＳの内部バッファに格納し、受信側ＮＩＣにパケット送信要求を通知する（ステップ（３７））。受信側ＮＩＣは、受信側ＯＳから送信要求を受信すると、ＤＭＡ転送により、受信側ＯＳの内部バッファからパケットフレーム（ＡＣＫ）を読み出す（ステップ（３８））。そして、受信側ＮＩＣは、パケットフレーム（ＡＣＫ）を送信する（ステップ（３９））。
【００５０】
また、受信側ＯＳは、受信処理が完了するとユーザプログラムに完了応答を通知する。この際、本実施の形態では、受信側フックライブラリが、受信側ＯＳからユーザプログラムに対する完了応答をフックし、以下のような処理を行う。すなわち、受信側フックライブラリは、アドレス情報受信用バッファに格納されたアドレス情報を破棄する（ステップ（４０））。
【００５１】
このようにすれば、受信側ＮＩＣが、ＤＭＡ転送により、ユーザデータをデータ受信用バッファに直接書き込むので、ソフトウェアレベルにおいて、ユーザデータのコピーは発生しない。また、受信側ＯＳが、内部バッファにコピーするのはアドレス及び長さの情報だけであり、例えば、大量のユーザデータを受信する場合でも、コピー処理によるＣＰＵ負荷を最小限に抑えることができる。さらに、フックライブラリによりアドレス情報は破棄されるので、送信側ユーザプログラム及び送信側ＯＳを変更しなくても実現することができる。
【００５２】
次に、図５のような処理を実施するためのＮＩＣ３７の処理をより詳細に説明する。図９に、ＮＩＣ３７の送信処理の処理フローを示す。まず、ＤＭＡ処理部３７４は、送信側ＯＳからパケット送信要求を受信すると（図９：ステップＳ１）、ＤＭＡ転送により、送信側ＯＳの内部バッファから、送信すべきパケットフレームを読み出し、メモリバッファ３７１に格納する（ステップＳ３）。送信判定部３７２は、メモリバッファ３７１を参照し、送信すべきパケットフレームの内容を判定する（ステップＳ５）。すなわち、送信すべきパケットフレームが、アドレス情報パケットフレームか否か判定する。もし、送信すべきパケットフレームが、アドレス情報パケットフレームでない場合（ステップＳ７：Ｎｏルート）、従来と同様に、送信部３７５は、パケットフレームを送信する（ステップＳ９）。そして、元の処理に戻る。
【００５３】
一方、送信すべきパケットフレームが、アドレス情報パケットフレームである場合（ステップＳ７：Ｙｅｓルート）、送信判定部３７２は、ゼロコピーパケットフレームを生成する旨の命令をゼロコピーパケット構築部３７３に対して出力する。そして、ゼロコピーパケット構築部３７３は、ユーザデータを読み出す旨の命令をＤＭＡ処理部３７４に対して出力する。ＤＭＡ処理部３７４は、アドレス情報パケットフレームに含まれるアドレス情報に基づき、ＤＭＡ転送により、データを読み出し、メモリバッファ３７１に格納する（ステップ１１）。上で述べたように、アドレス情報には、ユーザデータが格納された領域を指すアドレスとユーザデータの長さが含まれるので、これらの情報を基にユーザデータを読み出す。そして、ゼロコピーパケット構築部３７３は、ユーザデータに制御ヘッダとアドレス情報パケットフレームのコピーとを付加し、ゼロコピーパケットフレームを生成する（ステップＳ１３）。送信部３７５は、メモリバッファ３７１に格納されているアドレス情報パケットフレーム及びゼロコピーパケットフレームを送信する（ステップＳ１５）。そして、元の処理に戻る。
【００５４】
次に、図８のような処理を実施するためのＮＩＣ３７の処理をより詳細に説明する。図１０に、ＮＩＣ３７の受信処理の処理フローを示す。まず、ＤＭＡ処理部３７４は、受信側フックライブラリからデータ受信用バッファのアドレスを受信し、メモリバッファ３７１に格納する（図１０：ステップＳ１７）。また、受信部３７６は、パケットフレームを受信し、メモリバッファ３７１に格納する（ステップＳ１９）。そして、受信判定部３７７は、メモリバッファ３７１を参照し、受信したパケットフレームの内容を判定する（ステップＳ２１）。すなわち、受信したパケットフレームが、アドレス情報パケットフレーム、ゼロコピーパケットフレーム及びその他のパケットフレームのいずれであるか判定する。
【００５５】
もし、受信したパケットフレームが、アドレス情報パケットフレームである場合（ステップＳ２３：Ｙｅｓルート）、受信判定部３７７は、対応するゼロコピーパケットフレームを検索する旨の命令をゼロコピーパケット処理部３７８に対して出力する。ゼロコピーパケット処理部３７８は、アドレス情報パケットフレームとゼロコピーパケットフレームに含まれるアドレス情報パケットフレームのコピーとを比較し、対応するゼロコピーパケットフレームを受信しているか否か判定する（ステップＳ２５）。まだ対応するゼロコピーパケットフレームを受信していなければ（ステップＳ２５：Ｎｏルート）、端子Ａを介してステップＳ１９の処理に戻る。一方、対応するゼロコピーパケットフレームを受信している場合には（ステップＳ２５：Ｙｅｓルート）、ステップＳ３３の処理に移行する。
【００５６】
一方、受信したパケットフレームが、アドレス情報パケットフレームでなく（ステップＳ２３：Ｎｏルート）、ゼロコピーパケットフレームである場合（ステップＳ２７：Ｙｅｓルート）、受信判定部３７７は、対応するアドレス情報パケットフレームを検索する旨の命令をゼロコピーパケット処理部３７８に対して出力する。ゼロコピーパケット処理部３７８は、アドレス情報パケットフレームとゼロコピーパケットフレームに含まれるアドレス情報パケットフレームのコピーとを比較し、対応するアドレス情報パケットフレームを受信しているか否か判定する（ステップＳ３１）。まだ対応するアドレス情報パケットフレームを受信していなければ（ステップＳ３１：Ｎｏルート）、端子Ａを介してステップＳ１９の処理に戻る。一方、対応するアドレス情報パケットフレームを受信している場合には（ステップＳ３１：Ｙｅｓルート）、ステップＳ３３の処理に移行する。
【００５７】
また、受信したパケットフレームが、アドレス情報パケットフレームでなく（ステップＳ２３：Ｎｏルート）、且つゼロコピーパケットフレームでもない場合（ステップＳ２７：Ｎｏルート）、受信したパケットフレームは、従来のパケットフレームであるため、従来と同様の処理を行う。すなわち、ＤＭＡ処理部３７４は、ＤＭＡ転送により、受信したパケットフレームを受信側ＯＳの内部バッファに書き込む（ステップＳ２９）。
【００５８】
また、対応するゼロコピーパケットフレームを受信している場合（ステップＳ２５：Ｙｅｓルート）又は対応するアドレス情報パケットフレームを受信している場合（ステップＳ３１：Ｙｅｓルート）、ゼロコピーパケット処理部３７８は、ゼロコピーパケットフレームに含まれるユーザデータ及びアドレス情報パケットフレームの書込命令をＤＭＡ処理部３７４に対して出力する。ＤＭＡ処理部３７４は、メモリバッファ３７１に格納されたデータ受信用バッファのアドレスを基に、ＤＭＡ転送により、ゼロコピーパケットフレームに含まれるユーザデータをデータ受信用バッファに書き込む（ステップＳ３３）。また、ＤＭＡ処理部３７４は、ＤＭＡ転送により、アドレス情報パケットフレームを受信側ＯＳの内部バッファに書き込む（ステップＳ３５）。そして、元の処理に戻る。
【００５９】
なお、受信側ＮＩＣが、受信側フックライブラリからデータ受信用バッファのアドレスを受信する前に、送信側ＮＩＣからパケットフレームが送信される場合があるが、その場合には、アドレス情報パケットフレームとゼロコピーパケットフレームとをメモリバッファ３７１で保持しておき、所定のタイミングでステップＳ３３及びＳ３５の処理を行うようにすれば良い。
【００６０】
以上のように、本実施の形態によれば、送信側計算機及び受信側計算機のソフトウェアレベルにおいて、ユーザデータのコピーは発生しないので、例えば、大量のユーザデータを送受信する場合でも、コピー処理によるＣＰＵ負荷を最小限に抑えることができ、通信速度の低下を防止することができる。また、従来のユーザプログラム３１及びＯＳ３５をそのまま利用することができ、ＯＳ３５の通信制御機能（例えば、パケット欠損時の再送等）もそのまま利用することができる。すなわち、ソフトウェアレベルでネットワーク上の信頼性が保証されるため、ハードウェアレベルにおいて、ネットワーク上の信頼性を保証する必要はない。
【００６１】
［実施の形態２］
次に図１１乃至図１６を用いて本発明の第２の実施の形態を説明する。本実施の形態におけるシステム構成は、基本的には図１に示したものと同じであるが、ＮＩＣ３７の代わりにＮＩＣ３７ｂが処理を行う。
【００６２】
図１１に、第２の実施の形態におけるＮＩＣ３７ｂの機能ブロック図を示す。第２の実施の形態におけるＮＩＣ３７ｂは、メモリバッファ３７１と、送信判定部３７２と、統合パケットフレーム構築部３７３ｂと、ＤＭＡ処理部３７４と、送信部３７５と、受信部３７６と、受信判定部３７７と、統合パケットフレーム処理部３７８ｂとを有する。統合パケットフレーム構築部３７３ｂは、パケット送信時に、以下で詳細に述べる統合パケットフレームを生成する。また、統合パケットフレーム処理部３７８ｂは、パケット受信時に、統合パケットフレームに含まれるユーザデータをデータ受信用バッファへ書き込むようにＤＭＡ処理部３７４に通知する。メモリバッファ３７１、送信判定部３７２、ＤＭＡ処理部３７４、送信部３７５、受信部３７６及び受信判定部３７７は、基本的には第１の実施の形態と同じものである。
【００６３】
第２の実施の形態におけるパケット送信の処理概要を図１２及び図１３を用いて説明する。まず、送信側ユーザプログラムは、ユーザデータの送信を送信側ＯＳに対して要求する（図１２：ステップ（５１））。送信側ユーザプログラムは、従来と同様に、送信すべきユーザデータが格納された領域を指すアドレス、ユーザデータの長さ及びエンドポイントを指定する。この際、第１の実施の形態と同様に、送信側フックライブラリが、送信側ユーザプログラムから送信側ＯＳに対する要求をフックし、以下のような処理を行う。すなわち、送信側フックライブラリは、送信側ユーザプログラムにより指定されたアドレス及び長さを含むアドレス情報を生成し、送信側フックライブラリの内部バッファに格納する（ステップ（５２））。そして、送信側フックライブラリは、アドレス情報の送信を送信側ＯＳに対して要求する。すなわち、送信側ユーザプログラムは、従来と同様にユーザデータの送信を要求しているが、送信側ＯＳは、ユーザデータではなく、アドレス情報の送信を行うことになる。送信側ＯＳは、アドレス情報を送信側ＯＳの内部バッファにコピーしてパケットフレームを生成する（ステップ（５３））。
【００６４】
送信側ＯＳは、アドレス情報パケットフレームを生成した後、送信側ＮＩＣにパケット送信要求を通知する。送信側ＮＩＣは、送信側ＯＳからの送信要求を受信すると、ＤＭＡ転送により、送信側ＯＳの内部バッファからパケットフレームを読み出す（ステップ（５４））。そして、送信側ＮＩＣは、読み出したパケットフレームが、アドレス情報パケットフレームか否か判定する（ステップ（５５））。もし、読み出したパケットフレームが従来のパケットフレームと判定された場合には、従来と同様に、送信側ＮＩＣはパケットフレームを送信する。一方、読み出したパケットフレームがアドレス情報パケットフレームと判定された場合、本実施の形態では、送信側ＮＩＣは、ＤＭＡ転送により、アドレス情報に含まれるアドレスの指す領域からユーザデータを読み出し、統合パケットフレームを生成する（ステップ（５６））。送信側ＮＩＣは、アドレス情報パケットフレームの最後尾にゼロコピー情報と読み出したユーザデータを付加し、統合パケットフレームを生成する。
【００６５】
図１３に、統合パケットフレームのフォーマットの一例を示す。図１３の例では、統合パケットフレームは、アドレス情報パケットフレーム（図６）と、ゼロコピー情報と、ユーザデータとから構成される。
【００６６】
送信側ＮＩＣは、統合パケットフレームを生成した後、統合パケットフレームを送信する（ステップ（５７））。また、本実施の形態におけるパケット受信の処理概要については、後で説明するが、統合パケットフレームが受信側計算機に到達した場合、送信側ＮＩＣは、受信側計算機からのパケットフレーム（ＡＣＫ）を受信する（ステップ（５８））。そして、送信側ＮＩＣは、ＤＭＡ転送により、送信側ＯＳの内部バッファにパケットフレーム（ＡＣＫ）を書き込み、パケットフレーム（ＡＣＫ）を受信した旨を送信側ＯＳに通知する（ステップ（５９））。送信側ＯＳは、送信側ＮＩＣからの受信通知を受信すると、ＡＣＫパケットフレームを確認する（ステップ（６０））。送信側ＯＳは、パケットフレームが問題なく送信先に到達したことを確認できたので、当該パケットフレームを送信側ＯＳの内部バッファから削除する等の処理を実施する。この際、送信側ＯＳは、実際には、アドレス情報パケットフレームを内部バッファから削除することになる。
【００６７】
第１の実施の形態では、アドレス情報パケットフレームとゼロコピーパケットフレームとの２つのパケットを送信したが、第２の実施の形態では、必要な情報を１つのパケット（統合パケットフレーム）にまとめて送信する。
【００６８】
このようにすれば、送信側ＮＩＣが、ＤＭＡ転送により、ユーザデータを直接読み出すので、ソフトウェアレベルにおいて、ユーザデータのコピーは発生しない。また、送信側ＯＳが、内部バッファにコピーするのはアドレス及び長さの情報だけであり、例えば、大量のユーザデータを送信する場合でも、コピー処理によるＣＰＵ負荷を最小限に抑えることができる。さらに、送信側ユーザプログラム及び送信側ＯＳを変更しなくても実現することができる。
【００６９】
次に、第２の実施の形態におけるパケット受信の処理概要を図１４を用いて説明する。まず、受信側ユーザプログラムは、ユーザデータの受信を受信側ＯＳに対して要求する（図１４：ステップ（６１））。受信側ユーザプログラムは、従来と同様に、データ受信用バッファのアドレス、データの長さ及びエンドポイントを指定する。この際、第１の実施の形態と同様に、受信側フックライブラリが、受信側ユーザプログラムから受信側ＯＳに対する要求をフックし、以下のような処理を行う。すなわち、受信側フックライブラリは、受信側ユーザプログラムにより指定されたデータ受信用バッファのアドレスを受信側ＮＩＣに通知する（ステップ（６２））。これにより、後で説明するが、受信側ＮＩＣは、ＤＭＡ転送により、ユーザデータをデータ受信用バッファに書き込むことができるようになる。また、受信側フックライブラリは、受信側フックライブラリの内部バッファに、アドレス情報を格納するための領域（以下、アドレス情報受信用バッファと呼ぶ）を確保する。後で説明するが、アドレス情報受信用バッファには、受信側ＯＳによりアドレス情報がコピーされる。そして、受信側フックライブラリは、アドレス情報の受信を受信側ＯＳに対して要求する。すなわち、受信側ユーザプログラムは、従来と同様にユーザデータの受信を要求しているが、受信側ＯＳは、ユーザデータではなく、アドレス情報の受信を行うことになる。そして、受信側ＯＳは、受信側ＮＩＣからの受信通知を待つ。
【００７０】
また、受信側ＮＩＣは、パケットフレームを受信すると、受信したパケットフレームが、統合パケットフレームか否か判定する（ステップ（６３））。もし、受信したパケットフレームが、統合パケットフレームでなければ、従来通りの処理を実施する。一方、受信したパケットフレームが、統合パケットフレームである場合には、受信側ＮＩＣは、ＤＭＡ転送により、統合パケットフレームに含まれるユーザデータをデータ受信用バッファに書き込む（ステップ（６４））。また、受信側ＮＩＣは、ＤＭＡ転送により、受信側ＯＳの内部バッファに統合パケットフレームに含まれる制御ヘッダ及びアドレス情報（すなわち、アドレス情報パケットフレームの内容）を書き込み、パケットフレームを受信した旨を受信側ＯＳに通知する（ステップ（６５））。受信側ＯＳは、受信側ＮＩＣから受信通知を受信すると、受信側ＯＳの内部バッファに格納されたアドレス情報パケットフレームから制御ヘッダを除いたデータ（すなわち、アドレス情報）をアドレス情報受信用バッファにコピーする（ステップ（６６））。
【００７１】
また、受信側ＯＳは、ＡＣＫパケットフレームを生成して受信側ＯＳの内部バッファに格納し、受信側ＮＩＣにパケット送信要求を通知する（ステップ（６７））。受信側ＮＩＣは、受信側ＯＳから送信要求を受信すると、ＤＭＡ転送により、受信側ＯＳの内部バッファからパケットフレーム（ＡＣＫ）を読み出す（ステップ（６８））。そして、受信側ＮＩＣは、パケットフレーム（ＡＣＫ）を送信する（ステップ（６９））。
【００７２】
また、受信側ＯＳは、受信処理が完了するとユーザプログラムに完了応答を通知する。この際、本実施の形態では、受信側ＯＳからユーザプログラムに対する完了応答をフックし、以下のような処理を行う。すなわち、受信側フックライブラリは、アドレス情報受信用バッファに格納されたアドレス情報を破棄する（ステップ（７０））。
【００７３】
第２の実施の形態では、１つのパケット（統合パケットフレーム）として送信されるので、第１の実施の形態のように、両パケットフレーム（アドレス情報パケットフレーム及びゼロコピーパケットフレーム）を受信したか否かの判定は行わなくて良い。
【００７４】
このようにすれば、受信側ＮＩＣが、ＤＭＡ転送により、ユーザデータをデータ受信用バッファに直接書き込むので、ソフトウェアレベルにおいて、ユーザデータのコピーは発生しない。また、受信側ＯＳが、内部バッファにコピーするのはアドレス及び長さの情報だけであり、例えば、大量のユーザデータを受信する場合でも、コピー処理によるＣＰＵ負荷を最小限に抑えることができる。さらに、フックライブラリによりアドレス情報は破棄されるので、送信側ユーザプログラム及び送信側ＯＳを変更しなくても実現することができる。
【００７５】
次に、図１２のような処理を実施するためのＮＩＣ３７ｂの処理をより詳細に説明する。図１５に、ＮＩＣ３７ｂの送信処理の処理フローを示す。まず、ＤＭＡ処理部３７４は、送信側ＯＳからパケット送信要求を受信すると（図１５：ステップＳ４１）、ＤＭＡ転送により、送信側ＯＳの内部バッファから、送信すべきパケットフレームを読み出し、メモリバッファ３７１に格納する（ステップＳ４３）。送信判定部３７２は、メモリバッファ３７１を参照し、送信すべきパケットフレームの内容を判定する（ステップＳ４５）。すなわち、送信すべきパケットフレームが、アドレス情報パケットフレームか否か判定する。もし、送信すべきパケットフレームが、アドレス情報パケットフレームでない場合（ステップＳ４７：Ｎｏルート）、従来と同様に、送信部３７５は、パケットフレームを送信する（ステップＳ４９）。そして、元の処理に戻る。
【００７６】
一方、送信すべきパケットフレームが、アドレス情報パケットフレームである場合（ステップＳ４７：Ｙｅｓルート）、送信判定部３７２は、統合パケットフレームを生成する旨の命令を統合パケットフレーム構築部３７３ｂに対して出力する。そして、統合パケットフレーム構築部３７３ｂは、ユーザデータを読み出す旨の命令をＤＭＡ処理部３７４に対して出力する。ＤＭＡ処理部３７４は、アドレス情報パケットフレームに含まれるアドレス情報に基づき、ＤＭＡ転送により、データを読み出し、メモリバッファ３７１に格納する（ステップ５１）。上で述べたように、アドレス情報には、ユーザデータが格納された領域を指すアドレスとユーザデータの長さが含まれるので、これらの情報を基にユーザデータを読み出す。そして、統合パケットフレーム構築部３７３ｂは、ゼロコピー情報と読み出したユーザデータとをアドレス情報パケットフレームの最後尾に付加し、統合パケットフレームを生成する（ステップＳ５３）。送信部３７５は、メモリバッファ３７１に格納されている統合パケットフレームを送信する（ステップＳ５５）。そして、元の処理に戻る。
【００７７】
次に、図１４のような処理を実施するためのＮＩＣ３７ｂの処理をより詳細に説明する。図１６に、ＮＩＣ３７ｂの受信処理の処理フローを示す。まず、ＤＭＡ処理部３７４は、受信側フックライブラリからデータ受信用バッファのアドレスを受信し、メモリバッファ３７１に格納する（図１６：ステップＳ５７）。また、受信部３７６は、パケットフレームを受信し、メモリバッファ３７１に格納する（ステップＳ５９）。そして、受信判定部３７７は、メモリバッファ３７１を参照し、受信したパケットフレームの内容を判定する（ステップＳ６１）。すなわち、受信したパケットフレームが、統合パケットフレームか否か判定する。
【００７８】
もし、受信したパケットフレームが、統合パケットフレームでなければ（ステップＳ６３：Ｎｏルート）、従来と同様の処理を実施する。すなわち、ＤＭＡ処理部３７４は、ＤＭＡ転送により、受信したパケットフレームを受信側ＯＳの内部バッファに書き込む（ステップＳ６５）。一方、受信したパケットフレームが、統合パケットフレームである場合には（ステップＳ６３：Ｙｅｓルート）、受信判定部３７７は、統合パケットフレームの処理を実施する旨の命令を統合パケットフレーム処理部３７８ｂに対して出力する。統合パケットフレーム処理部３７８ｂは、統合パケットフレームに含まれるユーザデータ、並びに統合パケットフレームに含まれる制御ヘッダ及びアドレス情報（すなわち、アドレス情報パケットフレームの内容）の書込命令をＤＭＡ処理部３７４に対して出力する。ＤＭＡ処理部３７４は、メモリバッファ３７１に格納されたデータ受信用バッファのアドレスを基に、ＤＭＡ転送により、統合パケットフレームに含まれるユーザデータをデータ受信用バッファに書き込む（ステップＳ６７）。また、ＤＭＡ処理部３７４は、ＤＭＡ転送により、統合パケットフレームに含まれる制御ヘッダ及びアドレス情報を受信側ＯＳの内部バッファに書き込む（ステップＳ６９）。そして、元の処理に戻る。
【００７９】
以上のように、本実施の形態によれば、送信側計算機及び受信側計算機のソフトウェアレベルにおいて、ユーザデータのコピーは発生しないので、例えば、大量のユーザデータを送受信する場合でも、コピー処理によるＣＰＵ負荷を最小限に抑えることができ、通信速度の低下を防止することができる。また、従来のユーザプログラム３１及びＯＳ３５をそのまま利用することができ、ＯＳ３５の通信制御機能（例えば、パケット欠損時の再送等）もそのまま利用することができる。すなわち、ソフトウェアレベルでネットワーク上の信頼性が保証されるため、ハードウェアレベルにおいて、ネットワーク上の信頼性を保証する必要はない。
【００８０】
以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で説明した機能ブロック図は必ずしも実際のプログラムモジュール構成に対応するものではない。また、ＯＳ３５は、必ずしもＯＳである必要はなく、ＯＳと同様の方式で通信を制御する専用ライブラリのような場合もある。
【００８１】
また、上で述べた例では、フックライブラリ３３においてアドレス情報を生成等の処理を行うこととしていたが、フックライブラリ３３を用意せず、ユーザプログラム３１やＯＳ３５で行うようにしても良い。ユーザプログラム３１で行う場合には、ユーザプログラム３１の一部を変更する必要があるが、ユーザプログラム３１の主構造やＯＳ３５を変更する必要はない。また、ＯＳ３５で行うには、ＯＳ３５の一部を変更する必要はあるが、ＯＳ３５が有する通信の信頼性保証に関連する処理及びユーザプログラム３１を変更する必要はない。
【００８２】
また、上で説明したアドレス情報パケットフレーム、ゼロコピーパケットフレーム及び統合パケットフレームのフォーマットは一例であって、データ部の内容は、データの並びを変更したり、さらに必要に応じてデータを追加又は削除したりしても良い。例えば、制御ヘッダに、ＩＰヘッダやＴＣＰヘッダを含めないようにしても良い。
【００８３】
また、処理フローにおいても、処理結果が変らなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。
【００８４】
（付記１）
プロセッサと通信装置とを有するコンピュータにより実行される通信制御方法であって、
送信すべきデータを格納する第１バッファのアドレス及び前記送信すべきデータの長さの情報を含むアドレス情報を生成し、第２バッファに格納するアドレス情報生成ステップと、
前記アドレス情報を前記第２バッファから第３バッファにコピーすると共に、第１制御ヘッダを付加し、第１パケットを生成する第１パケット生成ステップと、
前記第１パケットを前記第３バッファから前記通信装置内の第４バッファに前記プロセッサを介さずにコピーするコピー処理ステップと、
前記アドレス情報に基づき、前記送信すべきデータを前記第１バッファから前記第４バッファに前記プロセッサを介さずにコピーすると共に、第２制御ヘッダを付加し、第２パケットを生成する第２パケット生成ステップと、
前記第４バッファに格納された前記第１パケット及び前記第２パケットを送信先端末に送信する送信ステップと、
を含む通信制御方法。
【００８５】
（付記２）
プロセッサと通信装置とを有するコンピュータにより実行される通信制御方法であって、
送信すべきデータを格納する第１バッファのアドレス及び前記送信すべきデータの長さの情報を含むアドレス情報を生成し、第２バッファに格納するアドレス情報生成ステップと、
前記アドレス情報を前記第２バッファから第３バッファにコピーすると共に、第１制御ヘッダを付加し、第１パケットを生成する第１パケット生成ステップと、
前記第１パケットを前記第３バッファから前記通信装置内の第４バッファに前記プロセッサを介さずにコピーするコピー処理ステップと、
前記アドレス情報に基づき、前記第１バッファから前記送信すべきデータを前記プロセッサを介さずに読み出し、前記第４バッファに格納された前記第１パケットの最後尾に付加して、統合パケットを生成する第２パケット生成ステップと、
前記第４バッファに格納された前記統合パケットを送信先端末に送信する送信ステップと、
を含む通信制御方法。
【００８６】
（付記３）
前記コンピュータのオペレーティング・システムに対するデータ送信要求をフックするフック処理ステップ
をさらに含み、
前記フック処理ステップの後に、前記アドレス情報生成ステップを実施する
付記１又は２記載の通信制御方法。
【００８７】
（付記４）
前記第１パケット生成ステップが、前記コンピュータのオペレーティング・システムにより実行される
付記１又は２記載の通信制御方法。
【００８８】
（付記５）
前記オペレーティング・システムにより、前記第１パケットの送信要求を前記通信装置に通知するステップ
をさらに含む付記４記載の通信制御方法。
【００８９】
（付記６）
前記コピー処理ステップ、前記第２パケット生成ステップ及び前記送信ステップが、前記通信装置により実行される
付記１又は２記載の通信制御方法。
【００９０】
（付記７）
前記第２パケット生成ステップが、
前記第１パケットをコピーして前記第２パケットに付加するステップ
を含む付記１記載の通信制御方法。
【００９１】
（付記８）
プロセッサと通信装置とを有するコンピュータにより実行される通信制御方法であって、
送信元端末からパケットを受信し、前記通信装置内の第１バッファに格納する受信ステップと、
受信した前記パケットが、所定のアドレスの情報と前記所定のアドレスの示す領域に格納される特定のデータの長さの情報とを含む第１パケットである場合、当該第１パケットとの対応付けを表す情報と前記特定のデータとを含む第２パケットを既に受信しているか否か判定する第１判定ステップと、
受信した前記パケットが、前記第２パケットである場合、当該第２パケットに対応する前記第１パケットを既に受信しているか否か判定する第２判定ステップと、
前記第１判定ステップにおいて前記第２パケットを既に受信していると判定された場合、又は前記第２判定ステップにおいて前記第２パケットに対応する前記第１パケットを既に受信していると判定された場合、前記第２パケットに含まれる前記特定のデータを前記第１バッファから第２バッファに前記プロセッサを介さずにコピーし、前記第１パケットを前記第１バッファから第３バッファに前記プロセッサを介さずにコピーするコピー処理ステップと、
前記第１パケットに含まれる前記所定のアドレスの情報と前記特定のデータの長さの情報とを前記第３バッファから第４バッファにコピーすると共に、前記第１パケットに対する確認応答を前記送信元端末に送信する応答ステップと、
を含む通信制御方法。
【００９２】
（付記９）
プロセッサと通信装置とを有するコンピュータにより実行される通信制御方法であって、
送信元端末から、所定のアドレスの情報と前記所定のアドレスの示す領域に格納される特定のデータの長さの情報と前記特定のデータとを含む統合パケットを受信し、前記通信装置内の第１バッファに格納する受信ステップと、
前記統合パケットに含まれる前記特定のデータを前記第１バッファから第２バッファに前記プロセッサを介さずにコピーし、前記統合パケットから前記特定のデータを除いたデータを第１パケットとして前記第１バッファから第３バッファに前記プロセッサを介さずにコピーするコピー処理ステップと、
前記第１パケットに含まれる前記所定のアドレスの情報と前記特定のデータの長さの情報とを前記第３バッファから第４バッファにコピーすると共に、前記第１パケットに対する確認応答を前記送信元端末に送信する応答ステップと、
を含む通信制御方法。
【００９３】
（付記１０）
前記コンピュータのオペレーティング・システムに対するデータ受信要求をフックし、前記第２バッファのアドレスを前記通信装置に通知するステップ
をさらに含む付記８又は９記載の通信制御方法。
【００９４】
（付記１１）
前記第４バッファに格納された前記所定のアドレスの情報と前記特定のデータの長さの情報とを破棄するステップ
をさらに含む付記８又は９記載の通信制御方法。
【００９５】
（付記１２）
前記受信ステップ、前記第１判定ステップ、前記第２判定ステップ及び前記コピー処理ステップが、前記通信装置により実行される
付記８記載の通信制御方法。
【００９６】
（付記１３）
前記受信ステップ及び前記コピー処理ステップが、前記通信装置により実行される
付記９記載の通信制御方法。
【００９７】
（付記１４）
前記応答ステップが、前記コンピュータのオペレーティング・システムにより実行される
付記８又は９記載の通信制御方法。
【００９８】
（付記１５）
前記第１パケットとの対応付けを表す情報が、対応する前記第１パケットをコピーした情報である
付記８記載の通信制御方法。
【００９９】
（付記１６）
プロセッサを有するコンピュータに接続される通信装置であって、
送信すべきパケットを格納する記憶装置と、
パケット送信要求を受信した場合に、当該パケット送信要求に係る第１パケットを格納している第１バッファから、前記第１パケットを前記記憶装置に前記プロセッサを介さずにコピーする手段と、
前記記憶装置に格納された前記第１パケットに、特定のデータを格納する第２バッファのアドレスの情報及び前記特定のデータの長さの情報が含まれる場合、前記特定のデータを前記第２バッファから前記記憶装置に前記プロセッサを介さずにコピーする手段と、
前記記憶装置に格納された前記特定のデータに、制御ヘッダを付加して第２パケットを生成するパケット生成手段と、
前記記憶装置に格納された前記第１パケット及び前記第２パケットを送信先端末に送信する手段と、
を有する通信装置。
【０１００】
（付記１７）
プロセッサを有するコンピュータに接続される通信装置であって、
送信すべきパケットを格納する記憶装置と、
パケット送信要求を受信した場合に、当該パケット送信要求に係る第１パケットを格納している第１バッファから、前記第１パケットを前記記憶装置に前記プロセッサを介さずにコピーする手段と、
前記記憶装置に格納された前記第１パケットに、特定のデータを格納する第２バッファのアドレスの情報及び前記特定のデータの長さの情報が含まれる場合、前記特定のデータを前記第２バッファから前記プロセッサを介さずに読み出し、前記記憶装置に格納された前記第１パケットの最後尾に付加して、統合パケットを生成する手段と、
前記記憶装置に格納された前記統合パケットを送信先端末に送信する手段と、
を有する通信装置。
【０１０１】
（付記１８）
前記パケット生成手段が、
前記記憶装置に格納された第１パケットをコピーして前記第２パケットに付加する手段
を有する付記１６記載の通信装置。
【０１０２】
（付記１９）
プロセッサを有するコンピュータに接続される通信装置であって、
受信したパケットを格納する記憶装置と、
送信元端末からパケットを受信し、前記記憶装置に格納する手段と、
受信した前記パケットが、所定のアドレスの情報及び前記所定のアドレスの示す領域に格納される特定のデータの長さの情報を含む第１パケットである場合、当該第１パケットとの対応付けを表す情報及び前記特定のデータを含む第２パケットを既に受信しているか否か判定する第１判定手段と、
受信した前記パケットが、前記第２パケットである場合、当該第２パケットに対応する前記第１パケットを既に受信しているか否か判定する第２判定手段と、
前記第１判定手段により前記第２パケットを既に受信していると判定された場合、又は前記第２判定手段により前記第２パケットに対応する前記第１パケットを既に受信していると判定された場合、前記第２パケットに含まれる前記特定のデータを前記記憶装置から第１バッファに前記プロセッサを介さずにコピーし、前記第１パケットを前記記憶装置から第２バッファに前記プロセッサを介さずにコピーする手段と、
を有する通信装置。
【０１０３】
（付記２０）
プロセッサを有するコンピュータに接続される通信装置であって、
受信したパケットを格納する記憶装置と、
送信元端末から、所定のアドレスの情報、前記所定のアドレスの示す領域に格納される特定のデータの長さの情報及び前記特定のデータを含む統合パケットを受信し、前記記憶装置に格納する手段と、
前記統合パケットに含まれる前記特定のデータを前記記憶装置から第１バッファに前記プロセッサを介さずにコピーし、前記統合パケットから前記特定のデータを除いたデータを第１パケットとして前記記憶装置から第２バッファに前記プロセッサを介さずにコピーする手段と、
を有する通信装置。
【０１０４】
（付記２１）
前記第１バッファのアドレスの情報を受信し、前記記憶装置に格納する手段
をさらに有する付記１９又は２０記載の通信装置。
【図面の簡単な説明】
【０１０５】
【図１】従来のパケット送受信の処理概要を説明するための図である。
【図２】（ａ）及び（ｂ）はイーサネット上で送受信されるパケットフレームのフォーマットの一例を示す図である。
【図３】本発明の実施の形態に係るシステム概要図である。
【図４】本発明の第１の実施の形態におけるＮＩＣの機能ブロック図である。
【図５】本発明の第１の実施の形態におけるパケット送信の処理概要を示す図である。
【図６】アドレス情報パケットフレームのフォーマットの一例を示す図である。
【図７】ゼロコピーパケットフレームのフォーマットの一例を示す図である。
【図８】本発明の第１の実施の形態におけるパケット受信の処理概要を示す図である。
【図９】本発明の第１の実施の形態におけるＮＩＣの送信処理の処理フローを示す図である。
【図１０】本発明の第１の実施の形態におけるＮＩＣの受信処理の処理フローを示す図である。
【図１１】本発明の第２の実施の形態におけるＮＩＣの機能ブロック図である。
【図１２】本発明の第２の実施の形態におけるパケット送信の処理概要を示す図である。
【図１３】統合パケットフレームのフォーマットの一例を示す図である。
【図１４】本発明の第２の実施の形態におけるパケット受信の処理概要を示す図である。
【図１５】本発明の第２の実施の形態におけるＮＩＣの送信処理の処理フローを示す図である。
【図１６】本発明の第２の実施の形態におけるＮＩＣの受信処理の処理フローを示す図である。
【符号の説明】
【０１０６】
１  インターフェース    ３  計算機
３１  ユーザプログラム    ３３  フックライブラリ
３５  ＯＳ    ３７  ＮＩＣ
３７１  メモリバッファ    ３７２  送信判定部
３７３  ゼロコピーパケット構築部    ３７３ｂ  統合パケットフレーム構築部
３７４  ＤＭＡ処理部    ３７５  送信部
３７６  受信部    ３７７  受信判定部
３７８  ゼロコピーパケット処理部    ３７８ｂ  統合パケットフレーム処理部
【図１】
2008148181.tif 000003
【図２】
2008148181.tif 000004
【図３】
2008148181.tif 000005
【図４】
2008148181.tif 000006
【図５】
2008148181.tif 000007
【図６】
2008148181.tif 000008
【図７】
2008148181.tif 000009
【図８】
2008148181.tif 000010
【図９】
2008148181.tif 000011
【図１０】
2008148181.tif 000012
【図１１】
2008148181.tif 000013
【図１２】
2008148181.tif 000014
【図１３】
2008148181.tif 000015
【図１４】
2008148181.tif 000016
【図１５】
2008148181.tif 000017
【図１６】
2008148181.tif 000018