JPH10164176A

JPH10164176A - 通信方法

Info

Publication number: JPH10164176A
Application number: JP9271642A
Authority: JP
Inventors: Ryuichi Ono; 隆一大野; Mitsuo Asai; 光男浅井; Yoji Yamashita; 洋史山下; Yoshihiro Takiyasu; 美弘滝安
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1996-10-04
Filing date: 1997-10-03
Publication date: 1998-06-19
Anticipated expiration: 2017-10-03
Also published as: JP3436100B2

Abstract

(57)【要約】【課題】本発明はコンピュータ通信のネットワーク使用
効率を高め、送受信要求におけるバイトストリームの制
約を軽減する方法を提供することにある。【解決手段】アプリケーション等のソフトウェア間での
通信機能を提供するプロトコルモジュールにおいて、論
理コネクションを張り、一つの送信要求を一つの受信要
求と対応付ける。各要求を単位としてＡＣＫを送り返す
ことで無駄なＡＣＫを避け、非同期送受信の際にも送受
信を終えた要求は即座に終了させることができ、効率的
なデータ転送が可能となる。また、対応する送信要求、
受信要求間では送信要求長、受信要求長の異なる場合に
も小さい方の要求長分に関しては信頼性のある通信を行
う。さらに、同期送受信の際には送信バッファの後半部
分のみをコピーし、前半部分の受信完了時に仮ＡＣＫを
送信側に返すことで、ＡＣＫを待つ必要が無くなるた
め、効率的なデータ転送が可能となる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はコンピュータ通信に
おける通信方法に関し、特にＯＳＩ参照モデルで規定さ
れるプロトコル階層においてトランスポート層及びネッ
トワーク層に好適な通信方法に関する。

【０００２】

【従来の技術】ネットワークを介して文字情報から画像
情報まで様々な種類のデータがコンピュータ間でやり取
りされている。これらのコンピュータ間通信においては
物理的な伝送路としては従来１０Ｍｂｐｓ以下の比較的
低速なネットワークが用いられてきたが、近年、ＡＴＭ
（ＡｓｙｎｃｈｒｏｎｏｕｓＴｒａｎｓｆｅｒＭｏ
ｄｅ）のように１００Ｍｂｐｓから１Ｇｂｐｓにも及ぶ
高速なネットワークが用いられるようになってきた。
このような物理的な伝送路の高速化に伴い、各コンピュ
ータ上でのプロトコル処理の際のデータコピー、割り込
み処理などのオーバヘッドが伝送路の帯域を使い切るた
めのボトルネックとなってきている。

【０００３】トランスポート層の代表的なプロトコルと
してＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏ
ｌＰｒｏｔｏｃｏｌ）がある。このプロトコルは、
“ＩＮＴＥＲＮＥＴＷＯＲＫＩＮＧＷＩＴＨＴＣＰ
／ＩＰ”（Ｄ．Ｃｏｍｅｒ著、Ｐｒｅｎｔｉｃｅ−Ｈａ
ｌｌＩｎｔｅｒｎａｔｉｏｎａｌ、Ｉｎｃ．、１９
８８）ｐｐ．１２９−１５１に具体的に記載されてい
る。ＴＣＰは信頼性のあるコネクション指向のストリー
ム型プロトコルであり、２つのコンピュータ間に張られ
た論理的なコネクション上を流れる各バイト単位にシー
ケンシャルに順序番号を与えることで全ての送信データ
が順序通り、誤り無く受信されることを保証している。
ＴＣＰでは上位層からの送出要求時に渡されたデータは
パケット紛失時の再送に備えてＴＣＰ内のバッファに一
旦コピーされる。上位層からの送信要求はこのコピーが
終了した時点で成功する。

【０００４】この送出要求時に渡されたデータはデータ
長が最大転送長（ＭＴＵ）よりも大きい場合、ＭＴＵ毎
に複数のパケットに分割され、このパケットごとにタイ
マがセットされる。パケットが正しく受信されると受信
側から送信側にバイトストリーム中でどこまでのバイト
を全て正しく受け取ったかを示す位置を含む確認応答
（ＡＣＫ）が返り、送信側ではＡＣＫ中の情報に従って
ＴＣＰ内の送信バッファの対応部分を解放する。また、
受信側では受け取ったデータを上位層からの受信要求が
来るまでＴＣＰ内のバッファに保持する。図２にＴＣＰ
の送受信時のパケットのやりとりを示す。図２において
送信側は図４においてコンピュータ４００を送信側コン
ピュータ、コンピュータ４６０を受信側コンピュータと
した場合の中位プロトコルモジュール４０４に相当し、
図２の受信側は同様に受信側コンピュータ４６０中の中
位プロトコルモジュール４６４に相当する。また、図２
においてＳＥＱ＝９は図４中の送信側中位プロトコルモ
ジュール４０４から受信側中位プロトコルモジュール４
６４への送受信バイトストリーム空間において９バイト
目からのデータを送信側から受信側に受け渡すことを示
す。また、ＡＣＫ＝２１は送受信バイトストリーム空間
において２０バイト目までのデータが受信されたことを
示す確認応答に相当する。図２ではまず順序番号９〜２
０に相当する１２バイトのデータパケット（ＳＥＱ＝
９）が送信側から受信側に向けて送信され、同時に送信
側ではパケット紛失に備えてタイマをセットする。受信
側ではこのデータパケットを受け取ると同時に順序番号
２１よりも前のパケットは受け取ったという情報を含む
確認応答（ＡＣＫ＝２１）を送信側に送り返す。以下同
様に、順序番号２１〜３４、３５〜３８に相当するデー
タが送信され、受信確認が返送される。ここで、順序番
号３９〜４８に相当するデータが送信中に失われるとそ
の送信時にセットされたタイマがタイムアウトを起こし
た時点で順序番号３９以降のデータが再送される。

【０００５】

【発明が解決しようとする課題】かかる従来の方法にお
いては、次のような問題がある。

【０００６】すなわち、ＴＣＰにおいては送信要求時に
上位層から渡されたデータを必ず一度コピーする必要が
あり、動画転送などの高速通信を行う際にはかなり大き
なオーバヘッドとなる。そこで、この送出時コピーを避
け、かつ信頼性のある通信を行おうとする場合、上位層
から渡されたデータバッファをそのままパケット紛失時
の再送に備えて保持する必要がある。このデータバッフ
ァはＡＣＫにより全てのデータが正しく受信されたこと
が確認できるまでトランスポート層中に保持する必要が
ある。この場合、ＴＣＰのようにパケット毎にＡＣＫが
返ってもトランスポート層内の送信用バッファを解放す
ることはできず、送信要求時に渡されたデータが全て正
しく受信されたことを確認できた時点ではじめて送信用
バッファが不要になる。つまり、ＴＣＰのようなパケッ
トごとのＡＣＫは無駄になる。

【０００７】また、送出時コピーをせずに非同期送信を
行う場合、ＴＣＰのようなストリームベースのやり方で
はバイトストリーム中でどこまでのバイトを全て正しく
受け取ったかを示す位置よりも前に行われた送信要求は
成功し、終了するが、その位置よりも後に行われた送信
要求でその要求時に渡されたデータに関しては正しく受
信されていてもその送信要求を終了させることができな
い。非同期受信の際にも同様に、ある受信要求に関して
そのデータは全て正しく受信されたにもかかわらず終了
させることができないといったことが起こりうる。図３
に非同期送受信時の送受信要求と送受信バイトストリー
ムの関係を示す。図３において送信要求は図４において
コンピュータ４００を送信側コンピュータ、コンピュー
タ４６０を受信側コンピュータとした場合に中位プロト
コルモジュール４０４がアプリケーション又は上位プロ
トコルモジュール４０２から受け取る各送信要求に相当
し、受信要求は受信側中位プロトコルモジュール４６４
がアプリケーション又は上位プロトコルモジュール４６
２から受け取る各受信要求に相当する。また、送信バイ
トストリームは中位プロトコルモジュール４０４が下位
プロトコルモジュール４０６に対してデータを送信する
場合に送信バイト空間上で送信データが占めるバイト位
置を示し、受信バイトストリームは中位プロトコルモジ
ュール４６４が下位プロトコルモジュール４６６からデ
ータを受信する場合に受信バイト空間上で受信データが
占めるバイト位置を示す。図３においてバイトストリー
ム上で３２０、３２４に相当する部分は送受信が完了し
ているものとすると送受信要求＃６、＃７は終了させる
ことができる。ここでバイトストリーム上で３２６に相
当する部分が受信されていないとすると、ＴＣＰの場
合、それよりも後の３２８に相当する部分が受信されて
いてもその部分に対応する送受信要求を終了させること
はできない。

【０００８】また、ＴＣＰにおいては受信要求が来るま
で受け取ったデータをＴＣＰ内のバッファに保持する必
要があるが、動画転送などの高速通信を行う際にはこの
受信データを保持するためにかなり大きなバッファが必
要となる。

【０００９】また、ＴＣＰのようなストリーム型のプロ
トコルではバイト単位で送受信データの位置を合わせる
ため、１バイトでも送受信位置がずれることは許され
ず、２０バイトの送信要求に対して最初の５バイトのみ
を受信したいとか、１０バイト〜３０バイトまでのいず
れの値を取るか分からない送信要求に対して３０バイト
の受信要求で受信を行う、などといった送信要求の長さ
と受信要求の長さの異なる場合には対応できない。

【００１０】また、送信側でコピーせずに同期送信を行
う場合には、送信要求中のすべてのデータを送り終わっ
てからＡＣＫが返ってくるまでの間、次のデータを送る
ことができない。

【００１１】このように従来の方法では、動画転送など
の高速通信を行う場合に高速かつＣＰＵ使用率の低い効
率的な通信ができないという問題と、送受信間でバイト
位置をきちんと合わせる必要があるという問題があっ
た。

【００１２】本発明の目的は、動画転送などの高速通信
においても高速かつＣＰＵ使用率の低い効率的なデータ
の送受信を可能にする通信方法を提供することにある。

【００１３】本発明の他の目的は、要求データ長の異な
る送信要求と受信要求のペア間での通信方法を提供する
ことにある。

【００１４】

【課題を解決するための手段】本発明は、送信端末と受
信端末との間で論理コネクションを張り、上記送信端末
では上記論理コネクションに対し送信要求を発行し、上
記受信端末では上記論理コネクションに対し受信要求を
発行することによりネットワークを介してデータ転送を
行う通信システムにおける通信方法に関するものであ
る。

【００１５】本通信方法においては、受信要求と送信要
求を対応付けるために識別子を上記受信要求及び上記送
信要求に付加する。

【００１６】ここで、本通信方法においては、受信要求
と対応する送信要求と同じ識別子を上記受信要求に付加
する。つまり、送信要求と対応する受信要求と同じ識別
子を上記送信要求に付加する。

【００１７】このようにすることで、論理コネクション
の送信端末側と受信端末側で同じ識別子を持つ送信要求
と受信要求がペアとなり、このペア間でデータのやり取
りを行う。

【００１８】この識別子としては、例えば、論理コネク
ションを張る際にコネクションの両端で同じ値に初期化
され、各送信要求時、受信要求時毎にインクリメントさ
れ、これらの要求番号が「コネクションの両端で同じ値
を取る上限値」を超えた場合には０に戻される整数値を
想定できる。以下、この整数値のことを要求番号と呼
び、識別子としてこのような整数値をとる場合について
述べる。

【００１９】これらの要求番号は各送信要求時、受信要
求時に更新される前、及び、更新された後のいずれかの
時点で各送信要求、受信要求に与えられる。送受信はコ
ネクションの両端で送信要求番号と受信要求番号が等し
い要求の間で行われる。送信側では送信要求により渡さ
れたデータが最大転送長（ＭＴＵ）ごとに分割されて送
信される。受信側では各受信要求ごとにどの部分が受信
されたかを示すデータ構造を持ち、このデータ構造を用
いて同じ要求番号を持つペアー間でのデータ受信の終了
を判断し、受信終了時にＡＣＫを送り返す。送信側でコ
ピーを行わない場合には、各分割単位ごとにＡＣＫを送
り返しても送信側のバッファを開放できず、無駄となる
が、このように、各要求を単位としてＡＣＫを送り返せ
ば、このような無駄なＡＣＫを避けることができる。ま
た、非同期送受信の際には要求が行われた順番に関係な
く送受信を終えた要求は即座に終了させることができ
る。このような特徴により、本通信方法では高速かつＣ
ＰＵ使用率の低い効率的なデータ転送が可能となる。

【００２０】また、受信要求により受信バッファが渡さ
れる前に対応する送信要求によるデータが到着した場
合、そのデータは捨てられるが、受信側が持つ何番目の
送信要求まで到着したかを示すデータ構造にこの送信要
求番号がセットされる。後でその受信要求が実際に行わ
れた時にはこのデータ構造により既に対応する送信要求
が行われていることがわかるため、送信側に対して再送
要求（ＮＡＣＫ）を返送することで即座にデータの再送
を行う。このように、受信要求される前に対応する送信
要求データが到着した場合、そのデータを保持せずに、
後に実際に受信要求が行われたときに再送してもらうこ
とで動画転送などの高速通信においてもトランスポート
層内部に大きなバッファを持つ必要を無くすことができ
る。

【００２１】さらに、送信パケット中にリクエスト中の
最後のパケットであることを示すフィールドを設け、送
信要求の要求データ長が対応する受信要求の要求データ
長よりも小さい場合にはこのフィールドを用いて送信要
求データの終りを受信側に知らせ、送信要求の要求デー
タ長分のデータについては信頼性のある通信を行う。ま
た、送信要求の要求データ長が対応する受信要求の要求
データ長よりも大きい場合には受信要求データ長分のデ
ータについては信頼性のある通信を行う。この場合、Ａ
ＣＫ中に実際に受信されたデータ長を入れるフィールド
を設け、そのフィールドにより送信側も実際に送られた
データ長を知ることができる。このように、対応する送
信要求、受信要求間では送信要求長、受信要求長の異な
る場合にも小さい方の要求長に相当するデータ分に関し
ては信頼性のある通信が行われるため、２０バイトの送
信要求に対して最初の５バイトのみを受信することや、
１０バイト〜３０バイトまでのいずれの値を取るか分か
らない送信要求に対して３０バイトの受信要求で受信を
行うことなども可能となる。

【００２２】また、同期送受信の場合には送信要求中の
送信バッファ中の後半部分のデータを送信端末上のバッ
ファにコピーして保持する。送信パケット中に仮ＡＣＫ
要求を行うことを示すフィールドを設け、コピーしない
部分の最後のパケットを送出する際にこのフィールドを
セットする。受信側では仮ＡＣＫ要求を行うことを示す
フィールドがセットされたパケットを受信した際にその
パケット以前のすべてのパケットを既に受信していれば
仮ＡＣＫを返送する。送信側ではこの仮ＡＣＫ受信時に
論理コネクションに対する次の送信要求を行うことがで
きる。さらに、ＡＣＫ受信時に上記送信端末上のコピー
データ保持用バッファを開放する。

【００２３】このように、同期送受信の場合には送信要
求中の送信バッファ中の後半部分のデータを送信端末上
のバッファにコピーして保持することでＡＣＫを待つこ
と無く次々と送信要求を発行できる。また、このコピー
部分の大きさはパケットのラウンドトリップ時間に相当
する大きさよりも大きくしてもＡＣＫ待ち時間の削減に
は効果が無い。そこで、上記ラウンドトリップ時間に相
当する大きさをコピー部分の大きさとすると、この大き
さは送信要求中の送信バッファサイズに依存しない値と
なるため、送信バッファサイズを十分`大きくとればコ
ピー部分の比率を低く抑えることができる。従って、本
通信方法により、高速かつＣＰＵ使用率の低い効率の良
いデータ転送が可能となる。

【００２４】また、この場合にも仮ＡＣＫ中に受信要求
中で指定されたデータ長を入れることで、対応する送信
要求、受信要求間で送信要求長、受信要求長の異なる場
合にも小さいほうの要求長分に関しては信頼性のある通
信を行うことができる。

【００２５】

【発明の実施の形態】以下、本発明の実施の形態を詳細
に説明する。

【００２６】まず、第１の実施の形態を示す。第１の実
施の形態の目的は送信側でコピーを行わない場合に高速
かつＣＰＵ使用率の低い効率的なデータの送受信を可能
にすること、及び、要求データ長の異なる送信要求と受
信要求のペア間での通信方法を提供することにある。

【００２７】図１は、第１の実施の形態の処理手順を示
すフローチャートであり、図４は、本発明に係るシステ
ム構成、及び、プロトコルモジュール階層を示すブロッ
ク図である。図８は図４の中位プロトコルモジュールの
ブロック図であり、図５、図６、図７はそれぞれ中位プ
ロトコルモジュールにおける送受信要求を格納するデー
タ構造、データパケットフォーマット、受信確認パケッ
トフォーマットを示す。

【００２８】図４において、コンピュータ４００、４６
０はネットワーク４３０を介して接続されている。ここ
でネットワーク４３０はＡＴＭスイッチ、ルータなどの
接続装置も含む。

【００２９】コンピュータ４００、４６０はディスプレ
イ４１８、４７８、キーボード４１６、４７６、ＣＰＵ
４１４，４７４、磁気ディスク４１２、４７２、ネット
ワークカード４０８、４６８、主メモリ４１０，４７０
から構成される。ディスプレイ４１８、４７８、キーボ
ード４１６、４７６、磁気ディスク４１２、４７２、ネ
ットワークカード４０８、４６８、主メモリ４１０，４
７０はＣＰＵ４１４，４７４よりバスを介してアクセス
される。主メモリ４１０、４７０には下位プロトコルモ
ジュール４０６、４６６、中位プロトコルモジュール４
０４、４６４、アプリケーション又は上位プロトコルモ
ジュール４０２、４６２がロードされ、ワークエリア４
０７、４６７が確保される。

【００３０】ネットワークインタフェースカード４０
８、４６８はＡＴＭカードのようなネットワークインタ
フェース用のハードウェアに相当する。ただし、ネット
ワークインタフェースカード４０８、４６８に相当する
機能の一部もしくは全部はコンピュータ４００、４６０
中ではなく、コンピュータ４００、４６０に付属する装
置としてネットワーク４３０中におかれるような構成を
取ることも可能である。また、ネットワークインタフェ
ースカード４０８、４６８中で下位プロトコルモジュー
ル４０６，４６６、及び、中位プロトコルモジュール４
０４，４６４に相当する機能の一部をハードウェアとし
て実現する場合もある。

【００３１】下位プロトコルモジュール４０６、４６６
はＯＳＩ参照モデルで規定されるプロトコル階層におい
て主に物理層、データリンク層、ネットワーク層に相当
するプロトコルモジュールであり、２つのコンピュータ
間でのデータ伝送を行うための機能を提供する。中位プ
ロトコルモジュール４０４、４６４は下位プロトコルモ
ジュール４０６、４６６に対して受信側のコンピュータ
の識別子（ＩＰアドレス、ＭＡＣアドレス等）又はＡＴ
Ｍのようにコネクションが張られる場合にはその識別子
（ＶＰＩ／ＶＣＩ番号等）を指定することでデータの宛
先等を指定し、さらに送受信用バッファ、バッファ長な
どを指定することで送受信されるデータの格納場所を指
定する。

【００３２】中位プロトコルモジュール４０４、４６４
はＯＳＩ参照モデルで規定されるプロトコル階層におい
て主にトランスポート層、ネットワーク層に相当するプ
ロトコルモジュールであり、下位プロトコルモジュール
４０６、４６６の機能を利用して２つのコンピュータ上
のアプリケーション等のソフトウェアモジュール間の通
信を行うための機能を提供する。アプリケーション又は
上位プロトコルモジュール４０２、４６２は中位プロト
コルモジュール４０４、４６４に対して受信側のコンピ
ュータの識別子及び受信側のコンピュータ上での受信相
手を識別するための識別子（ＴＣＰやＵＤＰのポート番
号等）、または、これらの識別子からコネクションを張
る際などに得られるコネクション識別子を指定すること
で論理コネクションの接続、データの宛先の指定等を行
い、さらに送受信用バッファ、バッファ長などを指定す
ることで送受信されるデータの格納場所を指定する。

【００３３】アプリケーション又は上位プロトコルモジ
ュール４０２、４６２は中位プロトコルモジュール４０
４、４６４の上位に位置するモジュールである。

【００３４】ワークエリア４０７、４６７はモジュール
間でのデータのやりとりの際に使用されるメモリ領域で
ある。

【００３５】図５において、コネクションデータ構造５
００は中位プロトコルモジュール４０４、４６４中に存
在する。コネクションデータ構造５００は論理コネクシ
ョンを張る際に各コネクションごとに割り当てられるデ
ータ構造であり、送信キュー５０２はアプリケーション
又は上位プロトコルモジュール４０２、４６２からの送
信要求の際に使用されるデータ構造を格納するためのキ
ュー、受信キュー５０４はアプリケーション又は上位プ
ロトコルモジュール４０２、４６２からの受信要求の際
に使用されるデータ構造を格納するためのキューであ
る。また、送信要求データ構造は送信要求番号、送信要
求データ長、送信要求用バッファなどからなり、受信要
求データ構造は受信要求番号、受信要求データ長、受信
要求用バッファ、受信要求用バッファ中で実際に受信し
たデータ部分を示すリストなどからなる。送信キュー５
０２中の送信要求の内、Ａｃｋ待ちの送信要求は既に送
信を終え、確認応答待ち状態の送信要求であり、送信中
の送信要求は現在送信中の送信要求を示す。また、送信
待ちの送信要求はまだ送信されずに送信待ち状態にある
送信要求を示す。受信キュー５０４中の受信要求は全
て、受信要求されたがまだ受信を完了していない受信要
求を示す。

【００３６】図６は図４の中位プロトコルモジュール４
０４、４６４間で受け渡されるデータパケットのフォー
マットを示す。コネクション識別子６００は中位プロト
コルモジュール４０４、４６４においてコネクションを
張る際に各コネクションを識別するために割り当てられ
る識別子であり、要求番号６０２はこのデータパケット
がどの送信要求データ構造に属するかを示す。オフセッ
ト６０４はこのデータパケットが属する送信要求中のど
の位置からのデータを含んでいるかを示す。オフセット
６０４はバイト単位で指定してもよいが、最大転送長
（ＭＴＵ）がコネクションの両端で予め合意されている
場合には送信要求はＭＴＵ単位に分割されるため送信要
求中で何個目の分割単位（ＵＮＩＴ）かを示すＵＮＩＴ
単位での番号を指定してもよい。パケット長６０６はこ
のパケットのバイト単位の長さを示す。ＬａｓｔＰａ
ｃｋｅｔＦｌａｇはこのデータパケットが送信要求の
最後のデータを含むパケットである場合にセットされる
フラグであり、受信側はこのフラグがセットされたパケ
ットを受信した際に送信要求の長さを知ることができ、
送信要求長の方が要求長よりも短い場合には送信要求長
分のデータを受け取った際にＡＣＫを返し受信要求を終
了する。

【００３７】図６のデータパケットフォーマットの具体
例を次に示す。コネクション識別子６００はＴＣＰやＵ
ＤＰにおけるポート番号と同様に、６０番などといった
番号を割り振る。要求番号６０２は送信要求が発行され
た際に割り当てられる各要求に固有の番号であり、１６
ビットなら０〜６５５３５までの間の適当な値を取る。
例えば、８などといった値が割り当てられる。オフセッ
ト６０４はＵＮＩＴ単位での番号で示す場合、３ＵＮＩ
Ｔ目などといったように、各分割単位に対して０から順
番にＵＮＩＴ番号が振られていく。パケット長６０６は
５１２バイトなどといった値で指定される。Ｌａｓｔ
ＰａｃｋｅｔＦｌａｇは通常０か１のどちらかの値を
取る。

【００３８】図７は図４の中位プロトコルモジュール４
０４、４６４間で受け渡される受信確認パケットのフォ
ーマットを示す。コネクション識別子７００は中位プロ
トコルモジュール４０４、４６４においてコネクション
を張る際に各コネクションごとに割り当てられるデータ
構造であり、要求番号７０２はこの受信確認パケットが
どの送信要求に対する確認応答（ＡＣＫ）であるかを示
す。受信長７０４は受信要求が実際に受信したデータ長
を示す。受信長７０４により送信側は受信要求長が送信
要求長よりも短い場合にも実際に送信されたデータ長を
送信要求終了時にアプリケーション又は上位プロトコル
モジュール４０２、４６２に知らせることができる。

【００３９】図７の受信確認パケットフォーマットの具
体例を次に示す。コネクション識別子７００はＴＣＰや
ＵＤＰにおけるポート番号と同様に、６０番などといっ
た番号を割り振る。要求番号７０２はこの受信確認パケ
ットにより受信が確認される送信要求、受信要求のペア
の要求番号であり、８などといった値が割り当てられ
る。受信長７０４は受信要求が実際に受信したデータ長
であり、３５８４バイトなどといった値で指定される。

【００４０】次に、図１のフローチャートに基いて図
４、図５、図６、図７の各部の動作を説明する。

【００４１】まず、アプリケーション又は上位プロトコ
ルモジュール４０２、４６２が送信要求又は受信要求を
中位プロトコルモジュール４０４、４６４に対して行う
（ステップ１００）と、送信要求の場合は送信要求デー
タ構造を作成（ステップ１０４）し、送信キュー５０２
に送信要求データ構造が挿入（ステップ１０６）され、
受信要求の場合は受信要求データ構造を作成（ステップ
１３０）し、受信キュー５０４に受信要求データ構造が
挿入（ステップ１３２）される。

【００４２】この際に、各送信要求、受信要求に送信要
求番号、受信要求番号が付加される。ただし、送信要求
番号、受信要求番号はコネクションの開設時にコネクシ
ョンの両端で各方向ごとに同じ値に初期化され、各送信
要求、受信要求の度にそれらの要求番号がインクリメン
トされて各要求に与えられる。つまり、コネクション上
の一つのコンピュータ上で一度目に出された受信要求の
受信要求番号はもう一方のコンピュータ上で一度目に出
された送信要求の送信要求番号と同じ値となり、２度
目、３度目にコネクションの両端のコンピュータで出さ
れた送信要求と受信要求に関しても同様に同じ値を取る
ため、コネクション上で対応する送信要求と受信要求の
ペアが決まり、その間でデータのやりとりを行うことに
なる。ここで、要求番号をインクリメントするのは各送
信要求、受信要求の度としたが、各送信要求完了時、受
信要求完了時にインクリメントしてもよい。また、要求
番号を際限なく大きくすることはできないため、その上
限値を設け、要求番号がその上限値を超えた場合には０
に戻すこととする。もちろんこの上限値は送信要求と受
信要求で同じ値を取る必要がある。

【００４３】送信要求の場合、以前に送信キューに挿入
された送信要求が全て送出を終えるまで待ち（ステップ
１０８）、以前に送信キューに挿入された送信要求が全
て送出を終えた時点で送出処理が行われ、タイマがセッ
トされる（ステップ１１０）。送出処理において送信要
求時に渡されたデータは最大転送長（ＭＴＵ）よりも大
きい場合、複数のパケットに分割して送出される。送信
要求データの送出後、この送信要求に対するＮＡＣＫパ
ケットを受信した場合（ステップ１１２）、ＮＡＣＫ受
信時の処理（ステップ１１８）としてＮＡＣＫパケット
により再送するように要求された送信要求データの一部
を再送する（ステップ１１４）。また、タイムアウトが
発生した（ステップ１１６）場合、タイムアウト時の処
理としてＡＣＫ要求パケットを送信し、タイマの再設定
を行う（ステップ１１８）。この送信要求に対するＡＣ
Ｋパケットを受信した場合（ステップ１２０）、送信キ
ューからこの送信要求を取り出し（ステップ１２２）、
アプリケーションまたは上位プロトコルモジュール４０
２、４６０に送信要求の完了を通知する。また、この際
に実際に受信側のコンピュータで受け取った受信長も同
時に知らせる。

【００４４】受信要求の場合、この受信要求に対して既
に送信データが到着しているかどうかチェック（ステッ
プ１３４）し、既に受け取っていた場合、ＮＡＣＫパケ
ットを送信することで再送を促す（ステップ１３６）。
受信したデータパケットはパケットヘッダのオフセット
とパケット長に従い受信データ用バッファの適当な位置
にそのデータを受け取る。ネットワーク４３０としてＡ
ＴＭのようにネットワーク上でのパケットの追い越しが
無いものを用いる場合、次に来るはずのパケットを予測
でき、予測よりも先のデータを持つパケットが到着した
場合にはそのパケットは失われたものと考えることがで
きるため（ステップ１３８）、そのような場合にはＮＡ
ＣＫパケットを送信することで失われたと考えられる部
分のデータの再送を要求できる（ステップ１４０）。デ
ータパケット又はＡＣＫ要求を受信した際には、対応す
る受信要求が、受信要求長と送信側がＬａｓｔＰａｃ
ｋｅｔＦｌａｇをセットすることで知らせてきた送信
要求長の小さい方の長さ分のデータを全て受け取ったか
どうかチェックされる（ステップ１４２、１４６）。こ
のチェックにより受信要求の完了が確認できた場合、Ａ
ＣＫパケットが送信側に向けて送出され（ステップ１５
０）、受信キューからこの受信要求を取り出し（ステッ
プ１５２）、アプリケーションまたは上位プロトコルモ
ジュール４０２、４６２に受信要求の完了を通知する。
また、この際に実際に受信側のコンピュータで受け取っ
た受信長も同時に知らせる。ＡＣＫ要求を受け取った際
に受信要求が完了していなければ、未到着のデータ部分
を知らせるために送信側に対してＮＡＣＫが送信され
る。

【００４５】このように受信要求の完了が確認できた場
合のみＡＣＫを送出することで、無駄なＡＣＫを省いて
いる。

【００４６】送信要求または受信要求は送信キューまた
は受信キューから取り出されるとそのデータ構造は解放
される（ステップ１５４）。

【００４７】以上説明した処理の流れを、さらに具体例
を用いて説明する。本例では要求番号８を持つ送信要求
と受信要求のペア間でのデータ送受信について処理の流
れを示す。

【００４８】まず、送信側では３５８４バイトのデータ
を送信するとする。最大転送長（ＭＴＵ）を１０２４バ
イトとすると、送信要求時に渡されたデータは最大転送
長よりも大きいため、４つのパケットに分割して次々と
送出される。図５のデータパケットはこの際に送出され
る４番目のデータパケットを示している。ここで、１番
目、２番目、３番目のデータパケットに関してはパケッ
ト長１０２４バイト、ＬａｓｔＰａｃｋｅｔＦｌａ
ｇは０となる。４番目のデータパケットが最後のパケッ
トとなるため、残りのパケット長である５１２バイトが
パケット長となり、ＬａｓｔＰａｃｋｅｔＦｌａｇ
は１となる。コネクション識別子、要求番号などのフィ
ールドは４つのデータパケットとも全て同じ値を取る。
オフセットは４番目のパケットであるため、３ＵＮＩＴ
分のオフセットが必要となる。

【００４９】次に、受信側でも３５８４バイトの受信要
求長で受信要求が行われるものとする。送信側から送出
されたデータパケットはデータパケットヘッダ中のコネ
クション識別子６０番、コネクション上の要求番号８に
より受信要求を識別し、さらにオフセット、パケット長
により受信要求中の受信データ用バッファの適切な位置
にデータがコピーされる。例えば、図５に示した４番目
のデータパケットはオフセットが３であるため、受信デ
ータ用バッファ上の３０７２バイト目から５１２バイト
の位置にコピーされる。全てのデータを受信した際には
受信確認パケットが送信側に向けて送出される。図７の
受信確認パケットはこの際に送信側に向けて送出される
受信確認パケットを示している。受信側では全てのデー
タを受信した時点で、送信側では受信確認パケットを受
信した時点で処理を完了することができる。

【００５０】第１の実施の形態の効果としては、送信要
求と受信要求のペア間で送受信制御を行うことで送信側
でコピーを行う場合の無駄なＡＣＫを省くことができ、
また、非同期送受信時には要求順序に関係無く送受信要
求を終わらせることができるため、高速かつＣＰＵ使用
率の低い効率的なデータ送受信が可能となる。

【００５１】また、要求データ長の異なる送信要求と受
信要求のペア間では小さい方の要求データ長分に関して
は信頼性のある送受信を保証するため、例えば、予め送
信要求データ長が分かっていない場合には大き目のデー
タ長で受信要求をすることで対応するなどといったこと
も可能となる。

【００５２】次に、第２の実施の形態を示す。第２の実
施の形態の目的は第１の実施の形態の目的に加え、同期
送受信の場合にも高速かつＣＰＵ使用率の低い効率的な
データの送受信を可能にすることである。

【００５３】図９は、第２の実施の形態を示すフローチ
ャートであり、図１０は図９中で仮ＡＣＫに係る処理の
流れを抽出した送受信処理の流れである。また、図５、
図１１、図１２はそれぞれ中位プロトコルモジュールに
おける送受信要求を格納するデータ構造、データパケッ
トフォーマット、受信確認パケットフォーマットを示
す。

【００５４】図５は第１の実施例の場合と同様、コネク
ションデータ構造を示す。ただし、同期送受信の場合、
各送受信キュー中にはそれぞれ一つ以下の送信中の送信
要求、データ待ちの受信要求しか同時に存在し得ない。

【００５５】図１１は図６のデータパケットのフォーマ
ットに仮ＡＣＫ要求Ｆｌａｇ１１５０が追加されたもの
である。仮ＡＣＫ要求Ｆｌａｇはこのデータパケットが
受信側に対して仮ＡＣＫ要求を行う場合にセットされる
フラグである。具体的な値としては通常０か１のどちら
かの値を取る。

【００５６】図１２は図４の中位プロトコルモジュール
４０４、４６４間で受け渡される仮ＡＣＫパケットのフ
ォーマットを示す。コネクション識別子１２００は中位
プロトコルモジュール４０４、４６４においてコネクシ
ョンを張る際に各コネクションごとに割り当てられるデ
ータ構造であり、要求番号１２０２はこの仮ＡＣＫパケ
ットがどの送信要求に対する仮ＡＣＫであるかを示す。
受信要求長１２０４は受信要求中で指定された受信デー
タ長を示す。受信要求長１２０４により送信側は受信要
求長が送信要求長よりも短い場合にも実際に送信される
データ長を送信要求終了時にアプリケーション又は上位
プロトコルモジュール４０２、４６２に知らせることが
できる。

【００５７】図１２の仮ＡＣＫパケットフォーマットの
具体例を次に示す。コネクション識別子１２００はＴＣ
ＰやＵＤＰにおけるポート番号と同様に、６０番などと
いった番号を割り振る。要求番号１２０２はこの仮ＡＣ
Ｋパケットにより送信バッファのコピーされない部分の
受信が確認される送信要求、受信要求のペアの要求番号
であり、８などといった値が割り当てられる。受信要求
長１２０４は受信要求中で指定された受信データ長であ
り、３５８４バイトなどといった値で指定される。

【００５８】次に、図９のフローチャート、及び、図１
０の処理の流れを示す図に基いて同期送受信の場合の追
加事項の動作を説明する。

【００５９】まず、ステップ１０２０では、送信側でア
プリケーション又は上位プロトコルモジュール４０２、
４６２から送信要求１が中位プロトコルモジュール４０
４、４６４に対して発行される。送信要求１中の送信バ
ッファの前半部（コピーされない部分）は最大転送長で
分割され、次々と送り出される。ステップ１０２２で
は、コピーされない部分の最後のパケットを送出するた
め、図１１中の仮ＡＣＫ要求Ｆｌａｇ１１５０がセット
される。これと同時にステップ１０２４では、送信バッ
ファの後半部を中位プロトコルモジュール中のバッファ
にコピーし、それ以降の送出はこの中位プロトコルモジ
ュール中のバッファから行う。受信側で仮ＡＣＫ要求フ
ラグがセットされたパケットを受信した際には、そのパ
ケット以前のすべてのパケットを既に受信しているか検
査し、受信していた場合、ステップ１０２６に示したよ
うに仮ＡＣＫパケットを送信側に返送する。また、この
際に仮ＡＣＫパケットの受信要求長１２０４に受信要求
で指定された受信長を入れる。この処理は図９のフロー
チャートではステップ９８０、９８２に相当する。送信
側でこの仮ＡＣＫパケットを受信した際にはコピーしな
い部分はすべて受信されていることがわかるため、上位
プロトコルモジュールから渡されたバッファは必要なく
なる。そこで、ステップ１０２８ではアプリケーション
又は上位プロトコルモジュール４０４、４６４に対して
送信終了を通知する。また、この際に仮ＡＣＫパケット
中で指定される受信要求長１２０４が送信要求長よりも
小さい場合、この受信要求長１２０４を実際に送受信さ
れるデータ長として同時に通知する。この処理は図９の
フローチャートではステップ９７０、９７２に相当す
る。ステップ１０３０では、この時点で、アプリケーシ
ョン又は上位プロトコルモジュール４０４、４６４が次
の送信要求２を中位プロトコルモジュール４０４、４６
４に対して発行している。また、ステップ１０５２で
は、送信側の中位プロトコルモジュール中のバッファを
対応する送信要求に対するＡＣＫパケットを受信した際
に解放している。

【００６０】このように、同期送受信の場合に送信バッ
ファの後半部分のみをコピーすることでＡＣＫを待つこ
となく次の送信要求を行うことができるため、高速かつ
ＣＰＵ使用率の低い効率的なデータ送受信が可能とな
る。

【００６１】以上説明した処理の流れを、さらに具体例
を用いて説明する。本例では要求番号８を持つ送信要求
と受信要求のペア間でのデータ送受信について処理の流
れを示す。

【００６２】まず、送信側では３５８４バイトのデータ
を送信するとする。最大転送長（ＭＴＵ）を１０２４バ
イトとすると、送信要求時に渡されたデータは最大転送
長よりも大きいため、４つのパケットに分割して次々と
送出される。図１１のデータパケットはこの際に送出さ
れる４番目のデータパケットを示している。ここで、１
番目、２番目、３番目のデータパケットに関してはパケ
ット長１０２４バイト、ＬａｓｔＰａｃｋｅｔＦｌ
ａｇは０となる。４番目のデータパケットが最後のパケ
ットとなるため、残りのパケット長である５１２バイト
がパケット長となり、ＬａｓｔＰａｃｋｅｔＦｌａ
ｇは１となる。コネクション識別子、要求番号などのフ
ィールドは４つのデータパケットとも全て同じ値を取
る。オフセットは４番目のパケットであるため、３ＵＮ
ＩＴ分のオフセットが必要となる。また、１番目、２番
目のデータパケットはコピーされないが、３番目、４番
目に関しては中位プロトコルモジュール中のバッファに
コピーされたデータが送出されるとすると、２番目のデ
ータパケット中の仮Ａｃｋ要求Ｆｌａｇは１となる。

【００６３】次に、受信側でも３５８４バイトの受信要
求長で受信要求が行われるものとする。送信側から送出
されたデータパケットはデータパケットヘッダ中のコネ
クション識別子６０番、コネクション上の要求番号８に
より受信要求を識別し、さらにオフセット、パケット長
により受信要求中の受信データ用バッファの適切な位置
にデータがコピーされる。例えば、図５に示した４番目
のデータパケットはオフセットが３であるため、受信デ
ータ用バッファ上の３０７２バイト目から５１２バイト
の位置にコピーされる。２番目のデータパケットを受信
した際には仮Ａｃｋ要求Ｆｌａｇが１であるため、０番
目のデータパケットの受信を確認し、送信側に向けて仮
Ａｃｋパケットを送出する。図１２の仮Ａｃｋパケット
はこの際に送信側に向けて送出される仮Ａｃｋパケット
を示している。

【００６４】送信側では受信側から仮Ａｃｋパケットを
受信した時点でアプリケーションまたは上位プロトコル
モジュールに対して送信終了を通知する。この時点でア
プリケーションまたは上位プロトコルモジュールは次の
送信要求を発行できる。

【００６５】受信側で全てのデータを受信した際には受
信確認パケットが送信側に向けて送出される。受信側で
は全てのデータを受信した時点で処理を完了することが
できる。また、送信側では受信確認パケットを受け取っ
た時点で中位プロトコルモジュール中のバッファを開放
できる。

【００６６】第２の実施の形態の効果としては、同期送
受信の場合に送信バッファの後半部分のみをコピーする
ことでコピーレスの同期送信の場合に避けられないＡＣ
Ｋ待ちに伴う待ち時間を減らすことが可能となり、高速
かつＣＰＵ使用率の低い効率的なデータ送受信が可能と
なることである。

【００６７】また、第２の実施の形態においても、第１
の実施の形態と同様、要求データ長の異なる送信要求と
受信要求のペア間では小さい方の要求データ長分に関し
ては信頼性のある送受信を保証する。

【００６８】

【発明の効果】以上述べたように、本発明によれば、送
信要求と受信要求のペア間で送受信制御を行うことで送
信側でコピーを行う場合の無駄なＡＣＫを省くことがで
き、また、非同期送受信時には要求順序に関係無く送受
信要求を終わらせることができるため、高速かつＣＰＵ
使用率の低い効率的なデータ送受信が可能となる。

【００６９】また、要求データ長の異なる送信要求と受
信要求のペア間では小さい方の要求データ長分に関して
は信頼性のある送受信を保証することが可能となる。そ
のため、例えば、予め送信要求データ長が分かっていな
い場合にも想定される最大送信要求データ長で受信要求
をすることで対応することも可能となる。

【００７０】また、予め先頭に近い程重要度の大きいデ
ータを配置する送受信要求のフォーマットを定めてお
き、受信側では受信要求長を調整することでどの優先度
までのデータを取得するかを決め、送信側でも送信要求
長を調節することでどの優先度までのデータを送出する
か決めるようにすれば、予め送受信間で送受信されるデ
ータ長を決めなくても、優先度に応じたデータの送受信
が可能となる。これにより、例えば送信側でＣＰＵやネ
ットワークの負荷に応じて送出長を変える、受信側で受
信者の必要に応じて受信長を変えるなどといったことも
可能となり、画像データの送受信やデータベース検索な
どに適用できる。

【００７１】さらに、同期送受信の場合には送信バッフ
ァの後半部分のみをコピーすることで、コピーレスの同
期送信を行う場合に避けられないＡＣＫ待ちに伴う待ち
時間を減らすことが可能となり、高速かつＣＰＵ使用率
の低い効率的なデータ送受信が可能となる。

【図面の簡単な説明】

【図１】本発明の第１の実施の形態の処理手順を示すフ
ローチャートである。

【図２】従来例（ＴＣＰ）の送受信時のパケットのやり
取りを示す図である。

【図３】従来例の非同期送受信時の送受信要求とバイト
ストリームの関係を示す図である。

【図４】本発明の実施の形態のシステムブロック図であ
る。

【図５】本発明の実施の形態の送受信要求を格納するデ
ータ構造を示す図である。

【図６】本発明の第１の実施の形態のデータパケットフ
ォーマットを示す図である。

【図７】本発明の実施の形態の確認応答パケットフォー
マットを示す図である。

【図８】本発明の実施の形態の中位プロトコルモジュー
ルを示す図である。

【図９】本発明の第２の実施の形態の処理手順を示すフ
ローチャートである。

【図１０】本発明の第２の実施の形態の仮ＡＣＫに関係
する処理の流れを示す図である。

【図１１】本発明の第２の実施の形態のデータパケット
フォーマットを示す図である。

【図１２】本発明の第２の実施の形態の仮ＡＣＫパケッ
トフォーマットを示す図である。

【符号の説明】

６００…コネクション識別子、６０２…送信要求の番号、６０４…送信要求中でのオフセット位置、６０６…パケットの長さ、６０８…送信要求の最後のデータを含むことを示すフラ
グ、６１０…データ、７００…コネクション識別子、７０２…受信確認を行う要求の要求番号、７０４…実際に受信したパケットの長さ、１１００…コネクション識別子、１１０２…送信要求の番号、１１０４…送信要求中でのオフセット位置、１１０６…パケットの長さ、１１０８…送信要求の最後のデータを含むことを示すフ
ラグ、１１５０…仮ＡＣＫ要求を行うことを示すフラグ、１２００…コネクション識別子、１２０２…仮ＡＣＫの対象となる要求の要求番号、１２０４…受信要求中に指定されたパケット長。

───────────────────────────────────────────────────── フロントページの続き (72)発明者滝安美弘神奈川県川崎市幸区鹿島田890番地株式会社日立製作所情報・通信開発本部内

Claims

【特許請求の範囲】

【請求項１】送信端末と受信端末とを備え、上記送信端
末と上記受信端末とを接続するネットワークを備え、送
信端末と受信端末との間で論理コネクションを張り、上
記送信端末では上記論理コネクションに対し送信要求を
発行し、上記受信端末では上記論理コネクションに対し
受信要求を発行することにより上記ネットワークを介し
て上記送信端末から上記受信端末へデータの転送を行う
通信システムにおける通信方法において、上記受信要求と上記送信要求とを対応付けるための識別
子を上記受信要求及び上記送信要求に付加し、上記受信
要求と上記送信要求とを対応付け、上記送信端末から上
記受信端末へ上記データの転送を行うことを特徴とする
通信方法。
【請求項２】請求項１において、受信要求と対応する送
信要求と同じ識別子を上記受信要求に付加することを特
徴とする通信方法。
【請求項３】請求項１において、送信要求と対応する受
信要求と同じ識別子を上記送信要求に付加することを特
徴とする通信方法。
【請求項４】請求項１において、受信側で各受信要求ご
とにどの部分が受信されたかを示すデータ構造を持ち、
このデータ構造を用いて同じ要求番号を持つペアー間で
のデータ受信の終了を判断し、受信終了時に受信確認
（ＡＣＫ）を送り返すことを特徴とする通信方法。
【請求項５】請求項１において、受信要求より前に対応
する送信要求によるデータが到着した場合、そのデータ
を捨て、そのデータが来たことを記憶しておき、後でそ
の受信要求が実際に行われた際に送信側に対して再送要
求（ＮＡＣＫ）を返送することで即座にデータの再送を
行うことを特徴とする通信方法。
【請求項６】請求項１において、送信パケット中にリク
エスト中の最後のパケットであることを示すフィールド
を設け、送信要求の要求データ長が対応する受信要求の
要求データ長よりも小さい場合にはこのフィールドを用
いて送信要求データの終りを受信側に知らせ、送信要求
の要求データ長分のデータについては信頼性のある通信
を行うことを特徴とする通信方法。
【請求項７】請求項６において、送受信終了時に送信要
求データ長が送信要求元及び受信要求元に通知されるこ
とを特徴とする通信方法。
【請求項８】請求項１において、送信要求の要求データ
長が対応する受信要求の要求データ長よりも大きい場合
には受信要求データ長分のデータについては信頼性のあ
る通信を行うことを特徴とする通信方法。
【請求項９】請求項８において、ＡＣＫ中に実際に受信
されたデータ長を入れるフィールドを設け、そのフィー
ルドにより送信側に実際に送られたデータ長を知らせる
ことで送受信終了時に受信要求データ長が送信要求元及
び受信要求元に通知されることを特徴とする通信方法。
【請求項１０】請求項１において、同期送受信の場合に
は送信要求中の送信バッファ中の後半部分のデータを送
信端末上のバッファにコピーして保持し、送信パケット
中に仮ＡＣＫ要求を行うことを示すフィールドを設け、
コピーしない部分の最後のパケットを送出する際にこの
フィールドをセットし、受信側では仮ＡＣＫ要求を行う
ことを示すフィールドがセットされたパケットを受信し
た際にそのパケット以前のすべてのパケットを既に受信
していれば仮ＡＣＫを返送し、送信側ではこの仮ＡＣＫ
受信時に論理コネクションに対する次の送信要求を行う
ことができ、ＡＣＫ受信時に上記送信端末上のコピーデ
ータ保持用バッファを開放することを特徴とする通信方
法。
【請求項１１】請求項１０において、仮ＡＣＫ中に受信
要求中で指定されたデータ長を入れるフィールドを設
け、そのフィールドにより送信側に実際に送受信される
データ長を知らせることで受信要求データ長が送信要求
元及び受信要求元に通知されることを特徴とする通信方
法。
【請求項１２】送信端末と受信端末とを備え、上記送信
端末と上記受信端末とを接続するネットワークを備え、
送信端末と受信端末との間で論理コネクションを張り、
上記送信端末では上記論理コネクションに対し送信要求
を発行し、上記受信端末では上記論理コネクションに対
し受信要求を発行することにより上記ネットワークを介
して上記送信端末から上記受信端末へデータの転送を行
う通信システムにおける上記送信端末の通信方法におい
て、上記受信要求と上記送信要求を対応付けるための識別子
を上記送信要求に付加し、上記受信要求と上記送信要求
を対応付け、受信端末へ上記データを出力することを特
徴とする通信方法。
【請求項１３】送信端末と受信端末とを備え、上記送信
端末と上記受信端末とを接続するネットワークを備え、
送信端末と受信端末との間で論理コネクションを張り、
上記送信端末では上記論理コネクションに対し送信要求
を発行し、上記受信端末では上記論理コネクションに対
し受信要求を発行することにより上記ネットワークを介
して上記送信端末から上記受信端末へデータの転送を行
う通信システムにおける上記受信端末の通信方法におい
て、上記受信要求と上記送信要求を対応付けるための識別子
を上記受信要求に付加し、上記受信要求と上記送信要求
を対応付け、送信端末から送られた上記データを受け取
ることを特徴とする通信方法。
【請求項１４】送信端末と受信端末とを備え、上記送信
端末と上記受信端末とを接続するネットワークを備え、
送信端末と受信端末との間で論理コネクションを張り、
上記送信端末では上記論理コネクションに対し送信要求
を発行し、上記受信端末では上記論理コネクションに対
し受信要求を発行することにより上記ネットワークを介
して上記送信端末から上記受信端末へデータの転送を行
う通信システムにおける上記送信端末の通信プログラム
を格納した記憶媒体において、上記通信プログラムでは、上記受信要求と上記送信要求
を対応付けるための識別子を上記送信要求に付加し、上
記受信要求と上記送信要求を対応付け、受信端末へ上記
データを出力することを特徴とする通信プログラムを格
納した記憶媒体。
【請求項１５】送信端末と受信端末とを備え、上記送信
端末と上記受信端末とを接続するネットワークを備え、
送信端末と受信端末との間で論理コネクションを張り、
上記送信端末では上記論理コネクションに対し送信要求
を発行し、上記受信端末では上記論理コネクションに対
し受信要求を発行することにより上記ネットワークを介
して上記送信端末から上記受信端末へデータの転送を行
う通信システムにおける上記受信端末の通信プログラム
を格納した記憶媒体において、上記通信プログラムでは、上記受信要求と上記送信要求
を対応付けるための識別子を上記受信要求に付加し、上
記受信要求と上記送信要求を対応付け、送信端末から送
られた上記データを受け取ることを特徴とする通信プロ
グラムを格納した記憶媒体。