JPH10229429A - 通信ネットワークシステム - Google Patents

Abstract

(57)【要約】 【課題】 通信中に、受信側から通知された内容に基づ
いて送信側の送信動作を制御する構成とすると、制御が
最適とならない場合があった。 【解決手段】 レイヤコネクションの設定時に、送信側
及び受信側の通信バッファに必要とされるバッファ量を
算出し、当該算出されたバッファ量を各通信バッファに
確保するバッファ管理手段を通信ネットワークシステム
に備えるようにする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、高速ネットワーク
上における高信頼、高効率、かつ高速なデータ通信を実
現するための通信プロトコルの方式に関するものであ
る。

【０００２】

【従来の技術】

文献名：ＸＴＰプロトコルにおけるレート制御機構の評
価 マルチメディア通信と分散処理 ５９−１（１９９３．
１．２９） 今日における伝送路の高速化は目覚ましく、コンピュー
タ間通信におけるスループットのボトルネックは、伝送
路の速度から計算機の処理能力や通信プロトコルの性能
等へと移りつつある。上記文献は、かかるスループット
のボトルネックとなる問題のうち、通信プロトコルにつ
いて記述したものである。

【０００３】そして、上記文献では、その「2.3 ＸＴＰ
プロトコルにおけるレート制御」の章において、送受信
間の通信においては、受信側からの制御パケットである
ＣＮＴＬパケットにより要求するスループット値である
rate及び１バーストでの送信バイト数であるburst の各
パラメータ値を送信側に指示し、受信側の処理許容量に
応じたペースで送信側がパケット送信することにより、
高速通信を可能とし、スループットの向上を目指すこと
が記載されている。

【０００４】

【発明が解決しようとする課題】ところで、上記文献
（特に、「4.2 パラメータの変更を行なうタイミン
グ」）には、当該文献に示されるＸＴＰプロトコルの手
順にて高速ネットワーク通信を行なう場合、スループッ
ト値及びバースト値の変更タイミングとして、次の３つ
の(ａ)〜(ｃ)の時点等が考えられることが記述されてい
るものの、かかるタイミングでは、受信側で各パラメー
タ値を常に適正な値が算出されるようにしようとして
も、他のコネクションの設定やアプリケーション状態の
変化などの不確定要素が多く困難であるという課題があ
った。

【０００５】(ａ)送信側で予想する又はデフォルトのス
ループット値及びバースト値での最初のパケット受信時 (ｂ)受信処理能力を越えた時点 (ｃ)受信処理能力に余裕があると分かった時点 また、これに加え、上記(ａ)においては適正な値ではな
いこと、(ｂ)においては既に受信能力を越えているの
で、伝送路が長距離の場合には、既に送信側から送出済
みであるパケットが処理不能となること、(ｃ)において
は伝送路帯域を有効に使用できていないこと等により、
高速ネットワークにて有効なスループットを発生できな
いという課題があった。

【０００６】

【課題を解決するための手段】

（Ａ） かかる課題を解決するため、第１の発明におけ
る通信ネットワークシステムにおいては、レイヤコネク
ションの設定時に、送信側及び受信側の通信バッファに
必要とされるバッファ量を算出し、当該算出されたバッ
ファ量を各通信バッファに確保するバッファ管理手段を
備えるようにする。

【０００７】以上のように、第１の発明によれば、レイ
ヤコネクションの設定段階で、予め必要とされるバッフ
ァ量を算出してこれを送信側及び受信側の双方の各通信
バッファに確保するので、各コネクションごとに最適な
状態で通信を開始でき、高いスループットを実現でき
る。

【０００８】（Ｂ） また、第２の発明における通信ネ
ットワークシステムにおいては、上位レイヤが送信デー
タの書込みアドレスを指定するのに先立って、当該送信
データを書き込むべき通信バッファ上のアドレスを、そ
の都度、上位レイヤに対して事前に通知する書込みアド
レス管理手段を備えるようにする。

【０００９】以上のように、第２の発明によれば、上位
レイヤは、事前に、送信データを書き込むべきアドレス
を認識できるので、無駄なメモリコピーを行わなくて済
み、高速なスループットを実現できる。

【００１０】（Ｃ） さらに、第３の発明における通信
ネットワークシステムにおいては、受信側の通信バッフ
ァに確保されたバッファ量と、受信側から応答のあった
送信データに対する肯定応答の受信回数とに基づいて、
上記受信側の通信バッファに現存するバッファ残量を常
時監視するバッファ残量監視手段を送信側に備えるよう
にする。

【００１１】以上のように、第３の発明によれば、送信
側において、常時、受信側の通信バッファのバッファ残
量を監視できるので、バッファ残量に余裕がある限り、
肯定応答を待たずに後続する送信データを送信でき、ス
ループットを向上させることができる。

【００１２】

【発明の実施の形態】

（Ａ）実施形態 （Ａ−１）実施形態の構成 以下、本実施形態に係るプロトコル処理を実行するプロ
トコル処理部の構成を、図面を参照しつつ説明する。図
２は、本実施形態に係るプロトコル処理部のＯＳＩ（Op
en System Interconnection ）レイヤ構造上での位置づ
けを表した図である。図２に示すように、当該プロトコ
ル処理部の処理は、トランスポート層及びネットワーク
層での処理に対応している。

【００１３】図３は、このプロトコル処理部の機能構成
を表したブロック図である。図３に示すように、本実施
形態に係るプロトコル処理部１は、通信メモリバッファ
２、受信メモリバッファ３、メモリ管理部４、ヘッダ処
理部５及びプロトコル制御部６からなる。

【００１４】ここで、送信メモリバッファ２は、通信時
にネットワークへ送信される送信データを一時格納する
のに用いられるバッファである。受信メモリバッファ３
は、通信時にネットワークを介して受信された受信デー
タを一時格納するのに用いられるバッファである。

【００１５】メモリ管理部４は、送信メモリバッファ２
及び受信メモリバッファ３の読み書き及び領域管理を実
行する管理部であり、アプリケーション部（図２）から
要求があった場合、要求に応じてアプリケーションデー
タ部とプロトコルヘッダ部に対応するメモリ領域を図４
に示す構成で確保する。また、メモリ管理部４は、アプ
リケーション部（図２）に対して、次の送信バッファア
ドレス及び受信バッファアドレスを通知すると共に、送
信処理及び受信処理の完了したメモリバッファの解放及
び再利用が巡回的に行われるよう制御しかつ管理する。

【００１６】ヘッダ処理部５は、送信パケットについて
のヘッダ情報の作成、受信バッファについてのヘッダ情
報の解析を行ない、パケットデータの誤り検出及び回復
処理を制御する。

【００１７】プロトコル制御部６は、パケットの送信・
受信に関する一連の動作を制御する手段であり、送信時
には受信メモリバッファ３の管理を行なって、送信ぺー
スを制御するようになっている。

【００１８】（Ａ−２）実施形態の動作 続いて、送信側及び受信側の端末間において実行される
通信プロトコル手順を、図１、図５及び図６を用いて説
明する。なおここで、図１は、送信側のプロトコル処理
部１が受信側との間で実行する主要な処理手順を表した
図であり、図５は、受信側のプロトコル処理部１が送信
側との間で実行する主要な処理手順を表した図である。
また、図６は、図１及び図５の制御に基づいて実現され
る通信プロトコル手順の全体を表す図である。

【００１９】なお、以下の説明においては、図６に示す
処理の流れに沿って、本実施形態に係る通信プロトコル
手順を説明する。また、以下の項目記号(ａ)〜(ｈ)は、
それぞれ図６の該当部分での動作を示している。

【００２０】(ａ)送信開始要求動作 まず、送信側のアプリケーション部からプロトコル処理
部１のプロトコル制御部６に対して「送信開始要求」が
通知される。この「送信開始要求」は、次の（a1）及び
（a2）の情報からなる。

【００２１】（a1）送信データを渡す際のデータ単位サ
イズ （a2）最大受渡しレート（例えば、１秒間に最大何回の
データを受渡すか） プロトコル制御部６は、この要求を入力すると、受信側
端末間でのコネクションの設定に必要な情報（一般的に
従来から必要とされている情報）及び送信時のタイムス
タンプを含む要求（以下、「コネクション設定要求」と
いう）をネットワークを介して受信側のプロトコル処理
部１６に対して送信する。この送信処理が、図１のステ
ップＳＰ１の処理である。

【００２２】(ｂ)コネクション設定要求動作 一方、受信側のプロトコル処理部１においては、受信側
のアプリケーション部からの「受信開始要求」をプロト
コル制御部６で受け、送信側から「コネクション設定要
求」が通知されるのを待ち受ける動作状態になる。この
処理が、図５のステップＳＰ１１の処理である。

【００２３】やがて、「コネクション設定要求」がネッ
トワークを介して受信されたことが確認されると、受信
側のプロトコル制御部６は、コネクション設定の受け入
れ準備を行ない、受信されたタイムスタンプ情報をその
まま含む「コネクション設定確認」を、送信側のプロト
コル制御部６へ返信する。この送信処理が、図５のステ
ップＳＰ１２の処理である。

【００２４】なおここでのコネクション設定の受け入れ
準備とは、従来のＴＣＰプロトコルで見られるようなア
プリケーションポート番号の割り当て等の処理である。

【００２５】(ｃ)リソース確保要求動作 次に、送信側のプロトコル制御部６は、「コネクション
設定確認」が受信されると、受け取った確認に含まれて
いる、「コネクション設定要求」を送出した時点でのタ
イムスタンプ情報とこれに対する確認が到着した時点
（現在）のタイムスタンプ情報から伝送路往復遅延時間
（ラウンドトリップタイム：以下、ＲＴＴという）を計
算する。そして、当該プロトコル制御部６は、計算によ
り求めたＲＴＴと、上記（a2）の最大レートと、送受信
データの処理に要する予測処理時間とを次の計算式に代
入し、最大受渡しレートでデータ送信するときに必要と
なるバッファ量を算出する。

【００２６】バッファ量＝(最大受渡しレート)×(ＲＴ
Ｔ＋(送信処理時間＋受信処理時間) この処理が、図１のステップＳＰ３の処理である。そし
て、当該量を計算により求めたプロトコル制御部６は、
このバッファ量と上記（a1）の受渡しデータ単位サイズ
を含む「リソース確保要求」を、受信側のプロトコル制
御部６に送信する。この処理が、図１のステップＳＰ４
の処理である。

【００２７】(ｄ)リソース確保応答動作 受信側のプロトコル制御部６は、前述の(ｂ)で「コネク
ション設定確認」を送出した後、「リソース確保要求」
が受信されるの待ち受ける状態にある。この処理が、図
５のステップＳＰ１３の処理である。

【００２８】「リソース確保要求」が受信されたことが
確認されると、プロトコル制御部６は、当該プロトコル
メッセージに含まれるバッファ量情報と受渡しデータ単
位サイズをメモリ管理部４に通知し、通信に必要な量の
バッファ領域の確保を要求する。この処理が、図５のス
テップＳＰ１４の処理である。

【００２９】メモリ管理部４は、図３において示したア
プリケーションデータ部の総量が、送信側から要求され
た上記バッファ量になり、かつ、１つのアプリケーショ
ンデータ部のサイズがアプリケーション受渡しデータ単
位サイズになるように、図３に示す構造で領域を受信メ
モリバッファ３上に確保する。ただし、この場合にメモ
リ不足等が起きる場合には、その時点で確保可能な適当
な量のバッファ領域を確保することになる。いずれにし
ても、メモリ管理部４は、実際に確保できた結果をプロ
トコル制御部６に通知する。プロトコル制御部６は、実
際に確保できたバッファ量を情報として含んだ「リソー
ス確保応答」を、送信側へ送信する。この処理が、図５
のステップＳＰ１５の処理である。

【００３０】この後、プロトコル制御部６は、自装置内
のアプリケーション部に対して「受信開始確認」を通知
し、受信準備が整ったことを通知する。受信側のアプリ
ケーション部は、この通知を受信すると、「次データ受
信開始」をプロトコル制御部６に通知する。「次データ
受信開始」を通知されたプロトコル制御部６は、受信デ
ータ待ちとなる。この処理が、図５のステップＳＰ１６
の処理である。

【００３１】(ｅ)送信開始確認動作 送信側のプロトコル制御部６は、受信側から「リソース
確保応答」を受信すると、受信メッセージ中に含まれる
実際に確保されたバッファサイズと受渡しデータ単位サ
イズをメモリ管理部４に通知する。この処理が、図１の
ステップＳＰ５の処理である。

【００３２】このとき、メモリ管理部４は、前述の(ｄ)
の処理において受信側のメモリ管理部４が行ったのと同
様に通信メモリバッファ２上にバッファ領域を確保す
る。この処理が、図１のステップＳＰ６の処理である。
この後、メモリ管理部４は、自装置内（送信側）のアプ
リケーション部に対し、通信メモリバッファ２上に確保
されている最初のアプリケーションデータ部の先頭アド
レスを、「送信開始確認」として通知する。

【００３３】(ｆ)「データ送信−１」及び「データ１送
信」動作 前述の(ｅ)での通知を受けた送信側のアプリケーション
部は、受渡しデータサイズ分の送信データを、上記通知
によって特定されたアドレスに対して書き込み、そのこ
とを「データ送信−１」としてプロトコル処理部１に通
知する。ここで、「データ送信−１」は、１回目の送信
データの書込みが完了したことを意味する。またこのと
き、アプリケーション部が書き込むデータサイズは、必
ずしもデータサイズ分である必要はない。

【００３４】送信側のプロトコル処理部１では、「デー
タ送信−１」が通知されると、ヘッダ処理部５によっ
て、書き込まれたアプリケーションデータ部を処理して
誤り訂正情報を作成すると共に、パケットシーケンス番
号、送信側ポート番号、受信側ポート番号、パケット種
別等の情報を作成する。ヘッダ処理部５は、この情報
を、通信メモリバッファ２のうち該当するアプリケーシ
ョンデータ部のヘッダ情報部に書き込む。これらの処理
が、図１のステップＳＰ７の処理である。

【００３５】以上の処理が終了すると、プロトコル制御
部６は、「データ１送信」として通信メモリバッファ２
上に書き込まれているヘッダ情報及びアプリケーション
データを、パケットとして受信側のプロトコル処理部１
へ送信する。このとき、送信されるパケットは、アプリ
ケーション部が書き込みを行なったアプリケーションデ
ータの実データ長に関わらず、確保した１パケット分の
固定長での送信である。この処理が、図１のステップＳ
Ｐ８の処理である。

【００３６】その後、送信側のプロトコル処理部１のメ
モリ管理部４は、通信メモリバッファ２上に存在する次
のアプリケーションデータ部の先頭アドレスを、「次デ
ータ送信開始」としてアプリケーション部に通知する。

【００３７】ここで、「データ送信−１」及び「次デー
タ送信開始」などの処理は、プログラム上での関数コー
ル及び関数リターンなどに該当する形式で行なわれるこ
とが望ましい。

【００３８】(ｇ)「データ受信−１」、「次データ受信
開始」及び「データ１受信確認」動作 受信側のプロトコル処理部１では、前述の(ｄ)の処理の
後、データが受信されるのを待ち受ける状態になってい
るが、やがて、ネットワークを介して「データ１送信」
が受信されると、当該受信パケットを、受信メモリバッ
ファ３に書き込む。

【００３９】この書込みが終了すると、ヘッダ処理部５
がヘッダ解析の他、誤り検出及び訂正処理を行なう。こ
の処理が、図５のステップＳＰ１７の処理である。ここ
で検査結果等が正常であれば、メモリ管理部４が、受信
メモリバッファ３に書き込まれた受信パケットのアプリ
ケーションデータ部の先頭アドレスを「データ受信−
１」としてアプリケーション部へ通知する。この処理
が、図５のステップＳＰ１８で肯定結果が得られてステ
ップＳＰ１９に移行する処理である。

【００４０】かかる処理が終了すると、「データ受信−
１」によって受信データを渡されたアプリケーション部
は、次データの取得のために「次データ受信開始」を、
そのプロトコル処理部１に対して通知する。なお、この
「次データ受信開始」の通知を受けたメモリ管理部４で
は、アプリケーション部に対して前回通知したアドレス
に該当する受信メモリバッファ３上の領域を再利用のた
めに解放する。

【００４１】その後、ヘッダ処理部５が応答のヘッダを
作成するので、これをプロトコル処理部１が、「データ
１受信確認」として、送信側のプロトコル処理部１に対
して送信される。

【００４２】ところで、前述の誤り検出処理時において
パケットデータに誤りが検出された場合、ヘッダ処理部
５は、パケットの再送を求めるため、ＮＡＣＫを即座に
送信側に送信し、この際には受信バッファメモリ３への
データ書き込みは行なわない。この処理が、図５におけ
るステップＳＰ１８で否定結果が得られ、ステップＳＰ
２１に移行する処理である。

【００４３】(ｈ)「コネクション解放要求」及び「コネ
クション解放確認」動作 以後、前述(ｆ)〜(ｇ)の処理が繰り返され、データの送
信が行なわれる。これは、図１のステップＳＰ９−ステ
ップＳＰ７−ステップＳＰ８の繰り返しループ処理及び
図５のステップＳＰ２０−ステップＳＰ１６−ステップ
ＳＰ１７−ステップＳＰ１８−ステップＳＰ１９、２１
の繰り返しループ処理に該当する。

【００４４】なおこのとき、送信側のプロトコル制御部
６では、受信側で確保されているバッファ量、受信側の
プロトコル処理部１へのパケット送信の回数、その応答
の受信回数から受信側の確保バッファの空き容量を常に
監視し続けている。従って、受信側の受信メモリバッフ
ァ３に空き容量がある限りにおいては、パケットの送信
を送信側のアプリケーション部の要求に応じて送り続け
ることになる。このことを、図６の２回目の送信パケッ
トが１回目の送信パケットの応答を待たずに送出されて
いることが表している。

【００４５】またこのとき、送信側のプロトコル処理部
１は、「データ１受信確認」などの正常な受信の確認を
通知する応答が受信された時、送信メモリバッファメモ
リ２のうち該当する部分の領域を管理部４が解放するよ
うになっている。

【００４６】ただし、このとき、受信側のヘッダ処理部
５が受信されたパケットにデータ誤りを検出し、「デー
タ１受信確認」などで異常応答を示す再送要求（ＮＡ
Ｋ）を送信側に通知した場合には、受信側のプロトコル
処理部１は、誤りの検出されたパケット以降のデータを
受信メモリバッファ３上に蓄積したままの状態にするよ
う動作する。他方、送信側のプロトコル処理部１は、次
の送信で、即座に該当パケットのみの再送を行なう選択
再送方式による再送を行なう。受信側では、再送パケッ
トの処理を行ない正常が確認された場合には、「データ
１受信確認」を送信側に返信するとともに、蓄積してお
いた受信メモリバッファ３上のアプリケーションデータ
を順次通知して行く。

【００４７】なお、上記の説明において、選択再送方式
については周知の技術であるので特に説明は付加しな
い。また、コネクション解放の手順についても、本実施
形態の本論とは直接関係ないので、これも詳細な説明は
省略する。いずれにしても、一連の処理の終了が確認さ
れると、設定されたコネクションが解放される。この処
理が、図１のステップＳＰ１０及び図５のステップＳＰ
２２の動作である。

【００４８】また、上記の動作説明における各通知メッ
セージなどは説明の簡単化のために明解な名前を付与し
ているが、実際の実装に強制されるものではない。同様
に、通知などの語句も実装方法に制限を与えるものでは
ない。

【００４９】（Ａ−３）実施形態の効果 以上のように本実施形態によれば、以下に示す効果が得
られる。

【００５０】(1) まず、第１に、「実施形態の動作」
の(ｃ)において示したように、通信開始に先立って送信
側のプロトコル処理部が、伝送路往復遅延時間（ＲＴ
Ｔ）とデータ処理時間に基づいて最大受渡しレートでデ
ータ送信をする場合に必要となるバッファ量を算出し、
これを受信側の受信バッファメモリ３上に確保するよう
にしたことにより、また、確保できない場合でも実際に
確保できたバッファ量を送信開始前に送信側に通知する
ようにしたことにより、送信側のアプリケーション部が
最大受渡しレートでデータを送信する合にも、ある時点
で受信されたパケットに対する正常受信（ＡＣＫ）が送
信側に到着するまでは、送信側が連続してパケットを送
信し続けることが可能となる。つまり、伝送路に空き時
間を作ることなく、パケットを連続的に送信することに
なるので、スループットの向上が期待できる。

【００５１】しかも、コネクションごとにバッファ量の
設定が可能となるので、伝送路の能力速度の許容値まで
のスループットが確保可能である。

【００５２】また、受信側で受信パケットに誤りを検出
した場合にも、ＮＡＣＫを送信側に通知し、送信側では
選択再送方式による該当パケットのみの再送を、ＮＡＣ
Ｋ受信後に即座に行なう再送方式で行なうことにより、
受信側では、送信側からの再送パケットが到着するまで
に送信側から送り出された全てのパケットを受信メモリ
バッファ３においてバッファリング可能であることか
ら、パケット誤り時にもスループットは低下しない。

【００５３】(2) 第２に、送信メモリバッファ２及び受
信メモリバッファ３に固定構造でメモリ領域を確保し、
送受信パケットを固定長で扱い、アプリケーションから
のデータを分割しないことにより、パケット長の計算に
よるオーバヘッド及びパケットに付随するヘッダ部分の
削減、データ分割と組み立てにかかる処理時間の削減が
可能となり、スループットの向上が実現できる。

【００５４】また、より高速化を実現するためのハード
ウェア処理の実現も容易である。

【００５５】(3) 第３に、上記(1) の受信バッファ量
と、ＡＣＫ受信による受信側バッファ量の残量を送信側
で管理するようにしたことにより、受信側の受信データ
の処理ペースに応じて送信側がデータ送信することが可
能となり、受信側バッファのオーバーフローの防止が可
能となる。またその時点での最適なスループットを実現
できるようになる。

【００５６】(4) 第４に、プロトコル処理部内で確保し
たバッファメモリをアドレス通知という形でアプリケー
ション部に公開する方式をとることにより、余分なメモ
リコピーを行なう必要がなくなり、高速なプロトコル処
理が可能となる。

【００５７】(5) 第５に、データ誤りのあるパケット受
信の際には、即座に通信側に再送要求を行なうようにし
たことにより、再送による遅延を最小限に抑えることが
可能となる。

【００５８】（Ｂ）他の実施形態 (B-1) なお、上述の実施形態においては、本方式で実
現されるプロトコル処理部を、ＯＳＩレイヤ階層におけ
るネットワーク層及びトランスポート層に適用する場合
について述べたが、本方式を実施する環境としては、実
施形態のような計算処理能力とメモリ装置とを有する計
算機であれば他のレイヤ階層にも適用可能である。

【００５９】すなわち、本機能の適用としては、通信機
能を具備するコンピュータ端末の内部機能、又は、外部
のフロントエンドプロセッサとしての位置づけである通
信装置等に実装されることとなる。

【００６０】(B-2) また、上述の実施形態において説
明した方式は、特に、光ファイバを用いた高速、広帯域
ネットワークと呼ばれるネットワークにて適用した場合
に最も効果を発揮する。

【００６１】

【発明の効果】上述のように、第１の発明によれば、レ
イヤコネクションの設定時に、送信側及び受信側の通信
バッファに必要とされるバッファ量を算出し、当該算出
されたバッファ量を各通信バッファに確保するバッファ
管理手段を通信ネットワークシステムに備えるようにし
たことにより、各コネクションごとに最適な状態で通信
を開始することができる。

【００６２】また、第２の発明によれば、上位レイヤが
送信データの書込みアドレスを指定するのに先立って、
当該送信データを書き込むべき通信バッファ上のアドレ
スを、その都度、上位レイヤに対して事前に通知する書
込みアドレス管理手段を通信ネットワークシステムに備
えるようにしたことにより、無駄なメモリコピーを行う
おそれを有効に回避でき、その分、スループットを一段
と向上することができる。

【００６３】さらに、第３の発明によれば、受信側の通
信バッファに確保されたバッファ量と、受信側から応答
のあった送信データに対する肯定応答の受信回数とに基
づいて、上記受信側の通信バッファに現存するバッファ
残量を常時監視するバッファ残量監視手段を通信ネット
ワークシステムの送信側に備えるようにしたことによ
り、送信側において、受信側の通信バッファのバッファ
残量に余裕があると判断できる限り、肯定応答を待たず
に後続する送信データを送信でき、スループットを向上
させることができる。

【図面の簡単な説明】

【図１】実施形態に係るプロトコル処理部が送信時に使
用する処理手順を示すフローチャートである。

【図２】プロトコル処理部のＯＳＩレイヤ階層上での位
置づけ例を示した図表である。

【図３】プロトコル処理部の構成例を示すブロック図で
ある。

【図４】メモリバッファ上に確保する領域の構成例を示
す図表である。

【図５】実施形態に係るプロトコル処理部が受信時に使
用する処理手順を示すフローチャートである。

【図６】通信プロトコル手順の基本概念を示す説明図で
ある。

【符号の説明】 １…プロトコル処理部、２…通信メモリバッファ、３…
受信メモリバッファ、４…メモリ管理部、５…ヘッダ処
理部、６…プロトコル制御部。

Claims (8)

【特許請求の範囲】
1. 【請求項１】 レイヤコネクションの設定時に、送信側
   及び受信側の通信バッファに必要とされるバッファ量を
   算出し、当該算出されたバッファ量を各通信バッファに
   確保するバッファ管理手段を備えることを特徴とする通
   信ネットワークシステム。
2. 【請求項２】 上記バッファ管理手段は、伝送路往復遅
   延時間と予想データ処理時間とに基づいて、必要とされ
   るバッファ量を算出することを特徴とする請求項１に記
   載の通信ネットワークシステム。
3. 【請求項３】 上記必要とされるバッファ量の算出は、
   送信側のバッファ管理手段が行い、受信側のバッファ管
   理手段へ通知することを特徴とする請求項１又は２に記
   載の通信ネットワークシステム。
4. 【請求項４】 受信側のバッファ管理手段は、送信側か
   ら通知されただけのバッファ量を通信バッファ内に確保
   できない場合、実際に確保することができたバッファ量
   を送信側のバッファ管理手段へ通知することを特徴とす
   る請求項３に記載の通信ネットワークシステム。
5. 【請求項５】 上記バッファ管理手段は、上位レイヤが
   要求する受渡しデータ長にヘッダ長を加算した固定デー
   タ長を、基本単位とする構造を上記通信バッファ上に構
   築することを特徴とする請求項１〜４のいずれかに記載
   の通信ネットワークシステム。
6. 【請求項６】 上記バッファ管理手段は、上位レイヤか
   ら上記通信バッファに書き込まれたデータを分割するこ
   となく送信することを特徴とする請求項５に記載の通信
   ネットワークシステム。
7. 【請求項７】 上位レイヤが送信データの書込みアドレ
   スを指定するのに先立って、当該送信データを書き込む
   べき通信バッファ上のアドレスを、その都度、上位レイ
   ヤに対して事前に通知する書込みアドレス管理手段を備
   えることを特徴とする通信ネットワークシステム。
8. 【請求項８】 受信側の通信バッファに確保されたバッ
   ファ量と、受信側から応答のあった送信データに対する
   肯定応答の受信回数とに基づいて、上記受信側の通信バ
   ッファに現存するバッファ残量を常時監視するバッファ
   残量監視手段を送信側に備えることを特徴とする通信ネ
   ットワークシステム。