JP5534014B2 - セッション確立装置、セッション確立方法及びセッション確立プログラム - Google Patents

Description

本発明は、セッション確立装置、セッション確立方法及びセッション確立プログラムに関する。

近年、インテリジェントプラットフォーム管理インタフェース(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）２３０及びＣＰＵ２４０をバス２５０で接続して構成される。

そして、ＲＯＭ２３０には、上記の実施例と同様の機能を発揮するセッション確立プログラムが予め記憶されている。セッション確立プログラムとしては、図１４に示すように、情報判定プログラム２３１、記憶プログラム２３２、割当制御プログラム２３３、情報登録プログラム２３４及び制御プログラム２３５である。尚、プログラム２３１〜２３５については、図１に示したセッション確立装置１の各構成要素と同様、適宜統合又は分散してもよい。

そして、ＣＰＵ２４０が、これらのプログラム２３１〜２３５をＲＯＭ２３０から読み出して実行する。そして、図１４に示すように、各プログラム２３１〜２３５は、情報判定プロセス２４１、記憶プロセス２４２、割当制御プロセス２４３、情報登録プロセス２４４及び制御プロセス２４５として機能するようになる。

ＣＰＵ２４０は、端末装置からセッション開始要求を受信すると、確立済み情報が確立済みではないことを示すセッションがあるか否かを判定する。更に、ＣＰＵ２４０は、確立済みではないセッションがある場合、当該セッションに対応した確立中情報が確立処理中でない旨を示しているか否かを判定する。更に、ＣＰＵ２４０は、確立処理中でないセッションに対応付けて、セッション識別情報及び端末識別情報を登録し、当該セッションの確立中情報を確立処理中である旨に登録する。つまり、コンピュータ２００は、セッション毎の確立済み情報及び確立中情報の参照結果に基づき、セッション開始要求を発行した端末装置に対するセッションの割当を制御する。その結果、コンピュータ２００は、セッション開始要求が競合したとしても、登録済みの確立中情報、確立済み情報、セッション識別情報及び端末識別情報を参照して、同一セッションが複数の端末装置に重複割当されてしまうような事態を回避できる。

更に、ＣＰＵ２４０は、端末装置からセッション実行要求を受信すると、セッション実行要求に含まれるセッション識別情報と同一のセッション識別情報のセッションがあるか否かを判定する。更に、ＣＰＵ２４０は、同一セッション識別情報を持つセッションがある場合、当該セッション識別情報を使用して当該セッション実行要求を発行した端末装置とのセッションを確立する。その結果、コンピュータ２００は、セッション開始要求が競合した複数の端末装置に対する同一セッションの重複割当を回避することで、端末装置がセッション開始要求を先に要求したにも関わらず、後で要求した他の端末装置によってセッションが横取りされてしまうような事態を回避できる。そして、コンピュータ２００は、円滑なセッションの確立を実現できる。

１ セッション確立装置
１Ａ サーバ管理システム
２ 端末装置
１１ 情報判定部
１２ 記憶部
１３ 割当制御部
１４ 情報登録部
１５ 制御部
２０ クライアント端末
２０Ａ クライアント端末
２０Ｂ クライアント端末
５１ 情報判定部
５２ スロット記憶部
５３ 割当制御部
５３Ａ 端末判定部
５４ 情報登録部
５５ 制御部

Claims (10)

1. 端末装置が使用するセッション毎に、当該セッションが確立済みであるか否かを示す確立済み情報と、当該セッションを確立するための処理が継続中である、当該セッションが確立処理中であるか否かを示す確立中情報とを対応付けて記憶する記憶部と、
   前記端末装置からセッション開始要求を受信すると、確立済みでない旨を前記確立済み情報が示すセッションが前記記憶部内にあるか否かを判定し、確立済みではないセッションがある場合に、当該セッションに対応した確立中情報が確立処理中でない旨を示しているか否かを判定する情報判定部と、
   前記セッションに対応した確立中情報が前記確立処理中でない旨を示している場合、当該セッション開始要求を発行した端末装置に対して当該セッションを割り当てる割当制御部と、
   前記セッション開始要求を発行した端末装置に対して当該セッションを割り当てた場合、当該セッションに対応付けて、当該セッションを識別するセッション識別情報及び当該端末装置を識別する端末識別情報を登録すると共に、当該セッションに対応した確立中情報を確立処理中である旨に登録する情報登録部と、
   端末装置からセッション実行要求を受信すると、当該セッション実行要求に含まれるセッション識別情報と同一のセッション識別情報のセッションが前記記憶部内にあるか否かを判定し、同一セッション識別情報を持つセッションがある場合、当該セッション識別情報を使用して当該セッション実行要求を発行した端末装置とのセッションを確立する制御部と
   を有することを特徴とするセッション確立装置。
2. 前記割当制御部は、
   前記セッションに対応した確立中情報が前記確立処理中である旨を示す場合、当該セッションに対応した端末識別情報が前記セッション開始要求を発行した端末装置の端末識別情報と同一であるか否かを判定する端末判定部を有し、
   前記端末識別情報が同一の場合、当該セッション開始要求を発行した端末装置に対して当該セッションを割り当て、前記端末識別情報が同一でない場合、当該セッション開始要求を発行した端末装置に対する当該セッションの割り当てを禁止することを特徴とする請求項１記載のセッション確立装置。
3. 前記情報登録部は、
   前記制御部が、前記セッション実行要求に含まれるセッション識別情報と同一のセッション識別情報のセッションがあると判定した場合、当該セッションに対応した確立中情報を確立処理中でない旨に登録し、当該セッションに対応した確立済み情報を確立済みである旨に登録することを特徴とする請求項１又は２記載のセッション確立装置。
4. 前記制御部は、
   前記端末装置からセッション終了要求を受信すると、当該セッション終了要求に含まれるセッション識別情報に対応したセッションが前記記憶部内にあるか否かを判定し、当該セッションがある場合、当該セッションに関わる前記セッション終了要求を発行した端末装置とのセッションを切断し、
   前記情報登録部は、
   前記セッション終了要求に含まれるセッション識別情報に対応したセッションが前記記憶部内にある場合、当該セッションに対応した端末識別情報及びセッション識別情報を消去し、当該セッションに対応した確立済み情報を確立済みでない旨に登録することを特徴とする請求項１又は２記載のセッション確立装置。
5. 前記セッション開始要求及び前記セッション実行要求は、
   インテリジェントプラットフォーム管理インタフェースの仕様に準拠した、前記端末装置とのセッション確立を要求するコマンドであることを特徴とする請求項１又は２記載のセッション確立装置。
6. 前記記憶部は、
   前記端末装置が対向装置内の各内部装置の状態監視に使用するセッション毎に、前記確立済み情報と、前記確立中情報とを対応付けて記憶することを特徴とする請求項１〜５の何れか一つに記載のセッション確立装置。
7. 端末装置からセッション開始要求を受信すると、記憶部に記憶されている、セッションが確立済みであるか否かを示す確立済み情報を参照して、前記確立済み情報が確立済みではないことを示すセッションが前記記憶部内にあるか否かを判定し、
   確立済みではないことを示すセッションが前記記憶部にある場合に、前記記憶部に記憶されている、当該セッションを確立するための処理が継続中である、当該セッションが確立処理中であるか否かを示す確立中情報を参照して、当該セッションが確立処理中であるか否かを判定し、
   当該セッションに対応した前記確立中情報が前記確立処理中でない旨を示している場合、当該セッション開始要求を発行した端末装置に対して当該セッションを割り当て、
   前記セッション開始要求を発行した端末装置に対して当該セッションを割り当てた場合、当該セッションを識別するセッション識別情報及び当該端末装置を識別する端末識別情報を当該セッションに対応付けて登録すると共に、当該セッションに対応した確立中情報を確立処理中である旨に登録し、
   端末装置からセッション実行要求を受信すると、当該セッション実行要求に含まれるセッション識別情報と同一のセッション識別情報のセッションが前記記憶部内にあるか否かを判定し、同一セッション識別情報を持つセッションが前記記憶部内にある場合、当該セッション識別情報を使用して当該セッション実行要求を発行した端末装置とのセッションを確立することを特徴とするセッション確立方法。
8. 前記記憶部は、
   前記端末装置が対向装置内の各内部装置の状態監視に使用するセッション毎に、前記確立済み情報と、前記確立中情報とを対応付けて記憶することを特徴とする請求項７記載のセッション確立方法。
9. 端末装置が使用するセッション毎に、当該セッションが確立済みであるか否かを示す確立済み情報と、当該セッションを確立するための処理が継続中である、当該セッションが確立処理中であるか否かを示す確立中情報とを対応付けて記憶部に記憶する記憶手順と、
   前記端末装置からセッション開始要求を受信すると、確立済みでない旨を前記確立済み情報が示すセッションが前記記憶部内にあるか否かを判定し、確立済みではないセッションがある場合に、当該セッションに対応した確立中情報が確立処理中でない旨を示しているか否かを判定する情報判定手順と、
   前記セッションに対応した確立中情報が前記確立処理中でない旨を示している場合、当該セッション開始要求を発行した端末装置に対して当該セッションを割り当てる割当制御手順と、
   前記セッション開始要求を発行した端末装置に対して当該セッションを割り当てた場合、当該セッションに対応付けて、当該セッションを識別するセッション識別情報及び当該端末装置を識別する端末識別情報を登録すると共に、当該セッションに対応した確立中情報を確立処理中である旨に登録する情報登録手順と、
   端末装置からセッション実行要求を受信すると、当該セッション実行要求に含まれるセッション識別情報と同一のセッション識別情報のセッションが前記記憶部内にあるか否かを判定し、同一セッション識別情報を持つセッションがある場合、当該セッション識別情報を使用して当該セッション実行要求を発行した端末装置とのセッションを確立する制御手順と
   を含むプログラムをコンピュータ装置に実行させることを特徴とするセッション確立プログラム。
10. 前記記憶部は、
    前記端末装置が対向装置内の各内部装置の状態監視に使用するセッション毎に、前記確立済み情報と、前記確立中情報とを対応付けて記憶することを特徴とする請求項９記載のセッション確立プログラム。

Images