JP6351363B2 - 通信装置およびそのデータ処理方法 - Google Patents

Description

本発明は、データ通信を行うためのプロトコル処理に関する。

インターネット通信に用いられる主要なプロトコルにTCP/IPがあり、TCP/IPを使用するプログラムを作成するためにソケットAPIが定義されている。また、TCP/IPのプロトコル処理における通信データのパケット化や再送処理のために、ネットワークバッファが用意されている。

TCP/IPパケットの送信において、ソケットAPI send()によって指定されたユーザデータがネットワークバッファにコピーされる。ネットワークバッファにコピーされたデータは、MTU（maximum transmission unit、最大伝送単位）に分割されて、複数のセグメントになる。そして、各セグメントとチェックサムのための擬似ヘッダのチェックサムが計算され、TCPヘッダとIPヘッダが追加されたTCP/IPパケットが生成される。伝送経路がEthernet（登録商標）の場合、さらに、Ethernet（登録商標）ヘッダが付加されたEthernet（登録商標）フレームが生成され送信される。

ユーザバッファからネットワークバッファへのデータコピーや、チェックサムの計算において広範囲なメモリアクセスが行われるため、メモリアクセスが遅いとTCP/IPパケットを高速に生成することができない。TCP/IPパケットの高速生成のために、ネットワークバッファとして、DRAMの代わりに、より高速アクセスが可能なSRAMの利用が考えられる。

特開2009-020684号公報

しかし、コストやチップ面積などの制限から、SRAMのメモリサイズを充分に大きくすることができず、充分なネットワークバッファをSRAMに割り当てることができない。

本発明は、高速な通信を必要とするコネクションが、優先的に、高速メモリに割り当てられたネットワークバッファを利用可能にすることを目的とする。

本発明は、前記の目的を達成する一手段として、以下の構成を備える。

本発明のある観点にかかる通信装置は、第一のメモリと、前記第一のメモリよりも高速アクセスが可能な第二のメモリと、送信データの通信プロトコルがTCPであるかUDPであるかを判定する判定手段と、前記判定手段により前記送信データの通信プロトコルがTCPであると判定された場合、前記第二のメモリをネットワークバッファとして使用して、当該送信データをパケット化し、前記判定手段により前記送信データの通信プロトコルがUDPであると判定された場合、前記第一のメモリをネットワークバッファとして使用して、当該送信データをパケット化するプロトコル処理手段と、を有し、前記プロトコル処理手段は、前記判定手段により前記送信データの通信プロトコルがTCPであると判定された場合であっても、前記第二のメモリにおいて利用可能なネットワークバッファの容量が所定の量よりも不足している場合、前記第一のメモリをネットワークバッファとして使用して、当該送信データをパケット化する。
また、本発明の別の観点にかかる通信装置は、第一のメモリと、前記第一のメモリよりも高速アクセスが可能な第二のメモリと、ネットワークバッファとして、前記第一のメモリに割り当てた汎用バッファおよび前記第二のメモリに割り当てた高速バッファを使用して送信データをパケット化するプロトコル処理手段とを有し、前記プロトコル処理手段は、送信データの前記パケット化に前記高速バッファを使用する指示を受信すると、前記送信データの通信に関するコネクションを管理する管理情報に前記高速バッファの使用フラグをセットし、前記指示は、ソケットアプリケーションプログラミングインタフェイスを利用して行われる。

本発明によれば、高速な通信を必要とするコネクションによる、高速メモリに割り当てられたネットワークバッファの優先的利用が可能になる。

実施例の通信機器の構成例を示すブロック図。 コネクション管理構造体を説明する図。 高速バッファを使用する場合の指示方法を示すフローチャート。 実施例1のソケットAPI send()によるデータ送信を説明するフローチャート。 高速バッファへのユーザデータのコピーを説明する図。 汎用バッファへのユーザデータのコピーを説明する図。 TCP/IPパケット化を説明する図。 実施例2のソケットAPI send()によるデータ送信を説明するフローチャート。 実施例3のACK受信時の処理を説明するフローチャート。 実施例3においてタイマ管理部が判定時間の経過を示す信号を発行した場合の処理を説明するフローチャート。 実施例3のソケットAPI send()によるデータ送信を説明するフローチャート。 実施例3と実施例2を組み合わせた場合のソケットAPI send()によるデータ送信を説明するフローチャート。 実施例4においてタイマ管理部が登録時間超過を示す信号を発行した場合の処理を説明するフローチャート。 実施例5のソケットAPI send()によるデータ送信を説明するフローチャート。 実施例6のソケットAPI send()によるデータ送信を説明するフローチャート。 ネットワークバッファの割当処理の詳細を説明するフローチャート。

以下、本発明にかかる実施例の通信処理を図面を参照して詳細に説明する。

［概要］
すべてのネットワークバッファを高速アクセスが可能なSRAMなどのメモリ（以下、高速メモリ）に割り当てられない原因の一つは、単一または複数のアプリケーションが、同時に、複数のコネクションの通信を行うことにある。そこで、高速な通信を必要としないコネクションは、通常のDRAMなどのメモリ（以下、汎用メモリ）に割り当てられたネットワークバッファ（以下、汎用バッファ）を使用するようにする。そして、高速な通信を必要とするコネクションによる、高速メモリに割り当てられたネットワークバッファ（以下、高速バッファ）の優先的利用を可能にする。

実施例においては、高速バッファを使うか、汎用バッファを使うかを、コネクションごとに指定可能にする。そして、コネクションのうち、特定のコネクションのみが高速バッファを使用するようにする。

また、実施例においては、コネクションを指定するほか、例えば、パケットの属性などを指定して、指定属性に合致するパケットのみ高速バッファを使用するようにする。

また、実施例においては、高速バッファを使用するTCPのコネクションの肯定応答(ACK)を監視する。そして、ACKの受信間隔が長い（通信速度が遅い）コネクションによる高速バッファの使用を禁止する。あるいは、所定時間内にACKを受信しなかった場合、当該コネクションが使用していた高速バッファのデータを汎用バッファにコピーして、高速バッファを解放する。

［装置の構成］
図1のブロック図により実施例の通信機器の構成例を示す。CPU102は、メインメモリであるDRAM103をワークメモリとして、ROM107や図示しないハードディスクドライブ(HDD)やソリッドステートドライブ(SSD)などの不揮発性メモリ109に格納された各種プログラムを実行する。CPU102が実行するプログラムにはネットワークドライバが含まれ、ネットワークドライバの実行により後述する送信データをパケット化するデータ処理やACKの受信処理などを含むプロトコル処理の機能が実現される。

メディアアクセス制御モジュール(MAC)104と物理レイヤモジュール(PHY)105は、Ethernet（登録商標）108などのネットワークを介した通信を行う通信部である。CPU102は、ネットワークドライバを実行し、MAC104を制御してデータの送受信を行う。

以上の構成は通常の通信装置と同様である。実施例の通信装置は、さらに、汎用メモリであるダイナミックランダムアクセスメモリ(DRAM)103のほかに高速メモリとしてスタティックランダムアクセスメモリ(SRAM)101と、後述するタイマ管理部106を備える。

［コネクション管理構造体］
図2によりコネクション管理構造体を説明する。DRAM103に割り当てられたコネクション管理構造体301は、各種情報を格納し、TCPなどのコネクションを管理するための構造体（管理情報）である。格納情報には次の情報が含まれる。宛先のIPアドレス(foreign IP address)とポート番号(foreign port number)、自分のIPアドレス(local IP address)とポート番号(local port number)、TCPステート、相手のウィンドウサイズ、送受信バッファサイズ、付加的な情報を追加するためのフラグなどである。

ソケット記述子(sd)302は、ソケットアプリケーションプログラミングインタフェイス（ソケットAPI）socket()の返り値として得られる情報である。つまり、ソケットAPI socket()を呼び出すと、コネクション管理構造体301が獲得され、sd302と対応付けされる。

図3のフローチャートにより高速バッファを使用する場合の指示方法を示す。CPU102が実行するアプリケーションは、高速バッファを使用する場合、ソケット記述子sdとフラグSO_FASTRAMを指定したソケットAPI setsockopt()を呼び出す(S401)。setsockopt()が呼び出されると、ネットワークドライバは、ソケット記述子sdに対応するコネクション管理構造体に、高速バッファの使用を示す使用フラグSO_FASTRAMをセットする(S402)。

［データ送信］
図4のフローチャートにより実施例1のソケットAPI send()によるデータ送信を説明する。CPU102が実行するアプリケーションは、ソケット記述子sdを指定したsend()を呼び出す(S501)。send()が呼び出されると、ネットワークドライバは、ソケット記述子sdに対応するコネクション管理構造体にフラグSO_FASTRAMがセットされているか否かを判定する(S502)。

ソケット記述子sdに対応するコネクション管理構造体に当該フラグがセットされている場合、ネットワークドライバは、ユーザデータをSRAM101に割り当てた高速バッファにコピーする(S503)。また、当該フラグが未セットの場合、ネットワークドライバは、ユーザデータをDRAM103に割り当てた汎用バッファにコピーする(S504)。

次に、ネットワークドライバは、TCPヘッダを生成するためにチェックサムを計算してTCP/IPヘッダを生成し、ユーザデータをTCP/IPパケット化する(S505)。さらに、Ethernet（登録商標）ヘッダを生成し、TCP/IPパケットをEthernet（登録商標）フレーム化し、Ethernet（登録商標）フレームをMAC104に送信する(S506)。

図5により高速バッファへのユーザデータのコピー(S503)を説明する。この例では、SRAM101に割り当てられた各ネットワークバッファ602のサイズは固定であるが、ネットワークバッファ602を複数使用することで大きなデータサイズのユーザデータを扱うことができる。

ソケットAPI send()は次の形式で呼び出される。
send(int sd, const void *buf, size_t buflen, int flags)；
ここで、sdはソケット記述子、
bufは送信データの先頭のポインタ、
buflenは送信データサイズ。

ソケットAPI send()が呼び出されると、ポインタbufが指定するアドレスから始まる、データサイズbuflenのユーザデータがネットワークバッファ602にコピーされる。一つのネットワークバッファ602では不足する場合、さらにネットワークバッファ602が使用される。図5の例では、二つのネットワークバッファ602が使用されている。また、ネットワークバッファ602の先頭にあるバッファ管理ヘッダは、図に破線矢印で示す、ネットワークバッファ602内のユーザデータの先頭と末尾をポイントするポインタを格納する。

図6により汎用バッファへのユーザデータのコピー(S504)を説明する。この場合、ソケットAPI send()で指定されたユーザデータは、DRAM103に割り当てられたネットワークバッファ702にコピーされる。また、ネットワークバッファ702の先頭にあるバッファ管理ヘッダは、図に破線矢印で示す、ネットワークバッファ702内のユーザデータの先頭と末尾をポイントするポインタを格納する。図6には、TCP/IPヘッダを格納するためのヘッダ用バッファ705と、パケット管理構造体706を示すが、これらに関しては後述する。

なお、ステップS503においてネットワークバッファ602が不足する場合、ネットワークバッファ602に空きができるまで待つ方法と、DRAM103に割り当てられたネットワークバッファ702を使用する方法が考えられる。

図7によりTCP/IPパケット化(S505)を説明する。TCP/IPパケット化において、ネットワークバッファ602（または702）のユーザデータはパケット単位に分割され、TCPヘッダ、IPヘッダが付加される。

ネットワークドライバは、DRAM103に、パケット管理構造体706、および、TCPヘッダとIPヘッダを格納するヘッダ用バッファ705を割り当てる。そして、TCPヘッダで使用するチェックサムを計算し、生成したTCPヘッダとIPヘッダをヘッダ用バッファ705に格納する。

パケット管理構造体706は、ヘッダ用バッファ705と複数のネットワークバッファ602（または702）を管理するための構造体である。パケット管理構造体706は、実線矢印で示すポインタのチェインで管理され、チェインされたパケット管理構造体706が指すデータが一つのパケットとして扱われる。また、パケット管理構造体706は、破線矢印で示すデータへのポインタとデータサイズを格納し、これによりパケット管理構造体706は一連のデータを指す。

図7はユーザデータが二分割された例を示す。図7(a)は一つ目のパケットを示し、パケット管理構造体706aはヘッダ用バッファ705のTCP/IPヘッダを指し、パケット管理構造体706bは一つ目のネットワークバッファの先頭から途中の一部のユーザデータを指す。これらデータから一つ目のパケットが生成される。

図7(b)は二つ目のパケットを示す。パケット管理構造体706cはヘッダ用バッファ705のTCP/IPヘッダを指し、パケット管理構造体706dと706dはそれぞれ一つ目のネットワークバッファの残りのユーザデータと二つ目のネットワークバッファのユーザデータを指す。これらデータから二つ目のパケットが生成される。

このように、高速な通信を必要とするコネクションの場合、ソケットAPI setsockopt()によってコネクション管理構造体にフラグSO_FASTRAMを設定する。続いて、ソケットAPI send()が呼び出されると、ソケット記述子sdに対応するコネクション管理構造体にフラグSO_FASTRAMがセットされているかに応じて、高速バッファを使用するか、汎用バッファを使用するかが判定される。

従って、高速バッファの使用が設定されている場合、ユーザデータのネットワークバッファへのコピーと、TCPヘッダに格納するチェックサムの計算が高速化され、高速な通信を行うことができる。また、高速な通信を必要としないコネクションには、汎用バッファが使用され、高速メモリに割り当てられた限られたネットワークバッファを効率的に使用することができる。

［ネットワークバッファの切替方法］
上記では、高速バッファを使うか、汎用バッファを使うかをソケット記述子sdごとに指定し、ステップS502の判定により、使用するネットワークバッファを切り替える例を説明した。しかし、これに限らず、次の方法によってネットワークバッファを切り替えることができる。

ステップS502において、ソケットAPI send()を呼び出したアプリケーションタスクの実行優先順位を調べ、所定の優先順位以上のタスクの場合は高速バッファが使用可能とする。こうすれば、優先順位が高いタスクが高速な通信を行うことができる。

また、ステップS502において、パケットの属性（宛先IPアドレス）を判定し、所定のIPアドレスに合致する場合は高速バッファが使用可能とする。こうすれば、特定の通信相手に対して高速な通信を行うことができる。

また、ステップS502において、パケットの属性（宛先ポートまたは送信元ポート）を判定し、所定のポート番号に合致する場合は高速バッファが使用可能とする。特定の通信プロトコルに対して所定のポート番号が割り当てられていることが多く、こうすれば、特定の通信プロトコルを用いる通信の場合、高速な通信を行うことができる。

また、ステップS502において、パケットの属性（宛先ポートおよび送信元ポート）を判定し、所定のポート番号の組み合わせに合致する場合は高速バッファが使用可能とする。こうすれば、特定のコネクションについて高速な通信を行うことができる。

また、ステップS502において、ソケットAPI send()を呼び出した際のデータサイズを判定し、データサイズが所定の閾値を超える場合は高速バッファが使用可能とする。こうすれば、大きなデータを送信する際に高速な通信を行うことができる。

ネットワークバッファを切り替えるための上記条件は、通信装置の機器設定やシステム設定として設定され、書換可能な不揮発性メモリ109であるEEPROM、フラッシュメモリ、HDD、SSDなどの記録媒体に記録されている。

また、上記では、TCP/IPを例に挙げたが、例えばUDP (user datagram protocol)にも本発明を適用することができる。

以下、本発明にかかる実施例2の通信処理を説明する。なお、実施例2において、実施例1と略同様の構成については、同一符号を付して、その詳細説明を省略する。

図8のフローチャートにより実施例2のソケットAPI send()によるデータ送信を説明する。図4に示す処理に加えて、コネクション管理構造体にフラグSO_FASTRAMがセットされている場合にシステム設定などに基づく判定(S511)が追加されている。

ステップS511の判定は、機器設定やシステム設定の判定結果に基づき高速バッファの使用可否を判断するものである。つまり、ソケットAPI setsockopt()によって高速バッファ602の使用が設定されたとしても、システム設定などに基づき高速バッファの使用が許可されない場合、汎用バッファが使用される。

高速バッファの使用が設定された複数のソケット記述子sdを指定するソケットAPI send()がほぼ同時に呼び出される場合が想定される。そのような場合、システム設定などに基づき高速な通信を行うべきと判断されないコネクションには汎用バッファが使用される。一方、システム設定などに基づき高速な通信を行うべきと判断されるコネクションには、優先的に、高速バッファが使用される。

ステップS511の判定には、上述したネットワークバッファの切替方法と同様の方法を適用することができる。つまり、ソケットAPI send()を呼び出したアプリケーションタスクの実行優先順位（優先順位が高いタスクが優先）による切り替えが適用可能である。また、パケットの属性（宛先IPアドレス：特定の通信相手が優先、宛先ポートまたは送信元ポート：特定の通信プロトコルが優先、宛先ポートおよび送信元ポート：特定のコネクションが優先）による切り替えが適用可能である。あるいは、ソケットAPI send()を呼び出した際のデータサイズ（大きなデータサイズが優先）に基づく切り替えが適用可能である。

以下、本発明にかかる実施例3の通信処理を説明する。なお、実施例3において、実施例1、2と略同様の構成については、同一符号を付して、その詳細説明を省略する。

実施例3においては、ACKの受信間隔によってコネクションの通信速度を判定し、高速な通信を行っていないと判断したコネクションによる高速バッファの使用を禁止する。図1に示すタイマ管理部106には高速バッファを使用するコネクションのソケット記述子sdと判定時間が登録される。タイマ管理部106は、時間をカウントし、判定時間が経過すると、対応するコネクションについて判定時間の経過を示す信号をCPU102（が実行するネットワークドライバ）に発行する。

図9のフローチャートにより実施例3のACK受信時の処理を説明する。図9に示す処理は、ACKの受信によるイベント割込処理である。

イベント割込が発生すると(S1101)、ネットワークドライバは、受信したACKに対応するコネクション管理構造体を検索する(S1102)。対応するコネクション管理構造体を検出すると、フラグSO_FASTRAMがセットされているか否かを判定する(S1103)。

当該フラグがセットされていない場合、ネットワークドライバは、再送のために確保していたネットワークバッファを解放し(S1106)、イベント割込処理を終了して通常処理に復帰する(S1107)。

一方、当該フラグがセットされている場合、つまり高速バッファを使用するコネクションの場合、ネットワークドライバは、検出したコネクション管理構造体に関連付けたタイマの停止処理を行い(S1104)、当該タイマの再設定処理を行う(S1105)。そして、再送のために確保していたネットワークバッファを解放し(S1106)、イベント割込処理を終了して通常処理に復帰する(S1107)。つまり、ACKを受信した場合、タイマはリセットされ再び時間をカウントする。

図10のフローチャートにより実施例3においてタイマ管理部106が判定時間の経過を示す信号を発行した場合の処理を説明する。図10に示す処理はタイマ割込処理である。

タイマ割込が発生すると(S1201)、ネットワークドライバは、タイマ管理部106が発行した信号に基づき、対応するコネクション管理構造体を検索する(S1202)。そして、検出したコネクション管理構造体に、高速バッファの使用禁止を示す非使用フラグNO_USE_FASTRAMをセットし(S1203)、タイマ割込処理を終了して通常処理に復帰する(S1204)。

図11のフローチャートにより実施例3のソケットAPI send()によるデータ送信を説明する。図4のステップS502の判定が、ソケット記述子sdに対応するコネクション管理構造体のフラグSO_FASTRAMとフラグNO_USE_FASTRAMの判定(S522)に変更されている。

つまり、実施例3において、ソケット記述子sdに対応するコネクション管理構造体のフラグSO_FASTRAMがセット、かつ、フラグNO_USE_FASTRAMが未セットの場合、ユーザデータが高速バッファにコピーされる(S503)。また、当該コネクション管理構造体のフラグSO_FASTRAMが未セット、または、フラグNO_USE_FASTRAMがセットの場合、ユーザデータが汎用バッファにコピーされる(S504)。

また、図12のフローチャートにより実施例3と実施例2を組み合わせた場合のソケットAPI send()によるデータ送信を説明する。つまり、ソケット記述子sdに対応するコネクション管理構造体のフラグSO_FASTRAMがセット、かつ、フラグNO_USE_FASTRAMが未セットの場合、システム設定に基づく使用可否の判定(S511)が行われる。

図12の処理によれば、当該コネクション管理構造体のフラグSO_FASTRAMがセット、フラグNO_USE_FASTRAMが未セット、かつ、高速バッファの使用が許可される場合、ユーザデータが高速バッファにコピーされる(S503)。また、当該コネクション管理構造体のフラグSO_FASTRAMが未セット、フラグNO_USE_FASTRAMがセット、または、高速バッファの使用が許可されない場合、ユーザデータが汎用バッファにコピーされる(S504)。

実施例3によれば、ACKの受信間隔が長い、所定の通信速度未満のコネクションによる高速バッファの使用を禁止して、高速な通信を行うコネクションに、優先的に、高速バッファを使用させることができる。

なお、通信速度の判定に、コネクションにおけるACKの受信間隔を使用する例を説明したが、ACK番号を利用して通信速度を判定することもできる。つまり、受信した複数のACKパケットに格納されたACK番号と、通信相手が受信したデータサイズ（バイト数）から通信速度が計算可能である。また、単位時間当りに送信したデータサイズ（バイト数）から通信速度が計算可能である。そして、通信速度の閾値を設定し、計算された通信速度が閾値未満であれば高速な通信が行われていないと判断すればよい。

以下、本発明にかかる実施例4の通信処理を説明する。なお、実施例4において、実施例1-3と略同様の構成については、同一符号を付して、その詳細説明を省略する。

TCPにおけるデータ送信においは、通信相手からACKを受信するまで、送信したデータを再送のために保持する必要がある。つまり、送信データに対するACKを所定の時間が経過しても受信できない場合や、同じACKを何回か受信した場合、通信相手が送信データを受信できなかったと判断して、保持するデータを再送する。言い替えれば、送信データに対するACKを受信するまで、当該データが格納されたネットワークバッファを解放することができず、高速バッファの効率的な利用に支障を来す場合がある。

そこで、実施例4においては、ACKの受信が遅い場合、再送が発生すると判断し、高速バッファのデータを汎用バッファにコピーして、高速バッファを解放する。

実施例4において、図9に示したACKの受信によるイベント割込処理が実行されるが、タイマ管理部106が登録時間超過を示す信号を発行した場合の処理が異なる。図13のフローチャートにより実施例4においてタイマ管理部106が登録時間超過を示す信号を発行した場合の処理を説明する。図13に示す処理はタイマ割込処理である。

タイマ割込が発生すると(S1501)、ネットワークドライバは、タイマ管理部106が発行した信号に基づき、対応するコネクション管理構造体を検索する(S1502)。対応するコネクション管理構造体を検出すると、フラグSO_FASTRAMがセットされているか否かを判定する(S1503)。なお、実施例3との組み合わせを考慮すると、フラグSO_FASTRAMがセット、かつ、フラグNO_USE_FASTRAMが未セットか否かの判定(S1503)になる。

フラグSO_FASTRAMが未セット（または、フラグNO_USE_FASTRAMがセット）の場合、ネットワークバッファは、高速バッファを使用しないコネクションと判断して、イベント割込処理を終了して通常処理に復帰する(S1508)。

フラグSO_FASTRAMがセット（かつ、フラグNO_USE_FASTRAMが未セット）の場合、ネットワークバッファは、高速バッファを使用するコネクションと判断する。そして、当該コネクションが使用する高速バッファの数を調べ(S1504)、高速バッファの使用数分の汎用バッファを確保する(S1505)。そして、当該コネクションが使用する高速バッファのデータを汎用バッファにコピーし(S1506)、当該コネクションが使用する高速バッファを解放し(S1507)、イベント割込処理を終了して通常処理に復帰する(S1508)。

また、高速バッファの解放(S1507)と通常処理への復帰(S1508)の間で、実施例3と同様に、当該コネクションに対応するコネクション管理構造体にフラグNO_USE_FASTRAMをセットしてもよい。さらに、実施例2、3、4の組み合わせも可能である。

このように、通信に遅滞があるコネクションが使用する高速バッファをより早く解放し、他のコネクションに、優先的に、高速バッファを使用させることができる。

以下、本発明にかかる実施例5の通信処理を説明する。なお、実施例5において、実施例1-4と略同様の構成については、同一符号を付して、その詳細説明を省略する。

TCP/IP通信におけるTCPの使用の指示は、ソケットAPIであるsocket()の引数によって行われる。ソケットAPIの第一引数がPF_INET(AF_INET)またはPF_INET6(PF_INET6)であり、かつ、第二引数がSOCK_STREAMである場合、TCPの使用が示される。例えば、TCPによるInternet protocol version 4 (IPv4)の通信は、socket(AF_INET, SOCK_STREAM, 0)によって呼び出される。その際、ソケット記述子(sd)302に対応付けられたコネクション管理構造体に、TCP通信であることを示すフラグがセットされる。

図14のフローチャートにより実施例5のソケットAPI send()によるデータ送信を説明する。CPU102が実行するアプリケーションは、ソケット記述子sdを指定したsend()を呼び出す(S1401)。send()が呼び出されると、ネットワークドライバは、ソケット記述子sdに対応するコネクション管理構造体を調べ、TCP通信か否かを判定する(S1402)。

ソケット記述子sdに対応するコネクション管理構造体にTCPフラグがセットされている場合、ネットワークドライバは、ユーザデータをSRAM101に割り当てた高速バッファにコピーする(S1403)。また、TCPフラグがセットされていない場合（例えばUDP通信の場合）、ネットワークドライバは、ユーザデータをDRAM103に割り当てた汎用バッファにコピーする(S1404)。

次に、ネットワークドライバは、パケットヘッダを生成するためにチェックサムを計算してパケットヘッダを生成し、ユーザデータをパケット化する(S1405)。さらに、Ethernet（登録商標）ヘッダを生成し、パケットをEthernet（登録商標）フレーム化し、Ethernet（登録商標）フレームをMAC104に送信する(S1406)。

このようにすれば、大量のデータを送信することが多いTCP通信のパケットに優先的に高速バッファを割り当てることができる。また、TCP通信以外にも大量のデータを送信することが多い通信プロトコルが存在する場合、ステップS1402において当該通信プロトコルによる通信と判定した場合は高速バッファを使用することも可能である。

以下、本発明にかかる実施例6の通信処理を説明する。なお、実施例6において、実施例1-5と略同様の構成については、同一符号を付して、その詳細説明を省略する。

上記の実施例においては、データ送信のためのネットワークバッファを割り当てる際、DRAM103に割り当てられた汎用バッファを使用するか、高速なSRAM101に割り当てられた高速バッファを使用するを切り替える例を説明した。実施例6では、ネットワークドライバの受信用のネットワークバッファとして優先的に汎用バッファを割り当て、ネットワークドライバの受信以外のネットワークバッファとして優先的に高速バッファを割り当てる例を説明する。

図15のフローチャートにより実施例6のソケットAPI send()によるデータ送信を説明する。また、図16のフローチャートにより図15に示すステップS1602におけるネットワークバッファの割当処理の詳細を説明する。図16には、ネットワークドライバが受信のために使用するネットワークバッファを割り当てる場合を除き、優先的に高速バッファを割り当てる例を示す。

CPU102が実行するアプリケーションは、ソケット記述子sdを指定したsend()を呼び出す(S1601)。send()が呼び出されると、図16のフローチャートに従うネットワークバッファの割り当てが行われる(S1602)。send()によるネットワークバッファ割当処理の呼び出しは、ネットワークドライバの受信用バッファの割り当てではなく、高速バッファが優先的に割り当てられる。

次に、ネットワークドライバは、ユーザデータをネットワークバッファにコピーし(S1603)、チェックサムなどの計算を行いユーザデータをパケット化し(S1604)、パケットをEthernet（登録商標）フレーム化し、Ethernet（登録商標）フレームをMAC104に送信する(S1605)。

次に、ネットワークバッファ割当処理(S1602)について説明する。ネットワークバッファ割当処理が呼び出されると(S1611)、ネットワークドライバの受信用のバッフの割り当てか否かが判定される(S1612)。ネットワークドライバの受信用バッファの割り当ての場合は、汎用バッファが割り当てられる(S1614)。

一方、ネットワークドライバの受信用バッファの割り当てではない場合、高速バッファに空きがあるか否かが判定され(S1613)、空きがあれば高速バッファが割り当てられる(S1615)。もし、高速バッファに空きがない場合は汎用バッファが割り当てられる(S1614)。

ネットワークドライバの受信用バッファは、何時、どれだけのパケットを受信するか分からないため、多数の受信バッファを割り当てる必要がある。言い替えれば、ネットワークドライバの受信用に割り当てられたバッファの使用頻度が低いことを意味する。従って、使用頻度が低いネットワークドライバの受信用バッファに汎用バッファを割り当て、ネットワークドライバの受信用以外には高速バッファを優先的に割り当てる。言い替えれば、ネットワークドライバの受信用のバッファとして汎用バッファが使用され、その他の通信用のネットワークバッファとして高速バッファが優先的に使用される。これにより、高速バッファの利用率の向上を図ることができる。

［その他の実施例］
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記録媒体を介してシステム或いは装置に供給し、そのシステムあるいは装置のコンピュータ（又はCPUやMPU等）がプログラムを読み出して実行する処理である。

101 … SRAM、102 … CPU、103 … DRAM

Claims (21)

1. 第一のメモリと、
   前記第一のメモリよりも高速アクセスが可能な第二のメモリと、
   送信データの通信プロトコルがTCPであるかUDPであるかを判定する判定手段と、
   前記判定手段により前記送信データの通信プロトコルがTCPであると判定された場合、前記第二のメモリをネットワークバッファとして使用して、当該送信データをパケット化し、
   前記判定手段により前記送信データの通信プロトコルがUDPであると判定された場合、前記第一のメモリをネットワークバッファとして使用して、当該送信データをパケット化するプロトコル処理手段と、
   を有し、
   前記プロトコル処理手段は、前記判定手段により前記送信データの通信プロトコルがTCPであると判定された場合であっても、前記第二のメモリにおいて利用可能なネットワークバッファの容量が所定の量よりも不足している場合、前記第一のメモリをネットワークバッファとして使用して、当該送信データをパケット化することを特徴とする通信装置。
2. 前記送信データの通信に関するコネクションを管理する管理情報に、当該送信データの通信プロトコルがTCPであるかUDPであるかの情報が含まれることを特徴とする請求項１に記載の通信装置。
3. 前記送信データを送信する送信手段を更に有することを特徴とする請求項１または２に記載の通信装置。
4. 前記送信手段により送信された前記送信データに対するACKを受信する受信手段を更に有し、
   前記受信手段が前記ACKを第１の時間内に受信しなかった場合、前記送信手段は、前記送信データを再送することを特徴とする請求項３に記載の通信装置。
5. 前記受信手段が前記ACKを第２の時間内に受信しなかった場合、前記第二のメモリに格納された前記送信データを、前記第一のメモリに移動させることを特徴とする請求項４に記載の通信装置。
6. 第一のメモリと、
   前記第一のメモリよりも高速アクセスが可能な第二のメモリと、
   ネットワークバッファとして、前記第一のメモリに割り当てた汎用バッファおよび前記第二のメモリに割り当てた高速バッファを使用して送信データをパケット化するプロトコル処理手段とを有し、
   前記プロトコル処理手段は、送信データの前記パケット化に前記高速バッファを使用する指示を受信すると、前記送信データの通信に関するコネクションを管理する管理情報に前記高速バッファの使用フラグをセットし、
   前記指示は、ソケットアプリケーションプログラミングインタフェイスを利用して行われることを特徴とする通信装置。
7. 前記プロトコル処理手段は、前記使用フラグがセットされた管理情報に対応するコネクションの前記パケット化に前記高速バッファを優先的に使用することを特徴とする請求項６に記載の通信装置。
8. 前記プロトコル処理手段は、前記使用フラグが未セットの管理情報に対応するコネクションの前記パケット化に前記汎用バッファを使用することを特徴とする請求項６に記載の通信装置。
9. 前記プロトコル処理手段は、前記使用フラグがセットされた管理情報に対応するコネクションについて、前記通信装置の設定に基づき前記高速バッファの使用可否を判定し、前記判定の結果に基づき前記高速バッファおよび/または前記汎用バッファを使用して前記コネクションにおける前記パケット化を行うことを特徴とする請求項６に記載の通信装置。
10. 前記プロトコル処理手段は、前記コネクションが所定の優先順位以上のタスクに関連する場合、前記高速バッファが使用可能と判定することを特徴とする請求項９に記載の通信装置。
11. 前記プロトコル処理手段は、前記コネクションが特定の通信相手に関連する場合、前記高速バッファが使用可能と判定することを特徴とする請求項９に記載の通信装置。
12. 前記プロトコル処理手段は、前記コネクションが特定の通信プロトコルを用いる場合、前記高速バッファが使用可能と判定することを特徴とする請求項９に記載の通信装置。
13. 前記プロトコル処理手段は、前記コネクションが所定の宛先ポートと送信元ポートの組み合わせの場合、前記高速バッファが使用可能と判定することを特徴とする請求項９に記載の通信装置。
14. 前記プロトコル処理手段は、前記コネクションの送信データが所定のデータサイズを超える場合、前記高速バッファが使用可能と判定することを特徴とする請求項９に記載の通信装置。
15. 前記プロトコル処理手段は、コネクションの通信速度を判定し、所定の通信速度未満のコネクションを管理する管理情報に前記使用フラグがセットされている場合、前記管理情報に前記高速バッファの使用禁止を示す非使用フラグをセットすることを特徴とする請求項６から１４のいずれか一項に記載の通信装置。
16. 前記プロトコル処理手段は、前記非使用フラグがセットされた管理情報に対応するコネクションの前記パケット化に前記汎用バッファを使用することを特徴とする請求項１５に記載の通信装置。
17. さらに、送信データに対する通信相手の肯定応答を所定時間内に受信したか否かを判定する判定手段を有し、
    前記肯定応答が前記所定時間内に受信されずに、前記送信データの通信に関するコネクションを管理する管理情報に前記使用フラグがセットされている場合、前記プロトコル処理手段は、前記コネクションが使用する前記高速バッファに格納されたデータを前記汎用バッファにコピーして前記高速バッファを解放することを特徴とする請求項６から１６のいずれか一項に記載の通信装置。
18. 前記第一のメモリはダイナミックランダムアクセスメモリ(DRAM)であり、前記第二のメモリはスタティックランダムアクセスメモリ(SRAM)であることを特徴とする請求項１から１７のいずれか一項に記載の通信装置。
19. 第一のメモリ、および、前記第一のメモリよりも高速アクセスが可能な第二のメモリを有する通信装置のデータ処理方法であって、
    送信データの通信プロトコルがTCPであるかUDPであるかを判定する判定工程と、
    前記判定工程において前記送信データの通信プロトコルがTCPであると判定された場合、前記第二のメモリをネットワークバッファとして使用して、当該送信データをパケット化し、
    前記判定工程において前記送信データの通信プロトコルがUDPであると判定された場合、前記第一のメモリをネットワークバッファとして使用して、当該送信データをパケット化するプロトコル処理工程と、
    を有し、
    前記判定工程において前記送信データの通信プロトコルがTCPであると判定された場合であっても、前記第二のメモリにおいて使用可能なネットワークバッファの容量が所定の量よりも不足している場合、前記プロトコル処理工程において、前記第一のメモリをネットワークバッファとして使用して、当該送信データをパケット化することを特徴とする処理方法。
20. 第一のメモリ、および、前記第一のメモリよりも高速アクセスが可能な第二のメモリを有する通信装置のデータ処理方法であって、
    ネットワークバッファとして、前記第一のメモリに割り当てた汎用バッファおよび前記第二のメモリに割り当てた高速バッファを使用して送信データをパケット化するプロトコル処理工程を有し、
    前記プロトコル処理工程では、送信データの前記パケット化に前記高速バッファを使用する指示を受信すると、前記送信データの通信に関するコネクションを管理する管理情報に前記高速バッファの使用フラグをセットし、
    前記指示は、ソケットアプリケーションプログラミングインタフェイスを利用して行われることを特徴とする処理方法。
21. コンピュータに請求項１９または２０に記載の各工程を実行ささせるためのプログラム。

Images