(57)【要約】稼動している通信装置に開設済みのセッションを、同じ通信システムに新たに追加される通信装置に冗長化すると共に、このセッションの冗長化を、できる限り、プロトコル非依存で、プロトコル実装の変更無しで行うことを可能にすることが課題である。この課題は、プロトコル処理部と、第一の冗長化処理部とを備える通信装置によって解決することができる。プロトコル処理部は、セッションを開設して、対向ノードと通信する。第一の冗長化処理部は、蓄積する手段と、送信する手段とを具備する。蓄積する手段は、プロトコル処理部がセッションを開設するときに、対向ノードから受信するセッション開設パケットを蓄積する。送信する手段は、予め決められた手順で、蓄積する手段が蓄積するセッション開設パケットを、他の通信装置へ送信する。
2009093378.tif 000002
【特許請求の範囲】
【請求項１】
セッションを開設して、対向ノードと通信するプロトコル処理部と、
前記プロトコル処理部がセッションを開設するときに、前記対向ノードから受信するセッション開設パケットを蓄積する手段と、予め決められた手順で、前記蓄積する手段が蓄積するセッション開設パケットを、他の通信装置へ送信する手段とを具備する第一の冗長化処理部とを備える
通信装置。
【請求項２】
前記第一の冗長化処理部は、
前記セッション開設パケットによって開設されたセッションと同一のセッションにかかるパケットが通過した場合に、前記かかるパケットに基づいて、前記蓄積する手段が蓄積するセッション開設パケットにおける所定のプロトコルパラメータを補正する手段を更に具備し、
前記補正する手段は、
前記所定のプロトコルパラメータとして、前記同一のセッションにかかるパケットが通過する都度、更新されるプロトコルパラメータを含むものを補正すると共に、前記他の通信装置が、前記送信する手段が送信するセッション開設パケットを用いて、前記プロトコル処理部が開設したセッションを冗長化したセッションを開設する場合に、前記他の通信装置が、前記冗長化したセッションを開設した後に、前記対向ノードから継続して送信されるパケットを受信できるように、前記所定のプロトコルパラメータを補正する
請求の範囲１記載の通信装置。
【請求項３】
上位のプロトコル層と、前記プロトコル処理部とを接続する通信ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）部と、
前記通信ＡＰＩ部を制御する第二の冗長化処理部とを更に備え、
前記第二の冗長化処理部は、
前記他の通信装置が前記セッション開設パケットによってセッションを開設するときに用いる所定のセッション開設基礎データを、前記他の通信装置に送信する手段を具備し、
前記第二の冗長化処理部の前記送信する手段は、
前記所定のセッション開設基礎データとして、少なくともソケット記述子番号を送信する
請求の範囲２記載の通信装置。
【請求項４】
前記プロトコル処理部が前記対向ノードへ送信データを送出したときに、前記送信データを前記対向ノードが受信したことを示す確認応答が届くまで、前記送信データを保持するＡＰＩ送受信バッファを更に備え、
前記第一の冗長化処理部は、
前記ＡＰＩ送受信バッファが空になったことを検出する手段を更に具備し、
前記第二の冗長化処理部の前記送信する手段は、
前記検出する手段が、前記ＡＰＩ送受信バッファが空になったことを検出した後に、前記所定のセッション開設基礎データを送信し、
前記第一の冗長化処理部の前記送信する手段は、
前記検出する手段が、前記ＡＰＩ送受信バッファが空になったことを検出した後に、前記蓄積する手段が蓄積するセッション開設パケットを送信する
請求の範囲３記載の通信装置。
【請求項５】
前記第一の冗長化処理部の前記送信する手段は、
前記対向ノード側がサーバとしてセッションが開設されていた場合に、前記蓄積する手段が蓄積するセッション開設パケットを、あて先と発信元とが入れ替わるように加工することなく、前記他の通信装置へ送信し、
前記対向ノード側がクライアントとしてセッションが開設されていた場合に、前記蓄積する手段が蓄積するセッション開設パケットを、サーバ側からクライアント側へ送信されるセッション開設パケットになるように加工してから、前記他の通信装置へ送信する
請求の範囲４記載の通信装置。
【請求項６】
前記第二の冗長化処理部は、
前記通信ＡＰＩ部から前記プロトコル処理部へ渡される送信データを保持する手段と、
確認応答が届いた場合に、前記渡される送信データを削除する手段と、
前記保持する手段が保持する送信データを前記他の通信装置へ転送する手段とを更に具備すると共に、
前記対向ノード側がクライアントとして複数のセッションが開設されていた場合には、
前記第二の冗長化処理部の前記送信する手段は、
各セッションに対応する初期シーケンス番号を、所定の順序に並び替えてから、前記他の通信装置へ送信し、
前記第一の冗長化処理部の前記送信する手段は、
前記蓄積する手段が蓄積するセッション開設パケットを、セッションごとに、前記所定の順序と同じ順序になるように並び替えてから、前記他の通信装置へ送信する
請求の範囲５記載の通信装置。
【請求項７】
請求の範囲１〜６のいずれかに記載された通信装置と同じ構成を有する別の通信装置から、予め決められた手順で、セッション開設パケットを受信してセッションを開設する通信装置であって、
下位のプロトコル層と、前記プロトコル処理部とを接続するネットワークインタフェース部を更に備え、
前記第一の冗長化処理部は、
前記別の通信装置に対して、セッション開設パケットを送信するように要求する手段と、
前記ネットワークインタフェース部が送受信する所定のパケットの通過を遮断する手段とを更に具備し、
前記遮断する手段は、
前記別の通信装置から受信するセッション開設パケットの通過を許容し、このセッション開設パケットに応答して、前記プロトコル処理部から送出されるパケットの通過を遮断する
請求の範囲６記載の通信装置。
【請求項８】
前記別の通信装置を、請求の範囲３〜６のいずれかに記載された通信装置と同じ構成を有する別の通信装置として、所定のセッション開設基礎データを受信する通信装置であって、
前記第二の冗長化処理部は、
前記プロトコル処理部がプロトコル端点を作成することを制御する端点制御手段と、前記プロトコル処理部がプロトコル端点を作成するために用いるプロトコルパラメータを補正する手段とを更に具備し、
前記第二の冗長化処理部の前記補正する手段は、
前記所定のセッション開設基礎データを前記別の通信装置から受信すると共に、受信した所定のセッション開設基礎データを前記プロトコル処理部に与え、
前記端点制御手段は、
前記第二の冗長化処理部の前記補正する手段が、前記受信した所定のセッション開設基礎データを前記プロトコル処理部に与えると、前記プロトコル処理部がプロトコル端点を作成するように制御する
請求の範囲７記載の通信装置。
【請求項９】
前記別の通信装置を、請求の範囲６に記載された通信装置と同じ構成を有する別の通信装置として、前記別の通信装置における第二の冗長化処理部の転送する手段によって転送される送信データを受信する通信装置であって、
前記第二の冗長化処理部は、
前記プロトコル処理部に送信データを書き込むことを制御する書き込み制御手段を更に具備し、
前記書き込み制御手段は、
前記別の通信装置において確認応答されていない送信データを、前記別の通信装置から受信すると共に、前記確認応答されていない送信データを前記プロトコル処理部に書き込むように制御する
請求の範囲８記載の通信装置。
【請求項１０】
前記遮断する手段は、
前記書き込み制御手段による前記プロトコル処理部への書き込み制御によって、前記プロトコル処理部から送出されるパケットの通過を遮断し、
前記端点制御手段は、
前記プロトコル処理部がプロトコル端点を作成するように制御するときに、前記別の通信装置がサーバ側としてセッションを開設していた場合には、クライアント用ソケットＡＰＩを用いて、前記プロトコル処理部がプロトコル端点を作成するように制御し、かつ、このプロトコル端点を共有する設定を行うと共に、前記共有する設定を、ＳＯ＿ＲＥＵＳＥＰＯＲＴソケットオプション、又は、ＳＯ＿ＲＥＵＳＥＡＤＤＲソケットオプションを設定することにより行い、
前記第二の冗長化処理部の前記補正する手段は、
前記別の通信装置から初期シーケンス番号を受信すると共に、受信した初期シーケンス番号を並び順に前記プロトコル処理部に与え、
前記プロトコル処理部は、
前記第二の冗長化処理部の前記補正する手段から与えられる初期シーケンス番号を、前記並び順に保持する手段を具備すると共に、前記別の通信装置からセッション開設パケットを受信すると、初期シーケンス番号を前記並び順に使ってセッションを開設する
請求の範囲９記載の通信装置。
【請求項１１】
セッションを開設して通信する第一のプロトコル処理部を備える第一の通信装置を稼動することと、
前記第一のプロトコル処理部が対向ノードとセッションを開設するときに、前記第一の通信装置が前記対向ノードから受信するセッション開設パケットを蓄積することと、
前記第一の通信装置が稼動している通信システムに、セッションを開設して通信する第二のプロトコル処理部を備える第二の通信装置を追加することと、
前記第二の通信装置へ、前記蓄積することによって蓄積されたセッション開設パケットを送信することと、
前記送信することによって送信されるセッション開設パケットによって、前記第二の通信装置にセッションを開設することとを備える
通信装置の冗長化方法。
【請求項１２】
前記蓄積することは、
前記セッション開設パケットによって開設されたセッションと同一のセッションにかかるパケットが通過した場合に、前記かかるパケットに基づいて、前記蓄積することによって蓄積されたセッション開設パケットにおける所定のプロトコルパラメータを補正することを含み、
前記補正することは、
前記同一のセッションにかかるパケットが通過する都度、更新されるプロトコルパラメータの補正を行うことを含むと共に、前記第二の通信装置が、前記送信されるセッション開設パケットを用いて、前記第一のプロトコル処理部が開設したセッションを冗長化したセッションを開設する場合に、前記第二の通信装置が、前記冗長化したセッションを開設した後に、前記対向ノードから継続して送信されるパケットを受信できるように、前記所定のプロトコルパラメータの補正を行うことを含む
請求の範囲１１記載の通信装置の冗長化方法。
【請求項１３】
前記追加することは、
前記第二の通信装置から前記第一の通信装置へ、セッション開設パケットを送信するように要求することと、
前記第二の通信装置が送受信する所定のパケットの通過を遮断することとを含み、
前記遮断することは、
前記第二の通信装置が前記第一の通信装置から受信するセッション開設パケットを通過させることと、
このセッション開設パケットに応答して、前記第二のプロトコル処理部から前記対向ノード宛に送出されるパケットの通過を遮断することとを含む
請求の範囲１２記載の通信装置の冗長化方法。
【請求項１４】
前記送信することは、
前記セッション開設パケットにより前記第二の通信装置がセッションを開設するときに用いる所定のセッション開設基礎データを、前記第二の通信装置に送信することを更に含む
請求の範囲１３記載の通信装置の冗長化方法。
【請求項１５】
前記開設することは、
前記所定のセッション開設基礎データを前記第二のプロトコル処理部に与えることと、
その後、前記送信されるセッション開設パケットによって、前記第二のプロトコル処理部にプロトコル端点を作成することとを含む
請求の範囲１４記載の通信装置の冗長化方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置及び通信装置の冗長化方法に関する。
【背景技術】
【０００２】
通信システムの可用性を高めるために、通信装置を冗長化する手法が用いられている。通信装置を冗長化すると、現用装置の処理を予備装置が引き継ぐことができるので、障害および保守等のために通信装置が停止することによるサービスの途絶を防ぐことが可能になる。【０００３】
現用装置の処理を予備装置が引き継ぐには、通常、処理に必要なプログラムおよびデータを現用装置と予備装置で共有するか、または、引き継ぎに支障のない頻度で現用装置と予備装置の間で同期をとるなどして引き継ぐべき情報の複製を保持する。【０００４】
ここで、低い頻度で更新／参照されるデータや、実装の変更が容易な処理の冗長化は比較的容易であるが、通信処理の中には上記に当てはまらない部分も存在する。【０００５】
具体的には、一般に広く利用されているＵＮＩＸ（登録商標）等のマルチプロセス実行環境の場合、アプリケーション処理はユーザプロセスとして実現されるため、プログラムの変更は比較的容易であり、また、アプリケーションプロトコルの多くはメッセージの交換単位で状態を冗長化すれば引き継ぎに支障がない。このため、共有データベースなどを用いて比較的簡単に状態を共有できる。または、複製を保持してその同期を取る場合も同期処理の頻度はそれほど高くない。【０００６】
これに対して、とくに通信処理のうち、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）などのコネクション指向トランスポートプロトコルは、その処理を引き継ぐにはコネクション状態を冗長化する必要がある。コネクション状態はパケットの送受信の都度参照・更新されるため、アプリケーションプロトコルに比べかなり高頻度で同期をとる必要がある。また、プロトコルの性能が処理遅延に対して敏感なため、処理遅延が大きなデータベース等で状態を共有するのは不向きである。【０００７】
さらにプロトコル処理はＵＮＩＸ（登録商標）システム等では主にカーネル内に実装されているため、冗長化のための変更が極めて困難である。【０００８】
ここで、プロトコル処理にはなるべく変更を加えずに状態を冗長化する方式として能動的多重化（英語では”ａｃｔｉｖｅ  ｒｅｐｌｉｃａｔｉｏｎ”）方式がある。これは、状態ではなく、状態を変更する信号を複製することで複数の系に同一の状態の複製を保持させるものである。パケットを複製してプロトコル状態（プロトコルに従って通信処理を行っている通信装置の状態）を更新させることにより、上記の課題を解決する冗長化システムを構築できる。ただし、装置毎に別々に状態の更新処理を行うため、単体の装置で処理するよりもコストが掛ることがある。【０００９】
先述のようにアプリケーションは二重処理によらずとも冗長化できるため、二重処理すると、共有データベースなどを用いる場合よりもコストが高くなってしまう。このため、「狩野，地引，『トランスポート端点のポータブルなクラスタ方式』，ＩＥＩＣＥ  Ｔｅｃｈｎｉｃａｌ  Ｒｅｐｏｒｔ，ＩＡ２００７−２，ｐｐ，５−１０，２００７年５月」にも記載されているように、上位のアプリケーションと下位のプロトコルとを個別の機構で冗長化できるよう、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）にて冗長化方式を分離するようにした方式がある。【００１０】
プロトコル状態の冗長化を二重処理により実現することで、冗長化処理をプロトコル非依存な方式にでき、かつ、プロトコル実装への変更も軽微ですませることができる。【００１１】
一方で、上記方式には下記の課題があることも分かっている。特にＴＣＰ等のコネクション指向プロトコルでは、コネクションを開設するためのパケットに含まれる情報が状態の生成に必要なことから、通信の途中からトラフィックを受け付けてもプロトコル状態は通常正しく生成できない。このため、プロトコル状態の複製を維持するには、現用装置・予備装置が同時に稼働を開始し、稼働している間は常にトラフィックを並列に処理し続ける必要がある。【００１２】
ここで例えば、現用装置が稼働を始めてからしばらくたって予備装置が稼働を始めるような場合には、予備装置が稼働し始めた後に開設されるセッションのプロトコル状態は冗長化できる。しかし、予備装置が稼働する前、現用装置のみが稼働している間に作成されたプロトコル状態は冗長化できないことになる。【００１３】
特に長時間継続するセッションを処理するようなシステムにおいて、セッションを開設してから、全ての系が停止・再開を行うと、いずれの系でも最初から該当セッションのトラフィックを処理していないため、該当セッションのプロトコル状態を保持できず、したがって冗長構成をとったとしても、該当セッションのトラフィックを処理できなくなる。【００１４】
典型的には、現用装置・予備装置の２ノードで構成されるシステムにおいて、保守等のために、系切り替えを行いながら１台ずつノードを停止させ、作業を行った後、再開させるような処理を行うと、上記の問題が発生する。【００１５】
このように、冗長化処理をプロトコル非依存とした方式は、プロトコル状態の複製契機に制限があることから、サービスの可用性に関して大きな問題が存在した。
【発明の開示】
【００１６】
本発明の課題は、稼動している通信装置に開設済みのセッションを、同じ通信システムに新たに追加される通信装置に冗長化すると共に、このセッションの冗長化を、できる限り、プロトコル非依存で、プロトコル実装（プロトコルに従った通信処理を行うために実装されるハードウェア及びソフトウェア）の変更無しで行うことを可能にすることである。
【００１７】
本発明の一つ目のアスペクトによる通信装置は、プロトコル処理部と、第一の冗長化処理部とを備える。プロトコル処理部は、セッションを開設して、対向ノードと通信する。第一の冗長化処理部は、蓄積する手段と、送信する手段とを具備する。蓄積する手段は、プロトコル処理部がセッションを開設するときに、対向ノードから受信するセッション開設パケットを蓄積する。送信する手段は、予め決められた手順で、蓄積する手段が蓄積するセッション開設パケットを、他の通信装置へ送信する。
【００１８】
本発明の二つ目のアスペクトによる通信装置の冗長化方法は、稼動することと、蓄積することと、追加することと、送信することと、開設することとを備える。稼動することにおいては、セッションを開設して通信する第一のプロトコル処理部を備える第一の通信装置を稼動する。蓄積することにおいては、第一のプロトコル処理部が対向ノードとセッションを開設するときに、第一の通信装置が対向ノードから受信するセッション開設パケットを蓄積する。追加することにおいては、第一の通信装置が稼動している通信システムに、セッションを開設して通信する第二のプロトコル処理部を備える第二の通信装置を追加する。送信することにおいては、第二の通信装置へ、蓄積することによって蓄積されたセッション開設パケットを送信する。開設することにおいては、送信することによって送信されるセッション開設パケットによって、第二の通信装置にセッションを開設する。
【００１９】
本発明によれば、稼動している通信装置に開設済みのセッションを、同じ通信システムに新たに追加される通信装置に冗長化すると共に、このセッションの冗長化を、できる限り、プロトコル非依存で、プロトコル実装の変更無しで行うことを可能にすることができる。
【図面の簡単な説明】
【００２０】
【図１】図１は、冗長化後の通信システムの構成を示すブロック図である。
【図２】図２は、第一の実施の形態における通信装置の構成を示すブロック図である。
【図３】図３は、第一の実施の形態において、追加系が追加される前に稼動系にある通信装置の動作を説明する流れ図である。
【図４】図４は、第一の実施の形態において、稼動系で開設されたセッションを冗長化する前段の処理を説明する流れ図である。
【図５ａ】図５ａは、第一の実施の形態において、稼動系で開設されたセッションを冗長化する後段の処理であって、稼動系のプロトコル端点がクライアント用プロトコル端点であった場合の処理を説明する流れ図である。
【図５ｂ】図５ｂは、第一の実施の形態において、稼動系で開設されたセッションを冗長化する後段の処理であって、稼動系のプロトコル端点がサーバ用プロトコル端点であった場合の処理を説明する流れ図である。
【図６−１】図６−１は、図４に対応するシーケンス図である。
【図６−２ａ】図６−２ａは、図５ａに対応するシーケンス図である。
【図６−２ｂ】図６−２ｂは、図５ｂに対応するシーケンス図である。
【図７】図７は、第二の実施の形態における通信装置の構成を示すブロック図である。
【図８Ａ】図８Ａは、第二の実施の形態における通信装置が、冗長化前に、アプリケーション契機で行うバッファ同期処理を説明する流れ図である。
【図８Ｂ】図８Ｂは、第二の実施の形態における通信装置が、冗長化前に、ネットワーク契機で行うバッファ同期処理を説明する流れ図である。
【図９】図９は、第二の実施の形態において、稼動系で開設されたセッションを冗長化するための準備処理を説明する流れ図である。
【図１０】図１０は、第三の実施の形態における通信装置の構成を示すブロック図である。
【図１１】図１１は、第三の実施の形態において、稼動系のサーバ用プロトコル端点を冗長化する処理を説明する流れ図である。
【図１２】図１２は、稼動系に蓄積される初期シーケンス番号の説明図である。
【図１３】図１３は、図１２のセッション開設パケットを並び替えた例を示す図である。
【図１４】図１４は、最初のセッションのキューにエンキューされたセッション開設パケットの説明図である。
【図１５Ａ】図１５Ａは、最初のセッションを追加系に開設するときに、一番目に交換されるセッション開設パケットの説明図である。
【図１５Ｂ】図１５Ｂは、最初のセッションを追加系に開設するときに、二番目に交換されるセッション開設パケットの説明図である。
【図１５Ｃ】図１５Ｃは、最初のセッションを追加系に開設するときに、三番目に交換されるセッション開設パケットの説明図である。
【図１６】図１６は、追加系に最初のセッションが開設されるときの説明図である。
【発明を実施するための最良の形態】
【００２１】
まず、本発明による通信装置を好適に使用することができる冗長化された通信システムについて説明する。図１を参照すると、冗長化された通信システムでは２台の通信装置１１，１２が稼動している。１台目の通信装置１１は、現用系であり、不図示のクライアントに対する所定のサービス提供をするなど、対向装置と通信を行う。２台目の通信装置１２は予備系であり、バックアップとして現用系の故障に備える。ここでは説明を簡単にするために、予備系を１台のみ示してあるが、複数台存在していても良い。【００２２】
２台の通信装置１１，１２は、通信用データリンク１０に接続され、対向ノードと通信を行えるようになっている。通信用データリンク１０は、対向ノードから受信する受信トラフィックを、冗長化されたそれぞれの通信装置１１，１２へ同報する機能を有する。また、いずれかの通信装置から送出される送信トラフィックを対向ノードへ送信する。図中、点線は受信トラフィックの流れを、破線は送信トラフィックの流れを示している。【００２３】
図１における２台の通信装置１１，１２は、同様の構成を有している。ネットワークインタフェース部１１６，１２６は、それぞれ、通信装置１１，１２を、下位層（当例ではデータリンク層）に接続するためのインタフェースである。プロトコル処理部１１４，１２４は、セッションを開設して、対向ノードと通信するプロトコル層（当例ではネットワーク層及びトランスポート層）における通信処理を行う。アプリケーション部１１１，１２１は、上位層（当例では、セッション層、プレゼンテーション層、アプリケーション層）の通信処理を行う。通信ＡＰＩ部１１３，１２３は、それぞれ、プロトコル処理部１１４，１２４と、アプリケーション部１１１，１２１との間で通信を行うためのインタフェースを提供する。【００２４】
パケットフィルタ冗長化処理部１１５，１２５と、通信ＡＰＩ冗長化処理部１１２，１２２とは、それぞれ、プロトコル処理部１１４，１２４に全く変更を加えることなく、若しくは、ほとんど変更を加えることなく、通信システムの冗長化を実現するものである。【００２５】
パケットフィルタ冗長化処理部１１５，１２５は、それぞれ、同報される受信データをプロトコル処理部１１４，１２４へ渡している。通信ＡＰＩ冗長化処理部１１２，１２２は、それぞれ、他の通信ＡＰＩ冗長化処理部と送受信データの照合と同期を行って、冗長化を実現している。現用系の通信ＡＰＩ冗長化処理部１１２は、通信ＡＰＩ部１１３を介してプロトコル処理部１１４から渡される受信データをアプリケーション部１１１へ渡している。一方、予備系の通信ＡＰＩ冗長化処理部１２２は、通信ＡＰＩ部１２３を介してプロトコル処理部１２４から渡される受信データを破棄している。【００２６】
通信ＡＰＩ冗長化処理部１１２、１２２は、受信データをアプリケーション部１１１へ渡す前に、又は、受信データを破棄する前に、受信データの照合を行っている。現用系の通信ＡＰＩ冗長化処理部１１２は、読み込んだ受信データを複製して、予備系の通信ＡＰＩ冗長化処理部１２２に送信する。そして、現用系の通信ＡＰＩ冗長化処理部１１２が通信ＡＰＩ部１１３を介してプロトコル処理部１１４から渡される受信データと、予備系の通信ＡＰＩ冗長化処理部１２２が通信ＡＰＩ部１２３を介してプロトコル処理部１２４から渡される受信データとを照合する。この照合が成功した場合のみ、現用系の通信ＡＰＩ冗長化処理部１１２は、受信データをアプリケーション部１１１へ渡す。【００２７】
一方、対向ノードにデータを送信する場合、まず、現用系のアプリケーション部１１１が、送信データを作成する。現用系の通信ＡＰＩ冗長化処理部１１２は、この送信データを複製し、複製した送信データを予備系の通信ＡＰＩ冗長化処理部１２２へ宛てて転送する。その後、現用系及び予備系の通信ＡＰＩ冗長化処理部１１２，１２２は、それぞれ、送信データをプロトコル処理部１１４，１２４へ渡す。現用系及び予備系のプロトコル処理部１１４，１２４は、並行して送信処理を行う。現用系では、プロトコル処理部１１４による送信処理の後、送信データがパケットフィルタ冗長化処理部１１５のパケットフィルタを素通りする。予備系では、プロトコル処理部１２４による送信処理の後、パケットフィルタ冗長化処理部１２５のパケットフィルタが送信データを破棄して、重複送信を防いでいる。【００２８】
予備系と現用系は系切り替え動作により役割が入れ替わることがあるため、これらは一般に共通の通信装置として実現する。以下、そのような通信装置を実施するための最良の形態のいくつかについて詳細に説明する。【００２９】
図２は、本発明を実施するための最良の形態の一つを示すブロック図である。図２を参照すると、この第一の実施の形態による通信装置２０は、アプリケーション部２１と、通信ＡＰＩ冗長化処理部２２と、通信ＡＰＩ部２３と、プロトコル処理部２７と、パケットフィルタ冗長化処理部２８と、ネットワークインタフェース部２９とを有している。【００３０】
アプリケーション部２１は、上位プロトコルの処理を行い、マルチプロセスＯＳでは通常ユーザプロセスとして実現される。ただし、通信ＡＰＩ部２３を用いてプロトコル処理部２７と通信を行うものであれば、ユーザプロセス以外の環境で実行されるものであっても良い。【００３１】
通信ＡＰＩ冗長化処理部２２は、ソケット（Ｓｏｃｋｅｔ）ＡＰＩ等の通信ＡＰＩ関数コール（以下、単に、ＡＰＩコールともいう。）を捕捉し、実際のＡＰＩコールの前後に付加的な処理を行うことにより、通信システムの冗長化を実現する。ＡＰＩコールは、アプリケーション部２１からプロトコル処理部２７へ向けて発行される。【００３２】
プロトコル処理部２７は、プロトコルスタックの機能を実現する。典型的にはＴＣＰ／ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）などの機能が含まれる。マルチプロセスＯＳでは、通常この部分はカーネル内に実装される。ただし、通信ＡＰＩ部２３とネットワークインタフェース部２９に挟まれているものであれば、カーネル以外の他の環境で実行されるものであってもよい。【００３３】
パケットフィルタ冗長化処理部２８は、プロトコル処理部２７が送受信する送受信データをネットワークインタフェース部２９付近で捕捉し、冗長化のための付加的な処理を行う。【００３４】
ネットワークインタフェース部２９は、プロトコル処理部２７を通信用データリンク１０に接続する役割を持つ。典型的な例としては、デバイスドライバがプロトコルスタックに提供するインタフェースが該当する。【００３５】
なお、図２では、図面の簡明化のため、アプリケーション部２１およびネットワークインタフェース部２９を各々一つずつ有する通信装置２０を図示したが、これらは複数存在していても良い。【００３６】
通信ＡＰＩ冗長化処理部２２について詳述する。図２の通信ＡＰＩ冗長化処理部２２は、ＡＰＩ呼出し捕捉部２２１と、ＡＰＩ呼出し遮断部２２２と、書き込み冗長化部２２３と、読み込み冗長化部２２４と、端点制御部２２５と、バッファ監視部２２６と、プロトコルパラメータ補正部２２７とを有している。【００３７】
ＡＰＩ呼出し捕捉部２２１は、アプリケーション部２１と、通信ＡＰＩ部２３との間に位置して、アプリケーション部２１からのＡＰＩコールを捕捉し、通信ＡＰＩ部２３の各ＡＰＩ２３１〜２３３を呼び出すことを行う前後に、他の冗長化処理を実行できるようにする。【００３８】
ＡＰＩ呼出し遮断部２２２は、後述するセッション冗長化処理の間、該当セッションに関するアプリケーション部２１によるＡＰＩコールを中断する機能を持つ。典型的には、アプリケーション部２１がＡＰＩコールを行っても、セッション冗長化処理が終わるまでＡＰＩの実行を保留する。これは、ＡＰＩコールからリターンしない（すなわちＡＰＩコールの実行をブロックする）ことで実現できる。【００３９】
書き込み冗長化部２２３は、アプリケーション部２１が書き込みＡＰＩ２３１をコールしたときに、書き込みデータを複製する。そして、現用系と予備系で各々書き込み処理を行い、送信処理を冗長化する機能を持つ。書き込みＡＰＩ２３１は、ＰＯＳＩＸシステムでは、典型的にはｗｒｉｔｅ（），ｓｅｎｄｔｏ（），ｓｅｎｄｍｓｇ（）などが該当する。【００４０】
読み込み冗長化部２２４は、アプリケーション部２１が読み込みＡＰＩ２３２をコールしたときに、現用系と予備系で各々読み込み処理を行えるようにするものである。受信データを照合することで受信処理の同期をとりながら通信システムを冗長化する機能を持つ。読み込みＡＰＩ２３２は、ＰＯＳＩＸシステムでは、典型的にはｒｅａｄ（），ｒｅｃｖｆｒｏｍ（），ｒｅｃｖｍｓｇ（）などが該当する。【００４１】
端点制御部２２５は、セッション制御ＡＰＩ２３３を利用して、所定のプロトコル状態を制御する機能を持つ。所定のプロトコル状態は、通信に必要な制御データ等によって特定されるが、この制御データは、一般にプロトコルコントロールブロック（ＰＣＢ）内に作成される。典型的には、ローカルＩＰアドレスおよびトランスポート層のポート番号、リモートＩＰアドレスおよびトランスポート層のポート番号、の４つ組を備えるプロトコル端点の制御データと、シーケンス番号等のプロトコルパラメータの制御データとが含まれる。セッション制御ＡＰＩ２３３は、ＰＯＳＩＸシステムでは、典型的にはｓｏｃｋｅｔ（），ｂｉｎｄ（），ｌｉｓｔｅｎ（），ａｃｃｅｐｔ（），ｃｏｎｎｅｃｔ（）などが該当する。【００４２】
バッファ監視部２２６は、ＡＰＩ送受信バッファ２６に送受信データがあるかどうかを検査する機能をもつ。送受信バッファ２６は、図２においては他のブロックから独立したものとして描かれているが、アプリケーション部２１が、通信ＡＰＩ部２３を通してプロトコル処理部２７に読み書きを行うときに、プロトコル処理部２７からアクセスできる位置にあればよく、例えば、プロトコル処理部２７内部の最上位層あるいは通信ＡＰＩ部２３内部などに位置していてもよい。【００４３】
プロトコルパラメータ補正部２２７は、プロトコル処理部２７が保持するプロトコルパラメータを所定の値に設定し直す機能をもつ。プロトコル処理部２７はプロトコル状態を示すプロトコルパラメータを保持している。これらのうち、プロトコルパラメータ補正部２２７は、乱数、時刻依存などを使って、作成される毎に異なる値をとるプロトコルパラメータを補正する。例えば、ＴＣＰの初期シーケンス番号、ＳＣＴＰ（Ｓｔｒｅａｍ  Ｃｏｎｔｒｏｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｐｒｏｔｏｃｏｌ）の認証タグなどがこれらにあたる。【００４４】
パケットフィルタ冗長化処理部２８について詳述する。図２のパケットフィルタ冗長化処理部２８は、セッション開設パケット捕捉部２８１と、セッション開設パケット蓄積部２８２と、セッション開設パケット補正部２８３と、通信遮断部２８４と、バッファ空き検出部２８５と、プロトコルパラメータ監視部２８６と、蓄積パケット要求部２８７と、蓄積パケット送信部２８８とを有している。【００４５】
セッション開設パケット捕捉部２８１および蓄積部２８２は、特にコネクション指向プロトコルに対して、そのコネクションを開設するのに必要なパケットが通過する際に、それらを捕捉複製し、蓄積しておく機能を持つ。コネクションを開設するのに必要なパケットとは、例えばＴＣＰの場合には、３ウエイハンドシェイクで交換されるＳＹＮ，ＳＹＮ／ＡＣＫ，ＡＣＫの各フラグがセットされたパケットを指す。【００４６】
セッション開設パケット補正部２８３は、セッション開設パケット蓄積部２８２が保持するパケットを、プロトコルパラメータ監視部２８６が監視するパラメータ等に従って加工する機能を持つ。【００４７】
通信遮断部２８４は、所定の条件により、送受信されるパケットを破棄する機能をもつ。パケットの破棄は、場合により、送受信いずれか片方向のみについて、または両方向ともに行う。【００４８】
バッファ空き検出部２８５は、ＡＰＩ送受信バッファ２６が空になっていることを検出する機能を持つ。特に送達確認を行うプロトコルでは、送信データに対する確認応答の到着を監視する。ＡＰＩ送受信バッファ２６の送信データが空になっていることは、全ての送信データに対する確認応答が到着したことを示している。【００４９】
プロトコルパラメータ監視部２８６は、パケットが通過する都度、プロトコルパラメータの変化を追跡する機能を持つ。通信プロトコルの中でも、特に、パケット毎にプロトコルパラメータが更新されるプロトコルに対して、追跡が行われる。パケット毎に更新されるプロトコルパラメータとしては、たとえば、ＴＣＰのシーケンス番号や確認応答番号などが該当する。【００５０】
蓄積パケット要求部２８７は、別の通信装置に対して、蓄積パケットを要求する機能を持つ。この要求は、予め決められたパケットの通過等を契機として行うことができ、所定のパケットを、別の通信装置へ送信することにより行うことができる。【００５１】
蓄積パケット送信部２８８は、他の通信装置から蓄積パケットを要求された場合に、セッション開設パケット蓄積部２８２に保持している該当パケットを、他の通信装置へ送信する機能を持つ。【００５２】
次に、図２の通信装置を有する通信システムの動作について詳細に説明する。この動作は、次の５段階の処理ブロックに分割して説明することができる。
１．稼動系でのセッション開設パケットの蓄積
２．トラフィックの追跡によるプロトコルパラメータの更新
３．バッファ掃き出し処理
４．追加系でのプロトコル端点作成
５．稼動系、追加系間でのパラメータ同期【００５３】
以下、これらの処理ブロックを順に説明する。なお、稼動系とは、現用系又は予備系のいずれかの通信装置を示す。また、追加系とは、通信システムに新たに追加され、稼動すると現用系又は予備系となる通信装置を示す。【００５４】
［１．稼動系でのセッション開設パケットの蓄積］
まず、稼動系の通信装置において、セッション開設パケットを蓄積する。図３は、稼動系の通信装置が、通信システムにおいて単体で動作しているときの処理を示した流れ図である。図３を参照すると、稼動系のネットワークインタフェース部がパケットを受信すると（Ｓ３０１）、セッション開設パケット捕捉部により、セッション開設パケットか否かの判断が行われる（Ｓ３０２）。セッション開設パケット捕捉部は、プロトコルヘッダなどの情報を元に、所定の通信プロトコルで送受信されるセッション開設パケットを選り分ける。セッション開設パケットとは、具体的には次のようなものを指す。例えばＴＣＰでは、通常、ＳＹＮ，ＳＹＮ／ＡＣＫ，ＡＣＫの各フラグをセットした３個のセグメントの交換による３ウエイハンドシェイクによりコネクションが開設される。これらのセグメントを含む各パケットがセッション開設パケットである。またＳＣＴＰでは、通常、ＩＮＩＴ，ＩＮＩＴ＿ＡＣＫ，ＣＯＯＫＩＥ＿ＥＣＨＯ，ＣＯＯＫＩＥ＿ＡＣＫの各チャンクを含むパケットの交換によりコネクションが開設される。これらの各パケットがセッション開設パケットである。なお、セッション開設パケットは、これらに限定されるものではなく、一般に他の通信プロトコルについても、プロトコルヘッダなどの情報からセッション開設パケットの選り分け規則を定義できる。【００５５】
受信パケットがセッション開設パケットであった場合、セッション開設パケットを複製して（Ｓ３０３）、複製パケットをセッション開設パケット蓄積部へ蓄積する（Ｓ３０４）。この蓄積は、複製パケットをセッション毎に識別できるように行うことにする。ここでは、セッションごとにキューを設けて、該当するキューに複製パケットを蓄積する。複製した後、複製元の受信パケットは通常どおりの送受信経路に戻す（Ｓ３０５）。【００５６】
［２．トラフィックの追跡によるプロトコルパラメータの更新］
セッション開設パケットによってセッションが確立された後は、対向ノードと、稼動系の通信装置との間に、送受信トラフィックが流れる。稼動系の通信装置は、送受信トラフィックを追跡して、プロトコルパラメータを更新する。図３において、受信パケットがセッション開設パケットで無かった場合（Ｓ３０２：ノー）、稼動系の通信装置では、蓄積したセッション開設パケットに対して、セッション毎に次の処理を行う。まず、セッションをキーに蓄積パケットを検索し（Ｓ３０６）、そのセッションについて、蓄積パケットがあるか否かを判断する（Ｓ３０７）。そのセッションにかかるパケットが通過した場合、そのパケットが通過した直後から該当セッションが始まるものとして追加系の通信装置でセッションを開設できるように、蓄積したセッション開設パケットのプロトコルパラメータ等を更新する（Ｓ３０８）。【００５７】
例えば、ＴＣＰの場合には、ＳＹＮ，ＳＹＮ／ＡＣＫ，ＡＣＫの各パケットに含まれる初期シーケンス番号と、確認応答番号とを更新する。後続パケットが通過するたびに、これらの番号が、通過したパケットの、その次のセグメントの番号になるように更新する。【００５８】
具体的には、セッション開設パケットにおいて、ＳＹＮフラグがセットされたセグメントの初期シーケンス番号が１００であり、その後、後続パケットにおいて、シーケンス番号が１０１から始まる１００バイトのセグメントが通過し、シーケンス番号２００が確認応答されたとする。この場合、蓄積されたセッション開設パケットにおいて、ＳＹＮフラグがセットされたセグメントの初期シーケンス番号を１００から２００へ更新する。これは、その次のセグメントを送る直前の状態からＴＣＰのハンドシェイクを行うと仮定した場合、初期シーケンス番号が２００になるはずだからである。【００５９】
［３．バッファ掃き出し処理］
追加系の通信装置が立ち上がると、セッションを冗長化する処理が行われる。図４は、稼動系のセッションを冗長化するための準備処理を説明する流れ図であり、図６−１は、図４に対応するシーケンス図である。稼動系は、所定のタイミングで、同じ通信システムに属する他の通信装置に向けて、稼動通知広告を行っている。追加系は、立ち上がると、この稼動通知広告を検知して、稼動系の通信装置を見つける。追加系は、その稼動系へ冗長化要求を発行する（Ｓ４０１）。稼動系は、追加系から冗長化要求を受け取ると（Ｓ４０２）、ＡＰＩ呼出し遮断部を操作し、書き込みＡＰＩの呼出しを遮断する（Ｓ４０３）。【００６０】
次に、稼動系は、バッファ空き検出部で送信セグメントを監視し（Ｓ４０４）、全ての送信セグメントに対する確認応答が到着するまで待つ（Ｓ４０５）。全ての確認応答が到着したら、稼動系は、パケットフィルタ冗長化処理部の通信遮断部を操作して、送受信いずれの通信データも通過できないようにする（Ｓ４０６）。【００６１】
送達確認を行うＴＣＰやＳＣＴＰなどのプロトコルでは、全ての送信データに対する確認応答が到着すると、ＡＰＩ送受信バッファの送信バッファ側は空になるはずである。この時点で、送信データは無くなっているが、確認応答に添付されているデータなどが受信バッファ側に残っていることがある。そのため、読み込みＡＰＩをコールして、ＡＰＩ送受信バッファの受信データを全て読み出す（Ｓ４０７）。読み出した受信データは、アプリケーション部が受け取る用意があれば渡しても良いし、読み込み冗長化部で保持しておいて、次回のアプリケーション部の読み込みＡＰＩコール時にアプリケーション部へ渡しても良い。これにより、ＡＰＩ送受信バッファ内の送受信データは全て掃き出される。【００６２】
［５．稼動系、追加系間でのパラメータ同期］
次に、稼動系から追加系へ、所定のセッション開設基礎データを送信する。所定のセッション開設基礎データは、追加系の通信装置がセッション開設パケットによりセッションを開設するときに用いるものであり、ここでは、稼動系が使っているソケット記述子番号と、通信装置毎に固有の値を用いることになっている所定のプロトコルパラメータの値を送信する（Ｓ４０８）。この所定のプロトコルパラメータとは、具体的には下記のものである。【００６３】
ＴＣＰについては、
−最終送信シーケンス番号
−現在の受信ウインドウサイズ
−現在の送受信バッファの大きさである。
ＳＣＴＰについては、
−最終送信シーケンス番号
−認証タグの値
−認証クッキー生成に用いる鍵の値である。【００６４】
追加系では、上記データを受け取ると（Ｓ４０９）、ソケットＡＰＩシステムコールを発行し、冗長化対象となるセッション用のソケット記述子を取得する（Ｓ４１０）。次に、プロトコル状態作成の準備のため、追加系は、冗長化対象セッションに絡むパケットが外部へ漏れないようにする。すなわち、パケットフィルタ冗長化処理部の通信遮断部が、冗長化対象セッションのパケットの送出を遮断する（Ｓ４１１）。また、後続するプロトコル端点の作成処理を行うために、追加系は、セッション開設パケット捕捉部を設定し、冗長化対象セッションのパケットを捕捉する。この動作については後述する。【００６５】
追加系は、追加系のソケット記述子と稼動系のソケット記述子との対応づけを作成し、複数のソケット記述子を用いる場合でも、どのソケット記述子同士が対応しているかを判別できるようにする。更に、追加系は、通信ＡＰＩ冗長化処理部のプロトコルパラメータ補正部を用いて、各冗長化対象セッションについて、稼動系から受信したプロトコルパラメータを、プロトコル処理部に設定する（Ｓ４１２）。【００６６】
［４．追加系でのプロトコル端点作成］
追加系では、プロトコル端点を作成する（Ｓ４１３）。プロトコル処理部がプロトコル処理を行うために用いる情報には、通信に必要なデータの他、統計情報などの通信には直接関係ない情報も含まれる場合があるが、ここでは、理解を容易にするため、通信に必要な情報のみを複製することを考える。通常、通信に必要な情報は、プロトコル処理部のプロトコルコントロールブロック（ＰＣＢ）でセッション毎に管理されている。以降、このＰＣＢを作成する手順を説明する。【００６７】
追加系でのＰＣＢ作成は、ＰＣＢを表現するデータ自体を稼動系からコピーするのでなく、追加系のプロトコル処理部が稼動系のプロトコル処理部と同一の振る舞いをするように、追加系のプロトコル処理部を外部から操作する。ここでは、追加系において、通信ＡＰＩ冗長化処理部及びパケットフィルタ冗長化処理部が、プロトコル処理部に対して送受信データを渡すことによって、追加系のプロトコル処理部内部に、稼動系で開設済みのセッションについてのＰＣＢを作成する。これにより、追加系において、プロトコル処理部の実装に変更を加えずに、稼動系で開設済みのセッションを追加系に冗長化できるようになる。【００６８】
冗長化対象セッションに対応づけられたプロトコル端点がどのように生成されたかにより、手順を場合分けして説明する。ソケットＡＰＩを使う場合には、サーバ用か、クライアント用かで、通常、セッションの作成方法が異なるためである。【００６９】
［４ａ．クライアント用プロトコル端点の作成］
稼動系のプロトコル端点がクライアント用として生成されていた場合の処理を説明する。クライアント用ソケットＡＰＩは、まず、ソケット（ｓｏｃｋｅｔ）システムコールでソケット記述子を生成したあと、対向端点を指定して、コネクト（ｃｏｎｎｅｃｔ）システムコールを発行することでコネクションを確立するのが典型的な使い方である。【００７０】
このとき、自ノード側のポート番号は、通信ＡＰＩ部またはプロトコル処理部により、通常自動的に割り当てられる。また、他のセッションとポート番号等が共有されることはない。【００７１】
アプリケーション部がコネクトシステムコールを発行すると、ＰＣＢエントリが作成される。例えばＴＣＰの場合であれば、ＳＹＮフラグがセットされたセグメントが対向端点へ向けて送出され、対向端点からＳＹＮ／ＡＣＫフラグがセットされたセグメントが到着して、コネクションが確立される。【００７２】
追加系でもこの手順を実行することにより、見掛け上新規コネクションが確立されるものとして追加系のプロトコル処理部が振る舞うように、追加系のプロトコル処理部外部から操作を行う。【００７３】
図５ａは、稼動系のクライアント用プロトコル端点を冗長化する処理を説明する流れ図であり、図６−２ａは、図５ａに対応するシーケンス図である。まず、追加系において、自ノード端点を稼動系と同一の値に固定するために、通信ＡＰＩ冗長化処理部の端点制御部がバインド（ｂｉｎｄ）システムコールを発行する（Ｓ５０２）。この時点で、自ノード端点が固定されたＰＣＢエントリが作成される。【００７４】
次に、対向端点を稼動系と同一の値にして、プロトコル端点を作成するために、端点制御部がコネクトシステムコールを発行する（Ｓ５０３）。この時点で、ＰＣＢエントリの自ノードと対向ノードの両方のプロトコル端点が固定され、端点間でコネクション確立に向けた処理が開始される。【００７５】
先述したように、ＴＣＰでは、クライアント側となる追加系のプロトコル処理部から、ＳＹＮフラグがセットされたセグメントが対向端点へ向けて送出される。【００７６】
このＳＹＮフラグがセットされたセグメントは、追加系の通信装置内部で破棄される。先述したようにパケットフィルタ冗長化処理部のセッション開設パケット捕捉部で、ＳＹＮフラグがセットされたセグメントを含むパケットを捕捉できるように予め設定してある（Ｓ４１１）。そのため、パケットフィルタ冗長化処理部の通信遮断部にて、追加系の通信装置外部へ送出されようとするパケットが捕獲され、破棄される（Ｓ５０４）。【００７７】
追加系のプロトコル処理部は、対向端点からの応答を待っている。追加系のパケットフィルタ冗長化処理部は、捕捉したパケットの情報から、対向ノードからの応答として期待されるパケットを送信するよう、稼動系のパケットフィルタ冗長化処理部へ要求を送信する（Ｓ５０５）。すなわち、追加系の蓄積パケット要求部が、稼動系の蓄積パケット送信部に対して、要求を送る。この要求は、セッション開設パケットそのものでもよいし、蓄積パケットの特定に必要な情報（端点情報など）を別の形式で送っても良い。【００７８】
稼動系の蓄積パケット送信部は、上記要求を受信する（Ｓ５０７）。稼動系の蓄積パケット送信部は、セッション開設パケット蓄積部を検索し、該当するセッションのセッション開設パケットを取り出す（Ｓ５０８）。そして、このセッション開設パケットを追加系へ送信する（Ｓ５０９）。例えば、ＴＣＰでは、ＳＹＮ／ＡＣＫフラグがセットされたセグメントを含むパケットを送信する。【００７９】
追加系において、パケットフィルタ冗長化処理部は、稼動系から届くセッション開設パケットを通過させて、プロトコル処理部に渡す（Ｓ５１０）。プロトコル処理部は、上記セグメントを対向端点から受信したものとして処理する。ＴＣＰでは、このあと、プロトコル処理部が、ＡＣＫフラグがセットされたセグメントを作成し、送出する。しかし、このパケットは、通信遮断部のセットにより、追加系の通信装置外部へは送出されない。この時点で、追加系でもコネクションが確立された状態になる。追加系は、同期処理完了を稼動系に通知し（Ｓ５１１）、稼動系は、この同期処理完了を受信する（Ｓ５１２）。その後、稼動系では、ＡＰＩ呼出し遮断部の設定を解除するなどする。【００８０】
別の例として、ＳＣＴＰについても簡単に説明しておく。ＳＣＴＰでは、２往復のセグメント交換が必要であるが、基本的にＴＣＰと同様の方法でコネクション状態を作成できる。【００８１】
ここで、稼動系に蓄積されているセッション開設パケットの各フィールドは、先述したトラフィックの追跡によるプロトコルパラメータの更新処理により、シーケンス番号等が最新の値に更新されている。【００８２】
このため、稼動系はセッション冗長化前と同様に継続して、追加系はセッションが冗長化された時点から新規に通信を開始したかのように、その後のプロトコル処理を進めることができる。【００８３】
［４ｂ．サーバ用プロトコル端点の作成］
次に、稼動系のプロトコル端点がサーバ用として作成されていた場合の処理を説明する。サーバ用プロトコル端点は、単一のポートを用いてセッションを待ち受け、複数の対向ノードと通信できるようになっている。【００８４】
通常、サーバ用ソケットＡＰＩは次のように用いる。
１．ソケットシステムコールでソケット記述子を生成する。
２．自ノード端点をバインドシステムコールで固定する。
３．リッスン（ｌｉｓｔｅｎ）システムコールを呼び、プロトコル処理部がセッションを受け入れて、アプリケーション部が通信を始めるまでのセッション開設待ちキューを設定する。プロトコル処理部は、セッションの待ち受けを始める。
４．アクセプト（ａｃｃｅｐｔ）システムコールを呼び、セッション開設待ちキューにセッションが入ったならば、それを取出して、確立済セッションに個別にソケット記述子を割り当てる。
５．各セッションの通信は、アクセプトシステムコールが返すソケット記述子を用いて行う。
上記がサーバ用ソケットＡＰＩの典型的な使い方である。【００８５】
ここで、サーバ用プロトコル端点の作成においては、プロトコル処理部にてコネクション確立が終了してから、ソケット記述子が生成される。また、初期シーケンス番号等のプロトコルパラメータは、コネクション確立前に設定しておく必要がある。したがって、初期シーケンス番号などのプロトコルパラメータを、ソケットＡＰＩ経由でセッション毎に設定することができない。【００８６】
このため、典型的なサーバ用プロトコル端点の作成手順では、既設セッションのＰＣＢを容易には複製できない。よって、第一の実施の形態では、稼動系にて、サーバ用ソケットＡＰＩを用いて生成された既設セッションを、クライアント用ソケットＡＰＩを用いて生成されたものとして取り扱うことにする。【００８７】
図５ｂは、稼動系のサーバ用プロトコル端点を冗長化する処理を説明する流れ図であり、図６−２ｂは、図５ｂに対応するシーケンス図である。サーバ用ソケットＡＰＩでは、自ノード側のプロトコル端点は最初にバインドしたアドレス及びポート番号を使う。また、同じアドレス及びポート番号を、個別セッションに割り当てたそれぞれのプロトコル端点でもそのまま使う。すなわち、待ち受けプロトコル端点と、ここから生成される既設セッションのプロトコル端点（複数のこともある）とは、自ノード側のアドレス及びポート番号を、共通の値として用いることが許されている。【００８８】
ところが、クライアント用ソケットＡＰＩでは、通常、自ノード側のプロトコル端点を共有できないので問題となる。そこで、所定のパラメータを設定することにより、自ノード側のプロトコル端点を共有することにする。例えば、ＢＳＤ系のオペレーティングシステムでは、ＳＯ＿ＲＥＵＳＥＰＯＲＴソケットオプション、ソケットＡＰＩをサポートするその他の多くのＯＳではＳＯ＿ＲＥＵＳＥＡＤＤＲソケットオプションを設定すると、アドレス及びポート番号を重複して利用できるようになる。追加系では、この機能を用いて、クライアント用ソケットＡＰＩを用いて作成するプロトコル端点を共有する（Ｓ６０１）。【００８９】
以下、ＳＯ＿ＲＥＵＳＥＡＤＤＲソケットオプションの設定例を示す。なお、／＊と＊／との間は、コメントであり、処理概要を解説したものである。【００９０】
／＊  ｓｅｒｖｅｒ＿ｅｎｄｐｏｉｎｔ  構造体にローカル端点のアドレスとポート番号を設定する  ＊／
ｗｈｉｌｅ  （／＊  既設ソケットがまだある  ＊／）  ｛
／＊  新しいソケット記述子を得て  ｓｄ  へ代入する  ＊／
ｏｐｔ  ＝  １；
／＊  該当記述子がローカル端点を重複して利用できるようにする  ＊／
ｓｅｔｓｏｃｋｏｐｔ（ｓｄ，  ＳＯＬ＿ＳＯＣＫＥＴ，  ＳＯ＿ＲＥＵＳＥＡＤＤＲ，    ＆ｏｐｔ，  ｓｉｚｅｏｆ（ｉｎｔ））；
／＊  ローカル端点を固定する  ＊／
ｂｉｎｄ（ｓｄ，  ｓｅｒｖｅｒ＿ｅｎｄｐｏｉｎｔ，  ｓｉｚｅｏｆ（ｓｅｒｖｅｒ＿ｅｎｄｐｏｉｎｔ））；
／＊  既設セッションの復元処理を行う  ＊／｝【００９１】
ソケットＡＰＩの呼出し手順等は、図５ａの場合と同様である。追加系では、図５ａのステップＳ５０２〜Ｓ５０５と同様に、図５ｂに示すように、ステップＳ６０２〜Ｓ６０５を実行する。これにより、追加系のプロトコル処理部にＰＣＢエントリが作成され、コネクション確立が開始される。【００９２】
一方、稼動系では、図５ａのステップＳ５０７、Ｓ５０８と同様に、図５ｂに示すように、ステップＳ６０６、Ｓ６０７を実行する。ただし、セッション開設パケットの送信手順がやや異なる。サーバ用プロトコル端点の作成と、クライアント用プロトコル端点の作成とでは、セッション開設パケットの向きが逆になるため、パケットの加工が必要になるからである。図５ｂでは、セッション開設パケットを加工してから（Ｓ６０８）、追加系へそのバケットを送信する（Ｓ６０９）。【００９３】
例えば、ＴＣＰの場合には、通常、クライアント側がコネクション確立を開始するため、サーバ側はパッシブオープンでコネクションを確立する。すなわち、サーバ側では、対向ノードからは、ＳＹＮフラグのみがセットされたセグメントと、ＡＣＫフラグのみがセットされたセグメントは送られてくるが、ＳＹＮ／ＡＣＫフラグがセットされたセグメントは送られてこない。一方、クライアント側では、対向ノードからは、ＳＹＮ／ＡＣＫフラグがセットされたセグメントは送られてくるが、ＳＹＮフラグのみがセットされたセグメント、及び、ＡＣＫフラグのみがセットされたセグメントは送られてこない。【００９４】
従って、単純に、稼動系のパケットフィルタ冗長化処理部に蓄積されているＳＹＮフラグのみがセットされたセグメントと、ＡＣＫフラグのみがセットされたセグメントとを追加系へ送信しても、追加系のプロトコル処理部は受け取れない。発信元と宛先アドレス、シーケンス番号と確認応答番号などが逆に設定されているためである。このことから、稼動系のパケットフィルタ冗長化処理部は、送信すべきセッション開設パケットのプロトコルパラメータを補正して送る必要がある。【００９５】
具体的に、ＴＣＰの場合を例示すると、次のようにプロトコルパラメータを補正すればよい。１．セッション開設パケット蓄積部から該当セッションについてＳＹＮフラグのみがセットされたセグメントを取出す。２．セッション開設パケット蓄積部から該当セッションについてＡＣＫフラグのみがセットされたセグメントを取出す。３．１．のセグメントの確認応答番号フィールドに２．のセグメントの確認応答番号フィールドの値をコピーし、１．のセグメントのＡＣＫフラグをセットする。４．３．で作成したセッション開設パケットを追加系へ送信する。【００９６】
加工されたセッション開設パケットを受信する追加系では、図５ａのステップＳ５１０、Ｓ５１１と同様に、図５ｂに示すように、ステップＳ６１０、Ｓ６１１を実行する。稼動系では、図５ａのステップＳ５１２と同様に、図５ｂに示すように、ステップＳ６１２を実行する。以上で、追加系は、見掛け上は自ノードがクライアントになったようにセッションを開設できる。ＳＣＴＰでも、手順はやや複雑になるが同様の方法でセッションを確立できる。【００９７】
以上の手順により、稼動系に開設済みのセッションと同じセッションを、追加系に冗長化できた。稼動系のパケットフィルタ冗長化処理部の通信遮断、および通信ＡＰＩ冗長化処理部の呼出し遮断を解除すれば、以降、例えば、稼動系を現用系、追加系を予備系として通信を継続できる。何らかの理由により、現用系が停止した場合には、予備系が自身のプロトコル端点を用いて通信を継続できる。なお、稼動系が停止してもプロトコル状態の引き継ぎが行えるように、好ましくは、追加系でも、稼動系が行っていたセッション開設パケットの蓄積等の処理を、セッション開設時から稼動系と同様に行っておく。【００９８】
次に、本発明を実施するための最良の形態の別の一つについて詳述する。この第二の実施の形態では、「バッファ掃き出し処理の効率化」を図る。第一の実施の形態では、追加系にセッションを冗長化する前に、稼動系のＡＰＩ送受信バッファを空にする操作を行う必要があった。この操作により、ＡＰＩ送受信バッファに保持された送受信データのコピーが不要になり、事後のセッション冗長化処理を単純にできた。【００９９】
一方、特にＡＰＩ送受信バッファ内の送信データは、対向端点からの確認応答の到着によって削除されるため、ＡＰＩ送受信バッファが空になるまでの時間は、対向端点の動作やネットワークの状態に依存することになる。第一の実施の形態では、稼動系が、ＡＰＩ送受信バッファが空になるまで通信を行えない状態になるため、しかも、その時間が外部に依存するので、通信システムの適用環境によっては好ましくない場合もあり得る。第二の実施の形態では、稼動系のＡＰＩ送受信バッファを空にしなくても良い方式を説明する。【０１００】
図７は、第二の実施の形態における通信装置の構成を示すブロック図である。同図を参照すると、図７の通信ＡＰＩ冗長化処理部３２は、図２の通信ＡＰＩ冗長化処理部２２の構成に加えて、送信バッファ７２８と、確認応答済データ削除部７２９とを備えている。また、図７のパケットフィルタ冗長化処理部３８は、図２のパケットフィルタ冗長化処理部２８が備えるバッファ空き検出部２８５に代えて、確認応答検出部７８５を備えている。【０１０１】
第二の実施の形態における通信装置を有する通信システムの動作を説明する。まず、第一の実施の形態における［３．バッファ掃き出し処理］、［５．稼動系、追加系間でのパラメータ同期］に相当する動作を説明する。ここでは、重複説明を避けるため、異なる部分を中心に説明する。【０１０２】
図８Ａ及び図８Ｂは、ＡＰＩ送受信バッファを掃き出すかわりに、稼動系の送信データを追加系へ複製するために、追加系が冗長化される前に、稼動系の通信装置において行われる処理を説明する流れ図である。第一の実施の形態では、稼動系のＡＰＩ送受信バッファが空になるまで待機していたが、図８Ａに示すように、第二の実施の形態では、稼動系にて、書き込みＡＰＩが呼び出される都度（Ｓ８０１）、ＡＰＩ呼出し捕捉部で捕捉した書き込みデータを複製して（Ｓ８０２）、通信ＡＰＩ冗長化処理部の送信バッファに保持しておく（Ｓ８０３）。【０１０３】
次に、稼動系では、通信ＡＰＩ冗長化処理部が書き込みＡＰＩをコールして、送信データをプロトコル処理部に書き込むと（Ｓ８０４）、プロトコル処理部が送信処理を行う（Ｓ８０５）。書き込まれた送信データはパケットとして成形されて、稼動系の通信装置から送出される。このとき、稼動系の確認応答検出部では、送信データのシーケンス番号を記録しておく（Ｓ８０６）。【０１０４】
再送つき確認応答を行うＴＣＰやＳＣＴＰのようなプロトコルでは、対向ノードから、やがて該当シーケンス番号の送信データに対する確認応答が送られてくる。確認応答が届くと、プロトコル処理部はＡＰＩ送受信バッファから該当する送信データを削除する。【０１０５】
図８Ｂに示すように、稼動系のネットワークインタフェース部が、対向ノードから送出されるパケットを受信すると（Ｓ８０７）、パケットフィルタ冗長化処理部の確認応答検出部は、受信パケットの確認応答を調べる（Ｓ８０８）。確認応答検出部は、ステップＳ８０６で記録した送信データに対する確認応答が通過すれば、確認応答が済んだ送信データを特定して、通信ＡＰＩ冗長化処理部の確認応答済データ削除部へ通知する（Ｓ８０９）。【０１０６】
確認応答済データ削除部では、該当通知に基づいて送信バッファから確認応答済データを削除する（Ｓ８１０）。これにより、ＡＰＩ送受信バッファと同一の内容の送信データを、通信ＡＰＩ冗長化処理部で保持できる。【０１０７】
この時、確認応答が到着する度に、確認応答検出部から確認応答済データ削除部へ通知を行うと、通知処理のコストが無視できないことがあるため、たとえば、次のようにしても良い。【０１０８】
確認応答済のデータを識別する情報を保持する領域を設け、確認応答検出部は、確認応答を受信する都度、該当情報を更新する。また、同情報は確認応答済データ削除部から参照できるようにしておき、所定の間隔、例えば、通信ＡＰＩ冗長化処理部の送信バッファが一杯になる都度、該当情報を参照して確認応答済データを削除する。【０１０９】
また、稼動系の既設セッションを追加系に冗長化する処理が開始されたら、確認応答済データ削除部は直ちに上記情報を参照して確認応答済データを送信バッファから削除する。【０１１０】
次に、第一の実施の形態で説明した図４に相当する部分の動作を説明する。図９は、稼動系の既設セッションを追加系に冗長化するための準備処理を説明する流れ図である。図９において、まず、第一の実施の形態で説明した場合と同じようにして、パラメータ同期などを行う。すなわち、図４のステップＳ４０１〜Ｓ４０３と同様のステップＳ９０１〜Ｓ９０３を実行し、図４のステップＳ４０６、Ｓ４０８〜Ｓ４１３と同様のステップＳ９０４〜Ｓ９１０を実行する。これらの処理が完了した時点で、プロトコル処理部内のプロトコル端点のパラメータやシーケンス番号等の値は稼動系と追加系とで一致する。ただし、ＡＰＩ送受信バッファの送信データは一致していない。【０１１１】
そこで、稼動系から追加系へ、稼動系の通信ＡＰＩ冗長化処理部における送信バッファ内の送信データを転送する（Ｓ９１１）。追加系の通信ＡＰＩ冗長化処理部では、この送信データを受信し（Ｓ９１２）、書き込みＡＰＩを通して、プロトコル処理部に、該当データをすべて書き込む（Ｓ９１３）。【０１１２】
さらに、稼動系で未送信シーケンス番号の値を取得し、該当シーケンス番号を追加系へ送信する。追加系の通信ＡＰＩ冗長化処理部では、プロトコルパラメータ補正部にて、未送信シーケンス番号の値を稼動系に合わせる（Ｓ９１４）。稼動系では、読み込みＡＰＩをコールし受信バッファ内のデータを読み出す（Ｓ９１５）。その後の処理は、図５ａ又は図５ｂにて説明した第一の実施の形態の場合と同様である。【０１１３】
なお、追加系において、ステップＳ９１３で書き込んだ送信データが、ステップＳ９０９のパラメータ補正前に、実際どれだけ送信されたかは考慮しなくて良い。この操作は、追加系において、通信ＡＰＩ部以下の下位に位置するプロトコル層の状態を稼動系と同一にするのが目的であり、また、追加系で作成される送信パケットは、パケットフィルタ冗長化処理部にて全て遮断されているので、外部へ送出されることは無いためである。【０１１４】
次に、本発明を実施するための最良の形態のさらに別の一つについて詳述する。この第三の実施の形態は、「稼動系のサーバ用プロトコル端点を、追加系にサーバ用プロトコル端点として冗長化できる方式」である。第一の実施の形態では、サーバ用ソケットＡＰＩを用いて開設されたセッションを冗長化する際にも、クライアント用ソケットＡＰＩを用いている。そのため、追加系では、稼動系とコネクションの開設方向が逆向きになり、稼動系から送信するセッション開設パケットに加工が必要になっていた。第三の実施の形態では、稼動系において、サーバ用ソケットＡＰＩにより開設されたセッションを、追加系でもサーバ用ソケットＡＰＩを用いて冗長化する方式を説明する。【０１１５】
図１０は、第三の実施の形態における通信装置の構成を示すブロック図である。第三の実施の形態では、プロトコル処理部に拡張を加えている。図１０に示すように、通信装置４０のプロトコル処理部４７に、受動的開設セッション用の初期シーケンス番号列を保持できる初期シーケンス番号保持部２７１を設けている。また、通信ＡＰＩ冗長化処理部４２のプロトコルパラメータ補正部４２７を通して、上記初期シーケンス番号列をセットできるようにしている。保持可能なシーケンス番号の個数は、リッスンシステムコールにより指定するアクセプト待ちキューの長さよりも少なくとも１多い値とする。例えば、アクセプト待ちキューの長さが１０であれば、保持可能なシーケンス番号列の最大長を１１とすることができる。【０１１６】
図１１は、第三の実施の形態において、稼動系のサーバ用プロトコル端点を追加系に冗長化する処理を説明する流れ図である。重複説明を避けるため、図４及び図５ｂで説明した第一の実施の形態の場合と異なる部分を中心に説明する。第三の実施の形態においては、ＡＰＩ送受信バッファを空にするところまでは、第一の実施の形態におけるステップＳ４０１〜Ｓ４０７と共通である。図１１は、それ以降のサーバ用プロトコル端点の冗長化処理について説明している。【０１１７】
パラメータ同期については、次のように行う。稼動系において、第一の実施の形態と同様に、プロトコルパラメータを補正したあと、開設済セッションを所定の順序に並べる（ＳＢ０１）。稼動系のパケットフィルタ冗長化処理部は、並び替えたセッション順に、追加系へ、開設済セッションの初期シーケンス番号を送信する（ＳＢ０２）。【０１１８】
図１２は、稼動系に蓄積される初期シーケンス番号の説明図であり、図示されているような初期シーケンス番号が稼動系から追加系のプロトコルパラメータ補正部へ送出される。図１２に示すように、稼動系から追加系へ送出する初期シーケンス番号は、稼動系のセッション開設パケット蓄積部に蓄積されているセッション開設パケットの中に含まれている。そこで、第三の実施の形態では、初期シーケンス番号を含むこれらのセッション開設パケットを用いて、稼動系から追加系へ初期シーケンス番号列を送信することにする。図１３は、セッション開設パケットのＩＤをキーとして、図１２のセッション開設パケットを並び替えた例を示す図である。稼動系は、初期シーケンス番号を所定の順序に並び替えた後、初期シーケンス番号列を追加系へ送信する。【０１１９】
追加系では、稼動系から初期シーケンス番号列を受信すると（ＳＢ０３）、通信ＡＰＩ冗長化処理部のプロトコルパラメータ補正部が、プロトコル処理部の初期シーケンス番号保持部に、稼動系で並び替えた順に、シーケンス番号を書き込む（ＳＢ０４）。稼動系から受信した初期シーケンス番号の個数が、初期シーケンス番号保持部が保持可能なシーケンス番号の個数を超えていた場合には、プロトコルパラメータ補正部は、書き込み可能な数だけシーケンス番号を書き込み、残りは初期シーケンス番号保持部に空きができ次第、後から書き込むことにする。【０１２０】
追加系のプロトコル処理部は、該当雛形端点にコネクションが到着すると、初期シーケンス番号としてこの値を並び順に使うように設定しておく。端点作成処理では、サーバ用ソケットＡＰＩを用いてプロトコル端点を作成する通常の手順にしたがって、バインドシステムコールにより端点を固定し（ＳＢ０５）、リッスンシステムコール（ＳＢ０６）、アクセプトシステムコール（ＳＢ０７）を順に発行する。【０１２１】
稼動系では、追加系へ初期シーケンス番号列を送信した後、その並び順に、パケットフィルタ冗長化処理部のセッション開設パケット蓄積部を検索する（ＳＢ０８−２）。そして、並び替えられたセッションの順番と同一の順番に、セッション開設パケット蓄積部からセッション開設パケットを取り出し、追加系へ送信する（ＳＢ０９）。【０１２２】
稼動系のセッション開設パケット蓄積部は、セッションごとにキューを有し、セッションごとにセッション開設パケットを蓄積している。図１４は、図１３の並び替えにより最初のセッションとなったセッションのキューにエンキューされたセッション開設パケットを説明する図である。図１４に示すように、最初のセッションのキューには、ＳＹＮフラグがセットされたセッション開設パケットと、ＡＣＫフラグがセットされたセッション開設パケットとがエンキューされている。対向ノードのアドレスは、１９２．１６８．１５３．１２であり、ポート番号は、４８２１２である。また、稼動系のアドレスは、１９２．１６８．１．８であり、ポート番号は、５０６０である。稼動系では、最初に、これらのセッション開設パケットを取り出して、追加系へ送信することになる。【０１２３】
図１５Ａ、図１５Ｂ、及び、図１５Ｃは、図１３の並び替えにより最初のセッションとなったセッションと同じセッションを、追加系に開設するときに、追加系と稼動系との間で交換されるセッション開設パケットについて説明する図である。図１５Ａに示すように、まず、稼動系から追加系へ、ＳＹＮフラグがセットされたセッション開設パケットが送出される。次に、図１５Ｂに示すように、追加系のプロトコル処理部から対向端点へ向けて、ＳＹＮ／ＡＣＫフラグがセットされたセッション開設パケットが送出されるが、このパケットは、追加系のパケットフィルタ冗長化処理部の通信遮断部によって破棄される。続いて、図１５Ｃに示すように、稼動系から追加系へ、ＡＣＫフラグがセットされたセッション開設パケットが送出される。これにより、追加系のプロトコル処理部は、最初のセッションを開設することができる。【０１２４】
最初のセッションを開設するとき、追加系のプロトコル処理部は、ＰＣＢエントリの該当セッションに、初期シーケンス番号を割り当てる。ここで、追加系のプロトコル処理部は、初期シーケンス番号保持部から、順番が一番目となっている初期シーケンス番号を取り出し、割り当てる。【０１２５】
セッションが一本確立されると、ソケット記述子が生成される。このソケット記述子は、アクセプトシステムコールの戻り値として得られる。【０１２６】
この時点で、初期シーケンス番号保持部には空きがひとつできる。プロトコルパラメータ補正部は、初期シーケンス番号保持部に未だ書き込んでいない残りの初期シーケンス番号があれば、その初期シーケンス番号を順番に書き込む（ＳＢ１０）。【０１２７】
図１６は、追加系に最初のセッションが開設されるときにおける、ＰＣＢエントリと初期シーケンス番号保持部のデータ内容について説明する図である。図１６において、初期シーケンス番号保持部が保持可能なシーケンス番号の個数を”４”としている。セッション開設前においては、図１６上段ボックスに示されているように、追加系のプロトコル処理部には、サーバ用ＰＣＢエントリが一つだけ有り、また、４個の初期シーケンス番号が保持されている。セッション開設パケットの交換により、最初のセッションが開設されると、図１６中段ボックスに示されているように、ＰＣＢエントリが一つ追加される。このＰＣＢエントリにおけるシーケンス番号には、初期シーケンス番号列における最初の初期シーケンス番号である”０ｘ８８３ａｆｃ８１”が割り当てられている。”０ｘ８８３ａｆｃ８１”の割り当てにより、初期シーケンス番号保持部には、空きが一つできる。図１６下段ボックスは、この空きに対して、”０ｘ３８１ａ８ｂｄ５”の初期シーケンス番号が書き込まれたところを示している。この”０ｘ３８１ａ８ｂｄ５”は、図１３に示されているＩＤが５であるセッションの初期シーケンス番号である。【０１２８】
以降、上記のセッション冗長化処理をセッション毎に繰り返すことにより（ＳＢ０８）、サーバ用ソケットＡＰＩを用いて、既設セッションのプロトコル状態とソケット記述子とを、追加系に冗長化できる。全セッションが冗長されると、追加系は、稼動系に同期処理完了を通知する（ＳＢ１１）。稼動系は、この同期処理完了を受信する（ＳＢ１２）。【０１２９】
図２、図７、及び、図１０に示した各機能ブロックは、コンピュータをこれらの機能ブロックとして動作させるプログラムによって実現することができる。また、このプログラムは記録媒体に格納することができ、コンピュータに読み込ませることによって、上記実施の形態における各通信装置を構築することが可能である。【０１３０】
以上、実施の形態を参照して本願発明を説明したが、本願発明は上記実施の形態に限定されるものではない。本願発明の構成や詳細には、請求の範囲に記載された本願発明の技術的思想の範囲内において、当業者が適宜、様々な変形又は変更を加えることが可能である。【０１３１】
この出願は、２００８年１月２１日に出願された特許出願番号２００８−０１０８６０号の日本特許出願に基づいている。本願は、この基礎出願により生じた優先権の利益を享受しており、この基礎出願における開示の内容の全てを、引用により、そっくりそのままここに取り込んでいる。
【図１】
2009093378.tif 000003
【図２】
2009093378.tif 000004
【図３】
2009093378.tif 000005
【図４】
2009093378.tif 000006
【図５ａ】
2009093378.tif 000007
【図５ｂ】
2009093378.tif 000008
【図６−１】
2009093378.tif 000009
【図６−２ａ】
2009093378.tif 000010
【図６−２ｂ】
2009093378.tif 000011
【図７】
2009093378.tif 000012
【図８Ａ】
2009093378.tif 000013
【図８Ｂ】
2009093378.tif 000014
【図９】
2009093378.tif 000015
【図１０】
2009093378.tif 000016
【図１１】
2009093378.tif 000017
【図１２】
2009093378.tif 000018
【図１３】
2009093378.tif 000019
【図１４】
2009093378.tif 000020
【図１５Ａ】
2009093378.tif 000021
【図１５Ｂ】
2009093378.tif 000022
【図１５Ｃ】
2009093378.tif 000023
【図１６】
2009093378.tif 000024
【手続補正書】
【提出日】平成22年7月20日(2010.7.20)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
セッションを開設して、対向ノードと通信するプロトコル処理部と、
前記プロトコル処理部がセッションを開設するときに、前記対向ノードから受信するセッション開設パケットを蓄積する手段と、予め決められた手順で、前記蓄積する手段が蓄積するセッション開設パケットを、他の通信装置へ送信する手段とを具備する第一の冗長化処理部とを備え、
前記第一の冗長化処理部は、
前記セッション開設パケットによって開設されたセッションと同一のセッションにかかるパケットが通過した場合に、前記かかるパケットに基づいて、前記蓄積する手段が蓄積するセッション開設パケットにおける所定のプロトコルパラメータを補正する手段を更に具備し、
前記補正する手段は、
前記所定のプロトコルパラメータとして、前記同一のセッションにかかるパケットが通過する都度、更新されるプロトコルパラメータを含むものを補正すると共に、前記他の通信装置が、前記送信する手段が送信するセッション開設パケットを用いて、前記プロトコル処理部が開設したセッションを冗長化したセッションを開設する場合に、前記他の通信装置が、前記冗長化したセッションを開設した後に、前記対向ノードから継続して送信されるパケットを受信できるように、前記所定のプロトコルパラメータを補正する
通信装置。
【請求項２】
請求項１に記載の通信装置において、
上位のプロトコル層と、前記プロトコル処理部とを接続する通信ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）部と、
前記通信ＡＰＩ部を制御する第二の冗長化処理部とを更に備え、
前記第二の冗長化処理部は、
前記他の通信装置が前記セッション開設パケットによってセッションを開設するときに用いる所定のセッション開設基礎データを、前記他の通信装置に送信する手段を具備し、
前記第二の冗長化処理部の前記送信する手段は、
前記所定のセッション開設基礎データとして、少なくともソケット記述子番号を送信する
通信装置。
【請求項３】
請求項２に記載の通信装置において、
前記プロトコル処理部が前記対向ノードへ送信データを送出したときに、前記送信データを前記対向ノードが受信したことを示す確認応答が届くまで、前記送信データを保持するＡＰＩ送受信バッファを更に備え、
前記第一の冗長化処理部は、
前記ＡＰＩ送受信バッファが空になったことを検出する手段を更に具備し、
前記第二の冗長化処理部の前記送信する手段は、
前記検出する手段が、前記ＡＰＩ送受信バッファが空になったことを検出した後に、前記所定のセッション開設基礎データを送信し、
前記第一の冗長化処理部の前記送信する手段は、
前記検出する手段が、前記ＡＰＩ送受信バッファが空になったことを検出した後に、前記蓄積する手段が蓄積するセッション開設パケットを送信する
通信装置。
【請求項４】
請求項３に記載の通信装置において、
前記第一の冗長化処理部の前記送信する手段は、
前記対向ノード側がサーバとしてセッションが開設されていた場合に、前記蓄積する手段が蓄積するセッション開設パケットを、あて先と発信元とが入れ替わるように加工することなく、前記他の通信装置へ送信し、
前記対向ノード側がクライアントとしてセッションが開設されていた場合に、前記蓄積する手段が蓄積するセッション開設パケットを、サーバ側からクライアント側へ送信されるセッション開設パケットになるように加工してから、前記他の通信装置へ送信する
通信装置。
【請求項５】
請求項４に記載の通信装置において、
前記第二の冗長化処理部は、
前記通信ＡＰＩ部から前記プロトコル処理部へ渡される送信データを保持する手段と、
確認応答が届いた場合に、前記渡される送信データを削除する手段と、
前記保持する手段が保持する送信データを前記他の通信装置へ転送する手段とを更に具備すると共に、
前記対向ノード側がクライアントとして複数のセッションが開設されていた場合には、
前記第二の冗長化処理部の前記送信する手段は、
各セッションに対応する初期シーケンス番号を、所定の順序に並び替えてから、前記他の通信装置へ送信し、
前記第一の冗長化処理部の前記送信する手段は、
前記蓄積する手段が蓄積するセッション開設パケットを、セッションごとに、前記所定の順序と同じ順序になるように並び替えてから、前記他の通信装置へ送信する
通信装置。
【請求項６】
請求項５に記載の通信装置において、
請求項１〜５のいずれかに記載された通信装置と同じ構成を有する別の通信装置から、予め決められた手順で、セッション開設パケットを受信してセッションを開設する通信装置であって、
下位のプロトコル層と、前記プロトコル処理部とを接続するネットワークインタフェース部を更に備え、
前記第一の冗長化処理部は、
前記別の通信装置に対して、セッション開設パケットを送信するように要求する手段と、
前記ネットワークインタフェース部が送受信する所定のパケットの通過を遮断する手段とを更に具備し、
前記遮断する手段は、
前記別の通信装置から受信するセッション開設パケットの通過を許容し、このセッション開設パケットに応答して、前記プロトコル処理部から送出されるパケットの通過を遮断する
通信装置。
【請求項７】
請求項６に記載の通信装置において、
前記別の通信装置を、請求項２〜５のいずれかに記載された通信装置と同じ構成を有する別の通信装置として、所定のセッション開設基礎データを受信する通信装置であって、
前記第二の冗長化処理部は、
前記プロトコル処理部がプロトコル端点を作成することを制御する端点制御手段と、前記プロトコル処理部がプロトコル端点を作成するために用いるプロトコルパラメータを補正する手段とを更に具備し、
前記第二の冗長化処理部の前記補正する手段は、
前記所定のセッション開設基礎データを前記別の通信装置から受信すると共に、受信した所定のセッション開設基礎データを前記プロトコル処理部に与え、
前記端点制御手段は、
前記第二の冗長化処理部の前記補正する手段が、前記受信した所定のセッション開設基礎データを前記プロトコル処理部に与えると、前記プロトコル処理部がプロトコル端点を作成するように制御する
通信装置。
【請求項８】
請求項７に記載の通信装置において、
前記別の通信装置を、請求の範囲５に記載された通信装置と同じ構成を有する別の通信装置として、前記別の通信装置における第二の冗長化処理部の転送する手段によって転送される送信データを受信する通信装置であって、
前記第二の冗長化処理部は、
前記プロトコル処理部に送信データを書き込むことを制御する書き込み制御手段を更に具備し、
前記書き込み制御手段は、
前記別の通信装置において確認応答されていない送信データを、前記別の通信装置から受信すると共に、前記確認応答されていない送信データを前記プロトコル処理部に書き込むように制御する
通信装置。
【請求項９】
セッションを開設して通信する第一のプロトコル処理部を備える第一の通信装置を稼動することと、
前記第一のプロトコル処理部が対向ノードとセッションを開設するときに、前記第一の通信装置が前記対向ノードから受信するセッション開設パケットを蓄積することと、
前記第一の通信装置が稼動している通信システムに、セッションを開設して通信する第二のプロトコル処理部を備える第二の通信装置を追加することと、
前記第二の通信装置へ、前記蓄積することによって蓄積されたセッション開設パケットを送信することと、
前記送信することによって送信されるセッション開設パケットによって、前記第二の通信装置にセッションを開設することとを備え、
前記蓄積することは、
前記セッション開設パケットによって開設されたセッションと同一のセッションにかかるパケットが通過した場合に、前記かかるパケットに基づいて、前記蓄積することによって蓄積されたセッション開設パケットにおける所定のプロトコルパラメータを補正することを含み、
前記補正することは、
前記同一のセッションにかかるパケットが通過する都度、更新されるプロトコルパラメータの補正を行うことを含むと共に、前記第二の通信装置が、前記送信されるセッション開設パケットを用いて、前記第一のプロトコル処理部が開設したセッションを冗長化したセッションを開設する場合に、前記第二の通信装置が、前記冗長化したセッションを開設した後に、前記対向ノードから継続して送信されるパケットを受信できるように、前記所定のプロトコルパラメータの補正を行うことを含む
通信装置の冗長化方法。
【請求項１０】
請求項９に記載の通信装置の冗長化方法において、
前記追加することは、
前記第二の通信装置から前記第一の通信装置へ、セッション開設パケットを送信するように要求することと、
前記第二の通信装置が送受信する所定のパケットの通過を遮断することとを含み、
前記遮断することは、
前記第二の通信装置が前記第一の通信装置から受信するセッション開設パケットを通過させることと、
このセッション開設パケットに応答して、前記第二のプロトコル処理部から前記対向ノード宛に送出されるパケットの通過を遮断することとを含む
通信装置の冗長化方法。
【国際調査報告】
2009093378.tif 000025
2009093378.tif 000026