JP4617440B2

JP4617440B2 - データ通信システムまたはその方法

Info

Publication number: JP4617440B2
Application number: JP2007259008A
Authority: JP
Inventors: 啓二奥間
Original assignee: Silex Technology Inc
Current assignee: Silex Technology Inc
Priority date: 2006-10-03
Filing date: 2007-10-02
Publication date: 2011-01-26
Anticipated expiration: 2027-10-02
Also published as: US7761646B2; US7647446B2; US20080082717A1; JP2008090847A; US20100058361A1

Description

等時性(アイソクロナス)データポートを持つＵＳＢ機器（Universal Serial Bus Device）をＰＣ（Personal Computer）と接続する場合に、ＵＳＢ機器とＰＣとを互いに遠くに離して設置することができない。一般的にＵＳＢ機器は、長くとも数メートルのケーブルを用いて、ＰＣに接続される。ＵＳＢ機器をアイソクロナスデータポートで、ＰＣからより長い距離を置いて配置するためには、ＵＳＢバスをネットワークケーブル、又は光ファイバーケーブルで置き換えるための装置があるが、これは１対１の接続であるため、ネットワークに接続することはできない（特許文献１参照）。

特開2002-542527号公報また、ネットワーククライアントからネットワークを介して、ＵＳＢ機器の接続された周辺装置サーバに対して、ＵＳＢ機器を制御する技術もある。本願の出願人である、サイレックス・テクノロジー株式会社による、ＵＳＢ機器サーバの以下のウエブサイトにおける考察を参照。

www.silex.jp/japan/products/network/what/index3.html（日本語）
www.silexamerica.com/us/products/network/what/index3.html（英語）
上記ＵＳＢ機器サーバは、特定の性質を備えている。図１に概略が示されているように、周辺機器ドライバモジュールは、ＩＲＰ（I/O Request Packet：入出力要求パケット）を、事前にネットワーククライアントにインストールされている周辺機器サーバドライバモジュールに送信する。周辺機器サーバドライバモジュールは、ＩＲＰをキューに記憶し、ＩＲＰの全部又は一部をカプセル化し、それをネットワークに渡す。ネットワーク通信の受信側の周辺機器サーバは、受信したカプセル化されたデータから送信されたデータを取り出す処理（デカプセル化）を行い、それによりデータを再構築して周辺機器に送信する。逆方向の応答データ通信は同様にカプセル化され、周辺機器から周辺機器サーバを介して、ネットワーク上で、周辺機器サーバドライバモジュールに送信される。周辺機器サーバドライバモジュールは、受信されたカプセル化データから応答データを取り出す（デカプセル化）。このとき、応答データは事前に記憶されたＩＲＰに記憶され、ＩＲＰは周辺機器ドライバモジュールに戻され、このキューエントリは削除される。この処理の結果として、ユーザは周辺機器サーバに接続された周辺機器を、あたかも、直接ネットワーククライアントに接続されたかのように使用できる。

しかし、上記したような、アイソクロナスデータポートを備える周辺機器がネットワークを介して、ネットワーククライアントに接続されている場合、以下のようないくつかの問題点が存在した。

ネットワーククライアント及び周辺機器は、ネットワークを介して互いに通信するため、周辺機器ドライバモジュールにより発行された要求は、ネットワークを介して周辺機器に送信され、その結果、周辺機器から周辺機器ドライバモジュールへ応答が送信されるのに時間がかかる。従来、アイソクロナスデータポートを備える周辺機器が周辺機器サーバを介してネットワークに接続されている場合、ネットワーククライアントに内蔵される周辺機器ドライバモジュールが、ネットワーククライアントに直接接続されていることを前提として接続が確立されるため、ＵＳＢ周辺機器がネットワークを介して使用された場合、要求に対する応答の遅延処理に問題があった。

かかる遅延の内容は、図１及び図２に示す通信シーケンス図を用いて示される。図１は、アイソクロナスデータの送信（アイソクロナスＯＵＴ）に関する、従来技術の通信シーケンスを示している。図１を参照すると、各々の矢印に付与された番号は、周辺機器サーバドライバモジュールによって各ＩＲＰに付与されたフレーム番号である。図示のごとく、周辺機器ドライバモジュールは、まずフレーム（１）（２）（３）に対応するＩＲＰをまとめて発行し、これらを周辺機器サーバドライバモジュールに送信する。発行されたＩＲＰの数は一般的には、周辺機器サーバドライバモジュールによって決定されるのではなく、ネットワーククライアントのオペレーティングシステムに組み込まれているドライバなど、外部要因により決定される。次に、発行されたＩＲＰを受け取った周辺機器サーバドライバモジュールは、ＩＲＰに含まれるデータをカプセル化し、ネットワークを介して周辺機器サーバに送信する。この時点で、周辺機器サーバドライバモジュールは、送信されたＩＲＰをキューに記憶する。

周辺機器サーバは、受信したデータが周辺機器で処理されるよう、周辺機器に送信する。データ処理が完了すると、周辺機器サーバは周辺機器サーバドライバモジュールに、データ処理が完了したことを通知し、この通知を検出した周辺機器サーバドライバモジュールは、キューに記憶されたＩＲＰを完了する。かかる手法によるＩＲＰの完了の結果により、周辺機器ドライバモジュールは次に新たなＩＲＰを発行してもよい。通常の動作では、周辺機器ドライバモジュールは以前発行したＩＲＰが完了するまでは、新たなＩＲＰは発行しない。

図１では、周辺機器サーバドライバモジュールは、処理はフレーム（１）について完了することを示す、フレームＧ（１）を周辺機器サーバから受け取り、フレームＧ（１）のＩＲＰが完了する。その後、新たなＩＲＰフレーム（４）が、周辺機器ドライバモジュールから発行される。かかる通信方法は、周辺機器が直接ネットワーククライアントに接続されている場合には、問題を生じさせない一方で、ＵＳＢ周辺機器がネットワークを介して接続されている場合、フレームＧ（１）により示される完了の遅れにより、次のＩＲＰフレーム（４）発行が遅れ、周辺機器へのデータ送信の遅延が結果として生じる。

図２は、アイソクロナスデータの受信（アイソクロナスＩＮ）に関する、従来技術の通信シーケンスを示している。基本的な通信フローは、上述したアイソクロナスＯＵＴの通信フローと類似する一方で、これは本件に記載されたアイソクロナスＩＮシーケンスであり、従って、周辺機器ドライバモジュールから発行されたＩＲＰはデータに対する要求であり、受信データはフレームＧ（１）からフレームＧ（５）に含まれている。図２から明らかなように、周辺機器に対するデータ要求であるフレーム（４）、（５）は、フレームＧ（１）、Ｇ（２）のＩＲＰが各々完了するまでは、発行されない。この場合においても、アイソクロナスＯＵＴの場合と同様に、ネットワークにおける遅延により、フレームＧ（１）、Ｇ（２）の到着が遅れ、そのことが次のＩＲＰであるフレームＧ（４）、Ｇ（５）の発行に遅延を生じさせ、最終的には周辺機器ドライバモジュールにより受け取られるべきフレームＧ（４）、Ｇ（５）のデータに遅延が生じる。

また、アイソクロナスデータ転送は、周辺機器が直接ネットワーククライアントに接続されている場合、データが転送されるバスのフレームの単位の時間で管理されるため、タイミングを管理するのは、ネットワーククライアント自身である。

しかし、アイソクロナスデータポートを備える周辺機器が周辺機器サーバに接続されると、たとえアイソクロナスデータがより早期に転送される準備が整っていても、周辺機器が従うタイミングは、周辺機器サーバから与えられ、結果として、ネットワーククライアントと周辺機器サーバは各々、ベースの異なるクロックを内部に保持することになる。このため、時間はミリ秒ごとの同期化ができず、従ってアイソクロナスデータ転送を管理するタイミングが、ネットワーククライアントと周辺機器サーバの間でずれる、という問題があった。

かかる問題は、アイソクロナスデータ転送を備えるＵＳＢ機器のみならず、特定のコンピュータ間において、開始されるべき時間に基づいて、アイソクロナスデータを管理し、かつ処理する周辺機器においても発生する。

本明細書に記載され、又は以前から当業者に公知の技術及び実践の他の態様も、本発明を理解するのに有用であろう。

本件発明は、上記問題を軽減または解決し、周辺機器サーバを利用する特定のコンピュータ間におけるアイソクロナスデータ転送を通して、周辺機器の使用を促進することを目的とする。

１）本発明にかかる等時性出力転送を行うデータ通信システムは、Ａ）等時性通信規格で通信を行う１または２以上の周辺機器、Ｂ）前記１または２以上の周辺機器が接続されるとともに、クライアントコンピュータがネットワーク接続された周辺機器サーバであって、いずれかの周辺機器が特定されたデータが前記クライアントコンピュータから与えられると、等時性通信規格にて、前記周辺機器に送信するとともに、当該送信したデータに対する応答データを、当該クライアントコンピュータに前記ネットワークを介してカプセル化して送信する周辺機器サーバ、Ｃ）前記周辺機器との間でデータを送受信するコンピュータであって、以下の手段c1),c2)を備えたクライアントコンピュータ、c1)入出力要求パケットデータを出力し、これに対する応答データを受け取ると、次の入出力要求パケットデータを出力する周辺機器制御手段、c2)前記周辺機器制御手段が出力した入出力要求パケットデータをカプセル化し、前記周辺機器サーバにネットワーク送信を行い、前記周辺機器サーバから、カプセル化された応答データを受け取ると、これをデカプセル化して前記入出力要求パケットデータに対応する応答データとして前記周辺機器制御手段に与える周辺機器サーバ制御手段、Ｄ）を備えた等時性出力転送を行うデータ通信システムにおいて、Ｅ）前記周辺機器サーバ制御手段は、前記周辺機器制御手段からの入出力要求パケットデータを前記周辺機器サーバに送信してから所定時間経過するか否か判断し、所定時間経過しても前記入出力要求パケットデータに対応する応答データを前記周辺機器サーバより受け取らなかった場合には、前記入出力要求パケットデータに対応するダミー応答データを前記周辺機器制御手段に与えるダミー応答出力手段を備えている。

したがって、入出力要求パケットデータを出力し、これに対する応答データを受け取ると、次の入出力要求パケットデータを出力する周辺機器制御手段であっても、前記周辺機器制御手段に次の入出力要求パケットデータをダミー配信することができる。これにより、前記周辺機器サーバを介して前記周辺機器によるアイソクロナスアウトのネットワーク通信が可能となる。

２）本発明にかかる等時性入力転送を行うデータ通信システムは、Ａ）等時性通信規格で通信を行う１または２以上の周辺機器、Ｂ）前記１または２以上の周辺機器が接続されるとともに、クライアントコンピュータがネットワーク接続された周辺機器サーバであって、いずれかの周辺機器が特定されたデータが前記クライアントコンピュータから与えられると、等時性通信規格にて、前記周辺機器に送信するとともに、当該送信したデータに対する応答データを、当該クライアントコンピュータに前記ネットワークを介してカプセル化して送信する周辺機器サーバ、Ｃ）前記周辺機器との間でデータを送受信するコンピュータであって、以下の手段c1),c2)を備えたクライアントコンピュータ、c1)入出力要求パケットデータを出力し、これに対する応答データを受け取ると、次の入出力要求パケットデータを出力する周辺機器制御手段、c2)前記周辺機器制御手段が出力した入出力要求パケットデータをカプセル化し、前記周辺機器サーバにネットワーク送信を行い、前記周辺機器サーバから、カプセル化された応答データを受け取ると、これをデカプセル化して前記入出力要求パケットデータに対応する応答データとして前記周辺機器制御手段に与える周辺機器サーバ制御手段、Ｄ）を備えた等時性入力転送を行うデータ通信システムにおいて、Ｅ）前記周辺機器サーバ制御手段は、前記周辺機器制御手段からの入出力要求パケットデータを前記周辺機器サーバに送信してから所定時間経過するか否か判断し、所定時間経過しても前記周辺機器サーバに送信すべき次の入出力要求パケットを前記周辺機器制御手段から受け取らなかった場合には、ダミーの入出力要求パケットデータを前記周辺機器サーバに与えるダミー要求出力手段を備えている。

このように、前記入出力要求パケットデータを送信後、所定時間経過しても前記周辺機器サーバに送信すべき次の入出力要求パケットを前記周辺機器制御手段から受け取らなかった場合には、ダミーの入出力要求パケットデータを前記周辺機器サーバに与える。したがって、入出力要求パケットを出力し、これに対する応答データを受け取ると、次の入出力要求パケットを出力する等時性通信規格で通信を行う周辺機器であっても、前記周辺機器サーバを介して前記周辺機器のアイソクロナスインのネットワーク通信が可能となる。

３）本発明にかかる等時性出力転送を行うデータ通信システムにおいては、前記周辺機器サーバ制御手段は、さらに、前記周辺機器サーバから前記入出力要求パケットデータに対応する応答データを受け取るまでは、前記ダミー応答データに対して前記周辺機器制御手段から次の入出力要求パケットデータが与えられても、この入出力要求パケットデータの前記周辺機器サーバへの送信を留保する留保手段、を有しており、
前記周辺機器サーバ制御手段は、前記ダミー応答データを前記周辺機器制御手段に与えてから所定時間経過したか否か判断し、所定時間経過しても前記入出力要求パケットデータに対応する応答データを前記周辺機器サーバより受け取らなかった場合には、前記周辺機器制御手段に前記ダミー応答データを与える処理を前記周辺機器サーバから応答データを受け取るまで繰り返す。
このように、前記ダミー応答データを与えつつ、入出力要求パケットデータを送信後、前記周辺機器制御手段から次の入出力要求パケットデータが与えられると、これを、前記周辺機器サーバに送信しないという処理を、前記周辺機器サーバからの入出力要求パケットデータに対応する応答データを受け取るまで繰り返すことにより、所定時間内に前記応答データを受け取らないと、タイムアウト等の処理を行う等時性通信規格で通信を行う周辺機器であっても、前記周辺機器サーバを介したネットワーク通信が可能となる。

４）本発明にかかる等時性入力転送を行うデータ通信システムにおいては、前記周辺機器サーバ制御手段は、前記周辺機器制御手段からの入出力要求パケットデータを前記周辺機器サーバに送信してから所定時間経過するか否か判断し、所定時間経過しても前記入出力要求パケットデータに対応する応答データを前記周辺機器サーバより受け取らなかった場合には、前記入出力要求パケットデータに対応するダミー応答データを前記周辺機器制御手段に与えるダミー応答出力手段、前記周辺機器サーバから前記入出力要求パケットデータに対応する応答データを受け取るまでは、前記ダミー応答データに対して前記周辺機器制御手段から次の入出力要求パケットデータが与えられても、この入出力要求パケットデータの前記周辺機器サーバへの送信を留保する留保手段、を有しており、前記周辺機器サーバ制御手段は、前記ダミー応答データを前記周辺機器制御手段に与えてから所定時間経過したか否か判断し、所定時間経過しても前記入出力要求パケットデータに対応する応答データを前記周辺機器サーバより受け取らなかった場合には、前記周辺機器制御手段に前記ダミー応答データを与える処理を前記周辺機器サーバから応答データを受け取るまで繰り返す。
このように、前記ダミー応答データを与えつつ、入出力要求パケットデータを送信後、前記周辺機器制御手段から次の入出力要求パケットデータが与えられると、これを、前記周辺機器サーバに送信しないという処理を、前記周辺機器サーバからの入出力要求パケットデータに対応する応答データを受け取るまで繰り返すことにより、所定時間内に前記応答データを受け取らないと、タイムアウト等の処理を行う等時性通信規格で通信を行う周辺機器であっても、前記周辺機器サーバを介したネットワーク通信が可能となる。

５）本発明にかかる等時性出力通信を行うデータ通信システムまたは等時性入力通信を行うデータ通信システムにおいては、前記留保手段は前記入出力要求パケットデータを送信した時系列順に記憶しており、前記ダミー応答制御手段は、前記ダミー応答データを送ると、前記周辺機器サーバから応答データを受け取るまで、前記応答待ち通信のうち、送信時が古いものを削除するとともに、残っている応答待ち通信の順位を繰り上げる。したがって、記憶手段の容量を所定量の範囲に保つことができる。
前記ダミー応答データをエラーメッセージとしてもよい。これにより、アイソクロナスイン通信においても、つぎの要求を、前記周辺機器制御プログラムが発することができる。

６）本発明にかかる周辺機器サーバ制御プログラムは、等時性データ通信でデータ通信を行う周辺機器が接続された周辺機器サーバとの間でデータ転送するためのクライアントコンピュータの周辺機器サーバ制御プログラムであって、
前記クライアントコンピュータには、入出力要求パケットデータを出力した後、これに対する応答データを受け取ると、次の入出力要求パケットデータを出力する周辺機器制御プログラムがインストールされており、前記クライアントコンピュータに以下の手段を実現させるための周辺機器サーバ制御プログラムである。前記周辺機器制御プログラムから与えられた入出力要求パケットデータをカプセル化し、カプセル化した入出力要求パケットデータを前記周辺機器サーバにネットワーク送信する送信手段、前記周辺機器サーバからネットワーク送信された前記入出力要求パケットデータに対応する応答データを受信すると、前記周辺機器制御プログラムに与える受信手段、前記周辺機器制御プログラムからの入出力要求パケットデータを前記送信手段によって前記周辺機器サーバに送信してから、所定時間経過したか否か判断する判断手段、前記所定時間経過しても前記入出力要求パケットデータに対応する応答データを前記周辺機器サーバより受け取らなかった場合には、前記入出力要求パケットデータに対応するダミー応答データを前記周辺機器制御プログラムに与えるダミー応答出力手段。
このように、前記要求を送信後、所定時間経過すると、ダミー応答データを前記周辺機器制御プログラムに与えることにより、応答データを受け取らない限りつぎの要求をおこなわない等時性通信規格で通信を行う周辺機器制御プログラムをタイムアウト等の処理から防ぐことができる。これにより、前記周辺機器サーバを介して前記周辺機器のアイソクロナスアウトのネットワーク通信が可能となる。

７）本発明にかかる周辺機器サーバ制御プログラムは、さらに、前記周辺機器サーバとの間のネットワークの混雑度を計測する混雑度計測手段、前記計測された混雑度に応じて、前記ダミー応答の出力タイミングを変更する変更手段、をクライアントコンピュータにより、さらに実現させるためのプログラムである。したがって、混雑度に応じて、次の要求を配信するタイミングを制御することができる。

８）本発明にかかる周辺機器サーバ制御プログラムは、等時性データ通信でデータ通信を行う周辺機器が接続された周辺機器サーバとの間でデータ転送するためのクライアントコンピュータの周辺機器サーバ制御プログラムであって、前記クライアントコンピュータには、入出力要求パケットデータを出力し、これに対する応答データを受け取ると、次の入出力要求パケットデータを出力する周辺機器制御プログラムがインストールされており、前記クライアントコンピュータに以下の手段を実現させるための周辺機器サーバ制御プログラム。前記周辺機器制御プログラムから与えられた入出力要求パケットデータをカプセル化し、カプセル化した入出力要求パケットデータを前記周辺機器サーバにネットワーク送信する送信手段、前記周辺機器サーバからネットワーク送信された前記入出力要求パケットデータに対応する応答データを受信すると、前記周辺機器制御プログラムに与える受信手段、前記周辺機器制御プログラムからの入出力要求パケットデータを前記送信手段によって前記周辺機器サーバに送信してから、所定時間経過したか否か判断する判断手段、前記所定時間経過しても前記周辺機器サーバに送信すべき次の入出力要求パケットを前記周辺機器制御手段から受け取らなかった場合には、ダミーの入出力要求パケットデータを前記周辺機器サーバに与えるダミー要求出力手段。

このように、前記要求を送信後、所定時間経過すると、ダミーの入出力要求パケットデータを前記周辺機器サーバに与えることにより、入出力要求パケットデータを受け取らない限り、これに対する応答データを応答しない等時性通信規格で通信を行う周辺機器であっても、応答データを前記周辺機器制御手段に配信することができる。これにより、前記周辺機器サーバを介して前記周辺機器のアイソクロナスインのネットワーク通信が可能となる。

９）本発明にかかる周辺機器サーバ制御プログラムにおいては、前記ダミー要求出力手段は、直前に前記周辺機器サーバに送った入出力要求パケットデータをダミーの入出力要求パケットデータとして、前記周辺機器サーバに与える。したがって、入出力要求パケットデータを受け取らない限り、応答しない等時性通信規格で通信を行う周辺機器であっても、前記応答データを前記周辺機器制御手段に配信することができる。これにより、前記周辺機器サーバを介して前記周辺機器のアイソクロナスインのネットワーク通信が可能となる。

１０）本発明にかかる周辺機器サーバ制御プログラムにおいては、前記周辺機器サーバとの間のネットワークの混雑度を計測する混雑度計測手段、前記計測された混雑度に応じて、前記ダミー応答の出力タイミングを変更する変更手段をクライアントコンピュータにより、さらに実現させるためのプログラムである。したがって、混雑度に応じて、次の要求を配信するタイミングを制御することができる。

１１）本発明にかかる通信装置は、等時性データ通信でデータ通信を行う周辺機器が接続された周辺機器サーバとの間でデータ転送する通信装置であって、1)前記周辺機器サーバに対して入出力要求パケットデータを出力し、これに対する応答データを受け取ると、次の入出力要求パケットデータを出力する周辺機器制御手段、2)前記周辺機器制御手段が出力した入出力要求パケットデータをカプセル化し、前記周辺機器サーバにネットワーク送信を行い、前記周辺機器サーバから、カプセル化された応答データを受け取ると、これをデカプセル化して前記入出力要求パケットデータに対応する応答データとして前記周辺機器制御手段に与える周辺機器サーバ制御手段、を備え、前記周辺機器サーバ制御手段は、前記周辺機器制御手段からの入出力要求パケットデータを前記周辺機器サーバに送信してから所定時間経過するか否か判断し、所定時間経過しても前記入出力要求パケットデータに対応する応答データを前記周辺機器サーバより受け取らなかった場合には、前記入出力要求パケットデータに対応するダミー応答データを前記周辺機器制御手段に与えるダミー応答出力手段を有する。

このように、前記入出力要求パケットデータを送信後、所定時間経過すると、ダミー応答データを前記周辺機器制御手段に与えることにより、前記周辺機器制御手段は応答データを受け取らない限り、次の要求を配信しない等時性通信規格で通信を行う周辺機器であっても、前記周辺機器制御手段から、次の要求を配信することができる。これにより、前記周辺機器サーバを介して前記周辺機器によるアイソクロナスアウトのネットワーク通信が可能となる。

１２）本発明にかかる通信装置は、等時性データ通信でデータ通信を行う周辺機器が接続された周辺機器サーバとの間でデータ転送する通信装置であって、1)前記周辺機器サーバに入出力要求パケットデータを出力し、これに対する応答データを受け取ると、次の入出力要求パケットデータを出力する周辺機器制御手段、2)前記周辺機器制御手段が出力した入出力要求パケットデータをカプセル化し、前記周辺機器サーバにネットワーク送信を行い、前記周辺機器サーバから、カプセル化された応答データを受け取ると、これをデカプセル化して前記入出力要求パケットデータに対応する応答データとして前記周辺機器制御手段に与える周辺機器サーバ制御手段、を備え、前記周辺機器サーバ制御手段は、前記周辺機器制御手段からの入出力要求パケットデータを前記周辺機器サーバに送信してから所定時間経過するか否か判断し、所定時間経過しても前記周辺機器サーバに送信すべき次の入出力要求パケットを前記周辺機器制御手段から受け取らなかった場合には、ダミーの入出力要求パケットデータを前記周辺機器サーバに与えるダミー要求出力手段を有する。

このように、前記入出力要求パケットデータを送信後、所定時間経過すると、ダミー要求を前記周辺機器サーバに与えることにより、入出力要求パケットデータを受け取らない限り、応答しない等時性通信規格で通信を行う周辺機器であっても、応答データを前記周辺機器制御手段に配信することができる。これにより、前記周辺機器サーバを介して前記周辺機器のアイソクロナスインのネットワーク通信が可能となる。

１３）本発明にかかるネットワーク通信方法は、等時性通信規格で通信を行う１または２以上の周辺機器を、クライアントコンピュータがネットワーク接続された周辺機器サーバに接続して、いずれかの周辺機器が特定されたデータが前記クライアントコンピュータから与えられると、等時性通信規格にて、前記周辺機器に送信するとともに、当該送信したデータに対する応答データを、当該クライアントコンピュータに前記ネットワークを介してカプセル化して送信するネットワーク通信方法であって、前記クライアントコンピュータは、1)入出力要求パケットデータを出力し、これに対する応答データを受け取ると、次の入出力要求パケットデータを出力する周辺機器制御手段が出力した入出力要求パケットデータをカプセル化して前記周辺機器サーバにネットワーク送信を行い、2)前記周辺機器サーバから、カプセル化された応答データを受け取ると、これをデカプセル化して前記入出力要求パケットデータに対応する応答データとして前記周辺機器制御手段に与え、3)前記周辺機器制御手段からの入出力要求パケットデータを前記周辺機器サーバに送信してから所定時間経過するか否か判断し、所定時間経過しても前記入出力要求パケットデータに対応する応答データを前記周辺機器サーバより受け取らなかった場合には、前記入出力要求パケットデータに対応するダミー応答データを前記周辺機器制御手段に与える。

このように、前記入出力要求パケットデータを送信後、所定時間経過すると、ダミー応答データを前記周辺機器制御手段に与えることにより、前記周辺機器制御手段は応答データを受け取らない限り次の要求を配信しない等時性通信規格で通信を行う周辺機器であっても、前記周辺機器制御手段から、次の要求を配信することができる。これにより、前記周辺機器サーバを介して前記周辺機器によるアイソクロナスアウトのネットワーク通信が可能となる。

１４）本発明にかかるネットワーク通信方法は、等時性通信規格で通信を行う１または２以上の周辺機器を、クライアントコンピュータがネットワーク接続された周辺機器サーバに接続して、いずれかの周辺機器が特定されたデータが前記クライアントコンピュータから与えられると、等時性通信規格にて、前記周辺機器に送信するとともに、当該送信したデータに対する応答データを、当該クライアントコンピュータに前記ネットワークを介してカプセル化して送信するネットワーク通信方法であって、前記クライアントコンピュータは、1)入出力要求パケットを出力し、これに対する応答データを受け取ると、次の入出力要求パケットを出力する周辺機器制御手段が出力した入出力要求パケットデータをカプセル化し、これを前記周辺機器サーバにネットワーク送信を行い、2)前記周辺機器サーバから、カプセル化された応答データを受け取ると、これをデカプセル化して前記入出力要求パケットデータに対応する応答データとして前記周辺機器制御手段に与え、3)前記周辺機器制御手段からの入出力要求パケットデータを前記周辺機器サーバに送信してから所定時間経過するか否か判断し、所定時間経過しても前記周辺機器サーバに送信すべき次の入出力要求パケットを前記周辺機器制御手段から受け取らなかった場合には、ダミーの入出力要求パケットデータを前記周辺機器サーバに与える。

このように、前記要求を送信後、所定時間経過すると、ダミーの入出力要求パケットデータを前記周辺機器サーバに与えることにより、要求を受け取らない限り、応答しない等時性通信規格で通信を行う周辺機器であっても、応答データを前記周辺機器制御手段に配信することができる。これにより、前記周辺機器サーバを介して前記周辺機器のアイソクロナスインのネットワーク通信が可能となる。

１５）本発明にかかるプログラムは、前記混雑度計測手段が計測した混雑度が、所定の混雑度を超えた場合には、さらに、下記の手段による制御を行うためのプログラムである。前記判断手段による前記所定時間経過した旨の判断が与えられると、ダミー応答データを前記周辺機器制御プログラムに与え、前記ダミー応答データに対して、前記周辺機器制御プログラムから、次の入出力要求パケットデータが与えられると、これを、前記周辺機器サーバに送信することなく記憶するステップを前記周辺機器サーバから応答データを受け取るまで繰り返す繰り返し手段。

したがって、混雑度計測手段が計測した混雑度が、所定の混雑度を超えるか否かで処理を変更することができる。

１６）本発明にかかる等時性入力通信を行うデータ通信システムまたは通信装置においては、前記ダミー要求出力手段は、直前に前記周辺機器サーバに送った入出力要求パケットデータをダミーの入出力要求パケットデータとして、前記周辺機器サーバに与える。
したがって、入出力要求パケットデータを受け取らない限り、応答しない等時性通信規格で通信を行う周辺機器であっても、前記応答データを前記周辺機器制御手段に配信することができる。これにより、前記周辺機器サーバを介して前記周辺機器のアイソクロナスインのネットワーク通信が可能となる。

実施形態においては、「要求を送信後、所定時間経過する」を計測するのに、送信時から所定時間経過した所定時刻（相対または絶対時刻）を記憶しておき、前記所定時刻になると、ダミー通信を与えるようにしたが、要求を送信後、所定時間経過したか否かを計測できれば、公知のどの様な方法をも用いることができる。

「周辺機器制御手段」とは、実施形態では、周辺機器ドライバモジュール４０２によるＣＰＵの処理が該当する。

「周辺機器サーバ制御手段」とは、実施形態では、周辺機器サーバドライバモジュール４０４によるＣＰＵの処理が該当する。

「ダミー応答出力手段」とは、実施形態では、周辺機器ドライバモジュール４０２にダミー応答を与えるＣＰＵの処理（第１実施形態ではステップ１３０４〜１３０８）、（第３実施形態ではステップ１９０６〜１９１０）が該当する。

「ダミー要求出力手段」とは、実施形態では、周辺機器ドライバモジュール４０２によるＣＰＵの処理が該当する。

「留保手段」とは、実施形態では、ステップ１８０６によるＣＰＵの処理が該当する。

「周辺機器サーバ制御プログラム」とは、実施形態では、周辺機器サーバドライバモジュール４０４が該当する。

「周辺機器制御プログラム」とは、実施形態では、周辺機器ドライバモジュール４０２が該当する。

「送受信制御手段」とは、周辺機器サーバドライバモジュール４０４によるＣＰＵの処理のうち、ステップ１９０２，１９０４が該当する。

「通信装置」「ダミー通信処理機能付き通信装置」とは、クライアント３０４が該当する。

本発明のいくつかの実施形態は、アイソクロナス入力通信を促進する方法を含んでおり、ＵＳＢ周辺装置などの少なくとも一つの周辺装置について第１の通信を周辺装置ドライバから受信するステップと、周辺装置に対して、ネットワークを介して前記第１の通信からのデータを送信するステップと、周辺装置ドライバから第２の通信を受信することなく、所定間隔が経過したことを記録するステップと、ダミーの通信を生成し、かつそれをネットワークを介して周辺装置に送信し、それにより周辺装置に対する通信のアイソクロナスシーケンスの送信を維持するステップ等を有する。ダミーの通信を生成するステップでは、周辺装置ドライバから直近に受信した通信からのダミーの通信データにコピーすることができる。

いくつかの実施形態では、前記方法は、ダミーの通信に応答する応答通信をネットワークを介して受信し、周辺装置ドライバに前記応答通信からのデータを送信するステップを含む。

いくつかの実施形態では、前記方法は、周辺装置サーバドライバモジュール内に、周辺装置ドライバモジュールからのデータを、当該データを遠隔周辺装置に送信するのに代えて保持するステップと、送信されたデータに応答して、周辺装置からの通信を受信した後に、周辺装置ドライバモジュールに、保持されたデータを送り戻すステップを含む。

いくつかの実施形態では、ネットワークを介して送信された通信が周辺装置サーバにバッファリングされ、前記方法は前記所定の間隔を変更し、それによりバッファリングされる通信の数を変更する。

本発明のいくつかの実施形態は、アイソクロナス出力通信を促進する方法を含んでおり、一つの周辺装置について第１の通信を周辺装置ドライバから受信するステップと、前記周辺装置に対して、ネットワークを介して前記第１の通信からのデータを送信するステップと、前記第１の通信に応答して前記周辺装置から応答通信をネットワークを介して受信することなく、所定間隔が経過したことを記録するステップと、ダミーの通信を生成し、かつそれを周辺装置ドライバに送信し、それにより周辺装置ドライバに対する通信のアイソクロナスシーケンスの送信を維持するステップ等を有する。前記第１の通信は、たとえば周辺装置ドライバからの入出力要求パケットを含んでいてもよい。

いくつかの実施形態では、前記方法は、ネットワークを介して、かつ前記所定間隔の経過後、前記第１の通信に応答する、応答通信を受信するステップと、周辺装置ドライバにそれを送信することなく、当該応答通信を放棄するステップとを含む。いくつかの実施形態では、前記方法は、前記第１の通信に応答する応答通信が受信されるまで、周辺装置ドライバに対するダミーの通信を送信するステップと、次に前記応答通信からのデータを周辺装置ドライバに送信するステップとを反復するステップを含む。

本発明のいくつかの実施形態は、アイソクロナス通信のためのシステムを含み、周辺装置サーバドライバモジュールと、周辺装置サーバドライバモジュールにより生成され、周辺装置サーバドライバモジュールから送信されるダミーの通信等の構成要素とを備え、それにより他の場所で生成され、周辺装置サーバドライバモジュールに送信された時機に適った通信が存在しない場合に、アイソクロナス通信を維持することができる。

いくつかの実施形態では、周辺装置サーバドライバモジュールは、アイソクロナス通信を表す、スケジューリング待ち行列と、更にスケジューリング待ち行列を管理する管理構成要素も備える。

いくつかの実施形態では、周辺装置サーバドライバモジュールがネットワークを介して周辺装置から応答通信が到着するのを待つ間、周辺装置ドライバモジュールがタイムアウトになることを阻止するために、周辺装置サーバドライバモジュールは、周辺装置ドライバモジュールに対するダミーの通信を反復して生成するための遅延制御構成要素を備える。

いくつかの実施形態では、周辺装置サーバドライバモジュールは、ネットワークを介した周辺装置ドライバモジュールから周辺装置へのアイソクロナス入力通信を維持するのを補助するための、アイソクロナス入力通信手段と、ネットワークを介した周辺装置から周辺装置ドライバモジュールへのアイソクロナス出力通信を維持するのを補助するための、アイソクロナス出力通信手段と、あるいはこれらの手段の双方を備えている。

いくつかの実施形態では、前記システムは、アイソクロナス通信を保持するためのバッファを有する周辺装置サーバを備えており、また前記システムは、アイソクロナス通信の送信間の間隔を変更することにより、バッファリングされたアイソクロナス通信の数を変更するための手段をも備えている。

本明細書で与えられた多くの実施例は方法であるが、本発明は、一般に対応する装置、システム、構成されたコンピュータ読み取り可能な記憶媒体、信号、及びプロセスプロダクト、並びに方法を提供する。

本発明の利点及び特徴が得られる方法を記載するために、本発明の説明は、添付図面との関連で述べられる。これらの図面は、本発明の選択された態様を図示するのみであり、本発明の範囲を完全に画定するものではない。

〔第１の実施形態〕
本発明は、具体的な実施例により本文及び図面に例示されているが、本発明の他の実施形態がこれらの実施例から逸脱する可能性があることは理解されるであろう。たとえば、ある実施例の特定の特徴は、削除され、新たに名前を付され、異なるグループ化がなされ、反復され、異なるハードウエア及び／又はソフトウエア内で例示化され、異なる順番で実行されてもよいし、又は２つ以上の実施例に現れる特徴の混合であってもよい。参照は、図面全体を通して、参照符号によりなされる。図面又は本文中の付与された参照符号と関連した表現における明らかな矛盾は、単に当該符号により参照されるものの範囲を広げるものとして理解されるべきである。

文言の定義は、明示的にかつ黙示的に本書面を通して与えられる。文言は本明細書では、必ずしも一般の用法、特定の産業の用法、特定の辞書、又は一連の辞書類における用法が有しているのと同一の意味を有するものではない。本発明者は、自身の語彙に対する権利を主張し、行使するものである。

たとえば、ここで用いられた「通信」は、データ及び／又は他の情報を搬送する、１以上のフレーム、パケット、または信号を意味する。データを搬送する代わりに、又はデータを搬送するのに加え、通信は、承認として送信され、又はそうでない場合には、たとえば、制御、管理、プロトコルのテストのために送信されてもよい。このように、データは一部（必ずしも全てではないが）の通信では、ペイロード（通信パケットのうちヘッダ部分を除いたデータ本体）である。

見出しは便宜のためであり、所与のトピックに関する情報は、該トピックを示す見出しのセクションの外に見出される可能性がある。

図３を参照すると、本発明の一実施形態のネットワーク環境が示されている。ネットワーク３０２には、ネットワーククライアント３０４及び周辺機器サーバ３０６が接続されている。周辺機器３０８は、周辺機器サーバ３０６に接続されている。ネットワーク３０２はたとえばＬＡＮ（Local Area Network）、又は接続された複数のＬＡＮであってもよい。より大規模なネットワークが、いくつかの実施形態において使用されてもよい。２つの周辺機器３０８が示されているが、１つ以上の周辺機器３０８が所与の実施形態において存在してもよい。

同様に、２つのネットワーククライアント３０４が示されているが、所与の実施形態において、１つ以上のネットワーククライアント３０４が存在してもよい。複数の周辺機器サーバ３０６は、同時使用のために別個に処理されるか、あるいはフェイルオーバー構成で構築されるかいずれかであるが、所与の実施形態に存在していてもよい。

通信３１０、３１２はネットワーク３０２を介して伝わる。図６及び図１１に関連して、更に以下で説明するように、通信３１０は通常のシーケンスにおける正規の通信であり、周辺機器３０８と周辺機器ドライバモジュール４０２との間を伝わる際に、データを搬送する。これに対して、通信３１２は通常のシーケンスのギャップを補償するために生成されたダミーの通信であり、これにより周辺機器ドライバモジュール４０２がタイムアウトになることを阻止する。

図３のネットワーククライアント３０４のハードウェア構成については一般的なパソコンと同様であるので説明は省略する。

図４は更に、図３で示した幾つかの事項を示す。一構成では、周辺機器ドライバモジュール４０２及び周辺機器サーバドライバモジュール４０４は、ネットワーククライアント３０４のハードディスク（図示せず）にインストールされている。周辺機器ドライバモジュール４０２は、ネットワークを介して接続される代わりに、ＵＳＢ周辺機器がネットワーククライアントに直接接続されている場合のような、従来の構成における、ＵＳＢ周辺機器を駆動するのに用いられる型の従来の周辺機器ドライバモジュールである。すなわち、本発明は、クライアントマシン上の既存のインストールされたＵＳＢ周辺機器ドライバに対して、改変を要求しない。

なお、周辺機器ドライバモジュールを一部変更して供給するようにしてもよい。すなわち、本発明は、クライアントマシン上の既存のインストールされたＵＳＢ周辺機器ドライバに対して、必ずしも改変を要求するものではない。

周辺機器サーバドライバモジュール４０４は、キュー管理部４０６、時間管理部４０８、送信管理部４１０、受信管理部４１２、及びこれら４つの管理部が参照する、スケジューリングキュー４１４を備えている。管理部４０６、４０８、４１０、４１２及びスケジューリングキュー４１４は、コスト、コピーの数、プロダクションモデルに対するテスト版、モジュール性などの要因により、ハードウエア、ファームウエア、ソフトウエアで、又はハードウエア、ファームウエア及び／又はソフトウエアの組合せで実施されてもよい。

すなわち、図４から明らかなように、本実施形態においては、キュー管理部４０６、時間管理部４０８、送信管理部４１０、受信管理部４１２、スケジューリングキュー４１４、遅延制御４１６、アイソクロナスＯＵＴ手段４１８、アイソクロナスＩＮ手段４２０は、すべてプログラムによって構成されている。これらのプログラムはＣＰＵ（図示せず）と協働して、周辺機器サーバ３０６の制御を行う。

いくつかの実施形態では、管理部４０６、４０８、４１０、４１２の２つ以上は、並行して少なくとも部分的に実行する。たとえば、時間管理部４０８は、たとえキュー管理部４０６が完了していなくても、動作開始してもよい。他のいくつかの実施形態において、動作は、キュー管理部４０６から開始し、当該管理部を完全に通過し、次に時間管理部４０８へ移り、当該管理部を通過し、次に送信管理部４１０へ移り、当該管理部を通過し、次に受信管理部４１２へ移り、当該管理部を通過し、次にキュー管理部４０６へ戻り、これらを繰り返す。４つの管理部は通常、キューに少なくとも一つのキューエントリがある限り、ループで動作する。しかし、本明細書で示されているように、残りの管理部の順序は、通常、アイソクロナスＩＮ（別称ISO-IN）と、アイソクロナスＯＵＴ（別称ISO-OUT）とで異なる。

いくつかの別の実施形態では、制御の流れが、第１のセクションを終える前に、第１のセクションから第２のセクションにジャンプする実行順序が可能である。たとえば、実行は、キュー管理部のステップ７０８からジャンプして、時間管理部の全てを通過し、次にキュー管理部を終えるためにジャンプして戻り、ステップ７０８以降を継続することが可能である。

より一般的には、２つ以上のプロセッサが利用可能であれば、管理部は並行して実行することができ、たとえば、キュー管理部の実行は、時間管理部の実行と重複してよい。

本発明のいくつかの実施形態は、マルチプロセッサ環境において動作することができる。デッドロックやデータの破損を防ぐため、２つ以上のセクションの並行した実行を調整するために、適切な機構が用いられてもよく、たとえば、状態を更新する場合に、カーネル関数である「SpinLock（）」を用いて、同時にステータスを更新したり参照したりすることを阻止してもよい。

本発明の実施形態は、上記周辺機器サーバドライバモジュール４０４及び周辺機器サーバ３０６に含まれる各セクションの動作により、アイソクロナスデータの通信の実現を助けることができる。アイソクロナスＩＮとアイソクロナスＯＵＴとの動作が異なるため、これらを以下に別個に説明する。

〔アイソクロナスデータ送信（アイソクロナスＯＵＴ）〕
最初に本実施形態における、アイソクロナス出力の基本的な通信手順を説明する。

周辺機器サーバドライバモジュール４０４は、周辺機器ドライバモジュール４０２からＩＲＰを受信し、ＩＤ、送信予定時刻、完了予定時刻、ＩＲＰをキューリスト４１４に１つのキューエントリとして登録する（たとえば、図５参照）。続いて、送信予定時刻が満了すると、キューリストからのＩＲＰのデータの一部分及びＩＤが、周辺機器サーバ３０６に対するコマンドとして送信される。周辺機器サーバドライバモジュール４０４は、現在時刻がＩＲＰの完了予定時刻を超えた場合には、ＩＲＰの完了通知を周辺機器ドライバモジュール４０２に送信する。

周辺機器サーバ３０６は、周辺機器サーバドライバモジュール４０４から上記コマンドを受信し、当該コマンドを周辺機器３０８に送信し、周辺機器３０８から応答データを受信し、応答データ及びコマンドのＩＤを周辺機器サーバドライバモジュール４０４に返信する。

周辺機器サーバドライバモジュール４０４は、同一のＩＤを有するキューエントリについて、スケジューリングキュー４１４を検索し、当該リスト４１４から該当するキューエントリを削除する。この手法でＩＲＰを備えるキューを管理することにより、ネットワークコンピュータの間で通信するアイソクロナスデータポート（アイソクロナスＯＵＴ）を備える周辺機器であっても、周辺機器ドライバモジュール４０２と周辺機器３０８との間で通信を確立することができる。

アイソクロナスＯＵＴ通信の内容を、図５に示したキューデータ、及び図６に示した通信シーケンスを一例として用いて、更に説明する。

図５に示されたキュー４１４データは、表形式であるが、キュー４１４は、プログラミング技術では一般に馴染みのある配列、表、リンクリスト、その他のリンクされたデータ構造、及び他の構造を用いて実施することができる。

図５の表におけるＩＤは、各ＩＲＰに対応する固有の識別番号であり、ＩＤの値の範囲が十分に大きいこと、たとえば、予測されたキューエントリの最大数よりも大きい場合に、ＩＤの値は結果的には繰り返されてもよい。

本実施形態では、ＩＲＰに対する参照は、ＩＲＰが完了していない場合には、該当するＩＲＰに対するメモリアドレス（ポインタ）を表し、ＩＲＰが完了した場合には、完了（「完了」、すなわち有効なポインタとして用いられない値）を表す。

混乱を避けるため、異なるアドレスが、図５の各ＩＲＰエントリについて示される。各ＩＲＰポインタは、固有のアドレスを有するが、メモリを再利用することができるため、ちょうど完了した別のＩＲＰと同一のアドレスをキュー中のより新規なＩＲＰが有する、ということが起きることがある。

図５の「ステータス」のラベル付けがされた欄には、他のステータス値が別個に示されている。本明細書の別の箇所に説明されているように、一つのステータス又はステータス値は、各ＩＲＰの現在の状態を表す。

他の実施形態では、たとえばこれら全てをＩＲＰポインタの欄に置くなど、ステータス値の場所を異なって配置してもよい。明白にわかる程度に、異なるセットのステータス値も他の実施形態で用いてもよい。

本明細書の別の箇所に説明されているように、送信予定時刻及び完了予定時刻に、時間管理部４０８により設定された値が入力される。

図５のステータス欄は、複数の起こりうる値を有している。すなわち、「送信準備待ち」、「送信開始」、「送信待ち」、「送信中」、「受信待ち」、「受信中」、「完了待ち」である。

「受信中」のステータスは、単に概念的に「完了」に包含され、図７〜図１０、図１２〜図１５の処理フローチャートでは用いられない。そのステータス値をチェックまたはポーリングする管理部は存在せず、かかるステータス値はセクション又は処理についてのトリガや充足条件とはならない。

図６を図１と比較することは有益である。図１が従来技術を示すことを思い起こされたい。上述のごとく、図１にかかる通信における周辺機器ドライバモジュール４０２は、いくつかのＩＲＰ（フレーム（１）（２）（３））をまとめて発行し、事前に発行されたＩＲＰが完了した後にのみ、次のＩＲＰを発行する。従って、フレーム（４）、（５）は、従来の周辺機器サーバドライバモジュールによりフレーム（１）（２）のＩＲＰが完了するまでは、周辺機器ドライバモジュール４０２から発行されない。結果として、周辺機器に対するフレーム（４）、（５）の到着が遅延し、データが途切れる。

本発明によれば、周辺機器サーバドライバモジュール４０４により、実施形態は、ＩＲＰを特定の時間で、すなわち完了予定時刻が到来すると、周辺機器サーバ３０６からＩＲＰへの応答が未だ到着していない場合であっても、ＩＲＰを強制的に完了する。図６に示した場合では、周辺機器サーバドライバモジュール４０４は、フレームＤ（１）を生成，送信することにより、未だ到着していないフレーム（１）を事実上完了させる。周辺機器ドライバモジュール４０２は、フレームＤ（１）を検出し、それによりフレーム（１）のＩＲＰが完了されたことを認識し、次のＩＲＰとしてフレーム（４）を発行する。この方法で動作することにより、ＩＲＰは何ら遅延なく発行され、周辺機器３０８におけるデータの等時性を提供できる。その一方で、遅れて戻ってきた正規フレーム（１）及び（２）、すなわちフレームＧ（１）及びＧ（２）は、周辺機器サーバドライバモジュール４０４に到着した際に削除される。これはフレームＧ（１）及びＧ（２）のＩＲＰが既にフレームＤ（１）及びＤ（２）により各々完了され、周辺機器ドライバモジュール４０２はこれらの応答を待っていないからである。上記動作は、キュー管理部４０６を軸として各管理部の協働により達成される。

図７から図１０をここで参照し、アイソクロナスＯＵＴ動作における、各管理部の機能及び協働を説明する。

〔キュー管理部〕
周辺機器ドライバモジュール４０２は、周辺機器３０８のアイソクロナスデータポートとの通信を開始する際、ＩＲＰを発行する。このＩＲＰは、周辺機器のサーバドライバモジュール４０４に送信される。これは、馴染みのあるＩＲＰ送信ツール及び技術を利用して行われてもよい。ステップ７０４では、キュー管理部４０６は、周辺機器ドライバモジュール４０２がＩＲＰを送信したか否かを確認する。ＩＲＰが送信されると、ステップ７０６において、受信されたＩＲＰは、周辺機器ドライバ４０２のアイソクロナスデータポートに対する、最初のＩＲＰであるか否かが確認される。仮に最初のＩＲＰである場合には、処理はステップ７０８に進み、そうでない場合には、ステップ７１０に進む。

ステップ７０８では、キュー管理部４０６は、時間管理部４０８に、送信予定時刻及び完了予定時刻を初期値に設定するよう指示する。

ステップ７１０においては、キュー管理部４０６は、新たにキューリスト４１４に、ＩＤ，ＩＲＰ、送信準備待ちのステータスを一つのリストエントリとして登録する。この時点では、送信予定時刻及び完了予定時刻は、新しいキューエントリにおいて、まだ特定されない。ステップ７１２では、キュー管理部４０６は、キューリスト中で、完了ステータスを有するキューエントリを検索し、かかるキューエントリがある場合には、手順はステップ７１４に進む。そうでない場合には、ステップ７１８に進む。

ステップ７１４では、キュー管理部４０６は、完了キューに登録されているＩＲＰのステータスを、「SATATUS_SUCCESS」として設定し、周辺機器ドライバモジュール４０２にＩＲＰを戻し（ＩＲＰを完了させる）、このＩＲＰを削除する。「SATATUS_SUCCESS」は、キューに固有のステータス値に対して、カーネルのステータス値である。処理が進行するにつれて、「SATATUS_SUCCESS」を繰り返し戻すことにより、本発明に係る処理が、周辺機器ドライバモジュール４０２に対して、処理が正常に進行していると認識させる。

このようにして、周辺機器ドライバモジュール４０２は、それ以前のＩＲＰが到着し、及び／又は未だ完了していない場合であっても、次のＩＲＰを発行できる。

ステップ７１６では、キュー管理部４０６は、完了したキューエントリを、受信待ちステータスに更新する。ステップ７１８では、キュー管理部４０６がキューリスト４１４内のエントリ数を確認する。少なくとも一つのキューエントリがあれば、処理はステップ７０４に戻る。そうでない場合には、アイソクロナスデータポートへの通信が完了するため、このキュー管理部４０６を介した反復は終了する。

〔時間管理部〕
ステップ８０４において、時間管理部４０８は、キュー管理部４０６からの要求を待ち、新しいキューエントリの送信予定時刻及び完了予定時刻を初期値に設定する。要求が受信されると、時間管理部４０８は現在時刻に基づいて、キューエントリのための送信予定時刻及び完了予定時刻を設定する。

送信予定時刻及び完了予定時刻に選択される値は、一部は関連するバスのタイミング要求に依存しており、タイミング間隔についても、以下で説明する。図５に示した時間は例であり、所与の実施形態における実際の時間と間隔は、この例とは異なっている可能性がある。

いくつかの実施形態では、次のキューエントリの送信予定時刻及び完了予定時刻は、時間管理部４０８のみが管理する情報であり、時間設定は、この時点では、ＩＲＰに対応する各キューエントリに対して行われない。たとえば、時間管理部４０８にとってローカルである変数のような場合は、時間管理部４０８が、次のキューエントリに設定される時刻を準備し保持するだけである。ステップ８０６では、時間管理部４０８は、送信準備待ちキューエントリについてキューリスト４１４を検索する。

送信準備待ちキューエントリが存在する場合には、処理はステップ８０８に進み、そうでない場合には、ステップ８１２に進む。ステップ８０８では、時間管理部４０８は、ステップ８０４で準備された送信予定時刻及び完了予定時刻を、送信準備待ちキューの送信予定時刻及び完了予定時刻にコピーし、そのエントリのステータスを送信待ちに変更する。

ステップ８１０では、時間管理部４０８は、次のキューエントリの送信予定時刻及び完了予定時刻を、時間管理部４０８内、若しくは別にキュー４１４の外側で保持されている、次のキューエントリのための時刻に更新する。

ステップ８１２では、時間管理部４０８がキュー４１４を、送信待ちステータスのキューエントリであり、かつ現在時刻より送信予定時刻が古いキュー４１４について検索する。かかるキューエントリが存在する場合には、このキューエントリは８１４で、送信開始ステータスとなるように変更され、存在しない場合には、処理はステップ８１６に進む。

ステップ８１６では、時間管理部４０８が、完了を待っており、かつ現在時刻より古い完了予定時刻を有するキューエントリを検索する。かかるキューエントリが存在する場合には、このキューは８１８で完了ステータスに変更され、存在しない場合には、処理はステップ８２０に進む。キューエントリが１つも残っていない場合には、時間管理部４０８は現在の反復処理を終了し、残っている場合には、処理はステップ８０４に戻る。

〔送信管理部〕
ステップ９０４では、送信管理部４１０は、送信開始状態のキューエントリについて検索する。かかるキューエントリが見つかった場合には、周辺機器サーバ３０６に送信されるキューエントリのＩＤ及びＩＲＰから送信データが作成され、キューエントリのステータスが９０６で送信中に更新される。ステップ９０８では、送信が完了した後、送信管理部４１０がキューエントリを完了待ちステータスに更新する。９０４で送信開始キューエントリが存在しない場合には、処理はステップ９１０に進む。ステップ９１０では、いずれかのキューエントリが残っている場合には、送信管理部４１０はステップ９０４に戻り、残っていない場合には、この送信管理処理の反復が終了する。

〔受信管理部〕
ステップ１００４では、受信管理部４１２は受信データを待ち、かかるデータが存在する場合には、処理はステップ１００６に進み、存在しない場合には、ステップ１００４でデータを待ち続ける。ステップ１００６では、受信管理部４１２は、キューリスト４１４を受信された受信データのＩＤに対応するキューエントリについて検索し、かかるキューエントリが存在する場合には、受信管理部４１２はステップ１００８でキューリストから、当該キューエントリを削除する。かかるキューエントリが存在しない場合には、受信データは廃棄され、処理はステップ１０１０に進む。この時点で、キューエントリはキューリストから削除され、リスト中に受信待ちステータスで残される。ステップ１０１０では、キューエントリが残っていない場合には、受信管理部４１２は現在の反復処理を終了し、残っている場合には、処理はステップ１００４に戻る。

〔フローチャート〕
いくつかの実施形態では、アイソクロナス通信（ＩＮ及びＯＵＴ共に）は、上述した各管理部４０６、４０８、４１０、４１２が互いに協働することにより達成される。特に周辺機器ドライバモジュール４０２から、キュー管理部４０６により受信された最初のＩＲＰは、上述の動作を開始するためのトリガとして供され、その後、キューリスト４１４に登録されたＩＲＰのステータスは順次変更され、そして処理は進行する。図７〜図１０は、アイソクロナスＯＵＴ通信における各管理部との関連において参照されてもよい。表１も処理フローを図示しており、ステータスの変化に関連したステップのシーケンスを表す表の列と共に記載されている。これらのステップは、図７〜図１０から抽出されており、これにより、表１はこれらの図面のステップ番号を参照している。表１のステップ番号は、別の管理部によりチェックされた状態が満足された、ある表示された管理部の実行における時点を示している。

他の管理部により求められる条件が満足されるステップの特定には、多少の柔軟性がある。キュー管理部のステップ７０８により、ステップ８０２に始まる時間管理部の実行がトリガされる。時間管理部のステップ８１４により、ステップ９０２に始まる送信管理部の実行がトリガされる。送信管理部のステップ９０８により、時間管理部のステップ８１６における実行がトリガされる。時間管理部のステップ８１８により、ステップ７１２におけるキュー管理部の実行がトリガされる。キュー管理部のステップ７１６により、ステップ１００２における受信管理部の実行がトリガされる。

図７〜図１０及び表１をここで参照すると、周辺機器サーバドライバモジュール４０４は、周辺機器ドライバモジュール４０２からＩＲＰを受け取り、このＩＲＰのキューエントリはキュー管理部４０６の送信準備待ちステータスに設定される（ステップ７１０）。時間管理部４０８では、送信準備待ちのキューエントリが存在すると、ステータスは送信待ちステータスに変更され（ステップ８０８）、送信待ちのキューエントリが存在し、現在時刻が当該キューエントリの送信予定時刻を超過すると、ステータスは送信開始に変更される。送信管理部４１０では、送信開始キューエントリが存在すると、送信が開始され、ステータスは送信中のステータスに変更され、そして送信が完了すると、完了待ちステータスに変更される。時間管理部４０８では、完了を待つキューエントリが存在し、現在時刻が当該キューエントリの完了予定時刻を超過すると、ステータスは完了に変更される。キュー管理部４０６では、完了したキューエントリが存在すると、このキューエントリのＩＲＰは完了され、ステータスは受信待ちステータスに変更される。受信管理部４１２では、データは周辺機器サーバ３０６から受信され、このデータに含まれるＩＤと、受信を待つキューエントリのＩＤが互いに一致する場合には、この受信待ちのキューエントリは削除される。

〔幾つかの効果〕
この方法では、アイソクロナスデータ（アイソクロナスＯＵＴ）を送信するための回数及びタイミングは、送信予定時刻及び完了予定時刻をキューに設定することにより調整することができる。すなわち、完了予定時刻を設定し、周辺機器ドライバモジュール４０２から送信されたＩＲＰに対する応答を強制することにより、周辺機器サーバ３０６が未だデータを処理中であっても、送信する次のデータが周辺機器ドライバモジュール４０２により発行される。また、送信予定時刻を設定することにより、アイソクロナス機器の周辺機器ドライバモジュール４０２が処理を開始する際に、まとめて送信するパケットの送信間隔を制御でき、たとえばこれ以降、図１７との関連で論じられるように、それにより周辺機器サーバ３０６が備えるパケットバッファ３１４の量を低減する効果を達成できる。

〔アイソクロナスデータ受信（アイソクロナスＩＮ）〕
次に、アイソクロナスＩＮ通信に関連した実施形態を説明する。アイソクロナスＩＮの処理手順は、上述したアイソクロナスＯＵＴの処理手順と多くの共通点があり、主に差異に焦点を当てて説明する。

従来技術を示した図２と図１１とを比較することは有益である。上述したアイソクロナスＯＵＴ通信と同様に、アイソクロナスＩＮの場合の遅延の主な原因は、周辺機器ドライバモジュール４０２によるＩＲＰの発行の遅延でもある。この課題を低減または解決するために、アイソクロナスＯＵＴ出力の実施形態においては、完了予定時刻においてＩＲＰが完了される一方で、アイソクロナスＩＮの実施形態においては、送信予定時刻においてＩＲＰを発行することにより課題を低減または解決する。これは、アイソクロナスＩＮ通信とアイソクロナスＯＵＴ通信におけるデータフローの方向を示している。

一般的な事項として、アイソクロナスＯＵＴ通信との類似性において、アイソクロナスＩＮ通信においても、以前に送信されたＩＲＰを完了させることにより、周辺機器ドライバモジュール４０２に次のＩＲＰを発行させることが可能である。しかし、この方法では、以前のＩＲＰを完了させる際に、周辺機器ドライバモジュール４０２に返信されるべきデータ、すなわち周辺機器３０８からの受信データ（別称受信データ）が存在しないことになり、従って、ＩＲＰは空のデータ又はデータは無視されるべきという他の指示で完了されることとなる。これは、アイソクロナスＩＮの通信におけるデータは、周辺機器３０８から周辺機器ドライバモジュール４０２への方向に流れるからである。

従って、本発明の幾つかの実施形態では、以下の処理を行うことにより、遅延を低減し又は阻止する。図１１は、本発明のある実施形態内のアイソクロナスＩＮのための通信シーケンスを図示している。本実施例における本発明に係る特徴的な動作は、フレームＤ（４）及びＤ（５）を含む。周辺機器サーバドライバモジュール４０４は、周辺機器ドライバモジュール４０２によるＩＲＰの発行を待つことなく、ダミーのフレームＤ（４）及びＤ（５）を発行し、その結果、これに対応するアイソクロナスＩＮのデータ（フレーム（４）及び（５））が遅延なく周辺機器ドライバモジュール４０２により受信される。

この時点で、フレームＤ（４）及びＤ（５）に含まれる受信データに対するリクエストは、最後に送信された正規のフレーム、すなわち本件ではフレーム（３）におけるリクエストのコピーを利用する。よって本件では、フレームＤ（４）及びＤ（５）は共に、フレーム（３）のコピーである。フレームＤ（５）の発行時点では、周辺機器サーバドライバモジュール４０４により発行されたフレーム（３）は、実際に発行された最新ＩＲＰである。つまり、ＩＲＰが周辺機器ドライバモジュール４０２により発行され、そのＩＲＰに対応したフレームが、フレームＤ（４）及びＤ（５）の間で、周辺機器サーバドライバモジュール４０４により発行されると、このフレームはフレームＤ（５）にコピーされるべき最新フレームとなる。最新フレームが常にコピーされるべき理由は、かかるフレームは周辺機器３０８で処理されるべき有効なリクエストを含んでいると仮定されるからである。

一方で、周辺機器ドライバモジュール４０２は、（周辺機器ドライバモジュール４０２により送信されたフレームからのデータを送信するのとは反対に）周辺機器サーバドライバモジュール４０４が実際にフレームを発行したことを認識できないため、周辺機器ドライバモジュール４０２は、正規のＩＲＰ、すなわちフレームＧ（４）及びＧ（５）を通常通り発行する。これらのＩＲＰであるフレームＧ（４）及びＧ（５）を受信した周辺機器サーバドライバモジュール４０４はこれらを保持し、データが周辺機器サーバ３０６から受信されると、周辺機器サーバドライバモジュール４０４は、当該データを以前に保持されたＩＲＰに追加し、ＩＲＰを完了させ、次に当該データを周辺機器ドライバモジュール４０２に戻す。

ここで図１２から図１５を参照して、各管理部の機能及び全体的なアイソクロナスＩＮ手順の処理フローを説明する。

〔キュー管理部〕
ステップ１２０４から１２１２は、アイソクロナスＯＵＴ処理手順のステップと同様である。ステップ１２１２では、完了したキューエントリが存在すると、ステップ１２１４において、キュー管理部４０６は対応するＩＲＰを完了させ、当該ＩＲＰを周辺機器ドライバモジュール４０２に戻す。続いて、対応するＩＲＰを含むキューエントリがステップ１２１６で削除される。この時点で、受信データは周辺機器ドライバモジュール４０２に渡される。一方で、完了したキューエントリがステップ１２１２において存在しないと、処理はステップ１２１８に進む。ステップ１２１８では、キュー管理部がキューリストに残っているキューエントリの数をカウントするか、又はいくつかが残っている場合でもすべてをカウントせず、少なくとも何らかのエントリが残っているかを知るために確認する。少なくとも１つのキューエントリが残っている場合には、処理はステップ１２０４に戻り、処理を続け、残っていない場合には、少なくともこの反復について処理を終了する。

〔時間管理部〕
ステップ１３０４では、時間管理部４０８は、キューの完了予定時刻及び送信予定時刻を、アイソクロナスＯＵＴ手順と同様の方法により設定する。ステップ１３０６では、時間管理部４０８は、(i)現在時刻より以前の（それより前に設定された）送信予定時刻を有し、かつ(ii)送信準備を待っているキューエントリが残っているか否かを確認する。周辺機器ドライバモジュール４０２からのＩＲＰがない場合であっても、送信予定時刻を設定することにより、周辺機器サーバドライバモジュール４０４は、指定した時刻が到来すると、強制的に周辺機器サーバ３０６にリクエストを送信することができる。ステップ１３０６では、キューエントリが残っている場合には、時間管理部４０８は（たとえば、図１１のＤ（４）についての）ダミーのキューエントリを生成するための以前に送信された正規のキューエントリからの受信データリクエストとして機能するデータをコピーし、そのステータスを送信開始ステータスに設定し、それをステップ１３０８でキューリスト４１４に追加する。続いて、処理はステップ１３１８に進む。一方、ステップ１３０６においてかかる特定されたキューエントリが存在しない場合には、処理はステップ１３１０に進み、通常の送信フローを実行する。ステップ１３１０では、時間管理部４０８が送信準備待ちのキューエントリが存在するか否かを確認する。かかるキューエントリが存在する場合には、時間管理部４０８は、ステップ１３０４で準備された送信予定時刻及び完了予定時刻を当該キューエントリに設定し、キューエントリのステータスを送信待ちに変更した後、処理はステップ１３１４に進む。一方で、かかるキューがステップ１３１０において存在しない場合にも、処理はステップ１３１４に進む。ステップ１３１４では、時間管理部４０８は、現在時刻より古い送信待ちキューエントリが存在するか否かを確認し、存在する場合には、ステップ１３１６において、該当するキューエントリのステータスが送信開始ステータスに変更され、処理はステップ１３１８に進み、存在しない場合にも、処理はステップ１３１８に進む。ステップ１３１８はアイソクロナスＯＵＴ処理手順と類似している（ステップ８２０）。

〔送信管理部〕
送信管理部は、本明細書の別の箇所で与えられたアイソクロナスＯＵＴの情報のそれと同様である。

〔受信管理部〕
ステップ１５０４及び１５０６はアイソクロナスＯＵＴ処理手順と同様である。ステップ１５０６で該当するキューエントリが存在する場合には、受信管理部４１２はこのキューエントリのステータスをステップ１５０８において完了ステータスに変更する。この部分はアイソクロナスＯＵＴの場合とは異なっている。すなわち、アイソクロナスＩＮ通信では、受信データを周辺機器ドライバモジュール４０２に返信することが必要であるため、受信管理部はキューエントリを削除せず、処理はステップ１５１０に進む。一方、ステップ１５０６において該当するキューエントリが存在しない場合にも、処理はステップ１５１０に進む。ステップ１５１０はアイソクロナスＯＵＴ処理手順と同様である。

〔フローチャート〕
アイソクロナス通信（ＩＮ及びＯＵＴ共に）は、上述の各管理部が協働して動作することにより実現される。特にキュー管理部４０６が周辺機器ドライバモジュール４０２から受信した最初のＩＲＰは、動作開始をトリガし、その後、キューリスト４１４に登録されたＩＲＰのステータスが順次変更し、その結果、処理が進行する。図１２から図１５は、アイソクロナスＩＮ処理手順における各管理部との関連において、参照されてもよい。表２も、ステータスの変化に関連したステップを表す表の列と共に、処理手順フローを示す。これらのステップは、図１２〜図１５から抽出されており、これにより、表２はこれらの図面のステップ番号を参照している。表２のステップの番号は、他の管理部によりチェックされた状態が満足された、ある表示された管理部の実行における時点を示している。表２の列は通常は順序通りであるが、送信開始ステータスにおける時間管理部に属する２つの列は並行処理であり、各々で送信管理部の列の「送信中」のステータスに続く。

キュー管理部のステップ１２０８により、ステップ１３０２に始まる時間管理部の実行はトリガされる。時間管理部のステップ１３０８またはステップ１３１６により、ステップ１４０４における送信管理部の実行がトリガされる。送信管理部のステップ１４０８により、ステップ１５０６における受信管理部の実行がトリガされる。受信管理部のステップ１５０８により、ステップ１２１２におけるキュー管理部の実行がトリガされる。

図１２〜図１５及び表２を参照すると、ステップ１２１０から１４０６は、アイソクロナス出力手順と同様である。ステップ１３０８は幾つかの実施形態内のアイソクロナスＩＮ通信に関する特徴的な動作である。時間管理部４０８において、現在時刻が送信予定時刻を超過すると、たとえ送信準備待ちステータスのキューエントリが存在しなくても、送信開始キューエントリを生成するために、事前に送信されていた正規のＩＲＰのデータがコピーされる（ステップ１３０８）。送信管理部４１０では、送信開始キューエントリが存在する場合には、そのステータスは送信中のステータスに変更され、送信が完了すると、受信待ちのステータスに変更される（ステップ１４０８）。受信管理部４１２では、データは周辺機器サーバ３０６から受信され、データに含まれるＩＤ及び受信を待つキューエントリのＩＤが互いに一致する場合には、このエントリのステータスは、完了ステータスに変更される（ステップ１５０８）。キュー管理部４０６では、完了したキューエントリが存在する場合には、受信データは完了のために、このキューエントリのＩＲＰに追加され、キューエントリは削除される（ステップ１２１６）。

〔幾つかの効果〕
この方法では、アイソクロナスデータ（アイソクロナスＩＮ）を受信するための回数及びタイミングは、送信予定時刻及び完了予定時刻をキューエントリについて設定することにより調整することができる。すなわち、送信予定時刻を設定し、周辺機器サーバドライバモジュール４０４からリクエストを強制的に送信することにより、未だ発行されていないＩＲＰに対するリクエストであっても、周辺機器３０８に送信することができる。また、完了予定時刻を設定することにより、たとえば、ネットワークの異常等により応答の品質が低下している場合でも、ＩＲＰは強制的に完了される。それにより、タイムアウトなどの周辺機器ドライバモジュール４０２が、異常状態に陥るのを防止するのを助けることができる。

〔第２の実施形態（時間同期）〕
他の一連の実施形態がここで説明され、これは上述の第１の実施形態に、アイソクロナスデータ通信の時間同期化を達成する方法を付加している。この目的を達成するために、以下の２つの要件が前提とされる。１つは、データをある一定の間隔で周辺機器サーバ３０６から周辺機器３０８へ、連続して送信することである。もう１つは、ＩＲＰのための十分なバッファスペース３１４を備えた周辺機器サーバ３０６を提供することである。これらの前提の結果として、周辺機器サーバドライバモジュール４０４は、周辺機器サーバ３０６のタイミングに従って、ＩＲＰ送信の同期化を維持することができる。また、たとえネットワークトラフィックの異常等により、応答の品質が低下していても、データは一定の間隔で周辺機器サーバ３０６に送信できる。当該産業では通常、「一定の」とは「受容可能な、かつ測定可能な許容範囲内」を意味する。図１６及び図１７はアイソクロナスＯＵＴモードにおける、上記目的を達成するための２つのパターンを図示している。アイソクロナスＩＮモードについては、以下の様に同様の機構を用いることができる。

周辺機器サーバ３０６からのＩＲＰの送信を、連続して一定の間隔で維持するために、周辺機器サーバ３０６により３１４にバッファリングされるべきＩＲＰの数も、所定範囲内の一定量又はそれに近い量に維持されるべきである。

図１６は、たとえばトラフィックが急激に増加したことにより改善した場合など、周辺機器３０８からの応答の品質が向上した場合を示している。周辺機器３０６によりバッファリングされるべきＩＲＰの数は、応答の改善により増加している。この時点で、周辺機器サーバドライバモジュール４０４から、周辺機器ドライバモジュール４０２へのＩＲＰ完了のための時間延長されたＩＲＰの時間間隔を減少させ、ＩＲＰ送信の数を増加させることにより、周辺機器サーバ３０６により３１４にバッファリングされるべきＩＲＰの数を増加することができる。フレーム（１）、（２）、（３）のＩＲＰを完了させるための周辺機器サーバドライバモジュール４０４のための時間間隔が１００％であり、フレーム（３）、（４）、（５）、（６）の時間間隔が９０％であると仮定する。すなわち、（１）から（２）の間隔が１００％とすると、（３）から（４）の間隔が９０％等である。周辺機器ドライバモジュール４０２が後続のＩＲＰ（フレーム（６）から（１１））をこれと同等の時間間隔で発行するので、周辺機器サーバ３０６に到着するフレームもこれと同等のタイミングで受信される。

一方、周辺機器サーバ３０６から周辺機器３０８に送信されたフレームの時間間隔が一定のものとして扱われるため、周辺機器サーバ３０６によりバッファリングされるべきＩＲＰの数は、上述のように時間間隔を減少させることにより増加することができる。このようなアプローチを実行することにより、トラフィックが急激に改善した場合であっても、周辺機器ドライバモジュール４０２と周辺機器３０８との間の等時性が確保できる。

図１７は、周辺機器３０８からの応答が、トラフィックの応答の劣化などの理由により遅延する傾向にある場合を示す。かかる場合、周辺機器ドライバモジュール４０２からのＩＲＰの発行をある程度遅延させることが有用である。周辺機器ドライバモジュール４０２により発行されたＩＲＰの時間間隔は、周辺機器サーバドライバモジュール４０４が完了するＩＲＰの時間間隔により決定され（又は少なくとも影響を受け）、その結果、ＩＲＰを完了する時間間隔が延長されると、それに伴い周辺機器ドライバモジュール４０２からＩＲＰを発行する時間間隔が延長される。機構内の図示された関係（コード及び／又は回路）を利用することにより、周辺機器ドライバモジュール４０２のＩＲＰを発行する時間間隔は、周辺機器サーバドライバモジュール４０４から制御可能である。

図１７に図示された実施例では、フレーム（１）、（２）、（３）のＩＲＰを完了するための周辺機器サーバドライバモジュール４０４の時間間隔が１００％であると仮定すると、フレーム（３）、（４）、（５）、（６）の時間間隔は１１０％である。周辺機器ドライバモジュール４０２は、これと同等の時間間隔で後続のＩＲＰ（フレーム（６）から（１１））を発行するため、周辺機器サーバ３０６に到着するフレームもまた、これと同等のタイミングで受信される。一方、周辺機器サーバ３０６から周辺機器３０８に送信されるフレームの時間間隔は一定であるため、周辺機器サーバ３０６によりバッファ３１４にバッファリングされるべきＩＲＰの数は、時間間隔が１００％から１１０％に変化することにより減少する。アイソクロナスＯＵＴモードにおいては、周辺機器サーバ３０６にバッファリングされた、送信済ＩＲＰの数は、ＩＲＰを完了させるための時間間隔を変更することにより管理できる。

しかし、アイソクロナスＩＮモードでは、周辺機器サーバドライバモジュール４０４が、等時性を維持するために、周辺機器サーバドライバモジュール４０４から周辺機器サーバ３０６に発行されたＩＲＰの時間間隔を管理しさえすればよい。従って、単に本明細書で教示されたように当該間隔を変更することにより、アイソクロナスＯＵＴモードにおける等時性が確保できる。かかるアプローチを実行することにより、トラフィック応答が一時的に品質劣化した場合であっても、周辺機器ドライバモジュール４０２と周辺機器３０８との間の等時性が確保できる。

上述のいずれの場合も、周辺機器サーバドライバモジュール４０４は、送信済ＩＲＰの数を管理し、その結果、周辺機器サーバ３０６により３１４にバッファリングされるべきＩＲＰの数が常に把握され、ＩＲＰ完了の時間間隔が上記数に基づき動的に決定される。

上記から理解できるように、周辺機器ドライバモジュール４０２からＩＲＰが発行されるタイミングは、周辺機器サーバドライバモジュール４０４によるＩＲＰ完了のタイミングを調整することにより制御され、これにより、周辺機器サーバドライバモジュール４０４が、周辺機器サーバ３０６の時間に従って、ＩＲＰ通信との同期をとることが可能になる。

本実施形態で示されたＩＲＰ完了の時間間隔の増減の幅は、単に一例であり、いかなる値も設定できることに留意すべきである。

本実施形態においては混雑度をキューに蓄積された送信済みＩＲＰの数で判断している。しかし、これに限定されず、ネットワークの混雑度を計測できる手法であればどのようなものであってもよく、たとえば、ＩＲＰを送信してから、応答が帰ってくるまでの時間で計測してもよい。

〔第３の実施形態（遅延制御）〕
この次の一連の実施形態では、遅延制御が上述の実施形態の少なくとも１つに追加される。ネットワークを介してのデータ送信は、周辺機器サーバを介してのみならず、ネットワーク応答、すなわちネットワークトラフィック、その他の種々の理由により、遅延を引き起こす可能性がある。この点において、遅延制御は、ネットワークソフトウエア及びハードウエアにとって、不可欠でないとしても重要な機能である。また、遅延制御は、本開示において示されるように、周辺機器が共有されるシステムにおいても重要である。

これは、本発明で使用される周辺機器ドライバモジュール４０２が通常、ＰＣに直接接続されている間に使用されるように設計されたソフトウエアであり、応答における品質劣化に関して特に考慮されたソフトウエアを備えていないからである。すなわち、周辺機器ドライバモジュール４０２は、遅延をほとんど生じさせないローカルな接続に用いられるとの仮定の下に設計されることが多いため、遅延が生じると、致命的な状態（たとえば、ＰＣ又は周辺機器ドライバモジュール４０２がフリーズする）を引き起こす可能性がある。かかる状態が頻繁に起こる場合には、システムの信頼性は低いものとなる。この点で、応答における品質劣化等に対処する遅延制御を組み込んだアプローチが以下に記載される。

図１８は、周辺機器３０８からの応答において遅延が起こった場合のシーケンス、及び送信されたキューリスト４１４の内容を示している。この図面を参照すると、遅延制御のないシステムでは、フレーム（１）、（２）、（３）が周辺機器ドライバモジュール４０２及び周辺機器サーバドライバモジュール４０４から送信された後、ステップ１８０８でフレームＧ（１）により示されるように、周辺機器サーバドライバモジュール４０４が、正規の（遅延制御のされていない）ＩＲＰを完了するまでは、ＩＲＰの応答は周辺機器ドライバモジュール４０２に返信されない。かかる場合、周辺機器ドライバモジュール４０２は、フレームＧ（１）を受信するまでは、フレーム（１）、（２）、（３）を発行した後に何も受信できないため、タイムアウトが生じる。

従って、本遅延制御の実施形態が提示される。特定の時間が到来すると、周辺機器サーバドライバモジュール４０４は、ＩＲＰ（フレームＤ（１）により示されるように）を強制的に完了し、これにより周辺機器ドライバモジュール４０２に次のＩＲＰを発行させることにより、この遅延制御された実施形態は、周辺機器ドライバモジュール４０２がタイムアウト処理に移行することを回避する。特に、周辺機器サーバドライバモジュール４０４により管理された、送信済ＩＲＰの数が所定数を超過した場合には、次のＩＲＰが完了して、最後のＩＲＰキューの位置に空のスペースを作る際に、送信済ＩＲＰの全てのフレーム番号が１つデクリメントされる（ステップ１８０４）。

続いて、周辺機器ドライバモジュール４０２により新たに発行されたＩＲＰ（フレーム（３））は、この空のＩＲＰキューエントリの末尾に挿入され、そのステータスは送信中のステータスに変更される（ステップ１８０６）。しかし、このＩＲＰは周辺機器サーバ３０６には送信されない。これは、周辺機器サーバ３０６からの応答が既にこの時点で遅延しており、ＩＲＰが送信されても応答を得ることができないからである。この処理（ステップ１８０４及び１８０６におけるキュー操作）は例示した図１８では２回繰り返されているが、かかる処理は正規な応答が返信されるまで、０回以上、繰り返し実行され得る。

前述のように、周辺機器サーバドライバモジュール４０４がキューを空にしながらキューを回転させ、擬似的処理を継続させることにより、周辺機器ドライバモジュール４０２は特定の応答が得られたことを認識し、これにより周辺機器ドライバモジュール４０２がタイムアウト処理に移行することを回避することができる。その後、正規の応答（フレームＧ（１））が周辺機器サーバ３０６から得られると、周辺機器サーバドライバモジュール４０４はこのＩＲＰを完了させ、キューの位置１つ前方へ移動する（ステップ１８０８）。

この時点で、フレーム番号はそのままで残される。その後、新規なＩＲＰ（フレーム（４））は周辺機器ドライバモジュール４０２から発行され、フレーム（４）はこのＩＲＰの送信が完了した時点で、送信済キューリスト４１４の末尾に追加される（ステップ１８１０）。かかる遅延制御のキュー管理方法により、たとえネットワークの応答における一時的な品質劣化が生じたとしても、ＰＣ側の周辺機器ドライバモジュール４０２について等時性が確保される。

図１８はアイソクロナスＯＵＴ通信及びアイソクロナスＩＮ通信の双方の遅延制御のシーケンスを示している。これらの差異は、ＩＲＰにおいて保持されるデータにある。アイソクロナスＯＵＴモードでは、アイソクロナスＯＵＴ通信のデータは、強制的に完了されたＩＲＰ（フレームＤ（１））に対応して発行されたＩＲＰ（フレーム（３））にステップ１８０６で保持される。一方、アイソクロナスＩＮモードでは、アイソクロナス入力通信のデータは、強制的に完了されたＩＲＰ（フレームＤ（１））に保持される。この場合、保持されるべきデータは、実際、周辺機器サーバ３０６から受信されておらず、従って、周辺機器サーバドライバモジュールは無効データ又はダミーのデータをＩＲＰに入れることによりＩＲＰを完了させる。

次に、本発明の幾つかの実施形態に係る、アイソクロナスＩＮ通信における遅延制御に移行するステップについて、図１９を用いて説明する。送信済ＩＲＰの数はステップ１９１９でカウントされる。送信済ＩＲＰの数がステップ１９２０で閾値を超える場合には、ダミーの通信がステップ１９２２で生成され、ステップ１９２４で周辺機器ドライバ４０２に送信される。ステップ１９２０で用いられる閾値は、試行錯誤により決定することができ、この選択された閾値により、周辺機器に対する通信のアイソクロナスシーケンスの送信が維持される。

即ち、候補となる閾値が小さすぎる場合は、通信が正常に進行しているときに、遅延制御モードが早すぎる段階から開始してしまう。遅延制御のダミーの通信に応答して、周辺機器ドライバ４０２は通信を送信し、これは１９２６で受信され、次にステップ１９２８でスケジューリングキュー４１４に追加される。図１８においても示されているように、管理部４０６、４０８、４１０、４１２により使用されるフレーム番号は前にシフトされる。ステップ２０１９及びステップ２０２０により示されるように、同様の遅延制御４１６はアイソクロナスＯＵＴ通信においても使用できる。

図１１で示されているように、ステップ１９０８におけるダミーは、周辺機器ドライバモジュール４０２から周辺機器サーバ３０６に最後に送信された、正規のフレームのコピーである一方、ステップ１９２２におけるダミーは、図１８の遅延制御と関連して、周辺機器サーバドライバモジュール４０４から周辺機器ドライバモジュール４０２へのダミーであることに留意すべきである。以下の通り、種々のダミーの通信３１２が用いられる。第１に、アイソクロナスＩＮモードでは、「通常の」（すなわち遅延制御モードではない）ダミー（たとえば図１１のＤ（４）及びＤ（５））は、周辺機器サーバドライバモジュール４０４から周辺機器サーバ３０６に送信される。このダミーの通信は、最後に送信されたフレームのコピーである。第２に、遅延制御モードにおいて使用されるダミーの通信（たとえば図１８のＤ（１））は、周辺機器サーバドライバモジュール４０４から周辺機器ドライバモジュール４０２に送信される。

このダミーは無効データであり、たとえば既に説明した「STATUS_SUCCESS」である。第３及び第４に、アイソクロナスＯＵＴモードでは、通常のダミー（たとえば、図６のＤ（１）及びＤ（２））及び／又は遅延制御モードのダミー（たとえば、図１８のＤ（１））が各々、使用できる。これらの第３及び第４の場合は、ダミーの通信は、周辺機器サーバドライバモジュール４０４から、周辺機器ドライバモジュール４０２に送信されるが、これはたとえば「ＥＲＲＯＲ」などの無効データであり、アイソクロナス送信においてタイムアウトモードを即座に生じさせるものではない。

本実施形態においては、周辺機器サーバドライバモジュール４０４がキューを空にしながらキューを回転させ、擬似的処理を継続させることにより、周辺機器ドライバモジュール４０２は特定の応答が得られたことを認識させるようにしている。したがって、ネットワークの混雑度に応じて、上記第１実施形態における制御モードと、本件実施形態における制御モードをスムーズに切り替えることができる。

なお、本発明の実施形態においては、後に例示するように第１実施形態による制御を行い、ダミー通信処理の間隔を調整後（第２実施形態）、それでも不十分な場合に、第３実施形態の制御に切り替えるのが好ましい。しかし、これに限定されず、第１実施形態から第３実施形態への切り替えを行ったり、さらに、第１実施形態を行うことなく、第３実施形態のみ行うようにしてもよい。この場合、周辺機器ドライバモジュール４０２から与えられる新たな要求を送信済みとしてキューに記憶しつつ、、所定の規則に基づいて、廃棄するようにしてもよい。さらに、前記新たな要求をそのまま廃棄するようにしてもよい。

〔追加的な見解〕
上記における説明を念頭に置くと、本発明のいくつかの実施形態は、図１１に示すように、アイソクロナスＩＮ通信を促進する方法を提供し、図１９において図示されたステップ、すなわち、周辺機器ドライバから、周辺機器のための第１の通信３１０（たとえば、図１１のフレーム２）を受信するステップ１９０２と、前記第１の通信からのデータをネットワークを介して当該周辺機器に送信するステップ１９０４と、第２の通信３１０を周辺機器ドライバから受信することなく所定間隔が経過したことを検出するステップ１９０６と、ダミーの通信３１２（たとえば、図１１のＤ（４））を生成するステップ１９０８と、ネットワークを介してそれを当該周辺機器に送信するステップ１９１０とを備え、当該周辺機器に対する通信のアイソクロナスシーケンスの送信を維持していると理解される。

ステップ１９０６に関して、正規の通信３１０なく経過した時間は、特定の組み込み及び構成により異なるが、ドライバがタイムアウトモードに移行するのを阻止するために、本発明がここでダミーの通信３１２を生成するのに十分長い時間である。いくつかの実施形態では、生成ステップ１９０８は、ダミーの通信３１２に周辺機器ドライバから直近に受信した通信からのデータをコピーする。たとえば、生成ステップ１９０８は図１１に示されるように、フレーム（３）からＤ（４）にコピーしても良い。

本発明は、単一の周辺機器、及び１より多い周辺機器を伴う方法を含むことが理解でき、ここで「１」又は「単一」は、「少なくとも一つ」を意味する。いくつかの実施形態では、受信ステップ１９０２は、ＵＳＢ周辺機器ドライバから通信を受信し、送信ステップ１９０４はデータをＵＳＢ周辺機器に向けて送信する。

いくつかの実施形態では、前記方法は更に、ダミーの通信３１２に応答する応答通信３１０（たとえば、データが周辺機器サーバドライバモジュールから周辺機器ドライバモジュールに送信される際の、図１１の右端のフレーム（４））をネットワークを介して受信するステップ１９１２と、応答通信からのデータを周辺機器ドライバに送信するステップ１９１４を含む。

いくつかの実施形態では、そして図１１から図１９を参照すると、前記方法は更に、周辺機器サーバドライバモジュール内に、周辺機器ドライバモジュールからのデータ（データ（１））を、当該データ（１）を遠隔周辺機器に送信するのに代えて保持するステップ１９１６と、送信されたデータ（データ（２））に応答して、周辺機器からの通信を受信するステップ１９１２、１９０２の後に、周辺機器ドライバモジュールに、保持されたデータ（データ（３））を送り戻すステップ１９１８を含む。「送信されたデータに応答して」という文言で参照された「データ（２）」は、「データ（１）およびデータ（３）」と同一ではない。なぜなら、「データ（２）」のみが、ダミーのデータ、すなわち、ダミーの通信３１２に含まれる内容に対応するデータだからである。従って、アイソクロナスＩＮモードでは、周辺機器ドライバモジュール（たとえば、図１１のＧ（４））からの実際の通信３１０に含まれるデータは、周辺機器サーバドライバモジュールに保持され、周辺機器サーバから通信が受信された後は、周辺機器ドライバモジュールに送り戻される。

いくつかの実施形態では、ネットワークを介して送信された通信は、周辺機器サーバにバッファリングされ、前記方法は更に、ダミーの通信３１２をトリガするのに用いられる所定の間隔を変更するステップ１９３０により実施される時間同期を備えており、それによりバッファリングされる通信の数を変更する。たとえば図１６及び１７で示されるように、間隔は各々、１９３０において、以前の値の９０％に変更されてもよいし、あるいは以前の値の１１０％に変更されてもよい。通信の所定の間隔を変更することは、たとえば、周辺機器サーバにバッファリングされるべきメモリ量を最適化するために好ましい。

図１９のステップ１９１９〜１９２８は、更に、本発明によるいくつかの実施形態にかかるアイソクロナスＩＮ通信の間に使用される、遅延制御４１６の形式を示している。送信済ＩＲＰの数はステップ１９１９でカウントされる。送信済ＩＲＰの数がステップ１９２０で閾値を超えるときは、ダミーの通信がステップ１９２２で生成され、周辺機器ドライバ４０２にステップ１９２４で送信される。ステップ１９２０で用いられた閾値は試行錯誤により決定することができ、選択された閾値により、周辺機器に対する通信のアイソクロナスシーケンスの送信が維持される。

即ち、候補となる閾値が小さすぎる場合は、通信が正常に進行しているときに、遅延制御モードが早すぎる段階で開始する。送信済ＩＲＰの数が所定数を超えた場合には、ステップ１９２２の分岐が採られ、送信済ＩＲＰの数が所定数を超えない場合には、ステップ１９３０の分岐が採られる。遅延制御ダミー通信に応答して、周辺機器ドライバ４０２が通信を送信し、これはステップ１９２６で受信され、スケジューリングキュー４１４にステップ１９２８で追加される。

図６に示されるように、本発明のいくつかの実施形態は、アイソクロナスＯＵＴ通信を利用する方法を提供し、図２０に示されたステップを含むことも理解される。すなわち、周辺機器に対する第１の通信３１０（たとえば、図６のフレーム（３））を周辺機器ドライバから受信するステップ２００２と、前記第１の通信からのデータをネットワークを介して当該周辺機器に送信するステップ２００４と、前記第１の通信に応答して、当該周辺機器から応答通信３１０のネットワークを介しての受信なく所定間隔が経過したことを検出するステップ２００６と、ダミーの通信３１２（たとえば、図６のフレームＤ（１））を生成するステップ２００８と、それを周辺機器ドライバに送信するステップ２０１０とを含み、それにより、周辺機器ドライバに対する通信のアイソクロナスシーケンスの送信が維持される。いくつかの実施形態では、前記第１の通信３１０（ステップ２００２で受信された通信）は、周辺機器ドライバからの入出力要求パケット（I/O Request Packet）を含んでいる。

いくつかの実施形態では、前記方法は更に、ネットワークを介して、かつ所定間隔の経過後、前記第１の通信に応答する応答通信３１０（たとえば、図６のフレームＧ（１））を受信するステップ２０１２と、前記応答通信を周辺機器ドライバに送信することなく廃棄するステップ２０１４とを含む。

いくつかの実施形態では、前記第１の通信に応答する応答通信が受信されるまで、少なくとも周辺機器ドライバに対するダミーの通信３１２（たとえばステップ１８０４）を送信するステップをステップ２０１６で繰り返し、当該応答通信からのデータを周辺機器ドライバにステップ２０１８で送信する。

いくつかの実施形態では、ネットワークを介して送信された通信は、周辺機器サーバにバッファリングされ、前記方法は更に、ダミーの通信３１２をトリガするのに用いられる所定の間隔をステップ２０３０で変更することにより実施される時刻同期を含み、それによりバッファリングされる通信の数を変更する。

いくつかの実施形態では、ステップ２０１２〜２０１４は、図１１におけるような、アイソクロナスＩＮ通信に対応し、ステップ２０１０、ステップ２０１９、ステップ２０２０、ステップ２０１６、ステップ２０１８は概して図１８のような遅延制御された通信に該当する。ステップ２０２０における分岐は、周辺機器サーバドライバモジュール４０４により管理される、送信済ＩＲＰ（ダミーのＩＲＰ３１２、及び／又は正規のＩＲＰ３１０）の数が所定数を超えるか否かに依存する。送信済ＩＲＰの数が所定数を超えた場合には、ステップ２０１６の分岐が採られ、送信済ＩＲＰの数が所定数を超えない場合には、ステップ２０３０の分岐が採られる。

特に記載したように、本発明は、方法のみならずシステムにおいても具体化される。本発明にかかるアイソクロナス通信のいくつかのシステムは、周辺機器サーバドライバモジュール４０４、及び周辺機器サーバドライバモジュールにより生成され、前記周辺機器サーバドライバモジュールから送信されたダミーの通信３１２（たとえば、図１１のＤ（４）、又は図６のＤ（１））を備え、それにより、他の場所で（周辺機器サーバドライバモジュールとは異なる場所で）生成された時機に適った通信が存在しない場合に、アイソクロナス通信を維持することができる。かかるシステムの実施形態は、アイソクロナスＩＮ通信、又はアイソクロナスＯＵＴ通信、あるいはその双方についての本発明の方法を使用してもよい。しかし、明確に示されない限り、所与のシステムの実施形態は、ＩＮ及びＯＵＴのアイソクロナス通信における本発明にかかる方法により動作する。

いくつかの実施形態では、周辺機器サーバドライバモジュール４０４は、アイソクロナス通信を表す（図５の実施例に示されたような）スケジューリングキュー４１４、及びスケジューリングキュー４１４を管理する管理構成要素（たとえば、キュー管理部４０６、時間管理部４０８、送信管理部４１０、受信管理部４１２、及びこれらと同等の機能を有するもの）を備えている。

いくつかの実施形態では、周辺機器サーバドライバモジュール４０４は、周辺機器ドライバモジュールがタイムアウトになることを阻止するために、周辺機器ドライバモジュールに対するダミーの通信を反復して生成するための（図１８の特定の実施例に示されているような）遅延制御構成要素４１６を備え、一方で、周辺機器サーバドライバモジュールは、ネットワークを介して周辺機器から応答通信が到着するのを待つ。本システムの他のモジュール及び構成要素のように、遅延制御構成要素４１６は、本明細書で特定された機能を提供する限り、ハードウエア、ファームウエア、ソフトウエア、又はこれらの組合せで実施されてもよい。

いくつかの実施形態では、周辺機器サーバドライバモジュールは、（たとえば、図１１におけるような）ネットワークを介した周辺機器ドライバモジュールから周辺機器へのアイソクロナスＩＮ通信を維持するのを助ける、アイソクロナスＩＮ通信手段４２０を備えている。この手段４２０は、図示された図１１のフローチャートに従う４つの管理部を備えたコード、及び／又は回路を備え、またネットワークを介した周辺機器ドライバモジュールから周辺機器へのアイソクロナス入力通信を維持するのを助ける、機能的に同等のコードも備えている。機能的に同等のコード又は回路は、記載された機能性を提供する必要があり、また常に必要とするわけではないが、当該要求された機能性に加え、他の機能性を提供してもよい。

機能的に同等のコード又は回路が、本明細書に記載されたかかる補助のあらゆる態様を提供する必要はなく、それに代えてかかる態様の少なくとも１つを提供すれば十分である。

本明細書で用いられる「コード」は、限定なくコンピュータ・プログラムコード又はソフトウエアを含む。同様に「コード」は、ディジタル処理装置に対する命令、及び／又はこれらの命令により実行される処理データを含んでいる。コードはＲＡＭに格納される必要はなく、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、ＡＳＩＣチップ、ＦＰＧＡチップ、ＰＡＬ回路などに格納できる。

いくつかの実施形態では、周辺機器サーバドライバモジュールは、（たとえば、図６におけるような）ネットワークを介した周辺機器から周辺機器ドライバモジュールへのアイソクロナスＯＵＴ通信を維持するのを助ける、アイソクロナスＯＵＴ通信手段４１８を備えている。この手段４１８は、記述された図６の示されたフローチャートに従う４つの管理部を備えたコード、及び／又は回路を備え、またネットワークを介した周辺機器から周辺機器ドライバモジュールへのアイソクロナスＯＵＴ通信を維持するのを助ける、機能的に同等のコードも備えている。

いくつかの実施形態では、前記システムは周辺機器サーバ３０６を備えている。いくつかの実施形態では、サーバ３０６がアイソクロナス通信を保持するためのバッファを備えている。いくつかのシステムの実施形態では、アイソクロナスＩＮ通信の送信間の間隔をステップ１９３０で変更することにより、及び／又はアイソクロナスＯＵＴ通信の送信間の間隔をステップ１９３０で変更することにより、バッファリングされたアイソクロナス通信の数を変更するための１又は複数の手段４１８、４２０も備えている。いくつかの可能な変更が図１６及び図１７に示されているが、これらの図面に示された特定の通信シーケンス及び間隔は、単に本発明のより広範な範囲のわずかな具体例に過ぎないと理解される。

本発明は種々の方法で具体化されてもよく、たとえば、プロセスを実行するための、ＲＡＭ又は永久記録媒体内のソフトウエア（データ・インストラクション）としての、ソフトウエアにより構成された汎用コンピュータハードウエアとしての、特定の目的のコンピュータハードウエアとしての、待ち行列、フレーム、プロセスにより生成された他のデータとしての、サーバコンピュータ、クライアント又はピアコンピュータ、スタンドアロンコンピュータ、又はネットワーク装置、ネットワークアプライアンス上のプロセス及び／又はハードウエア等である。構成、相互の関係、フレームカウント、その他ここで与えられる実施例の詳細は単なる例示であり、本発明は本明細書で与えられた特定の実施例に限定されない。

「アイソクロナス」及び「アイソシンクロナス」は一部の者によっては交換可能に用いられることがあるが、「アイソクロナス」の文言がここでは好まれている。しかし、何らかの辞書やいずれか第三者の頭の中にある文言の定義ではなく、この文言、又は本明細書中の実施例及び議論から当業者に明らかとなった他のあらゆる文言の意味が支配すべきである。

本発明の特定の実施形態は、たとえば方法として本明細書中に明白に例示および説明されているが、たとえば、実施形態の一種類の議論は概して、他の実施形態の種類にも及ぶと理解されよう。たとえば、方法の説明は、フローチャート、表、及び／又は線図によるものであっても、方法を実行するシステムを説明することをも補助し、また方法の説明は方法により生産される製品（たとえば、フレームのキュー又はシーケンス）を説明することをも補助する。

一実施形態による限定が必ずしも他の実施形態に読み込まれるということにはならない。構成要素、ステップ、ここで与えられた種々の実施例の他の態様を組み合せて所与の実施形態を形成してもよい。

上記実施形態においては、各機能を実現する為に、ＣＰＵを用い、ソフトウェアによってこれを実現している。しかし、その一部若しくは全てを、ロジック回路等のハードウェアによって実現してもよい。

なお、上記プログラムの一部の処理をオペレーティングシステム（ＯＳ）にさせるようにしてもよい。

従来のシステムにおけるネットワークを介したＵＳＢ通信、すなわち、従来のアイソクロナスＯＵＴ通信シーケンスを示す通信シーケンス図である。従来のシステムにおけるネットワークを介したＵＳＢ通信、すなわち、従来のアイソクロナスＩＮ通信シーケンスを示す他の通信シーケンス図である。適切な構成要素（ソフトウエア及び／又は回路）を介する本発明による使用に適合可能なシステムを示すブロック図である。図３に示したネットワーククライアントを更に示すブロック図である。図４に示した、スケジューリングキューを更に示す図である。本発明に係るシステム内のネットワークを介したＵＳＢアイソクロナスＯＵＴ通信を示す通信シーケンス図である。アイソクロナスＯＵＴ通信の間、図５に示したキュー等のキューを管理するための、図４に示したキュー管理部などの、本発明に係るキュー管理部の動作を示すフローチャートである。アイソクロナスＯＵＴ通信の間、図４に示した時間管理部などの、本発明に係る時間管理部の動作を示すフローチャートである。アイソクロナスＯＵＴ通信の間、図４に示した送信管理部などの、本発明に係る送信管理部の動作を示すフローチャートである。アイソクロナスＯＵＴ通信の間、図４に示した受信管理部などの、本発明に係る受信管理部の動作を示すフローチャートである。本発明に係るシステム内のネットワークを介したＵＳＢアイソクロナスＩＮ通信を示す通信シーケンス図である。アイソクロナスＩＮ通信の間、図５に示したキュー等のキューを管理するための、図４に示したキュー管理部などの、本発明に係るキュー管理部の動作を示すフローチャートである。アイソクロナスＩＮ通信の間、図４に示した時間管理部などの、本発明に係る時間管理部の動作を示すフローチャートである。アイソクロナスＩＮ通信の間、図４に示した送信管理部などの、本発明に係る送信管理部の動作を示すフローチャートである。アイソクロナスＩＮ通信の間、図４に示した受信管理部などの、本発明に係る受信管理部の動作を示すフローチャートである。周辺機器サーバにおいてバッファリングされた、増加したＩＲＰの数と共に、本発明に係るシステム内のネットワークを介したＵＳＢアイソクロナス通信を示す通信シーケンス図である。周辺機器サーバにおいてバッファリングされた、減少したＩＲＰの数と共に、本発明に係るシステム内のネットワークを介したＵＳＢアイソクロナス通信を示す通信シーケンス図である。遅延制御と共に、本発明に係るシステム内のネットワークを介したＵＳＢアイソクロナス通信を示す通信シーケンス図である。アイソクロナスＩＮ通信の間、本発明に係る実施形態の動作を更に示すフローチャートである。アイソクロナスＯＵＴ通信の間、本発明に係る実施形態の動作を更に示すフローチャートである。

符号の説明

３０４・・・ネットワーククライアント
３０６・・・周辺機器サーバ
４０４・・・周辺機器サーバドライバモジュール
４０６・・・キュー管理部
４０８・・・時間管理部
４１０・・・送信管理部
４１２・・・受信管理部
４１４・・・スケジューリングキュー
４１６・・・遅延制御
４１８・・・アイソクロナスＯＵＴ手段
４２０・・・アイソクロナスＩＮ手段

Claims

等時性データ通信でデータ通信を行う周辺機器が接続された周辺機器サーバとの間でデータ出力転送するための、クライアントコンピュータの周辺機器サーバ制御プログラムであって、
前記クライアントコンピュータには、入出力要求パケットデータを出力した後、これに対する応答データを受け取ると、次の入出力要求パケットデータを出力する周辺機器制御プログラムがインストールされており、
前記クライアントコンピュータを、
前記周辺機器制御プログラムから与えられた入出力要求パケットデータをカプセル化し、カプセル化した入出力要求パケットデータを前記周辺機器サーバにネットワーク送信する送信手段、
前記周辺機器サーバからネットワーク送信された前記入出力要求パケットデータに対応する応答データを受信すると、前記周辺機器制御プログラムに与える受信手段、
前記周辺機器制御プログラムからの入出力要求パケットデータを前記送信手段によって前記周辺機器サーバに送信してから、所定時間経過したか否か判断する判断手段、
前記所定時間経過しても前記入出力要求パケットデータに対応する応答データを前記周辺機器サーバより受け取らなかった場合には、前記入出力要求パケットデータに対応し、前記入出力要求パケットデータの完了を意味するダミー応答データを前記周辺機器制御プログラムに与えることにより、ネットワーク送信された前記入出力要求パケットデータの次に送信されるべき入出力要求パケットデータを前記周辺機器制御プログラムから出力させるダミー応答出力手段、
として機能させるための周辺機器サーバ制御プログラム。
請求項１の周辺機器サーバ制御プログラムにおいて、
前記周辺機器サーバとの間のネットワークの混雑度を計測する混雑度計測手段、
前記計測された混雑度に応じて、ダミー応答の出力タイミングを変更する変更手段、
を前記クライアントコンピュータにより、さらに実現させるための周辺機器サーバ制御プログラム。
等時性データ通信でデータ通信を行う周辺機器が接続された周辺機器サーバとの間でデータ入力転送するための、クライアントコンピュータの周辺機器サーバ制御プログラムであって、
前記クライアントコンピュータには、入出力要求パケットデータを出力した後、これに対する応答データを受け取ると、次の入出力要求パケットデータを出力する周辺機器制御プログラムがインストールされており、
前記クライアントコンピュータを、
前記周辺機器制御プログラムから与えられた入出力要求パケットデータをカプセル化し、カプセル化した入出力要求パケットデータを前記周辺機器サーバにネットワーク送信する送信手段、
前記周辺機器サーバからネットワーク送信された前記入出力要求パケットデータに対応する応答データを受信すると、前記周辺機器制御プログラムに与える受信手段、
前記周辺機器制御プログラムからの入出力要求パケットデータを前記送信手段によって前記周辺機器サーバに送信してから、所定時間経過したか否か判断する判断手段、
前記所定時間経過しても前記周辺機器サーバに送信すべき次の入出力要求パケットデータを前記周辺機器制御プログラムから受け取らなかった場合には、ダミーの入出力要求パケットデータを前記周辺機器サーバに与えることにより、ネットワーク送信された前記応答データの次に送信されるべき応答データを前記周辺機器サーバから入力するダミー要求出力手段、
として機能させるための周辺機器サーバ制御プログラム。
請求項３の周辺機器サーバ制御プログラムにおいて、
前記ダミー要求出力手段は、直前に前記周辺機器サーバに送った入出力要求パケットデータをダミーの入出力要求パケットデータとして、前記周辺機器サーバに与えること、
を特徴とする周辺機器サーバ制御プログラム。
請求項３または請求項４の周辺機器サーバ制御プログラムにおいて、
前記周辺機器サーバとの間のネットワークの混雑度を計測する混雑度計測手段、
前記計測された混雑度に応じて、ダミーの入出力要求パケットデータの出力タイミングを変更する変更手段、
をクライアントコンピュータにより、さらに実現させるための周辺機器サーバ制御プログラム。
等時性通信規格で通信を行う１または２以上の周辺機器を、クライアントコンピュータがネットワーク接続された周辺機器サーバに接続して、いずれかの周辺機器が特定されたデータが前記クライアントコンピュータから与えられると、等時性通信出力規格にて、前記周辺機器に送信するとともに、当該送信したデータに対する応答データを、当該クライアントコンピュータに前記ネットワークを介してカプセル化して送信するネットワーク通信方法であって、
前記クライアントコンピュータは、
1)入出力要求パケットデータを出力し、これに対する応答データを受け取ると、次の入出力要求パケットデータを出力する周辺機器制御手段が出力した入出力要求パケットデータをカプセル化して前記周辺機器サーバにネットワーク送信を行い、
2)前記周辺機器サーバから、カプセル化された応答データを受け取ると、これをデカプセル化して前記入出力要求パケットデータに対応する応答データとして前記周辺機器制御手段に与え、
3)前記周辺機器制御手段からの入出力要求パケットデータを前記周辺機器サーバに送信してから所定時間経過するか否か判断し、前記所定時間経過しても前記入出力要求パケットデータに対応する応答データを前記周辺機器サーバより受け取らなかった場合には、前記入出力要求パケットデータに対応し、前記入出力要求パケットデータの完了を意味するダミー応答データを前記周辺機器制御手段に与えることにより、ネットワーク送信された前記入出力要求パケットデータの次に送信されるべき入出力要求パケットデータを前記周辺機器制御手段から出力させること、
を特徴とするネットワーク通信方法。
等時性通信規格で通信を行う１または２以上の周辺機器を、クライアントコンピュータがネットワーク接続された周辺機器サーバに接続して、いずれかの周辺機器が特定されたデータが前記クライアントコンピュータから与えられると、等時性入力通信規格にて、前記周辺機器に送信するとともに、当該送信したデータに対する応答データを、当該クライアントコンピュータに前記ネットワークを介してカプセル化して送信するネットワーク通信方法であって、
前記クライアントコンピュータは、
1)入出力要求パケットを出力し、これに対する応答データを受け取ると、次の入出力要求パケットを出力する周辺機器制御手段が出力した入出力要求パケットデータをカプセル化し、これを前記周辺機器サーバにネットワーク送信を行い、
2)前記周辺機器サーバから、カプセル化された応答データを受け取ると、これをデカプセル化して前記入出力要求パケットデータに対応する応答データとして前記周辺機器制御手段に与え、
3)前記周辺機器制御手段からの入出力要求パケットデータを前記周辺機器サーバに送信してから所定時間経過するか否か判断し、前記所定時間経過しても前記周辺機器サーバに送信すべき次の入出力要求パケットデータを前記周辺機器制御手段から受け取らなかった場合には、直前に前記周辺機器サーバに送った入出力要求パケットデータをダミーの入出力要求パケットデータとして前記周辺機器サーバに与えることにより、ネットワーク送信された前記応答データの次に送信されるべき応答データを前記周辺機器サーバから入力すること、
を特徴とするネットワーク通信方法。
請求項２または請求項５の周辺機器サーバ制御プログラムにおいて、
前記混雑度計測手段が計測した混雑度が、所定の混雑度を超えた場合には、さらに、下記の手段による制御を行うためのプログラム。
前記判断手段による前記所定時間経過した旨の判断が与えられると、ダミー応答データを前記周辺機器制御プログラムに与え、前記ダミー応答データに対して、前記周辺機器制御プログラムから、次の入出力要求パケットデータが与えられると、これを、前記周辺機器サーバに送信することなく記憶するステップを前記周辺機器サーバから応答データを受け取るまで繰り返す繰り返し手段。