JP6334376B2 - 通信装置及びディスクリプタオーバーフロー検出方法 - Google Patents

Description

本発明の実施形態は、通信装置及びディスクリプタオーバーフロー検出方法に関する。

多数のクライアントにデータを配信する装置において、ＣＰＵ（Central Processing Unit）によるＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）ネットワーク処理の負荷が問題となっている。そこで、ＮＩＣ（Network Interface Card）上のＴＯＥ（TCP/IP Offload Engine）という専用プロセッサ・ハードウェアに、ＴＣＰ／ＩＰの処理の一部を任せるオフロード処理が注目されている。ＴＯＥは、ＣＰＵとＣＰＵにより実行されるソフトウェア（以下、「ＣＰＵ／ソフトウェア」と記載する。）が従来行っていたＴＣＰ／ＩＰプロトコルスタックのネットワーク処理のうち負荷の高い処理をハードウェア側で肩代わりして行った後、ソフトウェア側へバイパスする。これによりＣＰＵ／ソフトウェアの負担を軽減して処理を高速化させ、装置自体のスループットを向上させる。

ＴＯＥは、ハードウェアによりネットワーク処理を肩代わりした後にソフトウェア側へバイパスするために、ディスクリプタによりイベント通知を行う。このディスクリプタを通じて、ＣＰＵ／ソフトウェア（ＴＣＰ／ＩＰプロトコルスタック）とハードウェアとの間でコネクション情報（セッション情報）をやり取りする。ディスクリプタは、ハード的にはＴＯＥのメモリ上に構築したＦＩＦＯ（First In First Out）のリングバッファの形態を採る。ＴＯＥのハードウェアは、このリングバッファに対してディスクリプタの書き込みを行い、ＣＰＵ／ソフトウェアは、ＴＣＰ／ＩＰプロトコルスタックのネットワーク処理において、リングバッファからのディスクリプタの読み取りを行う。このリングバッファへの書き込み量（速度）よりも、読み込み量（速度）が遅いと、いずれリングバッファ中の読み込み未完了領域に（上書き）書き込みが発生してしまう。これが、「オーバーフロー」であり、有限なハードリソース（メモリなど）をリングバッファとして割り当てているため、いくらバッファ量を増大させたとしても原理的には回避できない課題である。このようなオーバーフローが発生した場合、従来のＮＩＣでは、ＴＣＰによる相手方からの再送を期待するより仕方が無かった。しかし、ＴＯＥにおいてソフトウェア処理の一部を肩代わりし、バイパスを行っている場合、相手方からの再送よりも、積極的にコネクションの復旧を行うことが望ましい場合が在った。

特開２００２−３６９１４７号公報 特開平５−２０４８２９号公報

本発明が解決しようとする課題は、ネットワーク処理を分割して実行する２つのネットワーク処理部間でネットワーク処理の対象となるイベントを通知するために用いるディスクリプタにオーバーフローが発生したことを検出することができる通信装置及びディスクリプタオーバーフロー検出方法を提供することである。

実施形態の通信装置は、第一ネットワーク処理部と、第二ネットワーク処理部とを持つ。第一ネットワーク処理部は、クライアント端末との間の接続を制御するためのネットワーク処理の一部を実行し、ネットワーク処理の処理対象となるイベントの発生をイベントディスクリプタにより通知する。第二ネットワーク処理部は、通知されたイベントディスクリプタに基づいてネットワーク処理を実行する。第一ネットワーク処理部は、バッファと、読出ポインタ記憶部と、書込ポインタ記憶部と、イベントディスクリプタ管理部と、オーバーフロー判断部とを持つ。読出ポインタ記憶部は、バッファにおける読出位置を示す読出ポインタを記憶する。書込ポインタ記憶部は、バッファにおける書込位置を示す書込ポインタを記憶する。イベントディスクリプタ管理部は、書込ポインタが示すバッファにおける書込位置にイベントディスクリプタを書き込み、書込ポインタを次の書込位置に進める処理と、読出ポインタが示すバッファにおける読出位置からイベントディスクリプタを読み出して第二ネットワーク処理部に通知し、読出ポインタを次の読出位置に進める処理とを行う。オーバーフロー判断部は、読出ポインタが示す読出位置と書込ポインタが示す書込位置とに基づいてディスクリプタのオーバーフローを判断する。

第１の実施形態のデータ配信システムを示す構成図。 第１の実施形態の配信装置の内部構成を示す機能ブロック図。 第１の実施形態の配信装置におけるＴＣＰの３ｗｈｓ（3-way handshake）のパッシブ・オープンのシーケンスを代表的な例として交えた時の内部フローを示す図。 第１の実施形態のリングバッファと書込ポインタ及び読出ポインタの関係を示す図。 第１の実施形態の書込ポインタ及び読出ポインタの移動を示す図。 第１の実施形態のディスクリプタオーバーフローの概念図。 第１の実施形態の配信装置によるディスクリプタオーバーフローの検知を示す図。 第１の実施形態の配信装置の動作を示す図。 第２の実施形態のコネクション管理部において管理するＴＣＰのコネクション状態の遷移を示す基本的な図。 第２の実施形態のコネクション管理情報を管理するハッシュテーブルリストを示す図。 第３の実施形態のＮＩＣ−ＴＯＥの構成を示す機能ブロック図。 第４の実施形態のＮＩＣ−ＴＯＥの構成を示す機能ブロック図。

以下、実施形態の通信装置及びディスクリプタオーバーフロー検出方法を、図面を参照して説明する。以下では、通信装置が、データ配信サービスを提供する配信装置である場合を例に説明する。

（第１の実施形態）
図１は、第１の実施形態のデータ配信システムを示す構成図である。
同図に示すように、配信装置１（通信装置）は、ＬＡＮ（Local Area Network）３を介してＩＰ（Internet Protocol）ネットワーク５に接続される。配信装置１は、ＩＰネットワーク５に接続される複数のクライアント端末７にデータを配信する。

近年、映像素材や音声素材などのデータを配信するデータ配信サービスの需要が高まっている。その中でも、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）をベースとしたベストエフォート型のネットワーキング技術を基盤インフラとしたフィールドでの配信需要が伸びている。それに伴い、回線の高速化・安定化（冗長化）などの施策が執り行われている。回線自体の高速化などによる大幅なネットワークパフォーマンスの向上のため、データの配信を行う装置において、ＣＰＵ（Central Processing Unit）によるＴＣＰ／ＩＰネットワーク処理の負荷が問題になりつつある。そこで、本実施形態の配信装置１は、ＴＯＥ（TCP/IP Offload Engine）を実装したＮＩＣ（Network Interface Card）を用いてデータ配信を行う。ＴＯＥは、ＣＰＵとＣＰＵにより実行されるソフトウェア（以下、「ＣＰＵ／ソフトウェア」と記載する。）が従来行っていたＴＣＰ／ＩＰのプロトコルスタックのネットワーク処理の一部を行う専用プロセッサ・ハードウェアである。

ＴＯＥは、ハードウェアによりネットワーク処理の一部を肩代わりした後に、ＣＰＵ／ソフトウェアに対してディスクリプタによるイベント通知を行う。このディスクリプタを通じて、ＣＰＵ／ソフトウェア（ＴＣＰ／ＩＰプロトコルスタック）とハードウェアとの間でコネクション情報（セッション情報）をやり取りする。例えば、ＣＰＵ／ソフトウェアにより行うべき従来のＴＣＰ／ＩＰのネットワーク処理の処理量を「１０」とする。その処理量「１０」のうち、ＴＯＥによりハードウェアが「７」、ＣＰＵ／ソフトウェアが「３」のネットワーク処理を行えば、ディスクリプタ引き渡しのオーバヘッドが多少発生したとしても、ＣＰＵ／ソフトウェアの負荷が軽減される。

ディスクリプタは、ハード的にはメモリ上に構築したＦＩＦＯ（First In First Out）のリングバッファの形態を採る。ハードウェアは、このリングバッファに対する書き込みを行い、ＣＰＵ／ソフトウェア（ＴＣＰ／ＩＰ プロトコルスタック）は、このリングバッファに対する読み取りを行う。しかしながら、リングバッファにおけるイベントディスクリプタの書き込み／読み込みにオーバーフローが発生した場合を危惧すると、イベントの通知がある事を期待あるいは前提としたシステムにおいては、ディスクリプタオーバーフロー時の救い上げの方法や手段を講じなくてはならない。本実施形態の配信装置１は、ディスクリプタオーバーフローを回復し、パフォーマンス及び信頼性の改善と向上を図る。

図２は、配信装置１の内部構成を示す機能ブロック図である。同図においては、本実施形態と関係する機能ブロックのみを抽出して示してある。配信装置１は、ＮＩＣ−ＴＯＥ１１（第一ネットワーク処理部）と、ローカルバス１２と、ホストＣＰＵ１３（第二ネットワーク処理部）と、アプリケーション実行部１４（第二ネットワーク処理部）と、システムメモリ１５と、メモリアクセス部１６と、送信データバッファ１７とを備える。ＮＩＣ−ＴＯＥ１１と、ホストＣＰＵ１３と、メモリアクセス部１６と、送信データバッファ１７とは、ローカルバス１２を介して接続される。

ＮＩＣ−ＴＯＥ１１は、ＴＯＥを実装したＮＩＣである。ＮＩＣ−ＴＯＥ１１は、受信バッファ１１０と、イベントディスクリプタ管理部１１１と、コネクション管理部１１３と、読出ポインタ記憶部１１４と、書込ポインタ記憶部１１５と、オーバーフロー判断部１１６と、新規イベント情報記憶部１１７と、ネットワーク処理部１１８と、送信バッファ１１９とを備える。読出ポインタ記憶部１１４と、書込ポインタ記憶部１１５と、新規イベント情報記憶部１１７とは、ＮＩＣ−ＴＯＥ１１の記憶領域内に設けられる。

受信バッファ１１０は、クライアント端末７から受信した通信パケットをバッファリングする。イベントディスクリプタ管理部１１１は、リングバッファ１１２によりイベントディスクリプタを管理する。イベントディスクリプタは、発生したＴＣＰのイベント、次に発生させるべきＴＣＰのイベント、及び、コネクションを特定する情報を含む。コネクションは、クライアント端末７との間のセッションで用いる論理的な接続である。以下では、コネクションと言う文言を用いて説明するが、セッションと言う文言に置き換えても相違はない。イベントディスクリプタは、コネクションを特定する情報に代えて、コネクションを特定する情報が書き込まれているアドレスの情報を含んでもよい。イベントディスクリプタ管理部１１１は、ネットワーク処理の処理対象となるイベントの発生をイベントディスクリプタによりホストＣＰＵ１３及びアプリケーション実行部１４に通知する。コネクション管理部１１３は、コネクション管理情報により各コネクションのコネクション状態を管理する。読出ポインタ記憶部１１４は、リングバッファ１１２の読出位置を示す読出ポインタを記憶する。書込ポインタ記憶部１１５は、リングバッファ１１２への書込位置を示す書込ポインタを記憶する。オーバーフロー判断部１１６は、読出ポインタが示すリングバッファ１１２の読出位置と、書込ポインタが示すリングバッファ１１２の書込位置とに基づいて、ディスクリプタのオーバーフローを判断する。新規イベント情報記憶部１１７は、ディスクリプタのオーバーフローが発生したときのＴＣＰのイベントの種別を記憶する。ネットワーク処理部１１８は、ハードウェアによりＴＣＰ／ＩＰのネットワーク処理を行う。送信バッファ１１９は、クライアント端末７に送信する通信パケットをバッファリングする。

ホストＣＰＵ１３は、アプリケーション実行部１４を動作させる。また、ホストＣＰＵ１３は、ＮＩＣ−ＴＯＥ１１から受信したイベントディスクリプタや、ディスクリプタオーバーフローの通知をアプリケーション実行部１４に出力する。また、ホストＣＰＵ１３は、アプリケーション実行部１４から出力されたイベントディスクリプタの読み出し指示や、ネットワーク処理の実行指示をＮＩＣ−ＴＯＥ１１に出力する。さらに、ホストＣＰＵ１３は、アプリケーション実行部１４がクライアント端末７へ配信するよう指示したデータの読み出しをメモリアクセス部１６に指示する。

アプリケーション実行部１４は、ホストＣＰＵ１３がシステムメモリ１５からソフトウェアのプログラムを読み出して実行することにより実現される。アプリケーション実行部１４は、各クライアント端末７へのデータ配信処理を制御する。データ配信処理には、ＴＣＰ／ＩＰプロトコルスタックのネットワーク処理が含まれる。

システムメモリ１５は、クライアント端末７へ配信する可能性があるデータを蓄積している。メモリアクセス部１６は、ホストＣＰＵ１３からの指示に従って、クライアント端末７へ配信するデータをシステムメモリ１５から読み出し、送信データバッファ１７に出力する。送信データバッファ１７は、クライアント端末７へ配信するデータを一時的に記憶する。

図３は、ＴＣＰの３ｗｈｓ（3-way handshake）の配信装置１側におけるパッシブ・オープンのシーケンスを代表的な例として交えた時の内部フローを示す図である。
アプリケーション実行部１４は、ｌｉｓｔｅｎ（）関数を実行し、接続要求を待つ（ステップＳ１０）。クライアント端末７は、コネクションの確立のためにＳＹＮセグメントを配信装置１へ送信する（ステップＳ１１）。配信装置１のＮＩＣ−ＴＯＥ１１は、ＳＹＮセグメントを受信したことを通知するイベントディスクリプタをホストＣＰＵ１３へ送信する（ステップＳ１２）。ホストＣＰＵ１３のカーネルは、シーケンス番号等の同期を行った後、ＳＹＮ／ＡＣＫの送信コマンドをＮＩＣ−ＴＯＥ１１に返送する（ステップＳ１３）。ＮＩＣ−ＴＯＥ１１は、ＳＹＮ／ＡＣＫの送信コマンドに従って、クライアント端末７にＳＹＮ／ＡＣＫセグメントを送信する(ステップＳ１４）。配信装置１のＮＩＣ−ＴＯＥ１１は、クライアント端末７からＡＣＫセグメントを受信すると(ステップＳ１５）、ＡＣＫセグメントに設定されているフラグと、シーケンス番号及び確認応答番号を判定し、シーケンス番号を更新する。なお、フラグは、ＳＹＮ／ＡＣＫ／ＦＩＮセグメントなどのＴＣＰの制御フレームの種類を示す。ＮＩＣ−ＴＯＥ１１は、ＡＣＫセグメントを受信したことを通知するイベントディスクリプタをホストＣＰＵ１３へ送信する(ステップＳ１６）。アプリケーション実行部１４は、ａｃｃｅｐｔ（）関数を実行し、クライアント端末７からの接続要求を受け入れる（ステップＳ１７）。これにより、配信装置１とクライアント端末７との間でコネクションが確立される。

その後、配信装置１は、クライアント端末７にデータを配信する。具体的には、アプリケーション実行部１４は、クライアント端末７へのデータ配信を指示する。ホストＣＰＵ１３は、アプリケーション実行部１４が配信を指示したデータのアドレスを指定して、メモリアクセス部１６に読み出しを指示する。メモリアクセス部１６は、ホストＣＰＵ１３から指定されたアドレスを用いてシステムメモリ１５から読み出したデータを送信データバッファ１７に転送する。ネットワーク処理部１１８は、送信データバッファ１７からデータを読み出してＴＣＰ／ＩＰのフレームに設定し、送信バッファ１１９に登録する。送信バッファ１１９に登録されたパケットは、ＬＡＮ３を介してＩＰネットワーク５に出力され、クライアント端末７へ配信される。

図４は、リングバッファ１１２と書込ポインタ及び読出ポインタの関係を示す図である。
図４（ａ）は、リングバッファ１１２の概念図である。リングバッファ１１２は、環状に連なった複数のバッファ領域を有する。図４（ｂ）は、リングバッファ１１２を直線状に展開したものであり、両端のバッファ領域が論理的に繋がれる。書込ポインタの書込位置及び読出ポインタの読出位置はそれぞれ、リングバッファ１１２内のバッファ領域を特定する。イベントディスクリプタ管理部１１１は、クライアント端末７から受信したパケットに基づくイベントを書込ポインタが示す書込位置のバッファ領域に書き込んで登録した際に、書込ポインタの位置を１つ進める。イベントディスクリプタ管理部１１１は、イベントディスクリプタが書き込まれたことによる割り込み要因をアプリケーション実行部１４に出力し、イベントの発生を通知する。アプリケーション実行部１４は、イベントディスクリプタ管理部１１１からの割り込みを受けてイベントの登録を認知すると、ディスクリプタを読み出すための割り込みを行う。イベントディスクリプタ管理部１１１は、アプリケーション実行部１４からの割り込みを受けて、読出ポインタが示す読出位置のバッファ領域から読み出したディスクリプタをアプリケーション実行部１４に通知し、読出ポインタの位置を進める。

ここで、ディスクリプタによるイベント通知とは、例えば、対向装置であるクライアント端末７のアプリケーションからＴＣＰの制御フレームを受信した旨の受信イベント通知である。イベント通知には、発生したイベント、次に発生させるべきイベント、及び、コネクションを特定する情報を含む。イベント通知の対象は、「ＳＹＮを受信した」(図３のステップＳ１１、Ｓ１２)、「ＡＣＫを受信した」(図３のステップＳ１５、Ｓ１６）などの制御フレームの受信である。また、ディスクリプタによるイベント通知には、ＮＩＣ−ＴＯＥ１１からの要求イベントの通知などがある。例えば、ＮＩＣ−ＴＯＥ１１は、クライアント端末７から受信した制御フレームが受付可（acceptable）では無いと判別できたために、「ＲＳＴを送信して欲しい」といった要求イベントをディスクリプタにより通知する。また、自装置側からの送信視点では逆に、「ＳＹＮ送信を完了した」、「ＡＣＫ送信を完了した」などの処理完了通知もディスクリプタによるイベント通知に含まれる。

イベント通知は、３ｗｈｓによるコネクション確立時のみならず、ホストＣＰＵ１３及びアプリケーション実行部１４(ＴＣＰ／ＩＰ プロトコルスタック）の負荷が軽減されうるイベントに対して行われる。例えば、コネクション切断時、コネクション確立状態におけるウィンドウ更新、ＡＣＫの応答などのイベントについてイベント通知が行われる。

図５は、書込ポインタ及び読出ポインタの移動を示す図である。図５（ａ）は、リングバッファ１１２の概念図であり、図５（ｂ）は、リングバッファ１１２を直線状に展開して示した図である。同図に示すように、書込ポインタが示す書込位置は、リングバッファ１１２のバッファ領域１１２ａ−１、バッファ領域１１２ａ−２、バッファ領域１１２ａ−３、…のように一定方向に移動する。また、読出ポインタが示す読出位置は、リングバッファ１１２のバッファ領域１１２ｂ−１、バッファ領域１１２ｂ−２、バッファ領域１１２ｂ−３、…のように書込ポインタと同じ方向に移動する。通常・定常の動作においては、書込ポインタが示す書込位置と読出ポインタが読出位置とがそれぞれ移動しても、それらが示すバッファ領域の間には一定の間隔が保たれる。瞬間的にリングバッファ１１２に多量のイベントのバースト登録が行われても、それを吸収できる分の十二分なマージンを持つ事が出来れば仕組み上破綻する事は無い。

図６は、ディスクリプタオーバーフローの概念図である。同図において、時間ｔ１〜ｔ３においては、イベントが発生するたびに、書込ポインタが示す書込位置が１つずつ移動している。そして、時間ｔ４では、書込ポインタが示す書込位置が読出ポインタが示す書込位置を追い越してしまっている。このように、ディスクリプタのオーバーフローとは、書込ポインタと読出ポインタのそれぞれが示すバッファ領域間のマージンを食いつぶし、書込ポインタの書込位置が読出ポインタの読出位置に追いつき、また、追い越してしまう事を表す。書込ポインタの書込位置が読出ポインタの読出位置を追い越してしまった場合には、ホストＣＰＵ１３やアプリケーション実行部１４に通知すべきイベントが何であったのか、また、どのコネクションに関するイベントであったのかの情報が失われてしまう。この時に失われるイベントは、追い越しによってイベント通知の読み出し（読み込み）前に上書きされてしまったバッファ領域に登録されていたイベント、あるいは、上書きできずにリングバッファ１１２に書き込むことができなかったイベントである。

図７は、配信装置１によるディスクリプタオーバーフローの検知を示す図である。配信装置１のオーバーフロー判断部１１６は、読出ポインタが示す読出位置と書込ポインタが示す書込位置を把握し、ディスクリプタのオーバーフローが発生したか、また、発生するかどうか、または、発生する直前の状態であるかどうかを判断する。イベントディスクリプタ管理部１１１（あるいはオーバーフロー判断部１１６）は、次の新規（予定）イベントが発行された段階で、次の新規（予定）イベントのイベント種別の情報を取得し、新規イベント情報記憶部１１７に登録する。登録されるイベント種別は、例えば、制御フレームの受信であれば、その制御フレームにおいて、ＳＹＮ／ＦＩＮ／ＡＣＫなどの種別が設定されているフラグである。次の新規（予定）イベント種別の情報が登録された段階では、イベントディスクリプタ管理部１１１は、まだリングバッファ１１２へのディスクリプタの書き込み登録を行わない。オーバーフロー判断部１１６は、新規イベント情報記憶部１１７にイベント種別の情報が登録された時点で、「現在の読出ポインタが示す読出位置＝＝現在の書込ポインタが示す読出位置＋１」が真となるか否かを判断する。「真」となった場合には、ディスクリプタのオーバーフローが発生した事を意味する。「偽」となった場合には、ディスクリプタのオーバーフローは発生していない事を意味する。図７の（ａ）は、「真」となる場合の例を示している。これは、リングバッファ１１２への書き込みを行って、書込ポインタが示す現在の書込位置が１つ進んだ場合、図７の（ｂ）のように、書込ポインタが示す書込位置が、読出ポインタが示す読出位置に追いついてしまう状態である。

なお、具体的、かつ、詳細にはもっと複雑な処置が必要であり、完全に飛び越しが行えないような制御や、初期化時においては例外判定をするような処置が必要となる。
上記の判断により、オーバーフロー判断部１１６は、ディスクリプタオーバーフロー（取りこぼし）の発生を検知・認識する。オーバーフロー判断部１１６は、ディスクリプタのオーバーフロー発生を検知・認識した際、新規イベント情報記憶部１１７に登録したイベント種別の情報により、どのようなイベント種別に関するイベント通知を取りこぼしたのかを判別する事が可能となる。ただし本実施形態では原理上、どのコネクションに関するイベント通知を取りこぼしたのかを判別したり保持したりすることはできない。

更にオーバーフロー判断部１１６は、ディスクリプタのオーバーフロー発生を検知・認識した際、ディスクリプタオーバーフローの発生と取りこぼしたイベントのイベント種別をホストＣＰＵ１３及びアプリケーション実行部１４に伝達する。このときオーバーフロー判断部１１６は、取りこぼしたイベントのイベント種別を、新規イベント情報記憶部１１７から読み出す。オーバーフロー判断部１１６は、イベント種別の伝達を、ＩＲＱ（Interrupt ReQuest）による割り込みおよび割り込み種別による識別などを用いて行う。これにより、ホストＣＰＵ１３／アプリケーション実行部１４においてディスクリプタオーバーフローの発生と、その時に取りこぼしが発生したイベントのイベント種別を認知可能となる。具体的なイベント種別としては先に記したような「ＳＹＮを受信した」、「ＡＣＫを受信した」、「ＲＳＴを送信して欲しい」、「ＳＹＮ送信を完了した」、…、「ＡＣＫ送信を完了した」などが考えられる。しかし、細分化すればするほど種別が肥大化していき、結果としてＴＯＥとしての性能劣化につながる事も有るため、多ければ良いという物では無い。

図８は、配信装置１の動作を示す図である。
配信装置１は、クライアント端末７から受信した通信パケットを受信バッファ１１０に登録する。受信バッファ１１０にバッファリングされている通信パケットのＳはＳＹＮセグメントを、ＡはＡＣＫセグメントを、ＦはＦＩＮセグメントを示す。受信バッファ１１０は、バッファリングされた通信パケットをＦＩＦＯ制御によってイベントディスクリプタ管理部１１１に出力する(ステップＳ１０５）。同図においては、ＳＹＮセグメントの通信パケットが出力されている。

イベントディスクリプタ管理部１１１（あるいはオーバーフロー判断部１１６）は、受信した通信パケットから制御フレームの種別を表すフラグ部分を抽出して新規イベント情報記憶部１１７に書き込む(ステップＳ１１０）。オーバーフロー判断部１１６は、ディスクリプタオーバーフローが発生したか否かを判断する(ステップＳ１１５）。すなわち、オーバーフロー判断部１１６は、読出ポインタ記憶部１１４から読出ポインタを読み出し、書込ポインタ記憶部１１５から書込ポインタを読み出す。オーバーフロー判断部１１６は、書込ポインタが示す書込位置の次の書込位置が、読出ポインタが示す読出位置と一致する場合、ディスクリプタオーバーフローが発生したと判断する。

オーバーフロー判断部１１６は、ディスクリプタオーバーフローが発生したと判断した場合、ディスクリプタオーバーフローの発生をアプリケーション実行部１４に通知する(ステップＳ１２０）。オーバーフロー判断部１１６は、アプリケーション実行部１４に出力するディスクリプタオーバーフローの発生の通知に、新規イベント情報記憶部１１７から読み出したイベント種別の情報を設定する。これにより、アプリケーション実行部１４は、ディスクリプタオーバーフローの発生と、その時に取りこぼしが発生したイベントのイベント種別を認知する。アプリケーション実行部１４は、取りこぼしが発生したイベントのイベント種別に応じた復旧処置をＮＩＣ−ＴＯＥ１１に指示する。ＮＩＣ−ＴＯＥ１１のネットワーク処理部１１８は、アプリケーション実行部１４から指示された復旧処置を実行する。

なお、ステップＳ１１５において、オーバーフロー判断部１１６は、書込ポインタが示す書込位置の次の書込位置が、読出ポインタが示す読出位置と一致しない場合、ディスクリプタオーバーフローが発生していないと判断する。この場合、イベントディスクリプタ管理部１１１は、書込ポインタが示すリングバッファ１１２の書込位置に、ステップＳ１０５において出力されたパケットのイベントディスクリプタを書き込む。イベントディスクリプタ管理部１１１は、書込ポインタを現在の書込位置から１つ進めた位置に更新し、アプリケーション実行部１４にイベントディスクリプタの書き込みが完了したことを（行われたことを）通知する。また、コネクション管理部１１３は、イベントが発生したコネクションのコネクション状態を、イベントの発生により遷移した先のコネクション状態とするようコネクション管理情報を更新する。イベントディスクリプタ管理部１１１は、アプリケーション実行部１４からイベントディスクリプタの読み出し指示を受けた場合、読出ポインタ記憶部１１４から読出ポインタを読み出す。イベントディスクリプタ管理部１１１は、読出ポインタが示すリングバッファ１１２の読出位置からイベントディスクリプタを読み出し、アプリケーション実行部１４に通知する。イベントディスクリプタ管理部１１１は、読出ポインタを現在の読出位置から１つ進めた位置に更新する。ＮＩＣ−ＴＯＥ１１のネットワーク処理部１１８は、アプリケーション実行部１４から指示に従ってクライアント端末７にＴＣＰの制御フレーム、あるいは、データパケットを送信する。コネクション管理部１１３は、ＴＣＰの制御フレームを送信した場合、制御フレームの送信対象であるコネクションのコネクション状態を、制御フレームの送信により遷移した先のコネクション状態とするようコネクション管理情報を更新する。

本実施形態によれば、リングバッファ上のディスクリプタによりＣＰＵ／ソフトウェアにイベント通知を行うＴＯＥを具備した配信装置において、ディスクリプタのオーバーフロー（取りこぼし）の発生を検知・認識する事が可能となる。
また、配信装置のＴＯＥは、ディスクリプタのオーバーフローの発生を検知・認識した際、どのようなイベント種別に関するイベント通知を取りこぼしたのかを判別する事が可能となる。さらに、ＴＯＥは、取りこぼしたイベント種別も合わせてＣＰＵ／ソフトウェア(ＴＣＰ／ＩＰプロトコルスタック)に伝達することが可能となり、ＣＰＵ／ソフトウェアにおいて適切な復旧処置を行うことができる。

（第２の実施形態）
本実施形態では、取りこぼしたイベントの種類と、各コネクションのコネクション状態とに基づいて、復旧処置の対象となるコネクションを絞り込む。以下では、第１の実施形態との差分を中心に説明する。

本実施形態の配信装置の構成は、図２に示す第１の実施形態の配信装置１と同様である。
図９は、配信装置１のコネクション管理部１１３において管理するＴＣＰのコネクション状態の遷移を示す基本的な図である（詳細は、ＩＥＴＦ ＲＦＣ７９３を参照）。ＳＹＮ_ＲＥＣＶ（ＳＹＮ_ＲＥＣＥＩＶＥＤ）、ＳＹＮ_ＳＥＮＴ、ＥＳＴＡＢＬＩＳＨＥＤ、…などの円は、ＴＣＰのコネクション状態を表す。状態間には、状態遷移のトリガとなるイベントが記載されている。このイベントは制御フレームの受信または送信である。また、フレームの受信に送信する制御フレームが記載されている場合がある。例えば、ＬＩＳＴＥＮ状態においてＳＹＮセグメントを受信すると、ＳＹＮ／ＡＣＫセグメントを送信し、ＳＹＮ_ＲＥＣＶ状態に遷移する。

ＴＣＰ／ＩＰのコネクションの管理機能は、従来、ＴＣＰ／ＩＰプロトコルスタックのネットワーク処理を行うＣＰＵ／ソフトウェアでのみ扱っていた。しかし、ＴＯＥにおいてはＴＣＰ／ＩＰのオフロード処理を行うために、コネクション情報の一部をハードウェアブロックにて扱う必要がある。結果的にコネクション管理の一部を、ハードウェア側でも担う。ＴＯＥにおいては、一般的に、図９に示すようなＴＣＰコネクションの状態を表す情報や、コネクションノードのＩＰアドレス、ＴＣＰポート番号、ＭＡＣアドレスなどの情報が扱われる。なお、本実施形態とは直接的に関わらないコネクション情報や項目も、ＴＯＥが扱う情報に含まれ得る。

コネクション管理部１１３が有するコネクションの管理機能には、今現在、どれだけのコネクションが張られているかを把握する機能も含まれる。コネクション管理部１１３は、上述したコネクション情報（ＴＣＰコネクションの状態を表す情報、コネクションノードのＩＰアドレス、ＴＣＰポート番号、ＭＡＣアドレスなど）を管理すると同時に、コネクションの総数を認識する事が出来る。具体的には、コネクション管理部１１３は、各コネクションに一意なコネクションＩＤ（セッションＩＤ）を割り当てることにより各コネクションを管理し、コネクション総数を把握する。なお、従来のＣＰＵ／ソフトウェアが行っていたＴＣＰ／ＩＰプロトコルスタックの処理において扱っていた手法と同じ手法を用いても構わない。これには、例えば図１０に示すようなハッシュテーブルリストにリンクさせて管理する方式がありえる。

図１０は、コネクション管理情報を示す図である。コネクション管理情報は、各コネクションのコネクション情報と、コネクション情報を管理するハッシュテーブルリストからなる。コネクション情報は、コネクションＩＤ(例えば、ＩＰアドレスやＭＡＣアドレスなど）に基づいてグループ分けされている。ハッシュテーブルリストには、各グループに属するコネクションのコネクション情報のうち先頭のコネクション情報のアドレスが登録されている。各コネクション情報には、次のコネクション情報のアドレス（ｎｅｘｔ）と、１つ前のコネクション情報のアドレス（ｐｒｅｖ）と、ＴＣＰのコネクション状態（ｓｔａｔｅ）とが設定される。グループの先頭のコネクション情報の場合、ｐｒｅｖには、ハッシュテーブルリストにおいて自コネクション情報のアドレスが記述されているフィールドのアドレスが設定される。

コネクション管理部１１３は、上述したコネクション管理情報を用いて、ディスクリプタオーバーフロー発生時のコネクションの総数を認識する事が可能である。さらに、コネクション管理部１１３は、ハッシュテーブルリストにリンクされているコネクション情報を探索することにより、それぞれのコネクションの状態を把握することも可能である。そこでコネクション管理部１１３は、ディスクリプタオーバーフロー発生時に各コネクションのコネクション状態を、ハッシュテーブルリストにリンクされているコネクション情報から探索する。

例えば、図９に示すように、パッシブ・オープンのコネクションとして以下の（１）〜（５）の流れがある。なお、［］は、制御フレームを表し、＜＞は、コネクション状態を表す。

（１）［ＳＹＮ］を受信する。
（２）［ＳＹＮ／ＡＣＫ］を送信する。
（３）＜ＳＹＮ_ＲＥＣＶ＞へ状態遷移する。
（４）［ＡＣＫ］を受信する。
（５）＜ＥＳＴＡＢＬＩＳＨＥＤ＞へ状態遷移する。これにより、コネクションが確立する。

ここで（４）「ＡＣＫを受信する」状況において、ディスクリプタのオーバーフローが発生したとする。ＮＩＣ−ＴＯＥ１１のオーバーフロー判断部１１６は、ディスクリプタのオーバーフローが発生したことを認知し、更に、「ＡＣＫの受信に関してのイベントを消失してしまった（取りこぼしてしまった）」ことを認知できる。ネットワーク処理部１１８は、この情報を元にハッシュテーブルリストにリンクされているコネクション情報を参照し、復旧処置対象のコネクションを探索する。

例えば、ＴＣＰのコネクション状態が＜ＳＹＮ_ＳＥＮＴ＞の場合、次に受信を期待しているのは［ＳＹＮ／ＡＣＫ］であり、[ＡＣＫ]の受信では無い。そのため、ディスクリプタのオーバーフローによってイベントを取りこぼしたコネクションの候補からは外れる。一方で、ＴＣＰのコネクション状態が＜ＳＹＮ_ＲＥＣＶ＞の場合、次に受信を期待しているのはまさに[ＡＣＫ]であり、ディスクリプタのオーバーフローによってイベントを取りこぼしたコネクションの候補とされる。

ネットワーク処理部１１８は、イベント通知を取りこぼしたとされるコネクションの候補を、それぞれのコネクションの状態を元に探索し、イベント通知を取りこぼしたとされるとして絞り込みが行われたコネクションの復旧（回復）を試みる。
例えば先の例の場合、配信装置１は、まさに取りこぼした[ＡＣＫ]を次に受信することを期待している＜ＳＹＮ_ＲＥＣＶ＞のコネクションを、イベントを取りこぼした候補、すなわち、復旧処理の対象とする。つまり、アプリケーション実行部１４は、オーバーフロー判断部１１６からディスクリプタオーバーフロー発生と[ＡＣＫ]の取りこぼしの通知を受ける。アプリケーション実行部１４は、復旧処置として、＜ＳＹＮ_ＲＥＣＶ＞のコネクションに対して、＜ＳＹＮ_ＲＥＣＶ＞に遷移する前の[ＳＹＮ／ＡＣＫ]を送信するよう指示する。ネットワーク処理部１１８は、アプリケーション実行部１４の指示を受け、コネクション情報にコネクション状態が＜ＳＹＮ_ＲＥＣＶ＞が設定されているコネクションを、イベントを取りこぼした候補として特定する。ネットワーク処理部１１８は、特定した候補のコネクションに対して[ＳＹＮ／ＡＣＫ]を再送する。これにより、対向側のクライアント端末７からの再度の[ＡＣＫ]送信を積極的に促す。

上述したように本実施形態では、ディスクリプタのオーバーフローが発生した際にイベント通知を取りこぼしたとされるコネクションの候補を、各コネクションのコネクション状態と、取りこぼしたイベントの種類とに基づいて選択することができる。配信装置は、選択した候補のコネクションに対してのみ復旧処置を行うため、復旧処置の負荷が軽減される。

（第３の実施形態）
本実施形態では、コネクション数が多い場合に復旧処置を制限する。以下では、上述した第１の実施形態及び第２の実施形態との差分を中心に説明する。本実施形態の配信装置１は、図２に示すＮＩＣ−ＴＯＥ１１に代えて、図１１に示すＮＩＣ−ＴＯＥ１１ａを備える。

図１１は、本実施形態のＮＩＣ−ＴＯＥ１１ａの構成を示す機能ブロック図である。同図は、本実施形態と関係する機能ブロックのみを抽出して示してある。また、同図において、図２に示す第１の実施形態のＮＩＣ−ＴＯＥ１１と同一の部分には同一の符号を付し、その説明を省略する。ＮＩＣ−ＴＯＥ１１ａが第１の実施形態のＮＩＣ−ＴＯＥ１１と異なる点は、コネクション管理部１１３に代えてコネクション管理部１１３ａを備える点、及び、コネクション総数記憶部２０１と、復旧抑制通知部２０２とをさらに備える点である。コネクション総数記憶部２０１は、コネクション総数を示す情報を記憶する。コネクション管理部１１３ａは、第１の実施形態又は第２の実施形態のコネクション管理部１１３と同様の機能を有する。さらに、コネクション管理部１１３ａは、コネクション総数記憶部２０１に記憶されているコネクション総数を、コネクションがオープンしたときに１だけ増加させ、コネクションがクローズされたときに１だけ減少させる。復旧抑制通知部２０２は、復旧処置の抑制を判断するための制限数（閾値）を記憶している。復旧抑制通知部２０２は、オーバーフロー判断部１１６がディスクリプタオーバーフローを通知する際にコネクション総数が制限数を超えている場合は、ホストＣＰＵ１３及びアプリケーション実行部１４に対して、復旧処置の抑制を指示する。

第２の実施形態では、ディスクリプタオーバーフロー発生時にイベント通知を取りこぼしたとされるコネクションの候補を絞り込んでいる。しかし、コネクション登録数が多い場合には、各コネクションがディスクリプタオーバーフロー発生時のイベント種別の条件にマッチしているかの判断のため、全てのコネクション管理情報を探索する（試行する）と、処理オーバヘッドが膨大となる。特にディスクリプタオーバーフロー発生時にイベント通知を取りこぼした際にはハッシュテーブルリストからの探索優位性は見込めない。コネクション情報として登録されている数が増えれば増えるほど、その処理オーダーは線型探索と同様に右肩上がりとなってしまう。

コネクション登録数が増えれば増えるほど、当然ながらオーバーフロー発生時のイベント種別条件にマッチした候補数が増える事も有る程度は予測される。しかし、全てのＴＣＰ／ＩＰのコネクション状態において、イベントを取りこぼした際に回復・復旧のための積極的なアクションが必要となるわけでは無い。具体的には、ＴＣＰの接続である以上、ある程度は対向ノードからの「再送」が期待できるからである。

上述したように、登録されているコネクション情報の数が増えれば増えるほど、その処理オーダーは線型探索と同様に右肩上がりとなってしまう。そこで、配信装置１は、「コネクションの総数＜制限数」であれば、復旧（回復）処置を積極的に実施し、「コネクションの総数≧制限数」であれば、復旧（回復）処置を行わない。そこで、復旧抑制通知部２０２は、コネクション総数記憶部２０１に記憶されているコネクション総数が所定の制限数を超えた場合、ホストＣＰＵ１３及びアプリケーション実行部１４に対し、復旧処置の抑制通知を送信する。

復旧抑制通知部２０２は、オーバーフロー判断部１１６がディスクリプタオーバーフローを検出した時に、コネクション総数が所定の制限数を超えている場合に復旧処置の抑制通知を送信する。アプリケーション実行部１４は、オーバーフロー判断部１１６からディスクリプタオーバーフローが通知されても、復旧処置の抑制通知を受信した場合は復旧処置を行わない。あるいは、オーバーフロー判断部１１６がディスクリプタオーバーフローを検出した時に、コネクション総数が所定の制限数以下である場合に復旧処置の抑制解除通知を送信してもよい。アプリケーション実行部１４は、復旧処置の抑制解除通知を受信した場合は、取りこぼしたイベント種別に応じて復旧処置を行う。

復旧（回復）処置を行わない場合には、ある程度は対向ノードであるクライアント端末７からの「再送」を期待する事になる。しかし、そもそもディスクリプタオーバーフローが発生する程度には瞬間的であるにしろ、ＴＯＥのハードウェアや、ホストＣＰＵ１３あるいはアプリケーション実行部１４（ＴＣＰ／ＩＰプロトコルスタックの処理部）はシステムビジーになっている。これは、「何も処置・処理ができなくなってしまう」という点で、従来の装置と同様である。

なお、復旧抑制通知部２０２は、複数段階の制限数を用いてもよい。例えば、復旧抑制通知部２０２は、「制限数（レベル０次）」、「制限数（レベル１次）」、「制限数（レベル２次）」、…のように複数のレベルのそれぞれの制限数を用いることが可能である。復旧抑制通知部２０２は、コネクション総数が各レベルの制限数を超えた場合、復旧処置の抑制通知をアプリケーション実行部１４に出力する。復旧抑制通知部２０２は、抑制通知に、コネクション総数がいずれのレベルの制限数を超えたかを表す種別を設定する。また、復旧抑制通知部２０２は、コネクション総数が各レベルの制限数以下となった場合、復旧処置の抑制解除通知をアプリケーション実行部１４に出力する。復旧抑制通知部２０２は、抑制解除通知に、コネクション総数がいずれのレベルの制限数以下となったかを表す種別を設定する。アプリケーション実行部１４は、コネクションの総数がいずれの段階の制限数を超えたかに応じて、イベントを取りこぼした候補となるコネクションの数を絞る。アプリケーション実行部１４は、イベントを取りこぼした候補のコネクションに対してＮＩＣ−ＴＯＥ１１と協働して復旧処置を行う。

例えば、３段階の制限数が、「制限数（レベル０次）」＜「制限数（レベル１次）」＜「制限数（レベル２次）」であるとする。
アプリケーション実行部１４は、「コネクションの総数＜制限数（レベル０次）」であれば、コネクション管理情報を全探索して、イベントを取りこぼした候補となるコネクションの全抽出を行う。
また、アプリケーション実行部１４は、「制限数（レベル０次）＜コネクションの総数＜制限数（レベル1次）」であれば、制限数（レベル０次）までは候補探索を行う。
また、アプリケーション実行部１４は、「制限数（レベル１次）＜コネクションの総数＜制限数（レベル２次）」であれば、制限数（レベル１次）までは候補探索を行う。
また、アプリケーション実行部１４は、「制限数（レベル２次）＜コネクションの総数」であれば、制限数（レベル２次）までは候補探索を行う。

本実施形態によれば、復旧抑制通知部２０２は、コネクションの総数と多段階の制限数との比較結果をアプリケーション実行部１４に通知し、アプリケーション実行部１４は、通知された比較結果に応じて復旧処置を行う対象のコネクションの数を制限する。コネクションの総数と多段階の制限数との比較結果は、種別が設定された抑制通知や抑制解除通知に相当する。これにより、ディスクリプタのオーバーフローが発生した際に復旧処置を行うコネクションの数を、コネクション総数に応じて少なくして、復旧処置の負荷を軽減する。

（第４の実施形態）
第３の実施形態では、コネクション総数が制限数よりも多い場合に復旧処置を制限している。本実施形態では、コネクション総数に加え、ＴＣＰのコネクション状態毎の総数を加味して復旧処置の対象となるコネクション数を制限する。以下では、上述した第３の実施形態との差分を中心に説明する。

本実施形態の配信装置１は、図２に示すＮＩＣ−ＴＯＥ１１に代えて、図１２に示すＮＩＣ−ＴＯＥ１１ｂを備える。
図１２は、本実施形態のＮＩＣ−ＴＯＥ１１ｂの構成を示す機能ブロック図である。同図は、本実施形態と関係する機能ブロックのみを抽出して示してある。また、同図において、図１１に示す第３の実施形態のＮＩＣ−ＴＯＥ１１ａと同一の部分には同一の符号を付し、その説明を省略する。ＮＩＣ−ＴＯＥ１１ｂがＮＩＣ−ＴＯＥ１１ａと異なる点は、ＳＹＮ_ＲＥＣＶ総数記憶部２０３と、ＳＹＮ_ＳＥＮＴ総数記憶部２０４と、ＥＳＴＡＢＬＩＳＨＥＤ総数記憶部２０５と、ＦＩＮ_ＷＡＩＴ１総数記憶部２０６と、ＬＡＳＴ_ＡＣＫ総数記憶部２０７とをさらに備える点、及び、コネクション管理部１１３及び復旧抑制通知部２０２に代えてコネクション管理部１１３ｂ及び復旧抑制通知部２０２ｂを備える点である。

コネクション管理部１１３ａは、第３の実施形態のコネクション管理部１１３ａと同様の機能を有する。さらに、コネクション管理部１１３ｂは、＜ＳＹＮ_ＲＥＣＶ＞状態であるコネクションの総数をＳＹＮ_ＲＥＣＶ総数記憶部２０３に書き込む。コネクション管理部１１３ｂは、＜ＳＹＮ_ＳＥＮＴ＞状態であるコネクションの総数をＳＹＮ_ＳＥＮＴ総数記憶部２０４に書き込む。コネクション管理部１１３ｂは、＜ＥＳＴＡＢＬＩＳＨＥＤ＞状態であるコネクションの総数をＥＳＴＡＢＬＩＳＨＥＤ総数記憶部２０５に書き込む。コネクション管理部１１３ｂは、＜ＦＩＮ_ＷＡＩＴ１＞状態であるコネクションの総数をＦＩＮ_ＷＡＩＴ１総数記憶部２０６に書き込む。コネクション管理部１１３ｂは、＜ＬＡＳＴ_ＡＣＫ＞状態であるコネクションの総数をＬＡＳＴ_ＡＣＫ総数記憶部２０７に書き込む。

復旧抑制通知部２０２ｂは、第３の実施形態の復旧抑制通知部２０２と同様の機能を有する。さらに、復旧抑制通知部２０２ｂは、各コネクション状態のコネクション総数の制限数を記憶している。復旧抑制通知部２０２ｂは、ＳＹＮ_ＲＥＣＶ総数記憶部２０３、ＳＹＮ_ＳＥＮＴ総数記憶部２０４、ＥＳＴＡＢＬＩＳＨＥＤ総数記憶部２０５、ＦＩＮ_ＷＡＩＴ１総数記憶部２０６、及び、ＬＡＳＴ_ＡＣＫ総数記憶部２０７から各コネクション状態のコネクション総数を読み出す。復旧抑制通知部２０２ｂは、ディスクリプタオーバーフローの通知の際に各コネクション状態のコネクション総数が、そのコネクション状態に対応した制限数を超えている場合は、ホストＣＰＵ１３及びアプリケーション実行部１４に対して復旧処置の抑制通知を出力する。復旧処置の抑制通知には、いずれのコネクション状態の制限数を超えたかを示す種別が設定される。なお、復旧抑制通知部２０２ｂは、ディスクリプタオーバーフローの通知の際に各コネクション状態のコネクション総数が、そのコネクション状態に対応した制限数以下である場合は、ホストＣＰＵ１３及びアプリケーション実行部１４に対して、復旧処置の抑制解除通知を出力してもよい。復旧処置の抑制解除通知には、いずれのコネクション状態の制限数以下となったかを示す種別が設定される。

上記構成により、ＮＩＣ−ＴＯＥ１１ｂは、コネクション総数の加えて、特定のコネクション状態のコネクションの数を常に把握する。従って、制限数が一つである必要性は希薄になり、それぞれのコネクション状態に応じた制限数が存在する。以下では、コネクション状態ｘについて用いる制限数を、制限数（ｘ）と記載する。アプリケーション実行部１４は、ディスクリプタオーバーフロー発生時のコネクション総数やそれぞれのコネクション状態のコネクション総数を元に、イベント通知を取りこぼしたとされるコネクションの候補数を多段階で制限する。

例えば、基本形として、第２の実施形態と同様に、アプリケーション実行部１４は、「コネクションの総数＜制限数」であれば、復旧（回復）処置を積極的に実施し、「コネクションの総数≧制限数」であれば、復旧（回復）処置を行わない。
さらに、例えば次の段階として、アプリケーション実行部１４は、「ＳＹＮ_ＲＥＣＶ状態のコネクションの総数＜制限数（ＳＹＮ_ＲＥＣＶ）」であれば、復旧（回復）処置を積極的に実施し、「ＳＹＮ_ＲＥＣＶ状態のコネクションの総数＞制限数（ＳＹＮ_ＲＥＣＶ）」であれば、復旧（回復）処置を行わない、という条件も用いることができる。 また、第３の実施形態と同様に、アプリケーション実行部１４は、コネクションの総数と多段階の制限数とによって、候補数を制限する。その制限の上で、次の段階として、特定のコネクション状態のコネクション総数が制限数を超えているか否かによって、その制限された候補数よりもさらに候補数を絞るかを決定するようにもできる。

また、これらには更なる組み合わせや重要性による優先度付を行う事が出来る。例えば、アプリケーション実行部１４が、ディスクリプタのオーバーフロー発生時に、［ＡＣＫ］の取りこぼしを認識できたとする。この場合、（ａ）＜ＳＹＮ_ＲＥＣＶ＞状態における[ＡＣＫ]取りこぼしと、（ｂ）＜ＬＡＳＴ_ＡＣＫ＞状態における[ＡＣＫ]取りこぼしと、（ｃ）＜ＥＳＴＡＢＬＩＳＨＥＤ＞状態における[ＡＣＫ]取りこぼしの可能性がある。単なるＴＣＰ／ＩＰの制御フレームのやり取りのレベルにおいては、これらはほぼ同程度の重要度として扱う事が可能であると思われる。しかしＴＯＥとして見た場合には、接続可能な最大接続数の制約が伴う事がある。具体的にはＴＯＥで管理するコネクション管理情報のリソースはＴＯＥ上のＲＡＭ（Random Access Memory）のあるアドレス領域Ｓからあるアドレス領域Ｅまでに確保されていると言った形で有限であり、このリソースの有効利用は要となる。

もし、＜ＥＳＴＡＢＬＩＳＨＥＤ＞状態以上でないとＴＯＥで管理するコネクション管理情報のリソースを消費しないようなＴＯＥであれば、（ｂ）＞（ｃ）＞（ａ）のような優先度付けを行う。もし対向側からＳＹＮを受信した段階で、ＴＯＥで管理するコネクション管理情報のリソースを消費するようなＴＯＥであれば、（ｂ）＝（ａ）＞（ｃ）のような優先度付けを行う。アプリケーション実行部１４は、コネクションの候補数の制限の中で、優先度が高いコネクション状態のコネクションから優先してイベントを取りこぼした候補を選択する。

ＴＯＥによるコネクション管理の高度化の他に、＜ＥＳＴＡＢＬＩＳＨＥＤ＞状態以降のユーザデータのやり取りに特徴を持ち、ユーザデータのやり取りにおけるスループット（伝送レート）を引き上げるようなＮＩＣもある。このようにＮＩＣの場合、スライディングウィンドウ、ウィンドウアップデート、到達したシーケンス番号の更新に重きを割り当て、（ｃ）＞（ｂ）＞（ａ）のような優先度付けも十分あり得る。

また、ＳＹＮの取りこぼしと、ＦＩＮの取りこぼしとでは重要度が異なる。ＳＹＮを取りこぼしてしまった場合には、当然対向装置のＩＰアドレスなども不明である。故に対向装置へ向けたＳＹＮ／ＡＣＫの送信もままならない。よってＳＹＮが再送されるのを待つより他が無い。

一方で、ＦＩＮを取りこぼした時に起こりえる状況としては２つある。
一つは定常・通常状態において、対向装置がＦＩＮに対するＡＣＫを期待し待ち構えている場合がある。この場合であることが確実に判別・認識できるのであれば、ＦＩＮの再送を期待する事が出来る。しかし一方で、準定常・異常状態であれば、対向装置はＦＩＮに対するＡＣＫを期待し待ち構えていない場合があり得る。

具体的には対向装置側のクライアント端末７において強制的にアプリケーションを終了してしまった場合や、ＣＴＬ−ＣコマンドによりアプリケーションプログラムがＦＩＮ送信のみを行うと言った場合である。このような場合に何も行わなければＴＣＰのキープアライブタイムアウトに到達するまで、配信装置１には使用できないリソースが残る事になる。このため、配信装置１は、既に＜ＥＳＴＡＢＬＩＳＨＥＤ＞状態のコネクションを、ＦＩＮを取りこぼしてしまった候補とし、最後に認知できているシーケンス番号によりＡＣＫを送信するという復旧・回避策を実施する。対向装置側のクライアント端末７にとっては既に切断・完了しているコネクションであるため、ＲＳＴを送信してくる場合がある。このＲＳＴ受信により、配信装置１は、いち早くコネクション管理情報のリソース解放を行う事が可能となる。
そこで、ディスクリプタのオーバーフローの発生によって取りこぼしたイベントの種別を主軸に重要度を設けるという組み合わせも発生する。

本実施形態では特定のコネクション状態に関するコネクションの総数を把握している。そこで、通常のコネクション管理とのトレードオフの形として、図１０に示したコネクション管理情報のハッシュテーブルリストの他に、ディスクリプタのオーバーフロー発生時にのみ参照活用されるリストを常に持っておくことも可能である。つまり、コネクション管理部１１３は、それぞれのコネクション状態に応じたリンクリストを保持する。このリンクリストが活用されるのはディスクリプタのオーバーフロー発生時のみとなるため、それ以外のケースではこのリンクリストの保守管理の手間の分だけ負荷がかかる事になる。そのためトレードオフの形としているのだが、このリンクリストを用いる場合にはディスクリプタのオーバーフローが発生したその時点のコネクションの総数とは関わりなく、取りこぼしたイベントの種別に応じた優先度を設ける。

本実施形態によれば、復旧を行わなかったときの影響の大きさを考慮して、復旧処置の対象となるコネクションの数や、優先して復旧処置の対象とするコネクションを決定することができる。

以上説明した少なくともひとつの実施形態によれば、オーバーフロー判断部を持つことにより、ＮＩＣ−ＴＯＥがアプリケーション実行部に対してネットワーク処理の対象となるイベントを通知するために用いるディスクリプタにオーバーフローが発生したことを検出することができる。また、オーバーフロー判断部がディスクリプタオーバーフロー発生時に取りこぼしたイベントの種別をアプリケーション実行部に通知することにより、アプリケーション実行部は通知されたイベントの種別に基づいて復旧処置を行うことができる。従って、ＴＣＰ／ＩＰのネットワーク処理においてＴＯＥがディスクリプタによるイベント通知を行う場合に、ディスクリプタオーバーフローを回復し、パフォーマンス及び信頼性の改善と向上を図ることができる。
また、以上説明した少なくともひとつの実施形態によれば、コネクション管理部と復旧抑制通知部とを持つことにより、復旧処置のために負荷がかかりすぎないようにすることができる。

上記実施形態のコネクション管理部１１３、オーバーフロー判断部１１６、復旧抑制通知部２０２、及び復旧抑制通知部２０２ｂの一部または全ての機能部を、ソフトウェア機能部により実現してもよい。コネクション管理部１１３、オーバーフロー判断部１１６、復旧抑制通知部２０２、及び復旧抑制通知部２０２ｂの一部または全ての機能部をソフトウェア機能部により実現する場合、その機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１…配信装置、３…ＬＡＮ、５…ＩＰネットワーク、７…クライアント端末、１１…ＮＩＣ−ＴＯＥ、１１ａ…ＮＩＣ−ＴＯＥ、１１ｂ…ＮＩＣ−ＴＯＥ、１２…ローカルバス、１３…ホストＣＰＵ、１４…アプリケーション実行部、１５…システムメモリ、１６…メモリアクセス部、１７…送信データバッファ、１１０…受信バッファ、１１１…イベントディスクリプタ管理部、１１２…リングバッファ、１１３‥コネクション管理部、１１３ａ‥コネクション管理部、１１３ｂ‥コネクション管理部、１１４…読出ポインタ記憶部、１１５…書込ポインタ記憶部、１１６…オーバーフロー判断部、１１７…新規イベント情報記憶部、１１８…ネットワーク処理部、１１９…送信バッファ、２０１…コネクション総数記憶部、２０２…復旧抑制通知部、２０２ｂ…復旧抑制通知部、２０３…ＳＹＮ_ＲＥＣＶ総数記憶部、２０４…ＳＹＮ_ＳＥＮＴ総数記憶部、２０５…ＥＳＴＡＢＬＩＳＨＥＤ総数記憶部、２０６…ＦＩＮ_ＷＡＩＴ１総数記憶部、２０７…ＬＡＳＴ_ＡＣＫ総数記憶部

Claims (9)

1. クライアント端末との間の接続を制御するためのネットワーク処理の一部を実行し、ネットワーク処理の処理対象となるイベントの発生をイベントディスクリプタにより通知する第一ネットワーク処理部と、
   通知された前記イベントディスクリプタに基づいてネットワーク処理を実行する第二ネットワーク処理部とを備え、
   前記第一ネットワーク処理部は、
   バッファと、
   前記バッファにおける読出位置を示す読出ポインタを記憶する読出ポインタ記憶部と、
   前記バッファにおける書込位置を示す書込ポインタを記憶する書込ポインタ記憶部と、
   前記書込ポインタが示す前記バッファにおける前記書込位置にイベントディスクリプタを書き込み、前記書込ポインタを次の書込位置に進める処理と、前記読出ポインタが示す前記バッファにおける前記読出位置から前記イベントディスクリプタを読み出して前記第二ネットワーク処理部に通知し、前記読出ポインタを次の読出位置に進める処理とを行うイベントディスクリプタ管理部と、
   前記読出ポインタが示す前記読出位置と前記書込ポインタが示す書込位置とに基づいてディスクリプタのオーバーフローを判断するオーバーフロー判断部とを備え、
   前記オーバーフロー判断部は、イベントが発生した場合に前記読出ポインタが示す前記読出位置と前記書込ポインタが示す書込位置とに基づいてディスクリプタのオーバーフローが発生したか否かを判断し、オーバーフローが発生したと判断した場合に、前記イベントの種別を取得する通信装置。
2. 前記イベントディスクリプタ管理部は、前記オーバーフロー判断部がディスクリプタのオーバーフローが発生していないと判断した場合に、前記書込ポインタが示す前記バッファにおける前記書込位置に、前記イベントのイベントディスクリプタを書き込む請求項１に記載の通信装置。
3. 前記オーバーフロー判断部は、取得した前記イベントの種別を前記第二ネットワーク処理部に通知する請求項１に記載の通信装置。
4. 前記第二ネットワーク処理部は、前記オーバーフロー判断部から受信した前記イベントの種別に基づいて前記クライアント端末との間の接続の復旧処置を実行する請求項１に記載の通信装置。
5. 前記第二ネットワーク処理部は、前記オーバーフロー判断部から受信した前記イベントの種別と、前記クライアント端末の接続の状態とに基づいて、復旧処置対象の前記接続を選択する請求項１に記載の通信装置。
6. 前記第一ネットワーク処理部は、
   前記クライアント端末の接続の状態を管理するコネクション管理部と、
   前記コネクション管理部において状態を管理している前記接続の数が制限数を超えた場合に前記第二ネットワーク処理部に復旧処置を抑制するよう指示する復旧抑制通知部とを備える請求項４に記載の通信装置。
7. 前記復旧抑制通知部は、前記接続の数と多段階の制限数との比較結果を前記第二ネットワーク処理部に通知し、
   前記第二ネットワーク処理部は、前記復旧抑制通知部から通知された前記比較結果に応じて復旧処置を行う対象の前記接続の数を制限する請求項６に記載の通信装置。
8. 前記復旧抑制通知部は、所定の状態の前記接続の数が制限数を超えた場合に前記第二ネットワーク処理部に復旧処置を抑制するよう指示する請求項６に記載の通信装置。
9. 通信装置が実行するディスクリプタオーバーフロー検出方法であって、
   クライアント端末との間の接続を制御するためのネットワーク処理の一部を実行し、ネットワーク処理の処理対象となるイベントの発生をイベントディスクリプタにより通知する第一ネットワーク処理部が、書込ポインタが示すバッファにおける書込位置にネットワーク処理の対象となるイベントの情報を示すイベントディスクリプタを書き込み、前記書込ポインタを次の書込位置に進める処理と、読出ポインタが示す前記バッファにおける読出位置から前記イベントディスクリプタを読み出して第二ネットワーク処理部に通知し、前記読出ポインタを次の読出位置に進める処理とを行うイベントディスクリプタ管理ステップと、
   前記第二ネットワーク処理部が、通知された前記イベントディスクリプタに基づいて前記ネットワーク処理を実行するネットワーク処理ステップと、
   前記第一ネットワーク処理部が、前記読出ポインタが示す前記読出位置と前記書込ポインタが示す書込位置とに基づいてディスクリプタのオーバーフローを判断するオーバーフロー判断ステップと、
   を有し、
   前記オーバーフロー判断ステップにおいては、イベントが発生した場合に前記読出ポインタが示す前記読出位置と前記書込ポインタが示す書込位置とに基づいてディスクリプタのオーバーフローが発生したか否かを判断し、オーバーフローが発生したと判断した場合に、前記イベントの種別を取得する、
   ディスクリプタオーバーフロー検出方法。

Images