JP2005276175A - 拡張性のあるプリントスプーラ - Google Patents

Abstract

【課題】専用のプリントサーバとともに最も有効に使用される拡張可能なプリントスプーラを提供すること。
【解決手段】多数のクライアントコンピュータにサービスを提供するプリントサーバは、クライアントコンピュータによってプリントサーバに送信されたデータの印刷を調整するサーバプリントスプーラを実施するソフトウェアを有する。いくつかのプリンタは、サーバコンピュータに結合されて、サーバプリンタスプーラの指示の元に印刷を行う。プリントスプーラへのクライアント呼び出しは、リモートプロシージャ呼び出しチャネルによって通信する非同期プロシージャによって達成される。プリントサーバのスレッドプールは、クライアント要求間での不合理なコンテキストスイッチ無しにこれらの呼び出しを処理する。
【選択図】 図１

Description

ここに開示したシステムは、クライアント／サーバコンピューティングアプリケーションで使用される改良されたプリントスプーラに関する。

大規模な企業では、複数のプリントサーバは単一のサーバにまとめられることが多い。この傾向は次第に高まっており、単一のプリントサーバによって益々多くのユーザにサービスが提供され、また益々多くのプリンタが接続されるようになってきている。Ｗｉｎｄｏｗｓ（登録商標）２００３ Ｓｅｒｖｅｒは、例えばＷｉｎｄｏｗｓ（登録商標）２０００ Ｓｅｒｖｅｒなどの拡張性に関し改良が施されている。本発明は、Ｗｉｎｄｏｗｓ（登録商標）２００３ Ｓｅｒｖｅｒアーキテクチャがプリントサーバとして機能する際に使用する技術を改良することに関する。

拡張性における問題に共通する原因は、そのサーバにおいてあまりに多くのスレッド（またはプロセス）がプロセッサ時間を獲得するため競合することにある。単一の中央処理ユニットでは、一度に１つの命令しか実行できない。作業がバックグラウンドスレッドに渡されても、メインスレッドまたは他のスレッドが実行し続けている間はその作業は実行されない。ロック時またはタイムスライスの割当時にスレッドがブロックされた場合、スレッドが起動する際にコンテキストスイッチによりＣＰＵリソースが消費される。スレッドにタイムスライスが割当られても結局ブロックされていることがわかるだけで、スレッドはすぐに休止することがしばしばある。この現象によって、キャッシュスラッシングが生じ、およびコンテキストスイッチを行なう際のサイクルの効率が悪化する。

例証のために、８００台のプリンタおよび５０００台のクライアントにサービスを提供する１つのサーバ（または複数のサーバ）のテストが行われた。このとき約５０００の並行スレッドが生じた。あるプロセスでスレッドが作成されるときはいつでも、サーバのオペレーティングシステムは、スレッドをスタックするためにアドレス空間の所定の領域を確保しておくとともに、この確保された領域のためにいずれかの物理的な格納領域をあてがう。Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｒｖｅｒ ２００３下で実行するプリントスプーラの場合、これらのパラメータは、スタックには２６２，１４４バイト、メモリにはＸ８６プロセッサのスレッド当たり３２，７６８バイトまで可能である。よって５０００のスレッドの場合、５０００×３２７６８＝１６４Ｍのメモリをあてがわれたことになる。５０００の同時に発生するスレッドは、主に２つの箇所、つまりクライアントおよびポートスレッドの関数から受信するＲＰＣの呼び出しに集中する。本発明は、これらの原因によるサーバリソースの消費を低減する取り組みに関する。このリソースの割当の問題は、（非特許文献１）にも記載されている。

chapter 14 (Asynchronous Input/Output and Completion ports) of a text entitled "Win32 Systems Programming" Copyright 2001, Addison Wesley Inside Microsoft Windows（登録商標） 2000 (Solomon et al Microsoft Press, copyright 2000)

Ｗｉｎｄｏｗｓ（登録商標） ２０００およびＷｉｎｄｏｗｓ（登録商標） ＸＰの現在のクライアントプリントスプーラは、名前付きパイプエンドポイントを使用してサーバと通信するリモートプロシージャ呼び出しを使用する。ここで、名前付きパイプを使用する際には、拡張性およびセキュリティに関連する問題が生じる。

クライアントへの印刷通知をサポートするためには、クライアントへ匿名の接続を可能とすることによって通知用の逆方向チャネル（サーバからクライアントへの通信）を使用することができるようにするしかない。登録されているすべてのクライアントへのこうした同時接続を維持することもサーバにとっては必要なものであり、このためサーバの拡張性の点で悪影響が生じる。
サーバが多数の無駄な未処理の呼び出しを抱えることは望ましくない。名前付きパイプにおいて、応答を待っている各クライアントは、サーバ上で実行される未処理の名前付きパイプを有しており、その各々について一定の量のカーネルメモリが必要となる。

スプーラインターフェイスには次の問題がある。
これらのインターフェイスは主に同期式インターフェイスであり、サーバ側で任意のスレッドをプールするのを妨げられる。また、クライアント側での任意の非同期操作にも悪影響を与え、アプリケーション応答時間に悪影響を与える可能性がある。

非特許文献２のテキストには、ネットワークに関連する章が含まれている。Ｓｏｌｏｍｏｎらのテキストには、「ここに記載した同期関数呼び出しに基づくインターフェイスに加えて、Ｗｉｎｄｏｗｓ（登録商標） ２０００ ＲＰＣは、非同期のＲＰＣもサポートする。非同期のＲＰＣによって、ＲＰＣアプリケーションは、一定の関数を実行できるようになるが、その関数が処理を続けていても終了するまで待たない。代わりにアプリケーションは、他のコードを実行し、後にサーバから応答が届くと、ＲＰＣランタイムは、クライアントが非同期の呼び出しと関連付けたイベントオブジェクトに信号を送る。クライアントは、関数の終了を知るため、WaitForSingleObjectなどの標準Ｗｉｎ３２関数を使用することができる」と記されている。

例示のシステムを専用のプリントサーバとともに使用して、プリンタによりデータを効率よく印刷することができる。本発明の１つの例としては、データを同時に印刷する必要があるアプリケーションプログラムを有する多数のクライアントコンピュータにサービスを提供するプリントサーバに供することである。これらのアプリケーションには、それだけには限定されないが、文書処理アプリケーションプログラムなどがある。サーバコンピュータは、クライアントコンピュータによってプリントサーバに送信されたデータの印刷を調整するサーバプリントスプーラを実装するソフトウェアを有する。いくつかのプリンタは、一般にネットワークによってサーバに結合されて、サーバプリントスプーラの指示の下に印刷を行う。

例示のシステムによれば、クライアントコンピュータは、サーバプリントスプーラに対する非同期のリモートプロシージャ呼び出しによってデータをプリンタのうちの１つに送信するクライアントコンピュータで実行されるクライアントプリントスプーラを含む。サーバプリントスプーラは、データを複数のプリンタに伝達することによって未処理のクライアントコンピュータ要求を処理するスレッドプールを維持するスレッドマネージャを含む。

クライアントコンピュータでの非同期のリモートプロシージャ呼び出しにより、停止中の、またはサーバの実行を待機中のアプリケーションプログラムのインスタンスが削減される。プリントサーバが重負荷下にあるとき、クライアントアプリケーションプログラムは、単にプリントサーバからの応答を待っている場合でさえ、うまく機能していないように思われる場合がある。

サーバでのスレッドプールの使用によって、従来技術のプリントスプーラで起こる非効率なコンテキストスイッチが低減する傾向にある。こうしたコンテキストスイッチはサーバリソースに負担をかけ、結果的にプリントサーバプロセッサ時間が非効率に使用されることになる。

例示のシステムにおいては、クライアントとサーバとの間の転送プロトコルとしてＴＣＰが使用される。ＴＣＰはより高速で、より豊富な機能を有しており、より拡張性が高く、頑強で、一般に名前付きパイプほどリソースを消費しない。ＴＣＰは、ドメインおよび他の非標準環境においてもよく機能する。ＴＣＰは、ファイアウォールとより親和性があり、そのトラフィックの処理に関わる構成要素をより少なくすることができる。

本発明のこれらおよび他の目的、利点および特徴を、添付図面とともに説明する以下のシステムの実施形態の例でより十分に説明する。

図２は、ネットワーク通信によってサーバ１２と通信する複数のワークステーション１１を有するネットワーク１０を示す図である。サーバ１２は、印刷要求を処理するためにネットワークを介していくつかのプリンタ１３と通信し、またプリンタ１３ａに結合するパラレルインタフェースのインターフェイスを備える。ネットワークを介した通信には、ワークステーションおよびサーバにインストールされている従来のイーサネット（登録商標）スイッチおよびイーサネット（登録商標）カードによる有線、および既知の無線通信標準を実装する無線ルータによる無線の両方がある。したがって、例えばラップトップコンピュータ１４は、物理的にネットワークハードウェアに結合されることなくサーバ１２と通信することができる。ワークステーション（またはラップトップ）は、ワークステーション上で実行されるアプリケーションプログラムのうちの１つの要求で、サーバに実装されているプリントスプーラに印刷を行うことを伝達し、指示することができる。文書処理アプリケーションは、例えばオペレーティングシステムによってアプリケーションに公開されているＷｉｎ３２アプリケーションプログラムインターフェイスによってその要求を伝達する。Ｗｉｎ３２は、Ｗｉｎｄｏｗｓ（登録商標）ブランドのオペレーティングシステムの現在好ましいアプリケーションインターフェイスであるが、サーバ１２に要求を送信する他の手段も本発明によって企図される。

本発明の実施形態例は、プロセス間通信のクライアント／サーバモデルを使用してプリントスプーラを実装する。より詳細には、一実施形態では、ワークステーション１１におけるクライアントプロセスは、ネットワーク１０によって１つまたは複数のプリントサーバ１２と通信して、従来技術の印刷システムより効率的で頑強な方法で印刷を行う。図３は、プリントスプーラでジョブをキューに入れるリモートプロシージャ呼び出し（本明細書ではＲＰＣ）に基づくプロセスを実施するサーバとクライアントとの対話を示す略図である。図３で、クライアント１５は、（図２のネットワークなど）ネットワークによってサーバ１６と対話していることがわかる。一例では、クライアントは、ワークステーションで実行されるソフトウェアであり、サーバソフトウェアはサーバコンピュータ１２で実行されるソフトウェアである。サーバソフトウェアは、専用のプリントサーバで実行されるソフトウェアであるが、本発明の実施形態例によれば、ワークステーションもサーバとして働くプリントスプーラを実装する。したがって、クライアント／サーバモデルによる別のアプリケーションでは、クライアントおよびサーバは、同じコンピュータ上で実行される。例えばワークステーション上のプリントスプーラは、非同期のプロシージャ呼び出しを使用して印刷要求を直接ローカルプリンタに伝達する。

ＲＰＣプロセス間通信の使用によって、ワークステーション１１の１つなど、ローカルマシン上で実行されるアプリケーションは、図２のサーバ１２などのリモートマシン上のプロセスを呼び出すことができる。呼び出す側の文書処理プログラムは、印刷プロセスがサーバ上のコード実行を呼び出すことに関与していない。ローカルアプリケーションにとっては、プロセスが完全にローカルマシン上で実行しているように見える。ＲＰＣは、トランスポートを中心とするビューよりむしろネットワーク接続された動作の手続きビュー（procedural view of networked operation）を提供し、したがって分散されたアプリケーションの開発および配置が簡単になる。Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムで使用されるＲＰＣプロセスは、ＯＳＦ（Ｏｐｅｎ Ｓｏｆｔｗａｒｅ Ｆｏｕｎｄａｔｉｏｎ）配布のコンピューティング環境との互換性がある。

ネットワーキングソフトウェアは従来、Ｉ／Ｏモデルの処理中心に構築されている。例えばＷｉｎｄｏｗｓ（登録商標）２０００では、ネットワーク操作は、アプリケーションがリモートＩ／Ｏ要求を発行したときに開始する。オペレーティングシステムは、それをリダイレクタに転送することによって要求を処理する。リダイレクタは、リモートファイルシステムとのクライアント対話をクライアントに意識させないようにするリモートファイルシステムとして動作する。

リモートプロシージャ呼び出し（ＲＰＣ）は、わずかに異なる手法を実行する。ＲＰＣアプリケーションは、プロシージャ、およびプロシージャライブラリを呼び出して特定のタスクを実行する、他の構築されたアプリケーションに類似する。しかし、インターフェイスによってアプリケーションプログラムに公開されるプログラムは、リモートコンピュータ上で実行されるプロシージャを呼び出すことができる点で相違する。リモートクライアントは、ネットワークによってサーバと通信する。これは、同じコンピュータ上のサーバと通信するローカルクライアントと異なる。

コンピュータシステム
図１は、例えば、ネットワーク１０上のワークステーション１１またはサーバ１２の構造を示すデータ処理システムの例を示している。本システムは、１つまたは複数の処理ユニット２１、システムメモリ２２、およびシステムメモリを含む様々なシステム構成要素を処理ユニット２１に結合するシステムバス２３を有する従来のコンピュータ２０の形の汎用コンピューティング装置を備える。システムバス２３は、様々なバスアーキテクチャのうちの任意のものを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のうちどんなものでもよい。

システムメモリは、読取り専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。基本入出力システム（ＢＩＯＳ）２６は、例えば起動中など、コンピュータ２０内の要素間での情報の転送を助ける基本ルーチンを含み、ＲＯＭ２４に格納されている。

コンピュータ２０は、図には示していないがハードディスクから読み取り、あるいはそこに書き込むハードディスクドライブ２７、リムーバブル磁気ディスク２９から読み取り、あるいはそこに書き込む磁気ディスクドライブ、およびＣＤ−ＲＯＭや他の光媒体など、リムーバブル光ディスク３１から読み取り、あるいはそこに書き込む光ディスクドライブ３０をさらに含む。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、それぞれハードディスクドライブインターフェイス３２、磁気ディスクドライブインターフェイス３３、および光ドライブインターフェイス３４によってシステムバス２３に接続される。ドライブおよびその関連のコンピュータ読取可能な媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュール、およびコンピュータ２０の他のデータの不揮発性記憶域を提供する。本明細書に記載した環境の例は、ハードディスク、リムーバブル磁気ディスク２９、およびリムーバブル光ディスク３１を使用するが、動作環境の例において、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）など、コンピュータによってアクセス可能なデータを格納できる他のタイプのコンピュータ読取可能な媒体を使用することもできることを当業者であれば理解されたい。

オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７、およびプログラムデータ３８を含めて、いくつかのプログラムモジュールをハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５に格納することができる。ユーザは、コマンドおよび情報をキーボード４０およびポインティング装置４２などの入力装置を介してコンピュータ２０に入力することができる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどがある。これらおよび他の入力装置は、しばしばシステムバスに結合されているシリアルポートインタフェース４６を介して処理ユニット２１に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など他のインターフェイスで接続してもよい。モニタ４７または他のタイプの表示装置もまた、ビデオアダプタ４８などのインターフェイスを介してシステムバス２３に接続される。パーソナルコンピュータ（ＰＣ）は一般に、モニタに加えて、スピーカやプリンタなどの他の周辺出力装置（図示せず）を含んでいる。

図１に示したコンピュータ２０は一般に、リモートコンピュータ４９など１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク式環境で動作する。リモートコンピュータ４９は、別のＰＣ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の一般のネットワークノードでよく、一般にコンピュータ２０に関連して上述した多くまたはすべての要素を含むが、図１にはメモリ記憶装置５０のみを示している。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ）５２を含む。こうしたネットワーキング環境は、オフィス、全社規模のコンピュータネットワーク、イントラネット、およびインターネットではごく一般的である。

ＬＡＮネットワーキング環境で使用する場合、コンピュータ２０は、ネットワークインターフェイスまたはアダプタ５３を介してローカルネットワーク５１に接続される。ＷＡＮネットワーキング環境で使用する場合、コンピュータ２０は一般に、モデム５４、およびインターネットなどＷＡＮ５２を介して通信を確立する他の手段を含む。モデム５４は、内蔵のものでも外付けのものでもよく、シリアルポートインタフェース４６を介してシステムバス２３に接続される。ネットワーク環境では、コンピュータ２０に関連して示したプログラムモジュール、またはその一部をリモートメモリ記憶装置に格納することができる。図示したネットワーク接続は例であり、コンピュータ間の通信リンクを確立する他の手段を使用してもよいことは理解されよう。

Ｗｉｎｄｏｗｓ（登録商標）２０００（およびそれ以降のバージョン）のオペレーティングシステム環境では、ＲＰＣアプリケーションを記述するために、オペレーティングシステムプログラマは、どのプロシージャがローカルで実行され、どのプロシージャがリモートで実行されるかを決定する。アプリケーションが実行されると、ローカルプロシージャ、およびローカルマシンにはないプロシージャが呼び出される。後者の場合を扱うために、アプリケーションは、リモートプロシージャごとに１つのスタブプロシージャを含む動的リンクライブラリ（ＤＬＬ）、またはローカルの静的リンクライブラリにリンクする。スタブプロシージャは、リモートプロシージャと同じ名前を有しており、同じインターフェイスを使用するが、スタブは、必要な操作を実行する代わりに、それに渡されたパラメータを取得し、ネットワークを介して送信するようにパラメータを整列させる（ｍａｒｓｈａｌ）。パラメータを整列させるプロセスとは、参照を解決し、ポインタが参照する任意のデータ構造のコピーを取得するなど、ネットワークリンクに合う特定の方法でパラメータを順序付けして、ひとまとめにすることを意味する。

次いでスタブは、リモートプロシージャが存在するコンピュータを探し出し、どのトランスポート機構を使用するかを決定するＲＰＣランタイムプロシージャを呼び出し、リモートサーバへの送信要求をローカルトランスポートソフトウェアに送信する。リモートサーバは、ＲＰＣ要求を受信すると、パラメータの整列を解き（ｕｎｍａｒｓｈａｌ）、元のプロシージャ呼び出しを再構築してプロシージャを呼び出す。サーバは、クライアント呼び出しの処理を終了すると、逆の順序で実行して結果を発呼者に戻す。Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム環境では、ＲＰＣアプリケーションの作成のプロセスは、Ｍｉｃｒｏｓｏｆｔインターフェイス定義言語コンパイラによって簡略化される。ＩＤＬファイルは、コンパイルされて、クライアント側およびサーバ側の双方のスタブルーチン、およびアプリケーションに含まれるヘッダーファイルを生成する。既存のＲＰＣアプリケーションを呼び出そうとするプログラマは、クライアント側のソフトウェアを記述し、アプリケーションをローカルのＲＰＣランタイム機能にリンクするだけでよい。

Ｗｉｎｄｏｗｓ（登録商標）２０００ネットワーキングサービスは、現在、名前付きパイプ、Ｎｅｔ ＢＩＯＳ、およびＴＣＰ／ＩＰのネットワークトランスポートプロバイダＤＬＬを含むＲＰＣアプリケーションを含む。クライアントの要求を処理するネットワーク１０上のサーバ１２などのサーバは、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（商標）によってネットワーク上でその存在を知らせる。

サーバスレッドプール
プリントスプーラ１００（サーバ１２で実行されるソフトウェアに実装）は、こうした要求を処理するスレッドプール２０２を維持することによって複数のクライアント要求（潜在的にこうした何千もの要求に同時に）に応答する。クライアント印刷要求ごとにサーバスレッドが割り当てられる従来技術と異なり、本発明の実施形態例によれば、サーバリソースに対して過度の負担をかけること無しに、効率的に複数のクライアント印刷要求に応答することができるスレッドプールが維持される。

ＲＰＣに基づくプリントスプーラ例は、第１のスレッドプール２０２ａからジョブを抽出し、サーバ上の完了ポート（completion port）２１０に基づいて第２のスレッドプール２０２ｂを実行するスケジューラ２０４を含む。完了ポートとは、ポートを待っている重複するハンドルとスレッドの組のことである。単一のＷｉｎ３２インターフェイス関数CreateIOCompletionPortは、ポートを作成し、ハンドルをポートに追加するために使用される。

受信する非同期のプリンタ関数ごとに、スプーラ１００’は、スレッドがサービスを提供するキューに項目を追加する。その非同期のプリンタ関数は、すぐにクライアントに戻る。スプーラ１００’は、スケジューラ２０４からキューに入れられた要求を処理するためのいくつかのワーカスレッドを有しており、１つのスレッドがこうした要求のキュー内の１つの要求を処理し終えると、非同期ＲＰＣ完了呼び出し関数（complete call function）によって結果がクライアントに送信される。次いでそのスレッドは、キューから次の項目を取得してその要求を処理する。キューのサイズに応じてスレッドプール内のスレッド数は増減して、負荷を管理することができる。

高性能サーバプリントスプーラの実装は、効率的なスレッドモデルの実装を必要とする。クライアント要求を処理するにはプリントスプーラスレッドが少なすぎる、または多すぎることによって、性能の問題がもたらされる可能性がある。プリンタスプーラの実施形態例の目的は、そのスレッドが不要なブロッキングを回避するようにしてできるだけ少ないコンテキストスイッチしか負担を受けないですむようにすると同時に、複数のアクティブなスレッド間の並行処理を最大限に実行することである。

プリントスプーラ１００’の一例では、印刷サービスを要求している様々なクライアント処理によってスプーラ１００に渡された印刷ジョブを達成するための焦点としてＩ／Ｏ完了エグゼクティブオブジェクト（completion executive object）２１０が使用されるが、これは完了ポートとしてＷｉｎ３２にエクスポートされる。

残念ながら、プリントスプーラ１００によって実行される関数の一部は、様々な理由のためにすぐには終わらない。これには、グローバルレジストリロック（global registry lock）、および他の遅い関数の呼び出しが含まれる。これらの関数でブロックが発生すると、スレッドプール１０６を維持するＲＰＣランタイムは、別のスレッドを作成して、スケジューラによって送信された新たに受信するクライアントにサービスを提供する。

本発明によれば、サーバが処理するのに時間のかかる関数が識別され、クライアントで非同期に実行するように変更される。従来技術のシステムの分析によると、終了に長時間を要するスプーラ自体から発信された関数ＮＯＴからのデータが提供された。これらの関数を識別することは、クライアントにおいて非同期のインターフェイスメソッドとして実行されるのがどの関数かを選択するための方法の１つである。

例示のシステムでは、新しいインターフェイスは、従来技術のｗｉｎｓｐｏｏｌインターフェイスと並行して実行される。新しいインターフェイスを実行する際、一部の関数は非同期であり、一部の関数は同期である。新しいインターフェイスは、非同期関数および同期関数を有し、そのトランスポートプロトコルとして名前付きパイプを使用する古い同期インターフェイスと並行して実行される。名前の衝突を避けるために、異なるメソッド名が使用される。

ＴＣＰ／ＩＰトランスポートおよびセキュリティモデル
従来技術のプリントスプーラにおいてトランスポートプロトコルとして使用された名前付きパイプは、静的エンドポイントを有する。本発明の実施形態例では、名前付きパイプを使用せず、代わりに図２のワークステーション１１およびサーバ１２など、異なる装置上で実行されるクライアントとサーバとの間で転送を行うｔｃｐ／ｉｐ転送プロトコルに依存する。本発明の現在好ましい実施形態ではＴＣＰ／ＩＰが使用されるが、他の実施形態では、ハイパーテキスト転送プロトコル（ｈｔｔｐ）など他の転送プロトコルを使用することができる。

ｔｃｐ／ｉｐの場合、例示のシステムでは、動的エンドポイントが使用される。サーバ側は、プロトコルシーケンスを登録し、次いで結合ベクトルを取得する。最後に、サーバはエンドポイントを登録する。

確実に所定のプロセスを特定のプロトコルシーケンスでのみ呼び出されるようにするため、例示のシステムでは、セキュリティコールバック関数（security callback function）を登録し、その関数で、どのプロトコルシーケンスで呼び出しが行われるかがチェックされる。

現在、Ｗｉｎｄｏｗｓ（登録商標）ＲＰＣは、ＳＳＰＩ（セキュリティサポートプロバイダインターフェイス）に基づくセキュリティモデルを提供しており、これは、高レベルのセキュリティを提供し、本発明の実施形態例によって使用される。

例示のシステムでは、サーバプリントスプーラでスレッドプールを作成する。受信する各非同期関数の呼び出しは、スプーラに、作業項目をスレッドプール２０２ａに入れさせてすぐにクライアントに戻る。作業項目は、後に第２のスレッドプール２０２ｂによってスケジュールされて実行される。プリントスプーラは、作業項目をスレッドプールのキューに入れる。

非同期メソッドへのクライアント呼び出し
ローカルクライアントは、新しい非同期インターフェイスメソッドを呼び出し、それによって文書処理プログラムなどの非同期パブリックＡＰＩをアプリケーションに公開する。また、スプーラクライアントは、新しい非同期メソッドを呼び出し、したがって一部の非同期メソッドＡＰＩをアプリケーションプログラムに公開する。例えば、文書処理プログラムは、あるプリンタの状況をチェックするために、ＧｅｔＰｒｉｎｔｅｒＤａｔａの非同期バージョンなど、非同期メソッドの例を呼び出すことができる。この関数は、ローカルの装置内のスプーラクライアントを経由してリモートサーバ装置内のスプーラを通る。サーバスプーラでは、本質的にスプーラワーカスレッドプール（spooler worker thread pool）２０２ａ内にサービス要求を追加して、すぐに文書処理プログラムにもどる。文書処理プログラムは次いで、他のタスクに取りかかることができ、後にプリンタデータが取り上げる準備がいつできるかが通知される。

従来技術のプリンタ通知は複雑である。アプリケーションは、例えばジョブが終了したかどうかを判定するためにプリンタ状況変更を監視したい場合、関数Find First Printer Change Notification（本明細書ではＦＦＰＣＮ）を呼び出す。この関数は、スプーラを呼び出し、スプーラは、サーバとの通信チャネルを設定する。後に文書処理プログラムが監視する必要のあるイベントが生じると、サーバスプーラは、イベント変更通知をスプーラクライアントに送り返す。この通信チャネルの設定および維持は、サーバでの大量のリソースを消費し、サーバスプーラが効率よく多数のクライアントを同時に扱うことを防ぐ。

従来技術の設計では、サーバは、逆方向チャネルを介して変更データを連続的にクライアントに送信する。ｗｉｎｓｐｏｏｌクライアントは、関数ＦＦＰＣＮへの次の呼び出しまで変更データをキャッシュに入れる。非同期ＲＰＣが使用される場合、変更データはデータを完了させる非同期呼び出しに包み込まれ、クライアントは、前の非同期ＲＰＣ呼び出しが完了すると、より多くの通知データのために、別の非同期ＲＰＣ呼び出しをプリンタに発行する。

図４は、従来技術版のＦＦＰＣＮ関数の概要を示している。

ステップ１１１：クライアントアプリケーション１０４は、関数RpcClientFindFirstPrinterChangeNotificationを呼び出す。

ステップ１１２：クライアントスプーラルータ１０５は、関数RouterFindFirstPrinterChangeNotificationを実行させてＷｉｎ３２プロバイダ１０６の関数RemoteFindFirstPrinterChangeNotificationを呼び出す。

ステップ１１３：Ｗｉｎ３２プロバイダはルータ関数CallRouterFindFirstPrinterChangeNotificationを呼び出す。

ステップ１１４：クライアントスプーラルータは、リモートスプーラ１００上のRpcRemoteFindFirstPrinterChangeNotificationExを呼び出す。

ステップ１１５：リモートスプーラルータ１０７関数RemoteFindFirstPrinterChangeNotificationは、ｌｏｃａｌｓｐｌプロバイダ１０８のLocalFindFirstPrinterChangeNotificationを呼び出す。

ステップ１１６：ｌｏｃａｌｓｐｌは、ルータ関数SetupReplyNotificationを呼び出す。

ステップ１１７：ルータ関数SetupReplyNotificationは、クライアントスプーラ上のRpcReply0penPrinterを呼び出して逆方向チャネルを通知用に設定する。

ローカルスプーラ上で何かが変更されると、図４Ａに概要を示すように、ローカルスプーラはクライアントに通知する。

ステップ１２１：ｌｏｃａｌｓｐｌは、リモートスプーラルータ関数PartialReplyPrinterChangeNotificationを呼び出すSetPrinterChangeを呼び出す。

ステップ１２２：PartialReplyPrinterChangeNotificationは、変更を蓄積し、別のスレッドThreadNotifyProcessJobは、クライアントスプーラに対してRpcRouterReplyPrinterを呼び出す。

ステップ１２３：RpcRouterReplyPrinterのクライアントスプーラは、ルータ関数RouterReplyPrinter->ReplyPrinterChangeNotificationWorker-->ThreadNotifyを呼び出す。ReplyPrinterChangeNotificationWorkerは、SetEvent（pChange->hEvent）を呼び出してクライアントを起動させる。

ステップ１２４：クライアントアプリケーションは、RpcFindNextPrinterChangeNotificationを呼び出す。

ステップ１２５：クライアントへの通知データを書き込み、リッスン状態にリセットするルータ関数RouterFindNextPrinterChangeNotificationを呼び出す。

このように従来技術のプリントスプーラの概要をまとめることによって、関数ＦＦＰＣＮの従来技術の実装に関する問題を識別するのが容易となる。サーバ１００は、任意のリッスン側クライアントのチャネルを設定する必要がある。これは、各チャネルがサーバプリントスプーラ１００上で一定の量のカーネルメモリを消費することから拡張性の問題でということができる。サーバは、まずシステムを使用してクライアントに接続を試み、クライアントネットワークの資格情報の使用を試みる。Ｗｉｎｄｏｗｓ（登録商標） ＮＴ４では、システムはネットワーク上でのＮＵＬＬの資格情報であり、Ｗｉｎｄｏｗｓ（登録商標） ２０００以降では、ｄｏｍａｉｎ＼ｍａｃｈｉｎｅ原則の資格情報（principle credential）である。クライアントネットワークの資格情報は、委任が可能でない限り、ＮＵＬＬの資格情報である。この逆方向チャネルを動作させるために、名前付きパイプを作成すると、すべての匿名ユーザに書き込み許可が与えられる。

図５に、本発明の実施形態例の非同期ＲＰＣの概要を示している。ステップは以下の通りである。

ステップ１５１：クライアントアプリケーション１０４’は１５１で関数RpcClientFindFirstPrinterChangeNotification()を呼び出す。

ステップ１５２：クライアントスプーラ内のルータ１６０は、イベントを作成し、呼び出しをＷｉｎ３２ｓｐｌプロバイダ１６１に発送する。

ステップ１５３：ｗｉｎ３２ｓｐｌプロバイダ１６１は、非同期RpcAsyncFindFirstPrinterChangeNotification()がリモートスプーラ１００’を呼び出すようにする。

ステップ１５４：リモートスプーラのｌｏｃａｌｓｐｌ１６２は、変更を監視する。

ステップ１５５：変更が削除されると、RpcAsyncCompleteCallが呼び出されてステップ１５３の非同期呼び出しを終了する。

ステップ１５６：ｗｉｎ３２ｓｐｌプロバイダでは、終了した呼び出しを受信すると、イベントを設定し、ステップ１５３からステップ１５５を繰り返す。

ステップ１５７：クライアントがRpcFindNextPrinterChangeNotification()を呼び出すと、ローカルスプーラは、キャッシュされた変更情報を送り返す。

プリンタ通知に非同期ＲＰＣを使用することによって、クライアントアプリケーションに変更データを送信するプロセスが大幅に簡略化される。文書処理プログラムは、新しい変更通知ＡＰＩを呼び出すことができる。この呼び出しは非同期であり、このことは、アプリケーションにすぐに戻ることを意味する。文書処理が必要とするイベントが行われると、サーバプリントスプーラ１００’は、その未処理の非同期メソッド呼び出しを終了する。スプーラクライアントは、完了した非同期通知から通知データを取得し、処理プログラムに送信し、サーバスプーラを同じ関数で再度呼び出してより多くの変更データを取得する。基本的に、非同期メソッドの終了段階において、変更通知データが運ばれ、非同期メソッドのループ呼び出しが行われてプリンタオブジェクトの変更が連続的に監視される。

ポートスレッドの拡張性の向上
サーバプリントスプーラ１００において、完了ポートスレッド２１０は、完了ポートが第１のジョブを受信したときに関数CreatePortThreadで作成され、未処理のジョブがなくなると、DestroyPortThreadによって破棄される。これは、新しいジョブの印刷の用意ができると、SetEvent(plniPort->Semaphore)によって起動される。ポートスレッドはプリントプロセッサを呼び出し、プリントプロセッサは、ＧＤＩおよびプリンタドライバをロードして印刷ジョブを実行させる（ｒｅｎｄｅｒ）（それらをプリンタ言語に変換する）。このステップは、ＣＰＵに負荷がかかる。

サーバプリントスプーラ１００’での印刷ジョブのシーケンスは次の通りである。
１．印刷ジョブを開始するには、StartDocPrincer --> localspl!LocalStartDocPrinter --> tcpmon!StartDocPortを呼び出す。
２．各ページを開始するには、StartPagePrinterを呼び出す。
３．データをページに書き込むには、Writeprinterを呼び出す。
４．各ページを終了するには、EndPagePrinter--> localspl!LocalWritePrinter---> tcpmon!WritePortを呼び出す。
必要なページだけ２、３、４を繰り返す。
印刷ジョブを終了するには、EndDocPrinter --> tcpmon!Writeportおよびtcpmon!EndDocPortを呼び出す。

スレッドの低減――スレッドプールを使用して印刷ジョブをスケジュールする
プリントスプーラ１００’は、新しいジョブを開始するスケジューラ２０４を実装する。スケジューラは、関数QueueUserWorkltemを呼び出して、ジョブ（作業項目）を第２のジョブスレッドプール２０６に入れる（図７参照）。

ｔｃｐｉｐモニタは、ジョブを処理するプリンタ１３に接続される。Tcpmon!StartDocPortは、接続が失敗すると、特別なエラーを返す。StartDocPortが失敗すると、スケジューラ２０４は、作業項目を同じ処理にかけて、後に作業項目を再試行（ジョブを再起動）する。

別の接続を最適化する方法としては、未処理の別のジョブがある場合、プリントスプーラは、サーバとプリンタとの間の確立された接続を再利用するという方法をとることができる。

本発明の実施形態例によって対処すべき問題は、スレッドプール２０６内の長いプリンタジョブが終了するのに時間がかかり、事実上スレッドプール２０６内の他のプリンタジョブをブロックしてしまうことである。実行しているスレッドがこの問題に対処するのに時間がかかり過ぎる場合、スレッドプールの実施形態においては、追加のワーカスレッドが作成される。

Ｉ／Ｏブロックの回避
上述したように、スプーラは、準備完了状態のジョブごとに作業項目を作成する。サーバが１０００台のプリンタに接続されている場合、最大１０００個の作業項目があり、これは、かなり少ない数のスレッドに変換されて、ポートスレッドプール２０６内の作業項目として処理される。

各作業項目に関して、スレッドプール２０６は、次のような端的な方法で実行される。

ｔｃｐｉｐモニタの例では、tcpmon! WritePortごとに、スプーラは、重複するSendDatatoPrinter関数が終了するまでは返す。

ProcessJobData()は、ＣＰＵに負荷がかかる何らかの描画（ｒｅｎｄａｉｎｇ）作業を意味する。ネットワークスループットを向上させるには、実施形態例では、ＩＯ完了ポート２１０を使用して、非同期ＩＯ通知を取得する。これによって、作業項目当たりの未解決の非同期ＩＯ呼び出し回数の閾値が得られる。その閾値に到達すると、スレッドは待ち状態になる。これを行うことによって、ポートプール２０６内のスレッド作業項目は、閾値に到達するまで如何なるブロックにもあわずに、ページを引き続き描画することができる。

例示のシステムでは、生データの転送にＷｉｎｄｏｗｓ（登録商標）ソケット関数TransmitFileが使用される。Ｉ／Ｏ完了ポートは、重複するTransmitFile呼び出しの通知を取得する。

Ｉ／Ｏ完了ポートスレッドインフラストラクチャの作成
Ｉ／Ｏ完了ポートスレッドは、すべての作業項目が重複する呼び出し状況を管理する。

ｌｏｃａｌｓｐｌは、初期化時（または他のとき）にIOCompletionポートを作成する。また、AsyncIoNotifyThreadスレッドを開始する。実施形態例では、サーバのＣＰＵごとに１つの並行するワーカスレッドを使用する。

Ｉ／Ｏ完了ポートスレッドは、次の機能を行う。１．非同期のWSASend/TransmitFilesから通知を受け付ける。２．WSASend/TransmitFileが成功または失敗すると、解放または再送信する。３．ポートごとに未解決の非同期ＩＯを監視する。

サーバがスケジュールされたジョブの印刷を開始する用意ができると、ｌｏｃａｌｓｐｌ１６２（図５）は、tpcmon!StartDocPortを呼び出し、完了ポートに渡す。ｔｃｐｉｐモニタ内で、ソケットが作成され、ＩＯ完了ポートに関連付けがなされる。ｔｃｐｉｐモニタはソケットとをＩ／Ｏ完了ポートとの関連付けを行なう。

重複するTransmitFileを使用して生ジョブを送信する
実施形態例では、サーバ内のｔｃｐｉｐモニタプログラム、プリントプロセッサプログラム、およびｌｏｃａｌｓｐｌ１６２プログラムの変更が含まれる。生データの従来技術の処理方法には、大きいオーバーヘッドがある。実施形態例では、重複するTransmitFileを呼び出して生ジョブを送信する。

これは、繰り返してファイルを読み取り、メモリに書き込み、データをプリンタに送信するといったオーバーヘッドを回避する。また、特にクライアント側の描画の際にスループットの向上が期待される。

追加のメソッド
TransmitRawJob(HANDLE hRawFile, LPWSA0VERLAPPED IpOverlapped)
が必要である。

重複するWSASendを使用して他のジョブを送信する
tcpipmon!WritePortでは、スケジューラ２０４は、ｉｏごとのデータ（per-io data）でWSASendを呼び出す。

perloDataは、WSASendシーケンスのカウンタを含む。また、EndDocPort()が呼び出されると、WSASend呼び出し回数をスプーラ１００’に返すことができる。スプーラは、その数を使用して、ジョブが完全に送信されたかどうかを追跡することができる。

１つのポートで１つのジョブが終了すると、スケジューラ２０４は、このポートにおいて次のジョブを発送する前に、未解決の（ｏｕｔｓｔａｎｄｉｎｇ）重複するすべてのＩ／Ｏが成功裏に終了したことを確認する必要がある。そうでない場合、ジョブを再起動する必要がある。また、localspl!localwritePrinterで、tcpip!writeportを呼び出す前に、スケジューラ２０４は、未処理のジョブ数が決して閾値を超えないようにする必要がある。

さらにスケジューラは、非同期のＩ／Ｏに使用すべき空のメモリ、およびロックされたメモリのリストを保持する。

スケジューラは、WritePortExと呼ばれる追加メソッドを加える必要がある。ｌｏｃａｌｓｐｌ １６２がｉｏごとのデータ（例えばWSASendのシーケンス番号）を渡すことができるように、追加パラメータがLPWSAOVERLAPPED lpOverlappedを呼び出すようにした。

ポートスレッド２０６で、未解決の非同期のＩ／Ｏ要求の閾値に適した回数を見つけることは、調整可能なパラメータである。これは、多くの要因に依存する。閾値をかなり低く設定すると、スレッドプール２０６は、常にブロックされ、データが送信されるのを待つ可能性がある。閾値をかなり高く設定すると、描画プログラム（ｒｅｎｄｅｒｉｎｇ ｃｏｄｅ）は、まったくブロックされること無く実行し続けることはできるが、未処理のＩ／Ｏデータを保持するのにより多くのメモリが必要となり、未処理のＩ／Ｏ操作を追跡するためにより多くのｎｏｏｎｐａｇｅｄプールが割当られる。この閾値の２〜８の値は、使用するように提案された数値であり、最適な結果は、ＬＡＮ速度、データ生成速度、データ消費速度などによって異なる。

未処理のＩ／Ｏ要求が非常に多くなるのを回避するには、次のような疑似コードによる最適化と組み合わせることもできる。

この技術は、完全にＩ／Ｏ完了ポートを置き換えることはできない。というのは、Ｉ／Ｏデータ消費の場合はデータ生成に追いつかないため（そのために重複する複数のＩ／Ｏが必要）、Ｉ／Ｏに未処理のデータで満たされない空きがある。

本発明はある程度の特定性で説明してきたが、本発明は、特許請求の範囲の意図および範囲内に含まれる開示された設計のすべての変更および変形を含むものとする。

本発明の実施形態例の実施に使用するコンピュータシステムを示す略図である。 少なくとも１つのコンピュータが本発明に従って構築されたプリントスプーラを実装するソフトウェアを含むネットワーク接続された複数のコンピュータを示す略図である。 本発明によるリモートプロシージャ呼び出しに基づくプリンタスプーラを実装する層状のソフトウェア構成要素を示す略図である。 クライアントとサーバとのプリントスプーラ間のプリンタ通知のためにプロセス間通信がどのように働くかを示す従来技術の図である。 クライアントとサーバとのプリントスプーラ間のプリンタ通知のためにプロセス間通信がどのように働くかを示す従来技術の図である。 本発明の実施形態例によるクライアントとサーバとのプリンタスプーラ間のプロセス間通信を示す図である。 本発明の実施形態例によるクライアント要求を処理するスレッドプールの動作を示す図である。 印刷要求を処理するスレッドプールに印刷ジョブを追加するスケジューラを示す略図である。

符号の説明

２１ 処理ユニット
２２ システムメモリ
２３ システムバス
３２ ハードディスクドライブインターフェイス
３３ 磁気ディスクドライブインターフェイス
３４ 光ドライブインターフェイス
３５ オペレーティングシステム
３６ アプリケーションプログラム
３７ 他のプログラムモジュール
３８ プログラムデータ
４６ 特殊ポートインターフェイス
４８ ビデオアダプタ
４９ リモートコンピュータ
５１ ローカルエリアネットワーク
５２ 広域ネットワーク
５３ ネットワークインターフェイス
５４ モデム
１００ サーバスプーラ
１０２ クライアントスプーラ
１０４ クライアントＡＰＰ
１０５ ルータ
１０７ ルータ
１０８ ローカルＳＰ
１００ サーバスプーラ
１０２ クライアントスプーラ
１０４ クライアントＡＰＰ
１００’ サーバスプーラ
１０２’ クライアントスプーラ
１０４’ クライアントＡＰＰ
１６０ ルータ
１６２ ローカルＳＰ
１００’ スプーラ
２０４ ジョブスケジューラ
２０６ スレッドプール
２１０ Ｉ／Ｏ完了ポートモニタスレッド

Claims (28)

1. ａ）印刷機能を有するアプリケーションプログラムを含む１つまたは複数のクライアントと、
   ｂ）前記１つまたは複数のクライアントによって前記サーバに伝達されるデータの印刷を調整するサーバプリントスプーラを実装するサーバと、
   ｃ）前記サーバプリントスプーラの指示により印刷する前記サーバに結合する１つまたは複数のプリンタとを備え、
   ｄ）クライアントの１つは、前記サーバプリントスプーラへの非同期リモートプロシージャ呼び出しによって前記１つまたは複数のプリンタのうちの少なくとも１つと通信する実行中のクライアントプリントスプーラを含むことを特徴とするプリンタによりデータを印刷するシステム。
2. 前記サーバスプーラは、データを前記複数のプリンタに伝達することによって未処理のクライアントコンピュータの要求を処理するスレッドプールを保持するスレッドマネージャを含むことを特徴とする請求項１に記載のシステム。
3. 前記サーバプリントスプーラは完了ポートを実装し、前記クライアントから受信する印刷要求が前記完了ポートに追加されることを特徴とする請求項１に記載のシステム。
4. 前記サーバプリントスプーラは、処理を待機中の印刷要求のリストを保持し、前記印刷要求のリストは、前記サーバのプロセッサ時間を共有しているスレッドプールに追加されることを特徴とする請求項１に記載のシステム。
5. 複数のスレッドプールが作成されて前記印刷要求を処理し、前記複数のスレッドプールの各々は単一のプロセッサスレッドによって処理されることを特徴とする請求項４に記載のシステム。
6. 前記クライアントプリントスプーラは所定のプロシージャを非同期に実行し、前記プロシージャのうちの一部は同期で実行されることを特徴とする請求項１に記載のシステム。
7. 前記クライアントは、印刷ジョブ全体が終了するまで、複数の非同期の要求でデータをサーバプリントスプーラに送信することを特徴とする請求項１に記載のシステム。
8. スレッドプールに印刷要求を送信して処理を行うスケジューラをさらに含むことを特徴とする請求項１に記載のシステム。
9. 前記スケジューラは、第１のプリント処理スレッドプールから印刷要求を選択し、第２のプリント処理スレッドプールに追加することを特徴とする請求項８に記載のシステム。
10. 前記スケジューラは、重複して生データを前記スレッドプールに送信することを特徴とする請求項８に記載のシステム。
11. 複数のプリンタによって複数のクライアントから発信されるデータを印刷する方法であって、
    ａ）アプリケーションがクライアントと通信し、クライアントがプリントサーバと通信するためのプリントスプーラインターフェイスを提供するステップであって、前記１つまたは複数のアプリケーションは、前記プリントスプーラインターフェイスを用いて、前記１つまたは複数のアプリケーションから発信される非同期のリモートプロシージャ呼び出しにより前記プリントサーバ上のサービスルーチンを呼び出すことが可能になるステップと、
    ｂ）１つまたは複数のコンピュータアプリケーションによって前記サーバに送信された印刷要求間にプリントサーバランタイムを割当ることにより前記クライアントからの印刷サービスの要求に応答するスケジューラを前記プリントサーバコンピュータで実行するステップと
    を備えたことを特徴とする方法。
12. 前記スケジューラは、１つまたは複数のスレッドプールを実装して、前記複数のコンピュータアプリケーションからの印刷要求を処理することを特徴とする請求項１１に記載の方法。
13. 前記１つまたは複数のスレッドプールは完了ポートによって実行され、前記クライアントコンピュータから受信する印刷要求は完了ポートに追加されることを特徴とする請求項１２に記載の方法。
14. 前記プリントサーバは、処理を待機中の印刷要求のリストを保持し、前記印刷要求のリストは、前記プリントサーバコンピュータのプロセッサ時間を共有しているスレッドプールに追加されることを特徴とする請求項１１に記載の方法。
15. 複数のスレッドプールは前記印刷要求を処理するように作成され、各スレッドプールは単一のプロセッサスレッドによって処理されることを特徴とする請求項１４に記載の方法。
16. 前記クライアントプリントスプーラインターフェイスは所定のプロシージャを非同期に実行し、前記プロシージャのうちの一部は同期で実行されることを特徴とする請求項１１に記載の方法。
17. 前記クライアント要求は、複数の非同期リモートプロシージャ呼び出しで前記プリントサーバコンピュータに連続的に伝えられる複数の印刷要求により構成されている印刷ジョブであることを特徴とする請求項１１に記載の方法。
18. 前記印刷要求は、スケジューラによりスレッドプールに送信されて処理されることを特徴とする請求項１１に記載の方法。
19. 前記スケジューラは、第１のプリント処理スレッドプールから印刷要求を選択し、第２のプリント処理スレッドプールに前記印刷要求を追加することを特徴とする請求項１８に記載の方法。
20. クライアント／サーバコンピューティングシステムにおいて、
    ａ）印刷要求をサーバプリントスプーラに伝達する通信チャネルにより非同期クライアント印刷要求を受信するステップと、
    ｂ）前記クライアント印刷要求を前記印刷要求のキューに入れるステップと、
    ｃ）スレッドプール内の前記印刷要求の処理の間で切り替えるプロセッサスレッドによって処理される前記印刷要求のサブセットを前記スレッドプールに入れることによって、選択されたプリント位置で前記印刷要求のサブセットからプリント出力をスケジュールするステップと
    を備えたことを特徴とするサーバプリントスプーラを実行する方法。
21. 複数のプリンタで複数のクライアントから発信されたデータを印刷するプリントスプーラを実行するコンピュータ読取可能な媒体であって、
    ａ）コンピュータアプリケーションがサーバと通信するためのプリントスプーラインターフェイスを提供するステップであって、前記１つまたは複数のアプリケーションは、前記プリントスプーラインターフェイスを用いて、前記アプリケーションから発信される非同期のリモートプロシージャ呼び出しによりプリントサーバ上のサービスルーチンを呼び出すことが可能になるステップと、
    ｂ）前記クライアントからの印刷サービスの要求に応答するスケジューラを前記プリントサーバで実行して、複数のコンピュータアプリケーションによって前記サーバに送信された印刷要求間にサーバランタイムを割当るようにするステップと
    を実行する命令を備えたことを特徴とするコンピュータ読取可能な媒体。
22. 前記スレッドプールは完了ポートによって実行され、クライアントから受信する印刷要求は前記完了ポートに追加されることを特徴とする請求項２１に記載のコンピュータ読取可能な媒体。
23. 前記プリントサーバは、処理を待機中の印刷要求のリストを保持し、前記印刷要求のリストは、前記サーバのプロセッサ時間を共有しているスレッドプールに追加されることを特徴とする請求項２１に記載のコンピュータ読取可能な媒体。
24. 複数のスレッドプールが作成されて前記印刷要求を処理し、前記複数のスレッドプールの各々は単一のプロセッサスレッドによって処理されることを特徴とする請求項２３に記載のコンピュータ読取可能な媒体。
25. 前記プリントスプーラインターフェイスは所定のプロシージャを非同期に実行し、前記プロシージャのうちの一部は同期で実行されることを特徴とする請求項２１に記載のコンピュータ読取可能な媒体。
26. 複数の非同期リモートプロシージャ呼び出しで前記プリントサーバに連続的に伝達される複数の印刷要求は、印刷ジョブを構成することを特徴とする請求項２１に記載のコンピュータ読取可能な媒体。
27. 前記印刷要求は、スケジューラによりスレッドプールに送信されて処理されることを特徴とする請求項２１に記載のコンピュータ読取可能な媒体。
28. 前記スケジューラは、第１のプリント処理スレッドプールから印刷要求を選択し、第２のプリント処理スレッドプールに前記要求を追加することを特徴とする請求項２７に記載のコンピュータ読取可能な媒体。
    

Images