JPH10155010A - パケット処理方法とネットワ−クア−キテクチャ - Google Patents

Abstract

(57)【要約】 【目的】 ネットワ−クア−キテクチャに組み込まれる
ネットワ−ク層／トランスポ−ト層の負荷を軽減し、よ
り効率良く動作するパケット処理方法とネットワ−クア
−キテクチャとを提供する。 【構成】 ネットワ−クからノ−ドの受信バッファ５ａ
にパケットを受信し、応答パケットをネットワ−クに送
信するＮＩＣ（Network Interface Controller）３と、
一定時間毎に入るタイマ割込みを使用し、割込み時間内
に受信バッファ５ａに受信される全パケットのネットワ
−ク層とトランスポ−ト層とに関するプロトコルを１回
の起動で一括処理し、それぞれのコネクションに属する
最後の受信パケットに対する応答パケットを割込み中に
ネットワ−クに一括して送信するＴＣＰ／ＩＰ部５とを
備える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はネットワ−クのノ−
ド間にコネクションを確立し、受信バッファに受信した
パケットに階層的に付加されたプロトコルを下位層から
上位層に向かって順に処理するパケット処理方法とネッ
トワ−クア−キテクチャとに関する。

【０００２】

【従来の技術】従来、ネットワ−クのノ−ドに組込まれ
るＯＳＩ(Open System Interconnection) 環境の標準ネ
ットワ−クア−キテクチャは、プロトコルを階層的に並
べた構造を採っており、ＩＳＯ(International Organi
zation for Standardization)等により、各層の位置付
けや、機能、層間のインタフェースなどが細かく規定さ
れている。

【０００３】ＩＳＯが規定したＯＳＩ参照モデルには、
下位から物理層、デ−タリンク層、ネットワ−ク層、ト
ランスポ−ト層、セッション層、プレゼンテ−ション
層、アプリケ−ション層の７層構造になっている。

【０００４】ネットワ−クに送り出されるパケット形式
のデ−タには、それぞれ、各層に関する制御情報である
プロトコルがヘッダとして付加されており、各ノ−ドの
ネットワ−クア−キテクチャはネットワ−クからパケッ
トを受信してパケットのヘッッダに階層的に含まれるプ
ロトコルを各層で順次処理してパケットに含まれるデ−
タをデ−タバッファに格納するとともに、受信パケット
に対する応答パケットをネットワ−クに送信する。

【０００５】例えば、インタ−ネットプロトコル層（以
後ＩＰと記す）はネットワ−ク層に位置し、主に一つ又
は複数の通信網を介して中継を行い、始点となるノード
から終点となるノードまでのデータ通信を行う。

【０００６】また、ＩＰの上位層（トランスポ−ト層）
としてのトランスファコントロ−ルプロトコル層（以後
ＴＣＰと記す）は、経路選択や中継機能に関与せず、始
点及び終点となるノードのさらに終端間における透過的
な両方向同時転送機能を提供する。

【０００７】ＴＣＰをネットワ−クア−キテクチャに組
込むには、一つのコネクション（デ−タを転送するため
の論理的な通信路）に対する処理を一つのＴＣＰタスク
で行せるようにし、Ｎ個のコネクションに対して（Ｎ＋
１）個のＴＣＰタスクを起動させる。ＴＣＰタスクの残
りの一つはマスタとして次のコネクションの確立用とし
て待機している。

【０００８】ＩＰは、１つのタスクが、受信した受信パ
ケットのヘッダ処理を順次処理して対応するＴＣＰタス
クを識別し、待機しているＴＣＰタスクに預けていく処
理を行っている。よって確立するコネクション数とは関
係なく常に１つのタスクとして存在する。

【０００９】各ＴＣＰタスクはそれぞれコネクションを
確立したクライアントタスクから受信した受信パケット
を処理し、相手のクライアントタスクに応答パケットを
送信する。このとき送信する応答パケットはただ一つ存
在するＩＰタスクを通る必要があるため、各ＴＣＰタス
クはＩＰタスクの使用権を獲得する。

【００１０】ＩＰタスクはＴＣＰタスクまたはデータリ
ンク層タスクからの呼び出し（以後ＰＯＳＴと記す）を
待つ。ＰＯＳＴとは、マルチタスク環境下のタスク間で
処理を移行する時に使用するオペレ−ションシステム
（以後ＯＳと記す）のシステムコールである。

【００１１】ここで、簡単にＩＰタスクとＴＣＰタスク
との動作を説明する。データリンク層タスクは、クライ
アントより最初のパケットを受信すると、そのヘッダか
らＩＰタスクを識別し、待機しているＩＰタスクに対し
てＰＯＳＴを行う。

【００１２】ＩＰタスクは受信パケットのヘッダからネ
ットワ−ク層に関するプロトコル処理を行い、ヘッダか
らＴＣＰタスクを識別し、待機しているＴＣＰマスタタ
スクに対してＰＯＳＴを行う。

【００１３】ＴＣＰマスタタスクは受信パケットの内容
がコネクションの開設要求と判断すると、パケットを処
理し、クライアントに対して応答パケットを送信する。
通常クライアントからの最初のパケットはコネクション
の開設を要求するパケットなので、クライアントへ応答
パケットを送信した後はタイマを動作させてスリ−ウェ
イハンドシェークの最後のパケットを待つ。

【００１４】ＴＣＰマスタタスクは、タイマアップする
前にクライアントからハンドシェークパケットを受信す
ると、コネクションの確立を認識する。また、コネクシ
ョン確立後の受信パケットがセッション層以上のサービ
スの要求がある場合には、新たにマスタタスクを生成し
ＰＯＳＴを行う。本例では、ＦＴＰ（File TransferPro
tocol）マスタタスクを起動する。

【００１５】ＦＴＰマスタタスクは、クライアントとの
間に制御コネクションを確立すると、fork()関数を用い
自分自身のコピー（ＦＴＰタスク）を作成する。ＦＴＰ
タスクは、ＴＣＰマスタタスクに対してポートの割り当
てを行う。

【００１６】ＴＣＰマスタタスクは、fork()関数を用い
自分自身のコピー（ＴＣＰタスク）を作成する。ＴＣＰ
タスクは、ＦＴＰタスクとの間にデ−タコネクションを
確立し、以後クライアントから切断されるまでそのコネ
クションを管理する。

【００１７】ＴＣＰマスタタスクは次のクライアントか
らのコネクションの開設要求に備えて待ち状態となる。

【００１８】他方、ＴＣＰタスクはパケットの受信毎に
トランスポート層の処理を行い、ＦＴＰタスクに対して
ＰＯＳＴを行う。ＦＴＰタスクは、ＴＣＰタスクから受
信したデータを受け取り、データ中に含まれるクライア
ントからのコマンドを実行する。

【００１９】以上説明した組込み処理は、完全にプリエ
ンプティブに動作するラウンドロビン方式のＯＳの組込
みを前提としている。

【００２０】

【発明が解決しようとする課題】従来のネットワ−クア
−キテクチャにあっては、複数のコネクションをそれと
同数のＴＣＰタスクで処理するため、コネクションを処
理するプロセスを動的に複数コピーする機能（上述した
fork()関数) が必要となる。この機能は１つのプログラ
ムを複数のタスクで共有し実行させるため、タスク間の
同期を取るラウンドロビン方式の完全にプリエンプティ
ブに動作する高機能なＯＳを必要とするという問題点が
あった。

【００２１】また、各層のプロトコル処理を別々のタス
クとして動作させるとともに、トランスポート層以上の
タスクはコネクションの確立に応じてタスクがコピーさ
れるので、ＯＳ上で動作するタスクの数が増え、ＯＳの
オーバヘッド量が増加するという問題点もあった。

【００２２】また、プロトコル処理における各プロセス
をすべて別々のタスクが行うことにより、メモリ上の作
業領域が増大するという問題点もあった。

【００２３】本発明はネットワ−クア−キテクチャに組
み込まれるネットワ−ク層／トランスポ−ト層の負荷を
軽減し、より効率良く動作するパケット処理方法とネッ
トワークア−キテクチャとを提供することを目的とす
る。

【００２４】

【課題を解決するための手段】上記目的を達成するため
に本発明のネットワ−クア−キテクチャにおいては、一
定時間毎に入るタイマ割込みを使用し、受信バッファに
受信されたパケットのネットワ−ク層とトランスポ−ト
層とに関するプロトコルを割込み中に一括処理して蓄積
し、プロトコルの内容から上位層のプロトコル処理手段
を指定通知する受信パケット一括処理手段と、それぞれ
のコネクションに属する最後の受信パケットに対する応
答パケットを割込み中にネットワ−クに一括して送信す
る送信パケット一括処理手段とを備える。

【００２５】また、同じ目的を達成するために本発明の
パケット処理方法においては、少なくともネットワ−ク
層、トランスポ−ト層、セッション層、プレゼンテ−シ
ョン層、アプリケ−ション層に関するプロトコルの処理
をそれぞれ一つのタスクにし、ネットワ−ク層、トラン
スポ−ト層を一つの機能とし、セッション層、プレゼン
テ−ション層、アプリケ−ション層を一つの機能とし、
その機能に処理の優先度を持たせて動作するパケット処
理方法とし、具体的手段として、メッセ−ジに基づいて
呼び出した処理手段に起動を駆けるオペレ−ティングシ
ステム機能によるメッセ−ジ処理手段と、メッセ−ジ処
理手段により呼び出されて受信バッファから受信パケッ
トを取り出し、少なくともネットワ−ク層、トランスポ
−ト層に関するプロトコルを処理して所定量に達するま
で蓄積する第１のパケット処理手段と、セッション層、
プレゼンテ−ション層、アプリケ−ション層に関するプ
ロトコルを処理して上位層に出力する第２のパケット処
理手段と、第１のパケット処理手段から指定された第２
のパケット処理手段を呼び出すメッセ−ジをメッセ−ジ
処理手段に出力するとともに上位側待ち行列に登録し、
メッセ−ジ処理手段からの呼び出しに応じて上位側待ち
行列を参照し、第２のパケット処理手段を呼び出すソケ
ット処理手段とを備える。

【００２６】

【発明の実施の形態】本発明の実施の形態について図面
を参照しながら説明する。尚、各図面に共通な要素には
同一符号を付す。第１の実施の形態 図１は第１の実施の形態によるプリンタのネットワ−ク
ア−キテクチャを示すブロック図であり、単一な中央処
理装置１（以後ＣＰＵ１と記す）上で動作する割込み処
理及びタスクを示す。

【００２７】尚、ノ−ドとして、図２に示すように、対
象を回線に接続されたネットワ−クプリンタ２（以後プ
リンタ２と記す）にしぼり説明する。

【００２８】ネットワ−クア−キテクチャは、ネットワ
−ク接続用ハ−ドウェアとしてのＮＩＣ（Network Inte
rface Controller）３と、トランスポ−ト層及びネット
ワ−ク層のプロトコル処理手段としてのＴＣＰ／ＩＰ部
４と、クライアントとのデータの送受信を制御し、メモ
リ５上に割り当てられた受信バッファ５ａを管理するＩ
ＦＣタスク６とからなる。

【００２９】ＮＩＣ３はネットワ−クからのパケットの
受信時に起動し、ＣＰＵ１に割り込みをかけて受信パケ
ットを受信バッファ５に受信し、受信パケットに対する
応答パケット等を送信する時に使用される。

【００３０】ＴＣＰ／ＩＰ部４はタイマ割り込み時に起
動し、割り込み時間内に受信バッファ５に受信されてあ
る受信パケットのネットワ−ク層とトランスポ−ト層と
に関するプロトコル処理を一括処理してメモリ５上に割
り当てられた受信パケット一時バッファ５ｂに格納して
ＩＦＣ（Interface Control ）タスク６にＰＯＳＴを行
う受信パケット一括処理手段４ａと、メモリ５上に割り
当てられた送信待ちバッファ５ｃに格納されてある応答
パケット等を割り込み時間内にネットワ−クに送信する
送信パケット一括処理手段４ｂとが設けてある。ＴＣＰ
／ＩＰ部４は、ＴＣＰとＩＰとを別タスクとせず一つの
タスクとして動作する。

【００３１】ＩＦＣタスク６は、ＴＣＰ／ＩＰ部４によ
り指定された通信アプリケーションを識別する通信アプ
リケーション識別部８と、受信パケットのセッション
層、プレゼンテ−ション層、アプリケ−ション層に関す
るプロトコルを処理する通信アプリケーション群９と、
受信パケットに含まれる受信デ−タを通信アプリケーシ
ョン群９から入力して印刷部１０に出力する入出力管理
部１１とからなる。

【００３２】図３は図１に示したネットワ−クア−キテ
クチャの処理時のタイムチャ−トである。ＴＣＰ／ＩＰ
部４は時間ｔ経過する毎にタイマ割り込みに入るように
設定されており、割り込み時間内にＴＣＰ／ＩＰ部４の
プロトコル処理を行う。時間ｔは割り込み処理時間に比
べて大きく設定されてあり、ＴＣＰ／ＩＰ部４が割り込
み処理を終了するとＰＯＳＴを行い、以後、次のタイマ
割り込みに入るまでＮＩＣ３によるパケット送受信処
理、ＩＦＣタスク６によるパケット処理、印刷部１０に
よる印刷処理等が行われる。

【００３３】ＴＣＰ／ＩＰ部４はタイマ割り込みにより
起動すると、受信バッファ５に受信済みの全パケットを
割り込み時間内に処理し、最後のパケットに対する応答
パケットを作成して送信待ちバッファ７ｂに格納する。
たとえば、受信バッファ５にクライアントＡから３つの
パケットＡ1 〜Ａ3 を受信してあるとすると、１回のタ
イマ割り込み処理で３つのパケットＡ1 〜Ａ3 を処理
し、パケットＡ3 に対する応答パケットを作成して送信
待ちバッファ７ｂに格納する。

【００３４】また、複数のクライアントからパケットを
受信した場合にも同様に、各クライアントから受信した
最後のパケットに対して応答パケットを作成して送信待
ちバッファ７ｂに格納する。つまり、クライアントＡか
ら３つのパケットＡ1 〜Ａ3を、クライアントＢから１
つのパケットＢ1 を、クライアントＣから２つのパケッ
トＣ1 、Ｃ2 を受信バッファ５に受信していた場合、Ｔ
ＣＰ／ＩＰ部４は、クライアントＡにはパケットＡ3 に
対する応答パケットを、クライアントＢにはパケットＢ
1 に対する応答パケットを、クライアントＣにはパケッ
トＣ2 に対する応答パケットをそれぞれ作成して送信待
ちバッファ７ｂに格納する。

【００３５】送信処理はＮＩＣ３に対して送信に必要な
情報をセットする前処理、ＮＩＣ３が行う送信処理、送
信完了後行う後処理からなる。

【００３６】送信パタ−ンの１つ目は、ＴＰＣ／ＩＰ部
４から応答される場合で、ＴＰＣ／ＩＰ部４とのコネク
ション確立シーケンス時の応答、デ−タパケットに対す
る応答、ARP(Address Resolution Protocol)における物
理アドレスの問い合わせに対する応答等、受信パケット
を受信した直後に発生する送信処理であり、上述したタ
イマ割り込み処理中に行う。

【００３７】即ち、データパケットのストリームに対す
る単なる応答である場合には、上述した通りに直ちに送
信を行わず、受信済みの全パケットの処理が終了した後
に応答パケットを作成する。その他の応答の場合には、
直ちに送信用のパケットを作成して送信待ちバッファ７
ｂに格納し、タイマ割り込み処理の最後にまとめて送信
要求をＮＩＣ３に出す。

【００３８】こうすることにより、送信パケットに対す
る応答を受信するまでのタイムアウト時間( ターンアラ
ウンド時間) を一括に管理する（以後Ｍａｘ Ｔｉｍｅ
ｏｕｔ処理と記す）ことができ、タイムアウト処理にか
かる負荷が減少する。

【００３９】本実施の形態によるア−キテクチャ組込み
におけるタイマ処理は、各コネクションを管理する情報
とともにタイマ情報をグローバルテーブルとして管理す
る。送信パケットのタイムアウト値、タイムアウトカウ
ンタ等をテーブル中に保存し、タイマ割り込み中でカウ
ンタをデクリメントし、タイマ割り込みの入る回数でタ
イムアウト時間を管理する。タイムアウト値はＴＣＰ／
ＩＰ部４のタイマ割り込みが入る時間ｔの倍数で定義
し、ｔの倍数単位の増減を行う。

【００４０】送信パターンの２つ目として、印刷部１０
のプリンタファームウェアや通信アプリケーション群９
の通信アプリケーション等から任意の時間に発生する送
信処理がある。

【００４１】従来のア−キテクチャ組込みによる送信で
は、ＴＣＰタスク及びＩＰタスクは、ＩＦＣタスク６か
ら送信要求を受けると、図４（Ａ）に示すように、直ち
に送信処理を行い、ＮＩＣ３へ送信処理を要求した。

【００４２】しかし、アプリケーションの送信では、タ
イムアウトが存在しないか、存在しても非常に長いので
緊急に送信する必要はない。従って、本発明ではＩＦＣ
タスク６の送信要求を一定時間蓄積し、一括して送信す
る方法を採る。

【００４３】通信アプリケーション関数内及びプリンタ
ファームウェア内で送信要求が発生すると、通信アプリ
ケーション関数が、特定のテーブルに対して送信要求を
書き込む。実際の送信は、図４（Ｂ）に示すように、Ｔ
ＣＰ／ＩＰ部４が次に入るタイマ割り込み中に通信アプ
リケーションによってセットされたテーブル情報を参照
して行う。

【００４４】また、タイマ割り込み時に受信パケットが
受信バッファ５内に存在する時は、受信パケットの処理
を優先して行い、その応答パケットと一緒に送信要求を
ＮＩＣ３に対して行う。

【００４５】次に動作について説明する。クライアント
よりランダムに送られてくるパケットは、図１に矢印
（ａ）、（ｂ）で示すように、第１、２層部のＮＩＣ３
によりリアルタイムに受信される。ＮＩＣ３はパケット
を受信する毎にＣＰＵ１に割り込みをかけて、割り込み
処理によりパケットを受信バッファ５に格納する。

【００４６】ＴＣＰ／ＩＰ部４は、時間ｔ毎に入るタイ
マ割り込み中にネットワ−ク層及びトランスポ−ト層の
プロトコル処理を、図１に矢印（ｃ）で示すように、そ
の時受信バッファ５に受信してある全パケットについて
行い、処理済みのパケットをパケット一時バッファ７ａ
に格納する。

【００４７】一連の受信データストリームにおける最終
パケットを受信すると、ＴＣＰ／ＩＰ部４は、ヘッダか
ら上位層プロトコル( 通信アプリケーション) を識別
し、それを通知するフラグをセットして、図１に矢印
（ｄ）で示すように、ＩＦＣタスク６に対してＰＯＳＴ
を行う。

【００４８】フラグはグローバルな変数で、ＴＣＰ／Ｉ
Ｐ部４が受信データストリームを渡すべき上位層( 通信
アプリケーション) を指定するために用い、ＴＣＰ／Ｉ
Ｐ部４からＩＦＣタスク６に対して受け渡される。受け
渡し方法は、ＯＳのメッセージパッシング機能を用い
る。

【００４９】通信アプリケーションは、すべてＩＦＣタ
スク６の関数として組み込まれ、指定された上位層が、
例えば、ＦＴＰ９ａとすると、図１に矢印（ｅ）で示す
ように、識別部８はＦＴＰ関数をコールする。

【００５０】ＦＴＰ９ａは、ＴＣＰ／ＩＰ部４が受信し
たデータストリームを受信パケット一時バッファ７ａか
ら受け取り、内容を処理する。必要であれば、図１に矢
印（ｆ）で示すように、入出力管理部１１へデータを渡
す。入出力管理部１１へ渡すデータは、コネクション別
になっているので、コネクション別のキュー( 以後、Ｉ
ＦＣ−ＥＤＩＴ間受信キューと記す) を作成する。

【００５１】ＩＦＣ−ＥＤＩＴ間受信キューは、ＩＦＣ
タスク６の通信アプリケーションＦＴＰ９ａから入出力
管理部１１を介し、印刷部１０のＥＤＩＴ（編集）タス
ク１０ａへ印刷データ、その他を渡す待ち行列である。
印刷部１０のＥＤＩＴタスク１０ａは、図１に矢印
（ｇ）で示すように、ＩＦＣ−ＥＤＩＴ間受信キューか
らデータを受け取り編集処理を行う。

【００５２】ここで、従来の方法（Ａとする）による受
信処理時間ｒＡと、本実施の形態方法（Ｂとする）によ
る受信処理時間ｒＢとの差Ｒｅｃを以下に示す。

【００５３】まず、処理をＴＣＰ／ＩＰ部４に、時間を
ｔ内に限定し、パケット受信時間を、パケット処理時間
とＯＳの処理時間に分けて求める。単位時間に受信する
パケットの数をｎ、１パケットを処理する時間をＥとす
ると一定時間ｔにおけるパケットの処理時間Ｅ（Ａ，
Ｂ）は、Ａ，Ｂ共に、 Ｅ（Ａ，Ｂ）＝Ｅ×ｔ×ｎ・・・・・・・・・・（１） また、ＯＳの処理時間は、タスク生成時間とタスクスイ
ッチ時間との和とすると、fork()関数等により子タスク
を作成し実行させる時間をＦ、同時にアクセスする平均
コネクション数をＮとすると一定時間ｔにおけるタスク
生成処理（コネクション確立毎生成）時間Ｆ（Ａ）は、
Ａのみ該当し、 Ｆ（Ａ）＝Ｆ×Ｎ・・・・・・・・・・・・・・（２） タスクスイッチに要する時間（ＰＯＳＴされてからタス
クが起動するまでの時間) において、従来の組込みにお
いて対象となるＯＳをＰＡ、割込みによるマルチタスク
ＯＳをＰＢとすると１パケット受信に対しＩＰタスク、
ＴＣＰタスクがそれぞれ起動するため一定時間ｔにおけ
るタスクチェンジ処理時間Ｐ（Ａ）、Ｐ（Ｂ）は、Ａで
は、１パケット受信毎にＩＰタスク、ＴＣＰタスクが呼
び出されるので、 Ｐ（Ａ）＝２×ＰＡ×ｔ×ｎ・・・・・・・・・（３） Ｂでは、ｔ時間内に１度ＴＣＰ／ＩＰ部４が呼ばれるの
で、 Ｐ（Ｂ）＝ＰＢ・・・・・・・・・・・・・・・（４） 従来方法の一定時間ｔにおける受信処理に要する時間ｒ
Ａは式（１）（２）（３）より、 ｒＡ＝Ｅ（Ａ，Ｂ）＋Ｆ（Ａ）＋Ｐ（Ａ） ＝Ｅｔｎ＋ＦＮ＋２（ＰＡ）ｔｎ・・・（５） タイマ割り込みが起動し、割り込み内の処理が起動する
までの時間をＩとすると、本方法の一定時間ｔにおける
受信処理に要する時間ｒＢは、（１）（４）より、 ｒＢ＝Ｅ（Ａ，Ｂ）＋Ｐ（Ｂ）＋Ｉ ＝Ｅｔｎ＋ＰＢ＋Ｉ・・・・・・・・・（６） となるから、それらの差Ｒｅｃは式（５）、（６）より
次の式で示すことができる。

【００５４】 Ｒｅｃ＝ｒＡ−ｒＢ ＝ＦＮ＋２（ＰＡ）ｔｎ−ＰＢ−Ｉ・・（７） 従って、本組込み方法により一定時間ｔにおけるパケッ
トの受信時間をＦＮ＋２（ＰＡ）ｔｎ−ＰＢ−Ｉだけ短
縮することができる。

【００５５】また、従来の組込み方法では、受信側ノー
ドは１パケットを受信するとＩＰタスクを経由し、直ち
に制御をＴＣＰタスクへ移す。そしてＴＣＰタスクが１
パケットの処理を終了すると、制御を他のタスクへ移さ
なければならないので、後続のパケットの受信を待っ
て、それらをまとめて応答することは難しい。そのた
め、１パケット受信する毎に応答パケットをクライアン
トに返していた。

【００５６】従来の方法の応答処理時間ＳＡと本実施の
形態による方法の応答処理時間ＳＢとの差Ｒｅｓは次の
ように求めることができる。

【００５７】 ＳＡ＝ｔ×ｎ×Ｒ＋ｔ×ｎ×ＰＡ＋ｔ×ｎ×Ｓ・・・（８） ＳＢ＝Ｎ×Ｒ＋Ｓ・・・・・・・・・・・・・・・・（９） 式（８）（９）より、 Ｒｅｓ＝ＳＡ−ＳＢ ＝ｔｎＲ＋ｔｎ（ＰＡ）−ＮＲ＋（ｔｎ−１）Ｓ・・（１０） ｎは単位時間に受信するパケット数、ｔは本実施の形態
による組込みで採用するタイマ割込みの間隔、ＰＡは従
来の組込みにおいて対象となるＯＳのタスクスイッチ時
間、ＰＢは割込みよるマルチタスクＯＳのタスクスイッ
チ時間、Ｎは同時にアクセスする平均コネクション数、
Ｒは１パケットの応答処理に要する時間、ＳはＮＩＣ３
への送信要求処理時間と送信完了割り込み処理時間の和
である。従って、本実施の形態による組込み処理によっ
て応答処理時間をｔｎＲ＋ｔｎ（ＰＡ）−ＮＲ＋（ｔｎ
−１）Ｓだけ短縮することができる。

【００５８】また、図７に示すように、実際の送信で
は、ＮＩＣ３に対して送信に必要な情報をセットする前
処理、ＮＩＣ３が行う送信処理と、送信完了後行う後処
理が必要である。特に後処理は、送信完了時に割込みと
して起動されるのでレジスタの退避等で数１００ミリ秒
が必要となり、従来の方法では送信の度にこの割込みが
発生する。本実施の形態による方法では時間ｔ内に発生
する送信要求および、受信したデータの応答パケットの
送信を、ＮＩＣ３に対し同時に起動をかけるため送信に
おける前処理と後処理は常に１回となる。

【００５９】送信パターン２の一定時間ｔにおける、従
来の組込み方法の処理時間ＹＡ、と本実施の形態による
組込み方法の処理時間ＹＢとの差Ｓｅｎを求めると、 ＹＡ＝ｔ×Ｙ×Ｓ・・・・・・・・・・・・・・（１１） ＹＢ＝Ｓ・・・・・・・・・・・・・・・・・・（１２） 式（１１）（１２）より Ｓｅｎ＝ＹＡ−ＹＢ ＝（ｔＹ−１）Ｓ・・・・・・・・・・・・（１３） Ｙは単位時間内に発生する送信要求数、ＳはＮＩＣ３へ
の送信要求処理時間と送信完了割り込み処理時間の和で
ある。

【００６０】一定時間ｔ内にパケットを受信している場
合は、その応答パケットと一緒に送信処理を行うため、
ＹＢは０となり、Ｓｅｎ＝ｔＹＳとなる。従って、本実
施の形態による組込み方法により、送信時間を( ｔＹ−
１) Ｓまたは、ｔＹＳだけ短縮することができる。

【００６１】本送信処理で送信するパケットのタイムア
ウト処理も送信パタ−ン１と同様にタイマ割り込み中で
行う。従来の送信したパケットに対するタ−ンアラウン
ド時間のタイムアウト処理は、送信したすべてのパケッ
トそれぞれに対しタイマをカウントする必要があるが、
本実施の形態による方法のように一定数のパケットを同
時に送信することにより、パケットのタイマ管理をグル
−プ化し処理時間を短縮することができる。

【００６２】また、従来はコネクションの接続している
間はＴＣＰタスクは起動したままとなり、タイムスライ
ス処理で他のタスクを実行しており、タイムスライス処
理に常に一定量のＣＰＵ資源を使用しているので、プロ
トコル処理や、プリンタファームウェアの処理の動作す
る効率が非常に悪くなる。

【００６３】本実施の形態による組込み方法では、ジョ
ブのスケジューリングにプライオリティを用いた割り込
みを使用し、タイムスライスによるラウンドロビン方式
は採用していない。

【００６４】第１の実施の形態によれば、ＴＣＰ／ＩＰ
部は受信バッファに受信してあるすべてのパケットを割
り込み処理時間ｔ内に処理するので、ＯＳのオ−バヘッ
ドを削減することができ、ＣＰＵを他の有効な処理に割
り当てることができる。

【００６５】第２の実施の形態 一般に割込み内での動作が多いと、他の処理への影響が
大きくなるので、第２の実施の形態では極力割込み内の
処理を減らし、大部分の処理をＩＦＣタスクに組み込む
ようにしたものである。

【００６６】図５は第２の実施の形態によるプリンタの
ネットワ−クア−キテクチャを示すブロック図であり、
受信割込み手段２０とインタ−バルタイマ２１とインタ
−フェ−ス制御手段としてのＩＦＣタスク２２とから成
る。

【００６７】受信割込み手段２０は、パケットの受信時
に起動して受信パケットをメモリ５の受信バッファ５ａ
に格納する毎にＩＦＣタスク２２にメッセ−ジ(message
-X)を出力する。インタ−バルタイマ２１はカウンタ２
１ｂがカウントアップする毎にＩＦＣタスク２２にメッ
セ−ジ(message-S) を出力する。

【００６８】ＩＦＣタスク２２は、メッセ−ジを受信し
て呼び出し処理を行うメッセ−ジ処理手段２４と、デ−
タリンク層（２層）、ネットワ−ク層（３層）、トラン
スポ−ト層（４層）の各プロトコルを処理して所定量に
達するまでメモリ５のパケット一時バッファ５ｂに蓄積
する第１のパケット処理手段２３と、パケット一時バッ
ファ５ｂからパケットを取り出してセッション層（５
層）、プレゼンテ−ション層（６層）、アプリケ−ショ
ン（７層）の各プロトコルを処理し、デ−タをメモリ５
のデ−タバッファ５ｄに出力する第２のパケット処理手
段３０と、第１のパケット処理手段２３から呼び出され
てメッセ−ジ(message-A) をメッセ−ジ処理手段２４に
出力し、メッセ−ジ処理手段２４からの呼び出し応じて
第２のパケット処理手段３０に起動を駆けるソケット処
理手段２８と、セントロニクス、ＲＳ−２３２Ｃ等のケ
−ブルを制御するＩＦＣタスク内の制御モジュ−ル３２
とを備えている。

【００６９】第１のパケット処理手段２３は、受信割込
み手段２０からメッセ−ジ処理手段２４にメッセ−ジ(m
essage-X) が出力されることによって起動され、受信バ
ッファ５ａから受信パケットを取り出してデ−タリンク
層（２層）のプロトコル処理を行うネットワ−クドライ
バ２５と、ネットワ−クドライバ２５が処理した受信パ
ケットのネットワ−ク層（３層）とトランスポ−ト層
（４層）の各プロトコルを処理してメモリ５のパケット
一時バッファ５ｂに蓄積するプロトコルスタック(TCP/I
P 、SPX/IPX 、その他）２６と、インタ−バルタイマ２
１からメッセ−ジ処理手段２４にメッセ−ジ(message-
S) が出力されることによって起動され、コネクション
を管理するタイマ処理手段３１とを備えている。

【００７０】第２のパケット処理手段３０は、プロトコ
ルスタック２６を使用することにより実際に他のノ−ド
と通信するアプリケ−ション(FTP、RPRINTER、その他)
２７と、アプリケ−ション２７が処理したデ−タのキュ
−管理を行うジョブ制御モジュ−ル２９とを備えてい
る。

【００７１】ソケット処理手段２８はアプリケ−ション
２７とプロトコルスタック２６の間の通信行う上で共通
のインタフェ−スを提供し、プロトコルスタック２６に
呼び出され、アプリケ−ション２７を指定するメッセ−
ジ(message-A) をメッセ−ジ処理手段２４に出力するソ
ケット(Low) ２８ａと、メッセ−ジ処理手段２４に呼び
出されメッセ−ジに含まれる内容に基づいてアプリケ−
ション２７を選択するソケット(High)２８ｂとを有す
る。

【００７２】図６はアプリケ−ションＦＴＰの構成を示
すブロック図である。アプリケ−ションＦＴＰ２７ａ
は、イニシャル処理部３５と、メイン処理部３６とから
構成される。

【００７３】イニシャル処理部３５は、プリンタ１から
のイニシャル要求に対し、ＦＴＰ内のワ−キング等の初
期化の他、アプリケ−ション登録をソケット(High)２８
ｂに対して行う。

【００７４】メイン処理３６は、メッセ−ジ(message-
A) の解析部３７と、下位層の状態をmessage-A によっ
て通知された時に呼び出されるコネクション管理部３８
と、受信したパケットの処理を行う際に参照するデ−タ
解析部３９と、デ−タ解析部３９でコマンドと判断され
たときに呼ばれるコマンド分岐部４０と、各コマンドの
処理群４１とから成る。

【００７５】図７はコネクション管理テ−ブルの説明図
であり、コネクション別に「コネクションの状態」、
「処理中のコマンド」、「コネクションＮｏ」、「送信
パケット数」、「相手先ポ−トＮｏ」が配列されてあ
る。コネクション管理テ−ブルはコネクション管理部３
８により管理され、受信したパケットの処理を行う際に
にメッセ−ジ解析部３７より参照される。

【００７６】図８はコネクションの状態と設定値との関
係を示す説明図、図９はプロトコルスタックの各処理手
段の処理ステップ数と負荷との関係を示す負荷算出テ−
ブル、図１０はパケットを再送する際の処理を示すフロ
−チャ−トである。

【００７７】次に動作について説明する。クライアント
よりランダムに送られてくるパケットは、ネットワ−ク
接続用Ｈ／ＷであるＮＩＣ３からの受信割り込み信号が
ＣＰＵ１に入力され、受信割り込みプログラムからなる
受信割込み手段２０によってリアルタイムに受信され、
受信バッファ５ａに格納される。１パケットを格納する
毎に受信割込み手段２０は、図５に矢印（ａ）で示すよ
うに、メッセ−ジ(message-X) をＩＦＣタスク２２に対
し出力する。

【００７８】ＩＦＣタスク２２のメッセ−ジ処理手段２
４は、アイドル時はＩＦＣタスク宛のメッセ−ジのセン
スをしている。メッセ−ジ(message-X) よりも先にＩＦ
Ｃタスク宛に送られたメッセ−ジがあればＩＦＣタスク
２２はその処理を先に実行する。

【００７９】メッセ−ジ処理手段２４はメッセ−ジ(mes
sage-X) を受信すると、図５に矢印（ｂ）で示すよう
に、ネットワ−クドライバ２５を呼び出す。ネットワ−
クドライバ２５は、通常のデ−タリンク層（２層）の処
理を行うが、複数のＮＩＣ３および複数の２層プロトコ
ル( 例えばEthernet、IEEE802.3 、IEEE802.5 等) にも
対応できる。

【００８０】ネットワ−クドライバ２５は、デ−タリン
ク層のプロトコル処理を終了すると、図５に矢印（ｃ）
で示すように、上位層を識別して対応するプロトコルス
タック２６、例えばＴＣＰ／ＩＰ２６ａを呼び出す。Ｔ
ＣＰ／ＩＰ２６ａはＴＣＰとＩＰとを別タスクとせず一
つのタスクとして作成されているので、ＴＣＰ−ＩＰ間
のオ−バ−ヘッドを削減する。

【００８１】ＴＣＰ／ＩＰ２６ａは、ネットワ−クドラ
イバ２５から受信したパケットのネットワ−ク層（３
層）とトランスポ−ト層（４層）のプロトコル処理を行
い、そのパケットをメモリ５のパケット一時バッファ５
ｂに格納し、ネットワ−クドライバ２５に対して制御を
返す。

【００８２】ネットワ−クドライバ２５は制御をＩＦＣ
タスク２２から他のタスクへ返し、次のパケットの受信
を待つ。

【００８３】以上の処理を数回繰り返すと、パケット一
時バッファ５ｂにパケットが一定量蓄積される。ＴＣＰ
／ＩＰ２６ａはパケットが一定量に達すると、図５に矢
印（ｄ）で示すように、ソケット(Low) ２８ａに対し、
対応するアプリケ−ション２７を指定する情報を出力し
てパケットの受け取りを要求する。

【００８４】ソケット(Low) ２８ａは、直接、ソケット
(High)２８ｂを呼び出さず、図５に矢印（ｅ）で示すよ
うに、メッセ−ジ処理手段２４に対しメッセ−ジ(messa
ge-A) を出力する。本処理により、メッセ−ジ処理手段
２４に起動を駆けられ、セントロニクス、ＲＳ−２３２
Ｃ等のケ−ブルを制御するＩＦＣタスク内の制御モジュ
−ル３２が動作するきっかけを与えることができる。

【００８５】メッセ−ジ処理手段２４はメッセ−ジ(mes
sage-A) を受信すると、図５に矢印（ｆ）で示すよう
に、ソケット(High)２８ｂを呼び出す。ソケット(High)
２８ｂは、図５に矢印（ｈ）で示すように、メッセ−ジ
(message-A) の内容に基づいてアプリケ−ション、例え
ばＦＴＰ２７ａを呼び出す。

【００８６】ＦＴＰ２７ａは、パケット一時バッファ５
ｂに蓄積されたパケットを全て処理し、図５に矢印
（ｉ）で示すように、ジョブ制御モジュ−ル２９を呼び
出す。

【００８７】ジョブ制御モジュ−ル２９は、図５に矢印
（ｊ）で示すように、パケットのデ−タをメモリ５のデ
−タバッファ５ｄに格納する。

【００８８】ここで、ＦＴＰの動作を図６〜図１１を参
照して詳細に説明する。ＦＴＰ２７ａはソケット(High)
２８ｂから受信したメッセ−ジ(message-A) により呼ば
れる関数により起動される。メッセ−ジ解析部３７はメ
ッセ−ジ(message-A) の内容を解析し、コネクションに
関する状態を通知するものであれば、コネクション管理
部３８を呼び出す。コネクション管理部３８は、メッセ
−ジ(message-A) の内容により、図７、８に示すコネク
ション管理テ−ブルの「コネクションの状態」の設定値
を変更する。

【００８９】メッセ−ジ解析部３７は、メッセ−ジ(mes
sage-A) の内容がパケットの受信であれば、デ−タ解析
部３９を呼び出す。デ−タ解析部３９は、ソケット(Hig
h)２８ｂに対してパケットの獲得を要求し、受信したパ
ケットの「コネクションの状態」を知るために、図７に
示したコネクション管理テ−ブルの「コネクションの状
態」を参照する。

【００９０】「コネクションの状態」が、図８に示した
ように設定値４であれば、獲得したパケットは、印字デ
−タと判断し、ジョブ制御モジュ−ル２９にパケットを
渡す。「コネクションの状態」が、設定値０、又は３で
ある場合には、パケットを受信する状態ではないので、
獲得したパケットを捨てる。

【００９１】「コネクションの状態」が、設定値１、又
は２である場合には、獲得したパケットは、コマンドで
あると判断してコマンド分岐部４０を呼び出す。コマン
ド分岐部４０は、「コネクションの状態」が、設定値１
で受信したパケットがログイン要求（ＵＳＥＲコマン
ド）である場合には、ログイン処理と判断し、コネクシ
ョン管理部３８を呼び出す。

【００９２】「コネクションの状態」が、設定値２であ
る場合には、ログイン済であるので、ログイン要求以外
のコマンドを受け付けられるので、該当するコマンド処
理部４１を呼び出す。

【００９３】コマンド処理部４１は送受信を必要とする
コマンドを受け付けた場合には、クライアントに対して
処理し、デ−タのコネクションの確立を行うために、下
位層に対してコネクションの確立要求を出す。

【００９４】コネクションが確立されるまでの間は、他
の処理に制御を渡すため、デ−タコネクションの確立後
の処理をコネクション管理テ−ブルの「処理中のコマン
ド」に書き込み、保持する。

【００９５】このように、各処理が独立してコネクショ
ン管理テ−ブルの「コネクションの状態」エリアの設定
値によって動作するので、複数のコネクション管理を行
うことができる。

【００９６】パケット送信時のタイマ処理は、図５に矢
印（ｌ）〜（ｎ）で示すように行なわれる。まず、一定
時間毎にインタ−バルタイマ２１は、矢印（ｌ）で示す
ように、ＩＦＣタスク２２のメッセ−ジ処理手段２４に
対してメッセ−ジ(message-S）を出力する。

【００９７】メッセ−ジ処理手段２４はメッセ−ジ(mes
sage-S）を受信すると、矢印（ｍ）に示すように、タイ
マ処理手段３１を呼び出す。タイマ処理手段３１は、矢
印（ｎ）に示すように、必要に応じてプロトコルスタッ
ク２６を呼び出す。

【００９８】タイマ処理手段３１及びタイマ処理手段３
１によって呼び出されるプロトコルスタックの動作を図
１０に基づいて説明する。プロトコルスタック２６は、
例えばＴＣＰ／ＩＰ２６ａが呼び出されているものとす
る。まず、ステップＳ1 とステップＳ2 とは、全コネク
ションにおいて毎回実行しなければならない処理で、タ
イマ処理手段３１を起動することにより必ず実行され
る。

【００９９】即ち、「コネクションの状態」のチェッ
ク、応答待ちパケットのタイマカウント処理、パケット
の再送処理、Ｍａｘ Ｔｉｍｅｏｕｔ処理等を実行す
る。

【０１００】その他のステップは、プロトコル上必ず毎
回実行する必要のない処理で、処理時間のかかるものが
多く、時間的に処理量のばらつきが大きい。これらの処
理は、図９に示すような処理ステップ数と対応する負荷
係数Ｇを用いる。

【０１０１】まずステップＳ3 で、負荷変数を初期化す
る。ステップＳ4 で、コネクション単位に要求される処
理を行い、１コネクションの処理が終了するまで行う。

【０１０２】ステップＳ5 で１コネクションの処理の最
後に行った処理の負荷係数Ｇの合計を負荷変数に加算す
る。ステップＳ6 で、負荷変数が一定値(MAX) 以上であ
れば、ステップＳ8 で処理を中断してタイマ関数を抜け
る。このとき次にタイマ関数が呼び出された時に処理を
開始するコネクションの位置( コネクションNo.)をメモ
リ５のグロ−バルエリア内の変数に記憶しておく。

【０１０３】負荷変数が一定値(MAX) 以下であれば、全
コネクションの処理を終了するまでステップＳ3 〜ステ
ップＳ7 を繰り返す。

【０１０４】負荷変数が一定値(MAX) 以下のまま、すべ
てのコネクションの処理を終了した場合はタイマ処理を
抜ける。

【０１０５】第２の実施の形態によれば、ネットワ−ク
プロトコル( ２層〜７層) 処理をシングルタスク上でソ
ケットインタフェ−スにより下位層と上位層とに分け、
ＯＳの基本機能であるメッセ−ジによって各層の処理手
段に起動をかけ得るようにしたので、シングルタスク上
で２つの処理に優先順位をつけることができ、また、ネ
ットワ−クプロトコル処理中に割込みにより他のインタ
−フェ−ス処理を受け付けることができるので、同一タ
スク上で他のホストインタフェ−ス( セントロニクス、
RS-232C)との共存を可能とした。

【０１０６】また、タイマ処理手段を設けたことによ
り、一時期に集中しがちな処理の負荷を分散し平均化さ
せ、安定したシステム状態を保つことができる。このこ
とにより、プリンタではオ−バ−ランや、オ−バ−フロ
−等の性能を向上させ、ネットワ−ク処理の集中に関係
なく安定した性能を保つことができる。

【０１０７】また、シングルタスク上で動作するアプリ
ケ−ションでマルチコネクションを確立し、管理するこ
とが可能となる。

【０１０８】第３の実施の形態 第３の実施の形態は受信バッファ５ａの使用量を定期的
に検知して許容コネクション数を変化させ、処理飽和状
態からのリカバリ−を迅速にするとともに、低要求コネ
クション確立時にも、効率良く動作させるようにしたも
のである。

【０１０９】図１１は第３の実施の形態によるインタ−
バルタイマ処理の要部を示すブロック図、図１２は許容
コネクションを増減させる際に使用するテ−ブルであ
る。

【０１１０】まず、図５に示したタイマ処理手段３１に
受信バッファ５ａの使用量をセンスするバッファ数セン
ス部５０と、図１２に示したテ−ブル５１ａを参照して
処理負荷を判断する判断部５１と、許容コネクション数
を設定するコネクション数設定部５２とを設ける。

【０１１１】次に動作について図１３に従って説明す
る。図１３は第３の実施の形態の動作を示すフロ−チャ
−トである。ステップＳ1 でバッファ数センス部５０は
インタ−バルタイマ２１の周期で受信バッファ５ａの使
用量をセンスし、ステップＳ2で受信バッファ５ａの使
用量をグローバルに確保したメモリ５の記憶領域Ｘに格
納する。また、１回目のセンス時は、「前回のセンス時
の受信バッファ使用量（Ｙ）」データは存在しないので
ｃ、メモリ５の記憶領域Ｙを0xＦＦＦＦにしておく。

【０１１２】ステップＳ3 で記憶領域Ｙの内容が0xＦＦ
ＦＦか否かをチェックし、0xＦＦＦＦの場合にはステッ
プＳ5 に分岐し、否の場合はステップＳ4 に分岐する。
ステップＳ4 で「前回のセンス時の受信バッファ使用量
（Ｙ）」データが存在するので、「今回のセンス時の受
信バッファ使用量（Ｘ）」を用い、図１２に示すテ−ブ
ル５１ａとの比較により、許容コネクション数の変更量
を決定し、メモリ５の記憶領域Ｚへ書き込む。

【０１１３】ステップＳ5 で、次のセンスに備え、「今
回センス時の受信バッファ使用量（Ｘ）」を「前回のセ
ンス時の受信バッファ使用量（Ｙ）」へコピーする。

【０１１４】ステップＳ6 で、記憶領域Ｚの内容が０か
否かをチェックして、０ならばステップＳ1 に戻って次
のインタ−バルタイマ２１による起動を待ち、否ならば
ステップＳ7 で記憶領域Ｚの内容に応じたコネクション
数を増減させる。コネクション数設定部５２は、記憶領
域Ｚの内容が０以外の時に起動し、記憶領域Ｚの内容に
応じたコネクション数を増減させる。本処理は、記憶領
域Ｚの内容が正の数である時には、各コネクションに必
要な領域の確保とイニシャライズ行う。記憶領域Ｚの内
容が負の数である時には各コネクションに必要な領域を
使用不可能にする。許容数までコネクションが接続して
いる場合は、コネクションが切断され次第各コネクショ
ンに必要な領域を使用不可能にする。

【０１１５】図１２を用いてコネクション数設定部の動
作を説明する。コネクション数設定部５２は、記憶領域
Ｚの内容が０以外の時に起動し、記憶領域Ｚの内容に応
じたコネクション数を増減させる。記憶領域Ｚの内容が
正の数である時には、各コネクションに必要な領域の確
保とイニシャライズ行う。記憶領域Ｚの内容が負の数で
ある時には各コネクションに必要な領域を使用不可能に
する。許容数までコネクションが接続している場合は、
コネクションが切断され次第各コネクションに必要な領
域を使用不可能にする。

【０１１６】現在及び前回の使用受信バッファ量が全受
信バッファ量の20% 以下であった場合は、要求負荷の低
いコネクションが全コネクションの大半を占めている可
能性が高いので、コネクションの許容数を1 つ増加させ
る。

【０１１７】また、現在の使用受信バッファ量が全受信
バッファ量の80% 以上であった場合には、後工程の処理
の負荷が高く、受信バッファのオーバフローが予想され
るのでコネクションの許容数を1 つ減少させる。

【０１１８】現在の使用受信バッファ量が全受信バッフ
ァ量の21% 〜50% の間で、前回の使用受信バッファ量が
51% 以上であった場合は、処理負荷が下降していること
を示しているので、急激な処理負荷の下降に備えコネク
ションの許容数を1 つ増加させる。

【０１１９】現在の使用受信バッファ量が全受信バッフ
ァ量の51% 〜80% の間で、前回の使用受信バッファ量が
50% 未満であった場合は、処理負荷が上昇していること
を示しているので、急激な処理負荷の上昇に備えコネク
ションの許容数を1 つ減少させる。

【０１２０】第３の実施の形態によれば、現在行ってい
る処理の重さにより確立するコネクション数を変化させ
ることにより、処理飽和状態からのリカバリーを早くし
低要求コネクション確立時にも、より効率良く動作させ
ることができる。

【０１２１】第４の実施の形態 第４の実施の形態は、図１に示した印刷部１０の展開タ
スク１０ａ等からの高負荷通知に対し、インタ−バルタ
イマ２１のタイマ間隔を可変とすることにより、展開タ
スク１０ａ等のプライオリティの低いタスクが処理負荷
の高い状態にある時に、ＩＦＣタスク２２等のプライオ
リティの高いタスクを制御できるようにしたものであ
る。

【０１２２】図１４は第４の実施の形態による負荷監視
処理のブロック図である。負荷監視部６０は図５に示し
た展開タスク１０ａ等の処理の負荷を監視するためにプ
ライオリティの低いタスク内に設けられている。負荷通
知エリア６１はメモリ５のグロ−バルエリアに設けら
れ、負荷監視部６０から通知を受信し、高負荷時に他の
処理へそれを通知する。タイマ間隔値変更手段２１ｃは
インタ−バルタイマ２１に設けられ、高負荷時にインタ
−バルタイマ２１のカウンタ２１ｂのタイマ間隔値を変
更する。

【０１２３】図１５はプリンタにおける展開処理とエン
ジン処理等とのタイムチャ−トであり、（ａ）〜（ｄ）
は展開処理、エンジン処理、タイマ処理、その他の処理
を示している。

【０１２４】時間Ｗは、エンジン処理期間Ｔ1 間に展開
処理が動作できる時間を示し、この時間内に一定のデー
タの展開が終了しない場合にオーバランが発生する。タ
イマ処理と、その他の処理（共に展開処理よりもプライ
オリティは高い）が時刻ｔ1、ｔ2 、ｔ4 、ｔ5 で発生
すると、実際の展開処理動作は、矢印で示す範囲とな
り、オーバランが発生しやすくなる。

【０１２５】図１６は第４の実施の形態の動作を示すフ
ロ−チャ−トである。

【０１２６】次に動作について図１６のステップに従っ
て説明する。ステップＳ1 でインタ−バルタイマ２１の
タイマ処理２１ａは、タイマ割込み毎にカウントするカ
ウンタ２１ｂがタイマ間隔値Ｔ以上なったかをセンス
し、以下だった場合はステップＳ2 でカウンタ２１ｂを
インクリメントし、以上だった場合はステップＳ3 でプ
ロトコルスタック内のタイマ処理手段３１を呼出すため
にＩＦＣタスク２２に対してメッセ−ジ(message-S）を
出力する。ステップＳ4 でカウンタ２１ｂは０にリセッ
トされる。

【０１２７】ステップＳ5 でタイマ間隔値変更手段２１
ｃは負荷通知エリア６１を参照し、負荷監視部６０から
の高負荷通知が受信されていると、ステップＳ8 でカウ
ンタ２１ｂのタイマ間隔値Ｔを２倍にのばす。高負荷通
知が受信されていない場合には、ステップＳ6 でカウン
タ２１ｂのタイマ間隔値Ｔを調べ、変更前のデフォルト
値であった場合には本処理を終了する。変更が入ってい
る場合には、ステップＳ7 でタイマ間隔値Ｔを半分に短
縮する。負荷監視部６０から負荷通知エリア６１に高負
荷通知が出力され続けていると、タイマ処理手段３１か
らポストされて起動されるプロトコルスタック２６中の
タイマ処理は２倍単位でその間隔が延び、負荷通知エリ
ア６１に高負荷通知が出力されていない時間が続くと、
デフォルトのタイマ間隔値まで二分の一単位で間隔は短
縮される。

【０１２８】本実施の形態をプリンタに適用し、展開タ
スク等からの高負荷通知に対し、タイマ処理の間隔を可
変とすることにより、図１５の時間Ｗに示す間隔内のタ
イマ処理時間を少なくすることが可能となる。また、図
１４に示す負荷通知エリアをグローバル領域に設定する
ことにより、タイマ処理以外の高負荷処理へも同時に通
知することができ、対策を入れることが可能となる。

【０１２９】第４の実施の形態によれば、展開タスク等
からの高負荷通知に対し、タイマ処理の間隔を可変とす
ることにより、展開タスク等のプライオリティの低いタ
スクが処理負荷の高い状態にある時に、ＩＦＣ等のプラ
イオリティの高いタスクを制御できる。このことによ
り、プリンタではオーバーランや、オーバーフロー等の
性能を向上させ、ネットワーク処理の集中に関係なく安
定した性能を保つことができる。

【０１３０】第５の実施の形態 第１の実施の形態から第４の実施の形態までは単独のプ
リンタ記述言語を備えたプリンタに対応したが、第５の
実施の形態はプリンタが複数のプリンタ記述言語、プリ
ンタコントロ−ルラングエジ（PRINTER CONTROL LANGUA
GE: 以後ＰＣＬと記す）、ポストスクリプト（POST SCR
IPT:以後ＰＳと記す）、プリンタジョブラングエジ（PR
INTER JOB LANGUAGE: 以後ＰＪＬと記す）等を備えた場
合に対応できるようにしたものである。

【０１３１】図１７は第５の実施の形態によるプリンタ
のネットワ−クア−キテクチャを示すブロック図であ
り、第２の実施の形態によるプリンタと異なるところ
は、ＰＣＬ、ＰＳ、ＰＪＬ等のプリンタ記述言語に対応
するＩＦＣタスク４０から共通に使用できるようにネッ
トワ−クドライバ２５を再入可能（一つの関数からコ−
ルされ、リタ−ンする前に他の関数からコ−ルすること
が可能である仕様）にした点と、セントロニクス、ＲＳ
−２３２Ｃ等のインタ−フェ−スをネットワ−クドライ
バ２５と同様に共通関数にした点である。

【０１３２】プリンタ言語判別部４１はプリンタ記述言
語に対応する各ＩＦＣタスク４０やセントロニクス、Ｒ
Ｓ−２３２Ｃ等のインタ−フェ−スと、各プリンタ記述
言語に対応する編集部、例えばＰＣＬ用編集部４２、Ｐ
Ｓ用編集部４３に接続され、各ＩＦＣタスク４０から出
力されるデ−タのプリンタ記述言語を判別して対応する
編集部に出力している。

【０１３３】図１８はＩＦＣタスクの構造を示すブロッ
ク図であり、第２の実施の形態によるＩＦＣタスクの構
造と異なるところは、ネットワ−クドライバ２５がＩＦ
Ｃタスク４０の外にある点と、上位層から呼ばれる共通
化ドライバ関数４４をＩＦＣタスク４０の内部に設けた
点である。

【０１３４】図１９は共通関数部の構造を示すブロック
図であり、ＩＦＣタスク４０のアクセスを制御するドラ
イバ（Ethernet方式、IEEE802.2 方式、IEEE802.3 方
式、SNAP方式等）をまとめたネットワ−クドライバ２５
と、ネットワ−ク接続用Ｈ／Ｗを制御するドライバをま
とめたＮＩＣドライバ４５とからなる。

【０１３５】次に動作を図１８を参照して説明する。第
２の実施の形態と異なるところは、メッセ−ジ処理手段
２４がＮＩＣドライバ４５からなる受信割り込み手段２
０から矢印（ａ）に示すメッセ−ジを受信すると、ＩＦ
Ｃタスク４０の外にあるネットワ−クドライバ２５を関
数コ−ルする点であり、その他の動作は第２の実施の形
態と同様である。

【０１３６】第５の実施の形態によれば、メモリ容量の
大きいネットワ−クドライバをＰＣＬ、ＰＳ、ＰＪＬ等
のプリンタ記述言語に対応するＩＦＣタスクに設けるこ
となく、各ＩＦＣタスクから共通に使用できるようにし
たので、メモリを効率よく使用できる。

【０１３７】第６の実施の形態 第６の実施の形態によるプリンタのネットワ−クア−キ
テクチャは、第５の実施の形態と同じである。メッセ−
ジ処理手段２４は各処理手段からのメッセ−ジを受信す
るイベントコントロ−ルブロック（Event Control Bloc
k:以後ＥＣＢと記す）からメッセ−ジを取り出して処理
するが、ＥＣＢが複数あって、処理する優先度をＥＣＢ
間に設けてあればタスク内の処理にも優先度を設けるこ
とができ、効率良くＣＰＵ１を動作させることができる
が、ＥＣＢが一つの場合には、タスク内の処理に優先度
を設けることができないのでＣＰＵ１を効率良く動作で
きなくなる。

【０１３８】第６の実施の形態はＥＣＢが一つの場合に
も効率の良い動作ができるようにしたものである。

【０１３９】図２０は第６の実施の形態によるメッセ−
ジ処理手段の動作を示すブロック図である。メッセ−ジ
処理手段２４はＥＣＢ４６とソケット処理手段２８の上
位側待ち行列ＷＡＰＦQueue ４７とを参照し、ＥＣＢ４
６からメッセ−ジを取り出してプロトコルスタック２６
へプロトコルを処理するように要求するか、上位側待ち
行列ＷＡＰＦQueue ４７の処理をコ−ルするかを判定す
る。

【０１４０】図２１は図２０に示したメッセ−ジ処理手
段の動作を示すフロ−チャ−トである。メッセ−ジ処理
手段２４はステップＳ1 でソケット処理手段２８に上位
層待ち行列ＷＡＰＦQueue ４７が生成されてあるか否か
をチェックして生成されてあるならばステップＳ2 に分
岐し、否ならばステップＳ4 に分岐する。

【０１４１】ステップＳ2 で上位層待ち行列数が所定
量、例えば１０個未満か否かをチェックして１０個未満
ならばステップＳ3 に分岐し、否ならばステップＳ5 に
分岐する。ステップＳ3 でＥＣＢ４６にメッセ−ジが受
信してあるか否かをチェックして受信してあるならばス
テップＳ4 に分岐し、否ならばステップＳ5 に分岐す
る。ステップＳ4 でプロトコルスタック２６へプロトコ
ルを処理するように要求し、ステップＳ5 でソケット
（Ｈｉｇｈ）２８ｂをコ−ルする。

【０１４２】尚、本実施の形態は第２の実施の形態にも
適用できる。

【０１４３】第６の実施の形態によれば、ＯＳからポス
トされたメッセ−ジを格納するＥＣＢを一つのタスクに
複数設けられない場合にも、タスク内の処理に優先度を
設けることができので、ＣＰＵを効率良く動作させるこ
とができる。

【０１４４】第７の実施の形態 第７の実施の形態によるプリンタのネットワ−クア−キ
テクチャは、第５の実施の形態と同じである。ジョブ制
御モジュ−ル２９はデ−タのクライアント識別子を格納
する共通テ−ブルを有し、デ−タを出力する際にクライ
アント識別子を格納し、上位層からデ−タ送信要求を受
ける際には共通テ−ブルに基づいてクライアント識別子
を解析し、同一コネクションを通じてパケットを送受信
するようにしたものである。

【０１４５】図２２は第７の実施の形態を示すブロック
図である。２のパケット処理手段３０はジョブ制御モジ
ュ−ル２９にデ−タのクライアント識別子（以後クライ
アントＩＤと記す）等を登録する共通テ−ブルを有す
る。

【０１４６】共通テ−ブルにはデ−タを印刷部の編集タ
スクに送信する際に使用するＤＭＤ４８と、プリンタ言
語判別部４１からデ−タ送信要求を受ける際に登録する
SendDescriptor ４９とがある。例えば、ネットワ−ク
ドライバ２５を経由して３つのパケットを受信したとす
る。各パケットはプロトコルを処理されてアプリケ−シ
ョンＡＰ1 、ＡＰ2 、ＡＰ4 を通じてジョブ制御モジュ
−ル２９に送信されてくるものとする。

【０１４７】クライアントＩＤ Ｃ1 、Ｃ2 、Ｃ3 は受
信割り込み手段２０がパケットを受信した際にＤＭＤ４
８に登録される。ジョブ制御モジュ−ル２９はアプリケ
−ションＡＰ1 、ＡＰ2 、ＡＰ4 から受信する印刷デ−
タとともにクライアントＩＤＣ1 、Ｃ2 、Ｃ3 をプリン
タ言語判別部４１に送信する。クライアントＩＤは３２
ビットで構成される。最初の８ビットはＩＦＣタスク４
０、セントロニクス、ＲＳ−２３２Ｃ等のインタ−フェ
−スの種別を示し、次の２４ビットは各インタ−フェ−
スによって固有となる。例えばＩＦＣタスク４０の場合
には、８ビットがアプリケ−ションを示すＩＤ（ＡＰ1
、ＡＰ2 、・・・・）で、残りの１６ビットが各アプ
リケ−ションにおける通番となる。このフォ−マットに
より同一のアプリケ−ションにクライアントの接続が集
中しても対応することができる。

【０１４８】プリンタ言語判別部４１は受信したクライ
アントに対してデ−タを送信する場合にはインタ−フェ
−スの種別をクライアントＩＤの最初の８ビットから判
断し、そのインタ−フェ−スのSend Descriptor ４９に
登録する。

【０１４９】ジョブ制御モジュ−ル２９はSend Descrip
tor ４９を参照してアプリケ−ションを識別するビット
を読み取り、対応するアプリケ−ションをコ−ルする。

【０１５０】尚、本実施の形態は第２の実施の形態にも
適用できる。

【０１５１】第７の実施の形態によれば、ＩＦＣタスク
等のインタ−フェ−スを使用してパケットの授受を行う
上位層が、クライアントＩＤの中身を意識することなく
応答パケットの送信先を特定するので、要求するクライ
アントに正確に応答パケットを送信できる。

【０１５２】第８の実施の形態 第８の実施の形態によるプリンタのネットワ−クア−キ
テクチャは、第５の実施の形態と同じである。第８の実
施の形態はプリンタ等に組み込まれた受信バッファのサ
イズが小さい場合に、効率的な受信バッファ空き容量を
算出して受信速度を向上させるようにしたものである。

【０１５３】図２３はプリンタ言語判別部４１とジョブ
制御モジュ−ル２９との間のデ−タ受け渡し処理を示す
説明図、図２４は送信側ＴＣＰと受信側ＴＣＰとの間の
デ−タ受け渡し処理を示す説明図、図２５は第８の実施
の形態を示すブロック図である。第７の実施の形態で説
明したように、プリンタ言語判別部４１は処理状況に応
じて受信デ−タをジョブ制御モジュ−ル２９に要求する
が、図２３に示すように、デ−タ要求のポ−リング間隔
が常に一定は限らない。

【０１５４】また、ＴＣＰ間の受信処理では、図２４に
示すように、受信パケットを複数受信して一つの応答パ
ケットを返すブロック転送方式を使用している。さら
に、トランスポ−ト層の機能を使用するなど、送受信端
末間の距離制限は事実上無いに等しい。従って、パケッ
ト転送時間Ｔは非常に短い場合もあるが、非常に長い場
合もある。

【０１５５】そこでジョブ制御モジュ−ル２９に定期的
にポ−リング間隔を監視して、ジョブ制御モジュ−ル２
９からプリンタ言語判別部４１に転送される単位時間内
のデ−タ数Ｒを計数する転送デ−タ計数手段５０を設け
る。

【０１５６】また、ＴＣＰの受信パケット処理時、パケ
ット転送時間Ｔを算出するパケット転送時間更新手段５
１をプロトコルスタック２６に設ける。

【０１５７】また、ジョブ制御モジュ−ル２９には、パ
ケット転送時間Ｔと単位時間にデ−タを上位層に転送す
る転送デ−タ数Ｒと現在の受信バッファ空容量Ｗとから
次回のパケットブロック転送において受信可能なデ−タ
容量Ｘを算出する受信可能デ−タ容量算出手段５２を設
ける。

【０１５８】受信可能なデ−タ容量Ｘは、 Ｘ＝（Ｒ×Ｔ＋Ｗ）・・・・・・・・・・・・（１４） で算出される。

【０１５９】メモリ５にはパケット転送時間Ｔを格納す
る格納エリア５３、ＮＩＣドライバ４５が受信パケット
を受信する毎に更新される受信バッファ空容量Ｗを格納
する格納エリア５４、受信可能デ−タ容量算出手段５２
が算出した受信可能なデ−タ容量Ｘを格納する格納エリ
ア５５が設けてある。

【０１６０】プロトコルスタック２６の応答パケット作
成手段５６は応答パケットを作成する際に格納エリア５
５の内容を応答パケットに盛り込んで送信する。

【０１６１】尚、本実施の形態は第２の実施の形態にも
適用できる。

【０１６２】第８の実施の形態によれば、実際の受信バ
ッファサイズにとらわれず、後工程の処理速度と前工程
の受信速度を接近させることにより、高速で効率的な受
信を実現できる。

【０１６３】第９の実施の形態 第９の実施の形態によるプリンタのネットワ−クア−キ
テクチャは、第５の実施の形態と同じである。第９の実
施の形態は、受信バッファが受信デ−タで満杯になり、
送信側からの接続を確認するポ−リングパケットが受信
できず、そのパケットに対する応答パケットを送信でき
ない状態が発生する。その状態が長時間続いた場合にも
接続が切断されないようにしたものである。

【０１６４】図２６は第９の実施の形態を示すブロック
図であり、図１９に示したデ−タリンク層以下を処理す
るＮＩＣドライバの受信構造を示す。ＮＩＣドライバ４
５は、第７の実施の形態で説明した通り、受信パケット
を自層及びその上位層で共通管理する共通テ−ブルにリ
ンクされている。共通テ−ブルは各層が処理した情報や
自層の後工程である層に対して通知する情報を格納する
領域としてメモリ５に設けてある。

【０１６５】受信バッファ５ａには常時空けておく「常
時空きエリア」と、常時使用する「常時使用エリア」と
を設けておく。ＮＩＣドライバ４５は「常時空きエリ
ア」と「常時使用エリア」とを認識し、受信パケットを
優先的に「常時使用エリア」に受信するとともに共通テ
−ブルに情報（受信デ−タサイズ、受信デ−タ格納領域
の先頭アドレス、等）を格納する。「常時使用エリア」
が受信パケットで満たされると、「常時空きエリア」に
受信できるように制御する。

【０１６６】ＮＩＣドライバ４５は「常時空きエリア」
に受信している状態でも、受信パケットの処理が進み、
「常時使用エリア」に空き領域ができた場合には、以降
「常時使用エリア」に受信するように制御する。「常時
空きエリア」は１〜２パケット分の領域からなり、この
エリアにパケットを受信した場合には「常時空きエリ
ア」にリンクした共通テ−ブル（特）にその情報を格納
する。

【０１６７】図２７は第９の実施の形態の動作を示すフ
ロ−チャ−トであり、（Ａ）はＮＩＣドライバの動作を
示し、（Ｂ）はＴＣＰバイパス処理の動作を示す。

【０１６８】先ず、ＮＩＣドライバ４５の動作を説明す
る。ステップＳ1 で「常時空きエリア」にパケットが受
信されたか否かをチェックし、受信ならばステップＳ2
に分岐し、否ならばステップＳ5 に分岐する。ステップ
Ｓ2 で共通テ−ブル（特）に空きがあるか否かをチェッ
クし、空きがあるならばステップＳ3 に分岐し、否なら
ばステップＳ6 に分岐する。ステップＳ3 で「常時空き
エリア」に受信されたパケットの情報を共通テ−ブル
（特）に格納する。

【０１６９】ステップＳ4 でＴＣＰバイパス処理を呼び
出し、ＴＣＰバイパス処理後、ステップＳ1 に戻る。ス
テップＳ5 では通常の処理を行ってステップＳ1 に戻
る。ステップＳ6 では「常時空きエリア」に受信したパ
ケットを破棄してステップＳ1に戻る。

【０１７０】ステップＳ7 で受信パケットがパケット送
信元からのポ−リングパケットか否かをチェックし、ポ
−リングパケットならばステップＳ8 に分岐し、否なら
ばステップＳ9 に分岐する。受信側のＴＣＰは受信バッ
ファが満杯になった等の理由で一時的に受信を止めたい
場合には、応答パケットの所定のエリアに０を格納して
送信側のＴＣＰに送信する。送信側のＴＣＰはこの応答
パケットを受信すると、パケットの送信を停止する。そ
して、パケットの送信を開始するタイミングを獲得する
ために、受信側のＴＣＰにポ−リングパケットを定期的
に送信する。

【０１７１】ステップＳ8 で応答パケットを作成して送
信する。ステップＳ9 で「常時空きエリア」に受信した
パケットを破棄する。

【０１７２】尚、本実施の形態は第２の実施の形態にも
適用できる。

【０１７３】第９の実施の形態によれば、受信バッファ
が受信デ−タで満杯になり、長時間受信バッファが空か
ない場合でも、送信側からの接続を確認するポ−リング
パケットが受信でき、そのパケットに対する応答パケッ
トを送信できるので、コネクションを維持できるととも
に、その間低負荷の処理により接続を保つことができ
る。

【０１７４】

【発明の効果】本発明は、以上説明したように構成され
ているので以下に記載される効果を奏する。ネットワ−
ク層、トランスポ−ト層を受信パケット一括処理手段と
いう一つの機能で処理するようにしたので、プロトコル
処理を１回の起動で、受信バッファに受信された全パケ
ットを処理できるので、ＯＳのオーバヘッド量を減少さ
せることができる。

【０１７５】また、ネットワ−ク層、トランスポ−ト層
を一括処理することにより、プロトコルをネットワ−ク
層、トランスポ−ト層別に処理する場合に比べてメモリ
上の作業領域を削減できる。

【０１７６】さらに、それぞれのコネクションに属する
最後の受信パケットに対する応答パケットを割込み中に
ネットワ−クに一括して送信する送信パケット一括処理
手段を備えたことにより、送信処理時間を大幅に短縮で
き、その分他の処理にＣＰＵを動作させることができる
ので、効率良く動作するネットワ−クプロトコルのイン
プリメント手法を提供できる。

【０１７７】同様に、少なくともネットワ−ク層、トラ
ンスポ−ト層を第１のパケット処理手段という一つの機
能で処理するようにし、セッション層、プレゼンテ−シ
ョン層、アプリケ−ション層を第２のパケット処理手段
という一つの機能で処理するようにして、その２つの機
能間にソケット処理手段及びメッセ−ジ処理手段を介在
させて処理の優先度を持たせるようにしたことにより、
ＯＳのオーバヘッド量を減少させることができる。

【０１７８】また、ネットワ−ク層、トランスポ−ト層
を一括処理することにより、プロトコルをネットワ−ク
層、トランスポ−ト層別に処理する場合に比べてメモリ
上の作業領域を削減できる。

【０１７９】また、低機能ＯＳを用いて他のインタ−フ
ェ−ス処理をも受け付けるできるようにしたので、同一
タスク上で他のホストインタフェ−ス( セントロニク
ス、RS-232C)との共存を可能にできる。

【図面の簡単な説明】

【図１】第１の実施の形態によるプリンタのネットワ−
クア−キテクチャを示すブロック図である。

【図２】第１の実施の形態によるネットワ−クの構成図
である。

【図３】図１に示したネットワ−クア−キテクチャのタ
イムチャ−トである。

【図４】従来と本発明との送信処理の比較を示すタイム
チャ−トである。

【図５】第２の実施の形態によるプリンタのネットワ−
クア−キテクチャを示すブロック図である。

【図６】アプリケ−ションＦＴＰの構成を示すブロック
図である。

【図７】コネクション管理テ−ブルの説明図である。

【図８】コネクションの状態と設定値との関係を示す説
明図である。

【図９】処理ステップ数と負荷との関係を示す負荷算出
テ−ブルである。

【図１０】パケットを再送する際の処理を示すフロ−チ
ャ−トである。

【図１１】第３の実施の形態の要部を示すブロック図で
ある。

【図１２】許容コネクションを増減させる際に使用する
テ−ブルである。

【図１３】第３の実施の形態の動作を示すフロ−チャ−
トである。

【図１４】第４の実施の形態による負荷監視処理のブロ
ック図である。

【図１５】プリンタにおける展開処理とエンジン処理等
とのタイムチャ−トである。

【図１６】第４の実施の形態の動作を示すフロ−チャ−
トである。

【図１７】第５の実施の形態によるプリンタのネットワ
−クア−キテクチャを示すブロック図である。

【図１８】ＩＦＣタスクの構造を示すブロック図であ
る。

【図１９】共通関数部の構造を示すブロック図である。

【図２０】第６の実施の形態を示すブロック図である。

【図２１】メッセ−ジ処理手段の動作を示すフロ−チャ
−トである。

【図２２】第７の実施の形態を示すブロック図である。

【図２３】プリンタ言語判別部とジョブ制御モジュ−ル
との間のデ−タ受け渡し処理の説明図である。

【図２４】ＴＣＰ間のデ−タ受け渡し処理の説明図であ
る。

【図２５】第８の実施の形態を示すブロック図である。

【図２６】第９の実施の形態を示すブロック図である。

【図２７】第９の実施の形態の動作を示すフロ−チャ−
トである。

【符号の説明】

１ ＣＰＵ ３ ＮＩＣ ４ ＴＣＰ／ＩＰ部 ５ メモリ ６、２２、４０ ＩＦＣタスク ２３ 第１のパケット処理手段 ３０ 第２のパケット処理手段

Claims (14)

【特許請求の範囲】
1. 【請求項１】 ネットワ−クのノ−ド間にコネクション
   を確立し、受信バッファに受信したパケットに階層的に
   付加されたプロトコルを下位層から上位層に向かって順
   に処理するパケット処理方法において、 少なくともネットワ−ク層、トランスポ−ト層、セッシ
   ョン層、プレゼンテ−ション層、アプリケ−ション層に
   関するプロトコルの処理をそれぞれ一つのタスクにし、
   ネットワ−ク層、トランスポ−ト層を一つの機能とし、
   セッション層、プレゼンテ−ション層、アプリケ−ショ
   ン層を一つの機能とし、その機能に処理の優先度を持た
   せて動作するようにしたことを特徴とするパケット処理
   方法。
2. 【請求項２】 ネットワ−クのノ−ド間にコネクション
   を確立し、受信バッファに受信したパケットに階層的に
   付加されたプロトコルを下位層から上位層に向かって順
   に処理するネットワ−クア−キテクチャにおいて、 一定時間毎に入るタイマ割込みを使用し、上記受信バッ
   ファに受信されたパケットのネットワ−ク層とトランス
   ポ−ト層とに関するプロトコルを割込み中に一括処理し
   て蓄積し、プロトコルの内容から上位層のプロトコル処
   理手段を指定通知する受信パケット一括処理手段と、 それぞれのコネクションに属する最後の受信パケットに
   対する応答パケットを上記割込み中にネットワ−クに一
   括して送信する送信パケット一括処理手段とを備えたこ
   とを特徴とするネットワ−クア−キテクチャ。
3. 【請求項３】 上記送信パケット一括処理手段は、上記
   受信パケット一括処理手段が受信パケットを一括処理中
   に上位層の処理手段から発生した応答パケット送信要求
   を、次のタイマ割込み時にまとめて送信を行い、それに
   対する受信側からの応答のタイムアウトをタイマ割込み
   回数でカウントするタイマ処理手段を備えた請求項２記
   載のネットワ−クア−キテクチャ。
4. 【請求項４】 ネットワ−クのノ−ド間にコネクション
   を確立し、受信バッファに受信したパケットに階層的に
   付加されたプロトコルを下位層から上位層に向かって順
   に処理するネットワ−クア−キテクチャにおいて、 メッセ−ジに基づいて呼び出した処理手段に起動を駆け
   るオペレ−ティングシステム機能によるメッセ−ジ処理
   手段と、メッセ−ジ処理手段により呼び出されて受信バ
   ッファから受信パケットを取り出し、デ−タリンク層、
   ネットワ−ク層、トランスポ−ト層に関するプロトコル
   を処理して所定量に達するまで蓄積する第１のパケット
   処理手段と、セッション層、プレゼンテ−ション層、ア
   プリケ−ション層に関するプロトコルを処理して上位層
   に出力する第２のパケット処理手段と、第１のパケット
   処理手段から指定された第２のパケット処理手段を呼び
   出すメッセ−ジをメッセ−ジ処理手段に出力し、メッセ
   −ジ処理手段からの呼び出しに応じて第２のパケット処
   理手段を選択するソケット処理手段とを設けたインタ−
   フェ−ス制御手段と、 パケット受信時に起動し、受信パケットを受信バッファ
   に格納する毎にメッセ−ジをインタ−フェ−ス制御手段
   に出力する受信割り込み手段とを備えたことを特徴とす
   るネットワ−クア−キテクチャ。
5. 【請求項５】 上記第１のパケット処理手段は、上記受
   信割り込み手段のメッセ−ジに基づいて呼び出され、受
   信バッファから受信パケットを取り出してデ−タリンク
   層のプロトコルを処理するネットワ−クドライバを有す
   る請求項４記載のネットワ−クア−キテクチャ。
6. 【請求項６】 ネットワ−クのノ−ド間にコネクション
   を確立し、受信バッファに受信したパケットに階層的に
   付加されたプロトコルを下位層から上位層に向かって順
   に処理するネットワ−クア−キテクチャにおいて、 メッセ−ジに基づいて呼び出した処理手段に起動を駆け
   るオペレ−ティングシステム機能によるメッセ−ジ処理
   手段と、ネットワ−ク層、トランスポ−ト層に関するプ
   ロトコルを処理して所定量に達するまで蓄積する第１の
   パケット処理手段と、セッション層、プレゼンテ−ショ
   ン層、アプリケ−ション層に関するプロトコルを処理し
   て上位層に出力する第２のパケット処理手段と、第１の
   パケット処理手段から指定された第２のパケット処理手
   段を呼び出すメッセ−ジをメッセ−ジ処理手段に出力
   し、メッセ−ジ処理手段からの呼び出しに応じて第２の
   パケット処理手段を選択するソケット処理手段とを有す
   るインタ−フェ−ス制御手段と、 パケット受信時に起動し、受信パケットを受信バッファ
   に格納する毎にメッセ−ジをインタ−フェ−ス制御手段
   に出力する受信割り込み手段と、 受信割り込み手段のメッセ−ジに基づいてインタ−フェ
   −ス制御手段のメッセ−ジ処理手段により呼び出され、
   デ−タリンク層に関するプロトコルを処理して第１のパ
   ケット処理手段を呼び出すネットワ−クドライバとを備
   えたことを特徴とするネットワ−クア−キテクチャ。
7. 【請求項７】 カウンタがカウンタアップする毎にメッ
   セ−ジを上記インタ−フェ−ス制御手段のメッセ−ジ処
   理手段に出力するインタ−バルタイマと、インタ−バル
   タイマのメッセ−ジに基づいて呼び出され、上記第１の
   パケット処理手段により蓄積されたパケット量を監視す
   るタイマ処理手段を上記第１のパケット処理手段に設け
   た請求項４記載、又は請求項６記載のネットワ−クア−
   キテクチャ。
8. 【請求項８】 上記タイマ処理手段は、上記第１のパケ
   ット処理手段がプロトコル処理中にタイマ処理を実行
   し、応答パケットの送信処理等のプライオリティの低い
   処理に負荷係数を設定し、一定の負荷に達した時点でタ
   イマ処理を中断し、次回のタイマ処理でその続きを実行
   することにより、１回のタイマ処理時に処理する負荷を
   平均化させる請求項７記載のネットワ−クア−キテクチ
   ャ。
9. 【請求項９】 上記タイマ処理部は、コネクションを増
   減する際に参照するテ−ブルを記憶するテ−ブル記憶手
   段と、前回起動時の受信バッファの使用量を格納してお
   く第１の受信バッファ使用量記憶手段と、上記メッセ−
   ジ処理手段に起動される毎に受信バッファの使用量をセ
   ンスして第２の受信バッファ使用量記憶手段に格納する
   バッファ量センス部と、第１の受信バッファ使用量記憶
   手段の内容と第２の受信バッファ使用量記憶手段の内容
   とテ−ブル記憶手段のテ−ブルとを参照して増減するコ
   ネクション数を判断する判断部と、判断部の出力に基づ
   いて許容コネクション数を設定するコネクション数設定
   部とを備えた請求項７記載のネットワ−クア−キテクチ
   ャ。
10. 【請求項１０】 上記デ−タバッファに格納されたデ−
    タを処理するプライオリティの低い処理手段に設けられ
    た負荷監視部と、負荷監視部からの負荷通知を記憶する
    負荷通知記憶手段と、負荷通知記憶手段の内容が高負荷
    通知ならば上記インタ−バルタイマに設けられたカウン
    タのタイマ間隔値を大きくし、否ならばカウンタのタイ
    マ間隔値を小さくするタイマ間隔値変更手段とを備えた
    請求項７記載のネットワ−クア−キテクチャ。
11. 【請求項１１】 上記メッセ−ジ処理手段はメッセ−ジ
    を格納するＥＣＢ（Event Control Block ）を一つ有
    し、ＥＣＢとソケット処理手段の上位側待ち行列とを参
    照し、上位側待ち行列の登録メッセ−ジ数が所定数以上
    の場合には上位側待ち行列を処理する請求項４記載、又
    は請求項６記載のネットワ−クア−キテクチャ。
12. 【請求項１２】 上記第２のパケット処理手段はデ−タ
    のクライアントＩＤを格納する共通テ−ブルを有し、デ
    −タを出力する際にクライアントＩＤを格納し、上位層
    からデ−タ送信要求を受ける際には共通テ−ブルに基づ
    いてクライアントＩＤを解析し、同一コネクションを通
    じてパケットを送受信する請求項４記載、又は請求項６
    記載のネットワ−クア−キテクチャ。
13. 【請求項１３】 第１のパケット処理手段が前回の受信
    パケットに対する応答パケットを送信してから今回の受
    信パケットを受信までのパケット転送時間を算出するパ
    ケット転送時間算出手段と、第２のパケット処理手段か
    ら単位時間にデ−タを上位層に転送する転送デ−タ数を
    計数する転送デ−タ数計数手段と、パケット転送時間と
    転送デ−タ数と現在の受信バッファ空容量とから次回の
    パケットブロック転送において受信可能なデ−タ容量を
    算出する受信可能デ−タ容量算出手段とを設けた請求項
    ４記載、又は請求項６記載のネットワ−クア−キテクチ
    ャ。
14. 【請求項１４】 上記受信割り込み手段は、上記受信バ
    ッファの「常時使用エリア」と「常時空きエリア」とに
    受信したパケットの情報を格納する共通テ−ブルを有
    し、パケットを受信する毎に共通テ−ブルを参照して
    「常時空きエリア」に受信したパケットが送信側から受
    信側に送信される受信可能確認用ポ−リングパケットの
    場合には応答パケットを作成して送信し、受信可能確認
    用ポ−リングパケット以外の場合にはそのパケットを破
    棄する請求項４記載、又は請求項６記載のネットワ−ク
    ア−キテクチャ。