JP4592242B2 - サーバ／クライアントシステム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明はサーバ／クライアントシステムに関し、特に、クライアント側のハードウエア資源を軽減したサーバ／クライアントシステムに関する。
【０００２】
【従来の技術】
図１は、従来のサーバ／クライアントシステムのハードウエア構成を概略的に示す図である。図において１００はサーバ、２００はパソコン相当のクライアントを示し、両者の間は通信回線３００によって接続されている。また、クライアント２００には、プリンタ、メモリカードリーダ、バーコードリーダ等のＩ／Ｏデバイス４００が接続回線５００を介して接続されている。
【０００３】
従来のサーバ／クライアントシステムにおけるサーバ１００は、ＣＰＵ１０１、メモリ１０２、ハードディスク１０３ａおよび１０３ｂ、回線制御部１０４を含んでいる。サーバ内のハードディスクは、一方に故障が生じた場合も他方でカバーできるように通常二重化（ミラーリング）されている。
【０００４】
クライアント２００は、ＣＰＵ２０１、メモリ２０２、ハードディスク２０３、回線制御部２０４、Ｉ／Ｏポート２０５を含んでいる。ハードディスク２０３内には、各種アプリケーションおよびデバイスドライバ、およびクライアント２００の動作を制御するオペレーションシステム（Ｏ／Ｓ）がソフトウエア２０６として組み込まれている。
【０００５】
従来のサーバ／クライアントシステムでは、図示する様に、アプリケーションはクライアント側において動作する構成になっており、そのため近年、Ｏ／Ｓやアプリケーションのコードサイズが大容量化し、またデバイスドライバの増加により、更に処理能力の高いハードウエア資源やより大容量の記憶装置を備えるクライアントが求められている。
【０００６】
しかしながら、ハードウエア資源として多用されるハードディスクは大容量化するに伴ってコストが上昇すると共に、故障の発生も多い。従って、製造コストの面のみならず、システム運用上のコスト面からもハードウエア資源の大容量化は好ましいものではない。従って、従来のアプリケーションやデバイスドライバの資産を有効活用しながらクライアント側での処理負担を軽減し、クライアントを軽量化することが求められている。
【０００７】
このため、サーバ１００においてアプリケーションを動作させ、クライアントとサーバ間で画面とキー入力を転送すれば、クライアント２００の処理負担は軽減され、それに伴ってハードウエアを軽量化することができる。Ｉ／Ｏデバイスはユーザの近く、即ちクライアントに接続されるのが普通であるため、デバイスドライバはクライアントに側に配置される。
【０００８】
この様に、アプリケーションをサーバ側に置き、一方クライアント側でデバイスドライバを動作させる場合、Ｉ／Ｏデバイス制御に関して以下の問題が生じる。
【０００９】
（１）クライアントのデバイスドライバは、コードサイズの大きいＯ／Ｓに依存している場合が多く、従ってデバイスドライバをクライアント側に置くと、クライアントの処理負担が大きくなり、デバイスドライバを動作させるのに必要なＯ／Ｓのための記憶装置が必要となってしまう。
（２）サーバ側に置いたアプリケーションと、クライアント側に置いたデバイスドライバ間でインターフェースが変わるため、デバイスドライバを作成しなおす必要が生じる。
（３）Ｉ／Ｏデバイスが複数種類ある場合、それぞれのデバイスドライバも、前記（２）の理由で作成しなおす必要が生じる。
（４）デバイスドライバの版数はクライアントの設置してある場所でしか確認することができない。
（５）クライアントＩ／Ｏデバイスの診断は、クライアントの設置してある場所でしか行うことが出来ない。
（６）クライアントのプラットフォームが変わる毎にデバイスドライバを作成しなおす必要が生じる。
【００１０】
以上の様に、アプリケーションをサーバ側で動作させ、デバイスドライバをクライアント側で動作させると、特に上記（１）、（２）、（３）の理由によりクライアントの軽量化および従来のアプリケーション、デバイスドライバ等の資産の有効活用は困難となる。更に、上記（４）、（５）、（６）に示す様に、システムの効率的な運用が難しい。
【００１１】
本発明は、前記の問題点に鑑みてなされたもので、従来のアプリケーション、デバイスドライバ等の資産を有効活用し、かつクライアント側のハードウエア資源を大幅に軽量化することが可能なサーバ／クライアントシステムを得ることをその主な目的とする。
【００１２】
前記目的を達成する本発明の１実施形態によれば、少なくとも１個のＩ／Ｏポートを有する少なくとも１個のクライアントを通信回線を介して１個のサーバに接続するサーバ／クライアントシステムにおいて、前記サーバ側に、前記Ｉ／Ｏポートを制御するためのデバイスドライバと、該デバイスドライバに対して前記Ｉ／Ｏポートと同一の機能を有するインターフェースを提供しかつ前記デバイスドライバからの入出力制御信号を前記クライアント側に送信し該クライアント側からのイベントを受信して前記デバイスドライバに通知するための仮想Ｉ／Ｏポートを設け、前記クライアント側に前記通信回線を介して前記仮想Ｉ／Ｏポートに接続されるデバイスハンドラを設け、該デバイスハンドラによって前記Ｉ／Ｏポートを制御する構成としたことを特徴とする、サーバ／クライアントシステムが提供される。
【００１３】
この様なサーバ／クライアントシステムでは、デバイスドライバと仮想Ｉ／Ｏポートによって、従来のサーバ／クライアントシステムにおけるデバイスドライバとＩ／Ｏポート間のインターフェースと同じインターフェースがサーバ側で実現されるので、従来のクライアント側で使用していたアプリケーションおよびデバイスドライバを全てサーバ側において動作させることが可能となる。これによってクライアント側のハードウエア資源を大幅に軽量化する事が可能となると共に、従来のアプリケーションおよびデバイスドライバの資産を変更せずそのままサーバ側で使用することができる。
【００１４】
更に、前記構成のサーバ／クライアントシステムにおいて、仮想Ｉ／Ｏポートにクライアントの通信回線上のアドレス、及び各Ｉ／Ｏポートを識別する機能を持たせることによって、複数の軽量化されたクライアントを１台のサーバによって一元管理することが可能となる。
【００１５】
また前記仮想Ｉ／Ｏポートにクライアント側のハードウエアの診断機能を付加することによって、複数のクライアントを管理するサーバにおいて、各クライアントのハードウエア診断を一元的に行うことが可能となる。
【００１６】
【発明の実施の形態】
図２は、本発明の１実施形態にかかるサーバ／クライアントシステムのハードウエア構成を示すブロック図である。図示する様に本実施形態のサーバ１は、ＣＰＵ１１、メモリ１２およびハードディスク１３ａ、１３ｂ等の記憶装置および回線制御部１４で構成されている。２重構造のハードディスク１３ａ、１３ｂ内には、従来クライアント側にあった各種アプリケーション、デバイスドライバおよび後述する仮想Ｉ／ＯポートおよびＯ／Ｓがソフトウエア１５として組み込まれている。
【００１７】
クライアント２は、ＣＰＵ２１、メモリ２２およびＲＯＭ２３等の記憶装置、回線制御部２４およびＩ／Ｏポート２５で構成されている。本システムでは、アプリケーションおよびデバイスドライバをサーバ側に置き、それらをサーバ側で動作させる構成を取っているため、ＲＯＭ２３内には、サーバ側のデバイスドライバから通信回線３を介して送信される信号をＩ／Ｏポート２５に入力可能な信号に変換するためのソフトウエア、即ちデバイスハンドラ、およびクライアント２全体を制御するための組込み用Ｏ／Ｓがソフトウエア２６として収納される。なお、デバイスハンドラの詳細な機能については、後述する。
【００１８】
本実施形態のクライアント２では、クライアント内でアプリケーションを動作させる必要がないので、デバイスハンドラおよびＯ／Ｓを含めたソフトウエア全体のコードサイズは従来のシステムに比べて遙に小さく、上述した様にＲＯＭ２３内に十分収納することができる。これによってクライアント内にハードディスクは不必要となる。
【００１９】
一般のサーバ／クライアントシステムにおいては、クライアント側の主な故障原因はハードディスクであり、従って本発明のシステムではハードディスクが不要となる事でシステムの信頼性が大きく向上する。
【００２０】
通信回線３としては、例えばＬＡＮ(Local Area Network)等を想定する。
【００２１】
図３は、図２に示すサーバ／クライアントシステムのソフトウエア構成を示す図面である。本実施形態のシステムでは、サーバ１内に各種アプリケーション１６、各種Ｉ／Ｏデバイス４を駆動するためのデバイスドライバ１７およびデバイスドライバ１７からの信号を通信回線３で伝送しうる信号に変換し、かつ通信回線３を介して入力された信号をデバイスドライバ１７に入力しうる信号に変換するための仮想Ｉ／Ｏポート１８およびこれらのソフトウエアを制御するＯ／Ｓ１９が設けられている。Ｏ／Ｓ１９は、これらのソフトウエアがクライアント２内に有った場合に使用されるＯ／Ｓと同じ物、例えばウインドウズ９８（商標）、ウインドウズＮＴ（商標）などの既存のＯ／Ｓを使用することができる。なお、アプリケーションおよびデバイスドライバも、既存のシステムにおいて使用されているものを使用することができることは勿論である。
クライアント２は、通信回線３を介して入力された信号をＩ／Ｏポート２５で認識しうる信号に変換し、かつＩ／Ｏポート２５からの信号を通信回線３で伝送しうる信号に変換するためのデバイスハンドラ２７を含む。本発明では、クライアント２側にコードサイズが大きいアプリケーションおよびデバイスドライバを含まず、ソフトウエアとしてはコードサイズが小さいデバイスハンドラ２７のみを含むので、これを制御するＯ／Ｓ２８は、極めて単純な構成の組込み用Ｏ／Ｓであって良い。
【００２２】
サーバ１内の仮想Ｉ／Ｏポート１８は、基本的に次の機能を有している。即ち、
（１）クライアント２側のＩ／Ｏポート２５と同一に機能するインターフェースを、その上位のデバイスドライバ１７に提供すること、
（２）上位のデバイスドライバ１７からの入出力制御信号をクライアント２のデバイスハンドラ２７に送信すること、およびデバイスハンドラ２７からのイベントを受信して上位のデバイスドライバ１７に通知すること、である。
【００２３】
また、クライアント２側のデバイスハンドラ２７の必要最低限の機能は、
（１）サーバ１の仮想Ｉ／Ｏポート１８から送信された入出力制御信号を受信し、Ｉ／Ｏポートに対して入力制御／出力制御を行い、かつＩ／Ｏポート２５からのイベントをサーバ１の仮想Ｉ／Ｏポート１８に送信することである。
【００２４】
本実施形態のサーバ／クライアントシステムでは、以上の様に、サーバ側に仮想Ｉ／Ｏポートを、クライアント２側にデバイスハンドラを設けたことにより、従来のアプリケーションおよびデバイスドライバを変更することなくサーバ側で動作させることが可能となり、クライアントのハードウエア資源が大幅に軽量化される。
【００２５】
以下に、本システムの更に詳細な構成およびその動作を、サーバ１内のアプリケーション１６とＩ／Ｏデバイス４間のデータフローを示す図４を用いて説明する。
【００２６】
まず、アプリケーション１６からＩ／Ｏデバイス４へのデータ入出力は以下の通りである。
（１）アプリケーション１６は入出力したいデータを含む入出力処理要求（１）をデバイスドライバ１７に対して行い、
（２）デバイスドライバ１７は入出力処理要求（１）に従い、仮想Ｉ／Ｏポート１８の入出力制御（２）を行う。
（３）仮想Ｉ／Ｏポート１８は入出力制御（２）を通信回線３上のデータに変換し、クライアント２側のデバイスハンドラ２７に入出力制御パケット（３）として送信する。
（４）デバイスハンドラ２７は入出力制御パケット（３）を受信すると、内容を解釈しＩ／Ｏポート２５の入出力制御（４）を行う。
（５）Ｉ／Ｏポート２５は入出力制御（４）を接続回線５上のデータ（５）に変換し、外部Ｉ／Ｏデバイス４に送信し、これを制御する。
【００２７】
以上によって、アプリケーションからＩ／Ｏデバイス４へ、入出力制御が実行される。
【００２８】
次に、Ｉ／Ｏデバイス４からアプリケーション１６へのイベントの通知について説明する。
まず、（６）Ｉ／Ｏデバイス４はイベント（制御信号線変化等）（６）を接続回線５上に出力する。
（７）デバイスハンドラ２７はＩ／Ｏポート２５からのイベント（７）を通信回線上のデータに変換し、仮想Ｉ／Ｏポート１８にイベントパケット（８）として送信する。
（８）仮想Ｉ／Ｏポート１８はイベントパケット（８）を受信すると、内容を解釈し、デバイスドライバ１７にイベント（９）を上げる。
（９）デバイスドライバ１７は、アプリケーション１６に対して、イベント（１０）を上げる。
【００２９】
以上が、本実施形態のサーバ／クライアントシステムにおけるアプリケーション１６とＩ／Ｏデバイス４間のデータフローである。
【００３０】
次に、本実施形態にかかるサーバ／クライアントシステムの動作シーケンスを、図５を用いて説明する。
【００３１】
サーバ１およびクライアント２に電源が投入されると、先ず、仮想Ｉ／Ｏポート１８とデバイスハンドラ２７間のコネクションが確立される。このコネクション確立は双方のネゴシエーションにより行われる。即ち、クライアント２側に電源が投入されると、デバイスハンドラ２７は通信回線上のコネクション確立要求のための接続要求（１１）（ブロードキャスト）を仮想Ｉ／Ｏポート１８に送信する。サーバ１に電源が投入されていて、仮想Ｉ／Ｏポート１８が起動していると、これに対するレスポンス（１２）が仮想Ｉ／Ｏポート１８よりデバイスハンドラ２７に出力される。レスポンス（１２）には、仮想Ｉ／Ｏポート１８の設定機能によって予め設定されたクライアント２の通信回線上のアドレス、クライアント２が持つ物理Ｉ／Ｏポートの種別、番号のマッピング情報が含まれる。デバイスハンドラ２７はこのレスポンス（１２）を受信すると、通信回線上のコネクションを確立し、マッピング情報に従って物理Ｉ／Ｏポートのマッピングを行い、これが完了するとマッピング完了通知（１３）を仮想Ｉ／Ｏポート１８に送信する。仮想Ｉ／Ｏポート１８はこの通知（１３）を受信すると、これに対するレスポンス（１４）を送信する。この時点で、仮想Ｉ／Ｏポート１８はデバイスドライバ１７からの制御を受け付ける事が可能となる。なお、この時点より以前にデバイスドライバ１７から制御信号が送信されると、仮想Ｉ／Ｏポート１８はエラー信号をデバイスドライバ１７に返す。
【００３２】
次に、アプリケーション１６からＩ／Ｏデバイス４へのデータ入出力について、そのシーケンスを説明する。なおこの場合のデータフローは、図４に示した通りである。
【００３３】
先ず、アプリケーション１６の入出力要求（１５）は、デバイスドライバ１７に受け付けられ、デバイスドライバ１７は仮想Ｉ／Ｏポート１８に入出力制御（１６）を行う。仮想Ｉ／Ｏポート１８は入出力制御（１６）を通信回線上のデータに変換し、これをデバイスハンドラ２７に入出力制御パケット（１７）として送信する。デバイスハンドラ２７は入出力制御パケット（１７）を受信すると、内容を解釈しＩ／Ｏポート２５の入出力制御（１８）を行う。Ｉ／Ｏポート２５は接続回線５上にデータ（１９）を出力する。
【００３４】
次に、Ｉ／Ｏデバイス４からアプリケーション１６へのイベントの通知について説明する。
【００３５】
Ｉ／Ｏデバイス４はイベント（制御信号変化等）（２０）を接続回線上に出力すると、デバイスハンドラ２７はＩ／Ｏポート２５からのイベント（２１）を通信回線上のデータに変換し、仮想Ｉ／Ｏポート１８にイベントパケット（２２）として送信する。仮想Ｉ／Ｏポート１８がイベントパケット（２２）を受信すると、内容を解釈し、デバイスドライバ１７にイベント（２３）を上げる。デバイスドライバ１７はアプリケーション１６に対してイベント（２４）を上げる。
【００３６】
図６は、仮想Ｉ／Ｏポート１８の機能を示すためのフローチャートである。なおこのフローチャートは、仮想Ｉ／Ｏポート１８の必要最低限の機能のみを示している。
【００３７】
仮想Ｉ／Ｏポート１８の内部の状態として、以下に示すものを想定する。即ち、
（１）待機：クライアント２側からの接続要求受信待ちの状態、
（２）完了通知待ち：クライアント２の物理Ｉ／Ｏポートのマッピング完了通知待ちの状態、
（３）接続：クライアント２の物理Ｉ／Ｏポートのマッピング完了通知受信後、デバイスドライバ１７からの制御を受け付けることが可能な状態、である。
仮想Ｉ／Ｏポートの前記各状態に対して、以下に示すイベントを想定する。即ち、
（４）接続要求受信：クライアント２からの接続要求受信のイベント、
（５）完了通知受信：クライアント２の物理Ｉ／Ｏポートのマッピング完了通知受信のイベント、
（６）入出力制御要求：デバイスドライバ１７からの入出力制御要求のイベント、
（７）イベントパケット受信：クライアント２からのイベントパケット受信のイベント、である。
【００３８】
以上の状態、およびイベントを参照して、以下に仮想Ｉ／Ｏポート１８の機能を説明する。
【００３９】
図６において、ステップＳ１で初期化処理を行って、仮想Ｉ／Ｏポート１８の状態を待機状態に設定する。次に、ステップＳ２でイベント取得する。この時、仮想Ｉ／Ｏポート１８の状態が待機状態であれば（ステップＳ３のＹes）、次にステップＳ４でイベントが接続要求受信であるか否かを判定する。イベントが接続要求受信で有る場合は（ステップＳ４のＹes）、ステップＳ５でデバイスハンドラ２７に対してレスポンスを送信し、ステップＳ６で状態を完了通知待ちとする。ステップＳ４でイベントが接続要求受信で無い場合（Ｎo ）、ステップＳ７で次に入力されるイベントが終了要求か否かを検出し、終了要求である場合（Ｙes）は、仮想Ｉ／Ｏポート１８の動作を終了する。一方、終了要求で無い場合は、ステップＳ２に戻って再びイベントを取得し、更にそれ以降のステップを実行する。
【００４０】
ステップＳ３で状態が待機では無い場合（Ｎｏ）は、ステップＳ８で状態が完了通知待ちであるか否かを判定する。完了通知待ち（ステップＳ８のＹes）の場合は、ステップＳ９においてイベントが完了通知受信であるか否かを判定する。完了通知受信の場合（ステップＳのＹes）は、ステップＳ１０においてレスポンスをデバイスハンドラ２７に送信し、接続状態に移行する（テップＳ１１）。ステップＳ９においてイベントが完了通知受信で無い場合（Ｎｏ）は、イベントが終了要求の場合を除いてステップＳ２に移動して再びイベントを取得する。
【００４１】
ステップＳ８で、状態が完了通知待ちでは無い場合（ステップＳ８のＮｏ）、ステップＳ１２で仮想Ｉ／Ｏポート１８の状態が接続状態であるか否かを判定する。接続状態の場合（ステップＳ１２のＹes）、ステップＳ１３でイベントが入出力制御要求であるか否かを判定し、Ｙesの場合、ステップＳ１４で入出力制御パケットをデバイスハンドラ２７に送信する。ステップＳ１３でイベントが入出力制御要求では無い場合（ステップＳ１３のＮｏ）、ステップＳ１５においてイベントがイベントパケット受信であるか否かを判定し、Ｙesの場合、受信したパケットをデバイスドライバ１７に上げる。ステップＳ１５でイベントパケット受信では無い場合（Ｎｏ）、ステップＳ７においてイベントの終了要求があるか否かを判定し、Ｙesの場合は処理を終了し、Ｎｏの場合はステップＳ２に移って以降の処理を続行する。
【００４２】
図７は、デバイスハンドラ２７の機能を示すフローチャートである。なお、このフローチャートはデバイスハンドラ２７の必要最低限の機能のみを示している。
【００４３】
デバイスハンドラ２７の内部状態としては、次の（１）〜（３）を想定する。即ち、
（１）待機：クライアント２の起動直後の状態、
（２）接続要求レスポンス待ち：接続要求送信後、サーバからのレスポンス待ちの状態、
（３）接続：物理Ｉ／Ｏポートのマッピング完了通知送信後、仮想Ｉ／Ｏポート１８からの入出力制御パケットを受け付けることが可能な状態、である。
更に、デバイスハンドラ２７の各状態に対して、（４）〜（７）のイベントを想定する。即ち、
（４）イベント無し：イベントが何も無いこと、
（５）接続要求レスポンス受信：接続要求送信後、サーバからのレスポンス受信のイベント、
（６）入出力制御パケット受信：サーバからの入出力制御パケット受信のイベント、および
（７）Ｉ／Ｏポートイベント：Ｉ／Ｏポート２５からのイベント、である。
【００４４】
次に、図７を参照して、デバイスハンドラ２７における処理手順を説明する。
【００４５】
先ず、ステップＳ２０において初期化処理を行って状態を待機とし、ステップＳ２１でイベントを取得する。次にステップＳ２２でイベントの状態が待機か否かを判定し、Ｙesの場合、ステップＳ２３においてイベントが無いことを確認する。イベントが無い場合（ステップＳ２３のＹes）、サーバ１の仮想Ｉ／Ｏポート１８に接続要求を送信し（ステップＳ２４）、状態を接続要求レスポンス待ちにする（ステップＳ２５）。次にイベントが終了要求であるか否かを判定し（ステップＳ２６）、終了要求で無い場合はステップＳ２１に移って以降のステップを再度実行する。
【００４６】
ステップＳ２２でデバイスハンドラ２７の状態が待機で無いと判定されると（ステップＳ２２のＮｏ）、ステップＳ２７において状態が接続要求レスポンス待ちであるか否かを判定する。Ｙesの場合、ステップＳ２８において、イベントが接続要求レスポンス受信であるか否かを判定し、Ｙesの場合、仮想Ｉ／Ｏポート１８に、物理Ｉ／Ｏポートマッピング完了通知を送信し、デバイスハンドラ２７の状態を接続にする（Ｓ３０）。
【００４７】
一方、ステップＳ２７で、デバイスハンドラ２７の状態が接続要求レスポンス待ちでは無い場合（Ｎｏ）、ステップＳ３１において状態が接続か否かを判定する。Ｙesの場合、ステップＳ３２においてイベントが入出力制御パケットの受信であるか否かを判定する。Ｙesの場合、ステップＳ３３において、Ｉ／Ｏポート２５に対し、入出力制御を行う。
【００４８】
ステップＳ３２でイベントが入出力制御パケット受信で無い場合、ステップＳ３４でイベントがＩ／Ｏポートイベントか否かを判定し、Ｙesの場合は、ステップＳ３５で仮想Ｉ／Ｏポートに対してこのイベントパケットを送信する。なお、ステップＳ３４でイベントがＩ／Ｏポートイベントで無い場合は、ステップＳ２６において、イベントが終了要求か否かを判定し、Ｙesの場合は処理を終了し、Ｎｏの場合はステップＳ２１に移動して以降のステップを再度実行する。
【００４９】
以上の様に、本発明の第１の実施形態にかかるサーバ／クライアントシステムでは、サーバ側に仮想Ｉ／Ｏポート１８を、クライアント側にデバイスハンドラ２７を設け、仮想Ｉ／Ｏポート１８の上位層であるデバイスドライバからの処理をデバイスハンドラ２７に転送し、このデバイスハンドラによってＩ／Ｏポート２５の制御を行い、かつＩ／Ｏポート２５からのイベントを仮想Ｉ／Ｏポート１８に転送する構成としたため、従来クライアント側で動作していたアプリケーションおよびデバイスドライバを、それらに変更を加えることなくサーバ１側で動作させることが可能となる。これによって、クライアント２側での処理負担は非常に軽減され、クライアント側にハードディスク等の大容量記憶装置の搭載が不要となる。
【００５０】
なお、図２、３に示す本実施形態のサーバ／クライアントシステムでは、仮想Ｉ／Ｏポート１８とデバイスドライバ１７との間のインターフェースとして、クライアント側にデバイスドライバを有する従来のサーバ／クライアントシステムにおいて使用されているインターフェースを採用している。
【００５１】
図８ａは、従来のシステムにおけるデバイスドライバ２１０とＩ／Ｏポート２０５（ハードウエア）間のインターフェース構成を示す図である。図示するように、デバイスドライバ２１０とＩ／Ｏポート２０５間には、Ｉ／Ｏポートデバイスドライバ２１１が存在し、ハードウエアの違いを吸収するために、デバイスドライバ２１０がＩ／Ｏポート２０５に対して行う操作は、抽象化されたコマンド３０となる。Ｉ／Ｏポートデバイスドライバ２１１はこのコマンド３０によってＩ／Ｏポート２０５（ハードウエア）を制御３１し、制御結果３２をＩ／Ｏポート２０５から受け取り、更に処理結果３３をデバイスドライバ２１０に返す。
【００５２】
図２、３に示す本実施形態のサーバ／クライアントシステムでは、図８ｂに示す様に、仮想Ｉ／Ｏポート１８が、図８ａに示すコマンド３０と処理結果３３のインターフェースをそのままデバイスドライバ１７に対して提供する構成としたものである。これによって、従来のシステムにおけるＯ／Ｓがデバイスドライバ２１０に提供するＡＰＩ（アプリケーションインターフェース）環境を、本実施形態のＯ／Ｓにおいてもデバイスドライバ１７に提供する事ができる。この結果本実施形態において、従来のデバイスドライバ２１０と同じデバイスドライバ１７を使用してＩ／Ｏデバイス４の制御を行うことが可能となったものである。
【００５３】
以上の様に本実施形態のサーバ／クライアントシステムでは、サーバ側で従来のデバイスドライバを変更せずそのまま使用することができ、既存の資産を有効活用することができる。
【００５４】
図９は、本発明の第２の実施形態の構成を示すブロック図である。本実施形態では、図示するように、１台のサーバ１に対して２台の本発明に従って軽量化されたクライアント２ａおよび２ｂが接続されている。なお、１個のサーバに対して接続されるクライアントの数は図示の例に限定されるものではなく、任意の複数個のクライアントが接続可能であることは言うまでもない。
【００５５】
図示の実施形態において、クライアント２ａはデバイスハンドラ２７ａとＩ／Ｏポート２５ａを有し、Ｉ／Ｏポート２５ａを介してＩ／Ｏデバイス４ａに接続されている。
クライアント２ｂはデバイスハンドラ２７ｂと２個のＩ／Ｏポート１、２を有し、それぞれＩ／Ｏデバイス４ｂ、Ｉ／Ｏデバイス４ｃに接続されている。
【００５６】
サーバ１において、アプリケーション１６ａ内にはクライアント２ａが使用するアプリケーション（１）とクライアント２ｂが使用するアプリケーション（２）が含まれる。デバイスドライバ１７ａ内は、クライアント２ａに接続されたＩ／Ｏデバイス４ａを駆動するためのデバイスドライバ（１）、クライアント２ｂに接続されたＩ／Ｏデバイス４ｂを駆動するためのデバイスドライバ（２）、Ｉ／Ｏデバイス４ｃを駆動するためのデバイスドライバ（３）が含まれる。
【００５７】
本実施形態において、仮想Ｉ／Ｏポート１８ａは、通信回線３を介してサーバ１に接続された各クライアント２ａ、２ｂおよび各Ｉ／Ｏポート２５ａ、２５ｂ、２５ｃを識別するために、仮想Ｉ／Ｏポート１８ａにおける仮想Ｉ／Ｏポート番号、各クライアント２ａ、２ｂの通信回線上のアドレス、各クライアントが持つ物理Ｉ／Ｏポートの種別、および物理Ｉ／Ｏポート番号を、それぞれ設定できる機能を有している。
【００５８】
図１０に図９のシステムにおける設定情報を示す。またこの設定情報は第５図中のレスポンス（１２）中に含まれる。
【００５９】
図１０に示す設定情報に従って、クライアント（１）２ａは、通信回線上のアドレス１で特定され、クライアント（２）２ｂはアドレス２で特定される。クライアント（１）２ａ中のＩ／Ｏポート２５ａは、物理Ｉ／Ｏポート種別がＣＯＭで、物理Ｉ／Ｏポート番号が１として特定される。クライアント（２）２ｂ中の２個のＩ／Ｏポート２５ｂ、２５ｃは、物理Ｉ／Ｏポート番号１、２で特定される。マッピング情報は、クライアントが持つ物理Ｉ／Ｏポートの種別、番号と仮想Ｉ／Ｏポート番号として設定された番号とを、１対１で対応させる。例えば、図１０の例では、クライアント（１）２ａの物理Ｉ／Ｏポート種別、番号＝ＣＯＭ１は、仮想Ｉ／Ｏポート番号１に対応する。更にクライアント（２）２ｂ中のＣＯＭ１は仮想Ｉ／Ｏポート番号２に、ＣＯＭ２は仮想Ｉ／Ｏポート番号３に、それぞれ１対１で対応する。
【００６０】
図９のシステムにおいて、クライアント（１）２ａに電源が投入されると、デバイスハンドラ２７ａが起動し、通信回線上のアドレス０（サーバ１）とアドレス１（クライアント２ａ）間で仮想Ｉ／Ｏポート１８ａとのコネクションが確立される。以降の仮想Ｉ／Ｏポート１８ａとデバイスハンドラ２７ａ間のデータ転送はこのコネクション上で行われる。デバイスドライバ１７ａからＩ／Ｏデバイス４ａに対する処理は、仮想Ｉ／Ｏポート１８ａ上でＩ／Ｏポート２５ａに対する処理として受け付けられ、処理電文にＩ／Ｏポート２５ａを示すＣＯＭ１が付加され、デバイスハンドラ２７ａに転送される。デバイスハンドラ２７ａでは、処理電文に付された情報ＣＯＭ１から、Ｉ／Ｏポート２５ａが識別され、これに対して処理が行われる。
【００６１】
一方、Ｉ／Ｏポート２５ａで発生したイベントには、デバイスハンドラ２７ａにおいて処理電文に１が付加され、仮想Ｉ／Ｏポート１８ａへパケット送信される。従って仮想Ｉ／Ｏポート１８ａでは、仮想Ｉ／Ｏポート番号１が認識され、仮想Ｉ／Ｏポート番号１に対応するデバイスドライバ（１）にイベントの発生が通知される。
【００６２】
クライアント２ｂに関しても、通信回線上のアドレス０とアドレス２間のコネクション上で、同様にして処理される。即ち、仮想Ｉ／Ｏポート１８ａとＩ／Ｏポート２５ｂ間は、仮想Ｉ／Ｏポート番号２とＣＯＭ１が１対１で対応し、仮想Ｉ／Ｏポート１８ａとＩ／Ｏポート２５ｃ間は、仮想Ｉ／Ｏポート番号３とＣＯＭ２とが１対１で対応する。従って、アドレス０とアドレス２間のコネクション上で往復される処理電文には、情報として仮想Ｉ／Ｏポート番号２、ＣＯＭ１あるいは仮想Ｉ／Ｏポート番号３、ＣＯＭ２が付加され、Ｉ／Ｏポート２５ｂまたはＩ／Ｏポート２５ｃが特定される。
【００６３】
本実施形態のサーバ／クライアントシステムでは、以上の様にして１個のサーバで、複数個のＩ／Ｏポートを有する複数個のクライアントを一元的に管理することができる。この場合、複数のクライアントに接続される複数種類のＩ／Ｏデバイスの各デバイスドライバは、従来のシステムにおけるデバイスドライバを変更せずに全てサーバ側で動作させることができるので、全てのデバイスドライバの版数をサーバ側で確認し、管理することができる。
【００６４】
図９におけるサーバ／クライアントシステムにおいて、仮想Ｉ／Ｏポート１８ａに診断指示機能と結果表示機能を付加することによって、全てのクライアントの診断をサーバ側で一元的に実行することができる。即ち、ユーザにより診断が開始されると、仮想Ｉ／Ｏポート１８ａは、診断コマンドを指定されたクライアント、例えばクライアント（１）２ａに送信し、クライアント２ａ中のデバイスハンドラ２７ａによってＩ／Ｏポート２５ａ、Ｉ／Ｏデバイス４ａおよびクライアントハードウエアの診察を実行させる。診断の結果は、仮想Ｉ／Ｏポート１８ａに送信され、診断結果として表示される。
【００６５】
図１１は、この診断機能において使用される診断メニューを例示する図である。本システムは、前述した様に仮想Ｉ／Ｏポート１８ａにおいて各クライアントの各Ｉ／Ｏポートを特定するための設定機能を有しているので、仮想Ｉ／Ｏポートユーザがこのシステムの診断を開始すると、指定されたＩ／Ｏデバイス、Ｉ／Ｏポート、クライアントの診断が行われる。まず、仮想Ｉ／Ｏポート１８ａは、診断コマンドを指定されたクライアント、例えばクライアント２ａに送信し、デバイスハンドラ２７ａは送信されたコマンドを受信すると直ちにそのレスポンスを仮想Ｉ／Ｏポート１８ａに返信する。従って仮想Ｉ／Ｏポート１８ａがこのレスポンスを受け取れなかった場合は、クライアント２ａの電源が切断されているか、あるいは何らかの異常が通信回線またはクライアント２ａにあることを意味する。この異常は、サーバ１側の例えばディスプレイにおいて表示される。
【００６６】
デバイスハンドラ２７ａが診断コマンドを受信すると、デバイスハンドラ２７ａはその内容を解釈し、例えばＩ／Ｏデバイス４ａの診断の場合、それがサポートする診断を行い、結果を仮想Ｉ／Ｏポート１８ａに送信する。例えばＩ／Ｏポート２７ａがシリアルポートである場合、内部折り返し診断等を実行し、結果を仮想Ｉ／Ｏポート１８ａに送信する。仮想Ｉ／Ｏポート１８ａが診断結果を受信すると、例えばサーバ側のディスプレイでその結果を表示する。
【００６７】
以上の診断処理は、仮想Ｉ／Ｏポート１８ａが各クライアント、各種Ｉ／Ｏポートを個々に識別しうるため、全てのクライアントの診断をサーバ側で一元的に実行することが可能となる。
【００６８】
図９に示す実施形態において、各クライアントのプラットフォーム（ハードウエア、Ｏ／Ｓ等）が変更された場合、それぞれのクライアントのデバイスハンドラは新たに作成しなおすことが必要であるが、一方、仮想Ｉ／Ｏポート１８ａと通信回線３上のコネクションの確立手順、仮想Ｉ／Ｏポート１８ａからの処理電文受信方法、仮想Ｉ／Ｏポート１８ａへのＩ／Ｏポート番号と種別を含む処理結果の電文フォーマット、イベントの電文フォーマットは変更する必要がない。さらに前記診断機能を有するシステムにおいても、診断コマンドの受信方法、レスポンスの電文フォーマット、診断結果の電文フォーマットも変更する必要はない。従って、各クライアントのプラットフォームが変更されても、サーバ側を変更する必要が無いので、クライアント側のプラットフォームの変更に柔軟に対処することが可能である。
【００６９】
【発明の効果】
以上に説明した様に、本発明によれば、従来のサーバ／クライアントシステムでクライアント側で使用されていたアプリケーション、デバイスドライバを変更することなくサーバ上に移すことが可能である。従って、クライアント側での処理負担が軽減され、その結果ハードウエア資源が大幅に軽量化される。従って、従来のＡＰＩ環境を維持しながら、軽量化されたクライアントを有するサーバ／クライアントシステムを構築することが可能となる。
また、クライアントのプラットフォームが変更された場合も、サーバ側に変更を要しないので、プラットフォームの変更に柔軟に対応することができる。
以上の様な本発明のサーバ／クライアントシステムは、１個のサーバで数個のクライアントを制御するＰＯＳシステム等に応用された場合、各クライアントが大幅に軽量化されるため、システム全体を構築するためのコストのみならず、システム運用上のコスト削減の効果が大きい。更に各プラットフォームの変更に柔軟に対処できるので、ＰＯＳシステムの設計変更時のコスト負担を大幅に削減できる。
【図面の簡単な説明】
本発明の前記およびその他の目的、特徴、利点等を、本発明の実施形態を示す添付図面と共に以下に詳細に説明するが、図中において、
【図１】 図１は、従来のサーバ／クライアントシステムの構成を示すブロック図、
【図２】 図２は、本発明の第１の実施形態にかかるサーバ／クライアントシステムのハードウエア構成を示すブロック図、
【図３】 図３は、図２に示すサーバ／クライアントシステムのソフトウエア構成を示すブロック図、
【図４】 図４は、図２および３に示すサーバ／クライアントシステムにおけるアプリケーションとＩ／Ｏデバイス間のデータフローを説明するための図、
【図５】 図５は、図２および３に示すサーバ／クライアントシステムにおける動作シーケンスを示す図、
【図６】 図６は、図２および３に示すサーバ／クライアントシステムに含まれる仮想Ｉ／Ｏポートの機能を説明するためのフローチャート、
【図７】 図７は、図２および３に示すサーバ／クライアントシステムに含まれるデバイスハンドラの機能を説明するためのフローチャート、
【図８】 図８ａは、従来のサーバ／クライアントシステムにおけるデバイスドライバとＩ／Ｏポート間のインターフェースを示す図、
図８ｂは、図２および３に示す本発明のサーバ／クライアントシステムにおけるデバイスドライバと仮想Ｉ／Ｏポート間のインターフェースを示す図、
【図９】 図９は、本発明の第２の実施形態にかかるサーバ／クライアントシステムの構成を示すブロック図、
【図１０】 図１０は、図９に示すサーバ／クライアントシステムに含まれる仮想Ｉ／Ｏポートの機能を説明するための図、および
【図１１】 図１１は、図９に示すサーバ／クライアントシステムに含まれる仮想Ｉ／Ｏポートのその他の機能を説明するための図である。

Claims (6)

1. 少なくとも１個のＩ／Ｏポートをそれぞれ有する第１及び第２のクライアントを通信回線を介して１個のサーバに接続するサーバ／クライアントシステムであって、
   前記サーバは、プロセッサと、第１及び第２のクライアントによって使用され、前記プロセッサにより実行されるアプリケーションと、前記Ｉ／Ｏポートを制御するための前記Ｉ／Ｏポートのそれぞれに対応するデバイスドライバと、回線制御部とを有し、
   前記プロセッサは、前記デバイスドライバを実行し、前記デバイスドライバの実行により出力された、前記Ｉ／Ｏポートの種別及び番号を識別する信号を含む第１及び第２の制御信号を、前記第１のクライアントの通信回線のアドレスに伝送する第１の伝送信号と前記第２のクライアントの通信回線のアドレスに伝送する第２の伝送信号とに変換し、且つ、前記第１および第２のクライアントのおのおのから前記通信回線を介して受け取った第３及び第４の伝送信号を、前記デバイスドライバの実行の入力情報として使用する第３及び第４の制御信号に変換し、
   前記回線制御部は、前記第１の伝送信号及び第２の伝送信号を、前記第１のクライアント及び第２のクライアントのアドレスに前記通信回線を介してそれぞれ送信し、且つ、前記第１のクライアント及び前記第２のクライアントから前記第３の伝送信号及び前記第４の伝送信号を前記通信回線を介してそれぞれ受信し、
   前記第１のクライアントは、前記第１の伝送信号を、前記Ｉ／Ｏポートで認識しうる信号に変換し、且つ、前記Ｉ／Ｏポートから受け取った信号を前記通信回線で伝送しうる前記第３の伝送信号に変換する、プロセッサを有し、
   前記第２のクライアントは、前記第２の伝送信号を、前記Ｉ／Ｏポートで認識しうる信号に変換し、且つ、前記Ｉ／Ｏポートから受け取った信号を前記通信回線で伝送しうる前記第４の伝送信号に変換する、プロセッサを有することを特徴とする、サーバ／クライアントシステム。
2. 前記第１又は第２のクライアントは、前記変換したＩ／Ｏポートで認識しうる信号に基づいて前記Ｉ／Ｏポートに対する入出力制御を行うことを特徴とする、請求項１に記載のサーバ／クライアントシステム。
3. 前記サーバは前記第１又は第２の伝送信号を入出力制御パケットとして前記通信回線を介して前記第１又は第２のクライアントに送信することを特徴とする、請求項１または２に記載のサーバ／クライアントシステム。
4. 前記第１又は第２のクライアントは前記Ｉ／Ｏポートを介して受信したＩ／Ｏポートイベントをイベントパケットとしての前記第３又は第４の伝送信号を前記通信回線を介して前記サーバに送信することを特徴とする、請求項１乃至３の何れか１項に記載のサーバ／クライアントシステム。
5. 前記サーバは、前記第１又は第２のクライアントのハードウエアの診断機能を有することを特徴とする、請求項１乃至４の何れか１項に記載のサーバ／クライアントシステム。
6. 前記通信回線はＬＡＮである、請求項１乃至５の何れか１項に記載のサーバ／クライアントシステム。

Images