JPH11327938A

JPH11327938A - フロー制御方法

Info

Publication number: JPH11327938A
Application number: JP10155230A
Authority: JP
Inventors: Hideo Sudo; 日出夫須藤
Original assignee: Oki Data Corp
Current assignee: Oki Electric Industry Co Ltd
Priority date: 1998-05-20
Filing date: 1998-05-20
Publication date: 1999-11-30

Abstract

(57)【要約】【解決手段】各アプリケーション７−１〜７−４によ
るパケットの受信処理は、キュー１１に登録する。自ア
プリケーションがカレントになると、自アプリケーショ
ンが使用しているコネクションを通じて送信元のノード
に印刷データ送信要求を発信する。処理を終了すると、
受信バッファを開放して、自アプリケーションの次に登
録してあるアプリケーションにカレントを受け渡す。そ
のアプリケーションが、キュー１１の２番目以降に別の
ジョブを実行するための登録をしている場合には、コネ
クションを切断しないで接続状態を持続させる。【効果】カレントとなっているアプリケーションは、
受信バッファを最大限に使用でき、そのシステムにおけ
る最大の速度で印刷パケットを受信することができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークに接
続され、複数のネットワークプロトコルを搭載するシス
テムが、複数のノードと同時に接続して通信を行う場合
に必要な、受信パケットのフロー制御方法に関するもの
である。

【０００２】

【従来の技術】ネットワークに接続されたシステムは、
ネットワークを介して他のノードと通信を行うために、
ネットワークプロトコルを搭載する。通有心相手先のノ
ードの使用するプロトコルには様々な種類のものがある
ため、通常は、複数のネットワークプロトコルを搭載す
る。これらのネットワークプロトコルには、それぞれ受
信パケットのフロー制御（流量制御）が装備されてい
る。フロー制御とは、ネットワーク上で２つのノードが
通信をする場合に、受信側のノードが送信側のノードに
対して、受信バッファの残り容量や、受信性能を考慮し
て、単位時間あたりのパケットの送信量（送信速度）を
調節するように要求するような制御をいう。送信側は、
要求された送信量に応じてパケットを送信するためのテ
ンポを調節する。

【０００３】フロー制御が無い場合、ネットワーク上で
通信する２つのノードにおいて、受信側は送信されてく
るパケットを無条件に受信しなければならなくなる。送
信側が送るパケットの送信速度が受信側の受信速度より
速い場合には、パケットの受け溢し(オーバーフロー)が
発生する。また、送信側のパケット送信速度が受信側の
受信速度より著しく遅い場合には、受信側の待ち時間が
増え、非効率な送受信となる。常に一定速度でパケット
を受信し続けられる受信側ノードはありえないので、フ
ロー制御は必須機能といえる。

【０００４】

【発明が解決しようとする課題】ところで、上記のよう
な従来の技術には、次のような解決すべき課題があっ
た。単一のプロトコルを搭載したノードであれば、受信
するパケットのフロー制御は搭載されたプロトコルの持
つフロー制御機能が行う。しかし、複数のプロトコルを
同時に動作させるノードが複数のノードから別々のプロ
トコルを用いてパケットを受信する場合（これをホット
プロトコルという）、それぞれのプロトコルが持つフロ
ー制御が、お互いに影響し合い、効率的に動作しなくな
ってしまうことがある。即ち、各プロトコルがフロー制
御のための受信バッファ（メモリ）を独自の制御で占有
するため、システム全体からみた場合に、受信バッファ
の使用効率が悪く、受信速度の遅いシステムとなってし
まう場合もある。

【０００５】

【課題を解決するための手段】本発明は以上の点を解決
するため次の構成を採用する。〈構成１〉複数のネットワークプロトコルをサポートす
るシステムにおいて、ネットワークからパケットを受信
して処理する複数のアプリケーションを順に登録して、
上記パケットの受信順と、受信処理の起動関数を管理す
るキューを設定し、このキューのカレントに登録された
アプリケーションが、上記パケットの受信処理を終了す
ると、そのアプリケーションは、受信バッファを開放し
て、その時点でキューに対して次に登録してあるアプリ
ケーションの関数をコールしてカレントを受け渡すこと
を特徴とするフロー制御方法。

【０００６】〈構成２〉構成１に記載のフロー制御方法
において、カレントを受け渡したアプリケーションは、
その後も確立したコネクションを切断しないで維持する
ことを特徴とするフロー制御方法。

【０００７】〈構成３〉構成１に記載のフロー制御方法
において、キューに登録された優先度の低い処理を優先
度の高い処理で置き換え、この優先度の高い処理が終了
したのち優先度の低い処理を元の位置に再登録し直し、
続いてこの優先度の低い処理を実行することを特徴とす
るフロー制御方法。

【０００８】〈構成４〉構成１に記載のフロー制御方法
において、サポートするアプリケーションの種類を優先
度の高いアプリケーショングループと優先度の低いアプ
リケーショングループとに分類し、優先度の高いアプリ
ケーショングループが使用可能な容量の限界値を、優先
度の低いアプリケーショングループが使用可能な容量の
限界値より大きくなるように、受信バッファの容量を設
定して、その限界値を、コネクション数に応じて動的に
変更することを特徴とするフロー制御方法。

【０００９】〈構成５〉構成１に記載のフロー制御方法
において、一定時間毎に受信したパケット中のブロード
キャスト（Broadcast）パケットとマルチキャスト（Mul
ticast）パケットのサイズを全て加算した合計サイズを
求め、その合計サイズに相当する記憶領域分を受信バッ
ファから差し引いて、パケット受信用の空きバッファ領
域にすることを特徴とするフロー制御方法。

【００１０】

【発明の実施の形態】以下、本発明の実施の形態を具体
例を用いて説明する。《具体例１》図１は、本発明のフロー制御方法を実施す
るシステムのブロック図である。この図の説明に入る前
に、このシステムが接続されるネットワークとそのプロ
トコルによる一般的な動作を説明する。

【００１１】図２は、複数のプロトコルを搭載したシス
テムの説明図である。図のように、ノード１Ａ，１Ｂ，
１Ｃは、相互にネットワーク２を通じて接続されてい
る。ノード１ＡにはプロトコルＸが搭載されている。ノ
ード１ＢにはプロトコルＹが搭載されている。ノード１
ＣにはプロトコルＸとプロトコルＹとが搭載されてい
る。

【００１２】図に示すような接続環境において、ノード
１Ａとノード１ＣはプロトコルＸを使用して通信し、ノ
ード１Ｂとノード１ＣはプロトコルＹを使用し通信して
いる。ノード１Ａおよびノード１Ｂが送信側ノード、ノ
ード１Ｃが受信側ノードであるとき、ノード１Ａとノー
ド１Ｃ間のコネクションはプロトコルＸの持つフロー制
御を使用し、ノード１Ｂとノード１Ｃ間のコネクション
はプロトコルＹのフロー制御を使用して通信をする。ノ
ード１Ｃは、それぞれのプロトコルＸ，Ｙのフロー制御
を使用してパケットを受信する。

【００１３】図３には、一般的なシステムの動作シーケ
ンスのうちで、特に問題となるタイミングについて図示
した。まずステップＳ１で、ノード１ＣのプロトコルＸ
は、その時点での空き受信バッファサイズＭをチェック
する。なお、ここではＭを“１０”とする。ノード１Ｃ
はノード１Ａに対して、サイズＭ分のパケットを要求す
る。この直後に、ノード１ＣのプロトコルＹがその時点
での空き受信バッファサイズをチェックしたとする（ス
テップＳ２）。すると、直前にパケットの送信要求を出
したノード１Ａからのパケットは未だ到着していないた
め、空き受信バッファサイズＭが得られる。

【００１４】そこで、ノード１ＣのプロトコルＹもノー
ド１Ｂに対してサイズＮを要求する。ノード１Ａは、ノ
ード１ＣのプロトコルＸより要求されたサイズＭのパケ
ットを、ノード１Ｃに対して送信する（ステップＳ
３）。この時点で空き受信バッファサイズはゼロとな
る。ノード１Ｂは、ノード１ＣのプロトコルＹより要求
されたサイズＭのパケットをノード１Ｃに対して送信す
る（ステップＳ４）。この時点で空き受信バッファサイ
ズは−Ｍとなる。即ち、ノード１Ｂから創始されたパケ
ットは受信バッファに格納できないから、受け溢しが発
生する。

【００１５】これを回避するために、搭載するプロトコ
ル数分の受信バッファを準備し、それぞれのプロトコル
のフロー制御を独立に動作させる方法があるが、受信す
るプロトコルが偏って使用される環境があった場合、受
信バッファの効率が悪くなってしまう。

【００１６】例えば、５個のプロトコルを搭載している
ノードがあった場合、５個の受信バッファを設けるとす
る。その中の１〜２個のプロトコルのパケットをある時
間帯に集中して受信した場合、５個の受信バッファのう
ち、対応する受信バッファはいっぱいになり、受信不可
能という状態が発生する。しかし、受信バッファ全体と
しては半分以上の受信領域が空いていることになり、メ
モリ効率が非常に悪いシステムとなる。

【００１７】また、従来、最も古いデータの上に新しい
データを自動的に上書きして、効率のよい受信バッファ
として使用できる、リングバッファ方式のものがしられ
ている。しかし、このリングバッファは、バッファ内に
１パケットでも開放しないパケットが存在すると、以降
の受信ができなくなるため、そのパケットを、処理前に
他のバッファにコピーしなければならないという欠点が
ある。

【００１８】そこで、この具体例では、ネットワークか
らパケットを受信して処理する複数のアプリケーション
を順に登録して、パケットの受信順と、受信処理の起動
関数を管理するキューを設定する。このキューのカレン
トに登録されたアプリケーションが、パケットの受信処
理を終了すると、そのアプリケーションは、受信バッフ
ァを開放して、その時点でキューに対して次に登録して
あるアプリケーションの関数をコールしてカレントを受
け渡すとともに、カレントを受け渡したアプリケーショ
ンは、その後も確立したコネクションを切断しないで維
持する。以下、その実現のためのシステム構成等を順に
説明する。

【００１９】〈構成〉再び図１に戻って、この具体例の
システム構成を説明する。図１において、このシステム
は、例えばネットワーク２に接続されたプリンタ装置３
により構成されるものとする。このプリンタ装置３は、
同一ネットワーク内の低レベルのパケット送受信を担当
するＮＩＣ（ネットワークインタフェースチップNetwor
k I/F Chip H/W）４とそのＮＩＣをソフトウェア的に制
御するドライバ（ハードウェアドライバH/W Driver）５
を備える。

【００２０】また、その他に、ＮＩＣ４やドライバ５を
使用して端点ノード間の通信を制御するプロトコルスタ
ック６と、そのプロトコルスタック６を使用して、より
高度な通信機能を提供するアプリケーション７−１〜７
−２が設けられている。なお、このアプリケーションの
数は任意であるが、ここでは、４つを例示した。さら
に、それぞれのアプリケーションに対して、「印刷デー
タの受信順」と「印刷データの受信処理起動機会」とを
提供するためのキュー（カレントキューCurrentQueue）
１１を設けている。

【００２１】上記ＮＩＣ４は、ネットワーク機能を持つ
ノードをネットワークに接続し、パケットの送受信や、
受信パケットの簡単なエラー検知等を可能とするハード
ウェアである。ドライバ５は、ＮＩＣ４から受信パケッ
トを受け取り、プロトコルスタック６に渡したり、プロ
トコルスタック６から送信パケットを受け取り、ＮＩＣ
４に渡して送信要求をしたりする処理を行う部分であ
る。プロトコルスタック６は、上記パケット送受信用プ
ロトコルを実行する部分である。

【００２２】各アプリケーション７−１〜７−４は、通
常の動作部と印刷データ受信起動部（関数８−１〜８−
４）とから成る。キュー１１は、コネクション番号管理
部１２と、関数アドレス管理部１３とから成る。コネク
ション番号管理部１２は、コネクションを識別するため
のコネクション番号を登録して管理する部分である。関
数アドレス管理部１３は、各アプリケーションの受信起
動を制御するための印刷データ受信処理起動用関数８−
１〜８−４のアドレスを登録して管理する部分である。
なお、コネクション番号とは、他のノードとの各コネク
ションを各アプリケーションが識別・管理するために内
部的に割り振った識別番号である。

【００２３】〈動作〉図４と、図５と、図６とは、図１
のシステムの動作フローチャートを示す。まず、図４を
用いて、キュー１１に例えばアプリケーション７−２〜
７−４等が既に登録されて、処理待ち状態にある場合
の、アプリケーション７−１の動作について説明する。
アプリケーション７−１の通常処理部は、ＮＩＣ４を通
じて印刷パケットを受信した場合に、ステップＳ１から
ステップＳ２に進み、キュー１１の先頭に他のアプリケ
ーションが既に登録されているかを確認する。ここでは
キュー１１に既に４個の登録がある。そこで、キュー１
１を上から検索し、登録されている最後尾に自アプリケ
ーションを追加登録する。図では、コネクション番号
“０”を使用するアプリケーションが、キュー１１の先
頭に登録済みで、そのアプリケーションの持つ印刷デー
タ受信起動部（関数）のアドレスXXXXが登録されてい
る。登録位置がカレントの場合、即ち、ただちにその処
理を実行できる場合には、XXXXは登録の必要がない。

【００２４】図のキュー１１には、続いてコネクション
番号２を使用するアプリケーションの登録があり、コネ
クション番号５を使用するアプリケーションの登録があ
り、最後にコネクション番号６を使用するアプリケーシ
ョンの登録が完了した状態になっている。ここに、アプ
リケーション７−１がコネクション番号７で接続された
とする。この場合、対応する印刷データ受信起動部（関
数）のアドレス１２３４を、コネクション番号６を使用
するアプリケーションの登録の次に追加する（ステップ
Ｓ３）。

【００２５】また、ステップＳ１において印刷パケット
を受信しない待ち状態が継続する場合は、各アプリケー
ション固有の処理となり、これまでに確立したコネクシ
ョンを切断しないように保持するための対応を行う。キ
ュー１１のポインタは、キュー１１中でのカレントの位
置を示すポインタである。

【００２６】続いて、図５を用いてキュー１１に他のア
プリケーションからの登録が無い場合のアプリケーショ
ンの動作について説明する。アプリケーションの通常処
理部は、印刷パケットを受信した場合に、ステップＳ１
からステップＳ２に進み、キュー１１の先頭に既に他の
アプリケーションの登録があるかどうかを確認する。登
録がある場合には、キュー１１の先頭に自アプリケーシ
ョンが使用するコネクション番号を登録する。印刷デー
タ受信起動部（関数）アドレスは登録する必要はない
（ステップＳ３）。この操作によって最優先で受信・印
刷する権利であるカレントが獲得できたので、送信側の
ノードに対して印刷パケットの送信要求を発信し、印刷
データを全て受信する（ステップＳ４）。受信処理終了
後、キュー１１を参照して、自アプリケーションの登録
の次に他のアプリケーションの登録があるかどうかを確
認する（ステップＳ５）。

【００２７】登録がない場合には受信の後処理を行い処
理を終了する（ステップＳ８）。これで、１ジョブ分の
印刷処理が終了する。他のアプリケーションの登録があ
る場合は、キュー１１のポインタを次の登録位置に移動
し（ステップＳ６）、そのポインタの指す印刷データ受
信起動部（関数）のアドレスを参照しその関数をコール
する（ステップＳ７）。関数の処理内容は後から説明す
る。その後ステップＳ８に進み、受信の後処理を行い処
理を終了する。

【００２８】受信の後処理とは、受信処理終了後に各ア
プリケーションが行う受信終了処理のことで、受信時に
使用した作業領域の初期化、使用済で不要となったバッ
ファの開放、受信結果（ログ）の保存、受信パケットの
うちの、必要情報の抽出保存などである。

【００２９】さらに、図６（ａ）を用いて、カレントが
獲得できた後のアプリケーションの動作について説明す
る。アプリケーションは、キュー１１にそれ以前に登録
されていたアプリケーションの処理が終了してカレント
を獲得すると、印刷パケットを受信する（ステップＳ
１）。印刷起動は印刷データ受信起動部（関数）によっ
て既に掛けられている。印刷パケット受信が終了する
と、キュー１１の２番目に他のアプリケーションの登録
があるか確認する（ステップＳ２）。

【００３０】他のアプリケーションの登録がない場合は
受信の後処理を行い処理を終了する（ステップＳ５）。
他のアプリケーションの登録がある場合は、キュー１１
のポインタを次の登録位置に移動し（ステップＳ３）、
そのポインタの指す印刷データ受信起動部（関数）のア
ドレスを参照し、その関数をコールする（ステップＳ
４）。次にステップＳ５に進んで、受信の後処理を行い
処理を終了する。

【００３１】今度は、図６（ｂ）を用いて印刷データ受
信起動部（関数）の動作について説明する。印刷データ
受信起動部（関数）は、キュー１１に対して自アプリケ
ーションより１つ先に登録されたアプリケーションが受
信処理を終了すると、そのアプリケーションによる後処
理を行う前に、そのアプリケーションから関数コールさ
れて起動する。

【００３２】自アプリケーションがカレントになると、
自アプリケーションが使用しているコネクションを通じ
て送信元のノードに印刷データ送信要求を発信して処理
を終了する（ステップＳ１）。その後、印刷データの到
着は待たずに本関数のコール元にリターンする（ステッ
プＳ２）。即ち、印刷データ受信起動部（関数）を関数
コールしたアプリケーションは、その時点でキュー１１
に対して自アプリケーションの次に登録してあるアプリ
ケーションにカレントを受け渡したことになる。

【００３３】また、カレントを受け渡したアプリケーシ
ョンが、キュー１１の２番目以降に別のジョブを実行す
るための登録をしている場合には、送信ノードからの印
刷パケットの送信を一時的に停止させる。やむを得ない
場合を除き、コネクションは切断しないで接続状態を持
続させる。詳細な印刷データの停止方法、コネクション
の維持方法は各アプリケーションおよびアプリケーショ
ンが使用するプロトコルスタックによって異なる。この
時に、コネクションを維持させる目的で受信したパケッ
トやその他の目的で受信したパケットは、即時処理して
受信バッファを開放する。

【００３４】このことにより、カレントとなっているア
プリケーションは、受信バッファを最大限に使用でき、
そのシステムにおける最大の速度で印刷パケットを受信
することができる。即ち、カレントを受け渡したアプリ
ケーションが受信バッファを開放した後に次にカレント
を獲得したアプリケーションがその受信バッファを使用
した通信を開始するので、既に図３を用いて説明したよ
うな不具合は生じない。

【００３５】図７と図８に、処理時間短縮効果の説明図
を示す。図７において、ステップＳ１で、ノード１Ｃの
アプリケーション７−１は、ノード１Ａまたは１Ｂから
印刷パケットを受信する。ここで、一般的な方法により
アプリケーション７−１の受信後処理をしてから、ステ
ップＳ２で次のアプリケーション７−２が受信要求をす
る。こうして、次のアプリケーション７−２はアプリケ
ーション７−１が受信後処理を開始してからＴ１時間後
にパケットの受信を終了する。

【００３６】一方、図８において、ステップＳ１で、ノ
ード１Ｃのアプリケーション７−１は、ノード１Ａまた
は１Ｂから印刷パケットを受信する。ここでは、アプリ
ケーション７−１の受信後処理を開始する前に、ステッ
プＳ２で次のアプリケーション７−２が受信要求をす
る。従って、次のアプリケーション７−２はアプリケー
ション７−１が受信後処理を開始してからＴ２時間後に
パケットの受信を終了する。図７の場合と図８の場合と
を比較すると、アプリケーション７−２の受信要求到達
時間中にアプリケーション７−１の受信後処理を実行す
ることができるので、実質的に処理の受け渡しを高速化
できる。もちろん、アプリケーション７−２の受信要求
到達時間とアプリケーション７−１の受信後処理時間と
はいずれが長くても同様の効果がある。

【００３７】また、コネクションが確立したアプリケー
ションへの印刷要求はキュー１１に登録することにより
待ち行列に入り、コネクションは切断されないでそのま
ま維持されるという方法をとれば、送信元ノードの使用
者は、Windows95（Microsoft社の登録商標）のようなマ
ルチタスクタイプのＯＳ（オペレーティングシステム）
を使用している場合の操作性が良くなる。即ち、一度印
刷要求を出しておけば、プリンタから「使用中/BUSY」
の応答を受けにくくなる。従って、何度も送信依頼をす
る必要がなくなる。

【００３８】〈効果〉以上のように、具体例１によれ
ば、例えば、シングルタスクの様なシンプルなＯＳ上に
組み込みを行ったネットワークシステムにおいて、複数
のコネクションを同時に接続し、複数のアプリケーショ
ンからの印刷要求を、バッファを効率的に使用しながら
受け付けることができる。また、複雑なマルチタスクＯ
Ｓ上に組み込みを行ったネットワークシステムにおいて
は、より高速に複数アプリケーションからの印刷要求を
効率的に処理することができる。

【００３９】さらに、カレントを獲得したアプリケーシ
ョンへの印刷データ以外のパケットを、受信バッファ内
に保持しないように制御するので、バッファ使用効率も
最大となる。また、受信バッファ中のデータを別のバッ
ファにコピーするような操作性の悪いリングバッファを
使用する必要がなく、制御が容易になる。

【００４０】また、カレントでない待機中のアプリケー
ションは、受信したパケットを即時処理してメモリを開
放するので、カレントとなっているアプリケーションは
受信バッファを最大限に使用でき、そのシステムにおけ
る最大の速度でパケットを受信することができる。

【００４１】《具体例２》ネットワークに接続されてい
る各ノードがサポートする機能は多様になると、機能間
に処理の優先度差が生じることがある。例えば複数ノー
ドからのパケット受信が、受信側ノード自身の設定の参
照・変更等の要求であった場合、この要求は常に最優先
で処理されるべきである。こうした要求は、予告無く割
込み的に発せられるが、長時間応答を待たせることがで
きない。この場合にも上記の例と同様のフロー制御を行
うと、優先度の低い機能が動作してパケットを受信して
いる時には、受信バッファの空きが得られず、優先度の
高いパケットを受信できない場合が発生する。従来技術
では、機能間に優先度の差を付けるために、ＯＳの機能
を使用したり、優先度の低い機能に対して、優先度の高
い機能が動作を始めたら、処理を譲るように制御してい
る。しかし、この場合、高機能のＯＳが必要になり、処
理が複雑になる欠点がある。また、印刷要求に対し優先
度を考慮できるシステムの場合、低い優先度で印刷要求
を出した後、高い優先度の要求が多発した場合、低い優
先度の印刷が長時間待たされてしまう。

【００４２】そこで、この具体例では、キューに登録さ
れた優先度の低い処理を優先度の高い処理で置き換え、
この優先度の高い処理が終了したのち優先度の低い処理
を元の位置に再登録し直し、続いてこの優先度の低い処
理を実行する。優先度の高い処理を優先させるととも
に、一度後回しにされた優先度の低い処理は、再度後回
しにされることがない。以下に、その具体的な説明を行
う。

【００４３】〈構成〉システムの基本的な構成は、図１
に示した具体例１のシステムと同様である。図９には、
具体例２のキューの構造説明図を示す。この（ａ）に示
す例では、キュー２１は、コネクション番号管理部２２
と、関数アドレス管理部２３と、優先度フラグ管理部２
４とから成る。優先度フラグは、その登録に対し割り込
みを禁止する場合には“１”、割り込みを許す場合には
“０”という内容になるデータである。

【００４４】また、（ｂ）には、一時的にそれまでキュ
ー２１に登録されていた内容を保持しておくためのバッ
クアップエリア２５を示す。このバックアップエリア２
５も、キュー２１と同様に、コネクション番号管理部２
６と、関数アドレス管理部２７とを備える。優先度フラ
グを保持する必要はないから、優先度フラグ管理部は無
い。

【００４５】バックアップエリア２５は、優先度が高い
印刷要求によりオーバーラップされた優先度が低い印刷
要求の、キュー２１の登録内容を、一時的に退避させて
おく領域で、各アプリケーションが個々に持ち管理する
領域である。

【００４６】〈動作〉具体例１と同様に、プリンタ装置
への組み込みを例としてその動作の説明をする。図１０
は、具体例２のシステムの動作フローチャートを示す。
この図を使用して、優先度の高い印刷要求がホストから
送信されてきた場合のアプリケーションの処理を説明す
る。アプリケーションは、印刷パケットを受信すると
（ステップＳ１）、キュー２１のポインタが指すカレン
トに、他のアプリケーションの登録があるかどうかを確
認する（ステップＳ２）。カレントに登録がなければ、
現在何も印刷が行われていないので、優先度の高低は関
係無い。そこで、具体例１と同様にして、キュー２１の
カレント位置に自アプリケーションの登録を行う。

【００４７】キュー２１のポインタが指すカレントに他
のアプリケーションの登録がある場合は、受信した印刷
要求の優先度を確認する（ステップＳ３）。優先度が高
い場合はキュー２１のカレント位置からはじめて、登録
されている項目の優先度フラグを、登録順にチェックす
る。そして最初に優先度フラグが“０”である登録を見
つけたところで検索を終了する。そして、そこに登録さ
れたコネクション番号と印刷データ受信起動部（関数）
の先頭アドレスを、バックアップエリア２５にコピーす
る（ステップＳ４）。

【００４８】その後、キュー２１のコピー元の位置に、
自アプリケーションの登録を行う（ステップＳ５）。登
録内容は、コネクション番号、印刷データ受信起動部
（関数）の先頭アドレス、優先度フラグで、優先度フラ
グは固定値“１”を登録する。アプリケーションは、ホ
ストからの印刷データ送信を一時停止させた状態で処理
を終了する。

【００４９】図１０において、キュー２１のポインタが
指すカレントは、たとえ優先度が“０”であっても、優
先度の高い印刷要求の割り込みは行わない。もはや印刷
処理が開始されている可能性が大きいからである。ま
た、図の例では、キュー２１の２番目にコネクション番
号２のアプリケーションの登録があるが、優先度フラグ
が“１”で割り込みを禁止しているため、割り込みは行
わない。次のコネクション番号５の登録についても同様
である。

【００５０】その次にあるコネクション番号６の登録
は、優先度フラグ“０”となっており、割り込み可能で
あるため、この登録の前に割り込みをする。その手順
は、始めにコネクション番号０と印刷データ受信起動部
（関数）の先頭アドレス“oooo”を自アプリケーション
の持つバックアップエリア２５に退避する。

【００５１】自アプリケーションの使用するコネクショ
ン番号が９、印刷データ受信起動部（関数）の先頭アド
レスが“xxox”だとすると、キュー２１でコネクション
番号６が登録してあった場所にコネクション番号９を、
印刷データ受信起動部（関数）の先頭アドレス“oooo”
が登録してあった場所に“xxox”を、優先度フラグ０の
登録してあった場所に優先度フラグ１を上書きする。

【００５２】そして、具体例１で説明したように＠キュ
ー２１に登録してあるポインタが指すカレントのアプリ
ケーションの受信処理が終了し、ポインタがコネクショ
ン番号２番のアプリケーションに移り、その受信処理が
終了すると、コネクション番号５番の処理に移る。コネ
クション番号５番の受信処理が終了すると、コネクショ
ン番号５番を使用するアプリケーションは次の登録へポ
インタを移すために、印刷データ受信起動部（関数）の
先頭アドレス“xxox”を参照して、その関数をコールす
る。

【００５３】次は、割り込みを行ったアプリケーション
がキュー２１に入っているので、コネクション番号５番
のアプリケーションが関数コールする印刷データ受信起
動部（関数）の先頭アドレスは“xxox”である。先頭ア
ドレス“xxox”の印刷データ受信起動部（関数）は、割
り込みを行ったコネクション番号９番を使用するアプリ
ケーションへの受信を起動する。

【００５４】図１１には、具体例２のシステム動作フロ
ーチャート（その２）を示す。この図を使用して、割り
込みをした印刷処理が終了した場合のアプリケーション
の処理を説明する。割り込みを行ったアプリケーション
はステップＳ１で印刷パケットの受信を終了すると、自
アプリケーションが持つバックアップエリア２５を確認
する（ステップＳ２）。バックアップエリア２５に、退
避されている登録がある場合にはその登録内容をキュー
２１の自アプリケーションの登録位置に戻す（ステップ
Ｓ３）。図では、バックアップエリア２５に退避されて
いるコネクション番号６と、印刷データ受信起動部（関
数）の先頭アドレス“oooo”を、キュー２１のポインタ
が指す位置のコネクション番号９と、印刷データ受信起
動部（関数）の先頭アドレス“xxox”が登録されている
場所にコピーする。その後バックアップエリア２５の内
容は消去する。

【００５５】次にカレントにするのは、バックアップエ
リア２５から戻したアプリケーションである。キュー２
１のポインタは、次の登録位置へ移さず、そのままにし
ておく。そしてカレント位置に戻した印刷データ受信起
動部（関数）の先頭アドレス“oooo”を関数コールする
（ステップＳ）。バックアップエリア２５に登録が無く
なれば、ステップＳ２からステップＳ６に進み具体例１
と同様の処理をする。その後のステップＳ５の処理も具
体例１と同様である。

【００５６】〈効果〉以上詳細に説明したように、この
具体例によれば、フロー制御を目的とする具体例１のキ
ューに、優先度を示すフラグ領域を設定して、優先度を
考慮した印刷処理を実現することができる。また、従来
の優先度を考慮した印刷処理では、優先度の低い印刷要
求に対し優先度の高い要求が殺到すると優先度の低い処
理が完全に停止してしまい、長時間印刷されないという
問題点があったが、この具体例によると、割り込まれた
優先度低の処理は、必ず割り込んだ処理の後に実行され
るため、優先度の低い印刷処理が長時間停止することは
なくなる。

【００５７】《具体例３》これまでの具体例では、カレ
ントのアプリケーションにバッファを最大限度まで使用
させた。一方、この具体例では、サポートするアプリケ
ーションの種類を優先度の高いアプリケーショングルー
プ（管理系アプリケーション）と優先度の低いアプリケ
ーショングループ（印刷系アプリケーション）とに分類
し、受信バッファ中に、管理系アプリケーションが使用
可能な容量の限界値BUFLIMIT_ADMIN（管理系用限界値）
と、 BUFLIMIT_PRINT（印刷系用限界値）を設ける。こ
れにより、最優先で処理すべき管理系アプリケーション
の処理のために、受信バッファに所定の空き領域が確保
できる。また、上記管理系限界値と印刷系限界値を動的
に変化させれば、管理系アプリケーションと印刷系アプ
リケーションの処理速度を、状況に応じて最適化でき
る。

【００５８】〈構成〉具体例３も、基本的に具体例１と
同一のシステム構成とし、以下の機能を追加する。図１
２には、具体例２による受信バッファの説明図を示す。
図に示すように、この具体例では、受信バッファ３１
に、パケット受信時の印刷系用限界値BUFLIMIT_PRINTと
管理系用限界値BUFLIMIT_ADMINを設定し、ＲＡＭ上にこ
の値を保持する領域を追加する。さらに、印刷系用限界
値BUFLIMIT_PRINTと管理系用限界値BUFLIMIT_ADMINを動
的に計算するためのワーキングエリアＡをＲＡＭ上に設
ける。ここには、管理系使用頻度係数を格納する。ワー
キングエリアＢについては、具体例４で説明する。

【００５９】〈動作〉これも具体例１と同様に、プリン
タ装置への組み込みを例とする。具体例１では、プリン
タがサポートするプロトコルの全てが印刷データを受信
することを目的とするアプリケーションであり、具体例
１は、同じプライオリティを持つプロトコル同士が複数
動作する場合のフロー制御である。この具体例では、プ
リンタの設定内容を参照したり、変更したり、印刷状況
の参照等を行うことを目的とするような、管理系アプリ
ケーションを、印刷系のアプリケーションと同時にサポ
ートする場合のフロー制御方法について説明する。

【００６０】管理系のアプリケーションは、使用者から
の設定内容の参照・変更といった要求コマンドに対し、
実行中の処理（印刷系アプリケーションの印刷データ受
信）の有無に関係無く即時に応答処理を実行しなければ
ならないと言う点が特徴である。具体例１では、受信バ
ッファ全てを印刷系アプリケーションの使用対象とし、
受信バッファの空き容量を、送信側への送信量リクエス
トサイズとして使用している。本具体例では、図１２に
示したように、２種類の限界値をＲＡＭ上に設定する。

【００６１】印刷系用限界値BUFLIMIT_PRINTは、印刷系
のアプリケーションが送信側への送信量リクエストサイ
ズとして使用する値の最大値である。受信バッファ内に
格納されているパケット容量が、全アプリケーション合
計で印刷系用限界値BUFLIMIT_PRINTよりも少ない場合の
み、印刷系アプリケーションが送信側に対しパケットの
送信を要求することができる。具体例１で説明した方法
と同様に、送信側へのパケットの要求サイズは、印刷系
用限界値BUFLIMIT_PRINTから現在の受信バッファの使用
量を引いた値となる。

【００６２】管理系用限界値BUFLIMIT_ADMINは、管理系
のアプリケーションが次の要求コマンドを受け付けるこ
とができる受信バッファサイズの最大値である。管理系
アプリケーションは、受信バッファ内に格納されている
パケット容量が全アプリケーション合計で管理系用限界
値BUFLIMIT_ADMINよりも少ない場合に、使用者からの要
求コマンドを受信できることを使用者へ通知する。

【００６３】印刷系アプリケーションの受信限界である
BUFLIMIT_PRINTを、管理系アプリケーションの受信限界
であるBUFLIMIT_ADMINよりも小さい値に取れば、管理系
アプリケーションの処理優先度を印刷系アプリケーショ
ンの処理優先度よりも高めることができる。即ち、２つ
の限界値の関係式は、BUFLIMIT_ADMIN > BUFLIMIT_PRIN
Tとなることが好ましい。

【００６４】さらに、プリンタ動作中に上記２つの限界
値を動的に変化させることにより、管理系アプリケーシ
ョンと印刷系アプリケーションの最適な動作関係を実現
できる。

【００６５】図１３には、コネクション数に応じた限界
値の設定例説明図を示す。図には、管理系用限界値BUFL
IMIT_ADMINと印刷系用限界値BUFLIMIT_PRINTの差（変数
Ａ）を、例示した。この値は、管理系アプリケーション
のコネクションの最大数Ｎと受信バッファ容量Ｇとの関
数で表している。

【００６６】図１４に、具体例３のシステムの動作フロ
ーチャートを示す。まず、一定時間内に受信したBroadc
astパケットや、Multicastパケットの合計パケットサイ
ズを算出して、ＲＡＭ上の変数Bに代入する（ステップ
Ｓ１）。次に受信バッファの全体サイズからステップＳ
１で求めた変数Bの値を減算し、限界値BUFLIMIT_ADMIN
を求めて、ＲＡＭ上の変数BUFLIMIT_ADMINに格納する
（ステップＳ２）。続いて管理系アプリケーションが使
用するコネクション数に応じて、図１３に示す値を変数
Ａに代入する（ステップＳ３）。コネクション数が
“０”の時には、１００Byteの余裕をとり、管理系アプ
リケーションのコネクションの確立ができるようにす
る。最後に、ステップＳ２で求めた限界値BUFLIMIT_ADM
INからステップＳ３で求めた変数Ａの値を減算し、ＲＡ
Ｍ上の変数BUFLIMIT_PRINTに格納する（ステップＳ
４）。

【００６７】以上の手順により、管理系用限界値BUFLIM
IT_ADMINと印刷系用限界値BUFLIMIT_PRINTを動的に決定
する。上記ステップＳ１で求めた変数Ｂの内容は、具体
例４の中で説明するため詳細を割愛する。変数Ｂを用い
ない場合は、管理系用限界値BUFLIMIT_ADMINは受信バッ
ファサイズと同じになる。

【００６８】〈効果〉以上詳細に説明したように、具体
例３によれば、受信バッファ中に、印刷系アプリケーシ
ョンの受信限界値と管理系アプリケーションの限界値を
設定し、それを動的に変更することにより、印刷系アプ
リケーションからのパケット受信中であっても、変数Ａ
で設定した部分を使用して、管理系アプリケーションか
らの要求コマンドを処理し応答を返すことができる。ま
た、管理系アプリケーションを使用しない場合も受信バ
ッファを無駄に空けて置くことをせずに、効率的に使用
することができる。

【００６９】《具体例４》この具体例では、一定時間毎
に受信したパケット中のブロードキャスト（Broadcas
t）パケットとマルチキャスト（Multicast）パケットの
サイズを全て加算した合計サイズを求め、その合計サイ
ズに相当する記憶領域分（変数Ｂ）を受信バッファから
差し引いて、パケット受信用の空きバッファ領域にす
る。

【００７０】この具体例も、基本的に具体例１と同様の
システム構成をし、その追加部分を以下に説明する。〈動作〉ここでも、具体例１と同様に、プリンタ装置へ
の組み込みを例とする。具体例１では、受信バッファ全
てを印刷系アプリケーションが使用対象とし、受信バッ
ファの空き容量を送信側への送信量リクエストサイズと
して使用している。この具体例では、図１２に示したよ
うに、受信バッファ中に、受信可能であると送信側に通
知しない領域（変数Ｂで示す領域）を取る。上記変数Ｂ
について次に説明する。

【００７１】一般的に、ネットワークの回線上を流れる
パケットは、以下の３種類に分類することができる。（１）自分宛てのパケット（２）自分以外宛てのパケット（３）自分を含めた集団宛てのパケット（全部へ送るこ
とを目的としたパケットを含む）変数Ｂ（ノイズ係数）は、一定時間内に回線上に流れる
（３）のパケットの総データ量（総バイト数）を示して
いる。

【００７２】ネットワークに対してある機器を接続する
ためには、ネットワークインタフェースチップNetwork
Interface Chip（ＮＩＣ）と呼ばれるH/W（ハードウェ
ア）が必要になるが、このH/Wは上記パケットの分類で
は（１）と（３）のパケットを受信する。印刷データや
管理用要求コマンドは、上記パケットの分類では（１）
であるから、特別な機能を持つアプリケーションをサポ
ートしない限り、分類（３）に該当するものは受信パケ
ット中のノイズであると言える。

【００７３】この具体例では、ノイズパケットを一定時
間毎モニタリングして、一定時間毎にノイズ係数を算出
する。具体例３の制御では、管理系用限界値BUFLIMIT_A
DMINは、受信バッファサイズと同じになり、管理系アプ
リケーションは、受信バッファの全空き容量を常に要求
する。しかし、回線上を流れるパケットで受信側のＮＩ
Ｃが受信するパケットが一時的に受信バッファを広く使
用すると、印刷系アプリケーションが送信側に通知した
受信バッファ量が確保できず、受信されたパケットの一
部を受け溢してしまうこともある。受け溢したパケット
は再送が発生し、ネットワーク中で無駄なパケットの転
送を増加させることになる。

【００７４】図１５は、具体例４のシステム動作フロー
チャートである。これにより、ノイズ係数の算出方法を
説明する。まず、ＮＩＣが１パケットを受信する（ステ
ップＳ１）。ＮＩＣは受信したことをＮＩＣを制御する
ファームウェアに通知する。ＮＩＣを制御するファーム
ウェアは、受信したパケットがBroadcast（全体宛ての
パケット）か、Multicast（自分を含む集団宛てのパケ
ット）かあるいはそれ以外のパケットかを判断する（ス
テップＳ２）。BroadcastかあるいはMulticastのいずれ
かのパケットであれば、受信したパケットのサイズをＲ
ＡＭ上に確保した作業用領域である変数Ｃに加算する
（ステップＳ３）。そうでない場合は、変数Ｃには加算
しない。以上のステップＳ１からステップＳ３までの処
理を一定時間繰り返し、一定時間経過後変数Ｃの値をノ
イズ係数である変数Ｂに代入する。変数Ｃには“０”を
代入して初期化する。以上の手順によりノイズ係数を一
定時間毎に随時算出する。

【００７５】こうして算出したノイズ係数に相当する分
をバッファ上に確保して、これを管理系アプリケーショ
ンが使用する。残りの部分を印刷系アプリケーションが
使用する。これにより、受信バッファの割り当てを最適
化する。一般のネットワークのパケット流通量は、ネッ
トワークのサイズが大きくなる程変化が緩くなるため、
ノイズ係数を更新する時間間隔は、接続するネットワー
クのサイズにより可変とすることが望ましい。ノイズ係
数を更新する時間間隔を固定してもよい。実験によれ
ば、その時間間隔は２秒程度が効率が良いことがわかっ
た。

【００７６】〈効果〉以上詳細に説明したように、具体
例４によれば、受信バッファ中にノイズ係数分の空き容
量を設定して管理系アプリケーションのために確保し、
それ以外の部分を印刷系アプリケーションが使用するの
で、回線上を流れるBroadcastパケットやMulticastパケ
ットに影響されずに円滑な受信のフロー制御を行うこと
ができる。また受信バッファの割り当てを最適化するの
で、パケットの再送が起こりにくくなり、使用者が実行
した管理アプリケーション等へのレスポンスが早くなる
という効果がある。さらに、それを動的に変更すること
により、状況に応じた、受信バッファ利用の最適化を図
ることができる。

【図面の簡単な説明】

【図１】具体例１のシステムブロック図である。

【図２】複数のプロトコルを搭載したシステムの説明図
である。

【図３】一般的なシステムの動作シーケンスである。

【図４】図１のシステムの動作フローチャート（その
１）である。

【図５】図１のシステムの動作フローチャート（その
２）である。

【図６】図１のシステムの動作フローチャート（その
３）である。

【図７】処理時間短縮効果の説明図（その１）である。

【図８】処理時間短縮効果の説明図（その２）である。

【図９】具体例２のキュー構造説明図である。

【図１０】具体例２のシステムの動作フローチャート
（その１）である。

【図１１】具体例２のシステムの動作フローチャート
（その２）である。

【図１２】具体例３による受信バッファの説明図であ
る。

【図１３】コネクション数に応じた限界値の設定例説明
図である。

【図１４】具体例３のシステムの動作フローチャートで
ある。

【図１５】具体例４のシステム動作フローチャートであ
る。

【符号の説明】

２ネットワーク３プリンタ装置４ＮＩＣ（ネットワークインタフェースチップNetwor
k I/F Chip H/W）５ドライバ（ハードウェアドライバH/W Driver）６プロトコルスタック７−１〜７−２アプリケーション１１キュー（カレントキューCurrent Queue）

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号ＦＩＨ０４Ｌ 29/06 Ｈ０４Ｌ 13/00 ３０５Ｚ

Claims

【特許請求の範囲】

【請求項１】複数のネットワークプロトコルをサポー
トするシステムにおいて、ネットワークからパケットを受信して処理する複数のア
プリケーションを順に登録して、前記パケットの受信順
と、受信処理の起動関数を管理するキューを設定し、このキューのカレントに登録されたアプリケーション
が、前記パケットの受信処理を終了すると、そのアプリ
ケーションは、受信バッファを開放して、その時点でキ
ューに対して次に登録してあるアプリケーションの関数
をコールしてカレントを受け渡すことを特徴とするフロ
ー制御方法。
【請求項２】請求項１に記載のフロー制御方法におい
て、カレントを受け渡したアプリケーションは、その後も確
立したコネクションを切断しないで維持することを特徴
とするフロー制御方法。
【請求項３】請求項１に記載のフロー制御方法におい
て、キューに登録された優先度の低い処理を優先度の高い処
理で置き換え、この優先度の高い処理が終了したのち優先度の低い処理
を元の位置に再登録し直し、続いてこの優先度の低い処
理を実行することを特徴とするフロー制御方法。
【請求項４】請求項１に記載のフロー制御方法におい
て、サポートするアプリケーションの種類を優先度の高いア
プリケーショングループと優先度の低いアプリケーショ
ングループとに分類し、優先度の高いアプリケーション
グループが使用可能な容量の限界値を、優先度の低いア
プリケーショングループが使用可能な容量の限界値より
大きくなるように、受信バッファの容量を設定して、そ
の限界値を、コネクション数に応じて動的に変更するこ
とを特徴とするフロー制御方法。
【請求項５】請求項１に記載のフロー制御方法におい
て、一定時間毎に受信したパケット中のブロードキャスト
（Broadcast）パケットとマルチキャスト（Multicast）
パケットのサイズを全て加算した合計サイズを求め、そ
の合計サイズに相当する記憶領域分を受信バッファから
差し引いて、パケット受信用の空きバッファ領域にする
ことを特徴とするフロー制御方法。