(57)【特許請求の範囲】
【請求項１】
イニシエータからターゲットに対して命令を発行することで、前記イニシエータの有する記憶領域に対してデータの書き込みあるいは読み出しを前記ターゲットに行わせてデータを交換する通信制御方法であって、
前記イニシエータが、前記記憶領域に対するデータの読み出し命令または前記記憶領域に対するデータの書き込み命令を、ターゲットが保持できる命令の総和を超えないようにターゲットに送信するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を保持するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令への参照を複数のキューのうちの１つにより保持するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を処理するステップとを有し、
前記イニシエータから前記ターゲットに対する命令の送信は、前記イニシエータの有する記憶領域に命令を置き、前記イニシエータの指示によって前記ターゲットが前記イニシエータの記憶領域から読み出すことにより行われることを特徴とする通信制御方法。
【請求項２】
イニシエータからターゲットに対して命令を発行することで、前記イニシエータの有する記憶領域に対してデータの書き込みあるいは読み出しを前記ターゲットに行わせてデータを交換する通信制御方法であって、
前記イニシエータが、前記記憶領域に対するデータの読み出し命令または前記記憶領域に対するデータの書き込み命令を、ターゲットが保持できる命令の総和を超えないようにターゲットに送信するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を保持するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令への参照を複数のキューのうちの１つにより保持するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を処理するステップとを有し、
前記キュー数の増加に応じて、前記ターゲットが保持できる命令の総和を増加させる、または前記イニシエータの命令パラメータに従って前記ターゲットが保持できる命令の総和を増加させる、または前記キュー数の減少に応じて、前記ターゲットが保持できる命令の総和を減少させる、または前記イニシエータの命令パラメータに従って前記ターゲットが保持できる命令の総和を減少させることを特徴とする通信制御方法。
【請求項３】
イニシエータからターゲットに対して命令を発行することで、前記イニシエータの有する記憶領域に対してデータの書き込みあるいは読み出しを前記ターゲットに行わせてデータを交換する通信制御方法であって、
前記イニシエータが、前記記憶領域に対するデータの読み出し命令または前記記憶領域に対するデータの書き込み命令を、ターゲットが保持できる命令の総和を超えないようにターゲットに送信するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を保持するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令への参照を複数のキューのうちの１つにより保持するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を処理するステップとを有し、
前記キューの増加数以上の個数分、前記ターゲットが保持できる命令の総和を増加させることを特徴とする通信制御方法。
【請求項４】
イニシエータからターゲットに対して命令を発行することで、前記イニシエータの有する記憶領域に対してデータの書き込みあるいは読み出しを前記ターゲットに行わせてデータを交換する通信制御方法であって、
前記イニシエータが、前記記憶領域に対するデータの読み出し命令または前記記憶領域に対するデータの書き込み命令を、ターゲットが保持できる命令の総和を超えないようにターゲットに送信するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を保持するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令への参照を複数のキューのうちの１つにより保持するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を処理するステップとを有し、
前記キューの数の増加時に伴って増加した前記ターゲットが保持できる命令の総和数の増加分だけ、当該キューの数の減少時に前記ターゲットが保持できる命令の総和数を減少させることを特徴とする通信制御方法。
【請求項５】
イニシエータからターゲットに対して命令を発行することで、前記イニシエータの有する記憶領域に対してデータの書き込みあるいは読み出しを前記ターゲットに行わせてデータを交換する通信制御方法であって、
前記イニシエータが、前記記憶領域に対するデータの読み出し命令または前記記憶領域に対するデータの書き込み命令を、ターゲットが保持できる命令の総和を超えないようにターゲットに送信するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を保持するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令への参照を複数のキューのうちの１つにより保持するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を処理するステップとを有し、
前記イニシエータは、前記複数のキューのそれぞれに対して少なくとも１つの命令を前記ターゲットが保持できるように、前記複数のキューのそれぞれに対して命令数の割り当てを行うことを特徴とする通信制御方法。
【請求項６】
前記イニシエータは、キューの増加時または減少時に、複数のキューのそれぞれに対して命令数の割り当てを行うことを特徴とする請求項５に記載の通信制御方法。
【請求項７】
前記複数のキューのそれぞれに対して割り当てられた命令数の総和は、前記ターゲットが保持できる命令の総和より小さく、
前記ターゲットが保持できる命令の総和と前記複数のキューのそれぞれに対して割り当てられた命令数の総和との差分が、前記複数のキューのそれぞれにおいて割り当てられた命令数を超えて前記ターゲットが保持している命令の数の総和より大きい場合には、前記イニシエータは、前記複数のキューのうちの１つにおいて割り当てられた命令数を超えて、当該１つのキューに対して命令を送信できることを特徴とする請求項５或いは６に記載の通信制御方法。
【請求項８】
イニシエータのメモリ内の記憶領域に対してターゲットからデータを読み出し或いは書き込みすることでターゲットとデータを交換するイニシエータにおける通信制御方法であって、
前記ターゲットが有する複数のキューのうちの１つを識別するキュー識別子が対応付けられた命令を生成する命令生成工程と、
前記ターゲットから与えられた前記ターゲットが保持できる命令の総和のパラメータを超えないように、前記命令生成工程で生成された命令をターゲットに対して送信する送信工程と、を備えることを特徴とする通信制御方法。
【請求項９】
前記複数のキューのそれぞれに対して少なくとも１つの命令を前記ターゲットが保持できるように、前記複数のキューのそれぞれに対して命令数の割り当てを行う割り当て工程を有することを特徴とする請求項８に記載の通信制御方法。
【請求項１０】
イニシエータのメモリ内の記憶領域に対してターゲットからデータを読み出し或いは書き込みすることでターゲットとデータを交換するイニシエータとしての機器であって、
前記ターゲットが有する複数のキューのうちの１つを識別するキュー識別子が対応付けられた命令を生成する命令生成手段と、
前記ターゲットから与えられた前記ターゲットが保持できる命令の総和のパラメータを超えないように、前記命令生成手段によって生成された命令をターゲットに対して送信する送信手段と、を備えることを特徴とする機器。
【請求項１１】
前記複数のキューのそれぞれに対して少なくとも１つの命令を前記ターゲットが保持できるように、前記複数のキューのそれぞれに対して命令数の割り当てを行う割り当て手段を有することを特徴とする請求項１０に記載の機器。
【請求項１２】
イニシエータの有する記憶領域に対してデータを読み出し或いは書き込みしてイニシエータとデータを交換するターゲットにおける通信制御方法であって、
前記イニシエータからの命令を所定容量の記憶領域に格納する格納工程と、
前記格納工程によって格納された命令を参照する参照データを複数のキューのうちの１つに登録するキューイング工程と、
前記複数のキューのうちの１つに登録されている参照データによって参照される命令を実行する実行工程と、を備えることを特徴とする通信制御方法。
【請求項１３】
前記キューの増加または減少に応じて前記所定容量の記憶領域の容量を増加または減少する容量変更工程と、
増加分または減少分をイニシエータに通知する通知工程と、を備えることを特徴とする請求項１２に記載の通信制御方法。
【請求項１４】
前記キューの増加数以上の個数分、前記ターゲットが保持できる命令の総和を増加させる、または前記イニシエータからの命令パラメータに応じて、前記ターゲットが保持できる命令の総和を増加させる、またはキューの数の増加時に伴って増加した前記ターゲットが保持できる命令の総和数の増加分だけ、当該キューの減少時に前記ターゲットが保持できる命令の総和数を減少させる、または前記イニシエータからの命令パラメータに応じて、前記ターゲットが保持できる命令の総和を減少させることを特徴とする請求項１２に記載の通信制御方法。
【請求項１５】
イニシエータの有する記憶領域に対してデータを読み出し或いは書き込みしてイニシエータとデータを交換するターゲットとしての機器であって、
前記イニシエータからの命令を格納する格納手段と、
前記格納手段によって格納された命令を参照する参照データを複数のキューのうちの１つに登録するキューイング手段と、
前記複数のキューのうちの１つに登録されている参照データによって参照される命令を実行する実行手段と、を備えることを特徴とする機器。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えば、イニシエータ（ホストコンピュータ）とターゲット（プリンタ等）の機器同士を接続する通信制御方法及びシステムに関する。
【０００２】
【従来の技術】
近年、ＩＥＥＥ１３９４インターフェースが、コンピュータと周辺機器、あるいは周辺機器同士の接続に用いられつつある。ＩＥＥＥ１３９４インターフェースは、セントロニクスインターフェースなどのハンドシェイク方式に比べて高速で、しかも双方向通信が可能である。また、メモリバスモデルのインターフェースであり、ＩＥＥＥ１３９４インターフェースで接続された機器は、相手の機器に対して指定されたアドレスのデータを読み書きすることができる。
【０００３】
このＩＥＥＥ１３９４は、広範囲に応用するための物理層及びリンク層のプロトコルを定めたもので、機器ごとの詳細なプロトコルは定められていない。そのため、物理・リンク層としてＩＥＥＥ１３９４を利用したＳＢＰ(Serial Bus Protocol)−２などのトランスポート層のプロトコルが提案されている。トランスポート層はアプリケーションに対してデータ転送機能を提供する層であり、この層を利用するアプリケーションは、互いにデータの交換が可能となる。
【０００４】
このＳＢＰ−２なるプロトコルは、ＩＥＥＥ１３９４のメモリバスモデルとしての特徴を活かしたプロトコルであり、データの受信側がそれ自身の都合に応じてデータを受信することができる。これに対して、ＳＢＰ−２以外のプロトコルには、非同期に発生するデータの転送が可能となるものも、マルチチャネルが実現できるものもあるが、そのようなプロトコルではＩＥＥＥ１３９４のメモリバスモデルとしての特徴を活かすことができない。すなわち、ホストとプリンタの通信であれば、プリンタ側の都合に応じてデータ転送を行うことができず、ホストがプリンタの状態を監視しながらデータ転送を行わねばならないことになる。
【０００５】
ＳＢＰ−２では、データを転送する場合に、まず送信側でログインという操作を行って通信相手との間のチャネルを確立する。この際、ログインした側がイニシエータと呼ばれ、イニシエータと接続された相手側がターゲットと呼ばれる。データ転送は、イニシエータからの指示に応じて、ターゲットからイニシエータのバッファにデータを読み書きすることで行われる。この方式においては、イニシエータは、送信するデータを格納したバッファのアドレスやサイズ等が書かれたＯＲＢ(Operation Request Block)を作成し、そのＯＲＢのアドレスをターゲットに知らせる。ターゲットでは自分の都合に合わせてＯＲＢに書かれたアドレスやサイズに基づいてイニシエータからデータを読み出し、あるいはデータを書き込み、それらの処理後ステータスブロックを作成して、処理の状態をイニシエータに知らせることになる。
【０００６】
【発明が解決しようとする課題】
このＩＥＥＥ１３９４の上に構築されるＳＢＰ−２プロトコルを利用して通信を行う場合、特に、ホストコンピュータ等のデータ源をイニシエータとし、それからターゲットであるプリンタ装置などの周辺機器へのデータ転送に応用する場合、次のような３つの問題点があった。
【０００７】
（問題点１）全２重通信のために手順が複雑である。
【０００８】
ＳＢＰ−２では、基本的にデータの転送はイニシエータによって管理され、ターゲットはイニシエータへの非同期のデータ転送を行うことができない。すなわち、ＳＢＰ−２では、ターゲットがイニシエータへのデータ転送を行いたい時には、イニシエータに対してアンソリシテドステータスでデータリード要求を送り、イニシエータはそれに応じてＯＲＢ生成し、ペンディング中のＯＲＢ（イニシエータからターゲットへのデータ転送要求などが含まれている）のリストの末尾にその生成したＯＲＢをつける。このＯＲＢは先頭から順番に処理されるため、ターゲットがイニシエータにリード要求を発行したタイミングではなく、イニシエータ側のＯＲＢの処理が進み、ターゲットからのデータリード要求によるＯＲＢが処理されたときに初めてターゲットからイニシエータにデータが転送されることになる。すなわち、双方向の非同期なデータ転送が行えず、ターゲットからイニシエータに転送すべきデータが非同期に発生する場合、例えばターゲットがプリンタであれば、そのプリンタでエラーが発生する場合など、直ちにイニシエータに伝達すべきデータを即時に伝達できない。
【０００９】
このため、例えばプリンタで非同期に発生するデータを即座にホストに転送するためには、プリンタをイニシエータとしてログイン手続きを行い、ホストコンピュータをターゲットとするデータ転送を行わねばならない。
【００１０】
このようにホストコンピュータとプリンタで互いにログインしてそれぞれがイニシエータでありターゲットであるような状況では、ホストコンピュータ及びプリンタの双方にイニシエータとしてのプロセスとターゲットとしてのプロセスを備えなければならない。また、ログインの操作もプリンタから行わねばならない。プリンタのような画像を扱う周辺装置では、画像処理のために大量のメモリ資源やプロセッサ資源を消費する。そのために、装置の構成を簡略化して原価を節減したり、処理を迅速に行うため画像処理用途以外に用いられる資源をできるだけ節約しなければならない。しかし、上述のように多くのプロセスを稼働することになればその分多くの資源を消費することになり、原価低減・処理の効率化という目的に反することになる。
【００１１】
また、ホストコンピュータとプリンタとの関係であれば、各方向に流れるデータは、印刷データとそれに対する処理状況といったように、互いに関連付けられるものであるが、各方向について独立したログインによりチャネルを設定すると、それらデータとレスポンスとを関連づけなければならず、そのための処理手順を新たに追加する必要がある。
【００１２】
このようにＩＥＥＥ１３９４及びＳＢＰ−２をそのままホストコンピュータ−プリンタ装置間の通信に適用することは適切でなく、各装置において必要とされる資源を減らすことや効率を向上させることが難しかった。
【００１３】
（問題点２）マルチチャネルを実現できない。
【００１４】
最近、周辺装置として種々の機能を複合させた複合機が利用されつつある。例えば、ファクシミリ装置を、スキャナ単体，プリンタ単体，ファクシミリとしホストコンピュータ等から利用できるデジタル複合機などがある。このような装置を利用する際には、各単体機能ごとに独立した複数のチャネルを介して通信を行えば、同時に複数の機能を利用することができる。
【００１５】
しかしながら、ＳＢＰ−２では、マルチチャネルを提供できないため、そのように単体機能を同時に利用することが難しい。
【００１９】
（問題点３）
イニシエータがターゲットに各キュー毎に数を超えないよう命令を送信していたため、使われないキューに確保されている数が無駄になる事がある。
【００２０】
本発明は上記問題点に鑑みてなされたもので、１回のログインで全２重通信（互いに非同期な双方向通信）を可能とし、また、データの交換に必要なプロセスやメモリといった資源を効率的に利用することができる通信制御方法、機器、ホスト装置、周辺装置及び制御方法を提供することを目的とする。
【００２１】
また、マルチチャネルを実現する通信制御方法、機器、ホスト装置、周辺装置及び制御方法を提供することを目的とする。
【００２３】
また、イニシエータからターゲットに送信できる命令の数の管理をターゲットの各キュー毎に行うのではではなく、一元管理することにより効率的にリソースを利用できるようにする。
【００２４】
また、キュー数の増加に応じて、ターゲットが保持できる命令の総和を増加させる、またはイニシエータの命令パラメータに従ってターゲットが保持できる命令の総和を増加させる、またはキュー数の減少に応じて、ターゲットが保持できる命令の総和を減少させる、またはイニシエータの命令パラメータに従ってターゲットが保持できる命令の総和を減少させることにより、ターゲットのリソース利用効率を向上させるようにする。
【００２５】
【課題を解決するための手段】
本発明に係る通信制御方法は、イニシエータからターゲットに対して命令を発行することで、前記イニシエータの有する記憶領域に対してデータの書き込みあるいは読み出しを前記ターゲットに行わせてデータを交換する通信制御方法であって、前記イニシエータが、前記記憶領域に対するデータの読み出し命令または前記記憶領域に対するデータの書き込み命令を、ターゲットが保持できる命令の総和を超えないようにターゲットに送信するステップと、前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を保持するステップと、前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令への参照を複数のキューのうちの１つにより保持するステップと、前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を処理するステップとを有し、前記イニシエータから前記ターゲットに対する命令の送信は、前記イニシエータの有する記憶領域に命令を置き、前記イニシエータの指示によって前記ターゲットが前記イニシエータの記憶領域から読み出すことにより行われることを特徴とする。
【００２６】
また、本発明に係る通信制御方法は、イニシエータからターゲットに対して命令を発行することで、前記イニシエータの有する記憶領域に対してデータの書き込みあるいは読み出しを前記ターゲットに行わせてデータを交換する通信制御方法であって、前記イニシエータが、前記記憶領域に対するデータの読み出し命令または前記記憶領域に対するデータの書き込み命令を、ターゲットが保持できる命令の総和を超えないようにターゲットに送信するステップと、前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を保持するステップと、前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令への参照を複数のキューのうちの１つにより保持するステップと、
前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を処理するステップとを有し、前記キュー数の増加に応じて、前記ターゲットが保持できる命令の総和を増加させる、または前記イニシエータの命令パラメータに従って前記ターゲットが保持できる命令の総和を増加させる、または前記キュー数の減少に応じて、前記ターゲットが保持できる命令の総和を減少させる、または前記イニシエータの命令パラメータに従って前記ターゲットが保持できる命令の総和を減少させることを特徴とする。
【００２７】
また、本発明に係る通信制御方法は、イニシエータからターゲットに対して命令を発行することで、前記イニシエータの有する記憶領域に対してデータの書き込みあるいは読み出しを前記ターゲットに行わせてデータを交換する通信制御方法であって、前記イニシエータが、前記記憶領域に対するデータの読み出し命令または前記記憶領域に対するデータの書き込み命令を、ターゲットが保持できる命令の総和を超えないようにターゲットに送信するステップと、前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を保持するステップと、前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令への参照を複数のキューのうちの１つにより保持するステップと、前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を処理するステップとを有し、前記キューの増加数以上の個数分、前記ターゲットが保持できる命令の総和を増加させることを特徴とする。
【００２８】
また、本発明に係る通信制御方法は、イニシエータからターゲットに対して命令を発行することで、前記イニシエータの有する記憶領域に対してデータの書き込みあるいは読み出しを前記ターゲットに行わせてデータを交換する通信制御方法であって、前記イニシエータが、前記記憶領域に対するデータの読み出し命令または前記記憶領域に対するデータの書き込み命令を、ターゲットが保持できる命令の総和を超えないようにターゲットに送信するステップと、前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を保持するステップと、前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令への参照を複数のキューのうちの１つにより保持するステップと、前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を処理するステップとを有し、前記キューの数の増加時に伴って増加した前記ターゲットが保持できる命令の総和数の増加分だけ、当該キューの数の減少時に前記ターゲットが保持できる命令の総和数を減少させることを特徴とする。
【００２９】
また、本発明に係る通信制御方法は、イニシエータからターゲットに対して命令を発行することで、前記イニシエータの有する記憶領域に対してデータの書き込みあるいは読み出しを前記ターゲットに行わせてデータを交換する通信制御方法であって、前記イニシエータが、前記記憶領域に対するデータの読み出し命令または前記記憶領域に対するデータの書き込み命令を、ターゲットが保持できる命令の総和を超えないようにターゲットに送信するステップと、前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を保持するステップと、前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令への参照を複数のキューのうちの１つにより保持するステップと、前記ターゲットが、前記イニシエータから受信した読み出し命令または書き込み命令を処理するステップとを有し、前記イニシエータは、前記複数のキューのそれぞれに対して少なくとも１つの命令を前記ターゲットが保持できるように、前記複数のキューのそれぞれに対して命令数の割り当てを行うことを特徴とする。
【００３０】
また、本発明に係る通信制御方法は、イニシエータのメモリ内の記憶領域に対してターゲットからデータを読み出し或いは書き込みすることでターゲットとデータを交換するイニシエータにおける通信制御方法であって、前記ターゲットが有する複数のキューのうちの１つを識別するキュー識別子が対応付けられた命令を生成する命令生成工程と、前記ターゲットから与えられた前記ターゲットが保持できる命令の総和のパラメータを超えないように、前記命令生成工程で生成された命令をターゲットに対して送信する送信工程とを備えることを特徴とする。
【００３１】
また、本発明に係る通信制御方法は、イニシエータのメモリ内の記憶領域に対してターゲットからデータを読み出し或いは書き込みすることでターゲットとデータを交換するイニシエータとしての機器であって、前記ターゲットが有する複数のキューのうちの１つを識別するキュー識別子が対応付けられた命令を生成する命令生成手段と、前記ターゲットから与えられた前記ターゲットが保持できる命令の総和のパラメータを超えないように、前記命令生成手段によって生成された命令をターゲットに対して送信する送信手段とを備えることを特徴とする。
【００３２】
また、本発明に係る通信制御方法は、イニシエータの有する記憶領域に対してデータを読み出し或いは書き込みしてイニシエータとデータを交換するターゲットにおける通信制御方法であって、前記イニシエータからの命令を所定容量の記憶領域に格納する格納工程と、前記格納工程によって格納された命令を参照する参照データを複数のキューのうちの１つに登録するキューイング工程と、前記複数のキューのうちの１つに登録されている参照データによって参照される命令を実行する実行工程とを備えることを特徴とする。
【００３３】
また、本発明に係る通信制御方法は、イニシエータの有する記憶領域に対してデータを読み出し或いは書き込みしてイニシエータとデータを交換するターゲットとしての機器であって、前記イニシエータからの命令を格納する格納手段と、前記格納手段によって格納された命令を参照する参照データを複数のキューのうちの１つに登録するキューイング手段と、前記複数のキューのうちの１つに登録されている参照データによって参照される命令を実行する実行手段とを備えることを特徴とする。
【００３８】
【発明の実施の形態】
（第１の実施の形態）
本発明の第１の実施の形態として、ホストコンピュータとプリンタとを、ＩＥＥＥ１３９４で接続し、その上に構築されたＳＢＰ−２プロトコルを用いた、本発明に係るプロトコル（以下ＳＨＰＴ−２と呼ぶ）に従ってデータ転送を行うプリンタシステムを説明する。図２４は、そのプリンタシステムにおけるハードウエア構成図である。
【００３９】
＜システムのハードウエア構成＞
図２４において、ホストコンピュータ２００は、ＲＯＭ３のプログラム用ＲＯＭに記憶された文書処理プログラム等に基づいて、図形，イメージ，文字，表（表計算等を含む）等が混在した文書処理を実行するＣＰＵ１を備える。ＣＰＵ１はシステムデバイス４に接続される各デバイスをＣＰＵ１が総括的に制御する。また、ＲＯＭ３のプログラム用ＲＯＭには、ＣＰＵ１の制御プログラム等が記憶され、ＲＯＭ３のフォント用ＲＯＭには上記文書処理の際に使用するフォントデータ等が記憶され、ＲＯＭ３のデータ用ＲＯＭは上記文書処理等を行う際に使用する各種データが記憶される。ＲＡＭ２は、ＣＰＵ１の主メモリ，ワークエリア等として機能する。
【００４０】
プログラムはＲＡＭ２に格納されても良い。また、ＲＡＭ２には、送信データバッファやＯＲＢを格納するシステムメモリが確保される。
【００４１】
キーボードコントローラ（ＫＢＣ）５は、キーボード９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）６は、ＣＲＴディスプレイ（ＣＲＴ）１０の表示を制御する。メモリコントローラ（ＭＣ）７は、プートプログラム，種々のアプリケーション，フォントデータ，ユーザファイル，編集ファイル等を記憶するハードディスク（ＨＤ）、フロッピーディスク（ＦＤ）等の外部メモリ１１とのアクセスを制御する。１３９４インターフェース８は、ＩＥＥＥ１３９４規格に従ってプリンタ１００に接続されて、プリンタ１００との通信制御処理を実行する。なお、ＣＰＵ１は、例えばＲＡＭ２上に設定された表示情報ＲＡＭへのアウトラインフォントの展開（ラスタライズ）処理を実行し、ＣＲＴ１０上でのＷＹＳＩＷＹＧを可能としている。また、ＣＰＵ１は、ＣＲＴ１０上の不図示のマウスカーソル等で指示されたコマンドに基づいて登録された種々のウィンドウを開き、種々のデータ処理を実行する。
【００４２】
プリンタ１００において、プリンタＣＰＵ１２は、ＲＯＭ１３のプログラム用ＲＯＭに記憶された制御プログラム等或いは外部メモリ１４に記憶された制御プログラム等に基づいてシステムバス１５に接続される各種のデバイスとのアクセスを総括的に制御し、印刷部インタフェース１６を介して接続される印刷部（プリンタエンジン）１７に出力情報としての画像信号を出力する。また、このＲＯＭ１３のプログラムＲＯＭには、後述する各種エージェントや画像処理を実現するＣＰＵ１２の制御プログラム等が記憶される。ＲＯＭ１３のフォント用ＲＯＭには上記出力情報を生成する際に使用するフォントデータ等が記憶され、ＲＯＭ１３のデータ用ＲＯＭには、ハードディスク等の外部メモリ１４が無いプリンタの場合には、ホストコンピュータ上で利用される情報等が記憶されている。ＣＰＵ１２は１３９４インターフェース１８を介してホストコンピュータとの通信処理が可能となっており、プリンタ内の情報等をホストコンピュータ２００に通知可能に構成されている。
【００４３】
ＲＡＭ１９は、ＣＰＵ１２の主メモリ、ワークエリア等として機能するＲＡＭで、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。なお、ＲＡＭ１９は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。
【００４４】
前述したハードディスク（ＨＤ）、ＩＣカード等の外部メモリ１４は、メモリコントローラ（ＭＣ）２０によりアクセスを制御される。外部メモリ１４は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。また、操作パネル１８には、操作のためのスイッチおよびＬＥＤ表示器等が配されている。また、前述した外部メモリは１個に限らず、少なくとも１個以上備え、内蔵フォントに加えてオプションフォントカード，言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていても良い。さらに、図示しないＮＶＲＡＭを有し、操作パネル１０１２からのプリンタモード設定情報を記憶するようにしても良い。
【００４５】
また、付図示ではあるが、ステイプル機能、ソーター機能等を有するフィニッシャーを接続可能である。
【００４６】
＜イニシエータの構成＞
上述したハードウエア構成において、プリンタ１００をターゲットとし、ホストコンピュータ２００をイニシエータとした通信システムを、図１及び図２に示す。本実施形態に置いては、これら構成は、それぞれホストコンピュータ及びプリンタにおけるＣＰＵによりプログラムを実行することで実現される。まず、図２のイニシエータから説明する。
【００４７】
図２において、イニシエータであるホストコンピュータにおいては、プリンタドライバ等のクライアント２０６はＳＨＰＴ−２処理部２０１を介してプリンタに対するデータ転送要求を発行するとともに、プリンタからの応答を受ける。
【００４８】
ＳＨＰＴ−２処理部２０１は、システムメモリに生成されるＩ／Ｏ要求キューやＯＲＢを管理している。クライアント２０６は単数或いは複数のクライアントプロセスからなり、各クライアントプロセスからのＩ／Ｏ要求コマンドは各クライアントプロセスの通信に用いられる各Ｉ／Ｏ要求キューにそれぞれキューイングされる。図中、４つのＩ／Ｏ要求キューが例示されているが、Ｉ／Ｏ要求キューの数はこれに限られるものではなく、Ｉ／Ｏ要求キューは各クライアントプロセスの通信接続時に動的に用意され、各クライアントプロセスの通信には単数或いは複数のＩ／Ｏ要求キューが用いられる。
【００４９】
図中の例では、クライアントプロセス２０６ａの通信には２つのＩ／Ｏ要求キュー２０２ａ，２０２ｂが用いられ、Ｉ／Ｏ要求キュー２０２ａにはクライアントプロセス２０６ａからのライト要求コマンドが、Ｉ／Ｏ要求キュー２０２ｂにはクライアントプロセス２０６ａからのリード要求コマンドが、それぞれキューイングされ、これらの二つのＩ／Ｏ要求キューにより非同期全二重通信が行なわれる様子を示している。同様にクライアントプロセス２０６ｂの通信にはＩ／Ｏ要求キュー２０２ｃが用いられ、このＩ／Ｏ要求キューにライト要求コマンドがキューイングされ、単方向通信が行われ、また、クライアントプロセス２０６ｃの通信にはＩ／Ｏ要求キュー２０２ｄが用いられ、このＩ／Ｏ要求キューにライト要求コマンド及びリード要求コマンドの一方もしくは両方をキューイングすることで同期半二重通信が行なわれる様子を示している。
【００５０】
ＯＲＢはイニシエータであるホストコンピュータからターゲットであるプリンタへ、あるいはプリンタからホストコンピュータへ渡されるデータバッファのアドレスやサイズ等を格納したブロックであり、先頭のＯＲＢからＯＲＢリスト２０４に順次リンクされている。このＯＲＢについては、次のような処理の原則がある。
【００５１】
（１）各Ｉ／Ｏ要求キューそれぞれの先頭から取り出したコマンドから順にＯＲＢが作成され、ＯＲＢリストの末尾につけられる。コマンドをＯＲＢリストの末尾につける順序には特に制約はない。各Ｉ／Ｏ要求キューに優先順位を付け、特定のＩ／Ｏ要求キューの先頭のコマンドが優先的にＯＲＢリストの末尾につけられるようにしてもよい。
【００５２】
（２）ＯＲＢは、ＯＲＢリストの先頭から順次フェッチされる。完了通知（ステータスブロック）を受信すると、そのステータスに対応するＯＲＢはＯＲＢリストからはずされる。
【００５３】
（３）リンクされるＯＲＢの数の上限は、後述するターゲットにおけるプリフェッチプールの容量（それぞれ処理中のコマンドも含む）と同一である。
【００５４】
（１），（２）項により、各Ｉ／Ｏ要求キュー毎のＩ／Ｏ要求は、それぞれのＩ／Ｏ要求において、発生した順にターゲットに発行されることが保証される。また、（３）項により、ＯＲＢリスト中のＩ／Ｏ要求はターゲットに渡されていることが保証される。この（３）項を実現するために、ＳＨＰＴ−２処理部２０１は、各要求キューに対してそれぞれ１つのカウンタ及びプリフェッチプールに対して１つのカウンタを用意している。
【００５５】
各Ｉ／Ｏ要求キューに対するカウンタはCurrent-QUEというカウンタであり、図の例では４つのＩ／Ｏ要求キューに対して４つのCurrent-QUEカウンタ２０３ａ，２０３ｂ，２０３ｃ，２０３ｄが示されている。それぞれのCurrent-QUEカウンタは、分母（右側）にＩ／Ｏ要求キューに割り当てられたプリフェッチプール内における予約域の数、及び、分子（左側）にそのＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数を保持している。
【００５６】
図中の例は、各Ｉ／Ｏ要求キューに割り当てられたプリフェッチプール内における予約域の数が“１”であり、各要求キュー２０２ａ，２０２ｂ，２０２ｃ，２０２ｄに属するコマンドの現在のＯＲＢリスト内での個数がそれぞれ“３”，“１”，“０”，“２”である状態を示している。
【００５７】
プリフェッチプールに対するカウンタはCurrent-POOLというカウンタ２０３ｅであり、分母（右側）にはプリフェッチプールの全域の数“１０”からそれぞれのＩ／Ｏ要求キューの予約域の数“１＋１＋１＋１”の総和“４”を減じたもの“６”がセットされる。このカウンタは各Ｉ／Ｏ要求キューに割り当てられた予約域以外のプリフェッチプールにおける空数を示している。
【００５８】
また、分子（左側）には、要求キューに貸し出せる数“３”がセットされる。具体的には、２０３ａ〜２０３ｄの分母より分子の大きいものから、この場合、２０３ａと２０３ｄの分子−分母（３−１＝２、２−１＝１）を計算し、各Ｉ／Ｏ要求キューに割り当てられた予約域以外のプリフェッチプールにおける空数６から計算された２と１を加えた３を減じたもの“３”がセットされる。
【００５９】
図中の例は各Ｉ／Ｏ要求キューに割り当てられた予約域以外のプリフェッチプールにおける空数が“６”である状態を示している。
【００６０】
このプリフェッチプールの全域の数はターゲットとなる機器が保持しており、ログイン時等にターゲットから読み出され、イニシエータに記憶される。
【００６１】
図中の例は、プリフェッチプールの全域の数が“１０”である状態を示している。各Ｉ／Ｏ要求キューに付随するCurrent-QUEカウンタの現在のＯＲＢリスト内での個数はＯＲＢの生成と削除に合わせて増減される。
【００６２】
ＯＲＢの生成に当たっては、Current-QUEカウンタの現在のＯＲＢリスト内での個数がＩ／Ｏ要求キューに初期に割り当てられたプリフェッチプール内における予約域の数を超えない場合には、Current-QUEカウンタを増加させ、ＯＲＢをＯＲＢリストに追加する。そうでない場合にはCurrent-POOLカウンタが“１”以上であるかどうかを調べ、“１”以上であれば、Current-POOLカウンタを減じ、Current-QUEカウンタを増加させ、ＯＲＢをＯＲＢリストに追加する。Current-POOLカウンタが既に“０”になっている場合にはＯＲＢをＯＲＢリストに追加しない。
【００６３】
ＯＲＢの削除にあたっては、Current-QUEカウンタの現在のＯＲＢリスト内での個数がＩ／Ｏ要求キューに初期に割り当てられたプリフェッチプール内における予約域の数を超えている場合には、Current-POOLカウンタを増加させる。いずれの場合にもCurrent-QUEカウンタの現在のＯＲＢリスト内での個数は減じられる。
【００６４】
また、ＯＲＢを生成した際には、ターゲット側のドアベルレジスタと呼ばれるレジスタに所定値を書き込む、あるいは、リストの先頭のＯＲＢのアドレスをＯＲＢポインタと呼ばれるレジスタに書き込むことにより、ＯＲＢが発生したことをターゲットに知らせる。既にターゲットが実行しているＯＲＢリストの最後にＯＲＢを追加した場合にはドアベルレジスタへの書き込みを行い、ＯＲＢリストがない状態で新規に先頭のＯＲＢを作成した場合には、ＯＲＢポインタへの書き込みを行う。この手続きはＳＢＰ−２で規定されている。
【００６５】
また、ＳＨＰＴ−２処理部２０１は、ステータスＦＩＦＯ２０５を含む。
【００６６】
１３９４インターフェース１０９を介して受信されたステータスは、ＳＨＰＴ−２処理部２０１により処理される。ＳＨＰＴ−２処理部２０１は、受信したステータスに対応するＯＲＢをＯＲＢリスト２０４から外すとともに、そのＯＲＢに対応するコマンドをＩ／Ｏ要求キューから外す。
【００６７】
イニシエータたるホストコンピュータは以上のような機能的な構成からなっている。
【００６８】
＜ターゲットの構成＞
図１は、ターゲットたるプリンタの機能上の構成を示すブロック図である。図１において、ドアベルレジスタ１０１ａは、イニシエータによって書き込まれるレジスタであり、ＯＲＢが新たに生成されたことを示す。また、ＯＲＢポインタ１０１ｂには、新たに生成されたＯＲＢのアドレスがイニシエータにより書き込まれる。フェッチエージェント１０１は、ドアベル１０１ａに書き込みがあると、１３９４インターフェース１０９を介してＯＲＢポインタで示されるＯＲＢを読み込む。ＯＲＢディスパッチャ１０２は、空参照リスト１０４からポインタを取り出し、ポインタの指し示すプリフェッチプール１０３の空領域にフェッチエージェント１０１により読み込まれたＯＲＢのコマンドを格納するとともに、当該ＯＲＢの後述するQueue IDフィールドにしたがって該当参照キューの末尾にポインタを接続する。
【００６９】
図中の例は、４つの参照キュー１０５ａ，１０５ｂ，１０５ｃ，１０５ｄが存在する状態を示している。参照キューの数はこれに限られるものではなく、参照キューは各クライアントプロセスの通信接続時に動的に用意され、各クライアントプロセスの通信には単数或いは複数の参照キューが用いられる。
【００７０】
実行エージェント１０６は、各参照キューにキューイングされたコマンドを先頭から取り出し、コマンドに従ってイニシエータのバッファへのデータの書込み及びイニシエータのバッファからのデータの読み出し等を行う。その後、ホストコンピュータにノーマルステータスを返す。
【００７１】
実行エージェント１０６は１つの実行スレッドがすべての参照キューに対する処理を他の参照キューの処理にブロックされないように独立にスケジューリングして実行するようにしてもよいし、各参照キュー毎に別の実行スレッドでスレッドをスケジューリングし実行してもよいし、またその組み合わせであってもよい。なお、実行エージェント１０６は、例えばＰＤＬを解釈実行してラスタデータを生成するラスタライザ等のクライアントプロセス１０８ａからのデータ転送要求に応じて、参照キュー１０５ｂで参照されるプリフェッチプール内のリードコマンドで指定されたイニシエータのバッファにデータを書き込む。このデータ転送要求は、イニシエータからのライトコマンドやリードコマンドとは非同期に発生するため、イニシエータはリードコマンドＯＲＢによって参照キュー１０５ｂで参照されるプリフェッチプール内にリードコマンドを常時キューイングしておく。ターゲットは、リードコマンドが参照キュー１０５ｂで参照されるプリフェッチプール内にキューイングされている限り、いつでもデータをイニシエータに渡すことができる。なお、バスインターフェース１１０は、ターゲットであるプリンタ１００からイニシエータであるホストコンピュータ２００のシステムメモリ２０８の所望のメモリロケーションにアクセスするためのインターフェースである。以上、イニシエータ及びタ−ゲットの構成と動作を簡単に説明した。これらを更に詳しく説明する前に、まずＯＲＢの詳しい内容を説明する。
【００７２】
＜コマンドＯＲＢ(Operation Request Block)の内容＞
図７はＯＲＢ一般の構成を示す図である。図７（Ａ）において、"Next_ORB"（リンク）フィールド３０１は、次のＯＲＢへのリンクである。
【００７３】
次のＯＲＢがない場合にはそれを表す所定の値が入れられる。なお、先頭のＯＲＢは、所定のアドレスレジスタにより示される。
【００７４】
"data_descripter"（データデスクリプタ）フィールド３０２は、データバッファのアドレスを示す。"d"（方向）フィールド３０３は、ホストコンピュータからプリンタへのデータ転送（０：ライト）か、プリンタからホストコンピュータへのデータ転送（１：リード）かを示す。"data_size"（データサイズ）フィールド３０４は、アドレスフィールド３０２で指し示されるデータバッファのサイズを示す。以上、図の点線よりも上のフィールド（未説明のフィールドも含めて）がＳＢＰ−２で規定されているフィールドであり、これから説明するフィールド３０５〜３０８が、ＳＨＰＴ−２に固有の処理に用いられるフィールドである。
【００７５】
"QueueID"フィールド３０５は、使用される参照キューのＩＤを表わしている。"function"（ファンクション）フィールド３０６は、図７（Ｂ）に示すようにＯＲＢの種類を示している。０Ｈがライトコマンド、４０Ｈがリードコマンドを表わす。
【００７６】
"seq_ID"（シーケンスＩＤ）フィールド３０８は、参照キュー毎に、ＯＲＢの生成順に振られるシーケンシャルな識別子である。この識別子は、本実施形態ではＯＲＢが生成されるごとに増加するように与えられる。
【００７７】
"seq_ID"フィールドは、最大値まで増加した後、次の増加で０に戻る。なお、このシーケンスＩＤフィールドに値を与える基準となるカウンタは、バスリセットや他の障害による影響を受けない領域に設けられる。それは、ターゲットにおいては、シーケンスＩＤの増加性を前提として処理を行うためである。コントロールブロックフィールド３０９には、ファンクションフィールド３０６の値や、各ファンクションに対してターゲットで実現される機能に応じて様々な値が入れられる。なお、バッファのアドレスやサイズについては、Ｉ／Ｏ要求キューに入れられたコマンドからＯＲＢ生成時に得る。
【００７８】
次に、機能ごとにＯＲＢの内容を説明する。
【００７９】
（ライトコマンドＯＲＢ）
図８はファンクション＝０ＨのライトコマンドＯＲＢを示している。
【００８０】
このコマンドは、指定したバッファ内のデータをイニシエータからターゲットに渡すためのコマンドである。ファンクションフィールドの値は０Ｈである。"t"（タグ）ビット３０７はデータタグを表している。
【００８１】
（リードコマンドＯＲＢ）
図９はファンクション＝４０ＨのリードコマンドＯＲＢを示している。
【００８２】
このコマンドは、イニシエータがターゲットからデータを読み出すためのコマンドである。ファンクションフィールドの値は４０Ｈである。
【００８３】
（コネクトコマンドＯＲＢ）
図１０はファンクション＝Ｃ１ＨのコネクトコマンドＯＲＢを示している。このコマンドは、"QueueID"が0のコネクションサービス用参照キューに対して発行され、新たな接続を開き、その接続に用いる参照キューのIDを取得する為に用いられる。"Service_ID"フィールド３０９ａには新たな接続先のサービスのＩＤを指定する。"Mode"フィールド３０９ｂには接続が全二重双方向、片方向、半二重双方向のいずれかを指定する。
【００８４】
"i"ビット３０９ｅはイニシエータがターゲットにプリフェッチプールの増加を要求するとき１にする。
【００８５】
（ディスコネクトコマンドＯＲＢ）
図１１はファンクション＝Ｃ２ＨのディスコネクトコマンドＯＲＢを示している。このコマンドは前記コネクトコマンドＯＲＢにより、開かれた接続を閉じるのに用いる。このコマンドは閉じようとしている参照キューに対して発行しても良いし、"QueueID"が0のコネクションサービス用参照キューに対して発行してもよい。"QueueID"が0のコネクションサービス用参照キューに対して発行した場合には、"QueueID1","QueueID2"フィールド３０９ｃ，３０９ｄで指定された参照キューに対する接続が閉じる。接続に１つの参照キューのみを使用している場合は、"QueueID2"フィールドには０を指定する。
【００８６】
（クエリーコマンドＯＲＢ）
図１２はファンクション＝Ｃ０ＨのクエリーコマンドＯＲＢを示している。このコマンドはログイン後通信に先立ってターゲットからプリフェッチプールの容量を獲得するのに用いる。
【００８７】
（ステータスブロック）
図１３は、ターゲットからイニシエータに返されるステータスの形式及びその内容を示している。図１３において、点線よりも上のフィールドはＳＢＰ−２で規定されたフィールドであるため、特に説明をしない。タグフィールド４０４はデータタグを表しており、リードコマンドＯＲＢに対するステータスでのみ有効である。
【００８８】
"SHPT2_status1"及び"SHPT2_status2"（ＳＨＰＴ−２ステータス）フィールドはコマンドＯＲＢの実行結果ステータスを示すフィールドで０以外でエラーを表わす。すなわち、値が０であれば、そのステータス対応するコマンドＯＲＢについての処理は完了したことを示す。例えば、対応するコマンドＯＲＢがライトコマンドであれば、ＳＨＰＴ−２ステータスが０のステータスブロックは、対応するライトコマンドＯＲＢで差し示されたバッファから、ターゲットがデータを全て読み出し、ターゲットの持つバッファに書き込み終えたことを意味する。また、値が０以外であれば、対応するコマンドＯＲＢの処理はエラーにより一部或いは全部が行われなかったことを示す。このエラーを受けたイニシエータは、クライアントにエラーである旨知らせるなどしてエラーに対応する。
【００８９】
"residual"（残余）フィールド４０６は、ＯＲＢで指し示されたバッファに対して処理されたデータ長を除いた残余データ長を示す。
【００９０】
（コネクトステータスブロック）
図１４は、ファンクション＝Ｃ１ＨのコネクトコマンドＯＲＢに対するステータスブロックであり、コネクトコマンド終了時に対してターゲットからイニシエータに渡される。新規接続に用いる参照キューのＩＤは"QueueID1"フィールド４０７ａ及び"QueueID2"フィールド４０７ｂに示される。コネクトコマンドＯＲＢの"Mode"フィールドが片方向の場合は"QueueID2"には０が返され、半二重の場合には"QueueID1"、"QueueID2"は同じＩＤが返され、双方向の場合には"QueueID1"、"QueueID2"には異なるＩＤが返される。"POOL_Inc"フィールド４０７ｃはターゲットのプリフェッチプールの容量増加分を示す。
【００９１】
（クエリーステータスブロック）
図１５は、ファンクション＝Ｃ０ＨのクエリーコマンドＯＲＢに対するステータスブロックであり、クエリーコマンド終了時に対してターゲットからイニシエータに渡される。"Init_POOL"フィールド４０７ｄにはターゲットのプリフェッチプールの容量が返される。
【００９２】
＜ＯＲＢの管理＞
次に、以上説明したイニシエータ及びターゲットの構成や、コマンドＯＲＢ及びステータスブロックの構成に基づいて、ＯＲＢがどのように用いられているか説明する。
【００９３】
図１、図２を用いて、イニシエータ、ターゲット及び各クライアント間におけるコマンドの流れを説明する。ここでは、要求キューＡ２０２ａ及び参照キューＡ１０５ａがイニシエータ側からターゲット側へのデータ転送に使われ、要求キューＢ２０２ｂ及び参照キューＢ１０５ｂがターゲット側からイニシエータ側へのデータ転送に使われるとして説明する。
【００９４】
イニシエータのクライアントからデータ転送要求が発生すると、クライアントはターゲットに渡すデータを格納したバッファのアドレス及びサイズを含むライトコマンドを、Ｉ／Ｏ要求キューＡ２０２ａの末尾につける。
【００９５】
ＳＨＰＴ−２処理部２０１では、Current-QUEカウンタ２０３ａが示すそのＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数がＩ／Ｏ要求キューに割り当てられたプリフェッチプール内における予約域の数以上かどうかをチェックし、予約域の数以下であれば、そのライトコマンドからＯＲＢを生成してＯＲＢリスト２０４の末尾にリンクし、Current-QUEカウンタ２０３ａが示すそのＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数を１増やす。ＯＲＢリスト内での個数が予約域の数以上であれば、Current-POOLカウンタ２０３ｅをチェックし空がある、すなわち０でなければそのライトコマンドからＯＲＢを生成してＯＲＢリスト２０４の末尾にリンクし、Current-QUEカウンタ２０３ａが示すそのＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数を１増やすとともにCurrent-POOLカウンタを１減ずる。
【００９６】
Current-POOLカウンタ２０３ｅをチェックし空がなければ空を待つ。図２の状態では、要求キューＡから既に３つのＯＲＢがリンクされていて、予約域１以上になっているが、Current-POOLカウンタは３であるから、Current-POOLカウンタを２に減じ、Current-QUEカウンタのＯＲＢリスト内での個数を４に増やして、要求キューで待っていたライト要求Qa-4に対するＯＲＢをＯＲＢリストに追加できる。なお、ＯＲＢが生成されてもそれに対応するライトコマンドはＩ／Ｏ要求キューから削除されず、ターゲットからの完了ステータスを受けた時点で削除される。
【００９７】
ＳＨＰＴ処理部２０１は、ＯＲＢをＯＲＢリストに入れると、１３９４インターフェースを介してターゲットのドアベル１０１ａに書き込む、あるいは、ＯＲＢポインタ１０１ｂに新たなＯＲＢのアドレスを書き込む。
【００９８】
ディスパッチャ１０２は、空参照リスト１０４からポインタを取り出し、ポインタの指し示すプリフェッチプール１０３の空領域にそのＯＲＢのコマンドを格納し、当該ＯＲＢのQueueIDフィールド（この場合は参照キューＡ１０５ａを示している）にしたがって参照キューの末尾にポインタを接続する。実行エージェント１０６は、参照キューで参照されるプリフェッチプール内のコマンドを順次実行する。すなわち、ターゲットのクライアントの用意したバッファに、ライトコマンドで示されるバッファの内容を書き込む。実行エージェントは、コマンドの処理が完了すると、ＳＨＰＴ−２ステータスが「完了」であるステータスブロックをイニシエータのステータスＦＩＦＯ２０５に書き込む。
【００９９】
ＳＨＰＴ−２処理部２０１は、ステータスＦＩＦＯに入れられたステータスブロックを先頭から処理する。すなわち、ＳＨＰＴ−２ステータスが「完了」であれば、そのステータスブロックに対応するＯＲＢをＯＲＢリストから外し、それとともにＩ／Ｏ要求キュー内の対応するライトコマンドを削除する。この時、Current-QUEカウンタ２０３ａが示すそのＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数がＩ／Ｏ要求キューに割り当てられたプリフェッチプール内における予約域の数を超えているかどうかをチェックし、超えていなければ、Current-QUEカウンタ２０３ａが示す現在のＯＲＢリスト内での個数を１減ずる。ＯＲＢリスト内での個数が予約域の数超えている場合には、Current-POOLカウンタ２０３ｅを１増やし、Current-QUEカウンタ２０３ａが示す現在のＯＲＢリスト内での個数を１減ずる。
【０１００】
以上の手順は、リードコマンドについても全く同様である。ただし、リードコマンドは、ターゲットにおいてリードすべきデータが発生しない限り処理されない。従って、イニシエータから発行されたリードコマンドＯＲＢは、リードすべきデータが発生するまでプリフェッチプール１０３に格納され参照キューＢ１０５ｂにキューイングされたままということになる。
【０１０１】
イニシエータがホストコンピュータ、ターゲットがプリンタである場合、ホストコンピュータからプリンタに印刷データを渡すためには、上述のライトコマンドを用いて、イニシエータのクライアントであるプリンタドライバから、ターゲットのクライアントであるラスタライザに印刷データが渡される。また、ホストコンピュータがプリンタの構成や状態を示す情報を要求する場合には、その旨のコマンド（クライアントレベルのコマンド）をプリンタにライトコマンドで渡す。それを受けたプリンタ（のクライアント）は、プリフェッチプールに格納され、参照キューにキューイングされているリードコマンドを用いて、ホストコンピュータに要求されたデータを渡す。さらに、プリンタでエラーが発生したような場合には、プリンタのクライアントは、プリフェッチプールに格納され、参照キューにキューイングされているリードコマンドを用いて、自発的にエラー情報をホストコンピュータに渡すことができる。このため、ホストコンピュータはプリンタと接続している間は、運用上少なくとも１つのリードＯＲＢをプリンタに対して発行しておく。さらに、リードコマンドを常時プリフェッチプールに格納させ、参照キューにキューイングさせておくためには、少なくとも２つのリードＯＲＢをプリンタに対して発行しておくことが望ましい。
【０１０２】
図２のＯＲＢリスト２０４は必ずしも先頭から順にＯＲＢが削除されていくとは限らない。例えば、参照キューＢ１０５ｂに向けられたＯＲＢＴ４（コマンドＱｂ−１）は参照キューＡ１０５ａに向けられたＯＲＢＴ３（コマンドＱａ−２）よりも先に完了し削除されることもある。このため、ＯＲＢＴ３（コマンドＱａ−２）のリンク先はなくなる。この場合、ＯＲＢＴ３（コマンドＱａ−２）及びＯＲＢＴ５（コマンドＱａ−３）へのポインタはＯＲＢＴ４（コマンドＱｂ−１）処理時にターゲットに既に渡っているため、ＯＲＢリスト上でリンク先をつなぎなおす必用はない。また、エラー等でＯＲＢリストがクリアされても、Ｉ／Ｏ要求キューには対応コマンドが残っているため、後述するエラー復旧処理も正常に行うことができる。
【０１０３】
＜エラーの復旧（イニシエータ）＞
既に説明したように、ＳＢＰ−２では、ネットワークに異常（エラー）に起因するバスリセットにより、イニシエータとターゲットとの間の接続は断たれてしまう。そこで、ＳＨＰＴ−２では、バスリセットにより失われた状態を復旧するための手順を定めている。
【０１０４】
イニシエータはネットワーク上のエラーなどからバスリセットが発生後、バスリセットの処理が終えたなら、ＳＢＰ−２の規定に従い全てのＯＲＢをＯＲＢリストから消去する。各Ｉ／Ｏ要求キューは、バスリセットがあってもリセットされることはない。
【０１０５】
イニシエータは、コネクションを再設定した後、Ｉ／Ｏ要求キューを参照して、それらキューの内容から新たにＯＲＢを生成し、ターゲットに対して発行する。このとき、ＯＲＢの生成時に対応するコマンドに対して割り当てられていた"Seq_ID"フィールドの値を再度指定することにより、バスリセット直前の状態を再現することができる。
【０１０６】
＜エラーの復旧（ターゲット）＞
イニシエータはＯＲＢリストを復旧させるだけでその状態をバスリセット直前の状態に戻せるが、ターゲットはリード／ライトのコマンドに応じてバッファに対してリード／ライトを行うため、リード／ライト中にバスリセットが発生した場合には、復旧後はその続きを行わねばならない。そのために、ターゲットの実行エージェントは、各参照キューで参照されるそれぞれの処理中のコマンドの"Seq_ID"フィールドと、その処理中のバッファの位置を各参照キュー毎に記憶している。
【０１０７】
例えば、イニシエータがリードＯＲＢを発行し、ターゲットはそれを実行エージェントによって処理する場合、実行前に、実行エージェント１０６はこれから処理するリードコマンドＯＲＢのseq_IDフィールドを読み出し、シーケンス識別子(Sequenceidentifier)として記憶しておく。また、クライアントのバッファにデータを書き込むに当たり、現在書き込んでいるバッファのアドレスを実行ポインタ(Nextexecpointer)として更新しつづける。これらの領域はバスリセットによって消去されないメモリ領域に確保される。
【０１０８】
バスリセットが終了したなら、イニシエータはＯＲＢを改めて発行してくるため、実行エージェントは、プリフェッチプールに格納され、参照キューの先頭で参照されるＯＲＢのseq_IDフィールドが、記憶されているシーケンス識別子よりも古ければ、そのＯＲＢは既に処理は完了しているために、完了ステータスを返す。両者が一致すれば、Nextexecpointerで示されるアドレスから書き込みを続行する。
【０１０９】
ライトコマンドについても同じ要領で復旧される。
【０１１０】
以上、本実施形態の印刷システムにおいて用いられるコマンドおよびステータスについて説明した。次に、イニシエータおよびターゲットにおけるコマンド及びステータスの処理手順を説明する。
【０１１１】
＜イニシエータのクライアントによるデータ転送要求＞
図３は、イニシエータのクライアントであるプリンタドライバ等から、ターゲットに対して、データを送信あるいは要求する際の手順を示している。
【０１１２】
データ転送事項が発生したなら（ステップＳ１３０１）、そのために必用なコマンドがライトであるかリードであるか判定し（ステップＳ１３０２）、ライトならばそのためのデータ転送バッファがあるか調べ（ステップＳ１３０３）、また、ターゲットに渡すべき送信データの準備ができているか調べて（ステップＳ１３０４）、すべて準備できていれば、バッファのアドレスやサイズ等、必用な引き数を与えてライトコマンドを作成し（ステップＳ１３０５）、ライト関数をコールする（ステップＳ１３０６）。
【０１１３】
一方、リードコマンドであると判定されれば、データを受けるための転送バッファがあるか調べ（ステップＳ１３０７）、あればバッファのアドレスやサイズ等、必用な引き数を与えてリードコマンドを作成し（ステップＳ１３０８）、リード関数をコールする（ステップＳ１３０９）。
【０１１４】
例えば、データ転送事項がプリンタに対する印刷データの送信ならば、ＰＤＬなど、クライアントレベルのコマンドやデータをバッファに用意し、ライトコマンドを作成することになるし、データ転送事項がプリンタからの状態の読み出しであれば、その旨を示すクライアントレベルのコマンドを用意してライトコマンドを作成するとともに、ターゲットからデータを受けるためのリードコマンドを作成する必用がある。また、ターゲットとの一連のデータ交換を行うに先立って、イニシエータのクライアントはリードコマンドを幾つか発行する。
【０１１５】
図４は、イニシエータのクライアントが下位すなわちＳＨＰＴ−２の層から処理終了通知を受けた際の処理手順である。まず、終了した処理がリードかライトか判定し（ステップＳ１４０１）、ライトであれば使用したデータバッファを解放する（ステップＳ１４０２）。一方、リードであれば、処理の終了はデータの受信の完了であるから、受信したデータに対応した処理を行い（ステップＳ１４０３）、データバッファを解放する（ステップＳ１４０４）。
【０１１６】
＜イニシエータのＳＨＰＴ処理部による処理＞
図５〜図６は、イニシエータのＳＨＰＴ−２処理部による処理手順である。
【０１１７】
図５（Ａ）及び（Ｂ）は、それぞれクライアントがコールするライト関数及びリード関数の内容を示す。ライト関数では、そのクライアントが接続要求を出しコネクトした時にクライアントに対してＳＨＰＴ−２部が与えたコネクトハンドルが引数として渡され、そのコネクトハンドルに該当するＩ／Ｏ要求キューのＩＤに基づき、そのＩ／Ｏ要求キューにライトコマンドを追加する。リード関数も同様に、そのクライアントが接続要求を出しコネクトした時にクライアントに対してＳＨＰＴ−２部が与えたコネクトハンドルが引数として渡され、そのコネクトハンドルに該当するＩ／Ｏ要求キューのＩＤに基づき、そのＩ／Ｏ要求キューにリードコマンドを追加する。それぞれのＩ／Ｏ要求キューにキューイングされたコマンドは、後にターゲット側でコネクトコマンドのステータスで与えられた"QueueID1","QueueID2"で示される参照キューへそれぞれ送られることになる。
【０１１８】
（Ｉ／Ｏ要求キュー管理）
図５（Ｃ）各Ｉ／Ｏ要求キューの管理手順を示す。これらの手順は、各Ｉ／Ｏ要求キューごとに単独のスレッドでスレッドスケジュールによって独立に行われてもよいし、すべてのＩ／Ｏ要求キューをひとつのスレッド内で管理が他のＩ／Ｏ要求キューの動作によってブロックされないように独立スケジュールすることで実行してもよいし、またこれらの組み合わせであってもよい。図５（ｃ）は１つのＩ／Ｏ要求キューの管理を示すものである。Ｉ／Ｏ要求キューの管理は各Ｉ／Ｏ要求キュー毎に行う。
【０１１９】
まず、Ｉ／Ｏ要求キュー内にＯＲＢ化されていないコマンドがあるか調べる（ステップＳ１６０１）。あれば、このＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数を示すカウンタCurrent-QUEがこのＩ／Ｏ要求キューに割り当てられたプリフェッチプール内における予約域の数より小さいか判定する（ステップＳ１６０２）。小さければＳ１６０５に進み、大きいか等しければＳ１６０４に進む。Ｓ１６０４では、プリフェッチプールに対するCurrent-POOLカウンタが０より大きければCurrent-POOLカウンタを１減じる。次にＳ１６０５でCurrent-QUEの値に１を加え（ステップＳ１６０５）、Ｉ／Ｏ要求キューに格納されている、ＯＲＢ化されていない先頭のコマンドを基に、シーケンスＩＤ(Seq_ID)やＳＨＰＴ−２コマンド(Function)を付加して、ＯＲＢを作成する（ステップＳ１６０６）。
【０１２０】
こうして作成したＯＲＢをＯＲＢリストにつけ（ステップＳ１６０７）、ターゲットのドアベルに書き込む、あるいは、ＯＲＢポインタにＯＲＢのアドレスを書き込む（ステップＳ１６０８）。このようにして、Ｉ／Ｏ要求キュー内のコマンドからＯＲＢが作成される。
【０１２１】
（ステータスブロックに対する処理）
図６は、ステータスブロックをターゲットから受けた際の処理手順である。ＯＲＢに対する処理完了のステータスブロックを受けると、対応するＯＲＢをＯＲＢリストから削除し（ステップＳ１７０１）、対応ＯＲＢに対するコマンドがキューイングされているＩ／Ｏ要求キューを選択する（ステップＳ１７０２）。選択したＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数を示すカウンタCurrent-QUEがこのＩ／Ｏ要求キューに割り当てられたプリフェッチプール内における予約域の数以下であるかを判定し、以下であるならばＳ１７０４に進む。そうでなければ、Ｓ１７０４に進む（Ｓ１７０３）。Ｓ１７０４では、プリフェッチプールに対するCurrent-POOLカウンタを１増やす。次にＳ１７０５で選択したＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数を示すカウンタCurrent-QUEを１減ずる。最後に、選択されたＩ／Ｏ要求キューに対応するクライアントに処理の終了を通知する（ステップＳ１７０６）。クライアントはこれを受けて、図４の処理を行うことになる。
【０１２２】
（エラー復旧処理）
ＳＨＰＴ−２処理部における通常の処理は以上のとおりである。次にバスリセット後などに復旧する手順を図１８により説明する。バスリセットが生じてターゲットとのＳＢＰ−２コネクションが切断されてしまった場合、あらためてＳＢＰ−２コネクションの再設定から行わねばならない。
【０１２３】
まず、新規のＯＲＢのリンク処理を中断し（ステップＳ１８０１）、ＯＲＢリストを破棄する（ステップＳ１８０２）。この後ＳＢＰ−２コネクションの再接続命令を出して（ステップＳ１８０３）、コネクションの確立を調べ（ステップＳ１８０４）、コネクションが再度張られたなら、各Ｉ／Ｏ要求キューの先頭のコマンドから順に対応するＯＲＢを作成する（ステップＳ１８０５）。このとき、各ＯＲＢの"Seq_ID"フィールドは、そのコマンドに対してバスリセット前に付与されていたのと同一のＩＤを付与する。作成されたＯＲＢはＯＲＢリストにリンクされ（ステップＳ１８０６）、ＯＲＢポインタにアドレスを書き込んで（ステップＳ１８０７）、ターゲットにＯＲＢの発生を知らせる。
【０１２４】
一方、コネクションが再設定できないまま一定時間経過すると（ステップＳ１８０８）、各Ｉ／Ｏ要求キュー内のコマンドをすべて破棄し（ステップＳ１８０９）、異常である旨をクライアントに知らせて（ステップＳ１８１０）、処理を終える。以上の手順により、リセット後に、あらためてターゲットとのＳＢＰ−２コネクションを確立し、リセット直前のＯＲＢリストを復旧することができる。
【０１２５】
＜ターゲットによる処理＞
図１９〜２０は、ＯＲＢを受けたターゲットによる処理手順である。
【０１２６】
（フェッチエージェントによる処理）
フェッチエージェントは１つのＳＢＰ−２コネクションに対して１つ用意される。フェッチエージェントはドアベルレジスタあるいはＯＲＢポインタに書き込みがあるとＯＲＢをフェッチする。まず、ドアベルレジスタあるいはＯＲＢポインタに書き込みが行われるまで待ち（ステップＳ１９０１）、書き込みがあると、ドアベルレジスタへの書き込みにより起動されたか判定し（ステップＳ１９０２）、そうでなく、ＯＲＢポインタへの書き込みにより起動されたのであればステップＳ１９０３に進む。一方、ドアベルへの書き込みがあったならば、ＯＲＢポインタで指されているＯＲＢの"Next_ORB"フィールドがＮＵＬＬ（後続ＯＲＢ無し）かどうかをテストする（ステップＳ１９０７）。ＮＵＬＬであればステップＳ１９０１に戻る。
【０１２７】
ＮＵＬＬでなければ、ステップＳ１９０８へと進み、現在のＯＲＢポインタで指されているＯＲＢのNext_ORBフィールドの値を、ＯＲＢポインタへと書き込み更新し（ステップＳ１９０８）、ステップＳ１９０３へ進む。
【０１２８】
こうしてＯＲＢポインタに処理すべきＯＲＢのアドレスが得られたなら、そのアドレスからＯＲＢを読み出す（ステップＳ１９０３）。空参照リストからプリフェッチプール内の空領域を指し示すポインタを取り出し、読み出したコマンドＯＲＢをその空領域に格納する（ステップＳ１９０５）。
【０１２９】
またそのＯＲＢの"QueueID"フィールドを参照してコマンドをキューすべき参照キューを選択し（ステップＳ１９０５）、選択した参照キューの末尾に空参照リストから取り出したポインタをキューする（ステップＳ１９０６）。
【０１３０】
この後、キュー処理を終えたＯＲＢのNext_ORBフィールドを参照して、その内容がNULL、すなわちリンクされているＯＲＢがなければ、Ｓ１９０１に戻り次のＯＲＢがリンクされ、ドアベルあるいはＯＲＢポインタへ書き込みがあるまで待つ。一方、リンクされているＯＲＢがあれば、ＯＲＢポインタで指されているＯＲＢのNext_ORBフィールドの値を、ＯＲＢポインタに書き込み更新し（ステップＳ１９０８）、ＯＲＢリストにリンクされているＯＲＢを順次プリフェッチプールに格納していく。
【０１３１】
このようにして、ＯＲＢリストのＯＲＢをプリフェッチプールにいれる。
【０１３２】
また、ステップＳ１９０４〜Ｓ１９０６の処理は、図１においてＯＲＢディスパッチャとして説明した処理である。
【０１３３】
（実行エージェント）
図２０は各参照キューに対する実行エージェントの手順を示す。これらの手順は、各参照キューごとに単独のスレッドでスレッドスケジュールによって独立に行われてもよいし、すべての参照キューをひとつのスレッド内で管理が他の参照キューの動作によってブロックされないように独立スケジュールすることで実行してもよいし、またこれらの組み合わせであってもよい。図２０は１つの参照キューに対する実行エージェントの手順を示すものである。各参照キューに対する実行エージェントの手順は各参照キュー毎に行う。
【０１３４】
実行エージェントは、まず参照キューにプリフェッチプール内のコマンドへのポインタがあるか調べ（ステップＳ２００１）、ＯＲＢをプリフェッチプールから取り出す（ステップＳ２００２）。これらは参照キューの先頭を指し示すポインタを用いることにより行う。ＯＲＢを読み出すと、そのＯＲＢのSeq_IDフィールドの値が、実行エージェントが保持する変数SequenceIdentifierよりも小さい値であるか判定する（ステップＳ２００３）。ただし、Seq_ID及びSequenceIdentifierはともに有限の桁数である。そこで、Seq_ID及びSequenceIdentifierがともにｎビットで表わされる場合、ステップＳ２００３における比較では、（（２のｎ乗−１）＜０（＝２のｎ乗））と定めておく。
【０１３５】
通常のシーケンスであれば、ひとつのＯＲＢの処理終了後、SequenceIdentifierには後述のように１加算される。また、SequenceIdentifierとＯＲＢのSeq_IDは同じ桁数であり、Seq_IDも１ずつ加算される。そのため、支障なく処理が進んでいる場合には、SequenceIdentifierとＯＲＢのSeq_IDとは、ステップＳ２００３において一致しているはずである。したがって、正常に処理が進めば、処理はステップＳ２００３からステップＳ２００４に移行する。
【０１３６】
そこでは、クライアントがバッファを用意してあるか調べ（ステップＳ２００４）、用意できたなら、ＯＲＢのdata_descriptorの値と実行エージェントが保持するNextexecPointerに格納されたｏｆｆｓｅｔ値とを加えたアドレスから所定サイズのデータアクセスを行い、クライアントが用意したバッファとの間でデータをやりとりする（ステップＳ２００５）。
【０１３７】
新たにＯＲＢの処理を行う場合には、ｏｆｆｓｅｔは０であるから、ＯＲＢにより指し示されるバッファの先頭から読み出すことになる。また、途中まで読み出されているバッファを続きから読む場合には、ｏｆｆｓｅｔは、バッファ中における続きのアドレスを示しているので、これを加算することで続きから読み出しを続行できる。データをバッファに格納したなら、data_descriptorの値＋ｏｆｆｓｅｔが次に読み出されるアドレスを指すように、NextexecPointerを更新する（ステップＳ２００６）。このような読み書きを、ＯＲＢのdata_sizeで示されるサイズ分に達するまで行う（ステップＳ２００７）。
【０１３８】
こうして１つのＯＲＢの処理を終えると、SequenceIdentifierに１加算して更新し（ステップＳ２００８）、NextexecPointer（ｏｆｆｓｅｔ）を０に初期化する（ステップＳ２００９）。
【０１３９】
処理を終えたなら、処理完了を通知するステータスブロックを作成し（ステップＳ２０１０）、ステータスＦＩＦＯに書き込み（ステップＳ２０１１）、ターゲットのクライアントに処理完了を通知する（ステップＳ２０１２）。それと同時に当該コマンドを指していた参照キュー内のポインタを空参照リストに戻す。
【０１４０】
ステップＳ２００３において、ＯＲＢのSeq_IDがSequenceIdentifierよりも小さい場合は、バスリセットなどにより、イニシエータが図１８の手順でＯＲＢリストを再生したような場合である。例えば、あるＯＲＢについて、ターゲットは処理を終え、SequenceIdentifierの値も更新していても、そのステータスブロックがイニシエータに届いていない時点でバスリセットが発生すると、イニシエータはそのＯＲＢもＯＲＢリストに入れてしまう。この場合に、ＯＲＢのSeq_IDよりも実行エージェントのSequenceIdentifierの方が大きくなる。この場合には、そのＯＲＢは処理を終えているため、ステップＳ２０１０以降によりステータスブロックをイニシエータに渡す。
【０１４１】
＜イニシエータの接続手順＞
図１６はイニシエータ側のクライアントからのオープン要求に対する処理手順を示したものである。クライアントからのオープン要求を受けると、まず、接続先のターゲットとの間に既にＳＢＰ−２のコネクション（ログイン状態）があるか否かを確認する（ステップＳ２５０１）。既にＳＢＰ−２コネクションがあれば、ステップＳ２５０７へ進み、まだＳＢＰ−２コネクションがなければ、ターゲットに対してログイン要求（ＳＢＰ−２コネクト要求）を発行する（ステップＳ２５０２）。ログインが成功したかどうかを確認し（Ｓ２５０３）、ログインに失敗した場合はステップＳ２５１３に進み戻り値にエラーコードをセットしてリターンし、ログインに成功した場合は、QueueIDが０のＩ／Ｏ要求キューを作成し、そこにクエリーコマンドを発行する（ステップＳ２５０４）。次にクエリーコマンドが成功したか否かを確認し（ステップＳ２５０５）、失敗ならステップＳ２５１２へ進み、ログアウト実行後Ｓ２５１３へと進む。クエリーコマンドが成功したら、クエリーコマンドに対するステータスブロックの"Init_POOL"を元にCurrent-POOLカウンタをセットする。この時既にQueueIDが０に対応するＩ／Ｏ要求キューは暗黙に形成されているので、QueueIDが０に対応するＩ／Ｏ要求キューの予約域として１以上をセットし、残りをCurrent-POOLカウンタにセットする（ステップＳ２５０６）。
【０１４２】
さらに、ステップＳ２５０７へ進んでQueueIDが０に対応するＩ／Ｏ要求キューに対して所望のServiceID,Modeを指定し、コネクトコマンドをキューする（ステップＳ２５０７）。コネクト時、ターゲットに対して、プリフェッチプールの増量を求める場合は"i"ビットを１にセットする。次にコネクトコマンドが成功したか否かを確認し（ステップＳ２５０８）、失敗であれば、ステップＳ２５１１で暗黙に用意されるQueueID0以外で既に他のＩ／Ｏ要求キューが存在しているかどうかを確認し、存在していなければターゲットからログアウトし（ステップＳ２５１２）、Ｓ２５１３に進み、存在していれば、ログアウトせずにＳ２５１３に進む。一方、コネクトコマンドが成功するとステータスブロックのQueueID1,QueueID2に対応して、新しいＩ／Ｏ要求キューを作成し、後にクライアントがこのコネクションを特定する為のハンドルを対応付ける。また、ステータスブロックのPOOL_Incフィールドと現在のCurrent-POOLレジスタの合計から、各キューに対して１以上の予約域をセットし、残りの数でCurrent-POOLレジスタを更新する（ステップＳ２５０９）。最後に作成されたＩ／Ｏ要求キューに対応させたハンドルを戻り値にセットし（ステップＳ２５１０）呼び出し元のクライアントにリターンする。
【０１４３】
＜ターゲットの接続手順＞
図１７は、図１６のイニシエータ側のクライアントからのオープン要求に対する処理手順に対応するターゲット側の処理手順を示したものである。
【０１４４】
まず、ターゲットはログイン要求が来るのを待つ（ステップＳ２６０１）。
【０１４５】
ログイン要求が来るとターゲットはＳＢＰ−２に規定された動作であるイニシエータのＩＤの確認、ログインディスクリプタの作成等を行うとともに、少なくとも１つのエントリを持ったプリフェッチプールを作成し、プリフェッチプール内のそれぞれのエントリに対するポインタのリストである空参照リストを作成する。また、QueueIDが０の参照キューの為のポインタ等も用意する（ステップ２６０２）。これらの準備が整ったら、ターゲットはイニシエータにＳＢＰ−２で規定されているログインレスポンスを返す（ステップ２６０３）。次にターゲットはクエリーコマンドが来るのを待つ（ステップ２６０４）。クエリーコマンドが来たら、作成したプリフェッチプールのサイズを"Init_POOL"フィールドに入れてクエリーコマンドに対するステータスブロックを送出する（ステップＳ２６０５）。ここまででＳＨＰＴ−２による通信の準備が出来たことになる。
【０１４６】
以降２６１０以下のループはQueueID0の参照キューに基づく実行エージェントの処理手順となる。Ｓ２６０６でコマンドがコネクトコマンドか否かを確認する。コネクトコマンドでなければＳ２６０９でそのコマンドの処理を行い２６１０へ戻る。コネクトコマンドであれば、Modeフィールドで指定されたモードにしたがって１つ或いは２つの参照キューの為のポインタ等を作成する。この時、コネクトコマンドの"i"ビットが１であれば、作成した参照キューの数以上の数のエントリをプリフェッチキューに追加し（ステップＳ２６０７）、作成した参照キューのID及びプリフェッチキューに追加したエントリ数をコネクトコマンドに対するステータスブロックでイニシエータに返す（ステップＳ２６０８）。この後から作成された参照キューを用いてクライアント間の通信が可能となる。
【０１４７】
＜イニシエータの接続終了手順＞
図２１はイニシエータ側のクライアントからのクローズ要求に対する処理手順を示したものである。クローズ要求があると、まず、ディスコネクトコマンドを発行する。該当するQueueIDのＩ／Ｏ要求キューに既にキューイングされているコマンドを終了してからディスコネクトしたい場合にはディスコネクトコマンドのQueueIDフィールドを当該QueueIDにし、キューイングされているコマンドにかかわらずディスコネクトしたい場合は、QueueID0にディスコネクトコマンドを発行する。この場合、QueueID1,QueueID2フィールドでディスコネクトするキューを指定する（ステップＳ２７０１）。次にディスコネクトコマンドが完了するのを待ち（ステップＳ２７０２）、完了後、もし現在のＯＲＢリストの中にディスコネクトしたキューに対するＯＲＢが残っていればそれらをＳＢＰ−２の規定する制御フィールドによって全て無効化し、コネクト時に作成されたＩ／Ｏ要求キューを開放するとともに、そのＩ／Ｏ要求キューのCurrent-QUEカウンタで示されていた現在のＯＲＢリスト内のＯＲＢ数分Current-POOLカウンタを増やし、さらにコネクト時に受け取ったプリフェッチプールの増加分を減ずる（ステップＳ２７０３）。さらに、ステップＳ２７０４で暗黙に用意されるQueueID0以外で既に他のＩ／Ｏ要求キューが存在しているかどうかを確認し、存在していなければターゲットからログアウトし（ステップＳ２７０５）、そして、コネクト時に割り当てたハンドルを開放し、リターンする。
【０１４８】
＜ターゲットの接続終了手順＞
図２２はターゲットのディスコネクト処理手順を示したものである。この手順は図１７のステップＳ２６０９に位置するものである。まず、ディスコネクトコマンドかどうかを判定し（ステップＳ２８０１）、ディスコネクトコマンドでなければさらに他のコマンドの処理（ステップ２８０７）を行う。ディスコネクトコマンドであれば、ディスコネクトの対象となる参照キューで参照されているコマンドでディスコネクトコマンド以外に実行されているコマンドがあればその実行を停止する（ステップＳ２８０２）。実行を停止した後、その参照キューで参照されているディスコネクト以外のコマンドに対するステータスブロックで未送出のものがあれば全て送出する（ステップＳ２８０３）。その後ディスコネクトコマンドに対するステータスブロックを返す（ステップＳ２８０４）。この時点で当該参照キューに残っている未処理のポインターを全て空参照リストへと戻す（ステップＳ２８０５）。コネクト時にプリフェッチプールの増加を行っていればその増加分を減少し、減少分を参照している空参照リスト内のポインタを削除する。さらに参照キューの為のポインタ等も削除し（ステップＳ２８０６）リターンする。
【０１４９】
図７に示したように、ＯＲＢにはQueueIDというキュー識別子のフィールドを備えている。そのため、ＳＨＰＴ−２処理部及びＯＲＢディスパッチャがキュー識別子を識別して、それぞれがキューごとに独立し実行すなわちＯＲＢの生成・処理が行われることにより、複数のキューによるマルチコネクション（チャネル）を実現することができる。この場合、１つの機器であっても、そこに含まれる複数のクライアントそれぞれに１つのコネクション（チャネル）を割り当てることで、クライアントごとに非同期の通信を行わせることができる。このため、例えばデジタル複合機であれば、それが有するスキャナやプリンタそれぞれについてクライアントとなるアプリケーションを設けておけば、それと接続されたホストコンピュータからは、あたかもそれぞれの機能を独立した機器であるかのように使用することができる。フローチャートで示したように、各キューの管理や実行エージェントは論理的に独立したプロセスであるために、マルチコネクション（チャネル）化は容易に行うことができる。
【０１５０】
またこのQueueIDにより識別される２つのキューを１つのコネクションに用いることによって、イニシエータとターゲットとの間で、簡素な制御手順によりデータの交換が双方向に行える。すなわち、イニシエータは所望のときに所望のデータをターゲットに渡すことができる。また、ターゲットは、イニシエータから渡されたデータをターゲット自身の都合に合わせて読み出すことができる。また、ターゲットはイニシエータが準備していさえすれば、自発的であろうと、あるいはイニシエータからの要求であろうと、何時でもイニシエータにデータを渡すことができる。また、バスリセットが発生しても、バスリセット直前の状態からの処理の続行を保証することができる。
【０１５１】
さらに、キューによる多重化路におけるターゲットのコマンドプール領域全体の割り当てをイニシエータが動的に行うことによって、通信効率及びターゲットのリソース利用効率が向上するとともに、コネクションに用いられるキュー数に応じてターゲットのコマンドプール領域の増減が行われることにより、ターゲットのリソース利用効率が向上する。
【０１５２】
（他の実施形態）
なお、本発明は、複数の機器（例えばホストコンピュータ，インタフェイス機器，リーダ，プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機，ファクシミリ装置など）に適用してもよい。
【０１５３】
また、本発明の目的は、イニシエータとして図３〜図６、図１６、図１８、図２１の手順のプログラムコードを記録した記憶媒体をコンピュータに供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても達成される。またターゲットも、図１７、図１９〜図２０、図２２の手順のプログラムコードを記録した記憶媒体をコンピュータに供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによって実現できる。
【０１５４】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１５５】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
【０１５６】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１５７】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１５８】
また、記憶媒体から読み出されたプログラムコードを実行してイニシエータとなる主体はコンピュータに限らず、データ転送機器であって、ＳＢＰ−２のログイン能力があれば、どのような機器であっても良い。
【０１５９】
また、ターゲットは、複数の参照キューを用いることにより、たとえば、第１の参照キューに印刷ジョブを格納し、第２のキューにターゲットの状態を確認するためのリードコマンドを格納し、第３のキューにフィニッシャー制御コマンドを格納することにより、パイプライン処理が実現でき、印刷ジョブに基づく印刷が完了したら、フィニッシャーによる機能の実行が終了する前に、第１の参照キューに次の印刷ジョブを格納できる。
【０１６０】
（第２の実施の形態）
第一の実施の形態においては、ディスコネクト時プリフェッチプールの容量は、対応するコネクト時の増量分だけ減少するように構成されているが、ディスコネクト時にイニシエータが減少分を指示するように構成されてもよい。この場合、図１１のディスコネクトコマンドＯＲＢに対して、図２３の如く、POOL_Decフィールド３０９ｆを設け、イニシエータがディスコネクトコマンドを発行時にこのフィールドにターゲットに開放させるプリフェッチプールの量を指定し、図２１のステップＳ２７０１でコマンドを発行し、ターゲットは図２２のステップＳ２８０６でPOOL_Decフィールドで指定された量だけプリフェッチプールを減ずればよい。
【０１６１】
この実施の形態によっても第一の実施の形態同様の下記のごとき効果が得られる。ＳＨＰＴ−２処理部及びＯＲＢディスパッチャがキュー識別子を識別して、それぞれがキューごとに独立し実行すなわちＯＲＢの生成・処理が行われることにより、複数のキューによるマルチコネクション（チャネル）を実現することができる。この場合、１つの機器であっても、そこに含まれる複数のクライアントそれぞれに１つのコネクション（チャネル）を割り当てることで、クライアントごとに非同期の通信を行わせることができる。
【０１６２】
このため、例えばデジタル複合機であれば、それが有するスキャナやプリンタそれぞれについてクライアントとなるアプリケーションを設けておけば、それと接続されたホストコンピュータからは、あたかもそれぞれの機能を独立した機器であるかのように使用することができる。フローチャートで示したように、各キューの管理や実行エージェントは論理的に独立したプロセスであるために、マルチコネクション（チャネル）化は容易に行うことができる。
【０１６３】
またこのQueueIDにより識別される２つのキューを１つのコネクションに用いることによって、イニシエータとターゲットとの間で、簡素な制御手順によりデータの交換が双方向に行える。すなわち、イニシエータは所望のときに所望のデータをターゲットに渡すことができる。また、ターゲットは、イニシエータから渡されたデータをターゲット自身の都合に合わせて読み出すことができる。また、ターゲットはイニシエータが準備していさえすれば、自発的であろうと、あるいはイニシエータからの要求であろうと、何時でもイニシエータにデータを渡すことができる。また、バスリセットが発生しても、バスリセット直前の状態からの処理の続行を保証することができる。
【０１６４】
さらに、キューによる多重化路におけるターゲットのコマンドプール領域全体の割り当てをイニシエータが動的に行うことによって、通信効率及びターゲットのリソース利用効率が向上するとともに、コネクションに用いられるキュー数に応じてターゲットのコマンドプール領域の増減が行われることにより、ターゲットのリソース利用効率が向上する。
【０１６５】
（第３の実施の形態）
また、第一の実施の形態においてはイニシエータはコネクトコマンドにおいて"i"ビットにより、プリフェッチプールの増加を要求するか否かのみを指定するように構成されていたが、イニシエータが増加数を指定して増加を要求することも可能である。この場合、図１０のコネクトコマンドにおける"i"フィールドのビット数を増やし、増加数を示すようにすればよい。さらに、第一の実施の形態においては、イニシエータ側におけるキューに対するプリフェッチプールに対応した予約域はコネクト時にのみ設定されるように構成されていたが、コネクト時以外にも予約域を増減できるように構成することも可能である。この場合、予約域の増加分はCurrent-POOLカウンタの値を超えないようにし、その範囲内で、予約域数を増し、Current-POOLカウンタを減ずる。減少するには、Current-QUEカウンタで示される現在のＯＲＢリスト内での当該キューに属するＯＲＢ数が予約域数を下回っている場合、その差分を上限として、その範囲内でなおかつ減少後の予約域数が１以上となる範囲で減少をさせることが可能である。この場合、その範囲内で予約域数を減じ、Current-POOLカウンタを増やす。
【０１６６】
この実施の形態によっても第一の実施の形態同様の下記のごとき効果が得られる。ＳＨＰＴ−２処理部及びＯＲＢディスパッチャがキュー識別子を識別して、それぞれがキューごとに独立し実行すなわちＯＲＢの生成・処理が行われることにより、複数のキューによるマルチコネクション（チャネル）を実現することができる。この場合、１つの機器であっても、そこに含まれる複数のクライアントそれぞれに１つのコネクション（チャネル）を割り当てることで、クライアントごとに非同期の通信を行わせることができる。
【０１６７】
このため、例えばデジタル複合機であれば、それが有するスキャナやプリンタそれぞれについてクライアントとなるアプリケーションを設けておけば、それと接続されたホストコンピュータからは、あたかもそれぞれの機能を独立した機器であるかのように使用することができる。フローチャートで示したように、各キューの管理や実行エージェントは論理的に独立したプロセスであるために、マルチコネクション（チャネル）化は容易に行うことができる。
【０１６８】
またこのQueueIDにより識別される２つのキューを１つのコネクションに用いることによって、イニシエータとターゲットとの間で、簡素な制御手順によりデータの交換が双方向に行える。すなわち、イニシエータは所望のときに所望のデータをターゲットに渡すことができる。また、ターゲットは、イニシエータから渡されたデータをターゲット自身の都合に合わせて読み出すことができる。また、ターゲットはイニシエータが準備していさえすれば、自発的であろうと、あるいはイニシエータからの要求であろうと、何時でもイニシエータにデータを渡すことができる。また、バスリセットが発生しても、バスリセット直前の状態からの処理の続行を保証することができる。
【０１６９】
さらに、キューによる多重化路におけるターゲットのコマンドプール領域全体の割り当てをイニシエータが動的に行うことによって、通信効率及びターゲットのリソース利用効率が向上するとともに、コネクションに用いられるキュー数に応じてターゲットのコマンドプール領域の増減が行われることにより、ターゲットのリソース利用効率が向上する。
【０１７０】
（第４の実施の形態）
上記実施の形態においては、プリフェッチプールの増加・減少は、コネクト（図１０）・ディスコネクトコマンド（図２３）の"i"ビット３０９ｅ，"POOL_Dec"フィールド等で指定していたか、コネクトステータス（図１４）の"POOL_Inc"フィールドで指定されたもとを用いていたが、これらの代わりにプリフェッチプール増加・減少の為の独立したコマンドを設けてもよい。
【０１７１】
図２５はプリフェッチプール容量変更コマンド（ファンクションコード＝Ｃ３Ｈ）のフォーマットを示している。図２５において"delta"フィールド３０９ｇは２の補数形式の符号付の数値を示しており、このフィールドが正であればプリフェッチプールの増加を、負であればプリフェッチプールの減少をターゲットに指示する。ターゲットはこのコマンドの指示に従って実際にプリフェッチプールの増加・減少を行う。
【０１７２】
このコマンドを使った場合、イニシエータのクライアントからのオープン要求処理時には、図１６のステップＳ２５０７に先だって、プリフェッチプールの増加が必要であればイニシエータはプリフェッチプール変更コマンドを発行し、プリフェッチプールを増加させる。ターゲットは図１７におけるステップＳ２６０７以前に必要であればすでにプリフェッチプール変更コマンドを別途受けているので、ステップＳ２６０７では、参照キューの為のポインタ等のみを作成することになる。また、イニシエータのクライアントからのクローズ要求処理時には、ディスコネクトコマンドが成功した後（ステップＳ２７０３）に、プリフェッチプール容量変更命令を発行してプリフェッチプールを減少させる。ターゲットは後にイニシエータからプリフェッチプール容量変更コマンドが発行されるはずなので、ディスコネクトコマンドの処理（図２２）においては、ステップＳ２８０６では参照キューに用いるポインタ等のみを削除し、プリフェッチプールの減少は行わない。
【０１７３】
この実施の形態によっても第一の実施の形態同様の下記のごとき効果が得られる。ＳＨＰＴ−２処理部及びＯＲＢディスパッチャがキュー識別子を識別して、それぞれがキューごとに独立し実行すなわちＯＲＢの生成・処理が行われることにより、複数のキューによるマルチコネクション（チャネル）を実現することができる。この場合、１つの機器であっても、そこに含まれる複数のクライアントそれぞれに１つのコネクション（チャネル）を割り当てることで、クライアントごとに非同期の通信を行わせることができる。
【０１７４】
このため、例えばデジタル複合機であれば、それが有するスキャナやプリンタそれぞれについてクライアントとなるアプリケーションを設けておけば、それと接続されたホストコンピュータからは、あたかもそれぞれの機能を独立した機器であるかのように使用することができる。フローチャートで示したように、各キューの管理や実行エージェントは論理的に独立したプロセスであるために、マルチコネクション（チャネル）化は容易に行うことができる。
【０１７５】
またこのQueueIDにより識別される２つのキューを１つのコネクションに用いることによって、イニシエータとターゲットとの間で、簡素な制御手順によりデータの交換が双方向に行える。すなわち、イニシエータは所望のときに所望のデータをターゲットに渡すことができる。また、ターゲットは、イニシエータから渡されたデータをターゲット自身の都合に合わせて読み出すことができる。また、ターゲットはイニシエータが準備していさえすれば、自発的であろうと、あるいはイニシエータからの要求であろうと、何時でもイニシエータにデータを渡すことができる。また、バスリセットが発生しても、バスリセット直前の状態からの処理の続行を保証することができる。
【０１７６】
さらに、キューによる多重化路におけるターゲットのコマンドプール領域全体の割り当てをイニシエータが動的に行うことによって、通信効率及びターゲットのリソース利用効率が向上するとともに、コネクションに用いられるキュー数に応じてターゲットのコマンドプール領域の増減が行われることにより、ターゲットのリソース利用効率が向上する。
【０１７７】
また、ＩＥＥＥ１３９４インターフェースを利用しているために、ターゲット側へのデータ転送を、ターゲットがその都合に応じて読み出すことで行うことができ、イニシエータがターゲットの都合によってデータ転送に占有されることを防止できる。
【０１７８】
また、ＳＢＰ−２プロトコルを利用しているため、ターゲットでキューされるのはＯＲＢだけで、実際に転送されるデータそのものは処理待ちの間イニシエータに格納されている。このため、ターゲットのメモリ資源を小容量化できる。
【０１７９】
また、最新の処理状態を保持することで、バスリセットが発生しても、バスリセット後に、バスリセット直前の状態から処理を再開することができ、処理の正常な続行を保証することができる。
【０１８０】
【発明の効果】
以上説明したように、本発明によれば、イニシエータとターゲットとの間において、１回のログインで非同期な双方向通信及びそのマルチチャネル化を可能とし、また、データの交換に必要なプロセスやメモリといった資源を効率的に利用できる。
【０１８１】
また、イニシエータからターゲットに送信できる命令の数の管理をターゲットの各キュー毎に行うのではではなく、一元管理することにより効率的にリソースを利用できる。
【０１８２】
また、キュー数の増加に応じて、ターゲットが保持できる命令の総和を増加させる、またはイニシエータの命令パラメータに従ってターゲットが保持できる命令の総和を増加させる、またはキュー数の減少に応じて、ターゲットが保持できる命令の総和を減少させる、またはイニシエータの命令パラメータに従ってターゲットが保持できる命令の総和を減少させることにより、ターゲットのリソース利用効率を向上させるようにする。
【図面の簡単な説明】
【図１】ターゲット（プリンタ）のブロック図である。
【図２】イニシエータ（ホストコンピュータ）のブロック図である。
【図３】イニシエータのクライアントによる、データ転送要求の発生時の処理手順のフローチャートである。
【図４】イニシエータのクライアントによる、ＳＨＰＴ−２からの処理終了通知受信時の処理手順のフローチャートである。
【図５】イニシエータのＳＨＰＴ−２処理部により実行される、クライアントからコールされるライト関数、リード関数のフローチャート、及び、イニシエータのＳＨＰＴ−２処理部により実行される、Ｉ／Ｏ要求キューの管理手順のフローチャートである。
【図６】イニシエータのＳＨＰＴ−２処理部により実行される、ステータスブロック受信時の処理手順のフローチャートである。
【図７】ＯＲＢ一般のフォーマットを示す図である。
【図８】ライトコマンドＯＲＢのフォーマットを示す図である。
【図９】リードコマンドＯＲＢのフォーマットを示す図である。
【図１０】コネクトコマンドＯＲＢのフォーマットを示す図である。
【図１１】ディスコネクトコマンドＯＲＢのフォーマットを示す図である。
【図１２】クエリーコマンドＯＲＢのフォーマットを示す図である。
【図１３】ステータスブロック一般のフォーマットを示す図である。
【図１４】コネクトステータスブロックのフォーマットを示す図である。
【図１５】クエリーステータスブロックのフォーマットを示す図である。
【図１６】イニシエータのＳＨＰＴ−２処理部により実行される、クライアントからのオープン要求に対する処理手順のフローチャートである。
【図１７】ターゲットのコネクト要求に対する処理手順のフローチャートである。
【図１８】イニシエータのＳＨＰＴ−２処理部により実行される、バスリセット直後の復旧処理手順のフローチャートである。
【図１９】ドアベルレジスタあるいはＯＲＢポインタに書き込みが行われた際のターゲットのフェッチエージェントによる処理手順のフローチャートである。
【図２０】ターゲットの実行エージェントによる処理手順のフローチャートである。
【図２１】イニシエータのＳＨＰＴ−２処理部により実行される、クライアントからのクローズ要求に対する処理手順のフローチャートである。
【図２２】ターゲットのディスコネクト要求に対する処理手順のフローチャートである。
【図２３】第２の実施の形態におけるディスコネクトコマンドＯＲＢのフォーマットを示す図である。
【図２４】ＩＥＥＥ１３９４インターフェースを用いたプリンタシステムのハードウエア構成図である。
【図２５】プリフェッチプール容量変更コマンドのフォーマットを示す図である。
【符号の説明】
１  ＣＰＵ
２  ＲＡＭ
３  ＲＯＭ
４  システムバス
１２  ＣＰＵ
１３  ＲＯＭ
１９  ＲＡＭ
１０１  フェッチエージェント
１０３  プリフェッチプール
１０５  参照キュー
１０６  実行エージェント
１０８  ターゲット側クライアント
１０９  １３９４インターフェース
１１０  バスインターフェース
２０１  ＳＨＰＴ−２処理部
２０２ａ  Ｉ／Ｏ要求キュー
２０４  ＯＲＢリスト
２０５  ステータスＦＩＦＯ
２０６  イニシエータ側クライアント
２０７  ライトバッファ
２０８  リードバッファ
【図１】
0004109770.tif 000002
【図２】
0004109770.tif 000003
【図３】
0004109770.tif 000004
【図４】
0004109770.tif 000005
【図５】
0004109770.tif 000006
【図６】
0004109770.tif 000007
【図７】
0004109770.tif 000008
【図８】
0004109770.tif 000009
【図９】
0004109770.tif 000010
【図１０】
0004109770.tif 000011
【図１１】
0004109770.tif 000012
【図１２】
0004109770.tif 000013
【図１３】
0004109770.tif 000014
【図１４】
0004109770.tif 000015
【図１５】
0004109770.tif 000016
【図１６】
0004109770.tif 000017
【図１７】
0004109770.tif 000018
【図１８】
0004109770.tif 000019
【図１９】
0004109770.tif 000020
【図２０】
0004109770.tif 000021
【図２１】
0004109770.tif 000022
【図２２】
0004109770.tif 000023
【図２３】
0004109770.tif 000024
【図２４】
0004109770.tif 000025
【図２５】
0004109770.tif 000026