JP2009266202A - セッション管理システム、その制御方法、及びクライアント端末 - Google Patents

Abstract

【課題】１つのネットワークインタフェースに対して複数の通信アドレスが割り当てられた場合に、ネットワークリソースを効率的に利用し、或いは低減できるようにする。
【解決手段】クライアントアプリケーションから要求された宛先アドレスと異なるアドレスで、且つサーバ識別子（サーバ識別情報）で識別されるサーバが同一の既存セッションを確認した場合には（Ｓ７０３）、同一サーバ識別子の既存セッションをデータ通信用のセッションとして選択し（Ｓ７０７）、選択されたセッションでデータ転送する（Ｓ７０８）。
【選択図】図７

Description

本発明は、アプリケーション間の通信に係る論理的な接続関係を示すセッションの管理技術に関する。

従来、ネットワーク（イントラネット、インターネットなどのＬＡＮ）に接続されて用いられる通信装置として、ＰＣ（パーソナルコンピュータ）、プリンタ、ＭＦＰなど様々の情報処理装置が知られている。

現在、ネットワーク接続される情報処理装置では、ＩＰプロトコルが広く利用されており、このＩＰプロトコルでは、各情報処理装置に固有のＩＰアドレス（通信アドレス）を割り当てることにより、接続先の機器を相互に識別している。

従来のＩＰ規約（ＩＰｖ４：ＩＰバージョン４）の下では、一般に、ネットワーク上の他の情報処理から装置を識別するためのＩＰアドレスとしては、１つのネットワークインタフェースについて１つのＩＰアドレスが付与されていた。

一方、近年普及しつつあるＩＰｖ６（ＩＰバージョン６）の下では、端末は、ルータに接続された際に、そのルータとの間で通信を行って自動的にＩＰアドレスを取得している。また、ルータが存在しない場合も通信を行えるようにすべく、そのＩＰアドレスとは別に、ネットワークインタフェース毎にＩＰｖ６アドレスが割り当てられる。

さらに、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバが存在する場合もある。このように、ＩＰｖ６を使用する環境では、複数のＩＰｖ６アドレスが１つのネットワークインタフェースに割り当てられる。その結果、ＩＰｖ６アドレスをサポートする情報処理装置においては、１つのネットワークインタフェースに対して、ＩＰｖ４アドレスや複数のＩＰｖ６アドレスが割り当てられることとなる。

また、情報処理装置同士が通信を行う場合は、送信元と送信先のネットワークソケット、即ちＩＰアドレスとポート番号の組が作成される。このネットワークソケットの作成処理は、情報処理装置のネットワークリソースであるメモリやＣＰＵ処理時間を消費する。

そのため、多数の情報処理装置と接続して通信を行うサーバは、その接続数に応じたネットワークリソースを消費する。一方、プリンタやＭＦＰなどの情報処理装置は、サーバと比べて利用可能なネットワークリソースが小さいために、同時に接続できる通信機器の数は少なくなっている。

さらに、ＴＣＰ通信の場合は、データサイズの如何を問わず、ネットワークソケットを開放するまでの時間が、ＵＤＰ通信の場合に比べて長くなっている。このため、ＴＣＰ通信の場合は、単位時間での同時接続数がＵＤＰ通信の場合に比べて少なくなり、サーバでは、クライアントからのリクエストが多い場合に接続エラーが発生してしまう。

そこで、クライアント／サーバシステムで、クライアントの複数のアプリケーションが複数のセッションを確立して同一アドレスのサーバと通信する場合に、ネットワークリソースを節約できるようにする提案がなされている（特許文献１参照）。

特開平１０−１７７５４８号公報

しかしながら、上記の特許文献１では、１つのネットワークインタフェースに対して複数のＩＰｖ６アドレスが割り当てられた場合は、同一サーバに対する通信であっても、複数のサーバアドレスに対するネットワークリソースを削減することはできなかった。

本発明は、上記の問題点に鑑みてなされたもので、その目的は、１つのネットワークインタフェースに対して複数の通信アドレスが割り当てられた場合に、ネットワークリソースを効率的に利用し、或いは低減できるようにすることにある。

上記目的を達成するため、本発明は、クライアント端末のクライアントアプリケーションと複数のアドレスを有するサーバのサーバアプリケーションとの間のセッションを管理するセッション管理システムにおいて、前記クライアント端末は、セッションを確立するために前記サーバのサーバ識別情報を取得する取得手段と、セッション情報及び前記サーバ識別情報を含むセッション管理情報を記憶する記憶手段と、前記クライアントアプリケーションが接続要求時に指定した宛先アドレスと異なるアドレスに係る既存セッションであって、前記サーバ識別情報で識別されるサーバが一致する既存セッションが前記記憶手段に記憶されているか否かを判別する判別手段と、前記判別手段により前記既存セッションが記憶されていると判別された場合に、当該既存セッションをデータ通信用のセッションとして選択する選択手段と、を有することを特徴とする。

本願発明によれば、クライアントアプリケーションから要求された宛先アドレスと異なるアドレスであって、サーバ識別情報で示されるサーバが一致する既存セッションでデータ通信を行うことができる。

従って、１つのネットワークインタフェースに対して複数の通信アドレスが割り当てられた場合に、ネットワークリソースを効率的に利用し、或いは低減できるようにすることが可能となる。

本発明の第１〜第３の実施の形態に係るセッション管理システムを適用したクライアント／サーバシステムのソフトウェアの構成を示す図である。 図１のクライアントＰＣ、サーバＰＣのハードウェアの構成を示すブロック図である（第１〜３の実施の形態）。 サーバＰＣのサーバプロセス間通信部の詳細なソフトウェア構成を示すブロック図である（第１〜３の実施の形態）。 クライアントＰＣのクライアントプロセス間通信部の詳細なソフトウェア構成を示すブロック図である（第１〜３の実施の形態）。 セッション管理情報を例示した図である（第１〜７（６）の実施の形態）。 本発明の第１の実施の形態においてサーバＰＣのサーバプロセス間通信部が行うセッション管理処理を示すフローチャートである。 本発明の第１の実施の形態においてクライアントＰＣのクライアントプロセス間通信部が行うセッション管理処理を示すフローチャートである。 図６、図７の処理の具体例を示すシーケンス図である（既存セッションが存在しない場合）。 図６、図７の処理の具体例を示すシーケンス図である（既存セッションが存在する場合）。 本発明の第２の実施の形態においてクライアントＰＣのクライアントプロセス間通信部が行うセッション管理処理を示すフローチャートである。 本発明の第２の実施の形態においてサーバＰＣとクライアントＰＣの間で行われるセッション管理処理を示すシーケンス図である。 本発明の第３の実施の形態においてクライアントＰＣのクライアントプロセス間通信部が行うセッション管理処理を示すフローチャートである。 本発明の第３の実施の形態においてサーバＰＣとクライアントＰＣの間で行われるセッション管理処理を示すシーケンス図である。 本発明の第４〜６の実施の形態に係るセッション管理システムを適用したクライアント／サーバシステムのソフトウェアの構成等を示す図である。 第４の実施の形態に係るクライアントＰＣのクライアントプロセス間通信部の詳細なソフトウェア構成を示すブロック図である。 第４の実施の形態に係るアドレスリスト情報を示す図である。 第４の実施の形態に係るセッション管理情報を示す図である。 第４の実施の形態に係るセッション管理処理を示すフローチャートである。 図１８のステップＳ１８０１におけるアドレスリスト取得処理の詳細を示すフローチャートである。 本発明の第５の実施の形態に係るセッション管理処理を示すフローチャートである。 図２０の続きのフローチャートである。 本発明の第６の実施の形態に係るセッション管理処理を示すフローチャートである。 同一のサーバが異なるサーバ識別情報で指定された場合の取り扱いを説明するためのアドレスリスト情報を例示した図である。 本発明の第７の実施の形態に係るクライアントＰＣのクライアントプロセス間通信部の詳細なソフトウェア構成を示すブロック図である。 第７の実施の形態に係るセッション管理情報を例示した図である。 第７の実施の形態に係るセッション管理処理を示すフローチャートである。 図２６の続きのフローチャートである。

以下、本発明を実施するための最良の形態を図面に基づいて説明する。なお、以下に説明する第１〜９の実施の形態は、特許請求の範囲に係る発明を限定するものではなく、また、第１〜９の実施の形態に係る特徴事項の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

［第１の実施の形態］
図１は、本発明の第１〜３，７の実施の形態に係るセッション管理システムを適用したクライアント／サーバシステムのソフトウェアの構成を示す図である。

図１において、クライアントＰＣ（クライアント端末）１００とサーバＰＣ１０５は、ネットワーク１０６を介して接続されている。本実施の形態では、ネットワーク１０６としては、ＬＡＮやＷＡＮを想定しているが、これ以外のネットワークを用いることも可能である。また、クライアントＰＣ１００とサーバＰＣ１０５は、ネットワーク１０６を介して接続されることなく、ＩＥＥＥ１３９４、ＩＥＥＥ１２８４などの規格に係るインタフェース（ケーブル）で接続することも可能である。

また、第１〜７の実施の形態では、クライアントＰＣ１００としては、プリンタ、ＭＦＰ（マルチファンクション・プリフェラル）を想定している。だだし、ネットワーク通信機能を有する携帯型情報端末、スキャナ装置、ファクシミリ装置等の各種の機器にも第１〜８の実施の形態に係る特徴事項を適用することが可能である。

クライアントＰＣ１００には、クライアントアプリケーション１０１，１０１ａが搭載されている。ただし、１つ又は３つ以上のクライアントアプリケーションが搭載されている場合にも第１の実施の形態を適用することができる（第２〜７の実施の形態も同様）。

クライアントアプリケーション１０１，１０１ａは、それぞれ対応するスタブオブジェクト１０２，１０２ａを利用して通信を行う。この際、実際の通信処理は、クライアントプロセス間通信部１０３によって行われる。

クライアントプロセス間通信部１０３は、オペレーティングシステムの通信ライブラリ１０４ａを用いてサーバＰＣ１０５と通信を行う。なお、通信ライブラリ１０４ａには、ソケット（ＩＰアドレス＋ポート番号）通信以外に、ＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）やＬＰＣ（Ｌｏｃａｌ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）、Ｗｅｂサービス等による通信も含まれている。

サーバＰＣ１０５では、サーバアプリケーション１０８が動作している。サーバアプリケーション１０８は、サーバプロセス間通信部１０７を用いて通信を行う。サーバプロセス間通信部１０７は、通信ライブラリ１０４ｂに基づいて、ネットワーク１０６を介してクライアントＰＣ１００と通信を行う。なお、サーバアプリケーション１０８は、１つであっても複数であってもよい。

上記のように、クライアントアプリケーション１０１，１０１ａとサーバアプリケーション１０８との間の実際の通信処理は、クライアントプロセス間通信部１０３とサーバプロセス間通信部１０７により行なわれる。この実際の通信処理には、一連の要求／応答に係るセッション管理処理も含まれる。換言すれば、クライアントプロセス間通信部１０３、サーバプロセス間通信部１０７により、本発明に特有なセッション管理処理が行われる。

なお、図１のクライアント／サーバシステムは、クライアントとサーバが共にＰＣ（コンピュータ）で構成されている。しかし、他のネットワークデバイス、通信機能を有する情報処理装置、周辺装置等で構成されたクライアント／サーバシステムに第１〜第３の実施の形態を適用してもよい。この場合、クライアントＰＣ１００又はサーバＰＣ１０５でのプログラムの動作を、これ以外のネットワークデバイス等のＣＰＵ、ＲＯＭ、ＲＡＭ等を用いて実行するように構成すればよい。

クライアントＰＣ１００、サーバＰＣ１０５は、図２に示したようなハードウェアで構成のコンピュータ２０００により実現される。

このコンピュータ２０００は、本体制御部２００と、その周辺機器としてのキーボード２０９、表示装置２１０、外部メモリ２１１を有している。本体制御部２００は、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、キーボード制御部２０５、表示制御部２０６、ディスク制御部２０７、及びネットワーク制御部２０８を有している。

ＣＰＵ２０１は、システムバス２０４に接続された各デバイスを統括的に制御する。このＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭ２０３ｂ、或いは外部メモリ（ＨＤ）２１０に記憶されたアプリケーション（文書処理プログラム又はサービス提供プログラム等）に基づいて、文書処理又はサービス提供処理等の各種処理を実行する。

なお、文書処理プログラムは、図形、イメージ、文字、表（表計算等を含む）等が混在した文書処理を行うものである。また、クライアントＰＣ１００における外部メモリ２１０には、文書処理に係るアプリケーションだけでなく、静止画や動画に係る画像情報、音楽情報、音情報を含む映像情報等の各種の情報を取得・処理するためのアプリケーションを格納してもよい。

また、ＣＰＵ２０１は、例えばＲＡＭ２０２上に設定された表示ＲＡＭへのアウトラインフォントの展開（ラスタライズ）処理を実行し、表示制御部２０６を介して文字列を表示装置２１０に表示する。更に、ＣＰＵ２０１は、この表示装置２１０上のマウスカーソル（図示略）等で指示されたコマンドに基づいて、種々のウインドウを開いて種々のデータ処理等又はサービス提供処理等を実行する。ユーザは、クライアントアプリケーション１０１，１０１ａやサーバアプリケーション１０８を使用する際、そのアプリケーションの設定操作等に関するウインドウを開き、このウインドウ上で各種の設定を行うことができる。なお、表示装置２１０としては、ＣＲＴ表示装置、液晶表示装置、プラズマ表示装置等を用いることができる。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として利用される。ＲＯＭ２０３は、フォント用ＲＯＭ２０３ａ、プログラム用ＲＯＭ２０３ｂ、データ用ＲＯＭ２０３ｃにより構成されている。

フォント用ＲＯＭ２０３ａ、外部メモリ２１１は、文書処理又はサービス提供処理等を行う際に使用するフォントデータ等を記憶している。プログラム用ＲＯＭ２０３ｂ、外部メモリ２１１は、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム等を記憶している。データ用ＲＯＭ２０３ｃ、外部メモリ２１１は、文書処理又はサービス提供処理等を行う際に使用する各種データ（プログラムを含む）を記憶している。なお、外部メモリ２１１に記憶されているプログラムは、実行時にはＲＡＭ２０２に展開される。

キーボード制御部２０５は、キーボード２０９やポインティングデバイス（不図示）からの入力データ、コマンドを制御する。表示制御部２０６は、表示装置２１０の表示動作を制御する。ディスク制御部２０７は、外部メモリ２１１に対するアクセスを制御する。

ネットワーク制御部２０８は、双方向性インタフェース２１２を介してネットワーク１０６に接続されている。このネットワーク制御部２０８は、図１に示したクライアントプロセス間通信部１０３又は１０７、通信ライブラリ１０４ａ又は１０４ｂに基づいてネットワークやセッションの接続、切断処理等を行う。

キーボード２０９は、各種のデータ、コマンド等を入力するためのキーを備えている。表示装置２１０は、文書処理又はサービス提供処理等に係る各種の情報等を表示する。外部メモリ２１１は、ハードディスク（ＨＤ）、フレキシブルディスク（ＦＤ）等により構成されている。この外部メモリ２１１は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル等を記憶している。なお、外部メモリ２１１は、アプリケーションとして、後述する図６〜図１３に係るフローチャート、シーケンスチャートに係る制御プログラムも記憶している。

図３は、サーバＰＣ１０５のサーバプロセス間通信部１０７の詳細なソフトウェア構成を示すブロック図である。

サーバプロセス間通信部１０７は、サーバプロセス間通信制御部３０１、サーバ識別子返信部３０２を有し、クライアントＰＣ１００からの通信リクエストに応答する。即ち、サーバプロセス間通信制御部３０１は、クライアントＰＣ１００からのリクエストに応じて、サーバ識別子返信部３０２によりサーバ識別子５０４（図５参照）を返信したり、サーバアプリケーション１０８で作成された返信データを返信したりする。このサーバ識別子５０４の返信処理の詳細は、後述する。

図４は、クライアントＰＣ１００のクライアントプロセス間通信部１０３の詳細なソフトウェア構成を示すブロック図である。なお、図４では、図１で説明したスタブオブジェクト１０２及び１０２ａの記載は省略している（図１５、図２４も同趣旨）。図４に示したように、クライアントプロセス間通信部１０３は、プロセス間通信制御部４０１、サーバ識別子取得部４０２、セッション管理部４０３、ＤＢ（データベース）管理部４０５、セッション切断管理部４０７、セッション再接続管理部４０９を有している。さらに、クライアントプロセス間通信部１０３は、セッション判定部４０４、セッション管理情報ＤＢ４０６、接続リファレンスカウント記憶部４０８を有している。

クライアントプロセス間通信部１０３は、プロセス間通信制御部４０１の制御の下にセッションの管理を行い、クライアントアプリケーション１０１，１０１ａとサーバアプリケーション１０８との間の通信動作を制御する。サーバ識別子取得部４０２は、サーバＰＣ１０５のサーバ識別子返信部３０２により返信されたサーバ識別子５０４を取得する。このサーバ識別子５０４は、使用するセッションを選択するために利用される。

セッション管理部４０３は、セッション情報の作成処理を行ったり、セッション管理情報ＤＢ４０６の中から一部の管理情報を削除するか否かを判断したりする。セッション判定部４０４は、接続要求時に指定された宛先アドレスと異なる宛先アドレスに係る既存セッションの中で、サーバ識別子５０４（サーバ特定用情報）で特定されるサーバが一致するものが存在するか否かを判定する。換言すれば、セッション判定部４０４は、新たにセッショションを確立して通信を行うか、或いは既存セッションを利用して通信を行うかを判定する。

ＤＢ管理４０５は、セッション管理情報ＤＢ４０６（図５参照）に対するアクセスを制御する。セッション切断管理部４０７は、接続リファレンスカウントに基づいてセッションの切断管理を行う。接続リファレンスカウント記憶部４０８は、接続リファレンスカウントを記憶する。この接続リファレンスカウントは、セッションをクローズするタイミングを決定するために利用される。セッション再接続管理部４０９は、通信エラーが発生したセッションで行っていた通信を、別のアドレス（ソケット）で再接続して行うための制御を行う。

図５は、セッション管理情報ＤＢ４０６に登録されているセッション管理情報を例示した図である。アプリケーション識別子５０１は、接続（コネクト）を要求したクライアントアプリケーション１０１，１０１ａを識別する識別子（インスタンスハンドル）である。

要求アドレス情報５０２は、クライアントアプリケーション１０１，１０１ａが接続を要求する際に宛先として指定した宛先アドレスである。この宛先アドレスは、ＩＰアドレス５０２ａとポート番号５０２ｂを含んでいる。通信アドレス情報５０３は、上記の宛先アドレスに基づいて既存セッションの利用可能性を判断した結果、実際に通信を行うものとして選択されたセッションに係る接続先（サーバＰＣ１０５）のアドレスである。この通信アドレスは、ＩＰアドレス５０３ａとポート番号５０３ｂを含んでいる。

なお、通信アドレス情報５０３には、ＩＰアドレス５０３ａ、ポート番号５０３ｂ以外に、ポート番号５０３ｂの代替情報としてのエンドポイント、或いはＩＰアドレス５０３ａ及びポート番号５０３ｂの代替情報としてのチャネル情報を含んでいてもよい。

サーバ識別子５０４は、接続要求元のクライアントアプリケーション１０１，１０１ａが宛先（アドレス、ポート番号等）に基づいてサーバＰＣ１０５に要求して取得したサーバ識別子（インスタンスハンドル）である。セッション番号５０５は、接続要求元のクライアントアプリケーション１０１，１０１ａと、接続先のサーバアプリケーション１０８との間で行なわれる一連の要求／応答（データ転送）に係るセッションを互いに識別するために付与される識別番号である。

次に、サーバＰＣ１０５のサーバプロセス間通信部１０７が行うセッション管理処理を、図６のフローチャートに基づいて説明する。

サーバプロセス間通信部１０７のサーバプロセス間通信制御部３０１は、クライアントＰＣ１００から接続要求を受けると、サーバ識別子返信部３０２により、サーバ識別子５０４を作成させる（ステップＳ６０１）。このサーバ識別子５０４としては、ＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）など、一意に特定できる識別子を用いる。これ以後、サーバＰＣ１０５のサーバプロセス間通信部１０７は、パケットを受信したソケットのＩＰアドレスやポート番号の如何を問わず、同一のサーバ識別子５０４を返信する。

次に、サーバプロセス間通信制御部３０１は、クライアントＰＣ１００からのパケットを通信ライブラリ１０４ｂを介して受信する（ステップＳ６０２）。そして、サーバプロセス間通信制御部３０１は、クライアントＰＣ１００から受信したパケットが、サーバ識別子５０４の取得要求に係るパケットであるか否かを判別する（ステップＳ６０３）。

その結果、サーバ識別子５０４の取得要求に係るパケットであれば、サーバプロセス間通信制御部３０１は、ステップＳ６０１でサーバ識別子返信部３０２により生成されたサーバ識別子５０４を、サーバ識別子５０４の取得要求元のクライアントＰＣに返信する。この処理は、ステップＳ６０４で行われる。この場合、サーバ識別子５０４は、返信パケットとして、通信ライブラリ１０４ｂを利用してネットワーク１０６経由でクライアントＰＣ１００に返信される。

次に、サーバプロセス間通信制御部３０１は、サービス終了の指示の有無を判別し（ステップＳ６０８）、サービス終了の指示が無ければ、ステップＳ６０２に戻ることにより、サービス提供を続行する。

一方、受信パケットがサーバ識別子５０４の取得要求に係るパケットでない場合は、サーバプロセス間通信制御部３０１は、受信パケットが新規データの受信要求（取得要求）に係るパケットであるか否かを判別する（ステップＳ６０５）。

その結果、新規データの取得要求に係るパケットであれば、サーバプロセス間通信制御部３０１は、クライアントＰＣ１００にデータ転送を行なうためのソケットを作成する（ステップＳ６０６）。このソケット作成処理は、通信ライブラリ１０４ｂを利用して、通信プロトコルとしてのＴＣＰプロトコルのａｃｃｅｐｔ処理により行われる。

サーバプロセス間通信制御部３０１は、ステップＳ６０６の処理の後は、ステップＳ６０７に進む。一方、新規データの受信要求（取得要求）に係るパケットでなければ、サーバプロセス間通信制御部３０１は、ステップＳ６０６のソケット作成処理をスキップして、ステップＳ６０７に進む。

ステップＳ６０７では、サーバプロセス間通信制御部３０１は、ステップＳ６０２で受信したパケットに係るサービス処理を、サーバアプリケーション１０８により実行させる。即ち、サーバプロセス間通信制御部３０１は、クライアントＰＣ１００からの受信データをサーバアプリケーション１０８に転送し、サーバアプリケーション１０８は、クライアントＰＣ１００からの要求に従って返信データを作成する。さらに、サーバアプリケーション１０８は、作成した返信データをサーバプロセス間通信制御部３０１に転送する。サーバプロセス間通信制御部３０１は、通信ライブラリ１０４ｂを利用して、ネットワーク１０６を経由してクライアントＰＣ１００に返信データを返信する。そして、サーバプロセス間通信制御部３０１は、上記のステップＳ６０８の処理を行う。

次に、クライアントＰＣ１００のクライアントプロセス間通信部１０３が行うセッション管理処理を、図７のフローチャートに基づいて説明する。なお、本フローチャートの処理は、直接には、プロセス間通信制御部４０１が行う（図１０、図１２、図１８、図２０、図２１、図２６も同様）。

クライアントプロセス間通信部１０３のプロセス間通信制御部４０１は、サーバＰＣ１０５のサーバアプリケーション１０８に対する接続要求を受け付ける（ステップＳ７０１）。この接続要求は、クライアントアプリケーション１０１，１０１ａから行われるものである。

次に、プロセス間通信制御部４０１は、上記の宛先アドレスに応じてサーバＰＣ１０５から返信されて来るサーバ識別子５０４を、サーバ識別子取得部４０２を介して取得する（ステップＳ７０２）。即ち、サーバ識別子取得部４０２は、プロセス間通信制御部４０１の制御の下に、通信ライブラリ１０４ａを利用し、ネットワーク１０６経由でサーバＰＣ１０５にサーバ識別子５０４の取得要求情報を送信する。また、サーバ識別子取得部４０２は、プロセス間通信制御部４０１の制御の下に、サーバＰＣ１０５からのサーバ識別子５０４を取得する。

次に、セッション管理部４０３は、プロセス間通信制御部４０１の制御の下に、ステップＳ７０２で取得したサーバ識別子５０４と同一のサーバ識別子５０４に係る既存のセッションが存在するか否かを判別する（ステップＳ７０３）。

この場合、セッション管理部４０３は、ＤＢ管理部４０５により、セッション管理情報ＤＢ４０６からセッション管理情報を取得する。そして、セッション管理部４０３は、取得したセッション管理情報について、別のアドレスで通信中の既存セッションの中に、今回の接続要求時に取得したサーバ識別子５０４と同一のサーバ識別子５０４に係る既存セッションが存在するか否かを判定する。この判定処理は、実際には、セッション判定部４０４が行う。

図５のセッション管理情報の例では、管理番号「１」と管理番号「２」の通信は、クライアントアプリケーション１０１，１０１ａからの異なるアドレスに対する接続要求である。しかしながら、これらの通信のそれぞれは同一のサーバＰＣ１０５との間で実行される。従って、同一のサーバＰＣ１０５と通信を行うにも拘わらず、複数のセッションを作成することは効率的ではないため、ここでは１つのセッションを用いて管理番号「１」と管理番号「２」のそれぞれの通信を実行するようにする。

つまり、例えば先に管理番号「１」の通信が開始された状態で管理番号「２」の通信を開始しようとする場合は、プロセス間通信制御部４０１は、新規のセッションを作成しない。その代わり、プロセス間通信制御部４０１は、管理番号「１」の既存セッションを管理番号「２」の通信のデータ転送用のセッションとして選択する（ステップＳ７０７）。そして、プロセス間通信制御部４０１は、後述するステップＳ７０８に進む。

なお、既存セッションを選択した場合は、ＵＤＰプロトコル（非コネクション型プロトコル）通信においては当該セッションを切断する必要はないが、ＴＣＰ（コネクション型プロトコル）通信においては当該セッションを切断する必要がある。これは、図１０、図１２のステップＳ７０７においても同様である。

今回取得したサーバ識別子５０４と同一のサーバ識別子５０４に係る既存セッションが存在しない場合は、セッション管理部４０３は、新規セッションを確立するために新規ソケットを作成する（ステップＳ７０４）。この場合、セッション管理部４０３は、通信ライブラリ１０４ａを利用して、クライアントアプリケーション１０１，１０１ａからの宛先アドレスで新規ソケットを作成する。

次に、セッション管理部４０３は、新規ソケットを含む新規セッションの情報を、ＤＢ管理部４０５により、セッション管理情報ＤＢ４０６に登録させる（ステップＳ７０５）。そして、プロセス間通信制御部４０１は、クライアントアプリケーション１０１，１０１ａからの宛先アドレスに基づく新規セッションを、今回のデータ転送用のセッションとして選択する（ステップＳ７０６）。

次に、プロセス間通信制御部４０１は、ステップＳ７０６、又はステップＳ７０７で選択されたセッションにより、クライアントアプリケーション１０１，１０１ａからのデータをサーバアプリケーション１０８に転送する（ステップ７０８）。

なお、データ転送用のセッションとして新規セッションが選択された場合は、ステップＳ７０４〜Ｓ７０８では、クライアントアプリケーション１０１，１０１ａからの宛先アドレスと、実際に通信を行う通信アドレスが同一になる。このように新規セッションで通信を行う処理は、従来からのプロセス間通信技術であるＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）などの通信処理と同じである。

一方、既存セッションが選択された場合は、クライアントアプリケーション１０１，１０１ａからの宛先アドレスと、実際に通信を行う通信アドレスが異なる。しかし、今回の接続要求時にステップＳ７０２で取得したサーバ識別子５０４と、既存セッションのサーバ識別子５０４とは一致している。従って、当該クライアントＰＣ１００のクライアントプロセス間通信部１０３は、同一のサーバＰＣ１０５のサーバプロセス間通信部１０７と通信を行うことが可能である。

そこで、本実施の形態では、ステップＳ７０７の処理では、今回の接続要求時に取得したサーバ識別子５０４と同一のサーバ識別子５０４に係る既存セッションを今回のデータ通信用のセッションとして選択している。この場合、クライアントアプリケーション１０１，１０１ａからの宛先アドレスに基づいてデータ通信用に新規にソケット（セッション）が作成されることはない。

このように、新規にソケットを作成することなく、既存セッションで通信を行うことにより、クライアントＰＣ１００、サーバＰＣ１０５は、通信ソケット数を低減できるなど、ネットワークリソースを節約することが可能となる。

次に、プロセス間通信制御部４０１は、クライアントアプリケーション１０１，１０１ａからのクローズ要求、通信ライブラリ１０４ａからの接続切断要求などの有無を判断する（ステップＳ７０９）。その結果、上記のクローズ要求、又は切断要求が無い場合は、プロセス間通信制御部４０１は、ステップＳ７０１に戻ることにより、ステップＳ７０１〜Ｓ７０９の処理を続行する。

一方、クローズ要求、切断要求の何れかが有る場合は、セッション管理部４０３は、通信ライブラリ１０４ａにより、クローズ（切断）要求に係るアドレスのセッション、ソケットのクローズ処理などを行う（ステップＳ７１０）。そして、セッション管理部４０３は、ステップＳ７１０での処理結果に基づいて、ＤＢ管理部４０５により、セッション管理情報ＤＢ４０６上のセッション管理情報を更新する（ステップＳ７１１）。

次に、図６、図７の処理の具体例を、図８、図９のシーケンス図に基づいて説明する。図８は、上記の既存セッションが存在しない場合の処理シーケンスを示している。

図８のプロセスＰ８０１では、サーバプロセス間通信部１０７は、サーバアプリケーション１０８がサービスを開始すると、クライアントＰＣ１００からのパケット受信を行うＬｉｓｔｅｎ処理を行う。また、サーバプロセス間通信部１０７は、ステップＳ６０１において、サーバ識別子５０４として用いるＵＵＩＤの生成処理を行う。

また、サーバプロセス間通信部１０７は、プロセスＰ８０１において、Ｌｉｓｔｅｎ処理でＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］での受信処理を行うべく受信ソケットを作成する。サーバプロセス間通信部１０７は、同様に、ＩＰｖ６アドレス［２００１：：１０］、ポート番号［１０２５］に係る受信ソケットも作成する。

プロセスＰ８０２では、クライアントアプリケーション１０１，１０１ａは、クライアントプロセス間通信部１０３に対して、ＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］への接続を要求する。プロセスＰ８０３では、この接続要求を受けて、クライアントプロセス間通信部１０３は、ステップＳ７０２のサーバ識別子５０４の取得処理を行う。プロセスＰ８０４では、サーバプロセス間通信部１０７は、ステップＳ６０４のサーバ識別子５０４の返信処理を行う。

なお、プロセスＰ８０３，Ｐ８０４のネゴシエーションにおいては、ＴＣＰ通信に比べて信頼性は多少劣るが、高速通信が行えるＵＤＰ通信により行うのが望ましい。ただし、ＴＣＰ通信でネゴシエーションを行っても良い。これは、後述する図９、図１１、図１３におけるネゴシエーションの場合も同趣旨である。

プロセスＰ８０５では、クライアントプロセス間通信部１０３は、ステップＳ７０３の処理、即ち、セッション管理情報に基づいて同一のサーバ識別子５０４に係る既存セッションの有無を判定する処理を行う。図８のシーケンス例では、この判定処理において既存セッションが無いと判定される。このため、プロセスＰ８０６では、ステップＳ７０４からステップＳ７０６の新規セッションの作成処理が行われる。

プロセスＰ８０７では、サーバプロセス間通信部１０７は、ＴＣＰのａｃｃｅｐｔ処理により新規セッション用のソケットを作成する。プロセスＰ８０８では、クライアントプロセス間通信部１０３は、クライアントアプリケーション１０１，１０１ａに対して、プロセスＰ８０２での接続要求に係る接続処理の結果を返信する。

プロセスＰ８０９では、ステップＳ７０８の処理が行われる。すなわち、クライアントプロセス間通信部１０３は、クライアントアプリケーション１０１，１０１ａが指定したＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］に向けてデータ送信処理を行う。

この送信処理を受けて、クライアントプロセス間通信部１０３は、クライアントアプリケーション１０１，１０１ａからのデータ量に応じて、プロセスＰ８１０−１〜プロセスＰ８１０−ｎで、サーバＰＣ１０５に向けてデータを転送する。

プロセスＰ８１１では、サーバプロセス間通信部１０７は、クライアントアプリケーション１０１，１０１ａからデータを受信すると、サーバアプリケーション１０８に対してデータを転送する。プロセスＰ８１２では、クライアントプロセス間通信部１０３は、データ転送が完了した時点でクライアントアプリケーション１０１，１０１ａに対してデータ転送の結果を通知する。

なお、プロセスＰ８０９〜Ｐ８１０−ｎにおける実際のデータ通信は、ＵＤＰ通信に比べて低速ではあるが信頼性の高いＴＣＰ通信により行うのが望ましい。ただし、実際のデータ通信をＵＤＰ通信で行っても良い。これは、後述する図９、図１１、図１３におけるネゴシエーションの場合も同趣旨である。

プロセスＰ８１３では、クライアントアプリケーション１０１，１０１ａからクライアントプロセス間通信部１０３に対して、ＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］の切断（クローズ）を要求する。この切断要求を受けて、クライアントプロセス間通信部１０３は、ステップＳ７１０の切断処理を行う。

プロセスＰ８１４では、サーバプロセス間通信部１０７は、クライアントプロセス間通信部１０３からＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］の切断指示を受けて、セッションの切断処理を行う。プロセスＰ８１５では、クライアントプロセス間通信部１０３は、ステップＳ７１１の処理を行い、クライアントアプリケーション１０１，１０１ａに対して当該セッションを切断した旨を通知する。

図９は、第１の実施の形態に係る既存セッションが存在する場合の処理シーケンスである。図９のプロセスＰ９０１では、サーバプロセス間通信部１０７は、サーバアプリケーション１０８がサービスを開始すると、クライアントからのパケットを受信すべく、Ｌｉｓｔｅｎ処理、及びステップＳ６０１のサーバ識別子（ＵＵＩＤ）５０４の生成処理を行う。

また、サーバプロセス間通信部１０７は、プロセスＰ９０１では、Ｌｉｓｔｅｎ処理により、ＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］での受信処理を行うべく受信ソケットを作成する。サーバプロセス間通信部１０７は、同様に、ＩＰｖ６アドレス［２００１：：１０］、ポート番号［１０２５］に係る受信ソケットも作成する。

プロセスＰ９０２では、クライアントアプリケーション１０１，１０１ａは、クライアントプロセス間通信部１０３に対して、ＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］への接続を要求する。プロセスＰ９０３では、この接続要求を受けて、クライアントプロセス間通信部１０３は、ステップＳ７０２のサーバ識別子５０４の取得処理を行う。プロセスＰ９０４では、サーバプロセス間通信部１０７は、ステップＳ６０４のサーバ識別子５０４の返信処理を行う。

プロセスＰ９０５では、クライアントプロセス間通信部１０３は、ステップＳ７０３の処理、即ち、セッション管理情報に基づいて、接続要求時のものと同一のサーバ識別子５０４に係る既存セッションの有無を判定する処理を行う。図９のシーケンス例では、プロセスＰ９０５の判定処理において既存セッションが無いと判定される。このため、プロセスＰ９０６では、ステップＳ７０４からステップＳ７０６の新規セッションの作成処理が行われる。

プロセスＰ９０７では、サーバプロセス間通信部１０７は、ＴＣＰのａｃｃｅｐｔ処理により新規セッション用のソケットを作成する。プロセスＰ９０８では、クライアントプロセス間通信部１０３は、プロセスＰ８０２での接続要求に係る接続処理の結果を、クライアントアプリケーション１０１，１０１ａに返信する。

プロセスＰ９０９では、ステップＳ７０８の処理が行われる。即ち、クライアントプロセス間通信部１０３は、クライアントアプリケーション１０１，１０１ａが指定したＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］に向けてデータ送信処理を行う。この送信処理を受けて、クライアントプロセス間通信部１０３は、クライアントアプリケーション１０１，１０１ａからのデータ量に応じて、プロセスＰ９１０−１〜プロセスＰ９１０−ｎで、サーバＰＣ１０５に向けてデータを転送する。

プロセスＰ９１１では、サーバプロセス間通信部１０７は、クライアントアプリケーション１０１，１０１ａから受信したデータを、サーバアプリケーション１０８に転送する。プロセスＰ９１２では、クライアントプロセス間通信部１０３は、データ転送が完了すると、その旨をクライアントアプリケーション１０１，１０１ａに通知する。

プロセスＰ９１３では、クライアントアプリケーション１０１，１０１ａは、クライアントプロセス間通信部１０３に対して、ＩＰｖ６アドレス［２００１：：１０］、ポート番号［１０２５］に対する接続を要求する。プロセスＰ９１４では、サーバプロセス間通信部１０７は、この接続要求をクライアントプロセス間通信部１０３から受けて、ステップＳ６０４のサーバ識別子５０４の返信処理を行う。この場合、クライアントアプリケーション１０１，１０１ａは、ＩＰｖ６アドレス［２００１：：１０］、ポート番号［１０２５］に係るサーバ識別子５０４を取得することとなる。

プロセスＰ９１５では、クライアントプロセス間通信部１０３は、ステップＳ７０３の処理、即ち、セッション管理情報に基づいて、接続要求時のものと同一のサーバ識別子５０４に係る既存セッションの有無を判定する処理を行う。

図９のシーケンス例では、ＩＰｖ６アドレス［２００１：：１０］、ポート番号［１０２５］で取得したサーバ識別子「１０」と同一の識別子が、既にセッションを確立しているＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］から返信される。従って、クライアントプロセス間通信部１０３は、同一の識別子に係る既存セッション［１０．０．０．１０］、ポート番号［１０２５］が有ると判定し、ＩＰｖ６アドレス［２００１：：１０］、ポート番号［１０２５］に対してセッションを確立しない。

以後、クライアントプロセス間通信部１０３は、ＩＰｖ６アドレス［２００１：：１０］、ポート番号［１０２５］に係るデータ転送処理は、ＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］に対して行う。

即ち、プロセスＰ９１６では、クライアントアプリケーション１０１，１０１ａは、クライアントプロセス間通信部１０３に対して、ＩＰｖ６アドレス［２００１：：１０］、ポート番号［１０２５］に対してデータ転送を要求する。

このデータ転送要求を受けて、クライアントプロセス間通信部１０３は、プロセスＰ９１７において、データ伝送要求時に指定されたＩＰｖ６アドレス［２００１：：１０］、ポート番号［１０２５］と異なるアドレスである、既存セッションに係るＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］に対して要求に係るデータを転送する。

プロセスＰ９１８では、クライアントプロセス間通信部１０３は、クライアントアプリケーション１０１，１０１ａからのデータ量に応じて、データ転送が完了するまで必要な転送処理を既存のセッションで繰り返す。

プロセスＰ９１９では、サーバプロセス間通信部１０７は、クライアントアプリケーション１０１，１０１ａから発送された受信データを、サーバアプリケーション１０８に転送する。プロセスＰ９２０では、クライアントアプリケーション１０１，１０１ａは、クライアントプロセス間通信部１０３に対して、ＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］の切断（クローズ）を指示する。この切断指示を受けて、クライアントプロセス間通信部１０３は、ステップＳ７１０の切断処理を行う。

プロセスＰ９２１では、サーバプロセス間通信部１０７は、クライアントプロセス間通信部１０３からの切断指示を受けて、ＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］に係るセッションの切断処理を行う。

このように、第１の実施の形態では、クライアントアプリケーション１０１，１０１ａから指示された宛先アドレスと異なるアドレスでサーバ識別子５０４が一致する既存セッションを、データ通信用のセッションとして用いる。

従って、ソケット等のネットワークリソースを効率的に使用したり、低減したりすることが可能となる。なお、この効果は、第２，第３の実施の形態においても同様に奏することができる。

［第２の実施の形態］
第１の実施の形態では、例えばクライアントアプリケーション１０１が、第１のセッションを切断した場合、第１のセッションを既存セッションとしてデータ通信に使用しているクライアントアプリケーション１０１ａは、データ通信を行うことができなくなる。

しかし、例えば、クライアントプロセス間通信部１０３は、クライアントアプリケーション１０１，１０１ａからの接続要求、クローズ要求に対して、セッションの参照カウンタのみを増減するようにする。そして、クライアントプロセス間通信部１０３は、参照カウンタが「０」になったときに実際にセッションを切断するようにすれば、セッションを共有したとしても、セッションの切断時に問題が発生じることはない。

そこで、第２の実施の形態では、宛先アドレスとは異なるアドレスで確立された既存セッションでデータ送信を行う場合にも、既存セッションによる通信が他のアプリケーション１０１，１０１ａからの切断指示で意に反して切断されないようにしている。

図１０は、本発明の第２の実施の形態においてクライアントプロセス間通信１０３が行うセッション管理処理を示すフローチャートである。なお、第２の実施の形態に係るセッション管理システムの構成等は第１の実施の形態の場合と同様であるため、その説明は省略する（第３の実施の形態も同様）。また、図１０において、ステップＳ７０１〜Ｓ７１１の処理は、図７のフローチャートにおけるステップＳ７０１〜Ｓ７１１の処理と同じであるため、その説明は必要に応じて行うに留める。

図１０において、プロセス間通信制御部４０１は、ステップＳ１００１では、ステップＳ７０６、又はステップＳ７０７で選択されたセッションのクローズ・リファレンス・カウンタの値を「＋１」する。なお、このクローズ・リファレンス・カウンタは、上記の参照カウンタ、及び図４の接続リファレンスカウンタに相当するカウンタであり、切断要求数をカウントするものである。また、クライアントＰＣ１００のセッション切断管理部４０７は、各セッションのクローズ・リファレンス・カウンタの値を接続リファレンスカウント記憶部４０８に保存し、このクローズ・リファレンス・カウンタの値に基づいて各セッションの切断を判断する。

次に、プロセス間通信制御部４０１は、ステップＳ７０６、又はステップＳ７０７で選択されたセッションにより、クライアントアプリケーション１０１，１０１ａからのデータをサーバアプリケーション１０８に転送する（ステップ７０８）。なお、ステップＳ７０７にて、宛先アドレスと異なるアドレスで確立された既存セッションが選択された場合は、データ転送を行う既存セッションのクローズ・リファレンス・カウンタの値を「＋１」するだけで、新規セッションの作成は行われない。

次に、プロセス間通信制御部４０１は、クライアントアプリケーション１０１，１０１ａからのクローズ要求、通信ライブラリ１０４ａからの接続切断要求などの有無を判断する（ステップＳ７０９）。その結果、上記のクローズ要求、又は切断要求が無い場合は、プロセス間通信制御部４０１は、ステップＳ７０１に戻ることにより、ステップＳ７０１〜Ｓ７０９の処理を続行する。

一方、クローズ要求、切断要求の何れかが有る場合は、プロセス間通信制御部４０１は、セッション管理部４０３により、セッション切断管理部４０７に対してクローズ要求、切断要求に係るアドレスの当該セッションのクローズを要求させる（ステップＳ１００２）。この場合、セッション切断管理部４０７は、接続リファレンスカウント記憶部４０８内の当該セッションのクローズ・リファレンス・カウンタの値を「−１」する（ステップＳ１００２）。

次に、プロセス間通信制御部４０１は、クローズ・リファレンス・カウンタの値が「−１」されることにより、「０」になったか否かを判断する（ステップＳ１００３）。その結果、「０」になっていなければ、プロセス間通信制御部４０１は、ステップＳ７０１に戻る。

一方、クローズ・リファレンス・カウンタの値が「０」になった場合は、プロセス間通信制御部４０１は、次のような処理を行う。すなわち、プロセス間通信制御部４０１は、セッション管理部４０３、及び通信ライブラリ１０４ａにより、クローズ（切断）要求に係るアドレスのセッション、ソケットのクローズ処理などを行う（ステップＳ７１０）。そして、セッション管理部４０３は、ステップＳ７１０での処理結果に基づいて、ＤＢ管理部４０５により、セッション管理情報ＤＢ４０６上のセッション管理情報を更新する（ステップＳ７１１）。

次に、図１０の処理の具体例を、図１１のシーケンス図に基づいて説明する。なお、図１１のシーケンスは、宛先アドレスと異なるアドレスで確立された既存のセッションでデータ送信を行う場合を示している。この場合、下記のようなシーケンスで、既存セッションによる通信が意に反して不能にならないように、既存セッションの切断を適切に行う場合を示している。

すなわち、プロセスＰ１１０１において、クライアントプロセス間通信部１０３は、ステップＳ７０６にて新規のセッションを確立したことにより、ステップＳ１００１のクローズ・リファレンス・カウンタの値を「＋１」する。このクローズ・リファレンス・カウンタは、接続要求に係る宛先アドレス毎に、その接続要求数及び切断要求数を係数するカウンタとして機能する。

プロセスＰ１１０２では、クライアントプロセス間通信部１０３は、ステップＳ７０７にて宛先アドレスと異なるアドレスで確立された既存のセッションを利用するために、新規セッションの作成は行わない。ただし、クライアントプロセス間通信部１０３は、ステップＳ１００１のクローズ・リファレンス・カウンタの値を「＋１」する処理を行う。

この時点で、接続リファレンスカウント記憶部４０８に記憶されているクローズ・リファレンス・カウンタの値は、サーバ識別子５０４が「１０」のサーバＰＣ１０５に対して「２」となる。実際の通信アドレスは、ＩＰｖ４アドレスの［１０．０．０．１０］、ポート番号［１０２５］である。

また、宛先アドレスとしては、ＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］の他に、ＩＰｖ６アドレス［２００１：：１０］、ポート番号［１０２５］があり、これらアドレスは、それぞれ接続状態で存在している。

プロセスＰ１１０３では、クライアントプロセス間通信部１０３は、ＩＰｖ４アドレスの［１０．０．０．１０］、ポート番号［１０２５］に対するクローズ処理を行う。この際、ステップＳ１００２の処理により、接続リファレンスカウント記憶部４０８内の該当セッションのクローズ・リファレンス・カウンタの値が「−１」される。

このクローズ処理により、接続リファレンスカウント記憶部４０８内のクローズ・リファレンス・カウンタの値は、サーバ接続子が「１０」のサーバＰＣ１０５に対して「１」個となる。実際の通信アドレスは、ＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］の１つである。また、宛先アドレスとしては、ＩＰｖ６アドレス［２００１：：１０］、ポート番号［１０２５］があり、このアドレスは接続状態で存在する。

プロセスＰ１１０４では、クライアントプロセス間通信部１０３は、ＩＰｖ６アドレス［２００１：：１０］、ポート番号［１０２５］に対するクローズ処理を行う。この際、ステップＳ１００２の処理により、接続リファレンスカウント記憶部４０８内の該当セッションのクローズ・リファレンス・カウンタの値が「−１」される。

このクローズ処理により、接続リファレンスカウント記憶部４０８内のクローズ・リファレンス・カウンタ（その値）は、サーバ接続子が「１０」のサーバＰＣ１０５に対して「０」個となる。クライアントプロセス間通信部１０３は、クローズ・リファレンス・カウンタの値が「０」個となったので、プロセスＰ１１０５において、ステップＳ７１０のセッションクローズ処理を行う。本処理例では、クライアントアプリケーション１０１，１０１ａは、クライアントプロセス間通信部１０３に対して、ＩＰｖ６アドレスの［２００１：：１０］、ポート番号［１０２５］に対する切断指示を行う。

しかし、クライアントプロセス間通信部１０３は、クライアントアプリケーション１０１，１０１ａからのセッション切断指示を受けて、実際の通信アドレスであるＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］に対して切断処理を行う。この切断処理は、ステップＳ７１０、及びステップＳ７１１の処理で行われる。

次に、プロセスＰ１１０６において、サーバプロセス間通信部１０７は、次のような処理を行う。即ち、サーバプロセス間通信部１０７は、クライアントプロセス間通信部１０３からのＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］に対する切断指示に応答して、通信ライブラリ１０４ｂにより、当該セッションの切断処理を行う。

これは、次のことを意味する。即ち、宛先アドレスと異なるアドレスで確立された既存セッションで通信を行っている際に、当該既存セッションに対する切断指示が他のアプリケーションからなされたとする。この場合は、その切断指示とは異なるアドレスの同一のサーバ識別子５０４に係るセッションが切断され、当該既存セッションが切断されることはない。

換言すれば、第２の実施の形態では、宛先アドレスとは異なるアドレスで確立された既存セッションでデータ送信を行う場合にも、既存セッションによる通信が他のアプリケーションからの切断指示で意に反して切断されることはない。

例えばクライアントアプリケーション１０１が、第１のセッションを切断した場合、第１のセッションを既存セッションとしてデータ通信に使用しているクライアントアプリケーション１０１ａは、データ通信を行うことができなくなる。

しかし、例えば、クライアントプロセス間通信部１０３は、クライアントアプリケーション１０１，１０１ａからのコネクト（接続）要求、クローズ（切断）要求に対して、セッションの参照カウンタのみを増減するようにする。そして、クライアントプロセス間通信部１０３は、参照カウンタが「０」になったときに実際にセッションを切断するようにすれば、セッションを共有したとしても、セッションの切断時に問題が発生じることはない。

［第３の実施の形態］
第１の実施の形態では、クライアントアプリケーション１０１とクライアントアプリケーション１０１ａが異なる宛先アドレスを指定した場合でも、同一のセッションを利用する場合がある。この際、実際に通信に利用する通信アドレスは、最初にセッションを作成した際の宛先アドレスとなる。

しかし、最初にセッションを作成した際の宛先アドレスでの通信で通信障害が発生した場合は、他の宛先アドレスでの通信が可能なときでも、同一セッションで通信を行っている他のクライアントアプリケーションも通信ができなくなる。

そこで、第３の実施の形態では、そのような通信障害が発生した場合でも、通信可能な宛先アドレスが存在するときは、該当セッションでの通信を可能とするようにしている。

図１２は、本発明の第３の実施の形態においてサーバＰＣ１０５とクライアントＰＣの間で行われるセッション管理処理を示すシーケンス図である。なお、図１２において、ステップＳ７０１〜Ｓ７１１は、図７のフローチャートにおけるステップＳ７０１〜Ｓ７１１と同じであるため、その全てを説明することなく、第３の実施の形態に特有なステップの説明に必要なステップだけを説明する。

図１２において、プロセス間通信制御部４０１は、ステップＳ７０６、又はステップＳ７０７で選択されたセッションにより、クライアントアプリケーション１０１，１０１ａからのデータをサーバアプリケーション１０８に転送する（ステップＳ７０８）。

次に、プロセス間通信制御部４０１は、データ転送に成功したか否かを判断する（ステップＳ１２０１）。その結果、データ転送に成功している合は、プロセス間通信制御部４０１は、クライアントアプリケーション１０１，１０１ａからのクローズ要求や、通信ライブラリ１０４ａからの接続切断要求などの有無を判断する（ステップＳ７０９）。

一方、データ転送に失敗した場合は、プロセス間通信制御部４０１は、セッション管理部４０３により、サーバ識別子５０４が同一の他の宛先アドレスの存在、又は通信可能な他の宛先アドレスの存在の有無を判断する（ステップＳ１２０２）。

その結果、サーバ識別子５０４が同一の他の宛先アドレスが存在しない場合、プロセス間通信制御部４０１は、データ転送のエラー処理を行って（ステップＳ１２０６）、上記のステップＳ７０９に進む。このエラー処理は、通信可能な他の宛先アドレスが存在する或いは場合にも同様に行われる。

一方、サーバ識別子５０４が同一の他の宛先アドレスが存在する場合は、プロセス間通信制御部４０１は、セッション再接続管理部４０９により、サーバ識別子５０４が同一の他の宛先アドレスに再接続セッションを確立する。この場合、通信に失敗した通信アドレスとは別の宛先アドレスで新規ソケットが作成される。

次に、プロセス間通信制御部４０１は、ＤＢ管理部４０５により、再接続セッションをセッション管理情報ＤＢ４０６に登録する（ステップＳ１２０４）。そして、プロセス間通信制御部４０１は、再接続セッションをデータ転送セッションに選択し（ステップＳ１２０５）、ステップＳ７０８に戻り、再接続セッションでデータ転送を行う。

図１３は、本発明の第３の実施の形態においてサーバＰＣ１０５とクライアントＰＣの間で行われるセッション管理処理を示すシーケンス図である。このシーケンスでは、宛先アドレスと異なるアドレスで確立された既存のセッションでデータ送信を行う場合に、セッション再接続処理を可能にしている。なお、図１３において図９の処理シーケンスと同様である処理については、その説明を省略する。

プロセスＰ１３０１では、プロセス間通信制御部４０１は、ステップＳ１２０１のデータ転送成功の確認処理を行う。この時点で、接続リファレンスカウント記憶部４０８が記憶しているクローズ・リファレンス・カウンタは、サーバ識別子５０４が「１０」のサーバＰＣ１０５に対して２個となる。この２個のサーバ識別子５０４の実際の通信アドレスは、ＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］である。

また、この時点での宛先アドレスは、ＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］、及びＩＰｖ６アドレスの［２００１：：１０］、ポート番号［１０２５］の２つが接続状態で存在する。

本シーケンス例では、プロセスＰ１３０１において、プロセス間通信制御部４０１は、実際の通信アドレスであるＩＰｖ４アドレス［１０．０．０．１０］、ポート番号［１０２５］でのデータ転送がエラーであると判断する。

プロセスＰ１３０２では、プロセス間通信制御部４０１は、セッション再接続管理部４０９により、ステップＳ１２０２でのサーバ識別子５０４が同一の他の宛先アドレスが存在するか否か判定処理を行う。

本シーケンス例では、セッション再接続管理部４０９は、サーバ識別子５０４が同一である他の宛先アドレスがあると判定し、再接続セッションの確立を行う。（プロセスＰ１３０３）。セッション再接続管理部４０９は、ＤＢ管理部４０５により、再接続セッションをセッション管理情報ＤＢ４０６に登録する。

この時点では、接続リファレンスカウント記憶部４０８が記憶しているクローズ・リファレンス・カウンタは、サーバ接続子が「１０」のサーバＰＣ１０５に対して２個である。

実際の通信アドレスは、ＩＰｖ６アドレス［２００１：：１０］、ポート番号［１０２５］である。また、宛先アドレスは、ＩＰｖ４アドレスの［１０．０．０．１０］、ポート番号［１０２５］およびＩＰｖ６アドレスの［２００１：：１０］、ポート番号［１０２５］が接続状態で存在する。

プロセスＰ１３０４では、プロセス間通信制御部４０１は、クライアントアプリケーション１０１，１０１ａから指定されたデータを、ＩＰｖ６アドレス［２００１：：１０］、ポート番号［１０２５］でデータ送信を行う。

このため、サーバ識別子が同一のセッションの中に接続可能な宛先アドレスが１つ以上ある場合は、接続要求を行ったクライアントアプリケーション１０１，１０１ａは、通信障害を意識することなく通信を継続することが可能となる。

［第４の実施の形態］
第１〜３の実施の形態では、クライアントＰＣ１００は、サーバＰＣ１０５から取得したサーバ識別子、すなわち、サーバ識別情報に基づいて既存セッションの有無を判定していた。

しかし、このためには、サーバＰＣ１０５側にサーバ識別子（サーバ識別情報）を返信する構成、すなわち、サーバプロセス間通信制御部３０１の制御の下にサーバ識別子を返信するサーバ識別子返信部３０２を備える必要がある。このため、多数のクライアントＰＣと通信するサーバＰＣ１０５の処理負担が増えると共に、ネットワークリソースの有効利用を阻害する要因ともなる。

そこで、第４の実施の形態では、クライアントＰＣ１００は、サーバＰＣ１０５から取得したサーバ識別子に基づいて既存セッションの有無を判定するのではなく、サーバＰＣ１０５と協働することなく既存セッションの有無を判定することとしている。

図１４は、本発明の第４〜６の実施の形態に係るセッション管理システムを適用したクライアント／サーバシステムのソフトウェアの構成等を示す図である。

第１〜３の実施の形態に係る図１との相違点は、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバ１４０１がネットワーク１０６に接続されている点である。

第４の実施の形態では、ＤＮＳサーバ１４０１等を利用することにより、クライアントＰＣ１００は、サーバＰＣ１０５と協働することなく、既存セッションの有無を判定する。

なお、ＤＮＳサーバ１４０１で動作しているＤＮＳサービスの仕様は、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）に係る技術仕様となっている。具体的には、ＤＮＳサーバ１４０１は、ＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）１０３４やＲＦＣ１０３５等で規定されている仕様でアドレス問題解決サービスを行っている。

ＲＦＣ１０３４、ＲＦＣ１０３５等では、ＩＰｖ４アドレスに対応したＡレコードの仕様や応答の実装について記述されている。また、ＲＦＣ１８８６等では、ＩＰｖ６に対応したＡＡＡＡレコードの仕様や応答の実装について記述されている。ＲＦＣは、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ．ｈｔｍｌで参照することができる。

図１５は、第４の実施の形態に係るクライアントＰＣ１００のクライアントプロセス間通信部１０３の詳細なソフトウェア構成を示すブロック図である。

クライアントＰＣ１００は、クライアントアプリケーション１０１からのリクエストにより、スタブオブジェクト（図省略）を介して、クライアントプロセス間通信部１０３および、通信ライブラリ１０４ａを介してサーバＰＣ１０５と通信を行う。

クライアントプロセス間通信部１０３は、第１〜３の実施の形態と同様に、プロセス間通信制御部４０１、セッション管理部４０３、セッション管理情報ＤＢ４０６、セッション判定部４０４を有している。

また、クライアントプロセス間通信部１０３は、第１〜３の実施の形態と同様に、セッション切断管理部４０７、セッション再接続管理部４０９を有している。さらに、クライアントプロセス間通信部１０３は、第４の実施の形態に特有なソフトウェアとして、アドレスリスト取得部１５０１、及びアドレスリスト記憶部１５０２を有している。

プロセス間通信制御部４０１は、セッションの管理を行いながら、クライアントアプリケーション１０１，１０１ａとサーバアプリケーション１０８の間で行う通信を統括的に制御する。アドレスリスト取得部３０２は、クライアントアプリケーション１０１，１０１ａから指定された宛先アドレスに係る１つまたは複数のアドレスをＤＮＳサーバ１４０１から取得し、アドレスリスト記憶部１５０２に順次記憶する。このアドレスリスト記憶部１５０２の記憶情報であるアドレスリスト情報については、後で図１６、図２３に基づいて詳細に説明する。

セッション管理部４０３は、セッション管理情報ＤＢ４０６に登録するセッション管理情報を管理する。この第４の実施の形態におけるセッション管理情報については、後で図１７に基づいて詳細に説明する。セッション判定部４０４は、アドレスリスト、及びセッション管理情報に基づいて、新規セッションの作成処理や既存セッションの利用可能性を判断する。

セッション切断管理部４０７、接続リファレンスカウント記憶部４０８、及びセッション再接続管理部４０９の処理内容等は、第１〜３の実施の形態と同様である。

次に、アドレスリスト記憶部１５０２に記憶されているアドレスリスト情報を図１６に基づいて詳細に説明する。アドレスリスト記憶部１５０２には、ＤＮＳサーバ１４０１から取得した宛先（サーバ）のアドレスリスト情報が順次格納されて、データベース化されていく。

サーバ識別子１６０１は、接続要求元のクライアントアプリケーション１０１，１０１ａが要求する宛先（接続先）に係るサーバ（サーバＰＣ１０５）のサーバ識別子（サーバ識別情報）である。このサーバ識別子１６０１としては、例えば、ホスト名やＮｅｔＢＩＯＳ名、コンピュータ名、完全修飾ドメイン名（ＦＱＤＮ：Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）等がある。

ただし、後述するように、第４の実施の形態では、アドレスリスト取得部１５０１は、クライアントアプリケーション１０１，１０１ａが異なる形式のサーバ識別情報で接続要求を行った場合に、異なる形式のサーバ識別情報をホスト名に統一している。そして、アドレスリスト取得部１５０１は、このホスト名に係るアドレスリストをＤＮＳサーバ１４０１から取得している。

従って、図１６のアドレスリスト情報にけるサーバ識別子１６０１は、実際には「ホスト名」となっている。同様に理由で、図１７のセッション管理情報におけるサーバ識別子５０４も、実際には「ホスト名」となっている。ただし、図２３のアドレスリスト情報にけるサーバ識別子１６０１は、実際には「ホスト名」であるところを、説明の便宜上、クライアントアプリケーション１０１，１０１ａが実際に指定したサーバ識別子（サーバ識別情報）を示している。

アドレス取得方法１６０２は、宛先（サーバ）のアドレスリストをＤＮＳサーバ１４０１から取得する際に用いたプロトコルやその取得方法を示す情報である。アドレス種別１６０３は、ＤＮＳサーバ１４０１から実際に取得したアドレスの種別を示す情報である。ＩＰアドレス１６０４は、ＤＮＳサーバ１４０１から実際に取得したアドレス（ＩＰアドレス）それ自体を示す情報である。

図１６の例では、サーバ識別子１６０１が「ＡｐｐＳｅｒｖｅｒ：ホスト名」のサーバについては、リスト番号「１」と「４」に係る通信時にはＩＰｖ４アドレス［１０．０．０．１０］を取得している。また、サーバ識別子１６０１が「ＡｐｐＳｅｒｖｅｒ」のサーバについては、リスト番号「２」に係る通信時にはＩＰｖ６アドレス［２００１：：１０］を取得し、リスト番号「３」に係る通信時にはＩＰｖ６アドレス［ｆｅ８０：：１０］を取得している。

また、サーバ識別子１６０１が「ＡｐｐＳｅｒｖｅｒ２：ホスト名」のサーバについては、リスト番号「５」に係る通信時にはＩＰｖ４アドレス［１０．０．０．２０］を取得し、リスト番号「６」に係る通信時にはＩＰｖ６アドレス［２００１：：２０］を取得している。

図１７は、セッション管理情報を例示した図である。アプリケーション識別子５０１は、接続を要求したクライアントアプリケーション１０１，１０１ａを識別する識別子（インスタンスハンドル）である。要求アドレス情報５０２は、クライアントアプリケーション１０１，１０１ａが接続を要求する際に接続先（宛先）として指定した宛先アドレスである。この宛先アドレス５０２は、サーバ識別情報（ホスト名、ＦＱＤＮ等）、ＩＰｖ４アドレス、ＩＰｖ６アドレス等のＩＰアドレス５０２ａと、ポート番号５０２ｂを含んでいる。

通信アドレス情報５０３は、上記の宛先アドレスに基づいて既存セッションの利用可能性を判断した結果、実際に通信を行うものとして選択されたセッションに係る接続先のアドレスである。この通信アドレス情報５０３は、ＩＰアドレス５０３ａとポート番号５０３ｂを含んでいる。

サーバ識別子５０４は、接続要求元のクライアントアプリケーション１０１，１０１ａがＤＮＳサーバ１４０１に対して接続先のアドレスリストを要求した当該接続先のサーバのサーバ識別子（ここでは、ホスト名）である。セッション番号５０５は、通信を実際に行うセッションの管理番号（セッション識別インスタンスハンドル）である。

次に、クライアントプロセス間通信部１０３のプロセス間通信制御部４０１が行う第４の実施の形態に係るセッション管理処理を、図１８のフローチャートに基づいて説明する。なお、図１８では、図７と同一の処理については、同一のステップ番号を付している（図２０、図２１、図２２、図２６、図２７も同様）。

クライアントプロセス間通信部１０３のプロセス間通信制御部４０１は、サーバＰＣ１０５のサーバアプリケーション１０８に対する接続要求を受け付ける（ステップＳ７０１）。この接続要求は、クライアントアプリケーション１０１，１０１ａから行われるものである。

次に、プロセス間通信制御部４０１は、アドレスリスト取得部１５０１により、上記の宛先アドレスに係るアドレスリストを取得する（ステップＳ１８０１）。

この場合、アドレスリスト取得部１５０１は、通信ライブラリ１０４ａを利用して、ネットワーク１０６経由でＤＮＳサーバ１４０１に対して、上記のアドレスリストに係るＡレコードやＡＡＡＡレコード等の取得要求を行う。ＤＮＳサーバ１４０１は、アドレスリスト取得部１５０１からのアドレスリスト取得要求に応じて、該当するアドレスリストを返信する。

なお、アドレスリスト取得部１５０１は、ステップＳ１８０１では、ＤＮＳサーバ１４０１以外に、各種のアドレス問題解決サービスを利用してアドレスリスト取得処理を行う。ＤＮＳサーバ１４０１以外のアドレス問題解決サービスとしては、例えば、ＬＬＭＮＲ（Ｌｉｎｋ Ｌｏｃａｌ Ｍｕｌｔｉｃａｓｔ Ｎａｍｅ Ｒｅｓｏｌｕｔｉｏｎ）やＮｅｔＢＩＯＳのブロードキャスト探索等が挙げられる。

アドレスリスト取得部１５０１は、宛先アドレスの中でサーバ識別情報として「Ｎｕｍｅｒｉｃ ｈｏｓｔ ａｄｄｒｅｓｓ」が指定された場合は、その「Ｎｕｍｅｒｉｃ ｈｏｓｔ ａｄｄｒｅｓｓ」をホスト名に変換してアドレスリスト取得処理を行う。

このステップＳ１８０１におけるアドレスリスト取得処理の詳細を、図１９のフローチャートに基づいて説明する。

アドレスリスト取得部１５０１は、クライアントアプリケーション１０１，１０１ａから指定された宛先情報の中で、ホスト名、アドレスの何れの形式のサーバ識別情報でサーバが指定されているのかを判別する（ステップＳ１９０１）。ここで言う「アドレス」とは、「Ｎｕｍｅｒｉｃ ｈｏｓｔ ａｄｄｒｅｓｓ」を指す。

アドレス形式のサーバ識別情報でサーバが指定されている場合は、アドレスリスト取得部１５０１は、当該アドレスに係るホスト名をＤＮＳサーバ１４０１上で検索する（ステップＳ１９０２）。この場合、アドレスリスト取得部１５０１は、例えば、Ｃ／Ｃ＋＋のソケットプログラミングにおいては、ｇｅｔｎａｍｅｉｎｆｏ（）関数により、当該指定アドレスに対応付けられたホスト名を検索する。

次に、アドレスリスト取得部１５０１は、アドレス取得関数に基づいて検索したホスト名を指定することにより、当該ホスト名に係るサーバのアドレスリストをＤＮＳサーバ１４０１から取得する（ステップＳ１９０３）。この場合、例えば、Ｃ／Ｃ＋＋のソケットプログラミングにおいては、ｇｅｔａｄｄｒｉｎｆｏ（）関数のａｉ＿ｆａｍｉｌｙ に 値ＡＦ＿ＵＮＳＰＥＣ を設定して呼出しを行うことにより、ホスト名に対応するアドレスリストを取得する。

一方、最初からホスト名の形式のサーバ識別情報でサーバが指定されている場合は、アドレスリスト取得部１５０１は、ステップＳ１９０２をスキップしてステップＳ１９０３に進む。ステップＳ１９０３の処理が終了すると、アドレスリスト取得部１５０１は、上記のホスト名、及び当該ホスト名に対応するアドレスリストをアドレスリスト記憶部１５０２に登録し（ステップＳ１９０４）、図１８のフローにリターンする。

そして、セッション判定部４０４は、プロセス間通信制御部４０１の制御の下に、ステップＳ１８０１で取得されたアドレスリストとセッション管理情報ＤＢ４０６の情報に基づいて、既存セッションの利用可能性を判定する（ステップＳ１８０２）。

この場合、セッション判定部４０４は、取得したアドレスリストに係るアドレスの中で、同一ホスト名のホスト（サーバ）に係る既存セッションとしてセッション管理情報ＤＢ４０６に登録されている既存セッションについては、利用できると判定する。

即ち、セッション判定部４０４は、取得したアドレス（１つのアドレスの場合もある）に係るアドレスとは別のアドレスで通信を行っている既存セッションの中で、当該取得アドレスに係るサーバと同一のサーバに係る既存セッションが存在するか否かを判断する。その結果、上記の同一のサーバに係る既存セッションが存在する場合には、セッション判定部４０４は、当該既存セッションを利用可能であると判定する。

この場合、前述のように、アドレスリストは、サーバ識別情報をホスト名に統一した状態で取得されている。従って、セッション判定部４０４は、ホスト名に基づいてサーバの同一性を認定する。

このことは、実質的に、クライアントアプリケーション１０１，１０１ａが接続要求時に指定した宛先アドレスにおけるサーバ識別情報が異なっていても、同一のサーバに係るサーバ識別情報であれば、同一のサーバに係るサーバ識別情報として取り扱うことを意味する。

これにより、たとえ異なるサーバ識別情報でサーバが指定されたとしても、既存セッションの利用可能性を適切に判定することができ、より一層、ネットワークリソースを効率的に使用することが可能となる。この点については、後で、図２３に基づいて詳細に説明する。

そして、プロセス間通信制御部４０１は、既存セッションを利用可能である場合には、その既存セッションを今回のデータ転送用のセッションとして選択する（ステップＳ１８０３）。

例えば、図１７のセッション管理情報例では、管理番号「１」と「２」のセッションは、クライアントアプリケーション（１）からの異なる宛先アドレスに係るセッションである。しかし、既に確立された既存セッションとして、同一のサーバ識別子「ＡｐｐＳｅｒｖｅｒ」に係る既存セッションが存在する。このような場合、プロセス間通信制御部４０１は、新規のセッションを作成せずに、当該既存セッションをデータ転送用のセッションとして選択する。

なお、図１６のアドレスリストの例では、ＩＰアドレス［１０．０．０．１０］と［２００１：：１０］は、同一のサーバ識別子「ＡｐｐＳｅｒｖｅｒ」に対応付けられているため、上記のように、同一のサーバ識別子の既存セッションが存在すると判定できる。

図１６，１７の例では、リスト番号「２」のアドレス［２００１：：１０］への接続要求に係る通信は、サーバ識別子「ＡｐｐＳｅｒｖｅｒ」が同一である管理番号「１」に係るアドレス［１０．０．０．１０］の既存セッションを利用してデータ転送が行われる。

このように、既存セッションを利用することにより、クライアントＰＣ１００、サーバＰＣ１０５は、宛先アドレスに係る通信ソケットを新たに作成する必要はなくなり、当該通信ソケットなどのネットワークリソースを節約することが可能となる。

図１８におけるステップＳ７０４，Ｓ７０５，Ｓ７０８〜Ｓ７１１の処理は、図７の同一ステップ番号の処理と全く同様なので、ここでは、その説明を省略する。

次に、第１，第２のクライアントアプリケーションが別のサーバ識別情報（ホスト名、ＦＱＤＮ等）でサーバを指定した場合の取り扱いを説明する。

前述のように、第４の実施の形態では、宛先として指定されたサーバ識別情報は異なるが、同一サーバに係るサーバ識別情報については、同一のサーバ識別情報として取り扱うことにより、既存セッションの利用可能性を適切に判定できるようにしている。

図２３は、このような場合のアドレスリスト情報を例示したものである。図２３のアドレスリスト情報の情報項目それ自体は、図１６のアドレスリスト情報の情報項目と全く同一なので、同一の情報項目に同一の符号を付しただけで、その説明は省略する。ただし、図２３のアドレスリスト情報におけるサーバ識別子１６０１は、異なる形式で指定されたサーバ識別情報をホスト名に統一した結果としてのホスト名ではなく、説明の便宜上、その統一前の指定に係るサーバ識別情報それ自体を示している。

図２３の例では、サーバ識別子「ＡｐｐＳｅｒｖｅｒ．ｆｏｏ．ｔｅｓｔ」に係るサーバと、サーバ識別子「ＡｐｐＳｅｒｖｅｒ」に係るサーバが、同一のＩＰアドレス「ｆｅ８０：：１０」に対応付けられている（リスト番号２，３参照）。

このような場合には、前述のホスト名への統一処理により、サーバ識別子「ＡｐｐＳｅｒｖｅｒ．ｆｏｏ．ｔｅｓｔ」に係るサーバと、サーバ識別子「ＡｐｐＳｅｒｖｅｒ」に係るサーバが、同一のサーバであるものとして取り扱われる。そして、セッション判定部４０４は、実質的に、これら両方のサーバ識別子に係るアドレスリスト情報に基づいて、既存セッションの利用可能性を判定することとなる。

例えば、接続要求時の宛先情報の中でサーバ識別子「ＡｐｐＳｅｒｖｅｒ．ｆｏｏ．ｔｅｓｔ」が指定されているが、当該サーバ識別子に係るＩＰアドレスに係る既存セッションが無いものとする。この場合において、サーバ識別子「ＡｐｐＳｅｒｖｅｒ．ｆｏｏ．ｔｅｓｔ」と同一のサーバに係るサーバ識別子「ＡｐｐＳｅｒｖｅｒ」の既存セッションとして、ＩＰアドレス［２００１：：１０］に係るものが有るものとする。

このような場合、セッション判定部４０４は、サーバ識別子「ＡｐｐＳｅｒｖｅｒ．ｆｏｏ．ｔｅｓｔ」を用いた接続要求に対して、ＩＰアドレス［２００１：：１０］に係る既存セッションを利用可能であると判定する。

このようにして、サーバ識別子は異なるが、同一サーバに係るサーバ識別子については、同一のサーバ識別子として取り扱うことにより、異なるサーバ識別子を指定した場合にも、既存セッションを利用できるようにしている。これにより、一層、ソケット等のネットワークリソースを効率的に使用することが可能となる。

［第５の実施の形態］
第１〜４の実施の形態では、クライアントアプリケーション１０１とクライアントアプリケーション１０１ａが異なる宛先アドレスを指定した場合でも、両者が同一のセッションを利用する場合がある。この場合、クライアントプロセス間通信部１０３は、最初に確立されたセッションに係る宛先アドレスで実際の通信を行う。

しかし、最初に確立されたセッションに係る宛先アドレスによる通信において、通信障害が発生した場合は、他のアドレスによる通信が可能であっても、同一セッションで通信を行っている他のクライアントアプリケーションも通信不能となる。

そこで、第５の実施の形態では、通信障害が発生しても、接続可能な他のアドレスが存在する場合は、当該接続可能な他のアドレスに係るセッションを確立して通信を行うようにしている。

次に、プロセス間通信制御部４０１が行う第５の実施の形態に係るセッション管理処理を、図２０、図２１のフローチャートに基づいて説明する。なお、第５の実施の形態は、第４の実施の形態を応用変形したものであり、図２０，２１のフローチャートは、図１８のフローチャートと部分的に一致している。そこで、図２０，２１おいては、図１８と同一の処理については、同一のステップ番号を付して、その説明は省略し、相違点だけを説明することとする。

プロセス間通信制御部４０１は、図２１のステップＳ２００１において、ステップＳ７０８で行った選択に係るセッションによるデータ転送に成功したか否かを判別する。その結果、データ転送に成功した場合は、前述のステップＳ７０９〜Ｓ７１１の処理を行う。

一方、データ転送に失敗した場合は、セッション判定部４０４は、プロセス間通信制御部４０１の制御の下に、セッション管理情報ＤＢ４０６上にサーバ識別情報（ホスト名等）が同一の他のアドレスが存在するか否かを判定する（ステップＳ２００２）。その結果、サーバ識別情報が同一の他のアドレスが存在しない場合は、プロセス間通信制御部４０１は、データ転送のエラー処理を行って（ステップＳ２００６）、ステップＳ７０９に進む。

一方、サーバ識別情報が同一の他のアドレスが存在する場合は、プロセス間通信制御部４０１は、サーバ識別情報（ホスト名）が同一の他のアドレスに再度接続するためのセッションを確立する（ステップＳ２００３）。この場合、プロセス間通信制御部４０１は、サーバ識別情報（ホスト名）が同一の他のアドレスに係る新規ソケットを作成する。

この場合、プロセス間通信制御部４０１は、サーバ識別情報（ホスト名）が同一の他のアドレスが複数存在するときは、クライアントアプリケーション１−１，１０１ａが指定した宛先アドレスに係るセッションを優先的に確立する。

次に、プロセス間通信制御部４０１は、セッション管理部４０３により、再接続に係る
セッションの情報をセッション管理情報ＤＢ４０６に登録する（ステップＳ２００４）。そして、プロセス間通信制御部４０１は、再接続に係るセッションをデータ転送用のセッションとして選択し（ステップＳ２００５）、ステップＳ７０８に戻る。

このように、第５の実施の形態では、複数のアプリケーションが同一のセッションでデータ送信を行っている際に或るアプリケーションに係る通信で障害が発生しても、他のアプリケーションは通信を続行することができる。従って、第５の実施の形態では、通信障害に強くてデータ転送の信頼性が高い通信システムを構築することが可能となる。

［第６の実施の形態］
第４，５の実施の形態では、例えばアプリケーション１１０１が第１のセッションを切断すると、当該第１のセッションを利用しているクライアントアプリケーション１０１ａは通信を行えなくなってしまう。

そこで、第６の実施の形態では、この問題を次のようにして解決している。すなわち、プロセス間通信制御部４０１は、セッションのクローズ要求に応じて、その都度、セッションをクローズするのではなく、各セッションのクローズ・リファレンス・カウンタに基づいてセッションをクローズしている。第６の実施の形態では、接続リファレンスカウント記憶部４０８にクローズ・リファレンス・カウンタを記憶するものとする。

第６の実施の形態におけるセッション管理処理を、図２２のフローチャートに基づいて説明する。なお、第６の実施の形態は、第４の実施の形態を応用変形したものであり、図２２のフローチャートは、図７、図１８のフローチャートと部分的に一致している。そこで、図２２においては、図７、図１８と同一の処理については、同一のステップ番号を付して、その説明は省略し、相違点だけを説明することとする。

セッション切断管理部４０７は、プロセス間通信制御部４０１の制御の下に、図２２のステップＳ２２０１において、ステップＳ７０６又はＳ１８０３で選択されたセッションに係るクローズ・リファレンス・カウンタを「＋１」する。この際、セッション切断管理部４０７は、「＋１」した当該セッションのクローズ・リファレンス・カウンタの値を接続リファレンスカウント記憶部４０８に保存する。

そして、プロセス間通信制御部４０１は、ステップＳ７０６又はＳ７０７で選択されたセッションにより、データ転送を行う（ステップＳ７０８）。次に、プロセス間通信制御部４０１は、クライアントアプリケーション１０１，１０１ａからのクローズ要求、通信ライブラリ１０４ａからの通信切断要求などの有無を判断する（ステップＳ７０９）。その結果、上記のクローズ要求、又は切断要求が無い場合は、プロセス間通信制御部４０１は、ステップＳ７０１に戻る。

一方、上記のクローズ要求、切断要求の何れかが有る場合は、セッション切断管理部４０７は、その要求に係るアドレスのセッションのクローズ・リファレンス・カウンタを「−１」する（ステップＳ２２０２）。このように、セッション切断管理部４０７は、セッションに係る宛先アドレス毎に、当該宛先アドレスに対する接続要求時にはクローズ・リファレンス・カウンタを「１」だけカウントアップし、切断要求時には「１」だけカウントダウンする。

そして、プロセス間通信制御部４０１は、クローズ・リファレンス・カウンタの値が「−１」されることにより、「０」になったか否かを判断する（ステップＳ２２０３）。その結果、クローズ・リファレンス・カウンタの値が「０」になっていなければ、プロセス間通信制御部４０１は、ステップＳ７０１に戻る。

一方、クローズ・リファレンス・カウンタの値が「０」になっていれば、プロセス間通信制御部４０１は、ステップＳ７１０に進み、クローズ要求、切断要求に係るアドレスのセッション、ソケットのクローズ処理を行う。

このように、第６の実施の形態では、セッションのクローズ要求に応じて、その都度、セッションをクローズするのではなく、各セッションのクローズ・リファレンス・カウンタに基づいてセッションをクローズしている。

従って、異なるクライアントアプリケーションが同一のセッションを利用してデータ転送する場合に、一方のクライアントアプリケーションからの切断指示で、他方のクライアントアプリケーションがデータ転送不能となることはない。これにより、一層、ソケット等のネットワークリソースを効率的に使用することが可能となる。

［第７の実施の形態］
第１〜６の実施の形態では、既存セッションを利用できる場合は、必ずその既存セッションを用いて通信を行っていた。しかしながら、先に通信が開始された第１の通信により確立された既存セッションよりも、後から通信が開始される第２の通信により本来確立されるべき新規セッションの方が、通信速度、経由するルータの数等の関係で通信効率が良い場合がある。

そこで、第７の実施の形態では、たとえ利用可能な既存セッションが有ったとしても、今回の通信で確立されるべき新規セッションの方が既存セッションよりも通信効率が良い場合には、新規セッションを確立して通信を行うようにしている。

上記の通信効率を判定するために、第７の実施の形態では、図２４に示したように、クライアントプロセス間通信部１０３は、プロセス間通信制御部４０１の制御の下に回線情報を取得する回線情報取得部２４０１を設けている。

クライアントＰＣ１００の他のソフトウェア構成は、図４に示した第１の実施の形態とほぼ同様なので、相違点だけを説明する。なお、図２４では、図４に示したセッション切断管理部４０７、接続リファレンスカウント記憶部４０８、及びセッション再接続管理部４０９が図示省略されている。

回線情報取得部２４０１は、宛先アドレスに対応するネットワーク１０６上の通信ルートの回線情報を、通信ライブラリ１０４ａから取得する。そして、回線情報取得部２４０１は、ＤＢ管理部４０５を介して、その回線情報をセッション管理情報としてセッション管理情報ＤＢ４０６に登録する。

回線情報取得部２４０１が取得する回線情報としては、ＩＰｖ６ヘッダのＴｒａｆｆｉｃ Ｃｌａｓｓ、Ｆｌｏｗ Ｌａｂｅｌ、Ｈｏｐ ＬｉｍｉｔやＩＰｖ４ヘッダのＳｅｒｖｉｃｅ Ｔｙｐｅ、Ｔｉｍｅ Ｔｏ Ｌｉｖｅ、更には、通信帯域がある。

回線情報取得部２４０１は、ＩＰプロトコルのＰａｔｈ ＭＴＵ（Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ） Ｄｉｓｃｏｖｅｒｙを用いて、Ｐａｔｈ ＭＴＵを検出することができる。このＰａｔｈ ＭＴＵ Ｄｉｓｃｏｖｅｒｙは、１回のデータ転送で通信可能なデータグラムの最大値を自動的に検出するものである。Ｐａｔｈ ＭＴＵ Ｄｉｓｃｏｖｅｒｙに関しては、ＲＦＣ （Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）で規定されている。

回線情報取得部２４０１は、ＲＦＣ１９８１のＰａｔｈ ＭＴＵ ｄｉｓｃｏｖｅｒｙ ｆｏｒ ＩＰ ｖｅｒｓｉｏｎ ６ や、ＲＦＣ１１９１のＰａｔｈ ＭＴＵ Ｄｉｓｃｏｖｅｒｙ等を、通信ライブラリ１０４ａから取得する。

なお、回線情報取得部２４０１は、通信帯域に関しては、クライアントＰＣ１００に装着されたネットワークカードの帯域情報を取得することができる。また、回線情報取得部２４０１は、ＲＦＣ２２０５で規定されているネットワーク制御プロトコルにより、クライアントアプリケーションの制御する帯域情報を取得することができる。

図２５は、第７の実施の形態に係るセッション管理情報を提示した図である。このセッション管理情報は、セッション管理情報ＤＢ４０６にデータベースとして登録されている。

図２５に示した第７の実施の形態に係るセッション管理情報では、図５に示した第１の実施の形態に係るセッション情報のデータ項目に対して、回線情報２５０１が付加されている。この回線情報２５０１は、クライアントアプリケーション１０１，１０１ａが接続要求を行った際に宛先として指定した宛先アドレス、及びポート番号に対応する通信ルートの回線状態を示す情報である。

回線情報２５０１としては、例えば、帯域情報２５０１ａ、ルータ数２５０１ｂ、Ｐａｔｈ ＭＴＵ２５０１ｃがある。ただし、これら以外の回線情報を利用して通信効率を判定することも可能である。

次に、第７の実施の形態に係るセッション管理処理を、図２６、図２７のフローチャートに基づいて説明する。なお、本フローチャートは、第１の実施の形態に係る図７と共通する処理ステップが多数あるが、これら処理ステップについては、同一符号を付すだけで、その説明を省略する。

プロセス間通信制御部４０１は、ステップＳ７０２にてクライアントアプリケーション１０１からの宛先アドレスに対し、サーバＰＣ１０５からサーバ識別子を取得する。さらに、プロセス間通信制御部４０１は、回線情報取得部２４０１により、クライアントアプリケーション１０１，１０１ａからの宛先アドレスに対応する通信ルートに係る回線情報を取得する（ステップＳ２６０１）。

この場合、回線情報取得部２４０１は、ｇｅｔｓｏｃｋｏｐｔ関数により、クライアントＰＣ１００のＯＳ上のソケットライブラリから、上記の通信ルートに係る回線状態の情報を取得することができる。また、回線情報取得部２４０１は、上記ＯＳ上の通信ライブラリ１０４ａからＰａｔｈ ＭＴＵ Ｄｉｓｃｏｖｅｒｙを取得し、このＰａｔｈ ＭＴＵ Ｄｉｓｃｏｖｅｒｙを用いて上記の通信ルートに係るＰａｔｈ ＭＴＵ２５０１ｃを取得することもできる。さらに、回線情報取得部２４０１は、ＩＰｖ４ヘッダのＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）や、ＩＰｖ６ヘッダのＨｏｐ Ｌｉｍｉｔ情報を取得することも可能である。

次に、プロセス間通信制御部４０１は、セッション管理部４０３により、ステップＳ７０２で取得したサーバ識別子５０４と同一のサーバ識別子５０４に係る既存のセッションが存在するか否かを判別する（ステップＳ７０３）。

この場合、セッション管理部４０３は、ＤＢ管理部４０５により、セッション管理情報ＤＢ４０６からセッション管理情報を取得する。そして、セッション管理部４０３は、取得したセッション管理情報について、別のアドレスで通信中の既存セッションの中に、今回の接続要求時に取得したサーバ識別子５０４と同一のサーバ識別子５０４に係る既存セッションが存在するか否かを判定する。この判定処理は、実際には、セッション判定部４０４が行う。

ステップＳ７０２で取得したサーバ識別子５０４と同一のサーバ識別子５０４に係る既存のセッションが存在する場合は、プロセス間通信制御部４０１は、ステップＳ２６０２に進む。

このステップＳ２６０２では、プロセス間通信制御部４０１は、セッション判定部４０４により、接続済みの既存セッションに係る回線状態と、今回接続を要求された宛先アドレスに係る回線状態を比較し、後者の方が良好であるか否かを判別する。

図２５のセッション管理情報の例では、管理番号「１」と管理番号「２」の通信は、クライアントアプリケーションからの異なる宛先アドレスではあるが、サーバ識別子が同一のサーバへの接続要求に係る通信である。これら通信についてＰａｔｈ ＭＴＵ２５０１ｃで比較すると、管理番号「１」では「１５００」、管理番号「２」では「９０００」なので、Ｐａｔｈ ＭＴＰが大きい（通信オーバヘッドの少ない）管理番号「２」に係る回線状態の方が良好であると判別される。

また、ルータ数２５０１ｂで比較すると、管理番号「１」では「３」、管理番号「２」では「１」なので、経由するルータ数が少ない（通信オーバヘッドの少ない）管理番号「２」に係る回線状態の方が良好であると判別される。なお、帯域情報２５０１ａの取得方法等については、後で詳細に説明する。

帯域情報２５０１ａ、ルータ数２５０１ｂ、Ｐａｔｈ ＭＴＵ２５０１ｃによる回線状態の良好性の判別結果が互いに矛盾する場合も想定されるが、このような場合は、これらの判別結果を総合してトータルの通信オーバヘッド等で判別すればよい。

また、帯域情報２５０１ａ、ルータ数２５０１ｂ、Ｐａｔｈ ＭＴＵ２５０１ｃ以外の通信条件、例えば通信ルートのトラフィック量等の時々刻々変化する通信条件に回線状態の良好性を判別することも可能である。また、ユーザの指定により、帯域情報２５０１ａ、ルータ数２５０１ｂ、Ｐａｔｈ ＭＴＵ２５０１ｃ等のパラメータについてそれぞれに重み付けをして、トータルの通信オーバヘッド等で回線状態の良好性を判別することも可能である。

今回接続を要求された宛先アドレスに係る回線状態の方が、接続済みの既存セッションに係る回線状態よりも良好である場合は、プロセス間通信制御部４０１は、セッション管理部４０３により、新規にセッションを確立する（ステップＳ２６０３）。この場合、セッション管理部４０３は、通信ライブラリ１０４ａを利用して、クライアントアプリケーション１０１，１０１ａからの宛先アドレスで新規ソケットを作成する。

次に、セッション管理部４０３は、新規ソケットを含む新規セッションの情報を、ＤＢ管理部４０５により、セッション管理情報ＤＢ４０６に登録させる（ステップＳ２６０４）。そして、プロセス間通信制御部４０１は、クライアントアプリケーション１０１，１０１ａからの宛先アドレスに基づく新規セッションを、今回のデータ転送用のセッションとして選択する（ステップＳ２６０５）。

次に、プロセス間通信制御部４０１は、データ転送を行っていた通信の同一サーバに係る既存セッションを新規セッションに変更する（ステップＳ２６０６）。そして、プロセス間通信制御部４０１は、セッション管理情報ＤＢ４０６上の当該既存セッションを削除する（ステップＳ２６０７）。

図２５のセッション管理情報の例では、管理番号「３」と管理番号「２」の通信については、管理番号「２」の通信の方が良好な回線状態となっている。この回線常態において、管理番号「３」、管理番号「２」の順にクライアントアプリケーション１０１からの接続要求がなされたと仮定する。

この場合、まず、管理番号「３」に係るセッションが新規に作成される。このセッションでは、クライアントアプリケーション１０１が実際にデータ転送を行う通信アドレスは、［２００１：：２０］、ポート番号１０２５となる。

続いて、管理番号「２」の接続要求がクライアントアプリケーション１０１ａからなされたとすると、当該管理番号「２」の回線状態の方が管理番号「３」の回線状態よりも良好なので、当該管理番号「２」に係る新規セッションが改めて作成される。

そして、ステップＳ２６０５〜Ｓ２６０７の処理により、その後のクライアントアプリケーション１０１，１０１ａに係るデータ転送は、共に、管理番号「２」に係る新規セッションの通信アドレス［２００１：：１０］、ポート番号１０２５で行われることとなる。

接続済みの既存セッションに係る回線状態の方が、新規に要求があった宛先アドレスに係る回線状態よりも良好である場合は、プロセス間通信制御部４０１は、ステップＳ７０７に進む。このステップＳ７０７では、プロセス間通信制御部４０１は、今回の接続要求時に取得したサーバ識別子５０４と同一のサーバ識別子５０４に係る上記接続済みの既存セッションを今回のデータ通信用のセッションとして選択する。

次に、回線状態情報２５０１における帯域情報２５０１ａの取得方法について説明する。この帯域情報２５０１ａは、図２６のステップＳ２６０１において、回線情報取得部２４０１は、クライアントアプリケーション１０１，１０１ａからの宛先アドレスに応じて取得する。

この場合、回線情報取得部２４０１はＬｉｎｋＳｐｅｅｄ取得関数により、送信元アドレスから宛先アドレスにリンクする際のクライアントＰＣ１００のネットワークアダプタのＬｉｎｋＳｐｅｅｄを、クライアントＰＣ１００上のＯＳ上のソケットライブラリから取得する。

なお、回線情報取得部２４０１は、ネットワーク機器のＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を実現するネットワーク制御プロトコルを上記のＯＳ上のソケットライブラリから取得して、帯域情報２５０１ａを認識することができる。この場合、回線情報取得部２４０１は、ネットワーク制御プロトコルからＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）（ＲＦＣ２２０５）の設定値を取得する。

回線情報取得部２４０１は、これらの設定値を確認することにより、クライアントＰＣ１００のネットワークアダプタのＬｉｎｋＳｐｅｅｄや、通信経路上のネットワーク機器の利用帯域情報を取得することにより回線状態の良好性を判定する。

そして、クライアントプロセス間通信部１０３は、帯域情報２５０１ａ，ルータ数２５０１ｂ，回線情報２５０１ｃを総合的に判断することにより、異なるアドレスで確立されたセッションでデータ転送を行う際のアドレスを選定する。そして、クライアントプロセス間通信部１０３は、選定したアドレスに係るセッションを実際のデータ転送で用いるセッションとして選択する。

なお、回線状態の良好性を判定する場合、必ずしも低帯域情報２５０１ａ，ルータ数２５０１ｂ，回線情報２５０１ｃの全てを用いる必要はなく、これらの何れか１つ、又は２つを任意に組み合わせて回線状態の良好性を判定してもよい。

［他の実施の形態］
本発明は、複数の機器から構成されるシステムに適用しても良いし、また１つの機器からなる装置に適用しても良い。また、前述の各実施の形態では、主としてＩＰｖ６を通信プロトコルとして利用することを想定していたが、１つのノード等に複数のアドレスを割当てることが可能な他の通信プロトコルを利用する場合にも、当該各実施の形態に係る技術思想を適用可能である。

なお、本発明は、前述した各実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムを読み出して実行することによっても達成され得る。その場合、プログラムの機能を有していれば、形態はプログラムである必要はない。

また、プログラムの実行環境は、パーソナルコンピュータやパーソナルコンピュータでのオペレーションシステムを仮想化した仮想ＰＣやリモートＰＣを含む。さらに、画像形成装置、プリンタやＭＦＰ（マルチファンクションペリフェラル）等の組み込みコンピュータで実行される場合も含まれる。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明のクレームでは、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記録媒体としては、様々なものが使用できる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などである。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページからハードディスク等の記録媒体にダウンロードすることによっても供給できる。その場合、ダウンロードされるのは、本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルであってもよい。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布する形態としても良い。その場合、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムが実行可能な形式でコンピュータにインストールされるようにする。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される形態以外の形態でも実現可能である。例えば、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

更に、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれるようにしてもよい。この場合、その後で、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される。

１００…クライアントＰＣ
１０１、１０１ａ…クライアントアプリケーション
１０３…クライアントプロセス間通信部
１０４ａ，１０４ｂ…通信ライブラリ
１０５…サーバＰＣ
１０６…ネットワーク
１０７…サーバプロセス間通信部
１０８…サーバアプリケーション
２０８…ネットワーク制御部
３０２…セッション識別子返信部
４０３…セッション管理部
４０４…セッション判定部
４０５…ＤＢ管理部
４０６…セッション管理情報ＤＢ
４０７…セッション切断管理部
４０８…接続リファレンスカウント記憶部
４０９…セッション再接続管理部
１４０１…ＤＮＳサーバ
１５０１…アドレスリスト取得部
１５０２…アドレスリスト記憶部
１４０１…ＤＮＳサーバ
１５０１…アドレスリスト取得部
２４０１…回線情報取得部

Claims (18)

1. クライアント端末のクライアントアプリケーションと複数のアドレスを有するサーバのサーバアプリケーションとの間のセッションを管理するセッション管理システムにおいて、
   前記クライアント端末は、
   セッションを確立するために前記サーバのサーバ識別情報を取得する取得手段と、
   セッション情報及び前記サーバ識別情報を含むセッション管理情報を記憶する記憶手段と、
   前記クライアントアプリケーションが接続要求時に指定した宛先アドレスと異なるアドレスに係る既存セッションであって、前記サーバ識別情報で識別されるサーバが一致する既存セッションが前記記憶手段に記憶されているか否かを判別する判別手段と、
   前記判別手段により前記既存セッションが記憶されていると判別された場合に、当該既存セッションをデータ通信用のセッションとして選択する選択手段と、
   を有することを特徴とするセッション管理システム。
2. 前記記憶手段に記憶される前記セッション管理情報には、前記サーバ識別情報の他に、前記クライアントアプリケーションが接続要求時に指定した宛先アドレス、通信を行う際に利用する通信アドレス情報が含まれていることを特徴とする請求項１に記載のセッション管理システム。
3. 前記通信アドレス情報には、通信プロトコル、アドレス、ポート番号、エンドポイント又はチャネル情報が含まれていることを特徴とする請求項２に記載のセッション管理システム。
4. 前記記憶手段は、前記指定した宛先アドレス毎に接続要求数及び切断要求数を記憶するカウンタの値を記憶すると共に、当該カウンタの値に基づいてセッションを切断する切断管理手段を有することを特徴とする請求項１〜３の何れかに記載のセッション管理システム。
5. 前記切断管理手段は、前記アプリケーションから要求された宛先アドレスと異なるアドレスで確立された既存セッションで通信を行っている際に、当該既存セッションに対する切断指示が他のアプリケーションからなされた場合に、当該既存セッションを切断することなく、当該切断指示とは異なるアドレスの同一の前記サーバ識別情報に係るセッションを切断するように前記カウンタを更新する更新手段を有することを特徴とする請求項４に記載のセッション管理システム。
6. 前記選択手段は、通信エラーが発生した通信アドレスと同一の前記サーバ識別情報を含む他のアドレスに基づいてセッションを確立し、当該セッションを新たなデータ通信用のセッションとして選択することを特徴とする請求項１〜５の何れかに記載のセッション管理システム。
7. 前記取得手段は、前記サーバから前記サーバ識別情報を取得することを特徴とする請求項１〜６の何れかに記載のセッション管理システム。
8. 前記取得手段は、アドレス問題解決サービスを利用して前記サーバ識別情報を取得することを特徴とする請求項１〜６の何れかに記載のセッション管理システム。
9. 前記選択手段は、通信エラーが発生した通信アドレスと同一の前記サーバ識別情報を含む他のアドレスに基づいてセッションを確立し、当該セッションを新たなデータ通信用のセッションとして選択することを特徴とする請求項８に記載のセッション管理システム。
10. 前記選択手段は、前記他のアドレスが複数存在する場合は、前記クライアントアプリケーションが接続要求時に指定した宛先アドレスに係るセッションを、新たなデータ通信用のセッションとして優先的に選択することを特徴とする請求項９に記載のセッション管理システム。
11. 前記記憶手段は、前記選択手段により選択されたセッションに係る宛先アドレス毎に、当該宛先アドレスに対する接続要求時にはカウントアップし、切断要求時にはカウントダウンするカウンタを記憶すると共に、当該カウンタの値に基づいて当該セッションを切断する切断管理手段を有することを特徴とする請求項１〜３，６〜１０の何れかに記載のセッション管理システム。
12. 前記判別手段は、前記クライアントアプリケーションが接続要求時に指定した宛先アドレスにおける前記サーバ識別情報が異なっていても、同一のサーバに係るサーバ識別情報であれば同一のサーバ識別情報として取り扱うことにより、前記サーバが一致する既存セッションを認定することを特徴とする請求項１〜１１の何れかに記載のセッション管理システム。
13. 前記選択手段は、前記判別手段により既存セッションが記憶されていると判別された場合であっても、前記クライアントアプリケーションが接続要求時に指定した宛先アドレスに係るセッションの方が当該既存セッションよりも通信効率が良いときには、当該指定した宛先アドレスに係るセッションをデータ通信用のセッションとして選択することを特徴とする請求項１〜１２の何れかに記載のセッション管理システム。
14. 前記選択手段は、前記通信効率の良好性を通信帯域、経由するルータ数、通信可能なデータグラムを含む複数の通信条件に基づいて判断することを特徴とする請求項１３に記載のセッション管理システム。
15. クライアント端末のクライアントアプリケーションと複数のアドレスを有するサーバのサーバアプリケーションとの間のセッションを管理するセッション管理システムの制御方法において、
    前記クライアント端末は、
    セッションを確立するために前記サーバのサーバ識別情報を取得する取得工程と、
    セッション情報及び前記サーバ識別情報を含むセッション管理情報を記憶する記憶工程と、
    前記クライアントアプリケーションが接続要求時に指定した宛先アドレスと異なるアドレスに係る既存セッションであって、前記サーバ識別情報で識別されるサーバが一致する既存セッションが前記記憶工程で記憶されたか否かを判別する判別工程と、
    前記判別工程により前記既存セッションが記憶されたと判別された場合に、当該既存セッションをデータ通信用のセッションとして選択する選択工程と、
    を有することを特徴とするセッション管理システムの制御方法。
16. 搭載されたクライアントアプリケーションと複数のアドレスを有するサーバのサーバアプリケーションとの間のセッションを管理する機能を有するクライアント端末において、
    セッションを確立するために前記サーバのサーバ識別情報を取得する取得手段と、
    セッション情報及び前記サーバ識別情報を含むセッション管理情報を記憶する記憶手段と、
    前記クライアントアプリケーションから要求された宛先アドレスと異なるアドレスであって、前記サーバ識別情報で識別されるサーバが一致する既存セッションが前記記憶手段に記憶されているか否かを判別する判別手段と、
    前記判別手段により既存セッションが記憶されていると判定された場合に、当該既存セッションをデータ通信用のセッションとして選択する選択手段と、
    を有することを特徴とするクライアント端末。
17. 請求項１５に記載のセッション管理システムの制御方法をコンピュータにより実行させるためのコンピュータで読み取り可能なプログラム。
18. 請求項１７に記載のプログラムをコンピュータで読み取り可能に記録した記録媒体。

Images