JP2010097492A

JP2010097492A - デバイス共有システム、デバイス共有クライアント、およびデバイス共有方法

Info

Publication number: JP2010097492A
Application number: JP2008268916A
Authority: JP
Inventors: Yasushi Inaba; 泰稲葉; Hidenori Tanii; 秀典谷井; Takashi Kato; 隆加藤; Inochi Negishi; 命根岸
Original assignee: Canon Imaging Systems Inc
Current assignee: Canon Imaging Systems Inc
Priority date: 2008-10-17
Filing date: 2008-10-17
Publication date: 2010-04-30
Anticipated expiration: 2028-10-17
Also published as: JP5470518B2

Abstract

【課題】ストレージデバイスなどのデバイスをネットワーク上のクライアントＰＣで共用する場合、サーバ側の処理負荷を低減するとともに、ユーザに手動操作を強いることなく、必要なときだけデバイスにアクセスするように制御する手段を提供する。
【解決手段】クライアントＰＣからサーバにセッション開始要求を送ってセッションを接続し、セッション接続中は、クライアントＰＣが生成する第一の制御コマンドをサーバに送ってデバイスとの間でデータの入出力を行うと共に、第二の制御コマンドを定期的に生成してサーバに送ってセッションの接続状態を確認し、第二の制御コマンドに対する応答が所定条件を満たすと、サーバとの間のセッションを切断し、セッション切断後、クライアントＰＣは、定期的に生成する第二の制御コマンドをサーバに送らず、該第二の制御コマンドに対する応答を擬似的に生成し、上位層に通知する。
【選択図】図８

Description

本発明は、ネットワークを介してデバイスを共有する機能を備えたシステム、クライアント、およびその制御方法に関するものである。

ネットワークの普及により、従来、パーソナルコンピュータ（ＰＣ）などにローカル接続して利用していたデバイス（周辺機器）をネットワーク上のクライアントＰＣから利用できるように工夫したデバイスサーバが発表されている。

その中でもストレージデバイスを、ネットワーク上のクライアントＰＣからデバイスサーバを介して共有ストレージとして利用可能とするための実現方法がいくつか提案されている。

ひとつの実現方法として、クライアントＰＣのオペレーティングシステム（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ；以下、ＯＳ）に対して、ネットワークに接続されているストレージとして認識させる方法がある。

この方法では、ＳＭＢ（ＳｅｒｖｅｒＭｅｓｓａｇｅＢｌｏｃｋ）プロトコルを用いてデバイスサーバに排他制御やセッション管理の仕組みを備えることで、複数のクライアントＰＣから１台のストレージに対してファイルアクセスを可能としている。

しかしながら、デバイスサーバにＳＭＢプロトコルを実装する必要があるため、デバイスサーバ側の処理負荷が高くなり、高速なＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）や大容量のメモリが必要となり、デバイスサーバが高価となってしまう問題がある。

また、別の実現方法として、クライアントＰＣのＯＳに対して、ローカル接続されているストレージとして仮想的に認識させる方法がある。

この方法では、クライアントＰＣに専用のアプリケーションソフトウェア（ユーティリティ）を導入しておき、ユーザがストレージにアクセスしようとするときにユーティリティを操作し、クライアントＰＣに対してローカル接続したストレージとして仮想的に認識させることで、ネットワーク上のクライアントＰＣから、ローカル接続した状態と同様にファイルアクセスできるようにしている。

図１４は、クライアントＰＣに導入したユーティリティをユーザが操作し、ストレージとのセッション接続の開始・切断を行う場合の基本的な動作を示すフローチャートである。

まず、ストレージを使用するとき、クライアントＰＣとストレージは接続状態でないため、クライアントＰＣのユーティリティを起動する。ユーティリティが起動すると、ユーザ操作によるストレージの使用開始待ちの状態となる（ステップＳ１４０１）。

そして、ユーザがクライアントＰＣのユーティリティを操作し、ストレージの接続操作を実行すると、クライアントＰＣからデバイスサーバに対してセッション開始要求が送られる（ステップＳ１４０２）。

デバイスサーバとの間でセッションが開始されると（ステップＳ１４０３でＹｅｓ）、ストレージへのアクセスが可能となり（ステップＳ１４０４、Ｓ１４０５）、ユーザによるストレージの切断操作が実行されない限り（ステップＳ１４０６でＮｏ）、繰り返しストレージへのアクセスが行われる。

一方、デバイスサーバとの間でセッションが開始できない場合（ステップＳ１４０３でＮｏ）、ストレージにはアクセスできないことになる（ステップＳ１４１０）。

ストレージに対するアクセスが終了すると、ユーザがクライアントＰＣのユーティリティを操作してストレージの切断操作を実行する。

ストレージに対する切断操作が実行されると（ステップ１４０６でＹｅｓ）、クライアントＰＣからデバイスサーバに対してセッション終了要求が送られ（ステップＳ１４０７）、デバイスサーバとの間のセッションが切断され、ストレージへのアクセスが終了となる（ステップＳ１４０８、Ｓ１４０９）。

図１５は、図１４のフローチャートに基づいて動作するクライアントＰＣ（ＰＣ１，ＰＣ２）が複数台でストレージにアクセスするときの過程を示したタイミングチャートである。

まず、ＰＣ１によってストレージにアクセスを開始するとき、ユーザは、ＰＣ１のユーティリティによりセッションの開始操作を行う。

セッションの開始操作が行われると、ＰＣ１は、デバイスサーバに対してセッション開始要求を送り、セッションが開始されると、デバイスサーバを介してストレージにアクセスすることが可能となる。

続いて、ストレージにアクセスするため、ＰＣ１からデバイスサーバに対して制御コマンドを送ると、デバイスサーバを介してストレージへのデータの読み書きを実行することができる。

ＰＣ１とデバイスサーバがセッション接続中は、ＰＣ１にセッションが専有されているため、ＰＣ２からストレージにアクセスすることができない。

ＰＣ１によるアクセスが終了したら、ユーザは、ＰＣ１のユーティリティを操作してセッションの切断操作を実行する。

セッションの切断操作が実行されると、ＰＣ１からデバイスサーバに対してセッション終了要求が送られ、デバイスサーバとの間でセッションの切断処理を行い、ストレージへのアクセスが終了となる。

ここで、ユーザがＰＣ２のユーティリティによりセッションの開始操作を行うと、ＰＣ２からストレージへのアクセスが開始される。

このように、ユーティリティを使ってセッションの開始・切断を行うことによって、複数のクライアントＰＣからストレージを共有することができる。

しかし、この方法では、ユーザによるセッションの開始・切断操作が必要であり、クライアントＰＣがストレージにデータを読み書きしていない間（実際にアクセスしていない間）もセッションが維持されているため、ユーザがセッションを切断しない限り、他のクライアントＰＣがストレージを使用することができないという問題が生じる。

かかる問題を解決するために、ブロックヘッダで特定されるデータ長のブロックデータが伝送される間だけ、特定のクライアントＰＣによるデータ伝送専有状態として、当該クライアントＰＣとストレージとの間のデータ伝送を許可するデバイスサーバを用いたネットワークファイル管理システムが開示されている。（特許文献１参照）

特開２００７−３１７０６７号公報

しかし、特許文献１に開示されたネットワークファイル管理システムでは、ストレージが使用されない無駄な空白時間を発生させることなしに複数のクライアントＰＣからストレージを共有することはできるものの、複数のクライアントＰＣからのアクセス要求が常にネットワーク上を行き交うことでトラフィック量が増大化するという問題が発生する。

しかも、多数のアクセス要求を処理し、特定のクライアントＰＣに対するデータ伝送専有状態の設定・解除を制御するために、デバイスサーバには高い処理性能が要求されるため、上述したＳＭＢプロトコルを用いて実現する方法と同様、デバイスサーバの高価格化は避けられない。

上記問題に鑑みて、本発明は、ストレージなどのデバイス（周辺機器）をネットワーク上のクライアントＰＣで共用する場合、サーバ側の処理負荷を低減するとともに、ユーザに手動操作を強いることなく、必要なときだけデバイスにアクセスするように制御する手段を提供することを目的とする。

上記目的を達するために、請求項１に記載のクライアントは、ネットワークを介してサーバに接続されたデバイスとの間でデータの入出力を行うクライアントであって、前記クライアント全体を制御するとともに前記デバイスへのアクセスを指示する上位層と、前記上位層からの指示に応じて第一の制御コマンドまたは第二の制御コマンドを生成する制御コマンド生成手段と、前記制御コマンド生成手段で生成された前記第一の制御コマンドまたは前記第二の制御コマンドに基づき、前記サーバとのセッションを制御するセッション制御手段と、を備え、前記セッション制御手段は、前記制御コマンド生成手段によって前記第一の制御コマンドまたは前記第二の制御コマンドが生成されると前記サーバに対してセッション開始要求を送るセッション開始要求手段と、当該セッション開始要求に対する応答に基づき前記サーバとセッションを開始するセッション開始手段と、前記サーバとセッション接続中、前記第一の制御コマンドに基づきデバイスとの間でデータの入出力を行うデータ入出力手段と、前記サーバとセッション接続中、前記第二の制御コマンドを前記サーバに対して定期的に送り当該セッションの接続状態を確認するセッション接続状態確認手段と、前記サーバから受信した当該第二の制御コマンドに対する応答が所定条件を満たすとき、当該セッションを切断するセッション切断手段と、当該セッションの切断後、前記制御コマンド生成手段で生成された前記第二の制御コマンドを前記サーバに対して送らず、当該第二の制御コマンドに対する応答を擬似生成して、前記上位層に通知する擬似応答手段とから構成されることを特徴とする。

上記目的を達するために、請求項８に記載のデバイス共有システムは、デバイスと、サーバと、ネットワークを介して前記サーバに接続された前記デバイスとの間でデータの入出力を行うクライアントから構成されるデバイス共有システムにおいて、前記クライアントは、前記クライアント全体を制御するとともに前記デバイスへのアクセスを指示する上位層と、前記上位層からの指示に応じて第一の制御コマンドまたは第二の制御コマンドを生成する制御コマンド生成手段と、前記制御コマンド生成手段で生成された前記第一の制御コマンドまたは前記第二の制御コマンドに基づき、前記サーバとのセッションを制御するセッション制御手段と、を備え、前記セッション制御手段は、前記制御コマンド生成手段によって前記第一の制御コマンドまたは前記第二の制御コマンドが生成されると前記サーバに対してセッション開始要求を送るセッション開始要求手段と、当該セッション開始要求に対する応答に基づき前記サーバとセッションを開始するセッション開始手段と、前記サーバとセッション接続中、前記第一の制御コマンドに基づきデバイスとの間でデータの入出力を行うデータ入出力手段と、前記サーバとセッション接続中、前記第二の制御コマンドを前記サーバに対して定期的に送り当該セッションの接続状態を確認するセッション接続状態確認手段と、前記サーバから受信した当該第二の制御コマンドに対する応答が所定条件を満たすとき、当該セッションを切断するセッション切断手段と、当該セッションの切断後、前記制御コマンド生成手段で生成された前記第二の制御コマンドを前記サーバに対して送らず、当該第二の制御コマンドに対する応答を擬似生成して、前記上位層に通知する擬似応答手段とで構成されることを特徴とする。

上記目的を達するために、請求項１８に記載のデバイス共有方法は、ネットワークを介してサーバに接続されたデバイスをクライアントによって共有するデバイス共有方法であって、前記クライアント全体を制御するとともに前記デバイスへのアクセスを指示する上位層からの指示に応じて第一の制御コマンドまたは第二の制御コマンドを生成する制御コマンド生成ステップと、前記制御コマンド生成ステップで生成された前記第一の制御コマンドまたは前記第二の制御コマンドに基づき、前記サーバとのセッションを制御するセッション制御ステップと、を実行し、前記セッション制御ステップでは、前記制御コマンド生成ステップによって前記第一の制御コマンドまたは前記第二の制御コマンドが生成されると前記サーバに対してセッション開始要求を送るセッション開始要求ステップと、当該セッション開始要求に対する応答に基づき前記サーバとセッションを開始するセッション開始ステップと、前記サーバとセッション接続中、前記第一の制御コマンドに基づきデバイスとの間でデータの入出力を行うデータ入出力ステップと、前記サーバとセッション接続中、前記第二の制御コマンドを前記サーバに対して定期的に送り当該セッションの接続状態を確認するセッション接続状態確認ステップと、前記サーバから受信した当該第二の制御コマンドに対する応答が所定条件を満たすとき、当該セッションを切断するセッション切断ステップと、当該セッションの切断後、前記制御コマンド生成ステップで生成された前記第二の制御コマンドを前記サーバに対して送らず、当該第二の制御コマンドに対する応答を擬似生成して、前記上位層に通知する擬似応答ステップを実行することを特徴とする。

本発明によれば、クライアントＰＣに対して、ネットワーク上のデバイスサーバに接続されているデバイスをローカル接続したデバイスとして認識させるとともに、デバイスにアクセスするときだけ、クライアントＰＣとデバイスサーバ間のセッションを接続することができる。

これにより、ネットワーク上でデバイスを共有する際、ＳＭＢプロトコルや特許文献１に開示された処理機能をデバイスサーバへ組み込む必要が無くなるため、デバイスサーバの負荷が軽減され、安価なネットワークシステム構成で複数のクライアントＰＣからデバイスを共有することが可能となる。

また、クライアントＰＣに対してデバイスが常に接続された状態として認識させることにより、クライアントＰＣのユーティリティなどで手動操作して行っていたセッションの開始、切断の操作が不要となり、デバイスがネットワーク環境にあることを意識せずに使用することが可能となる。

以下、本発明の第一の実施の形態について図面を参照して詳細に説明する。

図１は、本発明を実現するためのネットワークシステムの概略構成であり、ＰＣ１００Ａ，ＰＣ１００Ｂと、デバイスサーバ２００と、ストレージ３００から構成されている。

このネットワークシステムでは、デバイスサーバ２００とストレージ３００をＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）やＩＥＥＥ１３９４などのインターフェースに準拠した接続ケーブル４００で接続する。また、デバイスサーバ２００とＰＣ１００（ＰＣ１００Ａ，ＰＣ１００Ｂ）は、有線または無線のネットワーク５００で接続する。

また、図１のネットワークシステムでは、デバイスサーバ２００、ストレージ３００をそれぞれ別体の装置で構成しているが、この構成に限定されるものではなく、同等の機能を実現できる構成であれば種々の構成を採り得ることは勿論である。例えば、デバイスサーバ２００をストレージ３００のケーシング内に収まるように一体構造としても良い。

なお、以降の説明においては、クライアントＰＣのオペレーティングシステム（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ；以下、ＯＳ）をＷｉｎｄｏｗｓ（登録商標）、デバイスをストレージ、デバイスサーバとデバイスの接続インターフェースをＵＳＢとした場合の構成で説明するが、これらに限定されず、別のＯＳや接続インターフェースを使用しても良い。

次に、図１のネットワークシステムを構成する各装置について順次説明してゆく。

まず、クライアントであるＰＣ１００について説明する。ＰＣ１００（ＰＣ１００Ａ，ＰＣ１００Ｂ）は、例えば、パーソナルコンピュータのような装置であり、ネットワーク５００と接続し、デバイスサーバ２００を介してストレージ３００を利用することが可能な構成となっている。

図２は、ＰＣ１００（ＰＣ１００Ａ，ＰＣ１００Ｂ）のハードウェア構成およびソフトウェア構成の一例を示すブロック図である。

ＰＣ１００は、ＣＰＵ１０１、入力部１０２、表示部１０３、メモリ１０４、通信部１０５、外部記憶部１０６などから構成されており、これらが内部バス１０７で接続されている。

外部記憶部１０６は、ＯＳ１１０、アプリケーションプログラム１１１、本発明を実現するためのソフトウェア群１１２〜１１６（後述）など各種ソフトウェアが記録されている。ここで、アプリケーションプログラム１１１とは、ファイル管理ソフトウェアなど、ストレージ３００へのアクセスを発生せしめるソフトウェアプログラムを指す。

外部記憶部１０６に記憶されたこれらソフトウェアは、ＣＰＵ１０１の制御に従い、メモリ１０４上に読み出されて実行される。

通信部１０５は、ネットワーク５００（有線又は無線ネットワーク）に接続するためのインターフェースであり、デバイスサーバ２００との間でデータ通信を行うことで、ＰＣ１００からデバイスサーバ２００を介したストレージ３００へのアクセスを可能とする。

本発明を実現するためのソフトウェア群１１２〜１１６について説明する。

ＳＣＳＩコマンド層１１２は、ストレージ３００にアクセスする際に使用するドライバソフトウェア（例えば、ｄｉｓｋ．ｓｙｓなど）である。

ＰＣ１００内において、上位層（ＯＳ１１０およびアプリケーションプログラム１１１）からの指示によりストレージ３００へのアクセスが発生すると、制御コマンドであるＳＣＳＩコマンドの生成を行い、フィルタドライバ層１１３へ送出し、当該ＳＣＳＩコマンドに対する応答情報を待つ。なお、これ以降の説明では、制御コマンドをＳＣＳＩコマンドとして説明するが、ＳＣＳＩコマンドに限定するものではない。

フィルタドライバ層１１３は、ＳＣＳＩコマンド層１１２又はＵＳＢドライバ層１１４から送られてくるＳＣＳＩコマンドの種類（内容）を解析するソフトウェアである。

また、ＳＣＳＩコマンドの解析結果に基づいてＳＣＳＩコマンド層１１２を介して上位層に擬似応答情報を返すとともに、ネットワークプロトコル層１１５と連携してデバイスサーバ２００との間のセッションを切断する機能を備えている。

ＵＳＢドライバ層１１４は、接続対象となるＵＳＢデバイス（本実施例では、ストレージ３００）が持つ機能に合わせた制御を行うドライバソフトウェア（例えば、ｕｓｂｓｔｏｒ．ｓｙｓなど）であり、また、ＳＣＳＩコマンドとＵＳＢデバイスが扱えるＵＳＢパケットとの変換処理などを行うソフトウェアである。

ネットワークプロトコル層１１５は、ＵＳＢパケットに対してＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）ヘッダの付加、取り外しの処理を行い、ネットワーク５００を介して接続されているデバイスサーバ２００との間のデータ通信を制御するソフトウェアである。

ネットワークインターフェース層１１６は、Ｅｔｈｅｒｎｅｔ（登録商標）のような有線ネットワーク、若しくは、ＩＥＥＥ８０２．１１ａやＩＥＥＥ８０２．１１ｂのような無線ネットワークなどネットワーク５００に対応したネットワークパケットによる送受信や通信制御を行うためのドライバソフトウェアである。

なお、本実施例では、フィルタドライバ層１１３がＳＣＳＩコマンド層１１２とＵＳＢドライバ層１１４との間に配置してあるが、この位置に限定されるものではない。例えば、ＵＳＢドライバ層１１４の下に配置する構成や、ネットワークプロトコル層１１５のドライバソフトウェアの一部に組み込まれる構成であっても良い。

次に、デバイスサーバ２００について説明する。デバイスサーバ２００は、ＰＣ１００Ａ，１００Ｂとデバイスであるストレージ３００と間の接続制御を行う装置である。

図３は、デバイスサーバ２００のハードウェア構成およびソフトウェア構成の一例を示すブロック図である。

デバイスサーバ２００は、ＣＰＵ２０１、入力部２０２、表示部２０３、ＲＯＭ２０４、ＲＡＭ２０５、通信部２０６、ＵＳＢインターフェース２０７などから構成されており、これらが内部バス２０８で接続されている。

ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）２０４には、ＯＳ２１０、制御プログラム２１１、本発明を実現するためのソフトウェア群２１２〜２１３（後述）など各種ソフトウェアが記録されており、これらソフトウェアは、ＣＰＵ２０１の制御に従い、ＲＡＭ２０５上に読み出されて実行される。

ＵＳＢインターフェース２０７は、接続ケーブル４００を介してストレージ３００とローカル接続するためのインターフェースである。

通信部２０６は、ネットワーク５００（有線又は無線ネットワーク）に接続してＰＣ１００との間でデータ通信するためのインターフェースである。

本発明を実現するためのソフトウェア群２１２〜２１３について説明する。

通信層２１２は、ネットワークに接続された通信部２０６の制御を行うとともに、ネットワーク５００に接続されているＰＣ１００との間のセッションやネットワークパケットによる通信を行うソフトウェアである。

また、ＵＳＢコマンド層２１３との間で通信するため、ネットワークパケットとＵＳＢパケットとの変換を行う。ネットワークパケットはＵＳＢパケットにＩＰヘッダを付加して作成するため、変換にはＩＰヘッダの取り付け及び取り外しを行う。

ＵＳＢコマンド層２１３は、ＵＳＢパケットに基づいて、ストレージ３００との間でデータ通信を行うソフトウェアである。

なお、通信層２１２、ＵＳＢコマンド層２１３は、ストレージ３００内に内蔵する構成であっても良い。また、通信層２１２の機能を備えたソフトウェアを別筐体内に設け、デバイス（ストレージ３００）に接続可能なインターフェースを有した外付けアダプタの形態として構成してもよい。この場合は、ＵＳＢコマンド層２１３の機能を持つソフトウェアは、デバイス３００側のＲＡＭや外部記憶装置などに記録しておく構成とする。

ここで、上述した図２及び図３で各ソフトウェア構成を説明したＰＣ１００とデバイスサーバ２００間の通信に関して説明する。

ＰＣ１００のネットワークプロトコル層１１５は、ネットワークインターフェース層１１６を介して、デバイスサーバ２００の通信層２１２とＴＣＰプロトコル（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）を用いて通信する。ＴＣＰプロトコルは、信頼性のある通信を保証するためのプロトコルであり、本実施例においては、ネットワーク５００上に流れるストレージ３００のデータの転送に用いている。

ストレージ３００は、例えば、ＨＤＤ（ＨａｒｄＤｉｓｋＤｒｉｖｅ）のような装置であり、各種データの書き込み処理や読出し処理が可能な装置である。

なお、本実施例では、デバイスとしてストレージを例に説明しているが、例えば、プリンタやスキャナなど、別のデバイスであってもよい。

図４は、ＰＣ１００からストレージ３００へアクセスするときに使用する主なＳＣＳＩコマンドについて、ＣＤＢ（ＣｏｍｍａｎｄＤｅｓｃｒｉｐｔｏｒＢｌｏｃｋ）の種類、オペレーションコード、サイズと意味を示した一覧リストであり、上述したＰＣ１００のＳＣＳＩコマンド層１１２（図２参照）で生成される制御コマンドである。本発明においては、これらのＳＣＳＩコマンドをセッション制御に利用する。

各ＣＤＢは、１バイトのオペレーションコードとそれに対応する構造体のサイズが定義されており、例えば、ＴｅｓｔＵｎｉｔＲｅａｄｙのＣＤＢでは、オペレーションコードは０ｘ００であり、サイズは６バイトである。以下、本実施例の説明で使用するコマンドについて説明する。

ＴｅｓｔＵｎｉｔＲｅａｄｙコマンド（以下、ＴＵＲコマンド）は、ストレージ３００へのアクセスがアイドル状態になった場合、ＰＣ１００から定期的（例えば、一秒間隔）に送出され、ストレージの状態を確認するために用いられている制御コマンドである。

ＲＥＡＤコマンドは、ストレージ３００からデータを読み出すときに用いられるコマンドであり、ＷＲＩＴＥコマンドは、ストレージ３００へデータを書き込むときに用いられるコマンドである。なお、これ以降の説明では、ＴＵＲコマンド以外の制御コマンドを「アクセス制御コマンド」として説明する。

図５は、図４に図示した各ＳＣＳＩコマンドで共通に使用されるＳＲＢ（ＳＣＳＩＲｅｑｕｅｓｔＢｌｏｃｋ）のパケットフォーマットである。パケットは、ＳＲＢのサイズを示す２バイトのＬｅｎｇｔｈと、機能を示す１バイトのＦｕｎｃｔｉｏｎのフィールドなどで構成される。

ＳＣＳＩコマンド層１１２からフィルタドライバ層１１３へ送信されるＳＲＢ構造体は、６４バイトのサイズであり、Ｌｅｎｇｔｈ＝６４が設定される。Ｆｕｎｃｔｉｏｎは、ＳＣＳＩコマンドの実行コードとして０ｘ００、ストレージ３００への要求コードとしての０ｘ０１、制御を行う０ｘ０２などの値が設定される。

先頭からオフセット１０バイト目にあたる１バイトのＣｄｂＬｅｎｇｔｈは、ＣＤＢの有効データサイズを示している。ＣＤＢは、ＳＣＳＩデバイスの具体的なコマンドを示しており、オフセット４８バイト目から、１６バイト固定長のデータ領域が確保されている。

次に、ＰＣ１００とストレージ３００間のデータ通信の大まかな流れについて図６を参照しながら説明する。

まず、ＰＣ１００からストレージ３００へデータ送信を行う場合について説明する。

ＰＣ１００においてストレージ３００へのアクセス要求が発生すると、ＳＣＳＩコマンド層１１２は、アクセス要求の内容に応じて図４で説明したＳＣＳＩコマンドのいずれかを生成し、図５で示したフォーマットでフィルタドライバ層１１３へ送る。

フィルタドライバ層１１３は、ＳＣＳＩコマンド層１１２で生成されたＳＣＳＩコマンドの解析を行い、どのような内容のアクセス要求なのかを判定する。

ＵＳＢドライバ層１１４は、フィルタドライバ層１１３で解析されたＳＣＳＩコマンドをＵＳＢパケットに変換する（ＳＣＳＩコマンドをＵＳＢパケットのデータ層に格納する）。

ネットワークプロトコル層１１５は、ＵＳＢドライバ層１１４でＳＣＳＩコマンドから変換されたＵＳＢパケットにＩＰヘッダを付加し、ネットワーク５００に適した形式のデータであるネットワークパケットを作成する。

ネットワークインターフェース層１１６は、ネットワークプロトコル層１１５で作成されたネットワークパケットをネットワーク５００を介してデバイスサーバ２００に送出する。

デバイスサーバ２００では、まず、通信層２１２で、ＰＣ１００からネットワーク５００を介して送信されたネットワークパケットを受信し、ネットワークパケットからＩＰヘッダを取り外すことでＵＳＢパケットに変換し、これをＵＳＢコマンド層２１３へ送る。

ＵＳＢコマンド層２１３では、通信層２１２から送られたＵＳＢパケットを、接続ケーブル４００を介してストレージ３００へ送る。

ストレージ３００は、デバイスサーバ２００から送られてきたＵＳＢパケットに含まれるＳＣＳＩコマンドを解析し、その種類に応じた応答処理を行う。

ＳＣＳＩコマンドがＴＵＲコマンドである場合は、ストレージ３００を使用可能か否かの状態の確認処理を実行する。

ＳＣＳＩコマンドがＲＥＡＤコマンドである場合は、ストレージ３００からの読み込み処理を実行する。

ＳＣＳＩコマンドがＷＲＩＴＥコマンドである場合は、ストレージ３００への書き込み処理を実行する。

ＳＣＳＩコマンドが上述した以外のコマンドである場合は、該当するコマンドに応じた処理を実行する。

次に、ストレージ３００からＰＣ１００へデータ送信（応答）を行う場合について説明する。

上述した応答処理を行ったストレージ３００は、その結果をＰＣ１００に対する応答情報としてＵＳＢパケットでデバイスサーバ２００へ送る。

デバイスサーバ２００では、ＵＳＢコマンド層２１３がストレージからの応答情報であるＵＳＢパケットを受け取り、それを通信層２１２へ送る。

通信層２１２では、ＵＳＢコマンド層２１３からのＵＳＢパケットにＩＰヘッダを付加し、ネットワーク５００に適した形式のデータであるネットワークパケットを作成し、ネットワーク５００を介してＰＣ１００に送出する。

このようにして、ＰＣ１００とストレージ３００との間でデバイスサーバ２００を介したデータ通信が実行されることになる。

次に、ＰＣ１００（ＰＣ１００Ａ，ＰＣ１００Ｂ）の基本制御について説明する。

ＰＣ１００では、デバイスサーバ２００との接続が定常状態であるかどうかを判断して、定常状態に達した場合には、デバイスサーバ２００とのセッションを切断し、ＰＣ１００の上位層（ＯＳ１１０、アプリケーションプログラム１１１）およびＳＣＳＩコマンド層１１２からはストレージ３００が接続されていると認識される、いわゆる「擬似接続状態」へ移行し、定常状態である期間は「擬似接続状態」を維持する制御を実行する。

なお、定常状態とは、ＰＣ１００とストレージ３００との接続が一定に保たれている状態をいい、定常状態であるかどうかの判断には、ＴＵＲコマンドに対してストレージ３００が連続して「ＳＵＣＣＥＳＳ」を応答した回数を用いるものとし、この回数（初期値０）をカウントするカウンタを、以降の説明ではＳＵＣＣＥＳＳカウンタと呼ぶものとする。

図７は、ＰＣ１００がデバイスサーバ２００を介してストレージ３００にアクセスするときの制御動作の手順を示すフローチャートである。

まず、ＰＣ１００において、ストレージ３００へのアクセスが発生した場合、ＳＣＳＩコマンド層１１２がアクセス要求の内容に応じたＳＣＳＩコマンド（図４参照）の生成を行い、生成されたＳＣＳＩコマンドは、フィルタドライバ層１１３へ送信される（ステップＳ７０１）。

次に、フィルタドライバ層１１３が、生成されたＳＣＳＩコマンドを解析する（ステップＳ７０２）。

ＳＣＳＩコマンドがＴＵＲコマンドである場合（ステップＳ７０２でＹｅｓ）、フィルタドライバ層１１３では、ＳＵＣＣＥＳＳカウンタの値を判定する（ステップＳ７０３）。この判定により、擬似接続状態であるか否かの判定が行われる。

ＳＵＣＣＥＳＳカウンタの値が「５」未満の場合（ステップＳ７０３でＮｏ）、次に、デバイスサーバ２００との間のセッションの有無を判定する（ステップＳ７０５）。

デバイスサーバ２００との間で「セッションなし」の場合（ステップＳ７０５でＹｅｓ）、即ち、ＳＵＣＣＥＳＳカウンタの値が「０」の場合は、デバイスサーバ２００に対してセッション開始要求を送り、デバイスサーバ２００とセッションを開始する（ステップＳ７０６)。

デバイスサーバ２００との間で「セッションあり」の場合（ステップＳ７０５でＮｏ）、即ち、ＳＵＣＣＥＳＳカウンタの値が「１」以上「５」未満の場合、ステップＳ７０６の処理はスキップされる。

続いて、デバイスサーバ２００に対してＴＵＲコマンドを送信する。デバイスサーバ２００は、ストレージ３００にＴＵＲコマンドを送り、ストレージ３００で確認処理が実行され、その応答情報がデバイスサーバ２００に返送される。デバイスサーバ２００は、この応答情報をＰＣ１００に返送する（ステップＳ７０７)。

ＰＣ１００は、デバイスサーバ２００から送られてくる応答情報を受信すると、応答内容を確認する（ステップＳ７０８) 。

応答内容が「ＦＡＩＬ」であった場合（ステップＳ７０８でＮｏ)、デバイスサーバ２００との間のセッションを維持したまま、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットし（ステップＳ７１５)、次のＳＣＳＩコマンドの受信待機状態に移る。

応答内容が「ＳＵＣＣＥＳＳ」であった場合(ステップＳ７０８でＹｅｓ)、ＳＵＣＣＥＳＳカウンタの値を１つインクリメントし（ステップＳ７０９）、続いて、ＳＵＣＣＥＳＳカウンタの値が規定値「５」であるか否かを判定する（ステップＳ７１０）。

ＳＵＣＣＥＳＳカウンタの値が規定値「５」未満の場合（ステップＳ７１０でＮｏ）、デバイスサーバ２００との間のセッションを維持したまま、次のＳＣＳＩコマンドの受信待機状態に移る。

ＳＵＣＣＥＳＳカウンタの値が規定値「５」を示す場合（ステップＳ７１０でＹｅｓ）、デバイスサーバ２００との接続が定常状態であると判断してセッションを終了し（ステップＳ７１１）、次のＳＣＳＩコマンドの受信待機状態に移る。

一方、上述したステップＳ７０３の処理において、ＳＵＣＣＥＳＳカウンタの値が規定値「５」以上の場合は（ステップＳ７０３でＹｅｓ）、セッションが終了した状態、すなわち定常状態であるため、実際のネットワーク接続によるストレージ３００への問い合わせは行わず、フィルタドライバ層１１３で擬似応答情報を生成し、ＳＣＳＩコマンド層１１２に「ＳＵＣＣＥＳＳ」を返す（ステップＳ７０４）。そして、ＳＣＳＩコマンド層１１２から上位層に対して「ＳＵＣＣＥＳＳ」が通知され、次のＳＣＳＩコマンドの受信待機状態に移る。

これ以降、フィルタドライバ層１１３がアクセス制御コマンドを受け取るまで、上述したステップＳ７０１〜Ｓ７０４が繰り返される。この間、ＰＣ１００の上位層（ＯＳ１１０、アプリケーションプログラム１１１）およびＳＣＳＩコマンド層１１２では、ストレージ３００が接続された状態と判断されているが、デバイスサーバ２００とのセッションが切断されている状態、いわゆる「擬似接続状態」を維持することになる。

また、上述したステップＳ７０２の処理で、フィルタドライバ層１１３が解析したＳＣＳＩコマンドがアクセス制御コマンドである場合の処理について説明する。

ＳＣＳＩコマンドがアクセス制御コマンドの場合（ステップＳ７０２でＮｏ）、例えば、ＲＥＡＤコマンド／ＷＲＩＴＥコマンドなどの場合、次に、デバイスサーバ２００との間のセッションの有無を判定する（ステップＳ７１２）。

デバイスサーバ２００との間で「セッションなし」の場合（ステップＳ７１２でＹｅｓ）、ＳＵＣＣＥＳＳカウンタの値が「０」の場合は、デバイスサーバ２００に対してセッション開始要求を送り、デバイスサーバ２００とセッションを開始する（ステップＳ７１３）。

デバイスサーバ２００との間で「セッションあり」の場合（ステップＳ７１２でＮｏ）、即ち、ＳＵＣＣＥＳＳカウンタの値が「１」以上「５」未満の場合、ステップＳ７１３の処理はスキップされる。

続いて、デバイスサーバ２００に対してＲＥＡＤコマンド／ＷＲＩＴＥコマンドなどのＳＣＳＩコマンドを送信する。デバイスサーバ２００は、ストレージ３００に対しこのＳＣＳＩコマンドを送り、ストレージ３００でＲＥＡＤコマンド／ＷＲＩＴＥコマンドなどに応じた処理が実行され、その応答情報がデバイスサーバ２００に返送される。デバイスサーバ２００は、この応答情報をＰＣ１００に返送する（ステップＳ７１４)。

ＰＣ１００は、デバイスサーバ２００から送られてくる応答情報を受信すると、デバイスサーバ２００とのセッションを維持したまま、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットし（ステップＳ７１５)、次のＳＣＳＩコマンドの受信待機状態に移る。

上記のＳＵＣＣＥＳＳカウンタは、フィルタドライバ層１１３がその機能の一部として備えるものでもよく、また、別のソフトウェアとして外部記憶部１０６に記録され、ソフトウェア群１１２〜１１６同様、ＣＰＵ１０１の制御に従い、メモリ１０４上に読み出されて実行されるものでもよい。

上述したように、フィルタドライバ層１１３では、ＳＵＣＣＥＳＳカウンタの値が規定値「５」となるまでの間にアクセス制御コマンドを受信した場合、又は、応答情報が「ＦＡＩＬ」である場合、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットする。

本実施の形態では、ＰＣ１００とデバイスサーバ２００との接続が定常状態であるかどうかの判断基準の一例として、ＳＵＣＣＥＳＳカウンタの値を用いているが、規定値は「５」以外の値でも良く、ユーザが任意に設定できるようにしても良い。また、ＴＵＲコマンドに対する応答が一定時間ＳＵＣＣＥＳＳであることなどを条件にしても良い。

図８は、図７の制御フローに基づいて動作するＰＣ１００の状態遷移を示した図である。

状態８０１は、電源投入直後などＰＣ１００の初期状態である。このとき、デバイスサーバ２００との間は「セッションなし」で、ＳＵＣＣＥＳＳカウンタの値は初期値「０」である。

状態８０１において、ストレージ３００に対するアクセスが発生すると、状態８０１から状態８０２に遷移する。

状態８０２は、デバイスサーバ２００との接続がまだ定常状態になっていない状態である。このとき、デバイスサーバ２００との間は「セッションあり」で、ＳＵＣＣＥＳＳカウンタの値は「５」未満である。

状態８０２において、ＳＣＳＩコマンドを生成してデバイスサーバ２００に送出した後、デバイスサーバ２００を介してストレージ３００からの応答情報を受信すると、次の（ａ）、（ｂ）、（ｃ）の何れかの状態となる。

（ａ）ＴＵＲコマンドの要求があり、これに対する応答が「ＳＵＣＣＥＳＳ」であり、ＳＵＣＣＥＳＳカウンタの値が規定値「５」に達した場合、状態８０３に遷移する。

（ｂ）ＴＵＲコマンドの要求があり、これに対する応答が「ＳＵＣＣＥＳＳ」であり、ＳＵＣＣＥＳＳカウンタの値が規定値「５」未満の場合は、状態８０２を維持する。

（ｃ）アクセス制御コマンドの要求があり、これに対する応答があった場合、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットし、状態８０２を維持する。

このように、ＰＣ１００は、上述した（ａ）の場合のみ、状態８０２から状態８０３に遷移する。

状態８０３は、デバイスサーバ２００との接続が定常状態に達した状態、即ち、擬似接続状態を示している。このとき、デバイスサーバ２００との間は「セッションなし」で、ＳＵＣＣＥＳＳカウンタの値は規定値「５」以上である。

状態８０３において、ＯＳ１１０およびアプリケーションプログラム１１１からの指示によりＳＣＳＩコマンド層１１２がＳＣＳＩコマンドを生成したとき、次の（ｄ）、（ｅ）の何れかの状態となる。

（ｄ）ＳＣＳＩコマンドがＴＵＲコマンドの場合、フィルタドライバ層１１３で擬似応答情報を生成し、ＳＣＳＩコマンド層１１２に対しＳＵＣＣＥＳＳを応答し、状態８０３を維持する。

（ｅ）ＳＣＳＩコマンドがアクセス制御コマンドの場合、デバイスサーバ２００との間のセッションを開始し、デバイスサーバ２００に対して生成したＳＣＳＩコマンドを送る。そして、デバイスサーバ２００を介してストレージ３００からの応答情報を受信すると、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットし、状態８０２へ遷移する。

このように、ＰＣ１００は、ストレージ３００にアクセスが必要なときだけ、デバイスサーバ２００と間のセッションを開始してＳＣＳＩコマンドの送出を行うので、セッションの開始・切断を手動操作することなく、複数のクライアントＰＣによるストレージのアクセスを実現できる。また、クライアントＰＣからデバイスサーバ２００に対して定期的に送出するＴＵＲコマンドを抑制し、ネットワーク上の通信量（トラフィック）を低減することができる。

次に、デバイスサーバ２００の制御動作について図９を参照しながら説明する。

デバイスサーバ２００では、ＰＣ１００からのセッション開始要求又はセッション終了要求の受信を監視している。

セッション開始要求を受信した場合（ステップＳ９０１でＹｅｓ）、他のＰＣ１００とセッション接続中か否かを確認する（ステップＳ９０２）。

既にセッションが開始されている場合（ステップＳ９０２でＹｅｓ）、このＰＣ１００に対して「ＮＧ」を返す（ステップＳ９０３）。

セッションが開始されていない場合（ステップＳ９０２でＮｏ）、このＰＣ１００とセッションを開始し（ステップＳ９０４）、応答情報として「ＯＫ」を返す（ステップＳ９０５）。

上述したステップＳ９０１の処理において、セッション開始要求以外のパケットを受信した場合（ステップＳ９０１でＮｏ）、セッション終了要求であれば（ステップＳ９０６でＹｅｓ）、セッション接続中のＰＣ１００との間のセッションを切断し（ステップＳ９０７）、応答情報として「ＯＫ」を返す（ステップＳ９０８）。

一方、上述したステップＳ９０６の処理において、セッション終了要求以外のパケットを受信した場合（ステップＳ９０６でＮｏ）、そのパケットの種類に応じた応答処理を実行する（ステップＳ９０９）。

図１０は、図９の制御フローに基づいて動作するデバイスサーバ２００の状態遷移を示した図である。

状態１００１は、デバイスサーバ２００の初期状態である。このとき、ＰＣ１００との間は「セッションなし」である。ＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）プロトコルを用いた通信などによる外部からの要求に応答し、状態１００１を維持する。

ここで、ＰＣ１００においてストレージ３００に対するアクセスが発生すると、ＰＣ１００からデバイスサーバ２００に対してセッション開始要求が送られる。デバイスサーバ２００は、セッション開始要求に応じてＰＣ１００との間のセッションを開始し、状態１００２に遷移する（図１０の（ａ））。

状態１００２は、「セッションあり」の状態である。この状態では、次の（ｂ）、（ｃ）、（ｄ）の処理を行い、状態１００２を維持する。

（ｂ）セッション接続中のＰＣ１００からコマンドを受信して、それをストレージ３００に送信し、ストレージ３００から受信する当該コマンドに対する応答情報をＰＣ１００に返送する。

（ｃ）セッション接続中ではない他のＰＣ１００からセッション開始要求があった場合、そのＰＣ１００に対して新たにセッションを開始することができないため、「ＮＧ」を応答する。

（ｄ）ＵＤＰプロトコルを用いた通信などによる外部からの要求に応答する。

一方、状態１００２において、セッション接続中のＰＣ１００からセッション終了要求があった場合、当該ＰＣ１００とのセッションを切断し、状態１００１へ遷移する（図１０の（ｅ））。

このように、デバイスサーバ２００では、ＰＣ１００の状態遷移に応じて、「セッションなし」の状態１００１と「セッションあり」の状態１００２との遷移を繰り返す。

次に、上述したネットワークシステムにおいて、ＰＣ１００Ａからストレージ３００へアクセスするときの具体的なタイミングチャートについて説明する。

簡略化して分り易く説明をするために、まず、ＰＣ１００Ａ一台だけがストレージ３００にアクセスする場合（１対１で接続する場合）について、図１１を参照しながら説明する。

ここでは、他のクライアントＰＣからのセッション開始要求の有無を考慮せず、ＰＣ１００Ａからのセッション開始要求に対して、デバイスサーバ２００は常に「ＯＫ」を応答するものとする。

ＰＣ１００Ａにおいてストレージ３００へのアクセスが発生した場合、ストレージドライバであるＳＣＳＩコマンド層１１２において、アクセスの種類に応じたＳＣＳＩコマンドが生成され、生成されたＳＣＳＩコマンドは、フィルタドライバ層１１３へ送信される（タイミングＴ１１０１）。

フィルタドライバ層１１３は、デバイスサーバ２００に対してセッション開始要求を行う（タイミングＴ１１０２）。このとき、ＳＵＣＣＥＳＳカウンタの値は初期値の「０」である。

デバイスサーバ２００は、ＰＣ１００Ａに対して「ＯＫ」を応答して、ＰＣ１００Ａとの間のセッションを開始する（タイミングＴ１１０３）。

フィルタドライバ層１１３は、デバイスサーバ２００から「ＯＫ」の応答がありセッションが開始されると、ストレージ３００の状態を確認するためのＴＵＲコマンドを送信する（タイミングＴ１１０４）。

デバイスサーバ２００は、ＴＵＲコマンドを受信すると、これをストレージ３００に送信する（タイミングＴ１１０５）。ストレージ３００は、ＴＵＲコマンドに応じた処理を実行し、処理が完了すると応答情報をデバイスサーバ２００に返す（タイミングＴ１１０６）。デバイスサーバ２００はストレージ３００からの応答情報をＰＣ１００Ａに送る（タイミングＴ１１０７）。

フィルタドライバ層１１３は、デバイスサーバ２００から応答情報を受信し、これが「ＳＵＣＣＥＳＳ」であれば、ＳＵＣＣＥＳＳカウンタの値を１インクリメントするとともにＳＣＳＩコマンド層１１２へ応答を返す（タイミングＴ１１０８）。

以後、規定値「５」になるまで定期的（例えば、１秒間隔）にＴＵＲコマンドを送出する（タイミングＴ１１０９）。そして、ＳＵＣＣＥＳＳカウンタの値が規定値「５」になると、デバイスサーバ２００に対してセッション終了要求を送り、デバイスサーバ２００とのセッションを切断する（タイミングＴ１１１０）。

ＰＣ１００Ａでは、セッションが終了したあともＳＣＳＩコマンド層１１２が定期的にＴＵＲコマンドを送出するが（タイミングＴ１１１１）、フィルタドライバ層１１３はＳＵＣＣＥＳＳカウンタの値が規定値「５」以上となっているので、これ以降に送出するＳＣＳＩコマンドがＴＵＲコマンドである限り擬似応答情報をＳＣＳＩコマンド層１１２に返す（タイミングＴ１１１２）。

ＰＣ１００Ａの上位層（ＯＳ１１０、アプリケーションプログラム１１１）およびＳＣＳＩコマンド層１１２は、この擬似応答情報によってストレージ３００とは接続状態であると認識する。この状態がいわゆる「擬似接続状態」である。

次に、擬似接続状態のＰＣ１００Ａからストレージ３００に対してデータの書き込み／読み出しなどのアクセスを行う場合について説明する。

擬似接続状態のＰＣ１００Ａからストレージ３００に対してデータの書き込み／読み出しなどのアクセスを行うときは、アクセス制御コマンド（ＲＥＡＤコマンドやＷＲＩＴＥコマンドなど）の送信に先立って、まず、フィルタドライバ層１１３がデバイスサーバ２００に対してセッション開始要求を送る（タイミングＴ１１１３）。

デバイスサーバ２００は、ＰＣ１００Ａに対して「ＯＫ」を応答して、ＰＣ１００Ａとの間でセッションを開始する（タイミングＴ１１１４）。

フィルタドライバ層１１３は、デバイスサーバ２００から「ＯＫ」の応答がありセッションが開始されると、デバイスサーバ２００に対してアクセス制御コマンドを送る（タイミングＴ１１１５）。

デバイスサーバ２００は、ＰＣ１００Ａからアクセス制御コマンドを受信すると、ＵＳＢパケットに変換してストレージ３００へ送信する（タイミングＴ１１１６）。

ストレージ３００では、デバイスサーバ２００から送られてきたアクセス制御コマンドに応じた処理を実行し（例えば、データの書き込み／読み出しなど）、処理が終了するとその結果を応答情報としてデバイスサーバ２００に送信する（タイミングＴ１１１７）。

デバイスサーバ２００は、ストレージ３００からの応答情報を受信すると、この応答情報をＰＣ１００Ａに対して送信する（タイミングＴ１１１８）。

フィルタドライバ層１１３は、デバイスサーバ２００から応答情報を受信すると、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットするとともにＳＣＳＩコマンド層１１２へ応答を返す（タイミングＴ１１１９）。

その後は上述と同様に、フィルタドライバ層１１３からＴＵＲコマンドを定期的に送出し、ＳＵＣＣＥＳＳカウンタの値が規定値「５」になると、デバイスサーバ２００に対してセッション終了要求を送り、デバイスサーバ２００との間のセッションを切断する（タイミングＴ１１２０）。そして、再度ストレージ３００にアクセスするときまでの間、擬似接続状態を維持する。

次に、実際の運用により近いケースとして、複数台のＰＣ１００（ＰＣ１００Ａ，ＰＣ１００Ｂ）がストレージ３００にアクセスする場合（Ｎ対１で接続する場合）について、図１２を参照しながら説明する。

図１２は、ＰＣ１００Ａがセッション接続中、若しくは、ストレージ３００にアクセス中に、別のＰＣ１００Ｂからストレージ３００にアクセスしたときのタイミングチャートを示した説明図である。なお、ＰＣ１００Ａについては、前述した図１１と同じ動作であるため、詳細な説明は省略する。

まず、ＰＣ１００Ａとデバイスサーバ２００がセッション接続中のとき、ＰＣ１００Ｂがストレージ３００にアクセスしようとした場合について説明する。

ＰＣ１００Ａとデバイスサーバ２００との間でセッション接続中のとき、ＰＣ１００Ｂがデバイスサーバ２００にセッション開始要求を送る（タイミングＴ１２０１）。

デバイスサーバ２００は、ＰＣ１００Ａとセッション接続中のため、ＰＣ１００Ａとの間のセッションが切断されるまで間、ＰＣ１００Ｂに対して「ＮＧ」を返す（タイミングＴ１２０２）。

ＰＣ１００Ｂは、デバイスサーバ２００から「ＮＧ」の応答があると、定期的にセッション開始要求を再送する。

デバイスサーバ２００は、ＰＣ１００Ａとのセッションが切断され、「セッションなし」の状態（ＰＣ１００Ａが擬似接続状態）になったとき、ＰＣ１００Ｂからの「セッション開始要求」を受信すると、ＰＣ１００Ｂとの間でセッションを開始する（タイミングＴ１２０３）。

ＰＣ１００Ｂは、デバイスサーバ２００とセッションが開始されると、ストレージ３００の状態を確認するためＴＵＲコマンドを送信する（タイミングＴ１２０４）。

デバイスサーバ２００は、ＴＵＲコマンドを受信すると、これをストレージ３００に送信する（タイミングＴ１２０５）。ストレージ３００は、ＴＵＲコマンドに応じた処理を実行し、処理が完了すると応答情報をデバイスサーバ２００に返す。デバイスサーバ２００はストレージ３００からの応答情報をＰＣ１００Ｂに送る（タイミングＴ１２０６）。

ＰＣ１００Ｂは、デバイスサーバ２００から応答情報を受信し、これが「ＳＵＣＣＥＳＳ」であれば、ＳＵＣＣＥＳＳカウンタの規定値を判定し、規定値「５」になるまで定期的（例えば、１秒間隔）にＴＵＲコマンドを送出する（タイミングＴ１２０７）。そして、ＳＵＣＣＥＳＳカウンタの規定値「５」になると、デバイスサーバ２００に対してセッション終了要求を送り、デバイスサーバ２００とのセッションを切断する（タイミングＴ１２０８）。

この時点で、ＰＣ１００Ａ及びＰＣ１００Ｂは共に擬似接続状態であり、デバイスサーバ２００は「セッションなし」の状態である（タイミングＴ１２０９）。

続いて、ＰＣ１００Ａがストレージ３００にアクセス中（読出し中又は書き込み中など）に、ＰＣ１００Ｂからストレージ３００にアクセスしようとした場合について説明する。

上述したように、ＰＣ１００ＡとＰＣ１００Ｂは共に擬似接続状態であり、デバイスサーバ２００は「セッションなし」の状態であるとき、擬似接続状態のＰＣ１００Ａからデバイスサーバ２００にアクセスを開始すると、ＰＣ１００Ａからデバイスサーバ２００に対してセッション開始要求が送られ、デバイスサーバ２００との間のセッションが開始される。（タイミングＴ１２１０）

セッションが開始されると、ＰＣ１００Ａがデバイスサーバ２００に対してアクセス制御コマンド（ＲＥＡＤコマンドやＷＲＩＴＥコマンドなど）を送出し（タイミングＴ１２１１）、デバイスサーバ２００がストレージ３００に対してアクセス制御コマンドを送る（タイミングＴ１２１２）。

ストレージ３００では、アクセス制御コマンドに応じた処理（例えば、データの書き込み／読出しなど）を実行し、その結果を応答情報としてデバイスサーバ２００を介してＰＣ１００Ａに返信する（タイミングＴ１２１３）。

その後は上述と同様に、フィルタドライバ層１１３からＳＵＣＣＥＳＳカウンタの値が規定値「５」になるまで定期的に、ＴＵＲコマンドをデバイスサーバ２００に対して送出する（タイミングＴ１２１４）。

ここで、ＰＣ１００Ｂがストレージ３００へのアクセスを開始し、デバイスサーバ２００にセッション開始要求を送ると、デバイスサーバ２００は、ＰＣ１００Ｂに対して「ＮＧ」を応答する（タイミングＴ１２１５）。

ＰＣ１００Ｂは、デバイスサーバ２００からの「ＮＧ」応答に対して、定期的にセッション開始要求を再送するが、ＰＣ１００Ａとデバイスサーバ２００のセッションが切断されるまでは、デバイスサーバ２００からは「ＮＧ」が応答される。

デバイスサーバ２００とＰＣ１００Ａとの間のセッションが終了し、デバイスサーバ２００がセッションなしの状態になると、ＰＣ１００Ｂからのセッション開始要求により、ＰＣ１００Ｂとの間でセッションを開始する（タイミングＴ１２１６）。このときＰＣ１００Ａは擬似接続状態である。

これ以降のＰＣ１００Ｂの動作は、上述したＰＣ１００Ａと同様であり、セッションが開始されると、ＰＣ１００Ｂがデバイスサーバ２００を介してストレージ３００にアクセス可能になる。

上述したように、第一の実施の形態におけるネットワークシステムでは、あるクライアントＰＣがストレージ３００にアクセスするときだけ、クライアントＰＣとデバイスサーバ間のセッションを接続することにより、ネットワーク上の通信量（トラフィック）を低減することが可能となる。

また、高負荷な処理機能をデバイスサーバへ組み込む必要が無くなるため、安価なネットワークシステム構成で複数のクライアントＰＣからデバイスを共有することが可能となる。

次に、本発明の第二の実施の形態について図面を参照して詳細に説明する。本実施の形態は、図１〜図６、図８〜図１２に図示した構成が、上記第一の実施の形態と同じであり、その説明を省略する。以下に、上記第一の実施の形態と異なる点のみを説明する。

第二の実施の形態におけるＰＣ１００（ＰＣ１００Ａ，ＰＣ１００Ｂ）の基本制御フローについて、図１３を参照しながら説明する。図１３は第一の実施の形態における図７と同様、ＰＣ１００がデバイスサーバ２００を介してストレージ３００にアクセスするときの制御動作の手順を示すフローチャートであるが、ステップＳ１３１０とステップＳ１３１１は、図７にはなかったステップである（詳細は後述）。

ＰＣ１００において、ストレージ３００へのアクセスが発生した場合、ＳＣＳＩコマンド層１１２がアクセス要求の内容に応じたＳＣＳＩコマンド（図４参照）の生成を行い、生成されたＳＣＳＩコマンドは、フィルタドライバ層１１３へ送信される（ステップＳ１３０１）。

次に、フィルタドライバ層１１３が、生成されたＳＣＳＩコマンドを解析する（ステップＳ１３０２）。

ＳＣＳＩコマンドがＴＵＲコマンドである場合（ステップＳ１３０２でＹｅｓ）、フィルタドライバ層１１３では次に、ＴＵＲコマンドに対する応答が「ＳＵＣＣＥＳＳ」であるときの回数をカウントしているカウンタ（以降、ＳＵＣＣＥＳＳカウンタ）の値を判定する（ステップＳ１３０３）。この判定により、擬似接続状態であるか否かの判定が行われる。

ＳＵＣＣＥＳＳカウンタの値が「５」未満の場合（ステップＳ１３０３でＮｏ）、次に、デバイスサーバ２００との間のセッションの有無を判定する（ステップＳ１３０５）。

デバイスサーバ２００との間で「セッションなし」の場合（ステップＳ１３０５でＹｅｓ）、即ち、ＳＵＣＣＥＳＳカウンタの値が「０」の場合は、デバイスサーバ２００に対してセッション開始要求を送り、デバイスサーバ２００とセッションを開始する（ステップＳ１３０６)。

デバイスサーバ２００との間で「セッションあり」の場合（ステップＳ１３０５でＮｏ）、即ち、ＳＵＣＣＥＳＳカウンタの値が規定値未満の場合、ステップＳ１３０６の処理はスキップされる。

続いて、デバイスサーバ２００に対してＴＵＲコマンドを送信する。デバイスサーバ２００は、ストレージ３００にＴＵＲコマンドを送り、ストレージ３００で確認処理が実行され、その応答情報がデバイスサーバ２００に返送される。デバイスサーバ２００は、この応答情報をＰＣ１００に返送する。なお、このとき、デバイスサーバ２００は、他のクライアントＰＣ（例えば、ＰＣ１００Ｂ）から所定時間内に受信したセッション開始要求の有無をあわせて通知する。（ステップＳ１３０７)。

ここでいう所定時間とは、セッション開始後の累計時間や、定期的に送出されるＴＵＲコマンドの送出間隔（例えば、１秒間隔）を指すが、これに限定されるものではない。

ＰＣ１００Ａは、デバイスサーバ２００から送られてくる応答情報を受信すると、応答内容を確認する（ステップＳ１３０８) 。

応答内容が「ＦＡＩＬ」であった場合（ステップＳ１３０８でＮｏ)、デバイスサーバ２００との間のセッションを維持したまま、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットし（ステップＳ１３１７)、次のＳＣＳＩコマンドの受信待機状態に移る。

応答内容が「ＳＵＣＣＥＳＳ」であった場合(ステップＳ１３０８でＹｅｓ)、ＳＵＣＣＥＳＳカウンタの値を１つインクリメントする（ステップＳ１３０９）。

次に、ＰＣ１００Ａは、デバイスサーバ２００との接続を擬似接続状態に移行するかの基準となる規定値を変更するか否かを判定する（ステップＳ１３１０）。この判定には、ステップＳ１３０７において、デバイスサーバ２００から通知された他のクライアントＰＣからのセッション開始要求の有無に関する情報が用いられる。

他のクライアントＰＣからのセッション開始要求が「あり」の場合（ステップＳ１３１０でＹｅｓ）、規定値を変更する（例えば、「５」から「３」に下げる）（ステップＳ１３１１）。

一方、他のクライアントＰＣからのセッション開始要求が「なし」の場合（ステップＳ１３１０でＮｏ）、ステップＳ１３１１をスキップして規定値を変更しない。

続いて、ＳＵＣＣＥＳＳカウンタの値が規定値であるか否かを判定する（ステップＳ１３１０）。ステップＳ１３１１で規定値を変更した場合には、変更後の規定値に基づいて判定される。

ＳＵＣＣＥＳＳカウンタの値が規定値未満の場合（ステップＳ１３１０でＮｏ）、デバイスサーバ２００との間のセッションを維持したまま、次のＳＣＳＩコマンドの受信待機状態に移る。

一方、上述したステップＳ１３０３の処理において、ＳＵＣＣＥＳＳカウンタの値が規定値以上の場合は（ステップＳ１３０３でＹｅｓ）、セッションが終了した状態、すなわち定常状態であるため、実際のネットワーク接続によるストレージ３００への問い合わせは行わず、フィルタドライバ層１１３で擬似応答情報を生成し、ＳＣＳＩコマンド層１１２に「ＳＵＣＣＥＳＳ」を返す（ステップＳ１３０４）。そして、ＳＣＳＩコマンド層１１２から上位層に対して「ＳＵＣＣＥＳＳ」が通知され、次のＳＣＳＩコマンドの受信待機状態に移る。

これ以降、フィルタドライバ層１１３がアクセス制御コマンドを受け取るまで、上述したステップＳ１３０１〜Ｓ１３０４が繰り返される。この間、ＰＣ１００の上位層（ＯＳ１１０、アプリケーションプログラム１１１）およびＳＣＳＩコマンド層１１２では、ストレージ３００が接続された状態と判断されているが、デバイスサーバ２００とのセッションが切断されている状態、いわゆる「擬似接続状態」を維持することになる。

ＳＵＣＣＥＳＳカウンタの値が規定値を示す場合（ステップＳ１３１０でＹｅｓ）、デバイスサーバ２００との接続が定常状態であると判断してセッションを切断し（ステップＳ１３１１）、次のＳＣＳＩコマンドの受信待機状態に移る。

また、上述したステップＳ１３０２の処理で、フィルタドライバ層１１３が解析したＳＣＳＩコマンドがアクセス制御コマンドである場合の処理について説明する。

ＳＣＳＩコマンドがアクセス制御コマンドの場合（ステップＳ１３０２でＮｏ）、例えば、ＲＥＡＤコマンド／ＷＲＩＴＥコマンドなどの場合、次に、デバイスサーバ２００との間のセッションの有無を判定する（ステップＳ１３１４）。

デバイスサーバ２００との間で「セッションなし」の場合（ステップＳ１３１４でＹｅｓ）、ＳＵＣＣＥＳＳカウンタの値が「０」の場合は、デバイスサーバ２００に対してセッション開始要求を送り、デバイスサーバ２００とセッションを開始する（ステップＳ１３１５）。

デバイスサーバ２００との間で「セッションあり」の場合（ステップＳ１３１４でＮｏ）、即ち、ＳＵＣＣＥＳＳカウンタの値が規定値未満の場合、ステップＳ１３１５の処理はスキップされる。

続いて、デバイスサーバ２００に対してＲＥＡＤコマンド／ＷＲＩＴＥコマンドなどのＳＣＳＩコマンドを送信する。デバイスサーバ２００は、ストレージ３００に対しこのＳＣＳＩコマンドを送り、ストレージ３００でＲＥＡＤコマンド／ＷＲＩＴＥコマンドなどに応じた処理が実行され、その応答情報がデバイスサーバ２００に返送される。デバイスサーバ２００は、この応答情報をＰＣ１００に返送する（ステップＳ１３１６)。

ＰＣ１００は、デバイスサーバ２００から送られてくる応答情報を受信すると、デバイスサーバ２００とのセッションを維持したまま、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットし（ステップＳ１３１７)、次のＳＣＳＩコマンドの受信待機状態に移る。

上述したように、フィルタドライバ層１１３では、ＳＵＣＣＥＳＳカウンタの値が規定値となるまでの間にアクセス制御コマンドを受信した場合、又は、応答情報が「ＦＡＩＬ」である場合、ＳＵＣＣＥＳＳカウンタの値を「０」にリセットする。

上述したように、第二の実施の形態におけるネットワークシステムでは、デバイスサーバ２００がＰＣ１００に対して、他のクライアントＰＣからのセッション開始要求の有無をあわせて通知することによって、ＰＣ１００がより早く擬似接続状態に移行し、デバイスサーバ２００とのセッションを開放することができる。

なお、本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において適宜変更可能である。

上述した実施の形態では、１台のデバイスサーバが１台のストレージを管理する構成で説明したが、１台のサーバに複数のストレージを接続する構成としても良い。また、この場合はストレージ毎にセッションを用意し制御することで、複数のクライアントＰＣから、別々のストレージであれば、同時にアクセスが可能となる。

また、デバイスサーバとデバイスの接続インターフェースをＵＳＢとした場合の構成で説明したが、これらに限定されず、別の接続インターフェースを使用しても良い。具体的には、ＩＥＥＥ１３９４に対応するためには、ＰＣ１００が備えるＵＳＢドライバ層１１４とデバイスサーバ２００が備えるＵＳＢコマンド層２１２が、それぞれＩＥＥＥ１３９４ドライバ層とＩＥＥＥ１３９４コマンド層が置き換われば良い。

さらにはＰＣ１００が複数の異なるドライバ層を持ち、デバイスサーバ２００がそれに対応した複数の異なるコマンド層を備えるようにすれば、様々な接続インターフェースを備えたデバイスにも柔軟に対応できる。

また、本発明の目的は、上述した実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出して処理を実行することによっても達成することができる。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコードを記憶したコンピュータで読み取り可能な記憶媒体は本発明を構成することになる。

また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現されるように構成しても良い。

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

なお、プログラムコードを供給するため、例えば、フロッピー（登録商標)ディスク、ハードディスク、光磁気ディスク、ＣＤやＤＶＤに代表される光ディスク、磁気テープ、不揮発性のメモリカード、ＲＯＭ等の記憶媒体を用いることができる。または、プログラムコードは、ネットワークを介してダウンロードしてもよい。

本発明の実施形態に係るネットワークシステムの概略構成を示すブロック図である。図１のＰＣ１００Ａ，１００Ｂのハードウェアおよびハードウェアの概略構成を示すブロック図である。図１のデバイスサーバ２００のハードウェアおよびハードウェアの概略構成を示すブロック図である。制御コマンドとして用いられる主なＳＣＳＩコマンドの一覧表である。各ＳＣＳＩコマンドで共通に使用されるＳＲＢ（ＳＣＳＩＲｅｑｕｅｓｔＢｌｏｃｋ）のパケットフォーマットの説明図である。クライアントＰＣとストレージ間のデータ通信の大まかな流れの説明図である。第一の実施の形態におけるクライアントＰＣのセッションの制御動作を示すフローチャートである。クライアントＰＣの状態遷移図である。第一の実施の形態におけるデバイスサーバのセッションの制御動作を示すフローチャートである。デバイスサーバの状態遷移図である。第一の実施の形態における一台のクライアントＰＣがストレージにアクセスするときの過程を示したタイミングチャートである。第一の実施の形態における複数台のクライアントＰＣがストレージにアクセスするときの過程を示したタイミングチャートである。第二の実施の形態におけるクライアントＰＣのセッションの制御動作を示すフローチャートである。従来技術において、ネットワーク上のストレージにアクセスするとき、クライアントＰＣのユーティリティを操作してセッションを制御するときの動作を示すフローチャートである。従来技術において、複数台のクライアントＰＣがストレージにアクセスする場合の過程を示すタイミングチャートである。

符号の説明

１００Ａ，１００Ｂ：クライアントＰＣ
１０１：ＣＰＵ
１０２：入力部
１０３：表示部
１０４：メモリ
１０５：通信部
１０６：外部記憶部
１０７：内部バス
１１０：ＯＳ
１１１：アプリケーションプログラム
１１２：ＳＣＳＩコマンド層
１１３：フィルタドライバ層
１１４：ＵＳＢドライバ層
１１５：ネットワークプロトコル層
１１６：ネットワークインターフェース層
２００：デバイスサーバ
２０１：ＣＰＵ
２０２：入力部
２０３：表示部
２０４：ＲＯＭ
２０５：ＲＡＭ
２０６：通信部
２０７：ＵＳＢＩ／Ｆ（ＵＳＢインターフェース）
２０８：内部バス
２１０：ＯＳ
２１１：制御プログラム
２１２：通信層
２１３：ＵＳＢコマンド層
３００：ストレージ
４００：接続ケーブル
５００：ネットワーク

Claims

ネットワークを介してサーバに接続されたデバイスとの間でデータの入出力を行うクライアントであって、
前記クライアント全体を制御するとともに前記デバイスへのアクセスを指示する上位層と、
前記上位層からの指示に応じて第一の制御コマンドまたは第二の制御コマンドを生成する制御コマンド生成手段と、
前記制御コマンド生成手段で生成された前記第一の制御コマンドまたは前記第二の制御コマンドに基づき、前記サーバとのセッションを制御するセッション制御手段と、
を備え、
前記セッション制御手段は、
前記制御コマンド生成手段によって前記第一の制御コマンドまたは前記第二の制御コマンドが生成されると前記サーバに対してセッション開始要求を送るセッション開始要求手段と、
当該セッション開始要求に対する応答に基づき前記サーバとセッションを開始するセッション開始手段と、
前記サーバとセッション接続中、前記第一の制御コマンドに基づきデバイスとの間でデータの入出力を行うデータ入出力手段と、
前記サーバとセッション接続中、前記第二の制御コマンドを前記サーバに対して定期的に送り当該セッションの接続状態を確認するセッション接続状態確認手段と、
前記サーバから受信した当該第二の制御コマンドに対する応答が所定条件を満たすとき、当該セッションを切断するセッション切断手段と、
当該セッションの切断後、前記制御コマンド生成手段で生成された前記第二の制御コマンドを前記サーバに対して送らず、当該第二の制御コマンドに対する応答を擬似生成して、前記上位層に通知する擬似応答手段
とから構成されることを特徴とするクライアント。
前記セッション開始要求手段は、前記セッションの切断後、前記制御コマンド生成手段で生成される制御コマンドが前記第一の制御コマンドである場合、前記サーバに対してセッション開始要求を送ること
を特徴とする請求項１に記載のクライアント。
前記所定条件とは、前記第二の制御コマンドに対する成功応答が規定回数連続したか否かであること
を特徴とする請求項１に記載のクライアント。
前記所定条件とは、前記第二の制御コマンドに対する成功応答が規定時間連続したか否かであること
を特徴とする請求項１に記載のクライアント。
前記第一の制御コマンドは、前記デバイスとの間でデータの入出力を行うためのコマンドであり、前記第二の制御コマンドは、前記デバイスが利用可能か否かを確認するためのコマンドであること
を特徴とする請求項１に記載のクライアント。
前記セッション制御手段は、前記所定条件を変更するための所定条件変更手段を更に有すること
を特徴とする請求項１に記載のクライアント。
前記セッション接続状態確認手段は、他のクライアントからのセッション開始要求の有無を前記サーバから受信し、前記所定条件変更手段は、当該セッション開始要求の有無に応じて前記所定条件を変更すること
を特徴とする請求項６に記載のクライアント。
デバイスと、サーバと、ネットワークを介して前記サーバに接続された前記デバイスとの間でデータの入出力を行うクライアントから構成されるデバイス共有システムにおいて、
前記クライアントは、
前記クライアント全体を制御するとともに前記デバイスへのアクセスを指示する上位層と、
前記上位層からの指示に応じて第一の制御コマンドまたは第二の制御コマンドを生成する制御コマンド生成手段と、
前記制御コマンド生成手段で生成された前記第一の制御コマンドまたは前記第二の制御コマンドに基づき、前記サーバとのセッションを制御するセッション制御手段と、
を備え、
前記セッション制御手段は、
前記制御コマンド生成手段によって前記第一の制御コマンドまたは前記第二の制御コマンドが生成されると前記サーバに対してセッション開始要求を送るセッション開始要求手段と、
当該セッション開始要求に対する応答に基づき前記サーバとセッションを開始するセッション開始手段と、
前記サーバとセッション接続中、前記第一の制御コマンドに基づきデバイスとの間でデータの入出力を行うデータ入出力手段と、
前記サーバとセッション接続中、前記第二の制御コマンドを前記サーバに対して定期的に送り当該セッションの接続状態を確認するセッション接続状態確認手段と、
前記サーバから受信した当該第二の制御コマンドに対する応答が所定条件を満たすとき、当該セッションを切断するセッション切断手段と、
当該セッションの切断後、前記制御コマンド生成手段で生成された前記第二の制御コマンドを前記サーバに対して送らず、当該第二の制御コマンドに対する応答を擬似生成して、前記上位層に通知する擬似応答手段
とで構成されることを特徴とするデバイス共有システム。
前記クライアントは、前記セッション開始要求手段によって、前記セッションの切断後、前記制御コマンド生成手段で生成される制御コマンドが前記第一の制御コマンドである場合、前記サーバに対してセッション開始要求を送ること
を特徴とする請求項８に記載のデバイス共有システム。
前記所定条件とは、前記第二の制御コマンドに対する成功応答が規定回数連続したか否かであること
を特徴とする請求項８に記載のデバイス共有システム。
前記所定条件とは、前記第二の制御コマンドに対する成功応答が規定時間連続したか否かであること
を特徴とする請求項８に記載のデバイス共有システム。
前記第一の制御コマンドは、前記デバイスとの間でデータの入出力を行うためのコマンドであり、前記第二の制御コマンドは、前記デバイスが利用可能か否かを確認するためのコマンドであること
を特徴とする請求項８に記載のデバイス共有システム。
前記デバイスは、ストレージデバイスであること
を特徴とする請求項８に記載のデバイス共有システム。
前記クライアントのセッション制御手段は、前記所定条件を変更するための所定条件変更手段を更に有すること
を特徴とする請求項８に記載のデバイス共有システム。
前記クライアントは、前記セッション接続状態確認手段によって、他のクライアントからのセッション開始要求の有無を前記サーバから受信し、前記所定条件変更手段によって、当該セッション開始要求の有無に応じて前記所定条件を変更すること
を特徴とする請求項１４に記載のデバイス共有システム。
前記サーバは、セッション接続中でないクライアントからのセッション開始要求の有無の情報を管理し、前記第二の制御コマンドに対する応答に当該セッション開始要求の有無の情報を付加してセッション接続中のクライアントに送ること
を特徴とする請求項８に記載のデバイス共有システム。
前記サーバは、前記クライアントから送られてくる前記第一の制御コマンド及び前記第二の制御コマンドのパケットのヘッダを取り外して前記デバイスに送り、又、前記デバイスからの応答のパケットに対してヘッダを付加して前記クライアントへ送ること
を特徴とする請求項８に記載のデバイス共有システム。
ネットワークを介してサーバに接続されたデバイスをクライアントによって共有するデバイス共有方法であって、
前記クライアント全体を制御するとともに前記デバイスへのアクセスを指示する上位層からの指示に応じて第一の制御コマンドまたは第二の制御コマンドを生成する制御コマンド生成ステップと、
前記制御コマンド生成ステップで生成された前記第一の制御コマンドまたは前記第二の制御コマンドに基づき、前記サーバとのセッションを制御するセッション制御ステップと、
を実行し、
前記セッション制御ステップでは、
前記制御コマンド生成ステップによって前記第一の制御コマンドまたは前記第二の制御コマンドが生成されると前記サーバに対してセッション開始要求を送るセッション開始要求ステップと、
当該セッション開始要求に対する応答に基づき前記サーバとセッションを開始するセッション開始ステップと、
前記サーバとセッション接続中、前記第一の制御コマンドに基づきデバイスとの間でデータの入出力を行うデータ入出力ステップと、
前記サーバとセッション接続中、前記第二の制御コマンドを前記サーバに対して定期的に送り当該セッションの接続状態を確認するセッション接続状態確認ステップと、
前記サーバから受信した当該第二の制御コマンドに対する応答が所定条件を満たすとき、当該セッションを切断するセッション切断ステップと、
当該セッションの切断後、前記制御コマンド生成ステップで生成された前記第二の制御コマンドを前記サーバに対して送らず、当該第二の制御コマンドに対する応答を擬似生成して、前記上位層に通知する擬似応答ステップ
を実行することを特徴とするデバイス共有方法。
前記セッション開始要求ステップは、前記セッションの切断後、前記制御コマンド生成手段で生成される制御コマンドが前記第一の制御コマンドである場合、前記サーバに対してセッション開始要求を送るステップを実行すること
を特徴とする請求項１８に記載のデバイス共有方法。
前記セッション切断ステップの所定条件とは、前記第二の制御コマンドに対する成功応答が規定回数連続したか否かであること
を特徴とする請求項１８に記載のデバイス共有方法。
前記セッション切断ステップの所定条件とは、前記第二の制御コマンドに対する成功応答が規定時間連続したか否かであること
を特徴とする請求項１８に記載のデバイス共有方法。
前記セッション制御ステップは、更に、前記所定条件を変更する所定条件変更ステップを有すること
を特徴とする請求項１８に記載のデバイス共有方法。
前記セッション接続状態確認ステップにおいて、他のクライアントからのセッション開始要求の有無を前記サーバから受信するステップを更に実行し、前記所定条件変更ステップによって、当該セッション開始要求の有無に応じて前記所定条件の変更を実行すること
を特徴とする請求項２２に記載のデバイス共有方法。