JP4111472B2 - 通信制御方法及び装置及び通信システム - Google Patents
通信制御方法及び装置及び通信システム Download PDFInfo
- Publication number
- JP4111472B2 JP4111472B2 JP13399498A JP13399498A JP4111472B2 JP 4111472 B2 JP4111472 B2 JP 4111472B2 JP 13399498 A JP13399498 A JP 13399498A JP 13399498 A JP13399498 A JP 13399498A JP 4111472 B2 JP4111472 B2 JP 4111472B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- initiator
- instruction
- target
- identifier
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/9063—Intermediate storage in different physical parts of a node or terminal
- H04L49/9068—Intermediate storage in different physical parts of a node or terminal in the network interface card
- H04L49/9073—Early interruption upon arrival of a fraction of a packet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40123—Interconnection of computers and peripherals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/901—Buffering arrangements using storage descriptor, e.g. read or write pointers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/9047—Buffering arrangements including multiple buffers, e.g. buffer pools
- H04L49/9052—Buffering arrangements including multiple buffers, e.g. buffer pools with buffers of different sizes
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Communication Control (AREA)
- Computer And Data Communications (AREA)
- Accessory Devices And Overall Control Thereof (AREA)
- Record Information Processing For Printing (AREA)
Description
【０００１】
【産業上の利用分野】
本発明は、例えばホストコンピュータとプリンタ等の機器同士を接続する通信制御方法及び装置に関する。
【０００２】
【従来の技術】
近年、ＩＥＥＥ１３９４インターフェースが、コンピュータと周辺機器、あるいは周辺機器同士の接続に用いられつつある。ＩＥＥＥ１３９４インターフェースは、セントロニクスインターフェースなどのハンドシェイク方式に比べて高速で、しかも双方向通信が可能である。また、メモリバスモデルのインターフェースであり、ＩＥＥＥ１３９４インターフェースで接続された機器は、相手の機器に対して指定されたアドレスのデータを読み書きすることができる。
【０００３】
このＩＥＥＥ１３９４は、広範囲に応用するための物理層及びリンク層のプロトコルを定めたもので、機器ごとの詳細なプロトコルは定められていない。そのため、物理・リンク層としてＩＥＥＥ１３９４を利用したＳＢＰ(Serial Bus Protocol)−２などのトランスポート層のプロトコルが提案されている。トランスポート層はアプリケーションに対してデータ転送機能を提供する層であり、この層を利用するアプリケーションは、互いにデータの交換が可能となる。
【０００４】
このＳＢＰ−２なるプロトコルは、ＩＥＥＥ１３９４のメモリバスモデルとしての特徴を活かしたプロトコルであり、データの受信側がそれ自身の都合に応じてデータを受信することができる。これに対して、ＳＢＰ−２以外のプロトコルには、非同期に発生するデータの転送が可能となるものも、マルチチャネルが実現できるものもあるが、そのようなプロトコルではＩＥＥＥ１３９４のメモリバスモデルとしての特徴を活かすことができない。すなわち、ホストとプリンタの通信であれば、プリンタ側の都合に応じてデータ転送を行うことができず、ホストがプリンタの状態を監視しながらデータ転送を行わねばならないことになる。
【０００５】
ＳＢＰ−２では、データを転送する場合に、まず送信側でログインという操作を行って通信相手との間のチャネルを確立する。この際、ログインした側がイニシエータと呼ばれ、イニシエータと接続された相手側がターゲットと呼ばれる。データ転送は、イニシエータからの指示に応じて、ターゲットからイニシエータのバッファにデータを読み書きすることで行われる。この方式においては、イニシエータは、送信するデータを格納したバッファのアドレスやサイズ等が書かれたＯＲＢ(Operation Request Block)を作成し、そのＯＲＢのアドレスをターゲットに知らせる。ターゲットでは自分の都合に合わせてＯＲＢに書かれたアドレスやサイズに基づいてイニシエータからデータを読み出し、あるいはデータを書き込み、それらの処理後ステータスブロックを作成して、処理の状態をイニシエータに知らせることになる。
【０００６】
【発明が解決しようとする課題】
このＩＥＥＥ１３９４の上に構築されるＳＢＰ−２プロトコルを利用して通信を行う場合、特に、ホストコンピュータ等のデータ源をイニシエータとし、それからターゲットであるプリンタ装置などの周辺機器へのデータ転送に応用する場合、次のような４つの問題点があった。
（問題点１）全２重通信のために手順が複雑である。
【０００７】
ＳＢＰ−２では、基本的にデータの転送はイニシエータによって管理され、ターゲットはイニシエータへの非同期のデータ転送を行うことができない。すなわち、ＳＢＰ−２では、ターゲットがイニシエータへのデータ転送を行いたい時には、イニシエータに対してアンソリシテドステータスでデータリード要求を送り、イニシエータはそれに応じてＯＲＢ生成し、ペンディング中のＯＲＢ（イニシエータからターゲットへのデータ転送要求などが含まれている）のリストの末尾にその生成したＯＲＢをつける。このＯＲＢは先頭から順番に処理されるため、ターゲットがイニシエータにリード要求を発行したタイミングではなく、イニシエータ側のＯＲＢの処理が進み、ターゲットからのデータリード要求によるＯＲＢが処理されたときに初めてターゲットからイニシエータにデータが転送されることになる。すなわち、双方向の非同期なデータ転送が行えず、ターゲットからイニシエータに転送すべきデータが非同期に発生する場合、例えばターゲットがプリンタであれば、そのプリンタでエラーが発生する場合など、直ちにイニシエータに伝達すべきデータを即時に伝達できない。
【０００８】
このため、例えばプリンタで非同期に発生するデータを即座にホストに転送するためには、プリンタをイニシエータとしてログイン手続きを行い、ホストコンピュータをターゲットとするデータ転送を行わねばならない。
【０００９】
このようにホストコンピュータとプリンタで互いにログインしてそれぞれがイニシエータでありターゲットであるような状況では、ホストコンピュータ及びプリンタの双方にイニシエータとしてのプロセスとターゲットとしてのプロセスを備えなければならない。また、ログインの操作もプリンタから行わねばならない。
【００１０】
プリンタのような画像を扱う周辺装置では、画像処理のために大量のメモリ資源やプロセッサ資源を消費する。そのために、装置の構成を簡略化して原価を節減したり、処理を迅速に行うため画像処理用途以外に用いられる資源をできるだけ節約しなければならない。しかし、上述のように多くのプロセスを稼働することになればその分多くの資源を消費することになり、原価低減・処理の効率化という目的に反することになる。
【００１１】
また、ホストコンピュータとプリンタとの関係であれば、各方向に流れるデータは、印刷データとそれに対する処理状況といったように、互いに関連付けられるものであるが、各方向について独立したログインによりチャネルを設定すると、それらデータとレスポンスとを関連づけなければならず、そのための処理手順を新たに追加する必要がある。
【００１２】
このようにＩＥＥＥ１３９４及びＳＢＰ−２をそのままホストコンピュータ−プリンタ装置間の通信に適用することは適切でなく、各装置において必要とされる資源を減らすことや効率を向上させることが難しかった。
（問題点２）マルチチャネルを実現できない。
【００１３】
最近、周辺装置として種々の機能を複合させた複合機が利用されつつある。例えば、ファクシミリ装置を、スキャナ単体，プリンタ単体，ファクシミリとしてホストコンピュータ等から利用できるデジタル複合機などがある。このような装置を利用する際には、各単体機能ごとに独立した複数のチャネルを介して通信を行えば、同時に複数の機能を利用することができる。
【００１４】
しかしながら、ＳＢＰ−２では、マルチチャネルを提供できないため、そのように単体機能を同時に利用することが難しい。
（問題点３）バスリセットに対応できない。
【００１５】
ＩＥＥＥ１３９４では、１３９４シリアルバスへの機器の新たな接続や取り外し、あるいは、接続された機器の電源投入や切断といった、ネットワーク構成の変化要因となる状態変化が発生するとバスリセットが発生する。バスリセットは、バス上で上記のような状態変化を検知したノードがバスリセット信号をバス上に送信することで発生する。発生されたバスリセット信号は、ノードからノードへと伝達され、ネットワーク上の全ノードがバスリセット信号を受信すると、バスリセットのための一連の動作が各ノードで行われる。
【００１６】
このようにバスリセットは、ネットワーク上のノードにおける処理とは非同期に発生する。また、バスリセットの原因となったノードとアプリケーションについては無関係なノードであっても、一旦バスリセットが発生してしまえばバスリセットの処理を行わねばならない。このバスリセットの過程で、ＳＢＰ−２で通信を行っているノードでは、設定されていたコネクションが切断されてしまい、再度コネクションをつなげてもバスリセット直前の状態から処理を続行できる保証が与えられていない。
【００１７】
本発明は上記従来例に鑑みてなされたもので、１回のログインで全２重通信（互いに非同期な双方向通信）を可能とし、また、データの交換に必要なプロセスやメモリといった資源を効率的に利用できる通信制御方法及び装置及びそれを用いた印刷装置を提供することを目的とする。
【００１８】
また、マルチチャネルを実現する通信制御方法及び装置及びそれを用いた印刷装置を提供することを目的とする。
【００１９】
また、バスリセットが発生しても、バスリセット直前の状態から処理の続行を保証する通信制御方法及び装置及びそれを用いた印刷装置を提供することを目的とする。
【００２０】
【課題を解決するための手段】
上記目的を達成するために本発明は次のような構成から成る。すなわち、イニシエータとターゲットとの間の通信制御方法であって、前記イニシエータにおいて、前記イニシエータが有する記憶領域においてデータの書き込みあるいは読み出しが行われるべきアドレスを有する命令を前記ターゲットに発行するステップと、前記ターゲットにおいて、発行された命令に従って、前記イニシエータが有する記憶領域における前記アドレスに対するデータの書き込みあるいは前記イニシエータが有する記憶領域における前記アドレスからのデータの読み出しを実行するステップと、前記ターゲットにおいて、データの書き込みあるいは読み出しを実行中の命令の識別子と、当該命令に従ってデータの書き込みあるいは読み出しを行うべき記憶領域を示す、当該命令に対応する前記アドレスからのオフセットとを保持するステップとを有し、前記イニシエータは、前記ターゲットに対して発行した命令を、当該命令に従ったデータの書き込みあるいは読み出しを完了した旨の完了通知を前記ターゲットから受けるまで、再発行可能な状態で保持し、前記通信制御方法はさらに、前記イニシエータと前記ターゲットとの間の接続が一旦切断されて再度確立された後、前記イニシエータにおいて、再発行可能な状態で保持している命令を前記ターゲットに再発行するステップと、前記ターゲットにおいて、再発行された命令の識別子と保持していた識別子とを比較するステップと、前記ターゲットにおいて、再発行された命令の識別子と保持していた識別子との一致を示す第１の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを保持していたオフセットに基づいて実行するステップと、前記ターゲットにおいて、再発行された命令が有する識別子と保持していた識別子との不一致を示す第２の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを実行することなく、再発行された命令に対する前記完了通知を前記イニシエータに発行するステップとを有する。
【００２１】
あるいは、イニシエータとターゲットの間でデータを交換する通信システムであって、前記イニシエータは、前記イニシエータが有する記憶領域においてデータの書き込みあるいは読み出しが行われるべきアドレスを有する命令を前記ターゲットに発行する第１の発行手段と、前記ターゲットに対して発行した命令を、当該命令に従ったデータの書き込みあるいは読み出しを完了した旨の完了通知を前記ターゲットから受けるまで、再発行可能な状態で保持する第１の保持手段とを有し、前記ターゲットは、発行された命令に従って、前記イニシエータが有する記憶領域における前記アドレスに対するデータの書き込みあるいは前記イニシエータが有する記憶領域における前記アドレスからのデータの読み出しを実行する第１の実行手段と、前記第１の実行手段によりデータの書き込みあるいは読み出しを実行中の命令の識別子と、当該命令に従ってデータの書き込みあるいは読み出しを行うべき記憶領域を示す、当該命令に対応する前記アドレスからのオフセットとを保持する第２の保持手段とを有し、前記イニシエータはさらに、前記イニシエータと前記ターゲットとの間の接続が一旦切断されて再度確立された後、再発行可能な状態で保持している命令を前記ターゲットに再発行する再発行手段を有し、前記ターゲットはさらに、再発行された命令の識別子と保持していた識別子とを比較する比較手段と、再発行された命令の識別子と保持していた識別子との一致を示す第１の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを保持していたオフセットに基づいて実行する第２の実行手段と、再発行された命令が有する識別子と保持していた識別子との不一致を示す第２の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを実行することなく、再発行された命令に対する前記完了通知を前記イニシエータに発行する第２の発行手段とを有する。
【００２２】
あるいは、イニシエータとの間でデータを通信するターゲットとしての通信制御装置であって、前記イニシエータによって発行された、前記イニシエータが有する記憶領域においてデータの書き込みあるいは読み出しが行われるべきアドレスを有する命令に従って、前記イニシエータが有する記憶領域における前記アドレスに対するデータの書き込みあるいは前記イニシエータが有する記憶領域における前記アドレスからのデータの読み出しを実行する第１の実行手段と、前記イニシエータによって発行された命令に従ったデータの書き込みあるいは読み出しを完了した旨の完了通知を前記イニシエータに発行する第１の発行手段と、前記第１の実行手段によりデータの書き込みあるいは読み出しを実行中の命令の識別子と、当該命令に従ってデータの書き込みあるいは読み出しを行うべき記憶領域を示す、当該命令に対応する前記アドレスからのオフセットとを保持する識別子保持手段と、前記イニシエータと前記ターゲットとの間の接続が一旦切断されて再度確立された後、前記イニシエータによって再発行された命令の識別子と前記識別子保持手段によって保持されている識別子とを比較する比較手段と、前記比較手段による一致を示す第１の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを前記識別子保持手段によって保持されているオフセットに基づいて実行する第２の実行手段と、前記比較手段による不一致を示す第２の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを実行することなく、再発行された命令に対する前記完了通知を前記イニシエータに発行する第２の発行手段とを有する。
【００２３】
あるいは、イニシエータとの間でデータを交換するターゲットとしての通信制御装置であって、前記イニシエータによって発行された命令に従って、前記イニシエータが有する記憶領域に対するデータの書き込みあるいは前記イニシエータが有する記憶領域からのデータの読み出しを実行する第１の実行手段と、前記イニシエータによって発行された命令に従ったデータの書き込みあるいは読み出しを完了した旨の完了通知を前記イニシエータに発行する第１の発行手段と、前記第１の実行手段によりデータの書き込みあるいは読み出しを実行中の命令の識別子を保持する識別子保持手段と、前記第１の実行手段によりデータの書き込みあるいは読み出しを実行中の命令に従ってデータの書き込みあるいは読み出しを行うべき記憶領域を示す、当該命令に対応して指定されたアドレスからのオフセットを保持するオフセット保持手段と、前記イニシエータによって再発行された命令の識別子と前記識別子保持手段によって保持されている識別子とを比較する比較手段と、前記比較手段による一致を示す比較結果に従って、前記オフセット保持手段によって保持されているオフセットに基づいてデータの書き込みあるいは読み出しを実行する第２の実行手段と、前記比較手段による不一致を示す比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを実行することなく、再発行された命令に対する前記完了通知を前記イニシエータに発行する第２の発行手段とを備える。
【００２６】
【発明の実施の形態】
［第１の実施の形態］
本発明の第１の実施の形態として、ホストコンピュータとプリンタとを、ＩＥＥＥ１３９４で接続し、その上に構築されたＳＢＰ−２プロトコルを用いた、本発明に係るプロトコル（以下ＳＨＰＴと呼ぶ）に従ってデータ転送を行うプリンタシステムを説明する。図２４は、そのプリンタシステムにおけるハードウエア構成図である。
＜システムのハードウエア構成＞
図２４において、ホストコンピュータ２００は、ＲＯＭ３のプログラム用ＲＯＭに記憶された文書処理プログラム等に基づいて、図形，イメージ，文字，表（表計算等を含む）等が混在した文書処理を実行するＣＰＵ１を備える。ＣＰＵ１はシステムデバイス４に接続される各デバイスをＣＰＵ１が総括的に制御する。また、ＲＯＭ３のプログラム用ＲＯＭには、ＣＰＵ１の制御プログラム等が記憶され、ＲＯＭ３のフォント用ＲＯＭには上記文書処理の際に使用するフォントデータ等が記憶され、ＲＯＭ３のデータ用ＲＯＭは上記文書処理等を行う際に使用する各種データが記憶される。ＲＡＭ２は、ＣＰＵ１の主メモリ，ワークエリア等として機能する。プログラムはＲＡＭ２に格納されても良い。また、ＲＡＭ２には、送信データバッファやＯＲＢを格納するシステムメモリが確保される。
【００２７】
キーボードコントローラ（ＫＢＣ）５は、キーボード９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）６は、ＣＲＴディスプレイ（ＣＲＴ）１０の表示を制御する。メモリコントローラ（ＭＣ）７は、プートプログラム，種々のアプリケーション，フォントデータ，ユーザファイル，編集ファイル等を記憶するハードディスク（ＨＤ）、フロッピーディスク（ＦＤ）等の外部メモリ１１とのアクセスを制御する。１３９４インターフェース８は、ＩＥＥＥ１３９４規格に従ってプリンタ１００に接続されて、プリンタ１００との通信制御処理を実行する。なお、ＣＰＵ１は、例えばＲＡＭ２上に設定された表示情報ＲＡＭへのアウトラインフォントの展開（ラスタライズ）処理を実行し、ＣＲＴ１０上でのＷＹＳＩＷＹＧを可能としている。また、ＣＰＵ１は、ＣＲＴ１０上の不図示のマウスカーソル等で指示されたコマンドに基づいて登録された種々のウィンドウを開き、種々のデータ処理を実行する。
【００２８】
プリンタ１００において、プリンタＣＰＵ１２は、ＲＯＭ１３のプログラム用ＲＯＭに記憶された制御プログラム等或いは外部メモリ１４に記憶された制御プログラム等に基づいてシステムバス１５に接続される各種のデバイスとのアクセスを総括的に制御し、印刷部インタフェース１６を介して接続される印刷部（プリンタエンジン）１７に出力情報としての画像信号を出力する。また、このＲＯＭ１３のプログラムＲＯＭには、後述する各種エージェントや画像処理を実現するＣＰＵ１２の制御プログラム等が記憶される。ＲＯＭ１３のフォント用ＲＯＭには上記出力情報を生成する際に使用するフォントデータ等が記憶され、ＲＯＭ１３のデータ用ＲＯＭには、ハードディスク等の外部メモリ１４が無いプリンタの場合には、ホストコンピュータ上で利用される情報等が記憶されている。ＣＰＵ１２は１３９４インターフェース１８を介してホストコンピュータとの通信処理が可能となっており、プリンタ内の情報等をホストコンピュータ２００に通知可能に構成されている。
【００２９】
ＲＡＭ１９は、ＣＰＵ１２の主メモリ、ワークエリア等として機能するＲＡＭで、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。なお、ＲＡＭ１９は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。
【００３０】
前述したハードディスク（ＨＤ）、ＩＣカード等の外部メモリ１４は、メモリコントローラ（ＭＣ）２０によりアクセスを制御される。外部メモリ１４は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。また、操作パネル１８には、操作のためのスイッチおよびＬＥＤ表示器等が配されている。また、前述した外部メモリは１個に限らず、少なくとも１個以上備え、内蔵フォントに加えてオプションフォントカード，言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていても良い。さらに、図示しないＮＶＲＡＭを有し、操作パネル１０１２からのプリンタモード設定情報を記憶するようにしても良い。
【００３１】
＜イニシエータの構成＞
上述したハードウエア構成において、プリンタ１００をターゲットとし、ホストコンピュータ２００をイニシエータとした通信システムを、図１及び図２に示す。本実施形態に置いては、これら構成は、それぞれホストコンピュータ及びプリンタにおけるＣＰＵによりプログラムを実行することで実現される。まず、図２のイニシエータから説明する。
【００３２】
図２において、イニシエータであるホストコンピュータにおいては、プリンタドライバ等のクライアント２０６はＳＨＰＴ処理部２０１を介してプリンタに対するデータ転送要求を発行するとともに、プリンタからの応答を受ける。
【００３３】
ＳＨＰＴ処理部２０１は、システムメモリに生成されるＩ／Ｏ要求キューやＯＲＢを管理している。リードＩ／Ｏ要求キュー２０３にはクライアント２０６からのリード要求コマンドが、ライトＩ／Ｏ要求キュー２０２にはクライアント２０６からのライト要求コマンドが、それぞれキューイングされる。ＯＲＢはイニシエータであるホストコンピュータからターゲットであるプリンタへ、あるいはプリンタからホストコンピュータへ渡されるデータバッファのアドレスやサイズ等を格納したブロックであり、先頭のＯＲＢからＯＲＢリスト２０４に順次リンクされている。このＯＲＢについては、次のような処理の原則がある。
（１）リードＩ／Ｏ要求キュー及びライトＩ／Ｏ要求キューそれぞれの先頭から取り出したコマンドから順にＯＲＢが作成され、ＯＲＢリストの末尾につけられる。リード／ライトの順序には特に制約はない。
（２）ＯＲＢは、ＯＲＢリストの先頭から順次フェッチされる。完了通知（ステータスブロック）を受信すると、そのステータスに対応するＯＲＢはＯＲＢリストからはずされる。
（３）リンクされるＯＲＢの数の上限は、後述するターゲットにおけるリードプリフェッチキュー及びライトプリフェッチキューの容量（それぞれ処理中のコマンドも含む）の合計と同一である。
（１），（２）項により、ライトＩ／Ｏ要求，リードＩ／Ｏ要求は、それぞれのＩ／Ｏ要求において、発生した順にターゲットに発行されることが保証される。また、（３）項により、ＯＲＢリスト中のＩ／Ｏ要求はターゲットに渡されていることが保証される。この（３）項を実現するために、ＳＨＰＴ処理部２０１は、プリンタの２つのプリフェッチキューそれぞれについて２つのカウンタを用意している。ひとつはCurrentReadQUEというカウンタ２０３ａであり、後述するターゲットのリードプリフェッチキューの現在の空容量を示している。また、もうひとつはCurrentWriteQUEというカウンタ２０２ａであり、ターゲットのライトプリフェッチキューの空き容量を示している。これらカウンタの初期値はターゲットとなる機器が保持しており、ログイン時等にターゲットから読み出され、イニシエータに記憶される。これらカウンタはＯＲＢの生成と削除に合わせて増減される。
【００３４】
また、ＯＲＢを生成した際には、ターゲット側のドアベルレジスタと呼ばれるレジスタに所定値を書き込む、あるいは、リストの先頭のＯＲＢのアドレスをＯＲＢポインタと呼ばれるレジスタに書き込むことにより、ＯＲＢが発生したことをターゲットに知らせる。既にターゲットが実行しているＯＲＢリストの最後にＯＲＢした場合にはドアベルレジスタへの書き込みを行い、ＯＲＢリストがない状態で新規に先頭のＯＲＢを作成した場合には、ＯＲＢポインタへの書き込みを行う。この手続きはＳＢＰ−２で規定されている。
【００３５】
また、ＳＨＰＴ処理部２０１は、ステータスＦＩＦＯ２０５を含む。１３９４インターフェース１０９を介して受信されたステータスは、ＳＨＰＴ処理部２０１により処理される。ＳＨＰＴ処理部２０１は、受信したステータスに対応するＯＲＢをＯＲＢリスト２０４から外すとともに、そのＯＲＢに対応するコマンドをＩ／Ｏ要求キューから外す。
【００３６】
イニシエータたるホストコンピュータは以上のような機能的な構成からなっている。
【００３７】
＜ターゲットの構成＞
図１は、ターゲットたるプリンタの機能上の構成を示すブロック図である。図１において、ドアベルレジスタ１０１ａは、イニシエータによって書き込まれるレジスタであり、ＯＲＢが新たに生成されたことを示す。また、ＯＲＢポインタ１０１ｂには、新たに生成されたＯＲＢのアドレスがイニシエータにより書き込まれる。フェッチエージェント１０１は、ドアベル１０１ａに書き込みがあると、１３９４インターフェース１０１を介してＯＲＢポインタで示されるＯＲＢを読み込む。ＯＲＢディスパッチャ１０２は、フェッチエージェント１０１により読み込まれたＯＲＢがライトコマンドＯＲＢであればライトコマンドをライトプリフェッチキュー１０３の末尾につけ、リードコマンドＯＲＢであればリードコマンドをリードプリフェッチキュー１０５の末尾につける。このコマンドの種類は、ＯＲＢのファンクションフィールドの値に応じて判定される。
【００３８】
ライト実行エージェント１０４及びリード実行エージェント１０６は、それぞれライトプリフェッチキュー１０３及びリードプリフェッチキュー１０５にキューイングされたコマンドを先頭から取り出し、イニシエータのバッファへのデータの書込み及びイニシエータのバッファからのデータの読み出しを行う。その後、ホストコンピュータにノーマルステータスを返す。
【００３９】
なお、リード実行エージェント１０６は、例えばＰＤＬを解釈実行してラスタデータを生成するラスタライザ等のクライアント１０８からのデータ転送要求に応じて、リードプリフェッチキュー内のリードコマンドで指定されたイニシエータのバッファにデータを書き込む。このデータ転送要求は、イニシエータからのライトコマンドやリードコマンドとは非同期に発生するため、イニシエータはリードコマンドＯＲＢによってリードプリフェッチキューにリードコマンドを常時キューイングしておく。ターゲットは、リードコマンドがプリフェッチキューにキューイングされている限り、いつでもデータをイニシエータに渡すことができる。なお、バスインターフェース１１０は、ターゲットであるプリンタ１００からイニシエータであるホストコンピュータ２００のシステムメモリ２０８の所望のメモリロケーションにアクセスするためのインターフェースである。
【００４０】
以上、イニシエータ及びタ−ゲットの構成と動作を簡単に説明した。これらを更に詳しく説明する前に、まずＯＲＢの詳しい内容を説明する。
【００４１】
＜コマンドＯＲＢ(Operation Request Block)の内容＞
図７はＯＲＢ一般の構成を示す図である。図７（Ａ）において、"Next_ORB"（リンク）フィールド３０１は、次のＯＲＢへのリンクである。次のＯＲＢがない場合にはそれを表す所定の値が入れられる。なお、先頭のＯＲＢは、所定のアドレスレジスタにより示される。"data_descripter"（データデスクリプタ）フィールド３０２は、データバッファのアドレスを示す。"d"（方向）フィールド３０３は、ホストコンピュータからプリンタへのデータ転送（０：ライト）か、プリンタからホストコンピュータへのデータ転送（１：リード）かを示す。"data_size"（データサイズ）フィールド３０４は、アドレスフィールド３０２で指し示されるデータバッファのサイズを示す。以上、図の点線よりも上のフィールド（未説明のフィールドも含めて）がＳＢＰ−２で規定されているフィールドであり、これから説明するフィールド３０５〜３０８が、ＳＨＰＴに固有の処理に用いられるフィールドである。
【００４２】
"PSID"フィールド３０５ａ，"SSID"フィールド３０５ｂは、使用されるチャネルＩＤを表わしている。"function"（ファンクション）フィールド３０６は、図７（Ｂ）に示すようにＯＲＢの種類を示している。０Ｈがライトコマンド、４０Ｈがリードコマンドを表わす。
【００４３】
"t"（タグ）ビット３０７はデータタグを表している。"seq_ID"（シーケンスＩＤ）フィールド３０８は、ファンクションごと（リードあるいはライトコマンド）に、ＯＲＢの生成順に振られるシーケンシャルな識別子である。この識別子は、本実施形態ではＯＲＢが生成されるごとに１ずつ増えるように与えられる。なお、このシーケンスＩＤフィールドに値を与える基準となるカウンタは、バスリセットや他の障害による影響を受けない領域に設けられる。それは、ターゲットにおいては、シーケンスＩＤの連続性を前提として処理を行うためである。コントロールブロックフィールド３０９には、ファンクションフィールド３０６の値や、各ファンクションに対してターゲットで実現される機能に応じて様々な値が入れられる。なお、バッファのアドレスやサイズについては、Ｉ／Ｏ要求キューに入れられたコマンドからＯＲＢ生成時に得る。次に、機能ごとにＯＲＢの内容を説明する。
【００４４】
（ライトコマンドＯＲＢ）
図８はファンクション＝０ＨのライトコマンドＯＲＢを示している。このコマンドは、指定したバッファ内のデータをイニシエータからターゲットに渡すためのコマンドである。ファンクションフィールドの値は０Ｈであり、シーケンスＩＤは、ひとつのチャネルごとに、各ライトコマンドに対して昇順に与えられる。
【００４５】
（リードコマンドＯＲＢ）
図９はファンクション＝４０ＨのリードコマンドＯＲＢを示している。このコマンドは、イニシエータがターゲットからデータを読み出すためのコマンドである。ファンクションフィールドの値は４０Ｈであり、シーケンスＩＤは、ひとつのチャネルごとに、各リードコマンドに対して昇順に与えられる。
【００４６】
（ステータスブロック）
図１０（Ａ）〜（Ｃ）は、ターゲットからイニシエータに返されるステータスの形式及びその内容を示している。図１０（Ａ）において、点線よりも上のフィールドはＳＢＰ−２で規定されたフィールドであるため、特に説明をしない。ＰＳＩＤフィールド４０１，ＳＳＩＤフィールド４０２，ファンクションフィールド４０３，タグフィールド４０４は、図７のコマンドＯＲＢと同様のフィールである。図１０（Ｂ）にファンクションフィールドの値とその意味を示す。
【００４７】
"SHPT_status"（ＳＨＰＴステータス）フィールド図１０（Ｃ）に示すような意味を持つ。すなわち、値が０であれば、そのステータス対応するコマンドＯＲＢについての処理は完了したことを示す。例えば、対応するコマンドＯＲＢがライトコマンドであれば、ＳＨＰＴステータスが０のステータスブロックは、対応するライトコマンドＯＲＢで差し示されたバッファから、ターゲットがデータを全て読み出し、ターゲットの持つバッファに書き込み終えたことを意味する。また、値が１であれば、対応するコマンドＯＲＢの処理が部分的な終了していることを示す。また、値が２であれば、対応するコマンドＯＲＢの処理はエラーにより行われなかったことを示す。このエラーを受けたイニシエータは、クライアントにエラーである旨知らせるなどしてエラーに対応する。
【００４８】
"length_hi"（レングスハイ）フィールド４０５及び"length_lo"（レングスロウ）フィールド４０６は、処理されたデータ長を示す。
【００４９】
（ライトステータスブロック）
図１１は、ファンクション＝０のライトステータスブロックであり、ライトコマンドに対してターゲットからイニシエータに渡される。処理の状態は、ＳＨＰＴステータスにより、図１０（Ｃ）のように表わされる。
【００５０】
（リードステータスブロック）
図１２は、ファンクション＝４０Ｈのリードステータスブロックであり、リードコマンドに対してターゲットからイニシエータに渡される。処理の状態は、ＳＨＰＴステータスにより、図１０（Ｃ）のように表わされる。
【００５１】
＜ＯＲＢの管理＞
次に、以上説明したイニシエータ及びターゲットの構成や、コマンドＯＲＢ及びステータスブロックの構成に基づいて、ＯＲＢがどのように用いられているか説明する。
【００５２】
図３は、イニシエータ及びクライアント間におけるコマンドの流れを示している。まずライトコマンドについて説明する。イニシエータのクライアントからデータ転送要求が発生すると、クライアントはターゲットに渡すデータを格納したバッファのアドレス及びサイズを含むライトコマンドを、ライトＩ／Ｏ要求キュー２０２の末尾につける。ＳＨＰＴ処理部２０１では、ターゲットのライトプリフェッチキュー１０３の空き容量を示すCurrentWriteQUE２０２ａをチェックし、空きがあればそのライトコマンドからＯＲＢを生成してＯＲＢリスト２０４の末尾にリンクするが、空きがなければ空きを待つ。図３の状態では、ライトプリフェッチキューはライトコマンドＷ１〜Ｗ４によっていっぱいであり、その後のライトコマンドＷ５及びＷ６はライトＩ／Ｏ要求キューで待たされている。なお、ＯＲＢが生成されてもそれに対応するライトコマンドはライトＩ／Ｏ要求キューから削除されず、ターゲットからの完了ステータスを受けた時点で削除される。
【００５３】
ＳＨＰＴ処理部２０１は、ＯＲＢをＯＲＢリストに入れると、１３９４インターフェースを介してターゲットのドアベル１０１ａに書き込む、あるいは、ＯＲＢポインタ１０１ｂに新たなＯＲＢのアドレスを書き込む。ディスパッチャ１０２は、そのＯＲＢに基づいて、ライトコマンドをライトプリフェッチキュー１０３の末尾につける。ライト実行エージェント１０４は、ライトプリフェッチキュー内のコマンドを順次実行する。すなわち、ターゲットのクライアントの用意したバッファに、ライトコマンドで示されるバッファの内容を書き込む。ライト実行エージェントは、コマンドの処理が完了すると、ＳＨＰＴステータスが「完了」であるステータスブロックをイニシエータのステータスＦＩＦＯ２０５に書き込む。
【００５４】
ＳＨＰＴ処理部２０１は、ステータスＦＩＦＯに入れられたステータスブロックを先頭から処理する。すなわち、ＳＨＰＴステータスが「完了」であれば、そのステータスブロックに対応するＯＲＢをＯＲＢリストから外し、それとともにライトＩ／Ｏ要求キュー内の対応するライトコマンドを削除する。以上の手順は、リードコマンドについても全く同様である。ただし、リードコマンドは、ターゲットにおいてリードすべきデータが発生しない限り処理されない。従って、イニシエータから発行されたリードコマンドＯＲＢは、リードすべきデータが発生するまでリードプリフェッチキューにキューイングされたままということになる。
【００５５】
イニシエータがホストコンピュータ、ターゲットがプリンタである場合、ホストコンピュータからプリンタに印刷データを渡すためには、上述のライトコマンドを用いて、イニシエータのクライアントであるプリンタドライバから、ターゲットのクライアントであるラスタライザに印刷データが渡される。また、ホストコンピュータがプリンタの構成や状態を示す情報を要求する場合には、その旨のコマンド（クライアントレベルのコマンド）をプリンタにライトコマンドで渡す。それを受けたプリンタ（のクライアント）は、リードプリフェッチキューにキューイングされているリードコマンドを用いて、ホストコンピュータに要求されたデータを渡す。さらに、プリンタでエラーが発生したような場合には、プリンタのクライアントは、リードプリフェッチキューにキューイングされているリードコマンドを用いて、自発的にエラー情報をホストコンピュータに渡すことができる。このため、ホストコンピュータはプリンタと接続している間は、運用上少なくとも１つのリードＯＲＢをプリンタに対して発行しておく。さらに、リードコマンドを常時リードプリフェッチキューにキューイングさせておくためには、少なくとも２つのリードＯＲＢをプリンタに対して発行しておくことが望ましい。
【００５６】
図６はＯＲＢリストの更新の様子を示している。状態１から、ライトコマンドＷ１とリードコマンドＲ１とが処理されてそれらのＯＲＢはＯＲＢから削除される（状態２）。このため、ライトＯＲＢＷ２，Ｗ３のリンク先はなくなる。この場合、これらＯＲＢは既にターゲットに渡っているため、これらをＯＲＢリストにつなぎなおす必用はない。また、ＯＲＢリストになくとも、Ｉ／Ｏ要求キューには対応コマンドが残っているため、後述するエラー復旧処理も正常に行うことができる。
【００５７】
＜エラーの復旧（イニシエータ）＞
既に説明したように、ＳＢＰ−２では、ネットワークに異常（エラー）に起因するバスリセットにより、イニシエータとターゲットとの間の接続は断たれてしまう。そこで、ＳＨＰＴでは、バスリセットにより失われた状態を復旧するための手順を定めている。図４〜図６を参照してその手順の概要を説明する。
【００５８】
図４はイニシエータの状態を示している。図４において、状態１では、ライトコマンドＷ１〜Ｗ４のライトＯＲＢと、リードコマンドＲ１〜Ｒ３のリードＯＲＢが発行されており、ライトコマンドＷ５，Ｗ６はライトＩ／Ｏ要求キュー２０２にとどめられた状態にある。ターゲットにより１つのライトコマンドと２つのリードコマンドとが処理され、イニシエータは状態２に遷移する。処理されたコマンドに対応するＯＲＢはＯＲＢリスト２０４からはずされ、空き領域となっている。この状態では、ライトプリフェッチキューに空きが生じているが、まだライトコマンドＷ５に対応するＯＲＢは発行されていない。
【００５９】
ここでネットワーク上のエラーなどからバスリセットが発生する。バスリセットの処理が終えたなら、全てのＯＲＢをＯＲＢリストから消去する（状態３）。ライトＩ／Ｏ要求キュー２０２ならびにリードＩ／Ｏ要求キュー２０３は、バスリセットがあってもリセットされることはない。
【００６０】
イニシエータは、コネクションを再設定した後、ライトＩ／Ｏ要求キューならびにリードＩ／Ｏ要求キューを参照して、それらキューの内容から新たにＯＲＢを生成し、ターゲットに対して発行する。これが状態４である。ＯＲＢの生成時に対応するコマンドに対して何等かのマークをしておけば、バスリセット直前の状態を再現することができる。
【００６１】
また、図４には示されていないが、ステータスＦＩＦＯはバスリセットでは影響を受けないため、特に復旧する必用はない。
【００６２】
＜エラーの復旧（ターゲット）＞
図５は、ターゲット側におけるバスリセット後の復旧の様子を示す図である。イニシエータはＯＲＢリストを復旧させるだけでその状態をバスリセット直前の状態に戻せるが、ターゲットはリード／ライトコマンドに応じてバッファに対してリード／ライトを行うため、リード／ライト中にバスリセットが発生した場合には、復旧後はその続きを行わねばならない。そのために、ターゲットのリード／ライト実行エージェントは、処理中のコマンドと、処理中のバッファの位置を記憶している。
【００６３】
図５では例としてリードコマンドの場合を示している。イニシエータがリードＯＲＢを発行し、ターゲットはそれをリード実行エージェントによって処理する。実行前に、リード実行エージェント１０６はこれから処理するリードＯＲＢのseq_IDフィールドを読み出し、シーケンス識別子(Sequenceidentifier)として記憶しておく。図５ではその値は「３」である。また、クライアントのバッファにデータを書き込むに当たり、現在書き込んでいるバッファのアドレスを実行ポインタ(Nextexecpointer)として更新しつづける。図５ではその値は「offset」である。これらの領域はバスリセットによって消去されないメモリ領域に確保される。
【００６４】
バスリセットが終了したなら、イニシエータはＯＲＢを改めて発行してくるため、リード実行エージェントは、リードプリフェッチキューの先頭のＯＲＢのseq_IDフィールドが、記憶されているシーケンス識別子よりも古ければ、そのＯＲＢは既に処理は完了しているために、完了ステータスを返す。両者が一致すれば、Nextexecpointerで示されるアドレスから書き込みを続行する。
【００６５】
ライトコマンドについても同じ要領で復旧される。
【００６６】
以上、本実施形態の印刷システムにおいて用いられるコマンドおよびステータスについて説明した。次に、イニシエータおよびターゲットにおけるコマンド及びステータスの処理手順を説明する。
【００６７】
＜イニシエータのクライアントによるデータ転送要求＞
図１３は、イニシエータのクライアントであるプリンタドライバ等から、ターゲットに対して、データを送信あるいは要求する際の手順を示している。
【００６８】
データ転送事項が発生したなら（ステップＳ１３０１）、そのために必用なコマンドがライトであるかリードであるか判定し（ステップＳ１３０２）、ライトならばそのためのデータ転送バッファがあるか調べ（ステップＳ１３０３）、また、ターゲットに渡すべき送信データの準備ができているか調べて（ステップＳ１３０４）、すべて準備できていれば、バッファのアドレスやサイズ等、必用な引き数を与えてライトコマンドを作成し（ステップＳ１３０５）、ライト関数をコールする（ステップＳ１３０６）。
【００６９】
一方、リードコマンドであると判定されれば、データを受けるための転送バッファがあるか調べ（ステップＳ１３０７）、あればバッファのアドレスやサイズ等、必用な引き数を与えてリードコマンドを作成し（ステップＳ１３０８）、リード関数をコールする（ステップＳ１３０９）。
【００７０】
例えば、データ転送事項がプリンタに対する印刷データの送信ならば、ＰＤＬなど、クライアントレベルのコマンドやデータをバッファに用意し、ライトコマンドを作成することになるし、データ転送事項がプリンタからの状態の読み出しであれば、その旨を示すクライアントレベルのコマンドを用意してライトコマンドを作成するとともに、ターゲットからデータを受けるためのリードコマンドを作成する必用がある。また、ターゲットとの一連のデータ交換を行うに先立って、イニシエータのクライアントはリードコマンドを幾つか発行する。
【００７１】
図１４は、イニシエータのクライアントが下位すなわちＳＨＴＰの層から処理終了通知を受けた際の処理手順である。まず、終了した処理がリードかライトか判定し（ステップＳ１４０１）、ライトであれば使用したデータバッファを解放する（ステップＳ１４０２）。一方、リードであれば、処理の終了はデータの受信の完了であるから、受信したデータに対応した処理を行い（ステップＳ１４０３）、データバッファを解放する（ステップＳ１４０４）。
【００７２】
＜イニシエータのＳＨＰＴ処理部による処理＞
図１５〜図１８は、イニシエータのＳＨＰＴ処理部による処理手順である。図１５（Ａ）及び（Ｂ）は、それぞれクライアントがコールするライト関数及びリード関数の内容を示す。ライト関数では、ライトＩ／Ｏ要求キューにライトコマンドを追加し、リード関数では、リードＩ／Ｏ要求キューにリードコマンドを追加する。
【００７３】
（Ｉ／Ｏ要求キュー管理）
図１６（Ａ），（Ｂ）は、それぞれライトＩ／Ｏ要求キュー管理手順，リードＩ／Ｏ要求キュー管理手順を示す。これらの手順は、それぞれ単独のスレッドで行われる。両者の処理内容は、管理対象がライトＩ／ＯキューとリードＩ／Ｏキューとで異なるものの、同一であるため、ライトＩ／Ｏ要求キュー管理手順のみを説明する。その説明のライトＩ／Ｏ要求キューをリードＩ／Ｏ要求キューに、カウンタCurrentWriteQUEをCurrentReadQUEに、参照番号のＳ１６０ＸをＳ１６１Ｘに読み替えれば、リードＩ／Ｏ要求キューの管理手順となる。
【００７４】
まず、ライトＩ／Ｏ要求キュー内にＯＲＢ化されていないコマンドがあるか調べる（ステップＳ１６０１）。あれば、ターゲットのプリフェッチキューの空き容量を示すカウンタCurrentWriteQUEが０より大きいか、すなわち空きがあるか判定する（ステップＳ１６０２）。空きがあればCurrentWriteQUEの値から１減じ（ステップＳ１６０３）、ライトＩ／Ｏ要求キューに格納されている、ＯＲＢ化されていない先頭のコマンドを基に、シーケンスＩＤ(Seq_ID)やＳＨＰＴコマンド(Function)を付加して、ＯＲＢを作成する（ステップＳ１６０４）。
【００７５】
こうして作成したＯＲＢをＯＲＢリストにつけ（ステップＳ１６０５）、ターゲットのドアベルに書き込む、あるいは、ＯＲＢポインタにＯＲＢのアドレスを書き込む（ステップＳ１６０６）。このようにして、Ｉ／Ｏ要求キュー内のコマンドからＯＲＢが作成される。
【００７６】
（ステータスブロックに対する処理）
図１７は、ステータスブロックをターゲットから受けた際の処理手順である。ＯＲＢに対する処理完了のステータスブロックを受けると、対応するＯＲＢをＯＲＢリストから削除し（ステップＳ１７０１）、対応ＯＲＢがライトかそれともリードか判定する（ステップＳ１７０２）。ライトであれば、ライトＩ／Ｏ要求キューから、削除したＯＲＢの元となったコマンドを削除する（ステップＳ１７０３）。そして、ターゲットで処理を終えた分だけプリフェッチキューが空いたはずなので、カウンタCurrentWriteQUEに１加算する（ステップＳ１７０４）。最後に、クライアントに処理の終了を通知する（ステップＳ１７０５）。クライアントはこれを受けて、図１４の処理を行うことになる。
【００７７】
一方、対応ＯＲＢがリードであると判定された場合には、リードＩ／Ｏ要求キューから、削除したＯＲＢの元となったコマンドを削除する（ステップＳ１７０６）。そして、ターゲットで処理を終えた分だけプリフェッチキューが空いたはずなので、カウンタCurrentReadQUEに１加算する（ステップＳ１７０７）。最後に、クライアントに処理の終了を通知する（ステップＳ１７０８）。
【００７８】
（エラー復旧処理）
ＳＨＰＴ処理部における通常の処理は以上のとおりである。次にバスリセット後などに復旧する手順を図１８により説明する。バスリセットが生じてターゲットとのコネクションが切断されてしまった場合、あらためてコネクションの再設定から行わねばならない。
【００７９】
まず、新規のＯＲＢのリンク処理を中断し（ステップＳ１８０１）、ＯＲＢリストを破棄する（ステップＳ１８０２）。この後コネクションの再接続命令を出して（ステップＳ１８０３）、コネクションの確立を調べ（ステップＳ１８０４）、コネクションが再度張られたなら、ライトＩ／Ｏ要求キュー及びリードＩ／Ｏ要求キュー内の先頭のコマンドから順に対応するＯＲＢを作成する（ステップＳ１８０５）。作成されたＯＲＢはＯＲＢリストにリンクされ（ステップＳ１８０６）、ＯＲＢポインタにアドレスを書き込んで（ステップＳ１８０７）、ターゲットにＯＲＢの発生を知らせる。
【００８０】
一方、コネクションが再設定できないまま一定時間経過すると（ステップＳ１８０８）、ライトＩ／Ｏ要求キュー及びリードＩ／Ｏ要求キュー内のコマンドをすべて破棄し（ステップＳ１８０９）、異常である旨をクライアントに知らせて（ステップＳ１８１０）、処理を終える。
【００８１】
異常の手順により、リセット後に、あらためてターゲットとのコネクションを確立し、リセット直前のＯＲＢリストを復旧することができる。
【００８２】
＜ターゲットによる処理＞
図１９〜２１は、ＯＲＢを受けたターゲットによる処理手順である。
【００８３】
（フェッチエージェントによる処理）
フェッチエージェントはドアベルレジスタあるいはＯＲＢポインタに書き込みがあるとＯＲＢをフェッチする。まず、ドアベルへの書き込みにより起動されたか判定し（ステップＳ１９０１）、そうでなく、ＯＲＢポインタへの書き込みにより起動されたのであればステップＳ１９０５に進む。一方、ドアベルへの書き込みがあったならば、フラグＮｕｌｌｆｌｇをテストする（ステップＳ１９０２）。このフラグは、ＯＲＢポインタに有効な値がセットされていないことを示すフラグであり、Ｎｕｌｌｆｌｇがオフであれば、ＯＲＢポインタには処理すべきＯＲＢのアドレスが書き込まれているから、ステップＳ１９０５へと進む。Ｎｕｌｌｆｌｇがオンであれば、現在のＯＲＢポインタで指されているＯＲＢのNext_ORBフィールドの値を、ＯＲＢポインタへと書き込み（ステップＳ１９０３）、Ｎｕｌｌｆｌｇをオフにセットする（ステップＳ１９０４）。
【００８４】
こうしてＯＲＢポインタに処理すべきＯＲＢのアドレスが得られたなら、そのアドレスからＯＲＢを読み出す（ステップＳ１９０５）。読み出したＯＲＢのファンクションフィールドを参照して、そのＳＨＰＴコマンドがライトであるかリードであるか判定する（ステップＳ１９０６）。ライトであればライトＯＲＢをライトプリフェッチキューにつけ（ステップＳ１９０７）、リードであればリードＯＲＢをリードプリフェッチキューにつける（ステップＳ１９０８）。
【００８５】
この後、処理を終えたＯＲＢのNext_ORBフィールドを参照して、その内容がNULL、すなわちリンクされているＯＲＢがなければ、フラグＮｕｌｌｆｌｇをオンにして、ドアベルあるいはＯＲＢポインタへ書き込みがあるまで待つ。一方、リンクされているＯＲＢがあれば、ＯＲＢポインタで指されているＯＲＢのNext_ORBフィールドの値を、ＯＲＢポインタに書き込む（ステップＳ１９１０）。ＯＲＢリストにリンクされているＯＲＢ全てについてプリフェッチキューに入れるまで、この手順を繰り返す。
【００８６】
このようにして、ＯＲＢリストのＯＲＢをプリフェッチキューにいれる。また、ステップＳ１９０６〜Ｓ１９０８の処理は、図１においてＯＲＢディスパッチャとして説明した処理である。
【００８７】
（ライト実行エージェント）
ライト実行エージェントは、まずライトプリフェッチキューに未処理のライトコマンドがあるか調べ（ステップＳ２００１）、あればNextreadpointerの指すＯＲＢをライトプリフェッチキューから取り出す（ステップＳ２００２）。なおNextreadpointerはキューの先頭のＯＲＢを指し示すポインタである。ＯＲＢを読み出すと、そのＯＲＢのSeq_IDフィールドの値が、ライト実行エージェントが保持する変数Sequenceidentifierよりも小さい値であるか判定する（ステップＳ２００３）。ただし、Seq_ID及びSequenceidentifierはともに有限の桁数である。そこで、Seq_ID及びSequenceidentifierがともにｎビットで表わされる場合、ステップＳ２００３における比較では、（（２のｎ乗−１）＜０（＝２のｎ乗））と定めておく。
【００８８】
通常のシーケンスであれば、ひとつのＯＲＢの処理終了後、Sequenceidentifierには後述のように１加算される。また、SequenceidentifierとＯＲＢのSeq_IDは同じ桁数であり、Seq_IDも１ずつ加算される。そのため、支障なく処理が進んでいる場合には、SequenceidentifierとＯＲＢのSeq_IDとは、ステップＳ２００３において一致しているはずである。したがって、正常に処理が進めば、処理はステップＳ２００３からステップＳ２００４に移行する。
【００８９】
そこでは、クライアントがバッファを用意してあるか調べ（ステップＳ２００４）、用意できたなら、ＯＲＢのDataDescripterの値とライト実行エージェントが保持するNextexecpointerに格納されたｏｆｆｓｅｔ値とを加えたアドレスから所定サイズのデータを読み、クライアントが用意したバッファに格納する（ステップＳ２００５）。新たにＯＲＢの処理を行う場合には、ｏｆｆｓｅｔは０であるから、ＯＲＢにより指し示されるバッファの先頭から読み出すことになる。また、途中まで読み出されているバッファを続きから読む場合には、ｏｆｆｓｅｔは、バッファ中における続きのアドレスを示しているので、これを加算することで続きから読み出しを続行できる。データをバッファに格納したなら、DataDescripterの値＋ｏｆｆｓｅｔが次に読み出されるアドレスを指すように、Nextexecpointerを更新する（ステップＳ２００６）。このような読み出しを、ＯＲＢのdata_sizeで示されるサイズ分に達するまで行う（ステップＳ２００７）。
【００９０】
こうして１つのＯＲＢの処理を終えると、Sequenceidentifierに１加算して更新し（ステップＳ２００８）、Nextexecpointer（ｏｆｆｓｅｔ）を０に初期化する（ステップＳ２００９）。
【００９１】
処理を終えたなら、処理完了を通知するステータスブロックを作成し（ステップＳ２０１０）、ステータスＦＩＦＯに書き込み（ステップＳ２０１１）、ターゲットのクライアントに受信完了を通知する（ステップＳ２０１２）。
【００９２】
ステップＳ２００３において、ＯＲＢのSeq_IDがSequenceidentifierよりも小さい場合は、バスリセットなどにより、イニシエータが図１８の手順でＯＲＢリストを再生したような場合である。例えば、あるＯＲＢについて、ターゲットは処理を終え、Sequenceidentifierの値も更新していても、そのステータスブロックがイニシエータに届いていない時点でバスリセットが発生すると、イニシエータはそのＯＲＢもＯＲＢリストに入れてしまう。この場合に、ＯＲＢのSeq_IDよりも実行エージェントのSequenceidentifierの方が大きくなる。この場合には、そのＯＲＢは処理を終えているため、ステップＳ２０１０以降によりステータスブロックをイニシエータに渡す。
【００９３】
（リード実行エージェント）
リード実行エージェントは、まずリードプリフェッチキューに未処理のリードコマンドがあるか調べ（ステップＳ２１０１）、あればNextreadpointerの指すＯＲＢをリードプリフェッチキューから取り出す（ステップＳ２１０２）。このNextreadpointerは、ライト実行エージェントのそれと同じ名称ではあるが、それとは独立して備えられている。なおNextreadpointerはキューの先頭のＯＲＢを指し示すポインタである。ＯＲＢを読み出すと、そのＯＲＢのSeq_IDフィールドの値が、リード実行エージェントが保持する変数Sequenceidentifierよりも小さい値であるか判定する（ステップＳ２１０３）。このSequenceidentifierも、ライト実行エージェントのそれと同じ名称ではあるが、それとは独立して有する。Seq_ID及びSequenceidentifierはともに有限の桁数である。そこで、Seq_ID及びSequenceidentifierがともにｎビットで表わされる場合、ステップＳ２１０３における比較では、（（２のｎ乗−１）＜０（＝２のｎ乗））と定めておく。
【００９４】
通常のシーケンスであれば、ひとつのＯＲＢの処理終了後、Sequenceidentifierには後述のように１加算される。また、SequenceidentifierとＯＲＢのSeq_IDは同じ桁数であり、Seq_IDも１ずつ加算される。そのため、支障なく処理が進んでいる場合には、SequenceidentifierとＯＲＢのSeq_IDとは、ステップＳ２００３において一致しているはずである。したがって、正常に処理が進めば、処理はステップＳ２１０３からステップＳ２１０４に移行する。
【００９５】
そこでは、クライアントがデータを用意してあるか調べ（ステップＳ２１０４）、用意できたなら、ＯＲＢのDataDescripterの値とリード実行エージェントが保持するNextexecpointerに格納されたｏｆｆｓｅｔ値とを加えたアドレスに、クライアントのデータを所定サイズ書き込む（ステップＳ２１０５）。なお、このNextexecpointerも、ライト実行エージェントのそれと同じ名称ではあるが、それとは別のポインタである。新たにＯＲＢの処理を行う場合には、ｏｆｆｓｅｔは０であるから、ＯＲＢにより指し示されるバッファの先頭から書き込むことになる。また、途中まで書き込まれているバッファを続きから書く場合には、ｏｆｆｓｅｔは、バッファ中における続きのアドレスを示しているので、これを加算することで続きから書き込みを続行できる。データをバッファに格納したなら、DataDescripterの値＋ｏｆｆｓｅｔが次に書き込まれるアドレスを指すように、Nextexecpointerを更新する（ステップＳ２１０６）。このようなデータの書き込みを、クライアントが用意したデータを書き込み終えるまで行う（ステップＳ２１０７）。
【００９６】
こうして１つのＯＲＢの処理を終えると、Sequenceidentifierに１加算して更新し（ステップＳ２１０８）、Nextexecpointer（ｏｆｆｓｅｔ）を０に初期化する（ステップＳ２１０９）。
【００９７】
処理を終えたなら、処理完了を通知するステータスブロックを作成し（ステップＳ２１１０）、ステータスＦＩＦＯに書き込み（ステップＳ２１１１）、ターゲットのクライアントに受信完了を通知する（ステップＳ２１１２）。
【００９８】
ステップＳ２１０３において、ＯＲＢのSeq_IDがSequenceidentifierよりも小さい場合は、バスリセットなどにより、イニシエータが図１８の手順でＯＲＢリストを再生したような場合であるので、ライト実行エージェントと同様に、ステップＳ２１１０以降によりステータスブロックをイニシエータに渡す。
【００９９】
＜ターゲットへのデータライトシーケンス＞
図２２は、イニシエータ（ホストコンピュータ）からターゲット（プリンタ）へのライトを行う際のシーケンス例である。
【０１００】
なお、図中のＳＢＰ−２とは、ＳＢＰ−２規格で規定されたデータ、すなわちＳＢＰ−２で規定されたフィールドを処理する処理層である。また、ＳＨＰＴとは、ＳＢＰ−２で規定されいない、ファンクションごとに定められた処理を行う処理層である。ＳＨＰＴでは、前述したフローチャートの手順を行う。ＳＢＰ−２は、その手順において、ＯＲＢのリンクやドアベルのライト、ＯＲＢやステータスのＳＨＰＴへの引き渡し等の機能を果たす。
【０１０１】
まず、イニシエータのクライアントでデータ及びライトコマンドが、ＳＨＰＴでＯＲＢ（ここではライトＯＲＢ）が作成され、カウンタCurrentWriteQUEが１減らされて、ＯＲＢのリンク要求がＳＢＰ−２に出される（１９０１）。ＳＢＰ−２ではＯＲＢをリンクしてドアベルレジスタにライト要求を出す（１９０２）。１３９４インタフェースにより、ドアベルレジスタが書き込まれ（１９０３）、それがターゲットのＳＢＰ−２に通知される（１９０４）。
【０１０２】
通知を受けたＳＢＰ−２は、ＯＲＢリード要求を１３９４インタフェースに出して（１９０５）、システムメモリからＯＲＢが読み出される（１９０６）。ＳＨＰＴは、読み出されたＯＲＢの内容に応じて対応キューに格納する（１９０７）。ここではライトコマンドＯＲＢなので、１３９４インタフェースに対してデータリード要求を出す（１９０８）。これに応じて、指定されたアドレスからデータが読み出され、クライアントに渡される（１９０９）。クライアントは、この場合画像の展開を行うラスタライザ等であり、データが展開された画像であればそれはプリンタエンジンから印刷出力されることになる。
【０１０３】
処理が済むとライト実行エージェントからＳＢＰ−２に対してステータスブロック送信要求が出され（１９１０）、ステータスブロックがイニシエータに返される（１９１１）。イニシエータのＳＨＴＰは、これを受けると対応ＯＲＢをリンクから削除し、空きキューカウンタを１増やす（１９１２）。
【０１０４】
以上のシーケンスによりイニシエータからターゲットにデータが書き込まれる。
【０１０５】
＜ターゲットからのデータリードシーケンス＞
図２３は、イニシエータ（ホストコンピュータ）からターゲット（プリンタ）のデータのリードを行う際のシーケンス例である。
【０１０６】
まず、イニシエータのクライアントでリードコマンドが、ＳＨＰＴでＯＲＢ（ここではリードＯＲＢ）が作成され、カウンタCurrentReadQUEが１減らされて、ＯＲＢのリンク要求がＳＢＰ−２に出される（１９０１）。ＳＢＰ−２ではＯＲＢをリンクしてドアベルレジスタにライト要求を出す（１９０２）。１３９４インタフェースにより、ドアベルレジスタが書き込まれ（１９０３）、それがターゲットのＳＢＰ−２に通知される（１９０４）。
【０１０７】
通知を受けたＳＢＰ−２は、ＯＲＢリード要求を１３９４インタフェースに出して（１９０５）、システムメモリからＯＲＢが読み出される（１９０６）。ＳＨＰＴは、読み出されたＯＲＢの内容に応じて対応キューに格納する（１９０７）。
【０１０８】
リード実行エージェントは、ここでイニシエータに渡すデータが発生するまで待つ。データが発生すると、１３９４インタフェースに対してデータライト要求を出す（２００８）。これに応じて、指定されたアドレスに用意されたデータが書き込まれる（２００９）。
【０１０９】
処理が済むとリード実行エージェントからＳＢＰ−２に対してステータスブロック送信要求が出され（１９１０）、ステータスブロックがイニシエータに返される（１９１１）。イニシエータのＳＨＴＰは、これを受けると対応ＯＲＢをリンクから削除し、空きキューカウンタを１増やす（１９１２）。
【０１１０】
このシーケンスによりイニシエータからターゲットのデータが読み出される。
【０１１１】
以上のようにして、イニシエータとターゲットとの間で、簡素な制御手順によりデータの交換が双方向に行える。すなわち、イニシエータは所望のときに所望のデータをターゲットに渡すことができる。また、ターゲットは、イニシエータから渡されたデータをターゲット自身の都合に合わせて読み出すことができる。また、ターゲットはイニシエータが準備していさえすれば、自発的であろうと、あるいはイニシエータからの要求であろうと、何時でもイニシエータにデータを渡すことができる。また、バスリセットが発生しても、バスリセット直前の状態からの処理の続行を保証することができる。
【０１１２】
【他の実施形態】
さらに、図７に示したように、ＯＲＢにはＰＳＩＤ，ＳＳＩＤというチャネル識別子のフィールドを備えている。そのため、ＳＨＰＴ処理部及びＯＲＢディスパッチャがチャネル識別子を識別して、チャネルごとに独立したキュー及び実行エージェントを用いてＯＲＢの生成・処理を行えば、マルチチャネルを実現することができる。この場合、１つの機器であっても、そこに含まれる複数のクライアントそれぞれに１つのチャネルを割り当てることで、クライアントごとに非同期の通信を行わせることができる。このため、例えばデジタル複合機であれば、それが有するスキャナやプリンタそれぞれについてクライアントとなるアプリケーションを設けておけば、それと接続されたホストコンピュータからは、あたかもそれぞれの機能を独立した機器であるかのように使用することができる。フローチャートで示したように、各キューの管理や実行エージェントは独立したプロセスであるために、マルチチャネル化は容易に行うことができる。
【０１１３】
なお、本発明は、複数の機器（例えばホストコンピュータ，インタフェイス機器，リーダ，プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機，ファクシミリ装置など）に適用してもよい。
【０１１４】
また、本発明の目的は、イニシエータとして図１３〜図１８の手順のプログラムコードを記録した記憶媒体をコンピュータに供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても達成される。またターゲットも、図１９〜図２１の手順のプログラムコードを記録した記憶媒体をコンピュータに供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによって実現できる。
【０１１５】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１１６】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
【０１１７】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１１８】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１１９】
また、記憶媒体から読み出されたプログラムコードを実行してイニシエータとなる主体はコンピュータに限らず、データ転送機器であって、ＳＢＰ−２のログイン能力があれば、どのような機器であっても良い。
【０１２０】
以上説明したように、本発明によれば、イニシエータとターゲットとの間において、１回のログインで非同期な双方向通信を可能とし、また、データの交換に必要なプロセスやメモリといった資源を効率的に利用できる。
【０１２１】
また、ＩＥＥＥ１３９４インターフェースを利用しているために、ターゲット側へのデータ転送を、ターゲットがその都合に応じて読み出すことで行うことができ、イニシエータがターゲットの都合によってデータ転送に占有されることを防止できる。
【０１２２】
また、ＳＢＰ−２プロトコルを利用しているため、ターゲットでキューされるのはＯＲＢだけで、実際に転送されるデータそのものは処理待ちの間イニシエータに格納されている。このため、ターゲットのメモリ資源を小容量化できる。
【０１２３】
また、簡単にマルチチャネルを実現できる。
【０１２４】
【発明の効果】
バスリセットが発生しても、バスリセット後に、バスリセット直前の状態から処理を再開することができ、処理の正常な続行を保証することができる。
【０１２５】
【図面の簡単な説明】
【図１】ターゲット（プリンタ）のブロック図である。
【図２】イニシエータ（ホストコンピュータ）のブロック図である。
【図３】イニシエータとターゲットとの間におけるキューの状態の一例を示す図である。
【図４】イニシエータにおけるバスリセット後の復旧の様子の例を示す図である。
【図５】ターゲットにおけるバスリセット後の復旧の様子の例を示す図である。
【図６】イニシエータにおいてＯＲＢリストからＯＲＢを取り外す様子の例を示す図である。
【図７】ＯＲＢ一般のフォーマットを示す図である。
【図８】ライトコマンドＯＲＢのフォーマットを示す図である。
【図９】リードコマンドＯＲＢのフォーマットを示す図である。
【図１０】ステータスブロック一般のフォーマットを示す図である。
【図１１】ライトステータスブロックのフォーマットを示す図である。
【図１２】リードステータスブロックのフォーマットを示す図である。
【図１３】イニシエータのクライアントによる、データ転送要求の発生時の処理手順のフローチャートである。
【図１４】イニシエータのクライアントによる、ＳＨＴＰからの処理終了通知受信時の処理手順のフローチャートである。
【図１５】イニシエータのＳＨＴＰ処理部により実行される、クライアントからコールされるライト関数及びリード関数のフローチャートである。
【図１６】イニシエータのＳＨＴＰ処理部により実行される、ライトＩ／Ｏ要求キュー及びリードＩ／Ｏ要求キューの管理手順のフローチャートである。
【図１７】イニシエータのＳＨＴＰ処理部により実行される、ステータスブロック受信時の処理手順のフローチャートである。
【図１８】イニシエータのＳＨＴＰ処理部により実行される、バスリセット直後の復旧処理手順のフローチャートである。
【図１９】ドアベルレジスタあるいはＯＲＢポインタに書き込みが行われた際のターゲットのフェッチエージェントによる処理手順のフローチャートである。
【図２０】ライト実行エージェントによる処理手順のフローチャートである。
【図２１】リード実行エージェントによる処理手順のフローチャートである。
【図２２】イニシエータ（ホストコンピュータ）からターゲット（プリンタ）へのデータライト時のシーケンスの図である。
【図２３】イニシエータ（ホストコンピュータ）からターゲット（プリンタ）へのデータリード時のシーケンスの図である。
【図２４】ＩＥＥＥ１３９４インターフェースを用いたプリンタシステムのハードウエア構成図である。
【符号の説明】
１ ＣＰＵ
２ ＲＡＭ
３ ＲＯＭ
４ システムバス
１２ ＣＰＵ
１３ ＲＯＭ
１９ ＲＡＭ
１０１ フェッチエージェント
１０３，１０５ プリフェッチキュー
１０４ ライト実行エージェント
１０６ リード実行エージェント
１０８ ターゲット側クライアント
１０９ １３９４インターフェース
１１０ バスインターフェース
２０１ ＳＨＰＴ処理部
２０２ ライトＩ／Ｏ要求キュー
２０３ リードＩ／Ｏ要求キュー
２０４ ＯＲＢリスト
２０５ ステータスＦＩＦＯ
２０６ イニシエータ側クライアント
２０７ ライトバッファ
２０８ リードバッファ
【産業上の利用分野】
本発明は、例えばホストコンピュータとプリンタ等の機器同士を接続する通信制御方法及び装置に関する。
【０００２】
【従来の技術】
近年、ＩＥＥＥ１３９４インターフェースが、コンピュータと周辺機器、あるいは周辺機器同士の接続に用いられつつある。ＩＥＥＥ１３９４インターフェースは、セントロニクスインターフェースなどのハンドシェイク方式に比べて高速で、しかも双方向通信が可能である。また、メモリバスモデルのインターフェースであり、ＩＥＥＥ１３９４インターフェースで接続された機器は、相手の機器に対して指定されたアドレスのデータを読み書きすることができる。
【０００３】
このＩＥＥＥ１３９４は、広範囲に応用するための物理層及びリンク層のプロトコルを定めたもので、機器ごとの詳細なプロトコルは定められていない。そのため、物理・リンク層としてＩＥＥＥ１３９４を利用したＳＢＰ(Serial Bus Protocol)−２などのトランスポート層のプロトコルが提案されている。トランスポート層はアプリケーションに対してデータ転送機能を提供する層であり、この層を利用するアプリケーションは、互いにデータの交換が可能となる。
【０００４】
このＳＢＰ−２なるプロトコルは、ＩＥＥＥ１３９４のメモリバスモデルとしての特徴を活かしたプロトコルであり、データの受信側がそれ自身の都合に応じてデータを受信することができる。これに対して、ＳＢＰ−２以外のプロトコルには、非同期に発生するデータの転送が可能となるものも、マルチチャネルが実現できるものもあるが、そのようなプロトコルではＩＥＥＥ１３９４のメモリバスモデルとしての特徴を活かすことができない。すなわち、ホストとプリンタの通信であれば、プリンタ側の都合に応じてデータ転送を行うことができず、ホストがプリンタの状態を監視しながらデータ転送を行わねばならないことになる。
【０００５】
ＳＢＰ−２では、データを転送する場合に、まず送信側でログインという操作を行って通信相手との間のチャネルを確立する。この際、ログインした側がイニシエータと呼ばれ、イニシエータと接続された相手側がターゲットと呼ばれる。データ転送は、イニシエータからの指示に応じて、ターゲットからイニシエータのバッファにデータを読み書きすることで行われる。この方式においては、イニシエータは、送信するデータを格納したバッファのアドレスやサイズ等が書かれたＯＲＢ(Operation Request Block)を作成し、そのＯＲＢのアドレスをターゲットに知らせる。ターゲットでは自分の都合に合わせてＯＲＢに書かれたアドレスやサイズに基づいてイニシエータからデータを読み出し、あるいはデータを書き込み、それらの処理後ステータスブロックを作成して、処理の状態をイニシエータに知らせることになる。
【０００６】
【発明が解決しようとする課題】
このＩＥＥＥ１３９４の上に構築されるＳＢＰ−２プロトコルを利用して通信を行う場合、特に、ホストコンピュータ等のデータ源をイニシエータとし、それからターゲットであるプリンタ装置などの周辺機器へのデータ転送に応用する場合、次のような４つの問題点があった。
（問題点１）全２重通信のために手順が複雑である。
【０００７】
ＳＢＰ−２では、基本的にデータの転送はイニシエータによって管理され、ターゲットはイニシエータへの非同期のデータ転送を行うことができない。すなわち、ＳＢＰ−２では、ターゲットがイニシエータへのデータ転送を行いたい時には、イニシエータに対してアンソリシテドステータスでデータリード要求を送り、イニシエータはそれに応じてＯＲＢ生成し、ペンディング中のＯＲＢ（イニシエータからターゲットへのデータ転送要求などが含まれている）のリストの末尾にその生成したＯＲＢをつける。このＯＲＢは先頭から順番に処理されるため、ターゲットがイニシエータにリード要求を発行したタイミングではなく、イニシエータ側のＯＲＢの処理が進み、ターゲットからのデータリード要求によるＯＲＢが処理されたときに初めてターゲットからイニシエータにデータが転送されることになる。すなわち、双方向の非同期なデータ転送が行えず、ターゲットからイニシエータに転送すべきデータが非同期に発生する場合、例えばターゲットがプリンタであれば、そのプリンタでエラーが発生する場合など、直ちにイニシエータに伝達すべきデータを即時に伝達できない。
【０００８】
このため、例えばプリンタで非同期に発生するデータを即座にホストに転送するためには、プリンタをイニシエータとしてログイン手続きを行い、ホストコンピュータをターゲットとするデータ転送を行わねばならない。
【０００９】
このようにホストコンピュータとプリンタで互いにログインしてそれぞれがイニシエータでありターゲットであるような状況では、ホストコンピュータ及びプリンタの双方にイニシエータとしてのプロセスとターゲットとしてのプロセスを備えなければならない。また、ログインの操作もプリンタから行わねばならない。
【００１０】
プリンタのような画像を扱う周辺装置では、画像処理のために大量のメモリ資源やプロセッサ資源を消費する。そのために、装置の構成を簡略化して原価を節減したり、処理を迅速に行うため画像処理用途以外に用いられる資源をできるだけ節約しなければならない。しかし、上述のように多くのプロセスを稼働することになればその分多くの資源を消費することになり、原価低減・処理の効率化という目的に反することになる。
【００１１】
また、ホストコンピュータとプリンタとの関係であれば、各方向に流れるデータは、印刷データとそれに対する処理状況といったように、互いに関連付けられるものであるが、各方向について独立したログインによりチャネルを設定すると、それらデータとレスポンスとを関連づけなければならず、そのための処理手順を新たに追加する必要がある。
【００１２】
このようにＩＥＥＥ１３９４及びＳＢＰ−２をそのままホストコンピュータ−プリンタ装置間の通信に適用することは適切でなく、各装置において必要とされる資源を減らすことや効率を向上させることが難しかった。
（問題点２）マルチチャネルを実現できない。
【００１３】
最近、周辺装置として種々の機能を複合させた複合機が利用されつつある。例えば、ファクシミリ装置を、スキャナ単体，プリンタ単体，ファクシミリとしてホストコンピュータ等から利用できるデジタル複合機などがある。このような装置を利用する際には、各単体機能ごとに独立した複数のチャネルを介して通信を行えば、同時に複数の機能を利用することができる。
【００１４】
しかしながら、ＳＢＰ−２では、マルチチャネルを提供できないため、そのように単体機能を同時に利用することが難しい。
（問題点３）バスリセットに対応できない。
【００１５】
ＩＥＥＥ１３９４では、１３９４シリアルバスへの機器の新たな接続や取り外し、あるいは、接続された機器の電源投入や切断といった、ネットワーク構成の変化要因となる状態変化が発生するとバスリセットが発生する。バスリセットは、バス上で上記のような状態変化を検知したノードがバスリセット信号をバス上に送信することで発生する。発生されたバスリセット信号は、ノードからノードへと伝達され、ネットワーク上の全ノードがバスリセット信号を受信すると、バスリセットのための一連の動作が各ノードで行われる。
【００１６】
このようにバスリセットは、ネットワーク上のノードにおける処理とは非同期に発生する。また、バスリセットの原因となったノードとアプリケーションについては無関係なノードであっても、一旦バスリセットが発生してしまえばバスリセットの処理を行わねばならない。このバスリセットの過程で、ＳＢＰ−２で通信を行っているノードでは、設定されていたコネクションが切断されてしまい、再度コネクションをつなげてもバスリセット直前の状態から処理を続行できる保証が与えられていない。
【００１７】
本発明は上記従来例に鑑みてなされたもので、１回のログインで全２重通信（互いに非同期な双方向通信）を可能とし、また、データの交換に必要なプロセスやメモリといった資源を効率的に利用できる通信制御方法及び装置及びそれを用いた印刷装置を提供することを目的とする。
【００１８】
また、マルチチャネルを実現する通信制御方法及び装置及びそれを用いた印刷装置を提供することを目的とする。
【００１９】
また、バスリセットが発生しても、バスリセット直前の状態から処理の続行を保証する通信制御方法及び装置及びそれを用いた印刷装置を提供することを目的とする。
【００２０】
【課題を解決するための手段】
上記目的を達成するために本発明は次のような構成から成る。すなわち、イニシエータとターゲットとの間の通信制御方法であって、前記イニシエータにおいて、前記イニシエータが有する記憶領域においてデータの書き込みあるいは読み出しが行われるべきアドレスを有する命令を前記ターゲットに発行するステップと、前記ターゲットにおいて、発行された命令に従って、前記イニシエータが有する記憶領域における前記アドレスに対するデータの書き込みあるいは前記イニシエータが有する記憶領域における前記アドレスからのデータの読み出しを実行するステップと、前記ターゲットにおいて、データの書き込みあるいは読み出しを実行中の命令の識別子と、当該命令に従ってデータの書き込みあるいは読み出しを行うべき記憶領域を示す、当該命令に対応する前記アドレスからのオフセットとを保持するステップとを有し、前記イニシエータは、前記ターゲットに対して発行した命令を、当該命令に従ったデータの書き込みあるいは読み出しを完了した旨の完了通知を前記ターゲットから受けるまで、再発行可能な状態で保持し、前記通信制御方法はさらに、前記イニシエータと前記ターゲットとの間の接続が一旦切断されて再度確立された後、前記イニシエータにおいて、再発行可能な状態で保持している命令を前記ターゲットに再発行するステップと、前記ターゲットにおいて、再発行された命令の識別子と保持していた識別子とを比較するステップと、前記ターゲットにおいて、再発行された命令の識別子と保持していた識別子との一致を示す第１の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを保持していたオフセットに基づいて実行するステップと、前記ターゲットにおいて、再発行された命令が有する識別子と保持していた識別子との不一致を示す第２の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを実行することなく、再発行された命令に対する前記完了通知を前記イニシエータに発行するステップとを有する。
【００２１】
あるいは、イニシエータとターゲットの間でデータを交換する通信システムであって、前記イニシエータは、前記イニシエータが有する記憶領域においてデータの書き込みあるいは読み出しが行われるべきアドレスを有する命令を前記ターゲットに発行する第１の発行手段と、前記ターゲットに対して発行した命令を、当該命令に従ったデータの書き込みあるいは読み出しを完了した旨の完了通知を前記ターゲットから受けるまで、再発行可能な状態で保持する第１の保持手段とを有し、前記ターゲットは、発行された命令に従って、前記イニシエータが有する記憶領域における前記アドレスに対するデータの書き込みあるいは前記イニシエータが有する記憶領域における前記アドレスからのデータの読み出しを実行する第１の実行手段と、前記第１の実行手段によりデータの書き込みあるいは読み出しを実行中の命令の識別子と、当該命令に従ってデータの書き込みあるいは読み出しを行うべき記憶領域を示す、当該命令に対応する前記アドレスからのオフセットとを保持する第２の保持手段とを有し、前記イニシエータはさらに、前記イニシエータと前記ターゲットとの間の接続が一旦切断されて再度確立された後、再発行可能な状態で保持している命令を前記ターゲットに再発行する再発行手段を有し、前記ターゲットはさらに、再発行された命令の識別子と保持していた識別子とを比較する比較手段と、再発行された命令の識別子と保持していた識別子との一致を示す第１の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを保持していたオフセットに基づいて実行する第２の実行手段と、再発行された命令が有する識別子と保持していた識別子との不一致を示す第２の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを実行することなく、再発行された命令に対する前記完了通知を前記イニシエータに発行する第２の発行手段とを有する。
【００２２】
あるいは、イニシエータとの間でデータを通信するターゲットとしての通信制御装置であって、前記イニシエータによって発行された、前記イニシエータが有する記憶領域においてデータの書き込みあるいは読み出しが行われるべきアドレスを有する命令に従って、前記イニシエータが有する記憶領域における前記アドレスに対するデータの書き込みあるいは前記イニシエータが有する記憶領域における前記アドレスからのデータの読み出しを実行する第１の実行手段と、前記イニシエータによって発行された命令に従ったデータの書き込みあるいは読み出しを完了した旨の完了通知を前記イニシエータに発行する第１の発行手段と、前記第１の実行手段によりデータの書き込みあるいは読み出しを実行中の命令の識別子と、当該命令に従ってデータの書き込みあるいは読み出しを行うべき記憶領域を示す、当該命令に対応する前記アドレスからのオフセットとを保持する識別子保持手段と、前記イニシエータと前記ターゲットとの間の接続が一旦切断されて再度確立された後、前記イニシエータによって再発行された命令の識別子と前記識別子保持手段によって保持されている識別子とを比較する比較手段と、前記比較手段による一致を示す第１の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを前記識別子保持手段によって保持されているオフセットに基づいて実行する第２の実行手段と、前記比較手段による不一致を示す第２の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを実行することなく、再発行された命令に対する前記完了通知を前記イニシエータに発行する第２の発行手段とを有する。
【００２３】
あるいは、イニシエータとの間でデータを交換するターゲットとしての通信制御装置であって、前記イニシエータによって発行された命令に従って、前記イニシエータが有する記憶領域に対するデータの書き込みあるいは前記イニシエータが有する記憶領域からのデータの読み出しを実行する第１の実行手段と、前記イニシエータによって発行された命令に従ったデータの書き込みあるいは読み出しを完了した旨の完了通知を前記イニシエータに発行する第１の発行手段と、前記第１の実行手段によりデータの書き込みあるいは読み出しを実行中の命令の識別子を保持する識別子保持手段と、前記第１の実行手段によりデータの書き込みあるいは読み出しを実行中の命令に従ってデータの書き込みあるいは読み出しを行うべき記憶領域を示す、当該命令に対応して指定されたアドレスからのオフセットを保持するオフセット保持手段と、前記イニシエータによって再発行された命令の識別子と前記識別子保持手段によって保持されている識別子とを比較する比較手段と、前記比較手段による一致を示す比較結果に従って、前記オフセット保持手段によって保持されているオフセットに基づいてデータの書き込みあるいは読み出しを実行する第２の実行手段と、前記比較手段による不一致を示す比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを実行することなく、再発行された命令に対する前記完了通知を前記イニシエータに発行する第２の発行手段とを備える。
【００２６】
【発明の実施の形態】
［第１の実施の形態］
本発明の第１の実施の形態として、ホストコンピュータとプリンタとを、ＩＥＥＥ１３９４で接続し、その上に構築されたＳＢＰ−２プロトコルを用いた、本発明に係るプロトコル（以下ＳＨＰＴと呼ぶ）に従ってデータ転送を行うプリンタシステムを説明する。図２４は、そのプリンタシステムにおけるハードウエア構成図である。
＜システムのハードウエア構成＞
図２４において、ホストコンピュータ２００は、ＲＯＭ３のプログラム用ＲＯＭに記憶された文書処理プログラム等に基づいて、図形，イメージ，文字，表（表計算等を含む）等が混在した文書処理を実行するＣＰＵ１を備える。ＣＰＵ１はシステムデバイス４に接続される各デバイスをＣＰＵ１が総括的に制御する。また、ＲＯＭ３のプログラム用ＲＯＭには、ＣＰＵ１の制御プログラム等が記憶され、ＲＯＭ３のフォント用ＲＯＭには上記文書処理の際に使用するフォントデータ等が記憶され、ＲＯＭ３のデータ用ＲＯＭは上記文書処理等を行う際に使用する各種データが記憶される。ＲＡＭ２は、ＣＰＵ１の主メモリ，ワークエリア等として機能する。プログラムはＲＡＭ２に格納されても良い。また、ＲＡＭ２には、送信データバッファやＯＲＢを格納するシステムメモリが確保される。
【００２７】
キーボードコントローラ（ＫＢＣ）５は、キーボード９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）６は、ＣＲＴディスプレイ（ＣＲＴ）１０の表示を制御する。メモリコントローラ（ＭＣ）７は、プートプログラム，種々のアプリケーション，フォントデータ，ユーザファイル，編集ファイル等を記憶するハードディスク（ＨＤ）、フロッピーディスク（ＦＤ）等の外部メモリ１１とのアクセスを制御する。１３９４インターフェース８は、ＩＥＥＥ１３９４規格に従ってプリンタ１００に接続されて、プリンタ１００との通信制御処理を実行する。なお、ＣＰＵ１は、例えばＲＡＭ２上に設定された表示情報ＲＡＭへのアウトラインフォントの展開（ラスタライズ）処理を実行し、ＣＲＴ１０上でのＷＹＳＩＷＹＧを可能としている。また、ＣＰＵ１は、ＣＲＴ１０上の不図示のマウスカーソル等で指示されたコマンドに基づいて登録された種々のウィンドウを開き、種々のデータ処理を実行する。
【００２８】
プリンタ１００において、プリンタＣＰＵ１２は、ＲＯＭ１３のプログラム用ＲＯＭに記憶された制御プログラム等或いは外部メモリ１４に記憶された制御プログラム等に基づいてシステムバス１５に接続される各種のデバイスとのアクセスを総括的に制御し、印刷部インタフェース１６を介して接続される印刷部（プリンタエンジン）１７に出力情報としての画像信号を出力する。また、このＲＯＭ１３のプログラムＲＯＭには、後述する各種エージェントや画像処理を実現するＣＰＵ１２の制御プログラム等が記憶される。ＲＯＭ１３のフォント用ＲＯＭには上記出力情報を生成する際に使用するフォントデータ等が記憶され、ＲＯＭ１３のデータ用ＲＯＭには、ハードディスク等の外部メモリ１４が無いプリンタの場合には、ホストコンピュータ上で利用される情報等が記憶されている。ＣＰＵ１２は１３９４インターフェース１８を介してホストコンピュータとの通信処理が可能となっており、プリンタ内の情報等をホストコンピュータ２００に通知可能に構成されている。
【００２９】
ＲＡＭ１９は、ＣＰＵ１２の主メモリ、ワークエリア等として機能するＲＡＭで、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。なお、ＲＡＭ１９は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。
【００３０】
前述したハードディスク（ＨＤ）、ＩＣカード等の外部メモリ１４は、メモリコントローラ（ＭＣ）２０によりアクセスを制御される。外部メモリ１４は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。また、操作パネル１８には、操作のためのスイッチおよびＬＥＤ表示器等が配されている。また、前述した外部メモリは１個に限らず、少なくとも１個以上備え、内蔵フォントに加えてオプションフォントカード，言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていても良い。さらに、図示しないＮＶＲＡＭを有し、操作パネル１０１２からのプリンタモード設定情報を記憶するようにしても良い。
【００３１】
＜イニシエータの構成＞
上述したハードウエア構成において、プリンタ１００をターゲットとし、ホストコンピュータ２００をイニシエータとした通信システムを、図１及び図２に示す。本実施形態に置いては、これら構成は、それぞれホストコンピュータ及びプリンタにおけるＣＰＵによりプログラムを実行することで実現される。まず、図２のイニシエータから説明する。
【００３２】
図２において、イニシエータであるホストコンピュータにおいては、プリンタドライバ等のクライアント２０６はＳＨＰＴ処理部２０１を介してプリンタに対するデータ転送要求を発行するとともに、プリンタからの応答を受ける。
【００３３】
ＳＨＰＴ処理部２０１は、システムメモリに生成されるＩ／Ｏ要求キューやＯＲＢを管理している。リードＩ／Ｏ要求キュー２０３にはクライアント２０６からのリード要求コマンドが、ライトＩ／Ｏ要求キュー２０２にはクライアント２０６からのライト要求コマンドが、それぞれキューイングされる。ＯＲＢはイニシエータであるホストコンピュータからターゲットであるプリンタへ、あるいはプリンタからホストコンピュータへ渡されるデータバッファのアドレスやサイズ等を格納したブロックであり、先頭のＯＲＢからＯＲＢリスト２０４に順次リンクされている。このＯＲＢについては、次のような処理の原則がある。
（１）リードＩ／Ｏ要求キュー及びライトＩ／Ｏ要求キューそれぞれの先頭から取り出したコマンドから順にＯＲＢが作成され、ＯＲＢリストの末尾につけられる。リード／ライトの順序には特に制約はない。
（２）ＯＲＢは、ＯＲＢリストの先頭から順次フェッチされる。完了通知（ステータスブロック）を受信すると、そのステータスに対応するＯＲＢはＯＲＢリストからはずされる。
（３）リンクされるＯＲＢの数の上限は、後述するターゲットにおけるリードプリフェッチキュー及びライトプリフェッチキューの容量（それぞれ処理中のコマンドも含む）の合計と同一である。
（１），（２）項により、ライトＩ／Ｏ要求，リードＩ／Ｏ要求は、それぞれのＩ／Ｏ要求において、発生した順にターゲットに発行されることが保証される。また、（３）項により、ＯＲＢリスト中のＩ／Ｏ要求はターゲットに渡されていることが保証される。この（３）項を実現するために、ＳＨＰＴ処理部２０１は、プリンタの２つのプリフェッチキューそれぞれについて２つのカウンタを用意している。ひとつはCurrentReadQUEというカウンタ２０３ａであり、後述するターゲットのリードプリフェッチキューの現在の空容量を示している。また、もうひとつはCurrentWriteQUEというカウンタ２０２ａであり、ターゲットのライトプリフェッチキューの空き容量を示している。これらカウンタの初期値はターゲットとなる機器が保持しており、ログイン時等にターゲットから読み出され、イニシエータに記憶される。これらカウンタはＯＲＢの生成と削除に合わせて増減される。
【００３４】
また、ＯＲＢを生成した際には、ターゲット側のドアベルレジスタと呼ばれるレジスタに所定値を書き込む、あるいは、リストの先頭のＯＲＢのアドレスをＯＲＢポインタと呼ばれるレジスタに書き込むことにより、ＯＲＢが発生したことをターゲットに知らせる。既にターゲットが実行しているＯＲＢリストの最後にＯＲＢした場合にはドアベルレジスタへの書き込みを行い、ＯＲＢリストがない状態で新規に先頭のＯＲＢを作成した場合には、ＯＲＢポインタへの書き込みを行う。この手続きはＳＢＰ−２で規定されている。
【００３５】
また、ＳＨＰＴ処理部２０１は、ステータスＦＩＦＯ２０５を含む。１３９４インターフェース１０９を介して受信されたステータスは、ＳＨＰＴ処理部２０１により処理される。ＳＨＰＴ処理部２０１は、受信したステータスに対応するＯＲＢをＯＲＢリスト２０４から外すとともに、そのＯＲＢに対応するコマンドをＩ／Ｏ要求キューから外す。
【００３６】
イニシエータたるホストコンピュータは以上のような機能的な構成からなっている。
【００３７】
＜ターゲットの構成＞
図１は、ターゲットたるプリンタの機能上の構成を示すブロック図である。図１において、ドアベルレジスタ１０１ａは、イニシエータによって書き込まれるレジスタであり、ＯＲＢが新たに生成されたことを示す。また、ＯＲＢポインタ１０１ｂには、新たに生成されたＯＲＢのアドレスがイニシエータにより書き込まれる。フェッチエージェント１０１は、ドアベル１０１ａに書き込みがあると、１３９４インターフェース１０１を介してＯＲＢポインタで示されるＯＲＢを読み込む。ＯＲＢディスパッチャ１０２は、フェッチエージェント１０１により読み込まれたＯＲＢがライトコマンドＯＲＢであればライトコマンドをライトプリフェッチキュー１０３の末尾につけ、リードコマンドＯＲＢであればリードコマンドをリードプリフェッチキュー１０５の末尾につける。このコマンドの種類は、ＯＲＢのファンクションフィールドの値に応じて判定される。
【００３８】
ライト実行エージェント１０４及びリード実行エージェント１０６は、それぞれライトプリフェッチキュー１０３及びリードプリフェッチキュー１０５にキューイングされたコマンドを先頭から取り出し、イニシエータのバッファへのデータの書込み及びイニシエータのバッファからのデータの読み出しを行う。その後、ホストコンピュータにノーマルステータスを返す。
【００３９】
なお、リード実行エージェント１０６は、例えばＰＤＬを解釈実行してラスタデータを生成するラスタライザ等のクライアント１０８からのデータ転送要求に応じて、リードプリフェッチキュー内のリードコマンドで指定されたイニシエータのバッファにデータを書き込む。このデータ転送要求は、イニシエータからのライトコマンドやリードコマンドとは非同期に発生するため、イニシエータはリードコマンドＯＲＢによってリードプリフェッチキューにリードコマンドを常時キューイングしておく。ターゲットは、リードコマンドがプリフェッチキューにキューイングされている限り、いつでもデータをイニシエータに渡すことができる。なお、バスインターフェース１１０は、ターゲットであるプリンタ１００からイニシエータであるホストコンピュータ２００のシステムメモリ２０８の所望のメモリロケーションにアクセスするためのインターフェースである。
【００４０】
以上、イニシエータ及びタ−ゲットの構成と動作を簡単に説明した。これらを更に詳しく説明する前に、まずＯＲＢの詳しい内容を説明する。
【００４１】
＜コマンドＯＲＢ(Operation Request Block)の内容＞
図７はＯＲＢ一般の構成を示す図である。図７（Ａ）において、"Next_ORB"（リンク）フィールド３０１は、次のＯＲＢへのリンクである。次のＯＲＢがない場合にはそれを表す所定の値が入れられる。なお、先頭のＯＲＢは、所定のアドレスレジスタにより示される。"data_descripter"（データデスクリプタ）フィールド３０２は、データバッファのアドレスを示す。"d"（方向）フィールド３０３は、ホストコンピュータからプリンタへのデータ転送（０：ライト）か、プリンタからホストコンピュータへのデータ転送（１：リード）かを示す。"data_size"（データサイズ）フィールド３０４は、アドレスフィールド３０２で指し示されるデータバッファのサイズを示す。以上、図の点線よりも上のフィールド（未説明のフィールドも含めて）がＳＢＰ−２で規定されているフィールドであり、これから説明するフィールド３０５〜３０８が、ＳＨＰＴに固有の処理に用いられるフィールドである。
【００４２】
"PSID"フィールド３０５ａ，"SSID"フィールド３０５ｂは、使用されるチャネルＩＤを表わしている。"function"（ファンクション）フィールド３０６は、図７（Ｂ）に示すようにＯＲＢの種類を示している。０Ｈがライトコマンド、４０Ｈがリードコマンドを表わす。
【００４３】
"t"（タグ）ビット３０７はデータタグを表している。"seq_ID"（シーケンスＩＤ）フィールド３０８は、ファンクションごと（リードあるいはライトコマンド）に、ＯＲＢの生成順に振られるシーケンシャルな識別子である。この識別子は、本実施形態ではＯＲＢが生成されるごとに１ずつ増えるように与えられる。なお、このシーケンスＩＤフィールドに値を与える基準となるカウンタは、バスリセットや他の障害による影響を受けない領域に設けられる。それは、ターゲットにおいては、シーケンスＩＤの連続性を前提として処理を行うためである。コントロールブロックフィールド３０９には、ファンクションフィールド３０６の値や、各ファンクションに対してターゲットで実現される機能に応じて様々な値が入れられる。なお、バッファのアドレスやサイズについては、Ｉ／Ｏ要求キューに入れられたコマンドからＯＲＢ生成時に得る。次に、機能ごとにＯＲＢの内容を説明する。
【００４４】
（ライトコマンドＯＲＢ）
図８はファンクション＝０ＨのライトコマンドＯＲＢを示している。このコマンドは、指定したバッファ内のデータをイニシエータからターゲットに渡すためのコマンドである。ファンクションフィールドの値は０Ｈであり、シーケンスＩＤは、ひとつのチャネルごとに、各ライトコマンドに対して昇順に与えられる。
【００４５】
（リードコマンドＯＲＢ）
図９はファンクション＝４０ＨのリードコマンドＯＲＢを示している。このコマンドは、イニシエータがターゲットからデータを読み出すためのコマンドである。ファンクションフィールドの値は４０Ｈであり、シーケンスＩＤは、ひとつのチャネルごとに、各リードコマンドに対して昇順に与えられる。
【００４６】
（ステータスブロック）
図１０（Ａ）〜（Ｃ）は、ターゲットからイニシエータに返されるステータスの形式及びその内容を示している。図１０（Ａ）において、点線よりも上のフィールドはＳＢＰ−２で規定されたフィールドであるため、特に説明をしない。ＰＳＩＤフィールド４０１，ＳＳＩＤフィールド４０２，ファンクションフィールド４０３，タグフィールド４０４は、図７のコマンドＯＲＢと同様のフィールである。図１０（Ｂ）にファンクションフィールドの値とその意味を示す。
【００４７】
"SHPT_status"（ＳＨＰＴステータス）フィールド図１０（Ｃ）に示すような意味を持つ。すなわち、値が０であれば、そのステータス対応するコマンドＯＲＢについての処理は完了したことを示す。例えば、対応するコマンドＯＲＢがライトコマンドであれば、ＳＨＰＴステータスが０のステータスブロックは、対応するライトコマンドＯＲＢで差し示されたバッファから、ターゲットがデータを全て読み出し、ターゲットの持つバッファに書き込み終えたことを意味する。また、値が１であれば、対応するコマンドＯＲＢの処理が部分的な終了していることを示す。また、値が２であれば、対応するコマンドＯＲＢの処理はエラーにより行われなかったことを示す。このエラーを受けたイニシエータは、クライアントにエラーである旨知らせるなどしてエラーに対応する。
【００４８】
"length_hi"（レングスハイ）フィールド４０５及び"length_lo"（レングスロウ）フィールド４０６は、処理されたデータ長を示す。
【００４９】
（ライトステータスブロック）
図１１は、ファンクション＝０のライトステータスブロックであり、ライトコマンドに対してターゲットからイニシエータに渡される。処理の状態は、ＳＨＰＴステータスにより、図１０（Ｃ）のように表わされる。
【００５０】
（リードステータスブロック）
図１２は、ファンクション＝４０Ｈのリードステータスブロックであり、リードコマンドに対してターゲットからイニシエータに渡される。処理の状態は、ＳＨＰＴステータスにより、図１０（Ｃ）のように表わされる。
【００５１】
＜ＯＲＢの管理＞
次に、以上説明したイニシエータ及びターゲットの構成や、コマンドＯＲＢ及びステータスブロックの構成に基づいて、ＯＲＢがどのように用いられているか説明する。
【００５２】
図３は、イニシエータ及びクライアント間におけるコマンドの流れを示している。まずライトコマンドについて説明する。イニシエータのクライアントからデータ転送要求が発生すると、クライアントはターゲットに渡すデータを格納したバッファのアドレス及びサイズを含むライトコマンドを、ライトＩ／Ｏ要求キュー２０２の末尾につける。ＳＨＰＴ処理部２０１では、ターゲットのライトプリフェッチキュー１０３の空き容量を示すCurrentWriteQUE２０２ａをチェックし、空きがあればそのライトコマンドからＯＲＢを生成してＯＲＢリスト２０４の末尾にリンクするが、空きがなければ空きを待つ。図３の状態では、ライトプリフェッチキューはライトコマンドＷ１〜Ｗ４によっていっぱいであり、その後のライトコマンドＷ５及びＷ６はライトＩ／Ｏ要求キューで待たされている。なお、ＯＲＢが生成されてもそれに対応するライトコマンドはライトＩ／Ｏ要求キューから削除されず、ターゲットからの完了ステータスを受けた時点で削除される。
【００５３】
ＳＨＰＴ処理部２０１は、ＯＲＢをＯＲＢリストに入れると、１３９４インターフェースを介してターゲットのドアベル１０１ａに書き込む、あるいは、ＯＲＢポインタ１０１ｂに新たなＯＲＢのアドレスを書き込む。ディスパッチャ１０２は、そのＯＲＢに基づいて、ライトコマンドをライトプリフェッチキュー１０３の末尾につける。ライト実行エージェント１０４は、ライトプリフェッチキュー内のコマンドを順次実行する。すなわち、ターゲットのクライアントの用意したバッファに、ライトコマンドで示されるバッファの内容を書き込む。ライト実行エージェントは、コマンドの処理が完了すると、ＳＨＰＴステータスが「完了」であるステータスブロックをイニシエータのステータスＦＩＦＯ２０５に書き込む。
【００５４】
ＳＨＰＴ処理部２０１は、ステータスＦＩＦＯに入れられたステータスブロックを先頭から処理する。すなわち、ＳＨＰＴステータスが「完了」であれば、そのステータスブロックに対応するＯＲＢをＯＲＢリストから外し、それとともにライトＩ／Ｏ要求キュー内の対応するライトコマンドを削除する。以上の手順は、リードコマンドについても全く同様である。ただし、リードコマンドは、ターゲットにおいてリードすべきデータが発生しない限り処理されない。従って、イニシエータから発行されたリードコマンドＯＲＢは、リードすべきデータが発生するまでリードプリフェッチキューにキューイングされたままということになる。
【００５５】
イニシエータがホストコンピュータ、ターゲットがプリンタである場合、ホストコンピュータからプリンタに印刷データを渡すためには、上述のライトコマンドを用いて、イニシエータのクライアントであるプリンタドライバから、ターゲットのクライアントであるラスタライザに印刷データが渡される。また、ホストコンピュータがプリンタの構成や状態を示す情報を要求する場合には、その旨のコマンド（クライアントレベルのコマンド）をプリンタにライトコマンドで渡す。それを受けたプリンタ（のクライアント）は、リードプリフェッチキューにキューイングされているリードコマンドを用いて、ホストコンピュータに要求されたデータを渡す。さらに、プリンタでエラーが発生したような場合には、プリンタのクライアントは、リードプリフェッチキューにキューイングされているリードコマンドを用いて、自発的にエラー情報をホストコンピュータに渡すことができる。このため、ホストコンピュータはプリンタと接続している間は、運用上少なくとも１つのリードＯＲＢをプリンタに対して発行しておく。さらに、リードコマンドを常時リードプリフェッチキューにキューイングさせておくためには、少なくとも２つのリードＯＲＢをプリンタに対して発行しておくことが望ましい。
【００５６】
図６はＯＲＢリストの更新の様子を示している。状態１から、ライトコマンドＷ１とリードコマンドＲ１とが処理されてそれらのＯＲＢはＯＲＢから削除される（状態２）。このため、ライトＯＲＢＷ２，Ｗ３のリンク先はなくなる。この場合、これらＯＲＢは既にターゲットに渡っているため、これらをＯＲＢリストにつなぎなおす必用はない。また、ＯＲＢリストになくとも、Ｉ／Ｏ要求キューには対応コマンドが残っているため、後述するエラー復旧処理も正常に行うことができる。
【００５７】
＜エラーの復旧（イニシエータ）＞
既に説明したように、ＳＢＰ−２では、ネットワークに異常（エラー）に起因するバスリセットにより、イニシエータとターゲットとの間の接続は断たれてしまう。そこで、ＳＨＰＴでは、バスリセットにより失われた状態を復旧するための手順を定めている。図４〜図６を参照してその手順の概要を説明する。
【００５８】
図４はイニシエータの状態を示している。図４において、状態１では、ライトコマンドＷ１〜Ｗ４のライトＯＲＢと、リードコマンドＲ１〜Ｒ３のリードＯＲＢが発行されており、ライトコマンドＷ５，Ｗ６はライトＩ／Ｏ要求キュー２０２にとどめられた状態にある。ターゲットにより１つのライトコマンドと２つのリードコマンドとが処理され、イニシエータは状態２に遷移する。処理されたコマンドに対応するＯＲＢはＯＲＢリスト２０４からはずされ、空き領域となっている。この状態では、ライトプリフェッチキューに空きが生じているが、まだライトコマンドＷ５に対応するＯＲＢは発行されていない。
【００５９】
ここでネットワーク上のエラーなどからバスリセットが発生する。バスリセットの処理が終えたなら、全てのＯＲＢをＯＲＢリストから消去する（状態３）。ライトＩ／Ｏ要求キュー２０２ならびにリードＩ／Ｏ要求キュー２０３は、バスリセットがあってもリセットされることはない。
【００６０】
イニシエータは、コネクションを再設定した後、ライトＩ／Ｏ要求キューならびにリードＩ／Ｏ要求キューを参照して、それらキューの内容から新たにＯＲＢを生成し、ターゲットに対して発行する。これが状態４である。ＯＲＢの生成時に対応するコマンドに対して何等かのマークをしておけば、バスリセット直前の状態を再現することができる。
【００６１】
また、図４には示されていないが、ステータスＦＩＦＯはバスリセットでは影響を受けないため、特に復旧する必用はない。
【００６２】
＜エラーの復旧（ターゲット）＞
図５は、ターゲット側におけるバスリセット後の復旧の様子を示す図である。イニシエータはＯＲＢリストを復旧させるだけでその状態をバスリセット直前の状態に戻せるが、ターゲットはリード／ライトコマンドに応じてバッファに対してリード／ライトを行うため、リード／ライト中にバスリセットが発生した場合には、復旧後はその続きを行わねばならない。そのために、ターゲットのリード／ライト実行エージェントは、処理中のコマンドと、処理中のバッファの位置を記憶している。
【００６３】
図５では例としてリードコマンドの場合を示している。イニシエータがリードＯＲＢを発行し、ターゲットはそれをリード実行エージェントによって処理する。実行前に、リード実行エージェント１０６はこれから処理するリードＯＲＢのseq_IDフィールドを読み出し、シーケンス識別子(Sequenceidentifier)として記憶しておく。図５ではその値は「３」である。また、クライアントのバッファにデータを書き込むに当たり、現在書き込んでいるバッファのアドレスを実行ポインタ(Nextexecpointer)として更新しつづける。図５ではその値は「offset」である。これらの領域はバスリセットによって消去されないメモリ領域に確保される。
【００６４】
バスリセットが終了したなら、イニシエータはＯＲＢを改めて発行してくるため、リード実行エージェントは、リードプリフェッチキューの先頭のＯＲＢのseq_IDフィールドが、記憶されているシーケンス識別子よりも古ければ、そのＯＲＢは既に処理は完了しているために、完了ステータスを返す。両者が一致すれば、Nextexecpointerで示されるアドレスから書き込みを続行する。
【００６５】
ライトコマンドについても同じ要領で復旧される。
【００６６】
以上、本実施形態の印刷システムにおいて用いられるコマンドおよびステータスについて説明した。次に、イニシエータおよびターゲットにおけるコマンド及びステータスの処理手順を説明する。
【００６７】
＜イニシエータのクライアントによるデータ転送要求＞
図１３は、イニシエータのクライアントであるプリンタドライバ等から、ターゲットに対して、データを送信あるいは要求する際の手順を示している。
【００６８】
データ転送事項が発生したなら（ステップＳ１３０１）、そのために必用なコマンドがライトであるかリードであるか判定し（ステップＳ１３０２）、ライトならばそのためのデータ転送バッファがあるか調べ（ステップＳ１３０３）、また、ターゲットに渡すべき送信データの準備ができているか調べて（ステップＳ１３０４）、すべて準備できていれば、バッファのアドレスやサイズ等、必用な引き数を与えてライトコマンドを作成し（ステップＳ１３０５）、ライト関数をコールする（ステップＳ１３０６）。
【００６９】
一方、リードコマンドであると判定されれば、データを受けるための転送バッファがあるか調べ（ステップＳ１３０７）、あればバッファのアドレスやサイズ等、必用な引き数を与えてリードコマンドを作成し（ステップＳ１３０８）、リード関数をコールする（ステップＳ１３０９）。
【００７０】
例えば、データ転送事項がプリンタに対する印刷データの送信ならば、ＰＤＬなど、クライアントレベルのコマンドやデータをバッファに用意し、ライトコマンドを作成することになるし、データ転送事項がプリンタからの状態の読み出しであれば、その旨を示すクライアントレベルのコマンドを用意してライトコマンドを作成するとともに、ターゲットからデータを受けるためのリードコマンドを作成する必用がある。また、ターゲットとの一連のデータ交換を行うに先立って、イニシエータのクライアントはリードコマンドを幾つか発行する。
【００７１】
図１４は、イニシエータのクライアントが下位すなわちＳＨＴＰの層から処理終了通知を受けた際の処理手順である。まず、終了した処理がリードかライトか判定し（ステップＳ１４０１）、ライトであれば使用したデータバッファを解放する（ステップＳ１４０２）。一方、リードであれば、処理の終了はデータの受信の完了であるから、受信したデータに対応した処理を行い（ステップＳ１４０３）、データバッファを解放する（ステップＳ１４０４）。
【００７２】
＜イニシエータのＳＨＰＴ処理部による処理＞
図１５〜図１８は、イニシエータのＳＨＰＴ処理部による処理手順である。図１５（Ａ）及び（Ｂ）は、それぞれクライアントがコールするライト関数及びリード関数の内容を示す。ライト関数では、ライトＩ／Ｏ要求キューにライトコマンドを追加し、リード関数では、リードＩ／Ｏ要求キューにリードコマンドを追加する。
【００７３】
（Ｉ／Ｏ要求キュー管理）
図１６（Ａ），（Ｂ）は、それぞれライトＩ／Ｏ要求キュー管理手順，リードＩ／Ｏ要求キュー管理手順を示す。これらの手順は、それぞれ単独のスレッドで行われる。両者の処理内容は、管理対象がライトＩ／ＯキューとリードＩ／Ｏキューとで異なるものの、同一であるため、ライトＩ／Ｏ要求キュー管理手順のみを説明する。その説明のライトＩ／Ｏ要求キューをリードＩ／Ｏ要求キューに、カウンタCurrentWriteQUEをCurrentReadQUEに、参照番号のＳ１６０ＸをＳ１６１Ｘに読み替えれば、リードＩ／Ｏ要求キューの管理手順となる。
【００７４】
まず、ライトＩ／Ｏ要求キュー内にＯＲＢ化されていないコマンドがあるか調べる（ステップＳ１６０１）。あれば、ターゲットのプリフェッチキューの空き容量を示すカウンタCurrentWriteQUEが０より大きいか、すなわち空きがあるか判定する（ステップＳ１６０２）。空きがあればCurrentWriteQUEの値から１減じ（ステップＳ１６０３）、ライトＩ／Ｏ要求キューに格納されている、ＯＲＢ化されていない先頭のコマンドを基に、シーケンスＩＤ(Seq_ID)やＳＨＰＴコマンド(Function)を付加して、ＯＲＢを作成する（ステップＳ１６０４）。
【００７５】
こうして作成したＯＲＢをＯＲＢリストにつけ（ステップＳ１６０５）、ターゲットのドアベルに書き込む、あるいは、ＯＲＢポインタにＯＲＢのアドレスを書き込む（ステップＳ１６０６）。このようにして、Ｉ／Ｏ要求キュー内のコマンドからＯＲＢが作成される。
【００７６】
（ステータスブロックに対する処理）
図１７は、ステータスブロックをターゲットから受けた際の処理手順である。ＯＲＢに対する処理完了のステータスブロックを受けると、対応するＯＲＢをＯＲＢリストから削除し（ステップＳ１７０１）、対応ＯＲＢがライトかそれともリードか判定する（ステップＳ１７０２）。ライトであれば、ライトＩ／Ｏ要求キューから、削除したＯＲＢの元となったコマンドを削除する（ステップＳ１７０３）。そして、ターゲットで処理を終えた分だけプリフェッチキューが空いたはずなので、カウンタCurrentWriteQUEに１加算する（ステップＳ１７０４）。最後に、クライアントに処理の終了を通知する（ステップＳ１７０５）。クライアントはこれを受けて、図１４の処理を行うことになる。
【００７７】
一方、対応ＯＲＢがリードであると判定された場合には、リードＩ／Ｏ要求キューから、削除したＯＲＢの元となったコマンドを削除する（ステップＳ１７０６）。そして、ターゲットで処理を終えた分だけプリフェッチキューが空いたはずなので、カウンタCurrentReadQUEに１加算する（ステップＳ１７０７）。最後に、クライアントに処理の終了を通知する（ステップＳ１７０８）。
【００７８】
（エラー復旧処理）
ＳＨＰＴ処理部における通常の処理は以上のとおりである。次にバスリセット後などに復旧する手順を図１８により説明する。バスリセットが生じてターゲットとのコネクションが切断されてしまった場合、あらためてコネクションの再設定から行わねばならない。
【００７９】
まず、新規のＯＲＢのリンク処理を中断し（ステップＳ１８０１）、ＯＲＢリストを破棄する（ステップＳ１８０２）。この後コネクションの再接続命令を出して（ステップＳ１８０３）、コネクションの確立を調べ（ステップＳ１８０４）、コネクションが再度張られたなら、ライトＩ／Ｏ要求キュー及びリードＩ／Ｏ要求キュー内の先頭のコマンドから順に対応するＯＲＢを作成する（ステップＳ１８０５）。作成されたＯＲＢはＯＲＢリストにリンクされ（ステップＳ１８０６）、ＯＲＢポインタにアドレスを書き込んで（ステップＳ１８０７）、ターゲットにＯＲＢの発生を知らせる。
【００８０】
一方、コネクションが再設定できないまま一定時間経過すると（ステップＳ１８０８）、ライトＩ／Ｏ要求キュー及びリードＩ／Ｏ要求キュー内のコマンドをすべて破棄し（ステップＳ１８０９）、異常である旨をクライアントに知らせて（ステップＳ１８１０）、処理を終える。
【００８１】
異常の手順により、リセット後に、あらためてターゲットとのコネクションを確立し、リセット直前のＯＲＢリストを復旧することができる。
【００８２】
＜ターゲットによる処理＞
図１９〜２１は、ＯＲＢを受けたターゲットによる処理手順である。
【００８３】
（フェッチエージェントによる処理）
フェッチエージェントはドアベルレジスタあるいはＯＲＢポインタに書き込みがあるとＯＲＢをフェッチする。まず、ドアベルへの書き込みにより起動されたか判定し（ステップＳ１９０１）、そうでなく、ＯＲＢポインタへの書き込みにより起動されたのであればステップＳ１９０５に進む。一方、ドアベルへの書き込みがあったならば、フラグＮｕｌｌｆｌｇをテストする（ステップＳ１９０２）。このフラグは、ＯＲＢポインタに有効な値がセットされていないことを示すフラグであり、Ｎｕｌｌｆｌｇがオフであれば、ＯＲＢポインタには処理すべきＯＲＢのアドレスが書き込まれているから、ステップＳ１９０５へと進む。Ｎｕｌｌｆｌｇがオンであれば、現在のＯＲＢポインタで指されているＯＲＢのNext_ORBフィールドの値を、ＯＲＢポインタへと書き込み（ステップＳ１９０３）、Ｎｕｌｌｆｌｇをオフにセットする（ステップＳ１９０４）。
【００８４】
こうしてＯＲＢポインタに処理すべきＯＲＢのアドレスが得られたなら、そのアドレスからＯＲＢを読み出す（ステップＳ１９０５）。読み出したＯＲＢのファンクションフィールドを参照して、そのＳＨＰＴコマンドがライトであるかリードであるか判定する（ステップＳ１９０６）。ライトであればライトＯＲＢをライトプリフェッチキューにつけ（ステップＳ１９０７）、リードであればリードＯＲＢをリードプリフェッチキューにつける（ステップＳ１９０８）。
【００８５】
この後、処理を終えたＯＲＢのNext_ORBフィールドを参照して、その内容がNULL、すなわちリンクされているＯＲＢがなければ、フラグＮｕｌｌｆｌｇをオンにして、ドアベルあるいはＯＲＢポインタへ書き込みがあるまで待つ。一方、リンクされているＯＲＢがあれば、ＯＲＢポインタで指されているＯＲＢのNext_ORBフィールドの値を、ＯＲＢポインタに書き込む（ステップＳ１９１０）。ＯＲＢリストにリンクされているＯＲＢ全てについてプリフェッチキューに入れるまで、この手順を繰り返す。
【００８６】
このようにして、ＯＲＢリストのＯＲＢをプリフェッチキューにいれる。また、ステップＳ１９０６〜Ｓ１９０８の処理は、図１においてＯＲＢディスパッチャとして説明した処理である。
【００８７】
（ライト実行エージェント）
ライト実行エージェントは、まずライトプリフェッチキューに未処理のライトコマンドがあるか調べ（ステップＳ２００１）、あればNextreadpointerの指すＯＲＢをライトプリフェッチキューから取り出す（ステップＳ２００２）。なおNextreadpointerはキューの先頭のＯＲＢを指し示すポインタである。ＯＲＢを読み出すと、そのＯＲＢのSeq_IDフィールドの値が、ライト実行エージェントが保持する変数Sequenceidentifierよりも小さい値であるか判定する（ステップＳ２００３）。ただし、Seq_ID及びSequenceidentifierはともに有限の桁数である。そこで、Seq_ID及びSequenceidentifierがともにｎビットで表わされる場合、ステップＳ２００３における比較では、（（２のｎ乗−１）＜０（＝２のｎ乗））と定めておく。
【００８８】
通常のシーケンスであれば、ひとつのＯＲＢの処理終了後、Sequenceidentifierには後述のように１加算される。また、SequenceidentifierとＯＲＢのSeq_IDは同じ桁数であり、Seq_IDも１ずつ加算される。そのため、支障なく処理が進んでいる場合には、SequenceidentifierとＯＲＢのSeq_IDとは、ステップＳ２００３において一致しているはずである。したがって、正常に処理が進めば、処理はステップＳ２００３からステップＳ２００４に移行する。
【００８９】
そこでは、クライアントがバッファを用意してあるか調べ（ステップＳ２００４）、用意できたなら、ＯＲＢのDataDescripterの値とライト実行エージェントが保持するNextexecpointerに格納されたｏｆｆｓｅｔ値とを加えたアドレスから所定サイズのデータを読み、クライアントが用意したバッファに格納する（ステップＳ２００５）。新たにＯＲＢの処理を行う場合には、ｏｆｆｓｅｔは０であるから、ＯＲＢにより指し示されるバッファの先頭から読み出すことになる。また、途中まで読み出されているバッファを続きから読む場合には、ｏｆｆｓｅｔは、バッファ中における続きのアドレスを示しているので、これを加算することで続きから読み出しを続行できる。データをバッファに格納したなら、DataDescripterの値＋ｏｆｆｓｅｔが次に読み出されるアドレスを指すように、Nextexecpointerを更新する（ステップＳ２００６）。このような読み出しを、ＯＲＢのdata_sizeで示されるサイズ分に達するまで行う（ステップＳ２００７）。
【００９０】
こうして１つのＯＲＢの処理を終えると、Sequenceidentifierに１加算して更新し（ステップＳ２００８）、Nextexecpointer（ｏｆｆｓｅｔ）を０に初期化する（ステップＳ２００９）。
【００９１】
処理を終えたなら、処理完了を通知するステータスブロックを作成し（ステップＳ２０１０）、ステータスＦＩＦＯに書き込み（ステップＳ２０１１）、ターゲットのクライアントに受信完了を通知する（ステップＳ２０１２）。
【００９２】
ステップＳ２００３において、ＯＲＢのSeq_IDがSequenceidentifierよりも小さい場合は、バスリセットなどにより、イニシエータが図１８の手順でＯＲＢリストを再生したような場合である。例えば、あるＯＲＢについて、ターゲットは処理を終え、Sequenceidentifierの値も更新していても、そのステータスブロックがイニシエータに届いていない時点でバスリセットが発生すると、イニシエータはそのＯＲＢもＯＲＢリストに入れてしまう。この場合に、ＯＲＢのSeq_IDよりも実行エージェントのSequenceidentifierの方が大きくなる。この場合には、そのＯＲＢは処理を終えているため、ステップＳ２０１０以降によりステータスブロックをイニシエータに渡す。
【００９３】
（リード実行エージェント）
リード実行エージェントは、まずリードプリフェッチキューに未処理のリードコマンドがあるか調べ（ステップＳ２１０１）、あればNextreadpointerの指すＯＲＢをリードプリフェッチキューから取り出す（ステップＳ２１０２）。このNextreadpointerは、ライト実行エージェントのそれと同じ名称ではあるが、それとは独立して備えられている。なおNextreadpointerはキューの先頭のＯＲＢを指し示すポインタである。ＯＲＢを読み出すと、そのＯＲＢのSeq_IDフィールドの値が、リード実行エージェントが保持する変数Sequenceidentifierよりも小さい値であるか判定する（ステップＳ２１０３）。このSequenceidentifierも、ライト実行エージェントのそれと同じ名称ではあるが、それとは独立して有する。Seq_ID及びSequenceidentifierはともに有限の桁数である。そこで、Seq_ID及びSequenceidentifierがともにｎビットで表わされる場合、ステップＳ２１０３における比較では、（（２のｎ乗−１）＜０（＝２のｎ乗））と定めておく。
【００９４】
通常のシーケンスであれば、ひとつのＯＲＢの処理終了後、Sequenceidentifierには後述のように１加算される。また、SequenceidentifierとＯＲＢのSeq_IDは同じ桁数であり、Seq_IDも１ずつ加算される。そのため、支障なく処理が進んでいる場合には、SequenceidentifierとＯＲＢのSeq_IDとは、ステップＳ２００３において一致しているはずである。したがって、正常に処理が進めば、処理はステップＳ２１０３からステップＳ２１０４に移行する。
【００９５】
そこでは、クライアントがデータを用意してあるか調べ（ステップＳ２１０４）、用意できたなら、ＯＲＢのDataDescripterの値とリード実行エージェントが保持するNextexecpointerに格納されたｏｆｆｓｅｔ値とを加えたアドレスに、クライアントのデータを所定サイズ書き込む（ステップＳ２１０５）。なお、このNextexecpointerも、ライト実行エージェントのそれと同じ名称ではあるが、それとは別のポインタである。新たにＯＲＢの処理を行う場合には、ｏｆｆｓｅｔは０であるから、ＯＲＢにより指し示されるバッファの先頭から書き込むことになる。また、途中まで書き込まれているバッファを続きから書く場合には、ｏｆｆｓｅｔは、バッファ中における続きのアドレスを示しているので、これを加算することで続きから書き込みを続行できる。データをバッファに格納したなら、DataDescripterの値＋ｏｆｆｓｅｔが次に書き込まれるアドレスを指すように、Nextexecpointerを更新する（ステップＳ２１０６）。このようなデータの書き込みを、クライアントが用意したデータを書き込み終えるまで行う（ステップＳ２１０７）。
【００９６】
こうして１つのＯＲＢの処理を終えると、Sequenceidentifierに１加算して更新し（ステップＳ２１０８）、Nextexecpointer（ｏｆｆｓｅｔ）を０に初期化する（ステップＳ２１０９）。
【００９７】
処理を終えたなら、処理完了を通知するステータスブロックを作成し（ステップＳ２１１０）、ステータスＦＩＦＯに書き込み（ステップＳ２１１１）、ターゲットのクライアントに受信完了を通知する（ステップＳ２１１２）。
【００９８】
ステップＳ２１０３において、ＯＲＢのSeq_IDがSequenceidentifierよりも小さい場合は、バスリセットなどにより、イニシエータが図１８の手順でＯＲＢリストを再生したような場合であるので、ライト実行エージェントと同様に、ステップＳ２１１０以降によりステータスブロックをイニシエータに渡す。
【００９９】
＜ターゲットへのデータライトシーケンス＞
図２２は、イニシエータ（ホストコンピュータ）からターゲット（プリンタ）へのライトを行う際のシーケンス例である。
【０１００】
なお、図中のＳＢＰ−２とは、ＳＢＰ−２規格で規定されたデータ、すなわちＳＢＰ−２で規定されたフィールドを処理する処理層である。また、ＳＨＰＴとは、ＳＢＰ−２で規定されいない、ファンクションごとに定められた処理を行う処理層である。ＳＨＰＴでは、前述したフローチャートの手順を行う。ＳＢＰ−２は、その手順において、ＯＲＢのリンクやドアベルのライト、ＯＲＢやステータスのＳＨＰＴへの引き渡し等の機能を果たす。
【０１０１】
まず、イニシエータのクライアントでデータ及びライトコマンドが、ＳＨＰＴでＯＲＢ（ここではライトＯＲＢ）が作成され、カウンタCurrentWriteQUEが１減らされて、ＯＲＢのリンク要求がＳＢＰ−２に出される（１９０１）。ＳＢＰ−２ではＯＲＢをリンクしてドアベルレジスタにライト要求を出す（１９０２）。１３９４インタフェースにより、ドアベルレジスタが書き込まれ（１９０３）、それがターゲットのＳＢＰ−２に通知される（１９０４）。
【０１０２】
通知を受けたＳＢＰ−２は、ＯＲＢリード要求を１３９４インタフェースに出して（１９０５）、システムメモリからＯＲＢが読み出される（１９０６）。ＳＨＰＴは、読み出されたＯＲＢの内容に応じて対応キューに格納する（１９０７）。ここではライトコマンドＯＲＢなので、１３９４インタフェースに対してデータリード要求を出す（１９０８）。これに応じて、指定されたアドレスからデータが読み出され、クライアントに渡される（１９０９）。クライアントは、この場合画像の展開を行うラスタライザ等であり、データが展開された画像であればそれはプリンタエンジンから印刷出力されることになる。
【０１０３】
処理が済むとライト実行エージェントからＳＢＰ−２に対してステータスブロック送信要求が出され（１９１０）、ステータスブロックがイニシエータに返される（１９１１）。イニシエータのＳＨＴＰは、これを受けると対応ＯＲＢをリンクから削除し、空きキューカウンタを１増やす（１９１２）。
【０１０４】
以上のシーケンスによりイニシエータからターゲットにデータが書き込まれる。
【０１０５】
＜ターゲットからのデータリードシーケンス＞
図２３は、イニシエータ（ホストコンピュータ）からターゲット（プリンタ）のデータのリードを行う際のシーケンス例である。
【０１０６】
まず、イニシエータのクライアントでリードコマンドが、ＳＨＰＴでＯＲＢ（ここではリードＯＲＢ）が作成され、カウンタCurrentReadQUEが１減らされて、ＯＲＢのリンク要求がＳＢＰ−２に出される（１９０１）。ＳＢＰ−２ではＯＲＢをリンクしてドアベルレジスタにライト要求を出す（１９０２）。１３９４インタフェースにより、ドアベルレジスタが書き込まれ（１９０３）、それがターゲットのＳＢＰ−２に通知される（１９０４）。
【０１０７】
通知を受けたＳＢＰ−２は、ＯＲＢリード要求を１３９４インタフェースに出して（１９０５）、システムメモリからＯＲＢが読み出される（１９０６）。ＳＨＰＴは、読み出されたＯＲＢの内容に応じて対応キューに格納する（１９０７）。
【０１０８】
リード実行エージェントは、ここでイニシエータに渡すデータが発生するまで待つ。データが発生すると、１３９４インタフェースに対してデータライト要求を出す（２００８）。これに応じて、指定されたアドレスに用意されたデータが書き込まれる（２００９）。
【０１０９】
処理が済むとリード実行エージェントからＳＢＰ−２に対してステータスブロック送信要求が出され（１９１０）、ステータスブロックがイニシエータに返される（１９１１）。イニシエータのＳＨＴＰは、これを受けると対応ＯＲＢをリンクから削除し、空きキューカウンタを１増やす（１９１２）。
【０１１０】
このシーケンスによりイニシエータからターゲットのデータが読み出される。
【０１１１】
以上のようにして、イニシエータとターゲットとの間で、簡素な制御手順によりデータの交換が双方向に行える。すなわち、イニシエータは所望のときに所望のデータをターゲットに渡すことができる。また、ターゲットは、イニシエータから渡されたデータをターゲット自身の都合に合わせて読み出すことができる。また、ターゲットはイニシエータが準備していさえすれば、自発的であろうと、あるいはイニシエータからの要求であろうと、何時でもイニシエータにデータを渡すことができる。また、バスリセットが発生しても、バスリセット直前の状態からの処理の続行を保証することができる。
【０１１２】
【他の実施形態】
さらに、図７に示したように、ＯＲＢにはＰＳＩＤ，ＳＳＩＤというチャネル識別子のフィールドを備えている。そのため、ＳＨＰＴ処理部及びＯＲＢディスパッチャがチャネル識別子を識別して、チャネルごとに独立したキュー及び実行エージェントを用いてＯＲＢの生成・処理を行えば、マルチチャネルを実現することができる。この場合、１つの機器であっても、そこに含まれる複数のクライアントそれぞれに１つのチャネルを割り当てることで、クライアントごとに非同期の通信を行わせることができる。このため、例えばデジタル複合機であれば、それが有するスキャナやプリンタそれぞれについてクライアントとなるアプリケーションを設けておけば、それと接続されたホストコンピュータからは、あたかもそれぞれの機能を独立した機器であるかのように使用することができる。フローチャートで示したように、各キューの管理や実行エージェントは独立したプロセスであるために、マルチチャネル化は容易に行うことができる。
【０１１３】
なお、本発明は、複数の機器（例えばホストコンピュータ，インタフェイス機器，リーダ，プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機，ファクシミリ装置など）に適用してもよい。
【０１１４】
また、本発明の目的は、イニシエータとして図１３〜図１８の手順のプログラムコードを記録した記憶媒体をコンピュータに供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても達成される。またターゲットも、図１９〜図２１の手順のプログラムコードを記録した記憶媒体をコンピュータに供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによって実現できる。
【０１１５】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１１６】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
【０１１７】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１１８】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１１９】
また、記憶媒体から読み出されたプログラムコードを実行してイニシエータとなる主体はコンピュータに限らず、データ転送機器であって、ＳＢＰ−２のログイン能力があれば、どのような機器であっても良い。
【０１２０】
以上説明したように、本発明によれば、イニシエータとターゲットとの間において、１回のログインで非同期な双方向通信を可能とし、また、データの交換に必要なプロセスやメモリといった資源を効率的に利用できる。
【０１２１】
また、ＩＥＥＥ１３９４インターフェースを利用しているために、ターゲット側へのデータ転送を、ターゲットがその都合に応じて読み出すことで行うことができ、イニシエータがターゲットの都合によってデータ転送に占有されることを防止できる。
【０１２２】
また、ＳＢＰ−２プロトコルを利用しているため、ターゲットでキューされるのはＯＲＢだけで、実際に転送されるデータそのものは処理待ちの間イニシエータに格納されている。このため、ターゲットのメモリ資源を小容量化できる。
【０１２３】
また、簡単にマルチチャネルを実現できる。
【０１２４】
【発明の効果】
バスリセットが発生しても、バスリセット後に、バスリセット直前の状態から処理を再開することができ、処理の正常な続行を保証することができる。
【０１２５】
【図面の簡単な説明】
【図１】ターゲット（プリンタ）のブロック図である。
【図２】イニシエータ（ホストコンピュータ）のブロック図である。
【図３】イニシエータとターゲットとの間におけるキューの状態の一例を示す図である。
【図４】イニシエータにおけるバスリセット後の復旧の様子の例を示す図である。
【図５】ターゲットにおけるバスリセット後の復旧の様子の例を示す図である。
【図６】イニシエータにおいてＯＲＢリストからＯＲＢを取り外す様子の例を示す図である。
【図７】ＯＲＢ一般のフォーマットを示す図である。
【図８】ライトコマンドＯＲＢのフォーマットを示す図である。
【図９】リードコマンドＯＲＢのフォーマットを示す図である。
【図１０】ステータスブロック一般のフォーマットを示す図である。
【図１１】ライトステータスブロックのフォーマットを示す図である。
【図１２】リードステータスブロックのフォーマットを示す図である。
【図１３】イニシエータのクライアントによる、データ転送要求の発生時の処理手順のフローチャートである。
【図１４】イニシエータのクライアントによる、ＳＨＴＰからの処理終了通知受信時の処理手順のフローチャートである。
【図１５】イニシエータのＳＨＴＰ処理部により実行される、クライアントからコールされるライト関数及びリード関数のフローチャートである。
【図１６】イニシエータのＳＨＴＰ処理部により実行される、ライトＩ／Ｏ要求キュー及びリードＩ／Ｏ要求キューの管理手順のフローチャートである。
【図１７】イニシエータのＳＨＴＰ処理部により実行される、ステータスブロック受信時の処理手順のフローチャートである。
【図１８】イニシエータのＳＨＴＰ処理部により実行される、バスリセット直後の復旧処理手順のフローチャートである。
【図１９】ドアベルレジスタあるいはＯＲＢポインタに書き込みが行われた際のターゲットのフェッチエージェントによる処理手順のフローチャートである。
【図２０】ライト実行エージェントによる処理手順のフローチャートである。
【図２１】リード実行エージェントによる処理手順のフローチャートである。
【図２２】イニシエータ（ホストコンピュータ）からターゲット（プリンタ）へのデータライト時のシーケンスの図である。
【図２３】イニシエータ（ホストコンピュータ）からターゲット（プリンタ）へのデータリード時のシーケンスの図である。
【図２４】ＩＥＥＥ１３９４インターフェースを用いたプリンタシステムのハードウエア構成図である。
【符号の説明】
１ ＣＰＵ
２ ＲＡＭ
３ ＲＯＭ
４ システムバス
１２ ＣＰＵ
１３ ＲＯＭ
１９ ＲＡＭ
１０１ フェッチエージェント
１０３，１０５ プリフェッチキュー
１０４ ライト実行エージェント
１０６ リード実行エージェント
１０８ ターゲット側クライアント
１０９ １３９４インターフェース
１１０ バスインターフェース
２０１ ＳＨＰＴ処理部
２０２ ライトＩ／Ｏ要求キュー
２０３ リードＩ／Ｏ要求キュー
２０４ ＯＲＢリスト
２０５ ステータスＦＩＦＯ
２０６ イニシエータ側クライアント
２０７ ライトバッファ
２０８ リードバッファ
Claims (7)
- イニシエータとターゲットとの間の通信制御方法であって、
前記イニシエータにおいて、前記イニシエータが有する記憶領域においてデータの書き込みあるいは読み出しが行われるべきアドレスを有する命令を前記ターゲットに発行するステップと、
前記ターゲットにおいて、発行された命令に従って、前記イニシエータが有する記憶領域における前記アドレスに対するデータの書き込みあるいは前記イニシエータが有する記憶領域における前記アドレスからのデータの読み出しを実行するステップと、
前記ターゲットにおいて、データの書き込みあるいは読み出しを実行中の命令の識別子と、当該命令に従ってデータの書き込みあるいは読み出しを行うべき記憶領域を示す、当該命令に対応する前記アドレスからのオフセットとを保持するステップとを有し、
前記イニシエータは、前記ターゲットに対して発行した命令を、当該命令に従ったデータの書き込みあるいは読み出しを完了した旨の完了通知を前記ターゲットから受けるまで、再発行可能な状態で保持し、
前記通信制御方法はさらに、
前記イニシエータと前記ターゲットとの間の接続が一旦切断されて再度確立された後、前記イニシエータにおいて、再発行可能な状態で保持している命令を前記ターゲットに再発行するステップと、
前記ターゲットにおいて、再発行された命令の識別子と保持していた識別子とを比較するステップと、
前記ターゲットにおいて、再発行された命令の識別子と保持していた識別子との一致を示す第１の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを保持していたオフセットに基づいて実行するステップと、
前記ターゲットにおいて、再発行された命令が有する識別子と保持していた識別子との不一致を示す第２の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを実行することなく、再発行された命令に対する前記完了通知を前記イニシエータに発行するステップとを有することを特徴とする通信制御方法。 - 前記イニシエータは、前記アドレスとデータサイズとを有する命令を発行し、前記ターゲットは、当該アドレスから当該データサイズ分のデータの書き込みあるいは当該アドレスから当該データサイズ分のデータの読み出しを実行することを特徴とする請求項１に記載の通信制御方法。
- イニシエータとターゲットの間でデータを交換する通信システムであって、
前記イニシエータは、
前記イニシエータが有する記憶領域においてデータの書き込みあるいは読み出しが行われるべきアドレスを有する命令を前記ターゲットに発行する第１の発行手段と、
前記ターゲットに対して発行した命令を、当該命令に従ったデータの書き込みあるいは読み出しを完了した旨の完了通知を前記ターゲットから受けるまで、再発行可能な状態で保持する第１の保持手段とを有し、
前記ターゲットは、
発行された命令に従って、前記イニシエータが有する記憶領域における前記アドレスに対するデータの書き込みあるいは前記イニシエータが有する記憶領域における前記アドレスからのデータの読み出しを実行する第１の実行手段と、
前記第１の実行手段によりデータの書き込みあるいは読み出しを実行中の命令の識別子と、当該命令に従ってデータの書き込みあるいは読み出しを行うべき記憶領域を示す、当該命令に対応する前記アドレスからのオフセットとを保持する第２の保持手段とを有し、
前記イニシエータはさらに、
前記イニシエータと前記ターゲットとの間の接続が一旦切断されて再度確立された後、再発行可能な状態で保持している命令を前記ターゲットに再発行する再発行手段を有し、
前記ターゲットはさらに、
再発行された命令の識別子と保持していた識別子とを比較する比較手段と、
再発行された命令の識別子と保持していた識別子との一致を示す第１の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを保持していたオフセットに基づいて実行する第２の実行手段と、
再発行された命令が有する識別子と保持していた識別子との不一致を示す第２の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを実行することなく、再発行された命令に対する前記完了通知を前記イニシエータに発行する第２の発行手段とを有することを特徴とする通信システム。 - 前記第１の発行手段は、前記アドレスとデータサイズとを有する命令を発行し、前記第１の実行手段は、当該アドレスから当該データサイズ分のデータの書き込みあるいは当該アドレスから当該データサイズ分のデータの読み出しを実行することを特徴とする請求項３に記載の通信システム。
- イニシエータとの間でデータを通信するターゲットとしての通信制御装置であって、
前記イニシエータによって発行された、前記イニシエータが有する記憶領域においてデータの書き込みあるいは読み出しが行われるべきアドレスを有する命令に従って、前記イニシエータが有する記憶領域における前記アドレスに対するデータの書き込みあるいは前記イニシエータが有する記憶領域における前記アドレスからのデータの読み出しを実行する第１の実行手段と、
前記イニシエータによって発行された命令に従ったデータの書き込みあるいは読み出しを完了した旨の完了通知を前記イニシエータに発行する第１の発行手段と、
前記第１の実行手段によりデータの書き込みあるいは読み出しを実行中の命令の識別子と、当該命令に従ってデータの書き込みあるいは読み出しを行うべき記憶領域を示す、当該命令に対応する前記アドレスからのオフセットとを保持する識別子保持手段と、
前記イニシエータと前記ターゲットとの間の接続が一旦切断されて再度確立された後、前記イニシエータによって再発行された命令の識別子と前記識別子保持手段によって保持されている識別子とを比較する比較手段と、
前記比較手段による一致を示す第１の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを前記識別子保持手段によって保持されているオフセットに基づいて実行する第２の実行手段と、
前記比較手段による不一致を示す第２の比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを実行することなく、再発行された命令に対する前記完了通知を前記イニシエータに発行する第２の発行手段とを有することを特徴とする通信制御装置。 - 前記イニシエータは、前記アドレスとデータサイズとを有する命令を発行し、前記第１の実行手段は、当該アドレスから当該データサイズ分のデータの書き込みあるいは当該アドレスから当該データサイズ分のデータの読み出しを実行することを特徴とする請求項５に記載の通信制御装置。
- イニシエータとの間でデータを交換するターゲットとしての通信制御装置であって、前記イニシエータによって発行された命令に従って、前記イニシエータが有する記憶領域に対するデータの書き込みあるいは前記イニシエータが有する記憶領域からのデータの読み出しを実行する第１の実行手段と、
前記イニシエータによって発行された命令に従ったデータの書き込みあるいは読み出しを完了した旨の完了通知を前記イニシエータに発行する第１の発行手段と、
前記第１の実行手段によりデータの書き込みあるいは読み出しを実行中の命令の識別子を保持する識別子保持手段と、
前記第１の実行手段によりデータの書き込みあるいは読み出しを実行中の命令に従ってデータの書き込みあるいは読み出しを行うべき記憶領域を示す、当該命令に対応して指定されたアドレスからのオフセットを保持するオフセット保持手段と、
前記イニシエータによって再発行された命令の識別子と前記識別子保持手段によって保持されている識別子とを比較する比較手段と、
前記比較手段による一致を示す比較結果に従って、前記オフセット保持手段によって保持されているオフセットに基づいてデータの書き込みあるいは読み出しを実行する第２の実行手段と、
前記比較手段による不一致を示す比較結果に従って、再発行された命令に従ったデータの書き込みあるいは読み出しを実行することなく、再発行された命令に対する前記完了通知を前記イニシエータに発行する第２の発行手段と、
を備えることを特徴とする通信制御装置。
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP13399498A JP4111472B2 (ja) | 1998-05-15 | 1998-05-15 | 通信制御方法及び装置及び通信システム |
| US09/310,952 US6477587B1 (en) | 1998-05-15 | 1999-05-13 | Command-based communications between an initiator and a target |
| DE69938988T DE69938988D1 (de) | 1998-05-15 | 1999-05-14 | Datenübertragungssteuerverfahren und Vorrichtung |
| EP19990303764 EP0957433B1 (en) | 1998-05-15 | 1999-05-14 | Communication control method and apparatus |
| US10/238,675 US6701386B2 (en) | 1998-05-15 | 2002-09-11 | Identifier based data communication |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP13399498A JP4111472B2 (ja) | 1998-05-15 | 1998-05-15 | 通信制御方法及び装置及び通信システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11327815A JPH11327815A (ja) | 1999-11-30 |
| JP4111472B2 true JP4111472B2 (ja) | 2008-07-02 |
Family
ID=15117914
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP13399498A Expired - Fee Related JP4111472B2 (ja) | 1998-05-15 | 1998-05-15 | 通信制御方法及び装置及び通信システム |
Country Status (4)
| Country | Link |
|---|---|
| US (2) | US6477587B1 (ja) |
| EP (1) | EP0957433B1 (ja) |
| JP (1) | JP4111472B2 (ja) |
| DE (1) | DE69938988D1 (ja) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4109770B2 (ja) * | 1998-12-02 | 2008-07-02 | キヤノン株式会社 | 通信制御方法及び機器 |
| JP3387466B2 (ja) | 1999-03-19 | 2003-03-17 | セイコーエプソン株式会社 | データ通信装置 |
| JP2001287414A (ja) * | 2000-04-05 | 2001-10-16 | Sony Corp | データ変換装置及び方法、印刷装置及び方法、印刷制御装置及び方法、印刷システム及び印刷方法、データ伝送方法 |
| JP2002318777A (ja) * | 2001-04-19 | 2002-10-31 | Matsushita Electric Ind Co Ltd | 高速シリアルインターフェース用のコマンド発行装置 |
| US6601119B1 (en) * | 2001-12-12 | 2003-07-29 | Lsi Logic Corporation | Method and apparatus for varying target behavior in a SCSI environment |
| JP4264924B2 (ja) * | 2002-06-07 | 2009-05-20 | ソニーマニュファクチュアリングシステムズ株式会社 | データ転送方法 |
| US6901463B2 (en) * | 2003-03-05 | 2005-05-31 | Sun Microsystems, Inc. | Method and device for linking work requests with completion queue entries |
| US7366957B2 (en) * | 2003-07-31 | 2008-04-29 | Lsi Corporation | Method and apparatus for controlling SAS/fibre target behavior from a host |
| JP2007030190A (ja) * | 2005-07-22 | 2007-02-08 | Ricoh Co Ltd | 画像形成装置、利用枚数制限サーバ、印刷枚数管理方法、印刷枚数管理プログラム、印刷枚数管理プログラムを記録した記録媒体 |
| US7669028B2 (en) * | 2006-02-07 | 2010-02-23 | International Business Machines Corporation | Optimizing data bandwidth across a variable asynchronous clock domain |
| US9258391B2 (en) * | 2009-05-29 | 2016-02-09 | Canon Kabushiki Kaisha | Processing method and apparatus |
| IN2014DE02931A (ja) | 2013-11-01 | 2015-06-26 | Seiko Epson Corp | |
| CN104615388B (zh) * | 2013-11-01 | 2017-12-22 | 精工爱普生株式会社 | 打印控制系统 |
| EP3220282B1 (en) * | 2015-12-14 | 2019-05-08 | Huawei Technologies Co., Ltd. | Method for managing lock in cluster, lock server and client |
| JP6464211B2 (ja) * | 2017-02-03 | 2019-02-06 | ファナック株式会社 | プログラマブルコントローラ |
| US11068214B2 (en) * | 2017-12-19 | 2021-07-20 | Kyocera Document Solutions, Inc. | Printing computing device for printing PPL jobs having video data and methods for use with a printing system for printing PPL jobs having video data |
| CN109712268B (zh) * | 2018-12-13 | 2022-01-04 | 北京遥测技术研究所 | 一种高速飞行器黑障区数据测量处理方法和处理器 |
Family Cites Families (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4868742A (en) | 1984-06-20 | 1989-09-19 | Convex Computer Corporation | Input/output bus for system which generates a new header parcel when an interrupted data block transfer between a computer and peripherals is resumed |
| US4644533A (en) | 1985-05-06 | 1987-02-17 | American Telephone & Telegraph Company | Packet switch trunk circuit queueing arrangement |
| US5050066A (en) * | 1988-10-14 | 1991-09-17 | Intel Corporation | Apparatus with a single memory and a plurality of queue counters for queuing requests and replies on a pipelined packet bus |
| DE69128615T2 (de) * | 1990-10-03 | 1998-04-23 | Fujitsu Ltd | Sendesteuerungssystem für eingangs/ausgangsbefehle in einem datenverarbeitungssystem |
| JPH04192030A (ja) * | 1990-11-27 | 1992-07-10 | Canon Inc | プリンタバッファ装置 |
| US5386524A (en) * | 1992-04-16 | 1995-01-31 | Digital Equipment Corporation | System for accessing information in a data processing system |
| JP3002056B2 (ja) | 1992-06-23 | 2000-01-24 | キヤノン株式会社 | プリンタ装置及び該装置における印刷制御方法 |
| AU5169093A (en) | 1992-10-02 | 1994-04-26 | Compaq Computer Corporation | Method for improving scsi operations by actively patching scsi processor instructions |
| FR2708763B1 (fr) * | 1993-06-30 | 2002-04-05 | Intel Corp | Dispositif de mémoire flash, procédé et circuit de traitement d'un ordre d'utilisateur dans un dispositif de mémoire flash et système d'ordinateur comprenant un dispositif de mémoire flash. |
| US5625800A (en) * | 1994-06-30 | 1997-04-29 | Adaptec, Inc. | SCB array external to a host adapter integrated circuit |
| US5548791A (en) | 1994-07-25 | 1996-08-20 | International Business Machines Corporation | Input/output control system with plural channel paths to I/O devices |
| JPH08195764A (ja) * | 1994-11-15 | 1996-07-30 | Ricoh Co Ltd | Ｌａｎインタフェイス装置 |
| JP3315291B2 (ja) | 1995-05-18 | 2002-08-19 | 株式会社リコー | 画像形成ネットワーク装置 |
| US5835721A (en) * | 1995-08-21 | 1998-11-10 | Apple Computer, Inc. | Method and system for data transmission over a network link between computers with the ability to withstand temporary interruptions |
| US6055598A (en) * | 1996-09-26 | 2000-04-25 | Vlsi Technology, Inc. | Arrangement and method for allowing sequence-independent command responses across a computer bus bridge |
| US6081849A (en) | 1996-10-01 | 2000-06-27 | Lsi Logic Corporation | Method and structure for switching multiple contexts in storage subsystem target device |
| TW355762B (en) * | 1996-12-26 | 1999-04-11 | Toshiba Co Ltd | Checkpoint rollback I/O control device and I/O control method |
| US5815677A (en) * | 1996-12-31 | 1998-09-29 | Compaq Computer Corporation | Buffer reservation method for a bus bridge system |
| JP4086345B2 (ja) | 1997-09-09 | 2008-05-14 | キヤノン株式会社 | 通信制御方法及び装置及び通信システム |
| US6240474B1 (en) * | 1997-09-16 | 2001-05-29 | International Business Machines Corporation | Pipelined read transfers |
| JPH11194963A (ja) * | 1997-12-26 | 1999-07-21 | Fujitsu Ltd | コマンド実行監視方法、及び、コマンド実行監視装置 |
| US6895003B1 (en) | 1998-02-24 | 2005-05-17 | Canon Kabushiki Kaisha | Communication system, apparatus, and method in which data transmission is interrupted for a bus reset |
| US6523058B1 (en) * | 1998-09-29 | 2003-02-18 | Stmicroelectronics Inc. | State machine driven transport protocol interface |
| US6243778B1 (en) * | 1998-10-13 | 2001-06-05 | Stmicroelectronics, Inc. | Transaction interface for a data communication system |
| US6185632B1 (en) * | 1998-10-19 | 2001-02-06 | Hewlett-Packard Company | High speed communication protocol for IEEE-1394 including transmission of request and reply writes to a datagram-FIFO-address to exchange commands to end a job |
| US6212611B1 (en) * | 1998-11-03 | 2001-04-03 | Intel Corporation | Method and apparatus for providing a pipelined memory controller |
| US6363438B1 (en) * | 1999-02-03 | 2002-03-26 | Sun Microsystems, Inc. | Method of controlling DMA command buffer for holding sequence of DMA commands with head and tail pointers |
| US6286074B1 (en) * | 1999-03-24 | 2001-09-04 | International Business Machines Corporation | Method and system for reading prefetched data across a bridge system |
| US6301639B1 (en) * | 1999-07-26 | 2001-10-09 | International Business Machines Corporation | Method and system for ordering priority commands on a commodity disk drive |
-
1998
- 1998-05-15 JP JP13399498A patent/JP4111472B2/ja not_active Expired - Fee Related
-
1999
- 1999-05-13 US US09/310,952 patent/US6477587B1/en not_active Expired - Fee Related
- 1999-05-14 DE DE69938988T patent/DE69938988D1/de not_active Expired - Lifetime
- 1999-05-14 EP EP19990303764 patent/EP0957433B1/en not_active Expired - Lifetime
-
2002
- 2002-09-11 US US10/238,675 patent/US6701386B2/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| EP0957433B1 (en) | 2008-07-02 |
| EP0957433A3 (en) | 2001-05-16 |
| US6477587B1 (en) | 2002-11-05 |
| US6701386B2 (en) | 2004-03-02 |
| US20030014564A1 (en) | 2003-01-16 |
| EP0957433A2 (en) | 1999-11-17 |
| DE69938988D1 (de) | 2008-08-14 |
| JPH11327815A (ja) | 1999-11-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4109770B2 (ja) | 通信制御方法及び機器 | |
| JP4111472B2 (ja) | 通信制御方法及び装置及び通信システム | |
| JP4086345B2 (ja) | 通信制御方法及び装置及び通信システム | |
| US6647016B1 (en) | Communication control method, communication control apparatus, and storage medium | |
| US20080133654A1 (en) | Network block device using network asynchronous i/o | |
| JPH07281848A (ja) | リモート印刷システムおよびそのコンピュータ | |
| EP1516261B1 (en) | Bus system, station for use in a bus system, and bus interface | |
| US8291089B2 (en) | Image processing device, control method therefor, and program | |
| US20060242258A1 (en) | File sharing system, file sharing program, management server and client terminal | |
| CN112380152A (zh) | 一种NVMe-oF异构存储访问控制器及访问方法 | |
| JP4307467B2 (ja) | 通信制御方法及び通信システム | |
| JP2008117289A (ja) | データ通信システム、ユニットおよびデータ通信方法 | |
| JP3440865B2 (ja) | ネットワークファイルシステム | |
| CN118093225A (zh) | 订阅消息的传输方法及装置、存储介质及电子设备 | |
| Burns | Implementation and comparison of iSCSI over RDMA | |
| JPH04318617A (ja) | オンラインプリンティングシステム | |
| JP2003186821A (ja) | データ処理システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050516 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7426 Effective date: 20050516 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20050516 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060615 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060707 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060905 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070413 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070612 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080404 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080407 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110418 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130418 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130418 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140418 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |