(57)【要約】【課題】通信回線から受信したデータをアプリケーションにより参照または更新して別の通信回線へ送信する通信制御装置において、バッファ確保処理の回数を削減すること。【解決手段】通信コントローラ４０により通信回線４１から受信したデータを参照または更新して通信コントローラ５０により通信回線５１に送信する通信制御装置１００は、通信コントローラ４０による通信回線４１からのデータ受信時、受信データの格納とこの格納した受信データを参照または更新して通信回線５１に送信する送信データの格納とに兼用するバッファをメモリ上に確保する。【選択図】図１
2010062981.tif 000002
【特許請求の範囲】
【請求項１】
第１の通信コントローラにより第１の回線から受信したデータをアプリケーションにより参照または更新して第２の通信コントローラにより第２の回線に送信する通信制御装置であって、前記第１の通信コントローラによる前記第１の回線からのデータ受信時、受信データの格納と該格納した受信データを参照または更新して前記第２の回線に送信する送信データの格納とに兼用するバッファをメモリ上に確保することを特徴とする通信制御装置。
【請求項２】
前記第１の通信コントローラによる前記第１の回線からのデータ受信時、受信データの格納と送信データの格納とに兼用するバッファをメモリ上に確保し、該確保したバッファに受信データを格納し、受信データの先頭アドレスとデータ長とを引き渡す受信側ドライバ処理部と、
該受信側ドライバ処理部から受信データの先頭アドレスとデータ長とを受け取り、前記バッファ上の受信データ内の各層のプロトコルヘッダを下位の層から順に認識して、上位層のデータの先頭アドレスとデータ長とを引き渡す受信側通信プロトコル処理部と、
該受信側通信プロトコル処理部から上位層のデータの先頭アドレスとデータ長とを受け取り、前記バッファ上で上位層のプロトコルヘッダとペイロードを認識して参照または更新し、上位層のデータの先頭アドレスとデータ長とを引き渡す通信アプリケーション部と、
該通信アプリケーション部から上位層のデータの先頭アドレスとデータ長とを受け取り、上位層の１つ下の層から順に、前記バッファ上でその層のプロトコルヘッダを１つ上の層のプロトコルヘッダの前に格納し、送信データの先頭アドレスとデータ長とを引き渡す送信側プロトコル処理部と、
該送信側プロトコル処理部から送信データの先頭アドレスとデータ長とを受け取り、前記バッファから送信データを読み出して前記第２の通信コントローラにより前記第２の回線へ送信する送信側ドライバ処理部とを備えることを特徴とする請求項１に記載の通信制御装置。
【請求項３】
前記バッファは、前記受信データを格納するデータ格納領域と、前記送信データのプロトコルヘッダの総サイズが前記受信データのプロトコルヘッダの総サイズより大きくなった場合に使用する前方予備領域とで構成されていることを特徴とする請求項１または２に記載の通信制御装置。
【請求項４】
前記バッファは、前記受信データに含まれるペイロードのサイズが更新により拡大した場合に使用する後方予備領域をさらに含んで構成されていることを特徴とする請求項３に記載の通信制御装置。
【請求項５】
前記前方予備領域のサイズは、送信側の通信プロトコルの組み合わせのうち使用されるプロトコルヘッダの総サイズが最も大きい通信プロトコルのプロトコルヘッダの総サイズから、受信側の通信プロトコルの組み合わせのうち使用されるプロトコルヘッダの総サイズが最も小さい通信プロトコルのプロトコルヘッダの総サイズを差し引いた値以上に設定されていることを特徴とする請求項３または４に記載の通信制御装置。
【請求項６】
前記受信データで使用されている通信プロトコルの組み合わせの少なくとも一部を特定し、該特定したプロトコルと残りの階層のプロトコルとの組み合わせのうち使用されるプロトコルヘッダの総サイズが最大となる通信プロトコルのプロトコルヘッダの総サイズをＹ’、送信側の通信プロトコルの組み合わせのうち使用されるプロトコルヘッダの総サイズが最も大きい通信プロトコルのプロトコルヘッダの総サイズをＸとするとき、Ｘ−Ｙ’を前記前方予備領域のサイズとすることを特徴とする請求項３または４に記載の通信制御装置。
【請求項７】
前記後方予備領域のサイズは、更新を行った場合に想定されるペイロードの最大増加幅に基づいて決定されていることを特徴とする請求項４乃至６の何れか１項に記載の通信制御装置。
【請求項８】
第１の通信コントローラにより第１の回線から受信したデータをアプリケーションにより参照または更新して第２の通信コントローラにより第２の回線に送信する通信制御装置の通信制御方法であって、前記通信制御装置が、前記第１の通信コントローラによる前記第１の回線からのデータ受信時、受信データの格納と該格納した受信データを参照または更新して前記第２の回線に送信する送信データの格納とに兼用するバッファをメモリ上に確保することを特徴とする通信制御方法。
【請求項９】
第１の通信コントローラにより第１の回線から受信したデータをアプリケーションにより参照または更新して第２の通信コントローラにより第２の回線に送信する通信制御装置を構成するコンピュータを、前記第１の通信コントローラによる前記第１の回線からのデータ受信時、受信データの格納と該格納した受信データを参照または更新して前記第２の回線に送信する送信データの格納とに兼用するバッファをメモリ上に確保する手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データの送受信を行う通信制御装置に関する。
【背景技術】
【０００２】
データの送受信を行う通信制御装置においては、受信データや送信データは一時的にバッファに格納され、ＯＳＩ（開放型システム間相互接続）参照モデルの概念に基づいて設計されている階層構造によって、バッファ上で受信データの解析や送信データの組立てが行われる。この種の通信制御装置におけるバッファの管理技術の一例が特許文献１および特許文献２に記載されている。
【０００３】
図５を参照すると、特許文献１に記載された技術（以下、関連技術１と言う）によれば、送信処理は、図５（イ）〜（ハ）に示す手順で行われる。まず、最上位層であるＮ＋１層は、生成したデータａをバッファＢに格納し、Ｎ層に対して先頭アドレスｐ1とバッファレングスｎ1とを通知する（イ）。次にＮ層は、バッファＢ上のデータａの前にデータｂを組立て、Ｎ−１層に対して先頭アドレスｐ2とバッファレングスｎ2とを通知する（ロ）。次にＮ−１層は、バッファＢ上のデータｂの前にデータｃを組立て、Ｐ層に対して先頭アドレスｐ3とバッファレングスｎ3とを通知する。最後にＰ層は、先頭アドレスｐ3からバッファレングスｎ3分のデータを通信回線に送出する（ハ）。
【０００４】
また関連技術１によれば、受信処理は、図５（ニ）〜（ヘ）に示す手順で行われる。まず、Ｐ層は、通信回線からデータを受信してバッファＢに格納し、Ｎ−１層に対して先頭アドレスｑ3とバッファレングスｎ3とを通知する（ニ）。次にＮ−１層は、バッファＢ上のデータｃを受信し、Ｎ層に対して先頭アドレスｑ2とバッファレングスｎ2とを通知する（ホ）。次にＮ層は、バッファＢ上のデータｂを受信し、Ｎ＋１層に対して先頭アドレスｑ1とバッファレングスｎ1とを通知する。Ｎ＋１層はバッファＢ上のデータａを受信する（ヘ）。
【０００５】
他方、特許文献２に記載された技術（以下、関連技術２と言う）によれば、送信処理は次の手順で行われる。まず、送信データの種類や送信先に対応して、使用するプロトコルが各層毎に選択される。例えば、下位層から順にａ、ｂ、ｃの３つの層があり、層ａにはＡ〜Ｃの３種類のプロトコル、層ｂにはＤ〜Ｆの３種類のプロトコル、層ｃにはＧ〜Ｉの３種類のプロトコルがある場合に、層ａのプロトコルとしてＡ、層ｂのプロトコルとしてＤ、層ｃのプロトコルとしてＧがそれぞれ選択されたとする。次に、選択されたプロトコルＡ、Ｄ、Ｇに基づいて、使用されるプロトコルヘッダの総量を計算する。次に、送信データ格納領域に加えて、前記計算したプロトコルヘッダの総量分のヘッダ格納領域を持つバッファを確保し、送信データ格納領域に送信データを格納する。次に、プロトコルＧに制御が移り、プロトコルＧのヘッダがバッファ上の送信データの前に格納される。次に、プロトコルＤに制御が移り、バッファ上のプロトコルＧのヘッダの前にプロトコルＤのヘッダが格納される。次に、プロトコルＡに制御が移り、バッファ上のプロトコルＤのヘッダの前にプロトコルＡのヘッダが格納される。最後に、バッファ上のデータが通信回線に送出される。
【０００６】
【特許文献１】特開平６−２４４９０２号公報
【特許文献２】特開平７−２５０１２４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
関連技術１によれば、各層間で扱うデータを先頭アドレスとバッファレングスとでインタフェースする。このため、各層毎にデータバッファを設け、転送要求を受けたデータをそれらに取込み、必要なデータを付加して次層に転送する方法に比べて、処理が高速になり、メモリ領域を節約することができる。しかし、関連技術１では、送信時、前層のデータの前にデータを付加するための領域を確保するための処理が必要になる。
【０００８】
他方、関連技術２によれば、送信時、ヘッダ総量に見合った領域を含むバッファを確保するため、関連技術１におけるような問題は解消され、送信処理の効率が改善される。
【０００９】
しかしながら、関連技術１および関連技術２共に、送信時と受信時とでバッファを共用する考えはない。このため、１つの通信制御装置において、或る通信回線から受信したデータをアプリケーションで参照または更新して、別の通信回線を通じて他所へ送信する場合、受信データを格納するバッファの確保処理と、送信データを格納するバッファの確保処理との２回の確保処理が必要であった。
【００１０】
本発明はこのような事情に鑑みて提案されたものであり、その目的は、或る通信回線から受信したデータを参照または更新して別の通信回線へ送信する通信制御装置において、バッファ確保処理の回数を削減することにある。
【課題を解決するための手段】
【００１１】
本発明の通信制御装置は、第１の通信コントローラにより第１の回線から受信したデータをアプリケーションにより参照または更新して第２の通信コントローラにより第２の回線に送信する通信制御装置であって、前記第１の通信コントローラによる前記第１の回線からのデータ受信時、受信データの格納と該格納した受信データを参照または更新して前記第２の回線に送信する送信データの格納とに兼用するバッファをメモリ上に確保する。
【発明の効果】
【００１２】
本発明によれば、データ受信時、受信データの格納とこの格納した受信データを参照または更新して別回線に送信する送信データの格納とに兼用するバッファをメモリ上に確保するため、バッファ確保処理の回数を削減することが可能になる。また、バッファ確保処理回数が削減されることにより、通信処理の速度が向上すると共に、処理量の削減により通信制御装置の消費電力の削減が可能になる。
【発明を実施するための最良の形態】
【００１３】
［第１の実施の形態］
図１を参照すると、本発明の第１の実施の形態に係る通信制御装置１００は、ＣＰＵ１０と、ＲＯＭ２０と、ＲＡＭ３０と、２種類の通信コントローラ４０、５０とがバス６０により相互に接続されている。
【００１４】
ＲＯＭ２０は、通信制御装置１００のＣＰＵ１０で実行するプログラムおよび固定データを記憶する。ＲＡＭ３０は、送受信データを記憶するバッファおよび可変データを記憶する。
【００１５】
通信コントローラ４０は、通信回線４１からのデータの受信および通信回線４１へのデータの送信を行う部品である。同じく通信コントローラ５０は、通信回線５１からのデータの受信および通信回線５１へのデータの送信を行う部品である。本実施の形態の場合、通信コントローラ４０はイーサネット（登録商標）用のコントローラ、通信コントローラ５０はシリアルポート用のコントローラである。
【００１６】
ＣＰＵ１０は、通信制御装置１００の主たる制御を行う部品であり、通信の制御に関連する機能手段として、２種類の通信ドライバ処理部１１、１２と、通信プロトコル処理部１３と、通信アプリケーション部１４とを備えている。これらは、例えばＲＯＭ２０に格納されたプログラムにより実現することができる。
【００１７】
通信ドライバ処理部１１は通信コントローラ４０用の通信ドライバ、通信ドライバ処理部１２は通信コントローラ５０用の通信ドライバである。
【００１８】
通信プロトコル処理部１３は、通信ミドルウェアとしてのプロトコルスタックである。本実施の形態の場合、通信プロトコル処理部１３は、Ｌ２処理部１５およびＬ３処理部１６を備えている。Ｌ２処理部１５は、Ｌ２（レイヤ２）、即ちＯＳＩ参照モデルのデータリンク層に関する処理を司る部分であり、Ｌ３処理部１６は、Ｌ３（レイヤ３）、即ちＯＳＩ参照モデルのネットワーク層に関する処理を司る部分である。
【００１９】
通信アプリケーション部１４は、ＯＳＩ参照モデルのトランスポート層以上の層に関する処理を司る部分である。本実施の形態の場合、通信アプリケーション部１４は、Ｌ４（レイヤ４）、即ちトランスポート層に関する処理を司るＬ４処理部１７と、ＯＳＩ参照モデルのセッション層からアプリケーション層までの層に関する処理を司るアプリケーション部１８とで構成されている。
【００２０】
本実施の形態における通信制御装置１００は、通信コントローラ４０により通信回線４１から受信したデータをアプリケーション部１８において参照または更新して、通信コントローラ５０により通信回線５１に送信する通信アダプタ装置として機能する。また、Ｌ２〜Ｌ４の各層には、図２に示すようにそれぞれ複数の通信プロトコルが定義されており、実際のデータの送受信時には、複数の通信プロトコルの中から１つの通信プロトコルが選択されて適用される。
【００２１】
次に、通信回線４１から受信したデータをアプリケーション部１８において参照または更新して通信回線５１に送信する際の本実施の形態の動作を説明する。
【００２２】
図３を参照すると、通信コントローラ４０は、通信回線４１上に自通信制御装置宛のイーサネットフレームを検出すると、当該フレームを受信し、ＣＰＵ１０に割り込みで通知する。ＣＰＵ１０は、この割り込みを契機に通信ドライバ処理部１１を起動する。
【００２３】
通信ドライバ処理部１１は、通信コントローラ４０が受信したフレームを格納するためのバッファＢＵＦをＲＡＭ３０の空き領域に確保し、受信データ（受信フレーム）をバッファＢＵＦに格納する。このとき確保したバッファＢＵＦは、受信データの格納に使用する他、この受信データを参照または更新して通信回線５１に送信する際の送信データの格納用にも使用する。送信データのサイズが受信データのサイズを超えないことが保証されていれば、確保するバッファＢＵＦのサイズは受信データのサイズのみを考慮して決定すれば良い。しかし、受信と送信とで各層で使用するプロトコルが相違する結果、送信データのプロトコルヘッダの総サイズが受信データのプロトコルヘッダの総サイズを超える場合には、少なくとも超過する分だけサイズの大きなバッファＢＵＦを確保しておく必要がある。また、アプリケーション部１８がＬ４階層のペイロードを更新した結果、ペイロードのサイズが増加する場合、プロトコルヘッダによる増加分に加えて、ペイロードによる増加分も考慮したサイズのバッファＢＵＦを確保しておく必要がある。通信ドライバ処理部１１は、これらのことを踏まえて確保するバッファＢＵＦのサイズを決定する機能を有する。この機能の詳細については後述するが、今は説明の便宜上、図４に示すバッファＢＵＦが確保されたものとする。
【００２４】
図４に示すバッファＢＵＦは、ＲＡＭ３０のアドレスａ0からａ1までの領域が割り当てられている。また、バッファＢＵＦは、アドレスａ0からアドレスａ2までのサイズｎ0の前方予備領域と、アドレスａ2からアドレスａ6までのサイズｎ2のデータ格納領域と、アドレスａ6からアドレスａ1までのサイズｎ1の後方予備領域とに論理的に区分されている。データ格納領域は、受信データを格納するための領域である。前方予備領域は、送信データのプロトコルヘッダの総サイズが受信データのものより大きくなった場合に使用する拡張領域、後方予備領域は、ペイロードのサイズが更新により拡大した場合に使用する拡張領域である。
【００２５】
通信ドライバ処理部１１は、受信データを図４に示すようにバッファＢＵＦのデータ格納領域に格納し、データ格納領域の先頭アドレスａ2と受信データ長（＝データ格納領域のサイズｎ2）とを通信プロトコル処理部１３のＬ２処理部１５に通知する。図４に示したように、受信データは、ペイロードと、その前に付けられたＬ４ヘッダと、その前に付けられたＬ３ヘッダと、その前に付けられたＬ２ヘッダとで構成されている。
【００２６】
Ｌ２処理部１５は、バッファＢＵＦ上の通知されたアドレスａ2以降に格納されたＬ２ヘッダを解析してＬ２に適用されているプロトコルを識別し、そのプロトコルによる処理を実行する。そして、Ｌ２処理部１５は、Ｌ３ヘッダの先頭アドレスａ3とＬ３のデータ長ｎ3とをＬ３処理部１６に通知する。
【００２７】
Ｌ３処理部１６は、バッファＢＵＦ上の通知されたアドレスａ3以降に格納されたＬ３ヘッダを解析してＬ３に適用されているプロトコルを識別し、そのプロトコルによる処理を実行する。そして、Ｌ３処理部１６は、Ｌ４ヘッダの先頭アドレスａ4とＬ４のデータ長ｎ4とを通信アプリケーション部１４のＬ４処理部１７に通知する。
【００２８】
Ｌ４処理部１７は、バッファＢＵＦ上の通知されたアドレスａ4以降に格納されたＬ４ヘッダを解析してＬ４に適用されているプロトコルを識別し、そのプロトコルによる処理を実行する。そして、Ｌ４処理部１７は、ペイロードの先頭アドレスａ5とデータ長ｎ5とをアプリケーション部１８に通知する。
【００２９】
アプリケーション部１８は、バッファＢＵＦ上の通知されたアドレスａ5以降に格納されたペイロードを参照または更新する。ペイロードを参照する目的は、例えば、ペイロード中のデータの種類や送信先を識別することである。また、ペイロードを更新する目的は、例えば、データの形式を別の形式に変換したり、送信先を変更したりすることである。データ形式の変換は文字コードレベルで行われるために、ペイロードのサイズが変更される可能性がある。また、ＳＩＰ−ＵＲＩで送信先が記述されている場合、ＳＩＰ−ＵＲＩの書換えは文字コードレベルで行われるために、ペイロードのサイズが変更される可能性がある。
【００３０】
アプリケーション部１８は、受信したペイロードを更新した場合、更新後のペイロードを送信データに含めるペイロードとして、バッファＢＵＦのアドレスａ5以降の領域、つまり元のペイロード部分に上書きする。図４は、送信データに含めるペイロードがバッファＢＵＦのアドレスａ5からアドレスａ7までの領域に格納された例を示している。なお、参照だけで更新しない場合には、元のペイロードがバッファＢＵＦのアドレスａ5以降に格納されているので、それをそのまま送信データに含めるペイロードとして使用する。
【００３１】
次にアプリケーション部１８は、送信データの種類や送信先に基づいて、Ｌ４、Ｌ３、Ｌ２の各層で使用するプロトコルを決定する。ここでは、説明の便宜上、Ｌ４はプロトコルＧ、Ｌ３はプロトコルＤ、Ｌ２はプロトコルＡにそれぞれ決定されたものとする。決定されたプロトコルの情報は例えばＲＡＭ３０の所定のエリアに記憶され、Ｌ４処理部１７、Ｌ３処理部１６およびＬ２処理部１５によって参照される。
【００３２】
次にアプリケーション部１８は、Ｌ４処理部１７に対して、ペイロードの先頭アドレスａ5とデータ長ｎ'5とをＬ４処理部１７に通知する。
【００３３】
次にＬ４処理部１７は、バッファＢＵＦ上の通知されたアドレスａ5以降に格納されたペイロードの前にプロトコルＧのＬ４ヘッダを書き込み、書き込んだＬ４ヘッダの先頭アドレスａ8とデータ長ｎ'4を通信プロトコル処理部１３のＬ３処理部１６に通知する。
【００３４】
次にＬ３処理部１６は、バッファＢＵＦ上の通知されたアドレスａ8以降に格納されたＬ４ヘッダの前にプロトコルＤのＬ３ヘッダを書き込み、書き込んだＬ３ヘッダの先頭アドレスａ9とデータ長ｎ'3をＬ２処理部１５に通知する。
【００３５】
次にＬ２処理部１５は、バッファＢＵＦ上の通知されたアドレスａ9以降に格納されたＬ３ヘッダの前にプロトコルＡのＬ２ヘッダを書き込み、書き込んだＬ２ヘッダの先頭アドレスａ10とデータ長ｎ'2を、プロトコルＡを扱う通信コントローラ５０の通信ドライバ処理部１２に通知する。
【００３６】
次に通信ドライバ処理部１２は、バッファＢＵＦ上の通知されたアドレスａ10以降に格納されたＬ２のデータを読み出し、通信コントローラ５０へ送信する。通信コントローラ５０は受信したデータを通信回線５１へ送信する。通信コントローラ５０による送信が完了すると、通信ドライバ処理部１１は、送信データを格納していたバッファＢＵＦを解放する。
【００３７】
次に、受信データと送信データとで共用する図４のバッファＢＵＦのサイズｎ0、ｎ1、ｎ2を決定する方法について、幾つかの例を挙げて説明する。
【００３８】
（１）バッファＢＵＦのデータ格納領域のサイズｎ2の決定方法
サイズｎ2は、受信データを格納するデータ格納領域のサイズであるため、受信データのサイズに基づき決定する。例えば、サイズｎ2は、受信データのサイズと等しい値とする。
【００３９】
（２）バッファＢＵＦの前方予備領域のサイズｎ0の決定方法
サイズｎ0は、送信データのプロトコルヘッダの総サイズが受信データのものより大きくなった場合に使用する前方予備領域のサイズであるため、送信データおよび受信データのプロトコルヘッダの総サイズの差異に基づいて決定する。具体的な方法として、以下のような方法がある。
【００４０】
（2−1）例１
送信時の通信プロトコルの組み合わせのうち使用されるプロトコルヘッダの総サイズが最も大きい通信プロトコルのプロトコルヘッダの総サイズをＸ、受信時の通信プロトコルの組み合わせのうち使用されるプロトコルヘッダの総サイズが最も小さい通信プロトコルのプロトコルヘッダの総サイズをＹとするとき、Ｘ−Ｙを前方予備領域のサイズｎ0とする。この方法によれば、実際の受信データの通信プロトコルのＬ２〜Ｌ４のヘッダの総サイズが最小値のＹに等しく、実際の送信データの通信プロトコルのＬ２〜Ｌ４のヘッダの総サイズが最大値のＸに等しくなる場合に、前方予備領域のサイズｎ0の全てが使用されることになり、それ以外のケースでは、前方予備領域の一部が使用されるか、あるいは全く使用されないことになる。バッファ使用量の面で多少無駄が生じるものの、Ｘ−Ｙを予め計算してＲＯＭ２０等の固定データとして記憶しておけば、それを参照するだけで済むため、処理量は少なくなる。
【００４１】
（2−2）例２
通信ドライバ処理部１１が、受信データで使用されている通信プロトコルの組み合わせの一部または全部を特定し、この特定したプロトコルと残りの階層のプロトコルとの組み合わせのうち使用されるプロトコルヘッダの総サイズが最大となる通信プロトコルのプロトコルヘッダの総サイズをＹ’とするとき、Ｘ−Ｙ’を前方予備領域のサイズｎ0とする。ここで、Ｘは、例１におけるＸと同じく、送信時の通信プロトコルの組み合わせのうち使用されるプロトコルヘッダの総サイズが最も大きい通信プロトコルのプロトコルヘッダの総サイズである。
【００４２】
通信ドライバ処理部１１が、受信データで使用されている通信プロトコルの組み合わせの一部を特定する方法としては、例えば、データの受信時に割り込みをかけてきた通信コントローラ４０の種類によって、Ｌ２で使用されるプロトコルをプロトコルＡ〜Ｃの内の何れか１つまたは２つに特定する方法がある。また、通信ドライバ処理部１１が通信コントローラ４０に保持されている受信データを直接参照して、Ｌ２ヘッダ等、各ヘッダを解析して使用されているプロトコルを特定する方法がある。
【００４３】
（３）バッファＢＵＦの後方予備領域のサイズｎ1の決定方法
サイズｎ1は、ペイロードのサイズが更新により拡大した場合に使用する後方予備領域のサイズであるため、アプリケーション部１８によるペイロードの更新の有無および更新する場合の最大増加幅に基づいて決定する。すなわち、アプリケーション部１８がペイロードの更新を行わない仕様であるならば、後方予備領域のサイズｎ1は０である。また、更新を行った場合に想定される最大増加幅がΔｄであれば、後方予備領域のサイズｎ1はΔｄである。
【００４４】
次に本実施の形態の効果を説明する。
【００４５】
本実施の形態によれば、通信回線４１から受信したデータをアプリケーション部１８において参照または更新して通信回線５１を通じて他に送信する通信制御装置１００において、受信と送信とで同じバッファＢＵＦを使用可能としたことにより、バッファ確保処理の回数を半分に削減することができる。バッファ確保処理回数が半分に削減されることにより、通信処理の速度が向上すると同時に、処理量の削減により通信制御装置１００の消費電力の削減も可能になる。
【００４６】
［その他の実施の形態］
以上の実施の形態は、通信回線４１から受信したデータをアプリケーション部１８において参照または更新して通信回線５１に送信したが、その反対に、通信回線５１から受信したデータをアプリケーション部１８において参照または更新して通信回線４１に送信する実施の形態も考えられる。この場合、通信ドライバ処理部１２に、通信ドライバ処理部１１と同様のバッファ獲得機能が備えられる。
【００４７】
以上の実施の形態は、通信コントローラとして、イーサネット用のコントローラ、シリアルポート用のコントローラを使用したが、本発明における通信コントローラはこれらの種類に限定されず、トークンリングやＸ.25などの他の種類の通信コントローラであっても良い。
【００４８】
以上の実施の形態は、通信コントローラを２種類だけ備えていたが、３種類以上の通信コントローラを備えていても良い。
【００４９】
以上の実施の形態は、物理層の上位層として、Ｌ２、Ｌ３、Ｌ４の３層を持つ階層構造を例にしたが、ＯＳＩ参照モデルの概念に基づいて設計された階層構造であれば全て適用可能である。
【図面の簡単な説明】
【００５０】
【図１】本発明の第１の実施の形態のブロック図である。
【図２】本発明の第１の実施の形態における各層で使用可能な通信プロトコルを示す図である。
【図３】本発明の第１の実施の形態の動作説明図である。
【図４】本発明の第１の実施の形態におけるバッファの説明図である。
【図５】本発明の関連技術の説明図である。
【符号の説明】
【００５１】
１０…ＣＰＵ
１１、１２…通信ドライバ処理部
１３…通信プロトコル処理部
１４…通信アプリケーション部
１５…Ｌ２処理部
１６…Ｌ３処理部
１７…Ｌ４処理部
１８…アプリケーション部
２０…ＲＯＭ
３０…ＲＡＭ
４０、５０…通信コントローラ
４１、４２…通信回線
６０…バス
１００…通信制御装置
【図１】
2010062981.tif 000003
【図２】
2010062981.tif 000004
【図３】
2010062981.tif 000005
【図４】
2010062981.tif 000006
【図５】
2010062981.tif 000007