JPH09282116A - データ処理装置 - Google Patents

Abstract

(57)【要約】 【課題】 外部装置からのデータ受信待機中における処
理制御命令を、高速に検知して処理可能とする。 【解決手段】 ポート４０は外部装置からのデータを受
信し、ＵＩ制御部３５はデータに対する処理制御命令を
指示し、通知ドライバ３２はその処理制御命令をポート
４０に出力し、通信制御部３４は、データ解釈部３７に
対し、ポート４０に出力された処理制御命令に基づく処
理を受信データに対し実行するように制御する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、外部装置からのデ
ータを受信して処理を実行するデータ処理装置に関し、
特に、外部装置からのデータを所定のポートで受信し、
その待機中に、指示された処理制御命令を前記ポートか
ら検知して処理を実行するデータ処理装置に関する。

【０００２】

【従来の技術】従来より、イーサネットなどの通信イン
タフェースを備えたプリンタや、ワークステーション、
パーソナル・コンピュータ等のデータ処理装置が知られ
ている。これらのデータ処理装置は、例えば、図１１に
示すようなネットワークシステムを構成する。この図に
おいては、データ処理装置としてのプリンタ１１や、ワ
ークステーション１２、パーソナル・コンピュータ１３
などが、互いにイーサネット１４を介して接続され、相
互に通信を行なうことができる。

【０００３】この場合、例えば、プリンタ１１は、主に
次のような各部により構成される。すなわち、プリンタ
１１は、イーサネットのインタフェース部１５、通信ア
プリケーション１８、および各種アプリケーション１９
から構成され、このうち通信アプリケーション１８は、
各種通信プロトコルとの通信口（ポート）を介して通信
を行ない、また、各種アプリケーション１９は、受信し
たデータやジョブ処理、装置全体などの制御を行なう。
ここで、通信プロトコルには、イーサネットにおけるＡ
ｐｐｌｅＴａｌｋ−１６（米国アップル・コンピュータ
社商標）やＴＣＰ／ＩＰ１７等がある。通常、通信アプ
リケーション１８は、１以上のプロセス（タスクまたは
スレッドの場合もある）で構成され、各プロセスは１以
上のポートに対してデータの送受信処理を行なう。

【０００４】このように、異なるプロトコルのポートか
らの通信要求に対して、それぞれ対応するプロセスを起
動してデータ通信処理を行なう装置は、例えば特開平７
−６４８８５公報に記載されている。かかるデータ処理
装置（通信装置）は、外部装置からのデータの受信に対
しては効果的に処理を実行することができる。しかしな
がら、このデータ処理装置は、外部装置からのデータ受
信だけでなく、自身の操作パネルから指示されるよう
な、例えば、通信の中止や一時停止等のような、外部装
置から受信されるデータ以外の処理制御命令を、外部装
置からのデータ受信待機中にも検知し、これを処理しな
ければならない。

【０００５】そこで、従来、データ処理装置では、この
ような外部装置から受信されるデータ以外の処理制御命
令を通信アプリケーションに通知する場合、次に示す方
法が使用されていた。すなわち、通信アプリケーション
のプロセスは、データ受信待機中においては、外部装置
からデータが受信されるまでＣＰＵを放棄してブロック
しているため、（ａ）シグナルを用いてプロセスのデー
タ受信待機を終了させてからプロセスを起こし、処理制
御命令の通知の有無を検知させて処理するか、あるいは
（ｂ）データ受信待機にタイムアウト時間を設定し、一
定時間で受信待機からタイムアウトさせて、処理制御命
令の通知の有無を検知させて処理していた。

【０００６】

【発明が解決しようとする課題】しかしながら、（ａ）
シグナルを利用する場合、シグナルの用途が限定されて
いて使用できる通信の種類が限られているために、通知
する処理制御命令が多数ある場合には利用できない、と
いう問題があった。また、１つのプロセスが、複数のポ
ートの通信を処理しているときは、シグナルではポート
の指定ができないため、シグナルによりデータ受信待機
を終了しても、どの通信に対する処理制御命令か判断で
きないので、別の通知手段を用意してポートを指定する
必要があった。さらに、シグナルは、カーネルの機能で
あるため、オペレーティング・システムによっては、シ
グナルを利用できない、という問題もあった。

【０００７】また、（ｂ）受信待機のタイムアウトを利
用する場合には、通信アプリケーションが処理制御命令
を検知するタイミングが、設定したタイムアウト時間の
間隔（例えば１秒）であるため、処理制御命令が通知さ
れてからこれを検知するまでの検知時間が長くなり、処
理制御命令に対する応答速度が遅い、という問題があっ
た。もちろんタイムアウト設定時間を短くすれば、検知
時間は短縮されるが、通信アプリケーションのプロセス
がＣＰＵを占有する時間が増加していまうので、他のア
プリケーションのプロセスに影響がでない程度にしか、
タイムアウト時間（１〜２秒など）を短縮できない。ま
た、データ受信待機がタイムアウトする都度、処理制御
命令が通知されていないか、別の通知手段を検査しなけ
ればならないので、処理制御命令が通知されていない場
合は、無駄な処理が発生してしまう、という問題もあっ
た。

【０００８】本発明は、上記問題に鑑みてなされたも
の、その目的とするところは、外部装置からのデータ受
信待機中でも、処理制御命令を高速に検知して処理可能
なデータ処理装置を提供することにある。

【０００９】

【課題を解決するための手段】上記の目的を達成するた
め、請求項１に記載の発明にあっては、外部装置からの
データを受信するポートと、前記データに対する処理制
御命令を、前記ポートに出力する出力手段と、前記出力
手段によってポートに出力された処理制御命令に基づく
処理を、前記データに実行する処理実行手段とを具備す
ることを特徴としている。請求項２に記載の発明によれ
ば、請求項１に記載の発明において、前記ポートは複数
であり、これらポートの中からいずれか１つを選択する
選択手段を備え、前記出力手段は、選択手段により選択
されたポートに処理制御命令を出力することを特徴とし
ている。

【００１０】（作用）請求項１に記載の発明によれば、
外部装置からのデータをポートで受信待機中に、出力手
段が外部装置からのデータ以外の処理制御命令を前記ポ
ートに出力し、処理実行手段が当該処理制御命令に対応
する処理を実行する。したがって、通信にかかるデータ
以外の多数の処理制御命令を高速に検知して処理するこ
とが可能となる。請求項２に記載の発明によれば、選択
手段が、処理制御命令を出力する複数ポートを選択し、
選択されたポートに対して処理制御命令が出力されるの
で、選択したポート以外のポートで実行されている通信
に影響を与えることなく、選択したポートの通信に対し
てのみ処理制御命令を通知し、これを処理することがで
きる。このため、データ処理装置全体のパフォーマンス
を向上することも可能となる。

【００１１】

【発明の実施の形態】以下、本発明によるデータ処理装
置をプリンタサーバに適用した実施形態について、図面
を参照して説明する。図１は、本実施形態のプリンタサ
ーバの構成を示すブロック図である。この図に示すよう
に、プリンタサーバ２１は、イーサネット・インタフェ
ース２４を介してイーサネット２３と接続され、イーサ
ネット２３に接続されたワークステーション２２と通信
を行なう。また、プリンタサーバ２１は、プリンタ２５
とはＳＣＳＩインタフェース２６を介して接続され、ワ
ークステーション２２から受信したプリント・データを
解釈して画像を生成し、プリンタ２５に出力する。これ
により、プリンタ２５が、ワークステーション２２によ
るプリント・データに基づく画像を、実際に印刷するよ
うになっている。

【００１２】プリンタサーバ２１における、ソフトウエ
アプログラムは、カーネル３９上で動作している。かか
るカーネルは通信機構としてＵＮＩＸ ＳｙｔｅｍＶに
おいて採用されている標準的なストリーム（ＳＴＲＥＡ
ＭＳ）機構をもっている。イーサネット・ドライバ２７
およびＳＣＳＩドライバ３２の各々は、それぞれ、デバ
イス・ドライバであり、デバイスであるイーサネット・
インタフェース２４やＳＣＳＩインタフェース２６から
の割込処理や動作制御処理を行なう。ＥＬＡＰ（Ｅｔｈ
ｅｒＴａｌｋ・リンク・アクセス・プロトコル）ドライ
バ２７、ＤＤＰ（データグラム・デリバリー・プロトコ
ル）ドライバ２９、ＡＴＰ（ＡｐｐｌｅＴａｌｋ・トラ
ンザクション・プロトコル）ドライバ３０、ＰＡＰ（プ
リンタ・アクセス・プロトコル）ドライバ３１の各々
は、それぞれＡｐｐｌｅＴａｌｋの各レイヤにおけるプ
ロトコルを処理するストリーム機構ドライバであり、ス
トリーム機構によって動作する。

【００１３】通知ドライバ３２は、本発明で新たに追加
されるストリーム機構のドライバであり、通信制御部３
４がＡｐｐｌｅＴａｌｋプロトコルでワークステーショ
ン２２と通信を行なっているポート４０に対し、ＵＩ制
御部３５が指示する通信データ以外の処理制御命令を通
知する。かかる通知ドライバ３２は、通信制御部３４と
ＰＡＰドライバ３１との通信についてはバイパスするだ
けであり、従来、ＰＡＰドライバ３１に対して通信アク
セスしていた通信制御部３４の通信処理について、変更
を加えなくてもよいようになっている。

【００１４】通信ＡＰＩ（アプリケーション・プログラ
ム・インターフェース）３３は、プロトコル・スタック
を形成するストリーム機構ドライバに対して、アプリケ
ーションである通信制御部３４や、ＵＩ制御部３５がア
クセスを取るためのインタフェースである。各種アプリ
ケーションと、ストリーム機構ドライバとのアクセス
は、すべて通信ＡＰＩ３３を介して実行される。通信制
御部３４は、プロトコル・スタック上位のアプリケーシ
ョンであり、プロトコルからのデータ受信やプロトコル
に対するデータ送信等の通信に関する処理を実行する一
方、ポート４０から受信されるデータや、ＵＩ制御部３
５から通知される処理制御命令等に応じた処理も実行す
る。通信制御部３４は、また、ワークステーション２２
から印刷要求を受信した場合、ジョブ制御部３６に対し
プリント・ジョブをジョブ要求する。

【００１５】ＵＩ制御部３５は、図示しないＵＩ（ユー
ザー・インターフェース）部から入力される通信やジョ
ブ等に関する各種の操作指示命令を処理するとともに、
通信制御部３４が通信中において当該通信に対する中止
やジョブ受信の一時停止等の命令を入力した場合には、
通信ＡＰＩ３３の関数を呼出し、選択したポート４０を
介し通信制御部３４に処理制御命令を通知する。

【００１６】ジョブ制御部３６は、ジョブ要求されたジ
ョブのスケジュールおよびジョブの制御を行なう。デー
タ解釈部３７は、ジョブがスケジュールされた場合に、
通信制御部３４が受信したジョブデータを読み出し、解
釈処理を実行して、出力すべき画像の生成を行なう。プ
リンタ制御部３８は、データ解釈部３７が解釈処理を実
行して生成された画像を、ＳＣＳＩドライバ３２を介し
て、プリンタ２５に出力する。

【００１７】次に、通信制御部３４の動作について説明
する。はじめに、通信制御部３４の親プロセスの動作に
ついて説明する。図２は、通信制御部３４における親プ
ロセスの動作を示すフローチャートである。この図に示
すように、まず、通信制御部３４の親プロセスは、ステ
ップＳ１０１において、ストリーム機構ドライバのＥＬ
ＡＰドライバ２８、ＤＤＰドライバ２９、ＡＴＰドライ
バ３０、ＰＡＰドライバ３１、および通知ドライバ３２
をオープンするとともに、各ドライバをリンクして、Ａ
ｐｐｌｅＴａｌｋプロトコルの組立てを行ない、Ａｐｐ
ｌｅＴａｌｋプロトコルを始動する。次に、通信制御部
３４の親プロセスは、ステップＳ１０２において、ワー
クステーションからの印刷要求であるコネクション開設
要求を受信するため、ＳＬＳ（セッション・リスニング
・ソケット）を開設し、さらに、ＳＬＳにサーバ名を登
録するため、ＳＬＳＩｎｉｔ通信ＡＰＩをコールする。
すると、ＳＬＳＩｎｉｔ通信ＡＰＩは、通知ドライバ３
２をオープンし、コマンドＰＡＰ＿ＣＲＥＡＴＥ＿ＳＬ
Ｓをｐｕｔｍｓｇシステム・コールによって通知ドライ
バ３２に通知し、通知ドライバ３２からの応答をｇｅｔ
ｍｓｇシステム・コールによって受信する。通知ドライ
バ３２は、該コマンドを書込キューに受信すると、それ
を下位のＰＡＰドライバ３１にそのまま通知する。コマ
ンドＰＡＰ＿ＣＲＥＡＴＥ＿ＳＬＳを受信したＰＡＰド
ライバ３１は、ＳＬＳを開設して、サーバ名をこれに登
録し、コマンドに対する応答値を、上位の通知ドライバ
３２に通知する。通知ドライバ３２は、コマンド応答値
をそのまま、ストリーム・ヘッドに送信するため、ＳＬ
ＳＩｎｉｔ通信ＡＰＩ内のコマンド応答待ちにあるｇｅ
ｔｍｓｇシステム・コールに通知する。

【００１８】通知ドライバ３２は、図４に示すようなポ
ート番号管理テーブル２０１を有している。このポート
番号管理テーブル２０１は、通知ドライバ３２における
ストリームのキュー（ポインタ）とポート番号とを対応
づけて管理するテーブルである。通知ドライバ３２が通
信ＡＰＩ３３からオープンされると、ポート番号が割当
てられるとともに、該当する書込キューのポインタと一
緒にポート番号管理テーブル２０１に登録される一方、
通知ドライバ３２が通信ＡＰＩからクローズされると、
そのキューに該当するエントリがポート番号管理テーブ
ル２０１から削除される。

【００１９】通信制御部３４は、図５に示すような通信
管理テーブル２０２を有している。通信管理テーブル２
０２は、現時点においてアクティブなポートのポート番
号、そのポートタイプ、および通信プロトコルを登録す
るものであり、後述するように、ＵＩ制御部３５が特定
の通信ポートに対する処理制御命令の通知を行なう場
合、この通信管理テーブル２０２からその通信ポートの
ポート番号等を取得できるようになっている。

【００２０】さて、通信制御部３４の親プロセスは、ス
テップＳ１０３において、ＧｅｔＰｏｒｔＮｕｍ通信Ａ
ＰＩをコールして、ＳＬＳポートのポート番号を獲得
し、ポート番号を通信管理テーブル２０２に登録する。
ＧｅｔＰｏｒｔＮｕｍ通信ＡＰＩは、コマンドＧＥＴ＿
ＰＯＲＴ＿ＮＵＭをｐｕｔｍｓｇシステム・コールによ
って通知ドライバ３２に通知する。かかるコマンドを通
知ドライバ３２が受信すると、当該コマンド受信した書
込キューに対応するポート番号をポート番号管理テーブ
ル２０１から見つけ、そのポート番号をストリーム・ヘ
ッドに送信するため、ｇｅｔｍｓｇシステム・コールで
応答待ちしているＧｅｔＰｏｒｔＮｕｍ通信ＡＰＩに通
知する。

【００２１】次に、通信制御部３４の親プロセスは、ス
テップＳ１０４において、ｐｏｌｌシステム・コールに
よってデータ受信待ちを行なう。データが受信される
と、通信制御部３４の親プロセスは、ステップＳ１０５
において、当該受信データが、ｉｏｃｔｌ（Ｉ＿ＰＥＥ
Ｋ）システム・コールによって、ワークステーション２
２からのコネクション開設要求か否かを判定し、判定結
果が「Ｙｅｓ」であれば、ステップＳ１０６において、
ジョブ処理用の子プロセスを生成する。一方、ステップ
Ｓ１０５の判定結果が「Ｎｏ」であれば、通信制御部３
４の親プロセスは、ステップＳ１０７において、当該受
信データが処理制御命令であるか否かをさらに判定し、
判定結果が「Ｙｅｓ」であれば、ステップＳ１０８にお
いて、当該処理制御命令の処理を実行する。例えば、処
理制御命令が一時停止命令の場合は、親プロセスは、再
開命令を検知するまでジョブ受信一時停止状態とし、コ
ネクション開設要求に対しては拒絶応答するような処理
を実行する。なお、ステップＳ１０５、Ｓ１０７の判定
結果がいずれも「Ｎｏ」であれば、処理手順はステップ
Ｓ１０４に戻り、再びデータ受信待ちが行なわれる。

【００２２】このように、通信制御部３４の親プロセス
は、ワークステーションからの印刷要求を示すコネクシ
ョン開設要求を受信するため、ＳＬＳポートを開設して
データ受信し、さらに、当該データがコネクション開設
要求であれば、ジョブ処理用の子プロセスを生成する一
方、当該データが処理制御命令であれば、その命令の処
理を実行する。

【００２３】次に、上述したステップＳ１０６において
生成された子プロセスの動作について説明する。図３
は、通信制御部３４における子プロセスの動作を示すフ
ローチャートである。この図に示すように、通信制御部
３４の子プロセスは、まず、ステップＳ１１１におい
て、ワークステーション２２とのコネクションを開設し
てジョブを受信するために、ＧｅｔＮｅｘｔＪｏｂ通信
ＡＰＩをコールする。すると、ＧｅｔＮｅｘｔＪｏｂ通
信ＡＰＩは、通知ドライバ３２をオープンし、ＰＡＰ＿
ＧＥＴ＿ＮＥＸＴ＿ＪＯＢコマンドを、ｐｕｔｍｓｇシ
ステム・コールを使って通知ドライバ３２に通知する。
通知ドライバ３２は、当該コマンドをそのまま下位のＰ
ＡＰドライバ３１に送信し、当該コマンドを受信したＰ
ＡＰドライバ３１は、コネクション開設の処理を実行し
て、このコマンドに対する応答値を上位の通知ドライバ
３２に送信する。通知ドライバ３２は、この応答値をそ
のままストリーム・ヘッドに送信するので、ｇｅｔｍｓ
ｇシステム・コールで応答待ちになっているＧｅｔＮｅ
ｘｔＪｏｂ通信ＡＰＩに通知される。

【００２４】次に、通信制御部３４の子プロセスは、ス
テップＳ１１２において、ＧｅｔＰｏｒｔＮｕｍ通信Ａ
ＰＩをコールして、通信するＪＯＢポートのポート番号
を獲得し、ポート番号を通信管理テーブル２０２に登録
する。

【００２５】そして、通信制御部３４の子プロセスは、
ステップＳ１１３において、ｐｏｌｌシステム・コール
によってデータ受信待ちを行なう。データが受信される
と、通信制御部３４の子プロセスは、ステップＳ１１４
において、当該受信データが、ｉｏｃｔｌ（Ｉ＿ＰＥＥ
Ｋ）システム・コールによって、ジョブデータであるか
否かを判定する。判定結果が「Ｙｅｓ」であれば、ステ
ップＳ１１５において、ＰＡＰＲｅａｄ通信ＡＰＩをコ
ールして、受信したジョブデータをハードディスク等の
蓄積装置にスプールする。一方、ステップＳ１１４の判
定結果が「Ｎｏ」であれば、通信制御部３４の子プロセ
スは、ステップＳ１１６において、当該受信データがク
ライアント２２からのコネクション解放要求か否かをさ
らに判定する。この判定結果が「Ｙｅｓ」ならば、通信
制御部３４の子プロセスは、ステップＳ１１７におい
て、スプールしたジョブデータに対するジョブ要求をジ
ョブ管理部に対して行ない、次のステップＳ１１８にお
いて、ＰＡＰＣｌｏｓｅ通信ＡＰＩをコールして、コネ
クションの解放とＪＯＢポートの解放とを行なう。この
際、子プロセスは、通信管理テーブル２０２から、本通
信に関するエントリも削除する。さらに、ステップＳ１
１６の判定結果が「Ｎｏ」であれば、通信制御部３４の
子プロセスは、ステップＳ１１９において、当該受信デ
ータが処理制御命令か否かを判定する。この判定結果が
「Ｙｅｓ」ならば、通信制御部３４の子プロセスは、ス
テップＳ１２０において、その処理制御命令に対応する
処理を実行する。例えば、処理制御命令が中断命令の場
合に、通信制御部３４の子プロセスは、ジョブデータ受
信の途中でコネクション解放を行なうとともに、スプー
ルファイルを削除して、当該ジョブをアボートする。

【００２６】このように、通信制御部３４の子プロセス
は、ＪＯＢポートを開設してデータ受信し、さらに、当
該データがジョブデータであればそれをスプールし、コ
ネクション解放要求であれば、コネクションの解放とＪ
ＯＢポートの解放とを行ない、処理制御命令であれば、
当該処理制御命令に対応する処理を実行する。

【００２７】次に、ＵＩ制御部３５の動作について説明
する。図６は、ＵＩ制御部３５の動作を示すフローチャ
ートである。この図に示すように、まず、ＵＩ制御部３
５は、ステップＳ２１１において、図示しない操作パネ
ルや表示パネル等から構成されるＵＩ部への操作入力待
ちを行なう。ここで、操作入力がユーザにより行なわれ
ると、ＵＩ制御部３５は、ステップＳ２１２において、
操作入力が一時停止指示であるか否かを判定する。この
判定結果が「Ｙｅｓ」ならば、ＵＩ制御部３５は、ステ
ップＳ２１３において、第１に、通信管理テーブル２０
２を参照して、ＳＬＳポートのポート番号を獲得し、第
２に、ＮｏｔｉｆｙＣｏｎｔｒｏｌ通信ＡＰＩを使っ
て、獲得したＳＬＳのポート番号を指定し、そこに一時
停止命令ＰＡＵＳＥを通知する。ここで、Ｎｏｔｉｆｙ
Ｃｏｎｔｒｏｌ通信ＡＰＩは、ｐｕｔｍｓｇシステム・
コールを用いて、図７に示すような、メッセージ・ブロ
ックがリンクしたメッセージを、通知ドライバ３２に通
知する。

【００２８】一方、ステップＳ２１２の判定結果が「Ｎ
ｏ」ならば、ＵＩ制御部３５は、ステップＳ２１４にお
いて、操作入力が再開指示であるか否かを判別する。こ
の判定結果が「Ｙｅｓ」ならば、ＵＩ制御部３５は、ス
テップＳ２１５において、第１に、通信管理テーブル２
０２を参照して、ＳＬＳポートのポート番号を獲得し、
第２に、ＮｏｔｉｆｙＣｏｎｔｒｏｌ通信ＡＰＩを使っ
て、獲得したＳＬＳのポート番号を指定し、そこに再開
命令ＲＥＳＵＭＥを通知する。ここで、ＮｏｔｉｆｙＣ
ｏｎｔｒｏｌ通信ＡＰＩは、ｐｕｔｍｓｇシステム・コ
ールを用いて、図８に示すような、メッセージ・ブロッ
クがリンクしたメッセージを、通知ドライバ３２に通知
する。

【００２９】また、ステップＳ２１４の判定結果が「Ｎ
ｏ」でならば、ＵＩ制御部３５は、ステップＳ２１６に
おいて、操作入力が中止指示であるか否かを判別する。
この判定結果が「Ｙｅｓ」ならば、ＵＩ制御部３５は、
ステップＳ２１７において、第１に、通信管理テーブル
２０２を参照して、ＪＯＢポートのポート番号を獲得
し、第２に、ＮｏｔｉｆｙＣｏｎｔｒｏｌ通信ＡＰＩを
使い、獲得したＪＯＢのポート番号を指定して、そこに
中止命令ＡＢＯＲＴを通知する。ここで、Ｎｏｔｉｆｙ
Ｃｏｎｔｒｏｌ通信ＡＰＩは、ｐｕｔｍｓｇシステム・
コールを用いて、図９に示すような、メッセージ・ブロ
ックがリンクしたメッセージを通知ドライバ３２に通知
する。さらに、中止指示の場合、ＵＩ制御部３５は、通
信管理テーブル２０２のＪＯＢポートの通信情報をＵＩ
部に表示し、その中からユーザーが選択した特定の通信
に対してのみ中止操作を行なったり、または、現在アク
テイブなＪＯＢポートの通信全てに対して中止操作を行
なったりすることができる。

【００３０】このように、ＵＩ制御部３５は、特定の通
信ポートに対する処理制御命令が指示された場合、通信
管理テーブル２０２（図５参照）からその通信ポートの
ポート番号を取得するとともに、取得したポート番号に
当該処理制御命令の通知を行なう。すなわち、処理制御
命令は、データが受信されるＳＬＳあるいはＪＯＢポー
トに出力されるので、通信管理部３４にとってみれば、
データと処理制御命令とを同レベルで扱うことができ、
その結果、一定時間間隔で処理制御命令の有無を確認す
る必要がなくなる。このため本実施形態のデータ処理装
置によれば、処理制御命令を高速に検知し、当該処理制
御命令の処理を迅速に実行することができるのである。
さらに、特定の処理制御命令の場合（本実施形態では中
止指示の場合）、ＵＩ制御部３５は、ユーザが選択した
ＪＯＢポートに当該処理制御命令を通知する。このた
め、それ以外のポートで実行されている通信に影響を与
えることなく、選択した特定のポートでの通信に対して
のみ、当該処理制御命令にかかる処理を実行することも
できる。

【００３１】次に、通知ドライバ３２の動作について説
明する。図１０は、通知ドライバ３２の書込キューのメ
ッセージ処理の動作を示すフローチャートである。この
図に示すように、まず、通知ドライバ３２は、ステップ
Ｓ３０１において、メッセージの受信待機を書込キュー
にて行なう。ここで、メッセージが受信されると、通知
ドライバ３２は、ステップＳ３０２において、受信した
メッセージのメッセージタイプがＭ＿ＰＲＯＴＯである
か否かを判定する。この判定結果が「Ｙｅｓ」ならば、
通知ドライバ３２は、ステップＳ３０３において、メッ
セージ内のデータに設定されているコマンドを参照す
る。

【００３２】そして、通知ドライバ３２は、ステップＳ
３０４において、参照したコマンドが、ＧＥＴ＿ＰＯＲ
Ｔ＿ＮＵＭコマンドであるか否かを判定する。この判定
結果が「Ｙｅｓ」ならば、通知ドライバ３２は、ステッ
プＳ３０５において、当該メッセージを受信した書込キ
ューのキューポインタを持つストリームのポート番号
を、ポート番号管理テーブル２０１から獲得し、次のス
テップＳ３０６において、そのキューの読出キューに対
して、獲得したポート番号を通知する。

【００３３】一方、ステップＳ３０４の判定結果が「Ｎ
ｏ」ならば、通知ドライバ３２は、ステップＳ３０７に
おいて、当該コマンドがＮＯＴＩＦＹ＿ＣＯＮＴＲＯＬ
であるか否かを判定する。この判定結果が「Ｙｅｓ」な
らば、通知ドライバ３２は、ステップＳ３０８におい
て、当該メッセージ内のデータ内に設定されいる指定ポ
ート番号に対応する書込キューのポインタを、ポート番
号管理テーブル２０１から獲得し、次のステップＳ３０
９において、獲得した書込キューに対応する読出キュー
に、メッセージ内のコマンド・データを送信する。

【００３４】なお、ステップＳ３０２の判定結果が「Ｎ
ｏ」の場合（すなわち、受信したメッセージのメッセー
ジタイプがＭ＿ＰＲＯＴＯでない場合）、あるいはステ
ップＳ３０４、Ｓ３０７の判定結果がいずれも「Ｎｏ」
の場合（すなわち、コマンドがＧＥＴ＿ＰＯＲＴ＿ＮＵ
Ｍコマンドでも、ＮＯＴＩＦＹ＿ＣＯＮＴＲＯＬでもな
い場合）、通知ドライバ３２は、ステップＳ３１０にお
いて、受信したメッセージあるいコマンドを、そのま
ま、下位のストリーム機構ドライバであるＰＡＰドライ
バ３１の書込キューに送信する。通知ドライバ３２の読
出キューのメッセージ処理は、読出キューにて受信され
たメッセージを、そのまま、上位のストリーム・ヘッド
に送信して実行される。

【００３５】このように、通知ドライバ３２は、受信し
たメッセージのコマンドを参照し、それがＧＥＴ＿ＰＯ
ＲＴ＿ＮＵＭコマンドであれば、当該メッセージを受信
した書込キューのキューポインタを有するストリームの
ポート番号を、そのキューの読出キューに対して通知す
る一方、コマンドがＮＯＴＩＦＹ＿ＣＯＮＴＲＯＬコマ
ンドであれば、当該メッセージ内のデータ内に設定され
いる指定ポート番号に対応する書込キューのポインタを
獲得し、それに対応する読出キューに、メッセージ内の
コマンド・データを送信する。それ以外では、通知ドラ
イバ３２は、受信したメッセージをそのまま下位のドラ
イバに送信する。

【００３６】以上によって、通信制御以外のアプリケー
ションが選択したポートの通信に対して、任意の処理制
御命令を通信制御アプリケーションに通知することが可
能となる。

【００３７】なお、上述の実施形態では、通信インタフ
ェースをイーサネットとし、プロトコルをＡｐｐｌｅＴ
ａｌｋとしたが、本発明は、これらに限定されるわけで
なく、他の通信インタフェース（赤外線インタフェース
や、セントロニクス等）や、他のプロトコル（ＮｅｔＷ
ａｒｅやＴＣＰ／ＩＰなど）に対しても適用できるのは
いうまでもない。

【００３８】また、本実施形態では、処理制御命令を通
知するための通知ドライバをストリーム機構ドライバと
したが、本発明は、これに限定されるわけでなく、スト
リーム機構モジュールや、他の通信機構であるソケット
等を使って実現する場合にも本発明を適用できるのは明
らかである。さらに、本実施形態では、処理制御命令の
選択ポートへの通知処理を通知ドライバによって行なっ
たが、通知ドライバを設けずに、処理制御命令の選択ポ
ートへの通知処理を直接プロトコル・ドライバ（例え
ば、ＰＡＰドライバ）で実行する場合にも、適用できる
のは明らかである。。

【００３９】

【発明の効果】以上説明したように、本発明によれば、
多種類の処理制御命令を、通信を行なっているポートに
対して通知することができるので、他の処理に影響を及
ぼすことなく、多種類の処理制御命令を高速に検知して
処理することが可能となる（請求項１）。また、通信を
行なっているポートを選択して、処理制御命令を通知す
ることができるので、無関係な通信のポートに対する処
理を実行している通信制御部のプロセスに影響を及ぼす
ことなく、処理制御命令を処理することが可能となる
（請求項２）。

【図面の簡単な説明】

【図１】 本発明による実施形態の構成を示すブロック
図である。

【図２】 同実施形態における通信制御部の親プロセス
の動作を示すフローチャートである。

【図３】 同実施形態における通信制御部の子プロセス
の動作を示すフローチャートである。

【図４】 同実施形態におけるポート管理テーブルの説
明図である。

【図５】 同実施形態における通信管理テーブルの説明
図である。

【図６】 同実施形態におけるＵＩ制御部の動作を示す
フローチャートである。

【図７】 同実施形態における一時停止命令通知用のメ
ッセージを説明する図である。

【図８】 同実施形態における再開命令通知用のメッセ
ージを説明する図である。

【図９】 同実施形態における中止命令通知用のメッセ
ージを説明する図である。

【図１０】 同実施形態における通知ドライバの動作を
示すフローチャートである。

【図１１】 従来のデータ処理装置の構成を示すブロッ
ク図である。

【符号の説明】

２１……プリンタサーバ、２２……ワークステーショ
ン、２３……イーサネット、２４……イーサネット・イ
ンタフェース、２５……プリンタ、２６……ＳＣＳＩイ
ンタフェース、２７……イーサネット・ドライバ、２８
……ＥＬＡＰドライバ、２９……ＤＤＰドライバ、３０
……ＡＴＰドライバ、３１……ＰＡＰドライバ、３２…
…通知ドライバ、３３……通信ＡＰＩ、３４……通信制
御部、３５……ＵＩ制御部、３６……ジョブ制御部、３
７……データ解釈部、３８……プリンタ制御部、３９…
…カーネル、４０……ポート

Claims (2)

【特許請求の範囲】
1. 【請求項１】 外部装置からのデータを受信するポート
   と、 前記データに対する処理制御命令を、前記ポートに出力
   する出力手段と、 前記出力手段によってポートに出力された処理制御命令
   に基づく処理を、前記データに実行する処理実行手段と
   を具備することを特徴とするデータ処理装置。
2. 【請求項２】 前記ポートは複数であり、これらポート
   の中からいずれか１つを選択する選択手段を備え、 前記出力手段は、選択手段により選択されたポートに処
   理制御命令を出力することを特徴とする請求項１記載の
   データ処理装置。