JP2017011580A - 通信装置およびその制御方法、プログラム - Google Patents

Abstract

【課題】高速なデータバッファを効率よく利用可能にして、安定した高速通信を実現する。
【解決手段】第１のデータバッファと、第１のデータバッファよりも高速なアクセスが可能な第２のデータバッファと、を有する通信装置は、送信対象のデータを第２のデータバッファへ転送し、第２のデータバッファに転送された送信対象のデータを用いて送信用データを生成して通信相手装置へ送信し、送信用データが生成または送信された後、通信相手装置からの特定の応答を待たずに第２のデータバッファを解放する。通信装置は、第２のデータバッファが解放された後も送信対象のデータの再送を可能にするために、送信対象のデータまたは送信用データを第１のデータバッファに保持する。
【選択図】図１

Description

本発明は、通信装置およびその制御方法、プログラムに関する。

従来、パケット通信において、通信の信頼性を保障するため、セグメントを受け取った際にＡＣＫと呼ばれる肯定応答を用いる通信方式がある。例えば、インターネット通信において広く利用されているＴＣＰ／ＩＰでは、セグメントをオクテット単位にシーケンス番号で管理し、受け取ったセグメントのシーケンス番号をＡＣＫパケットとして応答する必要がある。なお、ＴＣＰ／ＩＰとは、Transmission Control Protocol/Internet Protocolである。

ＴＣＰ／ＩＰのプロトコル処理では、通信データのパケット化や再送処理のために、ネットワークバッファが用意されている。ＴＣＰ／ＩＰパケットの送信において、ソケットAPIsend()によって指定されたユーザデータがネットワークバッファに転送され、ＭＴＵ（maximum transmission unit：最大伝送単位）に分割される。そして、分割されたデータと擬似ヘッダのチェックサムが計算され、ＴＣＰヘッダとＩＰヘッダが追加されたＴＣＰ／ＩＰパケットが生成される。伝送経路がイーサネット（登録商標）の場合、さらに、イーサネットヘッダが付加されたイーサネットフレームが生成され送信される。

ユーザバッファからネットワークバッファへのデータ転送や、チェックサムの計算において広範囲なメモリアクセスが行われるため、メモリアクセスが遅いとＴＣＰ／ＩＰパケットを高速に生成することができない。ＴＣＰ／ＩＰ通信を高速にするため、ユーザバッファからネットワークバッファへデータ転送する際は、ＣＰＵ転送ではなくＤＭＡ転送の利用や、ネットワークバッファとしてＤＲＡＭの代わりにより高速アクセスが可能なＳＲＡＭの利用が考えられる（特許文献１）。

特開２０１２−１８２５５１号公報

しかしながら、高速アクセス可能なＳＲＡＭは、コストやチップ面積などの制限からメモリサイズを大きくすることができず、そのため充分なネットワークバッファとしてのデータバッファをＳＲＡＭに割り当てることができない。特許文献１では、ネットワークバッファをＤＲＡＭとＳＲＡＭに分割して割り当て、特定のソケットに対してＳＲＡＭに割り当てたネットワークバッファを利用することで、特定のソケットによる送信処理を高速化している。

しかし、ＴＣＰ通信の送信では、プロトコルにおいて、所定時間内に肯定応答を受信できなかった場合に再送が必要なため、肯定応答を受信するまで送信済みパケットデータを解放することができない。肯定応答を受信できない間は、ＳＲＡＭのネットワークバッファを解放できず、空き領域が逼迫してしまう。ＳＲＡＭのネットワークバッファが空いていない場合、新たな送信ではＳＲＡＭが利用できず、ＤＲＡＭを利用することになるため、高速通信の劣化が発生する課題がある。

本発明は上記の課題に鑑みてなされたものであり、高速なデータバッファを効率よく利用可能にして、安定した高速通信を実現することを目的とする。

上記の目的を達成するための本発明の一態様による通信装置は以下の構成を備える。すなわち、
第１のデータバッファと、前記第１のデータバッファよりも高速なアクセスが可能な第２のデータバッファとを有する通信装置であって、
送信対象のデータを前記第２のデータバッファへ転送する第１の転送手段と、
前記第２のデータバッファに転送された前記送信対象のデータを用いて送信用データを生成して通信相手装置へ送信する送信手段と、
前記送信手段により前記送信用データが生成または送信された後、前記通信相手装置からの特定の応答を待たずに前記第２のデータバッファを解放する解放手段と、
前記送信対象のデータの再送を可能にするために、前記送信対象のデータまたは前記送信用データを前記第１のデータバッファに保持させる保持手段と、を備える。

本発明によれば、高速なデータバッファを効率よく利用することが可能になり、安定した高速通信を実現できる。

第１実施形態に係る通信装置の構成を示すブロック図。 第１実施形態によるユーザデータの転送処理を説明する図。 第１実施形態による通信処理を示すフローチャート。 第２実施形態による通信処理におけるデータの転送を説明する図。 第２実施形態による通信処理を示すフローチャート。 第３実施形態による通信処理を示すフローチャート。 第４実施形態による通信処理を示すフローチャート。

以下、添付の図面を参照して、本発明の好適な実施形態のいくつかについて説明する。

＜第１実施形態＞
単一または複数のアプリケーションが、複数コネクションの通信時に、高速アクセスが可能なＳＲＡＭなどの高速メモリに割り当てられたネットワークバッファ（以下、高速バッファ）を使用できなくなることがある。その原因の一つは、肯定応答を必要とする通信では、通信相手装置から肯定応答が受信するまで送信に使用した高速バッファを解放できないことにある。

そこで、第１実施形態の通信装置では、送信対象のデータをネットワークバッファへＤＭＡ転送する際、高速バッファと、ＤＲＡＭなどの通常メモリに割り当てたネットワークバッファ（以下、通常バッファ）の２か所に送信対象のデータを転送する。そして、通信相手装置へのデータの送信と同時に高速バッファを解放し、通常バッファを通信相手装置から肯定応答を受信するまでデータの再送のために確保することで、高速通信が必要なコネクションによる高速バッファの効率的な使用を可能にする。

図１は、第１実施形態の通信装置１００の構成例を示すブロック図である。図１において、ＣＰＵ１０２は、メインメモリであるＤＲＡＭ１０１をワークメモリとして、ＲＯＭ１０３やハードディスク（不図示）などの、プログラム格納部としての記録媒体に格納された各種プログラムを実行する。ＣＰＵ１０２が実行するプログラムにはネットワークドライバが含まれる。ＣＰＵ１０２は、ネットワークドライバの実行により、後述する送信対象のデータをパケット化するデータ処理や肯定応答の受信処理などを含むプロトコル処理の機能を実現する。

メディアアクセス制御モジュール（ＭＡＣ１０７）と物理レイヤモジュール（ＰＨＹ１０８）は、イーサネット（登録商標）１０９などのネットワークを介した通信を行う通信部１１０である。ＣＰＵ１０２は、ネットワークドライバを実行し、ＭＡＣ１０７を制御してデータの送受信を行う。なお、本構成では、イーサネット（登録商標）での構成を示しているが無線ＬＡＮ（Ｗｉ−Ｆｉ）など、ＩＰ通信が可能であれば何でも構わない。

以上の構成は通常の通信装置と同様であるが、本実施形態の通信装置１００は、さらに、通常メモリであるＤＲＡＭ１０１のほかに、通常メモリよりも高速なアクセスが可能な高速メモリとしてＳＲＡＭ１０５を有する。ＤＲＡＭ１０１は通常バッファとしての第１のデータバッファを提供し、ＳＲＡＭ１０５は高速バッファとしての第２のデータバッファを提供する。また、通信装置１００は、高速メモリ転送機能１１１および通常メモリ転送機能１１２を含むデータ転送部１０６を有する。高速メモリ転送機能１１１は、ＤＭＡＣ（Direct Memory Access Controller）により高速メモリ（ＳＲＡＭ１０５）へのデータ転送を行う。通常メモリ転送機能１１２は、ＤＭＡＣにより通常メモリ（ＤＲＡＭ１０１）へのデータ転送を行う。通信装置１００は、さらに、プロトコルにおいて用いられる各種タイマを管理するタイマ管理部１０４を備える。

又、本発明において用いられるパケットは、インターネット上で送受信されるデータの単位である。本発明では発明の本質ではないので、このパケットの組み立て方法については、省略してある。

図３のフローチャートにより第１実施形態のソケットAPI send()によるデータ送信を説明する。最初にステップＳ３０１において、ＣＰＵ１０２が実行するアプリケーション（以下、単にアプリケーションという）は、send()を呼び出す。send()が呼び出されると、ステップＳ３０２において、ＣＰＵ１０２が実行するネットワークドライバはデータ転送部１０６を用いて送信対象のデータであるユーザデータを高速バッファと通常バッファの２か所へ転送する。ここで、高速メモリ転送機能１１１がＤＭＡによりユーザデータを高速バッファへ、通常メモリ転送機能１１２がＤＭＡによりユーザデータを低速バッファへ転送する。

図２は、第１実施形態によるユーザデータの転送を説明する図である。図２において、データ転送部１０６は、ＤＲＡＭ１０１内にあるユーザデータ１をＳＲＡＭ１０５内にある高速バッファ１とＤＲＡＭ１０１内にある通常バッファ１の２か所へ転送する。高速バッファ１に転送されたユーザデータ１は高速にパケットを生成するために使用される。他方、送信対象であるユーザデータ１の再送を可能にするために、ユーザデータ１が通常バッファに保持させている。これにより、高速バッファ１に転送されたユーザデータ１を用いて送信用データであるパケットが生成または送信された後は、ネットワークドライバは通信相手装置からの特定の応答（本実施形態では肯定応答）を待たずに高速バッファ１を解放することができる。

ステップＳ３０３およびＳ３０４において、ネットワークドライバは、高速バッファに転送されたユーザデータを用いて送信用データであるパケットを生成し、通信相手装置へ送信する。まず、ステップＳ３０３において、ネットワークドライバは、高速バッファに転送されたユーザデータを用いてチェックサムを計算してＴＣＰ／ＩＰヘッダを生成し、高速バッファのユーザデータをＴＣＰ／ＩＰパケット化する。さらに、ステップＳ３０４において、ネットワークドライバは、イーサネットヘッダを生成し、ＴＣＰ／ＩＰパケットをイーサネットフレーム化し、イーサネットフレームをＭＡＣ１０７に送信する。イーサネットフレーム化されたＴＣＰ／ＩＰパケットが送信済みになると、ステップＳ３０５において、ネットワークドライバはそのユーザデータを保持していた高速バッファを解放する。たとえば、図２では、ＣＰＵ１０２により実現されるネットワークドライバは、ＳＲＡＭ１０５内の高速バッファ１に転送されたユーザデータ１にＴＣＰ／ＩＰ処理を適用し、ネットワークＩ／Ｆとしての通信部１１０に転送する（ステップＳ３０３〜Ｓ３０４）。その後、ネットワークドライバは、ＳＲＡＭ１０５内の高速バッファ１を解放する（ステップＳ３０５）。なお、高速バッファの解放のタイミングは、送信用データであるパケットが生成された時点であってもよい。

次に、ネットワークドライバは、肯定応答を受信したか否か、通信相手とのコネクションが切断したか否か、パケットの再送のタイミングか否かを判定する。すなわち、ステップＳ３０６において肯定応答を受信したと判定された場合、またはステップＳ３０７においてコネクションが切断したと判定された場合、処理はステップＳ３０９へ進む。他方、肯定応答を受信しなかった場合、及び通信相手とのコネクションが切断していなかった場合、処理はステップＳ３０８へ進む。ステップＳ３０８において、ネットワークドライバは、タイマ管理部１０４が管理する再送タイマがタイムアウトしたか否か（データの再送タイミングか否か）を判定する。再送タイマがタイムアウトしていなければ処理はステップＳ３０６に戻り、再送タイマがタイムアウトしていれば処理はステップＳ３１０へ進む。

ステップＳ３１０において、ネットワークドライバは、ステップＳ３０２においてデータ転送部１０６が通常バッファに転送したユーザデータをＴＣＰ／ＩＰパケット化する。そして、ステップＳ３１１において、ネットワークドライバはイーサネットヘッダを生成し、ＴＣＰ／ＩＰパケットをイーサネット（登録商標）フレーム化し、イーサネットフレームをＭＡＣ１０７に送信する。その後、処理はステップＳ３０６へ戻る。他方、ステップＳ３０６またはステップＳ３０７から処理がステップＳ３０９に進んだ場合は、ＴＣＰ／ＩＰパケットが送信済みとなったことが確認されている。したがって、ステップＳ３１１において、ネットワークドライバはステップＳ３０２においてデータ転送部１０６がユーザデータの転送先に使用した通常バッファを解放する。

図２において、ＣＰＵ１０２は、ＤＲＡＭ１０１内の通常バッファ１に保持されているユーザデータを再送用のデータとして利用する。すなわち、ＣＰＵ１０２は、通常バッファ１に保持されているユーザデータにＴＣＰ／ＩＰ処理を適用してＴＣＰ／ＩＰパケット化、イーサネットパケット化し、通信部１１０に転送する。その後、ネットワークドライバは、ＤＲＡＭ１０１内の通常バッファ１を解放する。

以上のように、第１実施形態の通信装置１００によれば、肯定応答を必要とする通信において、送信対象のデータを高速バッファと通常バッファに保持させる。そして、通信装置１００はまず高速バッファを用いてユーザデータをパケット化して送信し、対応する肯定応答を待たずに、高速バッファを解放する。一方、通信装置１００は、通常バッファに保持されたユーザデータについては、通信相手から肯定応答を受信するまで再送のために保持状態を維持する。以上のように制御することにより、高速通信を必要とするコネクションによる高速バッファを効率的に使用することができる。

具体的には、第１実施形態によれば、送信対象のデータをＳＲＡＭとＤＲＡＭに配置しているネットワークバッファの２か所へＤＭＡ転送することで、ＳＲＡＭに確保したネットワークバッファを送信と同時に解放ができる。そのため、新たな送信対象のデータをＳＲＡＭに配置していているネットワークバッファが利用できる。その結果、メモリサイズが充分に大きくないＳＲＡＭのネットワークバッファを効率良く利用した高速な通信が可能になる。

＜第２実施形態＞
次に第２実施形態の通信処理を説明する。第１実施形態では、送信対象のデータであるユーザデータを高速バッファと低速バッファの両方に転送し、高速バッファを用いてユーザデータを送信して高速バッファを解放し、再送のために低速バッファに保持されたユーザデータを用いるようにした。第２実施形態の通信装置は、送信対象となるユーザデータを高速バッファへ転送し、高速バッファを用いて生成したパケットを通信部１１０から送信するとともに低速バッファに保持させる。こうして、第２実施形態の通信装置は、パケットの送信とともに高速バッファを解放することを可能とする。なお、第２実施形態の通信装置の構成は第１実施形態（図１）と同様である。

図４は、第２実施形態によるユーザデータの転送を説明する図である。また、図５は、第２実施形態の通信装置１００による通信処理を説明するフローチャートである。以下、図４、図５を参照して、第２実施形態のソケットAPI send()によるデータ送信について説明する。

まず、ステップＳ５０１において、ＣＰＵ１０２が実行するアプリケーションは、send()を呼び出す。send()が呼び出されると、ＣＰＵ１０２が実行するネットワークドライバは、ステップＳ５０２で、ユーザデータを高速バッファへ転送する。このステップにおけるデータの転送には、データ転送部１０６（高速メモリ転送機能１１１）によるデータ転送、ＣＰＵ１０２によるデータ転送のいずれが用いられてもよい。図４で説明すると、データ転送部１０６（或いはＣＰＵ１０２）は、ＤＲＡＭ１０１内にあるユーザデータ１をＳＲＡＭ１０５内にある高速バッファ１へ転送する。

ステップＳ５０３において、ネットワークドライバは、高速バッファに保持されたユーザデータのチェックサムを計算してＴＣＰ／ＩＰヘッダを生成し、高速バッファ上でユーザデータをＴＣＰ／ＩＰパケット化する。さらに、ステップＳ５０４において、ネットワークドライバは、イーサネットヘッダを生成し、高速バッファ上でＴＣＰ／ＩＰパケットをイーサネットフレーム化する。ステップＳ５０５において、ネットワークドライバは、データ転送部１０６（通常メモリ転送機能１１２）を用いて、高速バッファにあるイーサネットフレーム化されたＴＣＰ／ＩＰパケットを、ＭＡＣ１０７とＤＲＡＭ１０１内の通常バッファの２か所へ転送する。ステップＳ５０６において、ネットワークドライバは、ＴＣＰ／ＩＰパケットが送信済みのため、対応するユーザデータを保持していた高速バッファを解放する。

以上の処理を図４により説明する。ネットワークドライバは、ＳＲＡＭ１０５内の高速バッファ１が保持しているユーザデータにＴＣＰ／ＩＰ処理やイーサネットフレーム化処理を適用してパケットを生成する（ステップＳ５０３、Ｓ５０４）。データ転送部１０６は、生成されたパケットをネットワークＩ／Ｆとしての通信部１１０と、ＤＲＡＭ１０１内にある通常バッファ１の２箇所へデータ転送する（ステップＳ５０５）。その後、ネットワークドライバは、ＳＲＡＭ１０５内にある高速バッファ１を解放する（ステップＳ５０６）。

次に、ネットワークドライバは、肯定応答を受信したか否か、通信相手とのコネクションが切断したか否か、パケットの再送のタイミングか否かを判定する。すなわち、ステップＳ５０７において肯定応答を受信したと判定された場合、またはステップＳ５０８においてコネクションが切断したと判定された場合、処理はステップＳ５１０へ進む。他方、肯定応答を受信しなかった場合、及び通信相手とのコネクションが切断していなかった場合、処理はステップＳ５０９へ進む。ステップＳ５０９において、ネットワークドライバは、タイマ管理部１０４が管理する再送タイマがタイムアウトしたか否か（データの再送タイミングか否か）を判定する。再送タイマがタイムアウトしていなければ処理はステップＳ５０７に戻り、再送タイマがタイムアウトしていれば処理はステップＳ５１１へ進む。

ステップＳ５１１において、ネットワークドライバは、ステップＳ５０５においてデータ転送部１０６がＤＲＡＭ１０１内の通常バッファに転送したＴＣＰ／ＩＰパケットを送信用データとして取得し、ＭＡＣ１０７に送信することにより、パケットを再送する。再送の実行後、処理はステップＳ５０７へ戻る。ステップＳ５１０では、データの送信が完了したことが確認されているため、ステップＳ５０５においてデータ転送部１０６がＴＣＰ／ＩＰパケットのデータ転送先に使用したＤＲＡＭ１０１内の通常バッファを解放する。

図４においては、ＤＲＡＭ１０１内の通常バッファ１が再送時のデータのために利用されている。肯定応答を受信する前に再送タイマがタイムアウトすると、ＣＰＵ１０２（ネットワークドライバ）は、通常バッファ１に保持されているパケット（本実施形態ではイーサネットフレーム）をネットワークＩ／Ｆとしての通信部１１０に転送する。その後、肯定応答が確認されると、ＣＰＵ１０２は、ＤＲＡＭ１０１内にある通常バッファ１を解放する（ステップＳ５１０）。

以上のように、第２実施形態によれば、肯定応答の確認を必要とする通信プロトコルにおいて、通信相手への送信と同時に高速バッファが解放され、通信相手から肯定応答を受信するまで再送のために通常バッファにデータが確保される。したがって、高速通信を必要とするコネクションによる高速バッファを効率的に使用することができる。

＜第３実施形態＞
次に、第３実施形態の通信処理を説明する。第３実施形態では、高速バッファと通常バッファを併用した通信を行うか、高速バッファを用いずに通常バッファを用いた通信を行うかを自動的に判定して通信処理を切り換える構成について説明する。なお、第３実施形態の通信装置は、第１実施形態および第２実施形態と同様の構成（図１）を備えている。

図６は第３実施形態の通信装置１００による通信処理を示すフローチャートである。以下、図６を参照して第３実施形態の通信装置のソケットAPI send()によるデータ送信を説明する。まず、ステップＳ６０１において、ＣＰＵ１０２が実行するアプリケーションは、send()を呼び出す。send()が呼び出されると、ステップＳ６０２において、ＣＰＵ１０２が実行するネットワークドライバは、通信処理において高速バッファを利用するか否かを判定する。たとえば、コネクションが高速な通信を行っていると判定した場合には、高速バッファを利用すると判定される。たとえば、ネットワークドライバは、肯定応答（ＡＣＫ）の受信間隔を計測することによってコネクションの通信速度（ＲＴＴ：往復遅延時間）を推定し、この通信速度が所定値を超えるか否かにより、コネクションが高速な通信を行なっているか否かを判定する。そして、コネクションが高速な通信を行なっている場合には高速バッファを使用すると判定される。

コネクションが高速な通信を行なっていると判定された場合（高速バッファを使用すると判定された場合）、処理はステップＳ６０３に進む。また、コネクションが高速な通信を行っていないと判定された場合（高速バッファを使用しないと判定された場合）、処理はステップ６１０に進む。なお、高速な通信か否かの判定は、肯定応答（ＡＣＫ）の受信間隔が所定の判定時間を超えるか否かにより行うことができる。本実施形態では、図１に示すタイマ管理部１０４が、各コネクションについてデータ（パケット）の送信からの経過時間をカウントする。タイマ管理部１０４は、判定時間が経過すると、対応するコネクションに関して判定時間の経過を示す信号をＣＰＵ１０２（が実行するネットワークドライバ）に発行する。ネットワークドライバは、判定時間の経過を示す信号を受け取る前に肯定応答を受信していれば高速な通信と判定する。

ステップＳ６０２において高速バッファを使用すると判定されると、高速バッファと通常バッファを併用した通信処理を実行するべく処理はステップＳ３０２へ進む。ステップＳ３０２〜Ｓ３１１の処理は第１実施形態（図３）で説明したとおりである。一方、高速な通信ではないと判定されると、高速バッファへの送信対象のデータの転送は行われず、処理はステップＳ６０２からステップＳ６１０へ進む。すなわち、高速バッファへの送信対象のデータの転送は禁止される。

ステップＳ６１０において、ネットワークドライバは、送信対象のデータであるユーザデータをＤＲＡＭ１０１内の通常バッファへ転送する。このデータ転送は、データ転送部１０６画実行してもよいし、ＣＰＵ１０２が実行してもよい。次に、ステップＳ６１１において、ネットワークドライバは通常バッファへ転送されたユーザデータを用いてチェックサムを計算してＴＣＰ／ＩＰヘッダを生成し、通常バッファ上でユーザデータをＴＣＰ／ＩＰパケット化する。さらに、ステップＳ６６１２において、ネットワークドライバは、イーサネットヘッダを生成して、通常バッファ上でＴＣＰ／ＩＰパケットをイーサネットフレーム化し、得られたイーサネットフレームをＭＡＣ１０７に送信する。その後、処理はステップＳ３０６へ進む。

以上のように、第３実施形態によれば、高速な通信を行っているコネクションであると判断した場合には、高速バッファと通常バッファを使用した通信（図６のステップＳ３０２〜Ｓ３１１）が実行される。他方、低速な通信を行なっているコネクションであると判断した場合には、高速バッファを用いず、通常バッファを使用した通信が実行される(図６のステップＳ６１０〜Ｓ６１２、Ｓ３０６〜Ｓ３１１)。通信速度に応じた高速バッファの利用が実現されるので、さらに高速バッファを効率的に使用することができる。

なお、上記実施形態では、高速バッファを使用するか否か（ステップＳ６０２）を、通信速度が高速か否かに基づいて（往復遅延時間に基づいて）切り替える例を説明したが、本発明はこれに限られるものではない。たとえば、以下に示す方法、またはそれら方法のうちのいくつかの組み合わせによって、高速バッファを使用するか否かを判定するようにしてもよい。なお、以下の（１）、（２）、（３）、（６）では、これからユーザデータの送信のために生成されることになるパケットについて判定を行う。ステップＳ６０２における判定処理はユーザデータをパケット化する前に実行されるからである。

（１）ステップＳ６０２において、パケットの属性の一つである宛先アドレスを調べ、これが所定のアドレスに合致する場合に高速バッファを使用すると判定する。宛先アドレスとしては、ＩＰアドレスを用いることができる。こうすれば、特定の通信相手に対して高速な通信を行うことができる。
（２）ステップＳ６０２において、パケットの属性に含まれる宛先ポートまたは送信元ポートを調べ、宛先ポートまたは送信元ポートが所定のポート番号に合致する場合は高速バッファを使用すると判定する。特定の通信プロトコルに対して所定のポート番号が割り当てられていることが多いので、この方法によれば、特定の通信プロトコルを用いる通信の場合に高速な通信を行うようになる。たとえば特定の通信プロトコルがＴＣＰの場合は、ＴＣＰ通信のみが高速な通信を行うことができる構成となる。
（３）ステップＳ６０２において、パケットの属性に含まれる宛先ポートおよび送信元ポートを調べ、宛先ポートおよび送信元ポートの組み合わせが所定のポート番号の組み合わせに合致する場合は高速バッファを使用すると判定する。こうすれば、特定のコネクションについて高速な通信を行うことができる。
（４）ステップＳ６０２において、ユーザデータの送信に用いられるコネクションにおけるパケットのロス率を調べ、パケットのロス率が所定の閾値を超えない場合に高速バッファを使用すると判定する。こうすれば、パケットのロス率が少ない環境においてユーザデータを送信する場合に高速な通信を実現することができる。
（５）ステップＳ６０２において、ソケットAPI send()を呼び出した際の送信対象であるユーザデータのデータサイズを判定し、データサイズが所定の閾値を超える場合は高速バッファを使用すると判定する。こうすれば、大きなデータを送信する際に高速な通信を行うことができる。
（６）ステップＳ６０２において、パケットのデータ種別を判定し、所定のデータ種別に合致する場合は高速バッファを使用すると判定する。こうすれば、特定のデータについて高速な通信を行うことができる。例えば、ＲＴＰ（Real-time Transport Protocol）の場合、特定のペイロード形式のみに高速な通信を適用するように構成することができる。
（７）また、ステップＳ６０２において、高速バッファに枯渇が発生している（高速バッファの空き領域が逼迫している）かどうかを判定し、高速バッファに枯渇が発生していない場合に高速バッファを使用すると判定する。たとえば、高速バッファの空き容量が所定値を超える場合に高速バッファを使用すると判定される。

＜第４実施形態＞
次に、第４実施形態の通信処理を説明する。第１実施形態では、データを再送するごとにＴＣＰ／ＩＰパケットのパケットヘッダを生成する（ステップＳ３１０）がこれに限られるものではない。第４実施形態では、送信対象であるユーザデータに基づいて生成された送信用データが、ユーザデータと該ユーザデータに基づいて生成されたヘッダ部とを含む場合に、ヘッダ部を通常バッファに保持しておき、ユーザデータの再送時に再利用できるようにする。すなわち、第４実施形態では、生成したＴＣＰ／ＩＰパケットのパケットヘッダの再利用を可能にする構成を説明する。なお、第４実施形態の通信装置の構成は、第１実施形態（図１）と同様である。以下、図７のフローチャートにより第４実施形態のソケットAPI send()によるデータ送信を説明する。

最初にステップＳ７０１において、ＣＰＵ１０２が実行するアプリケーションは、send()を呼び出す。send()が呼び出されると、ステップＳ７０２において、ＣＰＵ１０２が実行するネットワークドライバは、データ転送部１０６を用いて送信対象のデータであるユーザデータを高速バッファと通常バッファの２か所へ転送する。

ステップＳ７０３において、ネットワークドライバは、高速バッファに保持されているユーザデータを用いてチェックサムを計算し、通常バッファにパケットヘッダを生成する。その後、ネットワークドライバは、通常バッファに生成したパケットヘッダと高速バッファに保持されているユーザデータとを連結し、ユーザデータをＴＣＰ／ＩＰパケット化する。さらに、ステップＳ７０４において、ネットワークドライバは、イーサネットヘッダを生成し、ＴＣＰ／ＩＰパケットをイーサネットフレーム化し、得られたイーサネットフレームをＭＡＣ１０７に送信する。ステップＳ７０５では、イーサネットフレーム化されたＴＣＰ／ＩＰパケットが送信済みとなるので、高速バッファを解放する。

次に、ネットワークドライバは、肯定応答を受信したか否か、通信相手とのコネクションが切断したか否か、パケットの再送のタイミングか否かを判定する。すなわち、ステップＳ７０６において肯定応答を受信したと判定された場合、またはステップＳ７０７においてコネクションが切断したと判定された場合、処理はステップＳ７０９へ進む。他方、肯定応答を受信しなかった場合、及び通信相手とのコネクションが切断していなかった場合、処理はステップＳ７０８へ進む。ステップＳ７０８において、ネットワークドライバは、タイマ管理部１０４が管理する再送タイマがタイムアウトしたか否か（データの再送タイミングか否か）を判定する。再送タイマがタイムアウトしていなければ処理はステップＳ７０６に戻り、再送タイマがタイムアウトしていれば処理はステップＳ７１０へ進む。

ステップＳ７１０において、ネットワークドライバは、ＤＲＡＭ１０１内の通常バッファに生成したパケットヘッダ（ステップＳ７０３）と、データ転送部１０６が通常バッファに転送したユーザデータ（ステップＳ７０２）とを連結する。これにより、通常バッファに保持されているユーザデータがＴＣＰ／ＩＰパケット化される。ステップＳ７１１において、ネットワークドライバは、イーサネットヘッダを生成し、ステップＳ７１０で生成されたＴＣＰ／ＩＰパケットをイーサネットフレーム化し、得られたイーサネットフレームをＭＡＣ１０７に送信する。その後、処理はステップＳ７０６へ戻る。他方、ステップＳ７０９において、ネットワークドライバは、ステップＳ７０３においてパケットヘッダの生成に使用した通常バッファとステップＳ７０２においてデータ転送部１０６がユーザデータのデータ転送先に使用した通常バッファを解放する。

以上のように、第４実施形態によれば、肯定応答を必要とする通信において、再利用できるパケットヘッダが通常バッファへ生成される。したがって、第１実施形態に比べて、データ再送時におけるパケットの生成が高速化される。なお、第４実施形態においても、高速バッファは通信相手への送信と同時に、肯定応答の受信を待たずに解放され、通常バッファは再送のために通信相手から肯定応答を受信するまで確保される。したがって、高速通信を行うコネクションによる高速バッファの効率的な使用が実現される。

なお、上記各実施形態では、ＴＣＰ／ＩＰプロトコルを例に挙げたが、これに限られるものではない。例えば、ＵＤＰプロトコルなど、データの送信後に肯定応答が確認されるまで再送を行うことが要求されるプロトコルに好適に適用することができる。

また、本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０１：ＤＲＡＭ、１０２：ＣＰＵ、１０３：ＲＯＭ、１０４：タイマ管理部、１０５：ＳＲＡＭ、１０６：データ転送部、１０７：ＭＡＣ、１０８：ＰＨＹ、１０９：イーサネット（登録商標）、１１０：通信部

Claims (18)

1. 第１のデータバッファと、前記第１のデータバッファよりも高速なアクセスが可能な第２のデータバッファとを有する通信装置であって、
   送信対象のデータを前記第２のデータバッファへ転送する第１の転送手段と、
   前記第２のデータバッファに転送された前記送信対象のデータを用いて送信用データを生成して通信相手装置へ送信する送信手段と、
   前記送信手段により前記送信用データが生成または送信された後、前記通信相手装置からの特定の応答を待たずに前記第２のデータバッファを解放する解放手段と、
   前記送信対象のデータの再送を可能にするために、前記送信対象のデータまたは前記送信用データを前記第１のデータバッファに保持させる保持手段と、を備えることを特徴とする通信装置。
2. 前記特定の応答を待つ間に、前記第１のデータバッファが保持している前記送信対象のデータまたは前記送信用データを用いて、前記送信対象のデータを前記通信相手装置へ再送する再送手段をさらに備えることを特徴とする請求項１に記載の通信装置。
3. 前記保持手段は、前記送信対象のデータを前記第１のデータバッファに転送する第２の転送手段を含み、
   前記再送手段は、前記第１のデータバッファに転送された前記送信対象のデータを用いて再送のための送信用データを生成し、送信することを特徴とする請求項２に記載の通信装置。
4. 前記保持手段は、前記送信用データを前記第１のデータバッファに転送する第２の転送手段を含み、
   前記再送手段は、前記第１のデータバッファから前記送信用データを取得して再送することを特徴とする請求項２に記載の通信装置。
5. 前記第２のデータバッファを使用するか否かを判定する判定手段をさらに備え、
   前記第２のデータバッファを使用しないと判定された場合には、
   前記第１の転送手段による前記送信対象のデータの転送を禁止し、
   前記送信手段は、前記第２の転送手段により前記第１のデータバッファに転送された前記送信対象のデータを用いて送信用データを生成する、ことを特徴とする請求項３に記載の通信装置。
6. 前記判定手段は、前記送信対象のデータを送信するコネクションの通信速度に基づいて前記第２のデータバッファを使用するか否かを判定することを特徴とする請求項５に記載の通信装置。
7. 前記判定手段は、前記送信対象のデータの宛先ポートおよび／または送信元ポートのポート番号に基づいて、前記第２のデータバッファを使用するか否かを判定することを特徴とする請求項５または６に記載の通信装置。
8. 前記判定手段は、前記送信対象のデータの宛先アドレスに基づいて、前記第２のデータバッファを使用するか否かを判定することを特徴とする請求項５乃至７のいずれか１項に記載の通信装置。
9. 前記判定手段は、前記送信対象のデータのコネクションにおけるパケットのロス率に基づいて、前記第２のデータバッファを使用するか否かを判定することを特徴とする請求項５乃至８のいずれか１項に記載の通信装置。
10. 前記判定手段は、前記送信対象のデータのデータサイズに基づいて、前記第２のデータバッファを使用するか否かを判定することを特徴とする請求項５乃至９のいずれか１項に記載の通信装置。
11. 前記判定手段は、前記送信用データとしてのパケットのデータ種別に基づいて、前記第２のデータバッファを使用するか否かを判定することを特徴とする請求項５乃至１０のいずれか１項に記載の通信装置。
12. 前記判定手段は、前記第２のデータバッファの空き容量に基づいて、前記第２のデータバッファを使用するか否かを判定することを特徴とする請求項５乃至１１のいずれか１項に記載の通信装置。
13. 前記送信手段が送信する前記送信用データは、前記送信対象のデータと該送信対象のデータに基づいて生成されたヘッダ部とを含み、
    前記ヘッダ部は前記第１のデータバッファに保持され、
    前記再送手段は、前記第１のデータバッファに保持されている前記ヘッダ部と前記送信対象のデータを用いて前記再送のための送信用データを生成することを特徴とする請求項３に記載の通信装置。
14. 前記解放手段は、さらに、前記特定の応答の受信に応じて前記第１のデータバッファを解放することを特徴とする請求項１乃至１３のいずれか１項に記載の通信装置。
15. 前記送信用データは、前記送信対象のデータをパケット化した得られるパケットであることを特徴とする請求項１乃至１４のいずれか１項に記載の通信装置。
16. 前記第１のデータバッファはＤＲＡＭにより構成され、前記第２のデータバッファはＳＲＡＭにより構成されることを特徴とする請求項１乃至１５のいずれか１項に記載の通信装置。
17. 第１のデータバッファと、前記第１のデータバッファよりも高速なアクセスが可能な第２のデータバッファとを有する通信装置の制御方法であって、
    送信対象のデータを前記第２のデータバッファへ転送する第１の転送工程と、
    前記第２のデータバッファに転送された前記送信対象のデータを用いて送信用データを生成して通信相手装置へ送信する送信工程と、
    前記送信工程で前記送信用データが生成または送信された後、前記通信相手装置からの特定の応答を待たずに前記第２のデータバッファを解放する解放工程と、
    前記送信対象のデータの再送を可能にするために、前記送信対象のデータまたは前記送信用データを前記第１のデータバッファに保持させる保持工程と、を有することを特徴とする通信装置の制御方法。
18. コンピュータを、請求項１乃至１６のいずれか１項に記載された通信装置の各手段として機能させるためのプログラム。

Images