(57)【特許請求の範囲】
【請求項１】
端末装置が使用するセッション毎に、当該セッションが確立済みであるか否かを示す確立済み情報と、当該セッションを確立するための処理が継続中である、当該セッションが確立処理中であるか否かを示す確立中情報とを対応付けて記憶する記憶部と、
前記端末装置からセッション開始要求を受信すると、確立済みでない旨を前記確立済み情報が示すセッションが前記記憶部内にあるか否かを判定し、確立済みではないセッションがある場合に、当該セッションに対応した確立中情報が確立処理中でない旨を示しているか否かを判定する情報判定部と、
前記セッションに対応した確立中情報が前記確立処理中でない旨を示している場合、当該セッション開始要求を発行した端末装置に対して当該セッションを割り当てる割当制御部と、
前記セッション開始要求を発行した端末装置に対して当該セッションを割り当てた場合、当該セッションに対応付けて、当該セッションを識別するセッション識別情報及び当該端末装置を識別する端末識別情報を登録すると共に、当該セッションに対応した確立中情報を確立処理中である旨に登録する情報登録部と、
端末装置からセッション実行要求を受信すると、当該セッション実行要求に含まれるセッション識別情報と同一のセッション識別情報のセッションが前記記憶部内にあるか否かを判定し、同一セッション識別情報を持つセッションがある場合、当該セッション識別情報を使用して当該セッション実行要求を発行した端末装置とのセッションを確立する制御部と
を有することを特徴とするセッション確立装置。
【請求項２】
前記割当制御部は、
前記セッションに対応した確立中情報が前記確立処理中である旨を示す場合、当該セッションに対応した端末識別情報が前記セッション開始要求を発行した端末装置の端末識別情報と同一であるか否かを判定する端末判定部を有し、
前記端末識別情報が同一の場合、当該セッション開始要求を発行した端末装置に対して当該セッションを割り当て、前記端末識別情報が同一でない場合、当該セッション開始要求を発行した端末装置に対する当該セッションの割り当てを禁止することを特徴とする請求項１記載のセッション確立装置。
【請求項３】
前記情報登録部は、
前記制御部が、前記セッション実行要求に含まれるセッション識別情報と同一のセッション識別情報のセッションがあると判定した場合、当該セッションに対応した確立中情報を確立処理中でない旨に登録し、当該セッションに対応した確立済み情報を確立済みである旨に登録することを特徴とする請求項１又は２記載のセッション確立装置。
【請求項４】
前記制御部は、
前記端末装置からセッション終了要求を受信すると、当該セッション終了要求に含まれるセッション識別情報に対応したセッションが前記記憶部内にあるか否かを判定し、当該セッションがある場合、当該セッションに関わる前記セッション終了要求を発行した端末装置とのセッションを切断し、
前記情報登録部は、
前記セッション終了要求に含まれるセッション識別情報に対応したセッションが前記記憶部内にある場合、当該セッションに対応した端末識別情報及びセッション識別情報を消去し、当該セッションに対応した確立済み情報を確立済みでない旨に登録することを特徴とする請求項１又は２記載のセッション確立装置。
【請求項５】
前記セッション開始要求及び前記セッション実行要求は、
インテリジェントプラットフォーム管理インタフェースの仕様に準拠した、前記端末装置とのセッション確立を要求するコマンドであることを特徴とする請求項１又は２記載のセッション確立装置。
【請求項６】
前記記憶部は、
前記端末装置が対向装置内の各内部装置の状態監視に使用するセッション毎に、前記確立済み情報と、前記確立中情報とを対応付けて記憶することを特徴とする請求項１〜５の何れか一つに記載のセッション確立装置。
【請求項７】
端末装置からセッション開始要求を受信すると、記憶部に記憶されている、セッションが確立済みであるか否かを示す確立済み情報を参照して、前記確立済み情報が確立済みではないことを示すセッションが前記記憶部内にあるか否かを判定し、
確立済みではないことを示すセッションが前記記憶部にある場合に、前記記憶部に記憶されている、当該セッションを確立するための処理が継続中である、当該セッションが確立処理中であるか否かを示す確立中情報を参照して、当該セッションが確立処理中であるか否かを判定し、
当該セッションに対応した前記確立中情報が前記確立処理中でない旨を示している場合、当該セッション開始要求を発行した端末装置に対して当該セッションを割り当て、
前記セッション開始要求を発行した端末装置に対して当該セッションを割り当てた場合、当該セッションを識別するセッション識別情報及び当該端末装置を識別する端末識別情報を当該セッションに対応付けて登録すると共に、当該セッションに対応した確立中情報を確立処理中である旨に登録し、
端末装置からセッション実行要求を受信すると、当該セッション実行要求に含まれるセッション識別情報と同一のセッション識別情報のセッションが前記記憶部内にあるか否かを判定し、同一セッション識別情報を持つセッションが前記記憶部内にある場合、当該セッション識別情報を使用して当該セッション実行要求を発行した端末装置とのセッションを確立することを特徴とするセッション確立方法。
【請求項８】
前記記憶部は、
前記端末装置が対向装置内の各内部装置の状態監視に使用するセッション毎に、前記確立済み情報と、前記確立中情報とを対応付けて記憶することを特徴とする請求項７記載のセッション確立方法。
【請求項９】
端末装置が使用するセッション毎に、当該セッションが確立済みであるか否かを示す確立済み情報と、当該セッションを確立するための処理が継続中である、当該セッションが確立処理中であるか否かを示す確立中情報とを対応付けて記憶部に記憶する記憶手順と、
前記端末装置からセッション開始要求を受信すると、確立済みでない旨を前記確立済み情報が示すセッションが前記記憶部内にあるか否かを判定し、確立済みではないセッションがある場合に、当該セッションに対応した確立中情報が確立処理中でない旨を示しているか否かを判定する情報判定手順と、
前記セッションに対応した確立中情報が前記確立処理中でない旨を示している場合、当該セッション開始要求を発行した端末装置に対して当該セッションを割り当てる割当制御手順と、
前記セッション開始要求を発行した端末装置に対して当該セッションを割り当てた場合、当該セッションに対応付けて、当該セッションを識別するセッション識別情報及び当該端末装置を識別する端末識別情報を登録すると共に、当該セッションに対応した確立中情報を確立処理中である旨に登録する情報登録手順と、
端末装置からセッション実行要求を受信すると、当該セッション実行要求に含まれるセッション識別情報と同一のセッション識別情報のセッションが前記記憶部内にあるか否かを判定し、同一セッション識別情報を持つセッションがある場合、当該セッション識別情報を使用して当該セッション実行要求を発行した端末装置とのセッションを確立する制御手順と
を含むプログラムをコンピュータ装置に実行させることを特徴とするセッション確立プログラム。
【請求項１０】
前記記憶部は、
前記端末装置が対向装置内の各内部装置の状態監視に使用するセッション毎に、前記確立済み情報と、前記確立中情報とを対応付けて記憶することを特徴とする請求項９記載のセッション確立プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、セッション確立装置、セッション確立方法及びセッション確立プログラムに関する。  
【背景技術】
【０００２】
近年、インテリジェントプラットフォーム管理インタフェース(Intelligent  Platform  Management  Interface:以下、単にＩＰＭＩと称する)を使用してサーバ装置の内部装置の状態情報をクライアント端末側で管理可能にしたサーバ管理システムが知られている。尚、ＩＰＭＩは、サーバ装置内の各内部装置の状態情報を監視可能にした標準インタフェースである。図１５は、サーバ管理システムを示すブロック図である。図１５に示すサーバ管理システム１００は、サーバ装置１１０と、クライアント端末１２０と、サーバ装置１１０とクライアント端末１２０との間を接続するＬＡＮ(Local  Area  Network)１３０とを有する。【０００３】
サーバ装置１１０は、例えば、ＣＰＵ（Central  Processing  Unit）及びメモリを搭載したシステムボード１１１Ａ、電源１１１Ｂ、ＩＯ（Input  Output）装置１１１Ｃやファン１１１Ｄ等の内部装置１１１を内蔵している。更に、各内部装置１１１は、自己の状態を検出するセンサ１１２を備えている。更に、サーバ装置１１０は、複数の内部装置１１１と、システム制御部１１３と、内部装置１１１とシステム制御部１１３との間を接続するＩ２Ｃバス１１４とを有する。システム制御部１１３は、ＩＰＭＩを使用して各内部装置１１１のセンサ１１２で検出した状態情報を収集する。クライアント端末１２０は、ＩＰＭＩを使用してＬＡＮ１３０経由でシステム制御部１１３と通信接続し、サーバ装置１１０内の各内部装置１１１の状態情報を監視可能にする。【０００４】
システム制御部１１３は、ポート部１４１と、ドライバ部１４２と、ＩＰＭＩ制御部１４３とを有する。ポート部１４１は、ＬＡＮ１３０と接続するインタフェースである。ドライバ部１４２は、Ｉ２Ｃバス１１４と接続するインタフェースである。ＩＰＭＩ制御部１４３は、論理チャネル部１５１と、コマンド処理部１５２と、デバイス部１５３と、セッション管理部１５４とを有する。【０００５】
論理チャネル部１５１は、ポート部１４１とコマンド処理部１５２との間の通信に使用するチャネルを論理的に関連付ける部位である。コマンド処理部１５２は、クライアント端末１２０からＩＰＭＩに準拠したコマンドを受信すると、コマンドに対応するコマンド処理を実行する。尚、コマンドとしては、例えば、各内部装置１１１のセンサ１１２で検出した状態情報の収集を指示するコマンドや、センサ１１２の設定変更を指示するコマンド等がある。デバイス部１５３は、コマンド処理部１５２で実行するコマンド処理に応じてセンサ１１２等の各種デバイスにアクセスする部位である。【０００６】
クライアント端末１２０とＩＰＭＩ制御部１４３との間の通信は、通信開始から通信切断までをセッション単位で維持される。尚、Ｖ１．５のＩＰＭＩでは、Get  Session  Challenge及びActivate  Sessionの一連の２コマンドを実行することで、クライアント端末１２０とＩＰＭＩ制御部１４３との間のセッションをオープン状態にする。また、ＩＰＭＩでは、Close  Sessionを実行することでクライアント端末１２０とＩＰＭＩ制御部１４３との間のセッションをクローズ状態にする。【０００７】
セッション管理部１５４は、クライアント端末１２０が使用するセッションのスロット１６１を記憶するスロット記憶部１６０を有する。スロット記憶部１６０は、クライアント端末１２０が使用するセッションを識別するセッションＩＤ１６１Ａと、セッション確立済みであるか否かを示すActiveフラグ１６１Ｂとを対応付けてスロット１６１単位で記憶する。尚、セッション確立済みとは、クライアント端末１２０とＩＰＭＩ制御部１４３との間のセッションが確立済みであることを示す。【０００８】
図１６は、セッションオープン時及びセッションクローズ時に関わるサーバ管理システム１００の一連の処理動作を示すシーケンス図である。クライアント端末１２０は、Get  Session  Challengeリクエストを発行し、そのGet  Session  ChallengeリクエストをＬＡＮ１３０経由でコマンド処理部１５２に通知する(ステップＳ１１１)。コマンド処理部１５２は、Get  Session  Challengeリクエストを受信すると、使用するセッションを識別する新規セッションＩＤの生成をセッション管理部１５４に依頼する(ステップＳ１１２)。セッション管理部１５４は、新規セッションＩＤの生成依頼を受信すると、新規セッションＩＤを生成する(ステップＳ１１３)。更に、セッション管理部１５４は、Activeフラグ１６１Ｂが“ＯＦＦ”に登録済みのスロット１６１を割り当て、当該スロット１６１に新規セッションＩＤを登録する(ステップＳ１１４)。すなわち、スロット１６１には、例えば、新規セッションＩＤ１６１Ａ“１”と、Activeフラグ１６１Ｂ“ＯＦＦ”とを対応付けて登録する。【０００９】
更に、セッション管理部１５４は、スロット１６１に登録した新規セッションＩＤを読み出す（ステップＳ１１４Ａ）。そして、セッション管理部１５４は、Get  Session  Challengeリクエストに対するGet  Session  Challengeレスポンスに新規セッションＩＤを付加し、このレスポンスをコマンド処理部１５２経由でクライアント端末１２０に返信する(ステップＳ１１５)。尚、図１６の例では、Get  Session  Challengeレスポンスには、ステップＳ１１４で登録した新規セッションＩＤ“１”を付加する。クライアント端末１２０は、Get  Session  Challengeリクエストに後続する、セッションを確立するためのActivate  Sessionリクエストをコマンド処理部１５２経由でセッション管理部１５４に通知する(ステップＳ１１６)。尚、Activate  Sessionリクエストには、Get  Session  Challengeレスポンスに付加したセッションＩＤ“１”を付加する。【００１０】
セッション管理部１５４は、Activate  Sessionリクエストを受信すると、当該リクエストに付加されたセッションＩＤ１６１Ａを登録済みのスロット１６１のActiveフラグ１６１Ｂに“ＯＮ”を登録する(ステップＳ１１７)。すなわち、当該スロット１６１には、セッションＩＤ１６１Ａ“１”と、Activeフラグ１６１Ｂ“ＯＮ”とを対応付けて登録する。【００１１】
そして、セッション管理部１５４は、当該スロット１６１の登録完了に応じて（ステップＳ１１７Ａ）、Activate  Sessionリクエストに対するActivate  Sessionレスポンスをコマンド処理部１５２経由でクライアント端末１２０に返信する(ステップＳ１１８)。その結果、セッション管理部１５４は、クライアント端末１２０とＩＰＭＩ制御部１４３との間のセッションをオープン状態にする。【００１２】
クライアント端末１２０は、ＩＰＭＩ制御部１４３とのセッションがオープン状態となった後、ＬＡＮ１３０経由でＩＰＭＩに準拠した一般コマンドを発行し、その一般コマンドをコマンド処理部１５２に通知する(ステップＳ１１９)。尚、一般コマンドは、例えば、各内部装置１１１のセンサ１１２で検出した状態情報の収集を指示するコマンドや、センサ１１２の設定変更を指示するコマンド等である。コマンド処理部１５２は、一般コマンドに対応するコマンド処理を実行し、そのコマンドの実行完了をＬＡＮ１３０経由でクライアント端末１２０に返信する(ステップＳ１２０)。【００１３】
クライアント端末１２０は、現在使用中のセッションをクローズすべく、セッションＩＤを付加したClose  SessionコマンドをＬＡＮ１３０経由でコマンド処理部１５２に通知する(ステップＳ１２１)。コマンド処理部１５２は、セッションＩＤを付加したClose  Sessionコマンドを受信すると、当該セッションＩＤ１６１Ａを登録済みのスロット１６１からのセッションＩＤ破棄をセッション管理部１５４に依頼する(ステップＳ１２２)。【００１４】
セッション管理部１５４は、セッションＩＤ破棄の依頼に応じて該当スロット１６１内のセッションＩＤ１６１Ａをゼロクリアすると共に、該当スロット１６１内のActiveフラグ１６１Ｂに“ＯＦＦ”を登録する(ステップＳ１２３)。すなわち、当該スロット１６１は、セッションＩＤ１６１Ａ“０”と、Activeフラグ１６１Ｂ“ＯＦＦ”とを対応付けて登録する。【００１５】
セッション管理部１５４は、当該スロット１６１の登録完了に応じて（ステップＳ１２３Ａ）、Close  Sessionコマンドに対するClose  Sessionレスポンスをコマンド処理部１５２及びＬＡＮ１３０経由でクライアント端末１２０に返信する(ステップＳ１２４)。その結果、セッション管理部１５４は、クライアント端末１２０とＩＰＭＩ制御部１４３との間のセッションをクローズ状態にする。【００１６】
上記サーバ管理システム１００では、スロット記憶部１６０内の複数のスロット１６１を使用して複数のクライアント端末１２０とのセッションを管理できる。
【先行技術文献】
【特許文献】
【００１７】
【特許文献１】特開２００７−２０１６８８号公報
【特許文献２】特開２００２−３５９６３７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１８】
サーバ管理システム１００では、ＩＰＭＩ制御部１４３にアクセスするクライアント端末１２０の台数が増加した場合、クライアント端末１２０とのセッションオープン中に他のクライアント端末１２０からのセッションオープンが競合してしまうことがある。【００１９】
例えば、クライアント端末１２０ＡからGet  Session  Challengeリクエストを受信した場合、セッション管理部１５４は、“ＯＦＦ”のActiveフラグ１６１Ｂを登録済みのスロット“１”をクライアント端末１２０Ａに割り当てる。更に、セッション管理部１５４は、当該スロット“１”に新規セッションＩＤを登録する。すなわち、スロット“１”には、セッションＩＤ１６１Ａ“１”と、Activeフラグ１６１Ｂ“ＯＦＦ”とを対応付けて登録することになる。【００２０】
クライアント端末１２０Ａから先に発行したGet  Session  Challengeリクエストに後続するActivate  Sessionリクエストを受信する前に、セッション管理部１５４がクライアント端末１２０ＢからGet  Session  Challengeリクエストを受信したとする。この際、セッション管理部１５４は、クライアント端末１２０ＡからのActivate  Sessionリクエストが未受信のため、そのActiveフラグ１６１Ｂは“ＯＦＦ”のままである。従って、セッション管理部１５４は、クライアント端末１２０ＢからのGet  Session  Challengeリクエストを受信すると、Activeフラグ１６１Ｂが“ＯＦＦ”のスロット“１”をクライアント端末１２０Ｂに対して再度割り当てしまう。その結果、クライアント端末１２０Ｂで使用するセッションＩＤ“１”を当該スロット“１”に重複登録してしまうことになる。【００２１】
つまり、セッション管理部１５４は、クライアント端末１２０Ａ及び１２０Ｂで使用するセッションが競合してしまうことになる。この状態でセッション管理部１５４が、クライアント端末１２０Ａよりも先に、クライアント端末１２０ＢからActivate  Sessionリクエストを受信したとする。この場合、セッション管理部１５４は、クライアント端末１２０Ｂに対してセッションＩＤ“１”のセッションをオープン状態にしてしまう。その結果、先にGet  Session  Challengeリクエストを発行したクライアント端末１２０ＡからActivate  Sessionリクエストを受信したとしても、そのセッションがクライアント端末１２０Ｂで使用中のため、セッションエラーが生じてしまう。【００２２】
つまり、クライアント端末１２０Ａは、Get  Session  Challengeリクエストを先に要求したにも関わらず、後で要求したクライアント端末１２０Ｂによってセッションが横取りされてしまうといった事態が生じる。【００２３】
そこで、このような事態に対処すべく、複数のクライアント端末１２０からGet  Session  Challengeリクエストが競合したとしても、各クライアント端末１２０に別のスロットを割り当てることが考えられる。しかしながら、障害等で同一クライアント端末１２０からGet  Session  Challengeリクエストを連続的に受信した場合に、その都度、同一クライアント端末１２０に別のスロットが順次割り当てられてしまう。その結果、セッション確立の限度数を超えたセッション数オーバが生じる。【００２４】
開示技術は上記点に鑑みてなされたものであり、その目的とするところは、複数のセッション要求が競合したとしても、セッションを円滑に確立できるセッション確立装置、セッション確立方法及びセッション確立プログラムを提供することにある。
【課題を解決するための手段】
【００２５】
本願の開示するセッション確立装置は、一つの態様において、端末装置が使用するセッション毎に、当該セッションが確立済みであるか否かを示す確立済み情報と、当該セッションが確立処理中であるか否かを示す確立中情報とを対応付けて記憶する記憶部と、前記端末装置からセッション開始要求を受信すると、確立済みでない旨を前記確立済み情報が示すセッションが前記記憶部内にあるか否かを判定し、確立済みではないセッションがある場合に、当該セッションに対応した確立中情報が確立処理中でない旨を示しているか否かを判定する情報判定部と、前記セッションに対応した確立中情報が前記確立処理中でない旨を示している場合、当該セッション開始要求を発行した端末装置に対して当該セッションを割り当てる割当制御部と、前記セッション開始要求を発行した端末装置に対して当該セッションを割り当てた場合、当該セッションに対応付けて、当該セッションを識別するセッション識別情報及び当該端末装置を識別する端末識別情報を登録すると共に、当該セッションに対応した確立中情報を確立処理中である旨に登録する情報登録部と、端末装置からセッション実行要求を受信すると、当該セッション実行要求に含まれるセッション識別情報と同一のセッション識別情報のセッションが前記記憶部内にあるか否かを判定し、同一セッション識別情報を持つセッションがある場合、当該セッション識別情報を使用して当該セッション実行要求を発行した端末装置とのセッションを確立する制御部とを有するようにした。
【発明の効果】
【００２６】
本願の開示するセッション確立装置の一つの態様では、複数のセッション要求が競合したとしても、セッションを円滑に確立できるという効果を奏する。
【図面の簡単な説明】
【００２７】
【図１】図１は、実施例１のセッション確立装置を示すブロック図である。
【図２】図２は、実施例２のサーバ管理システムを示すブロック図である。
【図３】図３は、Get  Session  Challengeリクエストのフォーマットを示す説明図である。
【図４】図４は、Get  Session  Challengeレスポンスのフォーマットを示す説明図である。
【図５】図５は、Activate  Sessionリクエストのフォーマットを示す説明図である。
【図６】図６は、Activate  Sessionレスポンスのフォーマットを示す説明図である。
【図７】図７は、Close  Sessionコマンドのフォーマットを示す説明図である。
【図８】図８は、Close  Sessionレスポンスのフォーマットを示す説明図である。
【図９】図９は、Get  Session  Challengeリクエスト受信処理に関わるセッション管理部の処理動作を示すフローチャートである。
【図１０】図１０は、Activate  Sessionリクエスト受信処理に関わるセッション管理部の処理動作を示すフローチャートである。
【図１１】図１１は、Close  Sessionコマンド受信処理に関わるセッション管理部の処理動作を示すフローチャートである。
【図１２】図１２は、セッションオープン競合時に関わるサーバ管理システムの処理動作を示すシーケンス図である。
【図１３】図１３は、Ｖ２．０のＩＰＭＩのセッションシーケンスの一例を示す説明図である。
【図１４】図１４は、セッション確立プログラムを実行するコンピュータを示す説明図である。
【図１５】図１５は、サーバ管理システムを示すブロック図である。
【図１６】図１６は、セッションオープン時及びセッションクローズ時に関わるサーバ管理システムの一連の処理動作を示すシーケンス図である。
【発明を実施するための形態】
【００２８】
以下、図面に基づいて、本願の開示するセッション確立装置、セッション確立方法及びセッション確立プログラムの実施例を詳細に説明する。尚、本実施例により、開示技術が限定されるものではない。
【実施例１】
【００２９】
図１は、実施例１のセッション確立装置を示すブロック図である。図１に示すセッション確立装置１は、複数の端末装置２と接続可能となっている。セッション確立装置１は、情報判定部１１と、記憶部１２と、割当制御部１３と、情報登録部１４と、制御部１５とを有する。【００３０】
記憶部１２は、端末装置２が使用するセッション毎に、確立済み情報１２Ｃ及び確立中情報１２Ｄを対応付けて記憶する。尚、確立済み情報１２Ｃは、セッションが確立済みであるか否かを示す情報である。確立中情報１２Ｄは、セッションが確立処理中であるか否かを示す情報である。尚、確立処理中とは、セッションを確立するための処理が継続中で未確立の状態である。これに対して、確立済みとは、セッションが確立した状態である。【００３１】
情報判定部１１は、端末装置２からセッション開始要求を受信すると、確立済み情報１２Ｃが確立済みでない旨を示しているセッションが記憶部１２内にあるか否かを判定する。更に、情報判定部１１は、確立済みではないセッションが記憶部１２内にある場合、当該セッションに対応した確立中情報１２Ｄが確立処理中でない旨を示しているか否かを判定する。割当制御部１３は、セッションに対応した確立中情報１２Ｄが確立処理中でない旨を示している場合、セッション開始要求を発行した端末装置２に対して当該セッションを割り当てる。【００３２】
また、割当制御部１３は、確立済み情報１２Ｃが確立済みでない旨を示しているセッションが記憶部１２内にない場合、セッション開始要求を発行した端末装置２に対する当該セッションの割当を禁止する。また、割当制御部１３は、セッションに対応した確立中情報１２Ｄが確立処理中でない旨を示していない場合、セッション開始要求を発行した端末装置２に対する当該セッションの割当を禁止する。【００３３】
情報登録部１４は、セッション開始要求を発行した端末装置２に対してセッションを割り当てた場合、割り当てたセッションに対応付けて、セッションを識別するセッション識別情報１２Ｂ及びセッション開始要求を発行した端末装置２を識別する端末識別情報１２Ｅを記憶部１２に登録する。更に、情報登録部１４は、当該セッションに対応する確立中情報１２Ｄを確立処理中である旨に登録する。【００３４】
制御部１５は、端末装置２からセッション実行要求を受信すると、セッション実行要求に含まれるセッション識別情報と同一のセッション識別情報１２Ｂを持つセッションが記憶部１２内にあるか否かを判定する。制御部１５は、同一セッション識別情報を持つセッションが記憶部１２内に登録されている場合、当該セッション識別情報を使用して当該セッション実行要求を発行した端末装置２とのセッションを確立する。【００３５】
また、制御部１５は、同一セッション識別情報を持つセッションが記憶部１２内にない場合、当該セッション識別情報を使用しての当該セッション実行要求を発行した端末装置２とのセッション確立を禁止する。【００３６】
実施例１では、端末装置２からセッション開始要求を受信すると、確立済み情報１２Ｃがセッション確立済みでない旨を示すセッションが記憶部１２内にあるか否かを判定する。更に、確立済みではないセッションが記憶部１２内にある場合、当該セッションに対応した確立中情報１２Ｄが確立処理中でない旨を示しているか否かを判定する。記憶部１２内のセッションに対応した確立中情報１２Ｄが確立処理中でない場合、当該セッション開始要求を発行した端末装置２に対して当該記憶部１２内のセッションを割り当てる。更に、実施例１では、割り当てられたセッションに対応付けて、そのセッションのセッション識別情報１２Ｂ及び端末装置２の端末識別情報１２Ｅを登録し、割り当てられたセッションに対応する確立中情報１２Ｄを確立処理中である旨に登録する。【００３７】
例えば、記憶部１２内に登録済みの確立済み情報１２Ｃがセッション確立済みでない場合及び確立中情報１２Ｄが確立処理中でない場合、割当制御部１３は、セッション開始要求を発行した端末装置２に対する当該記憶部１２に登録済みのセッションを割り当てる。これに対して、確立済み情報１２Ｃがセッション確立済みである場合、又は確立中情報１２Ｄが確立処理中である場合、割当制御部１３は、セッション開始要求を発行した端末装置２に対する当該記憶部１２に登録済みのセッションの割当を禁止する。【００３８】
つまり、セッション確立装置１は、セッション毎の確立済み情報１２Ｃ及び確立中情報１２Ｄの参照結果に基づき、セッション開始要求を発行した端末装置２に対するセッションの割当を制御する。その結果、セッション確立装置１は、セッション開始要求が競合した複数の端末装置２に対する同一セッションの重複割当を回避できる。【００３９】
更に、実施例１では、端末装置２からセッション実行要求を受信すると、セッション実行要求に含まれるセッション識別情報と同一のセッション識別情報１２Ｂのセッションが記憶部１２内にあるか否かを判定する。更に、実施例１では、同一セッション識別情報を持つセッションが記憶部１２内にある場合、当該セッション識別情報を使用してセッション実行要求を発行した端末装置２とのセッションを確立する。その結果、セッション確立装置１は、セッション開始要求が競合した複数の端末装置２に対する同一セッションの重複割当を回避することで、端末装置２がセッション開始要求を先に要求したにも関わらず、後で要求した他の端末装置２によってセッションが横取りされてしまうような事態を回避できる。そして、セッション確立装置１は、円滑なセッションの確立を実現できる。
【実施例２】
【００４０】
図２は、実施例２のサーバ管理システムを示すブロック図である。図２に示すサーバ管理システム１Ａは、サーバ装置３と、複数台のクライアント端末２０と、サーバ装置３とクライアント端末２０とを接続するＬＡＮ４とを有する。サーバ管理システム１Ａは、ＩＰＭＩを使用してサーバ装置３の内部装置の状態情報をクライアント端末２０側で管理可能にした。【００４１】
サーバ装置３は、複数の内部装置２１と、システム制御部２２と、内部装置２１とシステム制御部２２との間を接続するＩ２Ｃバス２３とを有する。内部装置２１は、例えば、ＣＰＵ及びメモリを搭載したシステムボード２１Ａ、電源２１Ｂ、ＩＯ装置２１Ｃやファン２１Ｄ等に相当する。更に、各内部装置２１は、自己の状態を検出するセンサ２１Ｅを内蔵している。【００４２】
システム制御部２２は、ＩＰＭＩを使用して各内部装置２１のセンサ２１Ｅで検出した状態情報を収集する。クライアント端末２０は、ＩＰＭＩを使用してＬＡＮ４経由でシステム制御部２２と通信接続し、サーバ装置３内の各内部装置２１の状態情報を監視可能にする。【００４３】
システム制御部２２は、ポート部３１と、ドライバ部３２と、ＩＰＭＩ制御部３３とを有する。ポート部３１は、ＬＡＮ４と接続するインタフェースである。ドライバ部３２は、Ｉ２Ｃバス２３と接続するインタフェースである。ＩＰＭＩ制御部３３は、論理チャネル部４１と、コマンド処理部４２と、デバイス部４３と、セッション管理部４４とを有する。論理チャネル部４１は、ポート部３１とコマンド処理部４２との間の通信に使用するチャネルを論理的に関連付ける部位である。コマンド処理部４２は、クライアント端末２０からＩＰＭＩに準拠したコマンドを受信すると、コマンドに対応するコマンド処理を実行する。尚、コマンドとしては、例えば、各内部装置２１のセンサ２１Ｅで検出した状態情報の収集を指示するコマンドや、各センサ２１Ｅの設定変更を指示するコマンド等である。デバイス部４３は、コマンド処理部４２で実行するコマンド処理に応じてセンサ２１Ｅ等の各種デバイスにアクセスする部位である。【００４４】
クライアント端末２０とＩＰＭＩ制御部３３との間の通信は、通信開始から通信切断までをセッション単位で維持される。尚、Ｖ１．５のＩＰＭＩでは、Get  Session  Challenge及びActivate  Sessionの一連の２コマンドを実行することで、クライアント端末２０とＩＰＭＩ制御部３３との間のセッションをオープン状態にする。また、ＩＰＭＩでは、Close  Sessionを実行することでクライアント端末２０とＩＰＭＩ制御部３３との間のセッションをクローズ状態にする。【００４５】
セッション管理部４４は、情報判定部５１と、スロット記憶部５２と、割当制御部５３と、情報登録部５４と、制御部５５とを有する。セッション管理部４４は、クライアント端末２０からのGet  Session  Challengeリクエストに対して応答した後、同一クライアント端末２０からのActivate  Sessionリクエストに対して応答すると、クライアント端末２０とのセッションをオープン状態にする。【００４６】
スロット記憶部５２は、クライアント端末２０が使用するセッションに割り当てられたスロット５２Ａ毎に、セッションＩＤ５２Ｂと、Activeフラグ５２Ｃと、Establishmentフラグ５２Ｄと、ＩＰアドレス５２Ｅとを対応付けて記憶する。セッションＩＤ５２Ｂは、クライアント端末２０が使用するセッションを識別するＩＤである。Activeフラグ５２Ｃは、クライアント端末２０が使用するセッションがオープン済み、すなわち確立済みであるか否かを示すフラグである。Activeフラグ５２Ｃは、セッションが確立済みの場合を“ＯＮ”、セッションが確立済みでない場合を“ＯＦＦ”とする。【００４７】
Establishmentフラグ５２Ｄは、クライアント端末２０が使用するセッションがオープン前の確立処理中であるか否かを示すフラグである。尚、確立処理中とは、セッションオープン前の処理、すなわち後述するGet  Session  Challengeリクエスト受信処理が完了し、後述するActivate  Sessionが未完の状態である。Establishmentフラグ５２Ｄは、セッションを確立処理中の場合を“ＯＮ”、セッションを確立処理中でない場合を“ＯＦＦ”とする。ＩＰアドレス５２Ｅは、クライアント端末２０を識別する端末識別情報である。【００４８】
情報判定部５１は、クライアント端末２０からGet  Session  Challengeリクエストを受信すると、スロット記憶部５２内からスロットを順次参照し、参照スロットに登録済みのActiveフラグ５２Ｃが“ＯＦＦ”であるか否かを判定する。情報判定部５１は、参照スロットに登録済みのActiveフラグ５２Ｃが“ＯＦＦ”の場合、参照スロットに登録済みのEstablishmentフラグ５２Ｄが“ＯＦＦ”であるか否かを判定する。また、情報判定部５１は、参照スロットに登録済みのActiveフラグ５２Ｃが“ＯＮ”の場合、参照スロットは使用中であると判断し、未参照スロットを検索する。【００４９】
また、割当制御部５３は、参照スロットに登録済みのEstablishmentフラグ５２Ｄが“ＯＦＦ”である場合、当該Get  Session  Challengeリクエストを発行したクライアント端末２０に対して当該スロットを割り当てる。また、割当制御部５３は、参照スロットに登録済みのEstablishmentフラグ５２Ｄが“ＯＮ”である場合、参照スロットに登録済みのＩＰアドレス５２Ｅと、当該リクエストを発行したクライアント端末２０のＩＰアドレスとを使用して当該クライアント端末２０に対するスロット割当の成否を識別する。【００５０】
また、情報登録部５４は、Get  Session  Challengeリクエストを発行したクライアント端末２０に対してスロットを割り当てた場合、当該スロットに対応付けて、そのセッションのセッションＩＤ５２Ｂ及びクライアント端末２０のＩＰアドレス５２Ｅを登録する。更に、情報登録部５４は、当該スロットのEstablishmentフラグ５２Ｄに“ＯＮ”を登録する。【００５１】
制御部５５は、クライアント端末２０からActivate  Sessionリクエストを受信すると、スロット記憶部５２内からスロットを順次参照する。更に、制御部５５は、参照スロットに登録済みのセッションＩＤ５２ＢがActivate  Sessionリクエストに含まれるセッションＩＤと同一であるか否かを判定する。制御部５５は、セッションＩＤが同一の場合、そのセッションＩＤのセッションを使用してActivate  Sessionリクエストを発行したクライアント端末２０とのセッションをオープン状態にする。【００５２】
制御部５５は、参照スロットに登録済みのセッションＩＤ５２Ｂが、Activate  Sessionリクエストに含まれるセッションＩＤと同一でない場合、そのセッションＩＤのセッションを使用してActivate  Sessionリクエストを実行したクライアント端末２０に対するセッションオープンを禁止する。【００５３】
情報登録部５４は、参照スロットに登録済みのセッションＩＤ５２ＢがActivate  Sessionリクエストに含まれるセッションＩＤと同一の場合、参照スロットのEstablishmentフラグ５２Ｄに“ＯＦＦ”を登録する。更に、情報登録部５４は、当該スロットのActiveフラグ５２Ｃに“ＯＮ”を登録する。【００５４】
また、割当制御部５３は、端末判定部５３Ａを有する。端末判定部５３Ａは、Get  Session  Challengeリクエスト受信時に任意のスロットを参照する。更に、端末判定部５３Ａは、参照スロットに登録済みのEstablishmentフラグ５２Ｄが“ＯＮ”の場合、参照スロットに登録済みのＩＰアドレス５２ＥがGet  Session  Challengeリクエストを発行したクライアント端末２０のＩＰアドレスと同一であるか否かを判定する。【００５５】
割当制御部５３は、端末判定部５３ＡにてＩＰアドレスが同一と判定された場合、Activate  Session未完のまま、クライアント端末２０が再度Get  Session  Challengeリクエストを発行したものと判断する。更に、割当制御部５３は、そのGet  Session  Challengeリクエストを発行したクライアント端末２０に対して当該スロットを再度割り当てる。また、割当制御部５３は、端末判定部５３ＡにてＩＰアドレスが同一でない場合、そのGet  Session  Challengeリクエストを発行したクライアント端末２０に対する当該スロットの割り当てを禁止する。【００５６】
制御部５５は、クライアント端末２０からClose  Sessionコマンドを受信すると、スロット記憶部５２内からスロットを順次参照する。更に、制御部５５は、参照スロットに登録済みのセッションＩＤ５２Ｂが当該Close  Sessionコマンドに含まれるセッションＩＤと同一であるか否かを判定する。制御部５５は、同一セッションＩＤの場合、当該スロットに登録済みのセッションＩＤ５２Ｂに関わるクライアント端末２０とのセッションを切断する。情報登録部５４は、受信したClose  Sessionコマンドが有するセッションＩＤ５２Ｂを登録済みのスロットがある場合、当該スロットに登録済みのセッションＩＤ５２Ｂ及びＩＰアドレス５２Ｅをゼロクリアする。更に、情報登録部５４は、当該スロットのActiveフラグ５２Ｃに“ＯＦＦ”を登録する。【００５７】
また、制御部５５は、セッションＩＤが同一でない場合、参照スロットがClose  Sessionコマンドを発行したクライアント端末２０のスロットではないものと判断し、更なる未参照スロットを参照することになる。【００５８】
次に、図３乃至図８に基づき、ＩＰＭＩで使用するセッションコマンドのフォーマットについて説明する。図３は、Get  Session  Challengeリクエストのフォーマットを示す説明図、図４は、Get  Session  Challengeレスポンスのフォーマットを示す説明図、図５は、Activate  Sessionリクエストのフォーマットを示す説明図である。更に、図６は、Activate  Sessionレスポンスのフォーマットを示す説明図、図７は、Close  Sessionコマンドのフォーマットを示す説明図、図８は、Close  Sessionレスポンスのフォーマットを示す説明図である。【００５９】
図３に示すGet  Session  Challengeリクエスト６１は、認証タイプの有無６１Ａ、セッションシーケンス番号６１Ｂ、セッションＩＤ６１Ｃ、認証コードの有無６１Ｄ、リクエストされた認証タイプ６１Ｅ及び、ユーザ名６１Ｆ等を含む。尚、Ｂｙｔｅは、データを格納するバイト単位の格納番号に相当する。認証タイプの有無６１Ａ、セッションシーケンス番号６１Ｂ、セッションＩＤ６１Ｃ及び認証コードの有無６１ＤはＢｙｔｅ“０”に格納する。リクエストされた認証タイプ６１Ｅは、Ｂｙｔｅ“１”に格納する。ユーザ名６１Ｆは、Ｂｙｔｅ“２”〜“１７”に格納する。【００６０】
図４に示すGet  Session  Challengeレスポンス６２は、認証タイプの有無６２Ａ、セッションシーケンス番号６２Ｂ、セッションＩＤ６２Ｃ及び認証コードの有無６２Ｄを含む。更に、Get  Session  Challengeレスポンス６２は、完了コード６２Ｅ、テンポラリセッションＩＤ６２Ｆ及びチャレンジデータ６２Ｇ等を含む。尚、テンポラリセッションＩＤ６２Ｆは、Get  Session  Challengeリクエストを実行したクライアント端末２０に新規に割り当てられた、Activate  Sessionリクエストで使用するセッションＩＤに相当する。チャレンジデータ６２Ｇは、Activate  Sessionリクエストで使用する文字列に相当する。認証タイプの有無６２Ａ、セッションシーケンス番号６２Ｂ、セッションＩＤ６２Ｃ及び認証コードの有無６２ＤはＢｙｔｅ“０”に格納する。完了コード６２ＥはＢｙｔｅ“１”に格納する。テンポラリセッションＩＤ６２ＦはＢｙｔｅ“２”〜“５”に格納する。チャレンジデータ６２ＧはＢｙｔｅ“６”〜“２１”に格納する。【００６１】
図５に示すActivate  Sessionリクエスト６３は、認証タイプ６３Ａ、セッションシーケンス番号６３Ｂ、セッションＩＤ(テンポラリセッションＩＤ)６３Ｃ、指定アルゴリズムで算出したＩＤ６３Ｄを含む。尚、セッションＩＤ６３Ｃは、Get  Session  Challengeレスポンス６２から得たテンポラリセッションＩＤ６２Ｆに相当する。更に、Activate  Sessionリクエスト６３は、セッションの認証タイプ６３Ｅ、権限レベル６３Ｆ、文字列６３Ｇ及びシーケンス番号６３Ｈ等を含む。尚、文字列６３Ｇは、Get  Session  Challengeレスポンス６２のチャレンジデータ６２Ｇで得た文字列に相当する。尚、認証タイプ６３Ａ、セッションシーケンス番号６３Ｂ、セッションＩＤ６３Ｃ及び、指定アルゴリズムで算出したＩＤ６３ＤはＢｙｔｅ“０”に格納する。セッションの認証タイプ６３ＥはＢｙｔｅ“１”に格納する。権限レベル６３ＦはＢｙｔｅ“２”に格納する。文字列６３ＧはＢｙｔｅ“３”〜“１８”に格納する。シーケンス番号６３ＨはＢｙｔｅ“１９”〜“２２”に格納する。【００６２】
図６に示すActivate  Sessionレスポンス６４は、セッションＩＤ６４Ａ、認証タイプ６４Ｂ、シーケンス番号６４Ｃ、指定アルゴリズムで算出したＩＤ６４Ｄ及び、セッションオープン完了を示す完了コード６４Ｅを含む。尚、セッションＩＤ６４Ａは、Activate  Sessionリクエストで要求したセッションＩＤに相当する。更に、Activate  Sessionレスポンス６４は、セッションオープン後の認証タイプ６４Ｆ、セッションＩＤ６４Ｇ、シーケンス番号６４Ｈ及び権限レベル６４Ｉ等を含む。尚、認証タイプ６４Ａ、認証タイプ６４Ｂ、シーケンス番号６４Ｃ及び指定アルゴリズムで算出したＩＤ６４ＤはＢｙｔｅ“０”に格納する。完了コード６４ＥはＢｙｔｅ“１”に格納する。セッションオープン後の認証タイプ６４ＦはＢｙｔｅ“２”に格納する。セッションＩＤ６４ＧはＢｙｔｅ“３”〜“６”に格納する。シーケンス番号６４ＨはＢｙｔｅ“７”〜“１０”に格納する。権限レベル６４ＩはＢｙｔｅ“１１”に格納する。【００６３】
図７に示すClose  Sessionコマンド６５は、セッションクローズ対象のセッションＩＤ６５Ａを含む。尚、セッションクローズ対象のセッションＩＤ６５ＡはＢｙｔｅ“１”〜“４”に格納する。図８に示すClose  Sessionレスポンス６６は、セッションクローズ完了を示す完了コード６６Ａを含む。尚、完了コード６６ＡはＢｙｔｅ“１”に格納する。【００６４】
次に実施例２のサーバ管理システム１Ａの動作について説明する。図９は、Get  Session  Challengeリクエスト受信処理に関わるセッション管理部４４の処理動作を示すフローチャートである。図９に示すGet  Session  Challengeリクエスト受信処理は、クライアント端末２０から受信したGet  Session  Challengeリクエストに応じてセッションオープン前の事前処理を実行する処理である。図９においてセッション管理部４４の情報判定部５１は、スロット記憶部５２内のスロットを順次参照し(ステップＳ１１)、参照スロットに登録済みのActiveフラグ５２Ｃが“ＯＮ”であるか否かを判定する(ステップＳ１２)。情報判定部５１は、参照したスロットのActiveフラグ５２Ｃが“ＯＮ”でない場合(ステップＳ１２否定)、すなわちActiveフラグ５２Ｃが“ＯＦＦ”の場合、参照スロットに登録済みのEstablishmentフラグ５２Ｄが“ＯＮ”であるか否かを判定する(ステップＳ１３)。【００６５】
割当制御部５３は、参照スロットに登録済みのEstablishmentフラグ５２Ｃが“ＯＮ”でない場合(ステップＳ１３否定)、すなわちEstablishmentフラグ５２Ｃが“ＯＦＦ”である場合、参照スロットを空きスロットとして利用する(ステップＳ１４)。セッション管理部４４の情報登録部５４は、当該空きスロットに新たなセッションＩＤ５２Ｂを登録し(ステップＳ１５)、更に、当該スロット内に当該クライアント端末２０を識別するＩＰアドレス５２Ｅを登録する(ステップＳ１６)。更に、情報登録部５４は、当該スロット内の“ＯＦＦ”のEstablishmentフラグ５２Ｄに“ＯＮ”を登録し(ステップＳ１７)、図９の処理動作を終了する。【００６６】
端末判定部５３Ａは、参照スロット内のEstablishmentフラグ５２Ｄが“ＯＮ”である場合(ステップＳ１３肯定)、クライアント端末２０のＩＰアドレスと参照スロットに登録済みのＩＰアドレスとが同一であるか否かを判定する(ステップＳ１８)。割当制御部５３は、ＩＰアドレスが同一である場合(ステップＳ１８肯定)、Activate  Session未完のまま、再度、Get  Session  Challengeリクエストを発行したクライアント端末２０であると判断する。更に、割当制御部５３は、Activate  Session未完のまま、再度、Get  Session  Challengeリクエストを発行したクライアント端末２０であると判断すると、当該クライアント端末２０に当該参照スロットを再利用し(ステップＳ１９)、図９の処理動作を終了する。尚、Activate  Session未完のまま、再度、Get  Session  Challengeリクエストを発行したクライアント端末２０に対して複数の参照スロットが割り当てられるような事態が回避できる。【００６７】
また、割当制御部５３は、ＩＰアドレスが同一でない場合(ステップＳ１８否定)、参照スロットが他のクライアント端末２０で使用中と判断し(ステップＳ２０)、未参照スロットがスロット記憶部５２内にあるか否かを判定する(ステップＳ２１)。割当制御部５３は、未参照スロットがある場合(ステップＳ２１肯定)、当該未参照スロットを参照すべく、ステップＳ１１に移行する。また、割当制御部５３は、未参照スロットがない場合(ステップＳ２１否定)、セッション確立可能な上限数を超えたセッション数オーバのエラーメッセージをクライアント端末２０に通知し(ステップＳ２２)、図９の処理動作を終了する。【００６８】
割当制御部５３は、参照スロットに登録済みのActiveフラグ５２Ｃが“ＯＮ”である場合(ステップＳ１２肯定)、参照スロットが他のクライアント端末２０で使用中と判断する(ステップＳ２３)。続いて、割当制御部５３は、未参照スロットがスロット記憶部５２内にあるか否かを判定する(ステップＳ２４)。割当制御部５３は、未参照スロットがある場合(ステップＳ２４肯定)、未参照スロットを参照すべく、ステップＳ１１に移行する。また、割当制御部５３は、未参照スロットがない場合(ステップＳ２４否定)、セッション数オーバのエラーメッセージをクライアント端末２０に通知し(ステップＳ２５)、図９の処理動作を終了する。【００６９】
図９に示すGet  Session  Challengeリクエスト受信処理では、セッション管理部４４がGet  Session  Challengeリクエストを受信すると、Activeフラグ５２Ｃが“ＯＦＦ”、Establishmentフラグ５２Ｄが“ＯＦＦ”に登録済みのスロットを、Get  Session  Challengeリクエストを発行したクライアント端末２０に割り当てる。更に、Get  Session  Challenge受信処理では、クライアント端末２０に割り当てたスロットにセッションＩＤ５２Ｂ及びＩＰアドレス５２Ｅを登録すると共に、当該スロットのActiveフラグ５２Ｃに“ＯＮ”を登録する。【００７０】
例えば、Activeフラグ５２Ｃが“ＯＦＦ”、Establishmentフラグ５２Ｄが“ＯＦＦ”に登録済みのスロットの場合、割当制御部５３は、当該スロットをGet  Session  Challengeリクエストを発行したクライアント端末２０に割り当てる。これに対して、Activeフラグ５２Ｃが“ＯＮ”に登録済みのスロットの場合、割当制御部５３は、Get  Session  Challengeリクエストを発行したクライアント端末２０に対する当該スロットの割当を禁止する。つまり、サーバ装置３は、スロット毎のActiveフラグ５２Ｃ及びEstablishmentフラグ５２Ｄの参照結果に基づき、Get  Session  Challengeリクエストを発行したクライアント端末２０に対するスロットの割当を制御した。その結果、サーバ装置３は、Get  Session  Challengeリクエストが競合した複数のクライアント端末２０に対して同一スロットの重複割当を回避できる。【００７１】
更に、セッション管理部４４がGet  Session  Challengeリクエストを受信したとき、スロットのActiveフラグ５２Ｃが“ＯＦＦ”、Establishmentフラグ５２Ｄが“ＯＮ”の場合には、当該スロットに登録済みのＩＰアドレスとリクエストを発行したクライアント端末２０のＩＰアドレスが同一であるか否かを判定する。同一ＩＰアドレスの場合、Get  Session  Challengeリクエストを発行したクライアント端末２０に当該スロットを割り当てる。つまり、サーバ装置３は、同一クライアント端末２０からActivate  Session未完のまま、再度、Get  Session  Challengeリクエストを受信したとしても、当該クライアント端末２０に割当済みのスロットを再利用することになる。その結果、サーバ装置３は、同一クライアント端末２０に対して複数のスロットを順次割り当ててしまうような事態を回避できる。【００７２】
更に、サーバ装置３は、スロットに登録済みのＩＰアドレスとGet  Session  Challengeリクエストを発行したクライアント端末２０のＩＰアドレスとが同一ではない場合、当該リクエストを発行したクライアント端末２０に別のスロットを割り当てる。その結果、サーバ装置３は、Get  Session  Challengeリクエストが競合した複数のクライアント端末２０に対して同一スロットが割り当てられてしまうような事態を回避できる。【００７３】
図１０は、Activate  Sessionリクエスト受信処理に関わるセッション管理部４４の処理動作を示すフローチャートである。図１０に示すActivate  Sessionリクエスト受信処理は、クライアント端末２０からのActivate  Sessionリクエストに応じてセッションをオープン状態にする処理である。図１０において制御部５５は、スロット記憶部５２からスロットを参照し(ステップＳ３１)、参照スロットに登録済みのActiveフラグ５２Ｃ  が“ＯＦＦ”であるか否かを判定する(ステップＳ３２)。【００７４】
制御部５５は、Activeフラグ５２Ｃ  が“ＯＦＦ”である場合(ステップＳ３２肯定)、参照スロットに登録済みのセッションＩＤ５２ＢがActivate  Sessionリクエストに付加されたセッションＩＤと同一であるか否かを判定する(ステップＳ３３)。【００７５】
情報登録部５４は、セッションＩＤが同一の場合(ステップＳ３３肯定)、参照スロットに登録済みのActiveフラグ５２Ｃに“ＯＮ”を登録する（ステップＳ３４)。更に、情報登録部５４は、参照スロットに登録済みのEstablishmentフラグ５２Ｄを“ＯＦＦ”登録し(ステップＳ３５)、図１０の処理動作を終了する。その結果、制御部５５は、Activate  Sessionリクエストを発行したクライアント端末２０とのセッションをオープン状態にする。【００７６】
更に、制御部５５は、参照スロットに登録済みのセッションＩＤ５２ＢがActivate  Sessionリクエストに付加されたセッションＩＤと同一でない場合(ステップＳ３３否定)、参照スロットがActivate  Sessionリクエストを発行したクライアント端末２０に割り当てるべき該当スロットではないと判断する  (ステップＳ３６)。そして、制御部５５は、参照スロットが該当スロットではないと判断すると、未参照スロットがスロット記憶部５２内にあるか否かを判定する(ステップＳ３７)。制御部５５は、未参照スロットがある場合(ステップＳ３７肯定)、未参照スロットを参照すべく、ステップＳ３１に移行する。【００７７】
また、制御部５５は、未参照スロットがない場合(ステップＳ３７否定)、Activate  Sessionリクエストに関わるセッションＩＤエラーをクライアント端末２０に通知し(ステップＳ３８)、図１０の処理動作を終了する。また、制御部５５は、Activeフラグ５２Ｃが“ＯＦＦ”でない場合（ステップＳ３２否定）、ステップＳ３６に移行する。【００７８】
図１０に示すActivate  Sessionリクエスト受信処理では、セッション管理部４４がActivate  Sessionリクエストを受信すると、当該リクエストのセッションＩＤと参照スロットに登録済みのセッションＩＤ５２Ｂとが同一であるか否かを判定する。セッションＩＤが同一の場合、当該セッションを使用したクライアント端末２０とのセッションをオープン状態にする。また、Activate  Sessionリクエスト受信処理では、セッションＩＤが同一でない場合、当該セッションを使用したクライアント端末２０とのセッションをオープンにしない。その結果、サーバ装置３は、Get  Session  Challengeリクエストが競合した複数のクライアント端末２０に対して同一スロットが割り当てられるような事態を回避することで、クライアント端末２０がGet  Session  Challengeリクエストを先に要求したにも関わらず、後で要求した他のクライアント端末２０によってセッションが横取りされてしまうような事態を回避できる。そして、サーバ管理システム１Ａは、円滑なセッションのオープンを実現できる。【００７９】
図１１は、Close  Sessionコマンド受信処理に関わるセッション管理部４４の処理動作を示すフローチャートである。図１１に示すClose  Sessionコマンド受信処理は、クライアント端末２０からのClose  Sessionコマンドに応じてクライアント端末２０とのセッションをクローズ状態にする処理である。図１１において制御部５５は、Close  Sessionコマンドを受信すると、スロット記憶部５２からスロットを参照し(ステップＳ４１)、参照スロットに登録済みのActiveフラグ５２Ｃが“ＯＮ”であるか否かを判定する(ステップＳ４２)。制御部５５は、参照スロットのActiveフラグ５２Ｃが“ＯＮ”である場合(ステップＳ４２肯定)、参照スロットに登録済みのセッションＩＤ５２ＢがClose  Sessionコマンドに付加されたセッションＩＤと同一であるか否かを判定する(ステップＳ４３)。【００８０】
情報登録部５４は、セッションＩＤが同一の場合(ステップＳ４３肯定)、参照スロットに登録済みのセッションＩＤ５２Ｂをゼロクリアする(ステップＳ４４)。更に、情報登録部５４は、参照スロットに登録済みのＩＰアドレス５２Ｅをゼロクリアする(ステップＳ４５)。更に、情報登録部５４は、参照スロットのActiveフラグ５２Ｃを“ＯＦＦ”登録し（ステップＳ４６)、図１１の処理動作を終了する。その結果、制御部５５は、Close  Sessionコマンドを発行したクライアント端末２０とのセッションをクローズ状態にする。【００８１】
また、制御部５５は、参照スロットのActiveフラグ５２Ｃが“ＯＮ”でない場合(ステップＳ４２否定)  、参照スロットがClose  Sessionコマンドを発行したクライアント端末２０に割り当てるべき該当スロットではないと判断する(ステップＳ４７)。そして、制御部５５は、未参照スロットがスロット記憶部５２内にあるか否かを判定する(ステップＳ４８)。制御部５５は、未参照スロットがない場合(ステップＳ４８否定)、Close  Sessionコマンドに関わるセッションＩＤエラーをクライアント端末２０に通知し(ステップＳ４９)、図１１の処理動作を終了する。【００８２】
また、制御部５５は、未参照スロットがある場合(ステップＳ４８肯定)、未参照スロットを参照すべく、ステップＳ４１に移行する。また、制御部５５は、参照スロットに登録済みのセッションＩＤ５２ＢがClose  Sessionコマンドに付加されたセッションＩＤと同一でない場合(ステップＳ４３否定)、参照スロットが該当スロットではないと判断すべく、ステップＳ４７に移行する。【００８３】
図１１に示すClose  Sessionコマンド受信処理では、Close  Sessionコマンドに応じて、当該コマンドを発行したクライアント端末２０とのセッションをクローズ状態にする。【００８４】
図１２は、セッションオープン競合時に関わるサーバ管理システム１Ａの処理動作を示すシーケンス図である。尚、説明の便宜上、クライアント端末２０Ａ及び２０ＢからのGet  Session  Challengeリクエストが競合した状態を想定する。クライアント端末２０Ａは、Get  Session  Challengeリクエストを発行し、そのGet  Session  ChallengeリクエストをＬＡＮ４経由でコマンド処理部４２に通知する(ステップＳ５１)。コマンド処理部４２は、クライアント端末２０ＡからGet  Session  Challengeリクエストを受信すると、使用するセッションの新規セッションＩＤの生成をセッション管理部４４に依頼する(ステップＳ５２)。【００８５】
セッション管理部４４は、新規セッションＩＤの生成依頼を受信すると、新規セッションＩＤを生成する(ステップＳ５３)。更に、セッション管理部４４は、Activeフラグ５２Ｃが“ＯＦＦ”及びEstablishmentフラグ５２Ｄが“ＯＦＦ”の空きスロット“１”を、Get  Session  Challengeリクエストを発行したクライアント端末２０Ａに割り当てる。更に、情報登録部５４は、空きスロット“１”に、Get  Session  Challengeリクエストを発行したクライアント端末２０ＡのＩＰアドレス５２Ｅ“ｘｘＡ”及び新規セッションＩＤ５２Ｂ“１”を登録する（ステップＳ５４）。更に、情報登録部５４は、当該空きスロット“１”のEstablishmentフラグ５２Ｄに“ＯＮ”を登録する(ステップＳ５４)。つまり、情報登録部５４は、ＩＰアドレス５２Ｅ“ｘｘＡ”、新規セッションＩＤ５２Ｂ“１”及び  Establishmentフラグ５２Ｄ“ＯＮ”を空きスロット“１”に登録する。その結果、当該スロット“１”は、クライアント端末２０Ａが利用するセッションＩＤ“１”対応のスロットとなる。【００８６】
セッション管理部４４は、スロット“１”に登録した新規セッションＩＤ“１”を読み出す（ステップＳ５４Ａ）。そして、セッション管理部４４は、Get  Session  Challengeリクエストに対するGet  Session  Challengeレスポンスをクライアント端末２０Ａに返信する(ステップＳ５５)。尚、図１２の例では、Get  Session  Challengeレスポンスには、ステップＳ５４で登録した新規セッションＩＤ“１”を付加する。【００８７】
次に、クライアント端末２０ＡがGet  Session  Challengeリクエストに後続するActivate  Sessionリクエストを発行する前に、クライアント端末２０Ｂは、Get  Session  Challengeリクエストを発行し、そのGet  Session  ChallengeリクエストをＬＡＮ４経由でコマンド処理部４２に通知する(ステップＳ５６)。コマンド処理部４２は、クライアント端末２０ＢからGet  Session  Challengeリクエストを受信すると、使用するセッションの新規セッションＩＤの生成をセッション管理部４４に依頼する(ステップＳ５７)。【００８８】
セッション管理部４４は、新規セッションＩＤの生成依頼を受信すると、新規セッションＩＤを生成する(ステップＳ５８)。更に、割当制御部５３は、クライアント端末２０Ａに先に割り当てたスロット“１”に登録済みのEstablishmentフラグ５２Ｄが“ＯＮ”のため、Get  Session  Challengeリクエストを発行したクライアント端末２０Ｂに対して空きスロット“１”の割当を禁止する。その結果、割当制御部５３は、Activeフラグ５２Ｃが“ＯＦＦ”及びEstablishmentフラグ５２Ｄが“ＯＦＦ”の空きスロット“２”を、Get  Session  Challengeリクエストを発行したクライアント端末２０Ｂに割り当てる。情報登録部５４は、空きスロット“２”にGet  Session  Challengeリクエストを発行したクライアント端末２０ＢのＩＰアドレス５２Ｅ“ｘｘＢ”及び新規セッションＩＤ５２Ｂ“２”を登録する（ステップＳ５９）。更に、情報登録部５４は、空きスロット“２”のEstablishmentフラグ５２Ｄに“ＯＮ”を登録する(ステップＳ５９)。つまり、情報登録部５４は、ＩＰアドレス５２Ｅ“ｘｘＢ”、新規セッションＩＤ５２Ｂ“２”及び  Establishmentフラグ５２Ｄ“ＯＮ”を空きスロット“２”に登録する。その結果、当該スロット“２”は、クライアント端末２０Ｂが利用するセッションＩＤ“２”対応のスロットとなる。【００８９】
セッション管理部４４は、スロット“２”に登録した新規セッションＩＤ“２”を読み出す（ステップＳ５９Ａ）。そして、セッション管理部４４は、Get  Session  Challengeリクエストに対するGet  Session  Challengeレスポンスをクライアント端末２０Ｂに返信する(ステップＳ６０)。尚、図１２の例では、Get  Session  Challengeレスポンスには、ステップＳ５９で登録した新規セッションＩＤ“２”を付加する。この結果、クライアント端末２０Ａ及び２０ＢによってGet  Session  Challengeリクエストが競合した状態となる。【００９０】
この際、クライアント端末２０Ｂは、クライアント端末２０Ａよりも先にActivate  Sessionリクエストを発行し、Activate  Sessionリクエストをコマンド処理部４２経由でセッション管理部４４に通知したものとする(ステップＳ６１)。尚、クライアント端末２０Ｂは、Activate  Sessionリクエストを発行する際、Get  Session  Challengeレスポンスに付加されたセッションＩＤ“２”をActivate  Sessionリクエストに付加する。【００９１】
情報登録部５４は、クライアント端末２０ＢからActivate  Sessionリクエストを受信すると、当該リクエストに付加されたセッションＩＤ“２”が登録済みのスロット“２”を参照する（ステップＳ６２）。更に、情報登録部５４は、参照スロット“２”のActiveフラグ５２Ｃに“ＯＮ”を登録すると共に、Establishmentフラグ５２Ｄに“ＯＦＦ”を登録する(ステップＳ６２)。【００９２】
当該スロット“２”には、セッションＩＤ５２Ｂ“２”と、Activeフラグ５２Ｃ“ＯＮ”と、Establishmentフラグ５２Ｄ“ＯＦＦ”と、クライアント端末２０ＢのＩＰアドレス５２Ｅ“ｘｘＢ”とを対応付けて登録する(ステップＳ６２)。そして、制御部５５は、当該スロット“２”の登録完了に応じて(ステップＳ６２Ａ)、Activate  Sessionリクエストに対するActivate  Sessionレスポンスをコマンド処理部４２経由でクライアント端末２０Ｂに返信する(ステップＳ６３)。この結果、制御部５５は、クライアント端末２０Ｂに対するセッションＩＤ“２”のセッションをオープン状態とする。【００９３】
そして、クライアント端末２０ＢがActivate  Sessionが完了してオープン状態にした後、クライアント端末２０Ａは、Activate  Sessionリクエストを発行し、Activate  Sessionリクエストをコマンド処理部４２経由でセッション管理部４４に通知する(ステップＳ６４)。尚、クライアント端末２０Ａでは、Activate  Sessionリクエストを発行する際、Get  Session  Challengeレスポンスに付加されたセッションＩＤ“１”をActivate  Sessionリクエストに付加する。【００９４】
情報登録部５４は、Activate  Sessionリクエストをクライアント端末２０Ａから受信すると、当該リクエストに付加されたセッションＩＤ“１”が登録済みのスロット“１”を参照する。情報登録部５４は、参照スロット“１”のActiveフラグ５２Ｃに“ＯＮ”を登録すると共に、Establishmentフラグ５２Ｄに“ＯＦＦ”を登録する(ステップＳ６５)。【００９５】
当該スロット“１”には、セッションＩＤ５２Ｂ“１”と、Activeフラグ５２Ｃ“ＯＮ”と、Establishmentフラグ５２Ｄ“ＯＦＦ”と、クライアント端末２０ＡのＩＰアドレス５２Ｅ“ｘｘＡ”とを対応付けて登録する(ステップＳ６５)。そして、制御部５５は、当該スロット“１”の登録完了に応じて(ステップＳ６５Ａ)、Activate  Sessionリクエストに対するActivate  Sessionレスポンスをコマンド処理部４２経由でクライアント端末２０Ａに返信する(ステップＳ６６)。この結果、制御部５５は、クライアント端末２０Ａに対するセッションＩＤ“１”のセッションをオープン状態とする。【００９６】
図１２では、クライアント端末２０からGet  Session  Challengeリクエストが発行された場合、各スロットのセッションＩＤ５２Ｂ、Activeフラグ５２Ｃ、Establishmentフラグ５２Ｄ及びＩＰアドレス５２Ｅを参照する。そのため、複数のクライアント端末２０のGet  Session  Challengeリクエストが競合したとしても、サーバ装置３は、複数のクライアント端末２０に対して同一スロットが割り当てられるような事態を回避する。更に、クライアント端末２０がGet  Session  Challengeリクエストを先に要求したにも関わらず、後で要求した他のクライアント端末２０によってセッションが横取りされてしまうような事態が回避できる。そして、サーバ管理システム１は、円滑なセッションオープンを実現できる。【００９７】
また、例えば、クライアント端末２０Ａは、Get  Session  Challengeリクエストを発行し、ステップＳ５１〜ステップＳ５５の処理動作を経て、Activate  Sessionリクエストを発行する。しかしながら、クライアント端末２０Ａは、Get  Session  Challengeリクエストを発行したにもかかわらず、Activate  Sessionリクエストを発行せず、何等かの原因でGet  Session  Challengeリクエストを再度発行したとする。このような場合でも、割当制御部５３は、Activeフラグ５２Ｃが“ＯＦＦ”、Establishmentフラグ５２Ｄが“ＯＮ”及びＩＰアドレス５２Ｅが同一のスロットをクライアント端末２０Ａに割り当てることで当該スロットを再利用することになる。その結果、サーバ装置３は、Get  Session  Challengeリクエストを受信する都度、同一クライアント端末２０に対して異なるスロットを順次割り当てしまうような事態を回避することで、従来のようなセッション数オーバを防止できる。【００９８】
実施例２では、クライアント端末２０からGet  Session  Challengeリクエストを受信すると、スロットを順次参照し、参照スロットに登録済みのActiveフラグ５２Ｃが“ＯＦＦ”であるか否かを判定する。更に、実施例２では、Activeフラグ５２Ｃが“ＯＦＦ”の場合、参照スロットに登録済みのEstablishmentフラグ５２Ｄが“ＯＦＦ”であるか否かを判定する。更に、実施例２では、Establishmentフラグ５２Ｄが“ＯＦＦ”の場合、Get  Session  Challengeリクエストを発行したクライアント端末２０に対して当該参照スロットを割り当てる。更に、実施例２では、クライアント端末２０に割り当てられたスロットに、そのセッションのセッションＩＤ５２Ｂ及びＩＰアドレス５２Ｅを登録し、Establishmentフラグ５２Ｄに“ＯＮ”を登録する。つまり、実施例２では、スロット毎のActiveフラグ５２Ｃ及びEstablishmentフラグ５２Ｄの参照結果に基づき、Get  Session  Challengeリクエストを発行したクライアント端末２０に対するスロットの割当を制御した。その結果、サーバ装置３は、Get  Session  Challengeリクエストが競合した複数のクライアント端末２０に対する同一スロットの重複割当を回避できる。【００９９】
更に、実施例２では、クライアント端末２０からActivate  Sessionリクエストを受信すると、スロットを順次参照し、参照スロットに登録済みのセッションＩＤ５２Ｂと当該リクエストに含まれるセッションＩＤとが同一であるか否かを判定する。実施例２では、セッションＩＤが同一の場合、参照スロットに登録済みのセッションＩＤ５２ＢのセッションＩＤを使用してActivate  Sessionリクエストを発行したクライアント端末２０とのセッションをオープン状態にする。その結果、サーバ装置３は、Get  Session  Challengeリクエストが競合した複数のクライアント端末２０に対する同一スロットの重複割当を回避することで、クライアント端末２０がGet  Session  Challengeリクエストを先に要求したにも関わらず、後で要求した他のクライアント端末２０によってセッションが横取りされてしまうような事態を回避できる。そして、円滑なセッションオープンを実現できる。【０１００】
実施例２では、参照スロットに登録済みのEstablishmentフラグ５２Ｄが“ＯＮ”の場合、参照スロットに登録済みのＩＰアドレスがGet  Session  Challengeリクエストを発行したクライアント端末２０のＩＰアドレスと同一であるか否かを判定する。実施例２では、ＩＰアドレスが同一の場合、当該リクエストを発行したクライアント端末２０に対して当該スロットを割り当てる。つまり、サーバ装置３は、同一クライアント端末２０からActivate  Session未完のまま、再度、Get  Session  Challengeリクエストを受信したとしても、当該クライアント端末２０に割当済みのスロットを再利用することになる。その結果、サーバ装置３は、同一クライアント端末２０に対して複数のスロットを順次割り当ててしまうような事態を回避できる。【０１０１】
更に、実施例２では、スロットに登録済みのＩＰアドレスがGet  Session  Challengeリクエストを発行したクライアント端末２０のＩＰアドレスとが同一ではない場合、当該リクエストを発行したクライアント端末２０に別のスロットを割り当てる。その結果、サーバ装置３は、Get  Session  Challengeリクエストが競合した複数のクライアント端末２０に対して同一スロットが割り当てられてしまうような事態を回避できる。【０１０２】
実施例２では、Activate  Sessionリクエストを受信すると、スロットを順次参照し、参照スロットに登録済みのセッションＩＤ５２Ｂがリクエストに付加されたセッションＩＤと同一であるか否かを判定する。実施例２では、セッションＩＤが同一の場合、当該セッションを使用したクライアント端末２０とのセッションをオープン状態にする。【０１０３】
実施例２では、クライアント端末２０からClose  Sessionコマンドを受信すると、スロットを順次参照し、参照スロットに登録済みのセッションＩＤがClose  Sessionコマンドに付加したセッションＩＤと同一であるか否かを判定する。実施例２では、同一セッションＩＤの場合、当該クライアント端末２０と当該セッションＩＤのセッションをクローズ状態にする。【０１０４】
尚、上記実施例２では、Ｖ１．５のＩＰＭＩ仕様のセッションを例に挙げて説明したが、Ｖ２．０のＩＰＭＩ仕様のセッションに採用しても良い。図１３は、Ｖ２．０のＩＰＭＩのセッションシーケンスの一例を示す説明図である。図１３に示すＶ２．０仕様のRMCP＋Open  Sessionは、セッション開始要求としてＶ１．５仕様のGet  Session  Challengeに相当する。更に、Ｖ２．０仕様のRAKP  Message１、RAKP  Message２、RAKP  Message３及びRAKP  Message４は、セッション実行要求としてＶ１．５のActivate  Sessionに相当する。セッション管理部４４の割当制御部５３は、クライアント端末２０からRMCP＋Open  Sessionリクエストを受信した場合、Activeフラグ“ＯＦＦ”及びEstablishmentフラグ“ＯＦＦ”の空きスロットを割り当てる。更に、情報登録部５４は、スロットに新規セッションＩＤ及びＩＰアドレスを登録すると共に、Establishmentフラグ５２Ｄに“ＯＮ”を登録する。この結果、他のクライアント端末２０からRMCP＋Open  Sessionリクエストを受信したとしても、割当制御部５３は、複数のクライアント端末２０に対してEstablishmentフラグ５２Ｄが“ＯＦＦ”登録済みのスロットを割り当てる。更に、割当制御部５３は、複数のクライアント端末２０に対してEstablishmentフラグ５２Ｄが“ＯＮ”登録済みのスロットの重複割当を回避できる。【０１０５】
また、上記実施例２では、Get  Session  Challenge及びActivate  Sessionの二段構えのＩＰＭＩコマンドを実行してセッションを確立する場合を例に挙げて説明した。しかしながら、ＩＰＭＩに限定することなく、二段構えのコマンドを実行してセッションを確立するシステムであれば、同様の効果が得られる。【０１０６】
また、図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。【０１０７】
更に、各装置で行われる各種処理機能は、ＣＰＵ（Central  Processing  Unit）（又はＭＰＵ（Micro  Processing  Unit）、ＭＣＵ（Micro  Controller  Unit）等のマイクロ・コンピュータ）上で、その全部又は任意の一部を実行するようにしても良い。また、各種処理機能は、ＣＰＵ（又はＭＰＵ、ＭＣＵ等のマイクロ・コンピュータ）で解析実行するプログラム上、又はワイヤードロジックによるハードウェア上で、その全部又は任意の一部を実行するようにしても良いことは言うまでもない。【０１０８】
ところで、本実施例で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図１４を用いて、上記の実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図１４は、セッション確立プログラムを実行するコンピュータを示す説明図である。【０１０９】
図１４に示すように、セッション確立プログラムとしてのコンピュータ２００は、ＨＤＤ（Hard  Disk  Drive）２１０、ＲＡＭ(Random  Access  Memory)２２０、ＲＯＭ（Read  Only  Memory）２３０及びＣＰＵ２４０をバス２５０で接続して構成される。【０１１０】
そして、ＲＯＭ２３０には、上記の実施例と同様の機能を発揮するセッション確立プログラムが予め記憶されている。セッション確立プログラムとしては、図１４に示すように、情報判定プログラム２３１、記憶プログラム２３２、割当制御プログラム２３３、情報登録プログラム２３４及び制御プログラム２３５である。尚、プログラム２３１〜２３５については、図１に示したセッション確立装置１の各構成要素と同様、適宜統合又は分散してもよい。【０１１１】
そして、ＣＰＵ２４０が、これらのプログラム２３１〜２３５をＲＯＭ２３０から読み出して実行する。そして、図１４に示すように、各プログラム２３１〜２３５は、情報判定プロセス２４１、記憶プロセス２４２、割当制御プロセス２４３、情報登録プロセス２４４及び制御プロセス２４５として機能するようになる。【０１１２】
ＣＰＵ２４０は、端末装置からセッション開始要求を受信すると、確立済み情報が確立済みではないことを示すセッションがあるか否かを判定する。更に、ＣＰＵ２４０は、確立済みではないセッションがある場合、当該セッションに対応した確立中情報が確立処理中でない旨を示しているか否かを判定する。更に、ＣＰＵ２４０は、確立処理中でないセッションに対応付けて、セッション識別情報及び端末識別情報を登録し、当該セッションの確立中情報を確立処理中である旨に登録する。つまり、コンピュータ２００は、セッション毎の確立済み情報及び確立中情報の参照結果に基づき、セッション開始要求を発行した端末装置に対するセッションの割当を制御する。その結果、コンピュータ２００は、セッション開始要求が競合したとしても、登録済みの確立中情報、確立済み情報、セッション識別情報及び端末識別情報を参照して、同一セッションが複数の端末装置に重複割当されてしまうような事態を回避できる。【０１１３】
更に、ＣＰＵ２４０は、端末装置からセッション実行要求を受信すると、セッション実行要求に含まれるセッション識別情報と同一のセッション識別情報のセッションがあるか否かを判定する。更に、ＣＰＵ２４０は、同一セッション識別情報を持つセッションがある場合、当該セッション識別情報を使用して当該セッション実行要求を発行した端末装置とのセッションを確立する。その結果、コンピュータ２００は、セッション開始要求が競合した複数の端末装置に対する同一セッションの重複割当を回避することで、端末装置がセッション開始要求を先に要求したにも関わらず、後で要求した他の端末装置によってセッションが横取りされてしまうような事態を回避できる。そして、コンピュータ２００は、円滑なセッションの確立を実現できる。
【符号の説明】
【０１１４】
１  セッション確立装置
１Ａ  サーバ管理システム
２  端末装置
１１  情報判定部
１２  記憶部
１３  割当制御部
１４  情報登録部
１５  制御部
２０  クライアント端末
２０Ａ  クライアント端末
２０Ｂ  クライアント端末
５１  情報判定部
５２  スロット記憶部
５３  割当制御部
５３Ａ  端末判定部
５４  情報登録部
５５  制御部
【図１】
0005534014.tif 000002
【図２】
0005534014.tif 000003
【図３】
0005534014.tif 000004
【図４】
0005534014.tif 000005
【図５】
0005534014.tif 000006
【図６】
0005534014.tif 000007
【図７】
0005534014.tif 000008
【図８】
0005534014.tif 000009
【図９】
0005534014.tif 000010
【図１０】
0005534014.tif 000011
【図１１】
0005534014.tif 000012
【図１２】
0005534014.tif 000013
【図１３】
0005534014.tif 000014
【図１４】
0005534014.tif 000015
【図１５】
0005534014.tif 000016
【図１６】
0005534014.tif 000017