JPH10229429A - Communication network system - Google Patents
Communication network systemInfo
- Publication number
- JPH10229429A JPH10229429A JP9028692A JP2869297A JPH10229429A JP H10229429 A JPH10229429 A JP H10229429A JP 9028692 A JP9028692 A JP 9028692A JP 2869297 A JP2869297 A JP 2869297A JP H10229429 A JPH10229429 A JP H10229429A
- Authority
- JP
- Japan
- Prior art keywords
- buffer
- transmission
- communication
- data
- network system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
Description
【0001】[0001]
【発明の属する技術分野】本発明は、高速ネットワーク
上における高信頼、高効率、かつ高速なデータ通信を実
現するための通信プロトコルの方式に関するものであ
る。BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a communication protocol for realizing high-reliability, high-efficiency, and high-speed data communication on a high-speed network.
【0002】[0002]
文献名:XTPプロトコルにおけるレート制御機構の評
価 マルチメディア通信と分散処理 59−1(1993.
1.29) 今日における伝送路の高速化は目覚ましく、コンピュー
タ間通信におけるスループットのボトルネックは、伝送
路の速度から計算機の処理能力や通信プロトコルの性能
等へと移りつつある。上記文献は、かかるスループット
のボトルネックとなる問題のうち、通信プロトコルにつ
いて記述したものである。Document name: Evaluation of rate control mechanism in XTP protocol Multimedia communication and distributed processing 59-1 (1993.
1.29) The speeding up of transmission lines today is remarkable, and the bottleneck of throughput in computer-to-computer communication is shifting from the speed of transmission lines to the processing capability of computers and the performance of communication protocols. The above-mentioned document describes a communication protocol among the problems that are bottlenecks in such a throughput.
【0003】そして、上記文献では、その「2.3 XTP
プロトコルにおけるレート制御」の章において、送受信
間の通信においては、受信側からの制御パケットである
CNTLパケットにより要求するスループット値である
rate及び1バーストでの送信バイト数であるburst の各
パラメータ値を送信側に指示し、受信側の処理許容量に
応じたペースで送信側がパケット送信することにより、
高速通信を可能とし、スループットの向上を目指すこと
が記載されている。[0003] In the above document, "2.3 XTP
In the section “Rate control in protocol”, in communication between transmission and reception, it is a throughput value requested by a CNTL packet which is a control packet from the receiving side.
By instructing the transmission side on each parameter value of rate and burst, which is the number of bytes transmitted in one burst, the transmission side transmits packets at a pace corresponding to the processing allowance of the reception side.
It describes that high-speed communication is possible and that throughput is improved.
【0004】[0004]
【発明が解決しようとする課題】ところで、上記文献
(特に、「4.2 パラメータの変更を行なうタイミン
グ」)には、当該文献に示されるXTPプロトコルの手
順にて高速ネットワーク通信を行なう場合、スループッ
ト値及びバースト値の変更タイミングとして、次の3つ
の(a)〜(c)の時点等が考えられることが記述されてい
るものの、かかるタイミングでは、受信側で各パラメー
タ値を常に適正な値が算出されるようにしようとして
も、他のコネクションの設定やアプリケーション状態の
変化などの不確定要素が多く困難であるという課題があ
った。The above document (particularly, "4.2 Timing for Changing Parameters") describes that when performing high-speed network communication by the procedure of the XTP protocol shown in the document, the throughput value and Although it is described that the following three points (a) to (c) can be considered as the burst value change timing, at such a timing, the receiving side always calculates an appropriate value for each parameter value. However, there are many uncertainties such as setting of other connections and changes in the application state, and there is a problem that it is difficult.
【0005】(a)送信側で予想する又はデフォルトのス
ループット値及びバースト値での最初のパケット受信時 (b)受信処理能力を越えた時点 (c)受信処理能力に余裕があると分かった時点 また、これに加え、上記(a)においては適正な値ではな
いこと、(b)においては既に受信能力を越えているの
で、伝送路が長距離の場合には、既に送信側から送出済
みであるパケットが処理不能となること、(c)において
は伝送路帯域を有効に使用できていないこと等により、
高速ネットワークにて有効なスループットを発生できな
いという課題があった。[0005] (a) When the first packet is received at the expected or default throughput value and burst value on the transmission side (b) When the reception processing capability is exceeded (c) When the reception processing capability is found to have a margin In addition, in addition to the above, the value is not an appropriate value in (a), and since the receiving capability is already exceeded in (b), when the transmission path is a long distance, the transmission side has already transmitted the data. Due to the fact that certain packets cannot be processed, and in (c), the transmission path bandwidth cannot be used effectively, etc.
There is a problem that an effective throughput cannot be generated in a high-speed network.
【0006】[0006]
(A) かかる課題を解決するため、第1の発明におけ
る通信ネットワークシステムにおいては、レイヤコネク
ションの設定時に、送信側及び受信側の通信バッファに
必要とされるバッファ量を算出し、当該算出されたバッ
ファ量を各通信バッファに確保するバッファ管理手段を
備えるようにする。(A) In order to solve such a problem, in the communication network system according to the first aspect of the present invention, when a layer connection is set, a buffer amount required for a communication buffer on the transmission side and the reception side is calculated, and the calculated amount is calculated. A buffer management means for securing a buffer amount in each communication buffer is provided.
【0007】以上のように、第1の発明によれば、レイ
ヤコネクションの設定段階で、予め必要とされるバッフ
ァ量を算出してこれを送信側及び受信側の双方の各通信
バッファに確保するので、各コネクションごとに最適な
状態で通信を開始でき、高いスループットを実現でき
る。As described above, according to the first aspect of the present invention, a necessary buffer amount is calculated in advance in the layer connection setting stage, and the calculated buffer amount is secured in each communication buffer on both the transmission side and the reception side. Therefore, communication can be started in an optimal state for each connection, and high throughput can be realized.
【0008】(B) また、第2の発明における通信ネ
ットワークシステムにおいては、上位レイヤが送信デー
タの書込みアドレスを指定するのに先立って、当該送信
データを書き込むべき通信バッファ上のアドレスを、そ
の都度、上位レイヤに対して事前に通知する書込みアド
レス管理手段を備えるようにする。(B) In the communication network system according to the second aspect of the present invention, prior to the upper layer designating the write address of the transmission data, the address on the communication buffer to which the transmission data is to be written is set each time. , Write address management means for notifying the upper layer in advance.
【0009】以上のように、第2の発明によれば、上位
レイヤは、事前に、送信データを書き込むべきアドレス
を認識できるので、無駄なメモリコピーを行わなくて済
み、高速なスループットを実現できる。As described above, according to the second aspect, since the upper layer can recognize the address to which the transmission data is to be written in advance, unnecessary memory copying is not performed, and high-speed throughput can be realized. .
【0010】(C) さらに、第3の発明における通信
ネットワークシステムにおいては、受信側の通信バッフ
ァに確保されたバッファ量と、受信側から応答のあった
送信データに対する肯定応答の受信回数とに基づいて、
上記受信側の通信バッファに現存するバッファ残量を常
時監視するバッファ残量監視手段を送信側に備えるよう
にする。(C) Further, in the communication network system according to the third aspect of the present invention, based on the amount of buffer secured in the communication buffer on the receiving side and the number of times of acknowledgment of transmission data responded by the receiving side. hand,
The transmitting side is provided with buffer remaining amount monitoring means for constantly monitoring the remaining buffer amount existing in the communication buffer on the receiving side.
【0011】以上のように、第3の発明によれば、送信
側において、常時、受信側の通信バッファのバッファ残
量を監視できるので、バッファ残量に余裕がある限り、
肯定応答を待たずに後続する送信データを送信でき、ス
ループットを向上させることができる。As described above, according to the third aspect, the transmission side can always monitor the remaining buffer capacity of the communication buffer on the receiving side.
Subsequent transmission data can be transmitted without waiting for an acknowledgment, and the throughput can be improved.
【0012】[0012]
(A)実施形態 (A−1)実施形態の構成 以下、本実施形態に係るプロトコル処理を実行するプロ
トコル処理部の構成を、図面を参照しつつ説明する。図
2は、本実施形態に係るプロトコル処理部のOSI(Op
en System Interconnection )レイヤ構造上での位置づ
けを表した図である。図2に示すように、当該プロトコ
ル処理部の処理は、トランスポート層及びネットワーク
層での処理に対応している。(A) Embodiment (A-1) Configuration of Embodiment Hereinafter, the configuration of a protocol processing unit that executes protocol processing according to the present embodiment will be described with reference to the drawings. FIG. 2 shows the OSI (Op.
en System Interconnection) It is a diagram showing the position on the layer structure. As shown in FIG. 2, the processing of the protocol processing unit corresponds to the processing in the transport layer and the network layer.
【0013】図3は、このプロトコル処理部の機能構成
を表したブロック図である。図3に示すように、本実施
形態に係るプロトコル処理部1は、通信メモリバッファ
2、受信メモリバッファ3、メモリ管理部4、ヘッダ処
理部5及びプロトコル制御部6からなる。FIG. 3 is a block diagram showing a functional configuration of the protocol processing unit. As shown in FIG. 3, the protocol processing unit 1 according to the present embodiment includes a communication memory buffer 2, a reception memory buffer 3, a memory management unit 4, a header processing unit 5, and a protocol control unit 6.
【0014】ここで、送信メモリバッファ2は、通信時
にネットワークへ送信される送信データを一時格納する
のに用いられるバッファである。受信メモリバッファ3
は、通信時にネットワークを介して受信された受信デー
タを一時格納するのに用いられるバッファである。Here, the transmission memory buffer 2 is a buffer used for temporarily storing transmission data transmitted to the network during communication. Receive memory buffer 3
Is a buffer used for temporarily storing received data received via a network during communication.
【0015】メモリ管理部4は、送信メモリバッファ2
及び受信メモリバッファ3の読み書き及び領域管理を実
行する管理部であり、アプリケーション部(図2)から
要求があった場合、要求に応じてアプリケーションデー
タ部とプロトコルヘッダ部に対応するメモリ領域を図4
に示す構成で確保する。また、メモリ管理部4は、アプ
リケーション部(図2)に対して、次の送信バッファア
ドレス及び受信バッファアドレスを通知すると共に、送
信処理及び受信処理の完了したメモリバッファの解放及
び再利用が巡回的に行われるよう制御しかつ管理する。The memory management unit 4 includes the transmission memory buffer 2
And a management unit that executes reading and writing of the reception memory buffer 3 and area management. When there is a request from the application unit (FIG. 2), the memory area corresponding to the application data unit and the protocol header unit is changed according to the request.
Secure with the configuration shown in In addition, the memory management unit 4 notifies the application unit (FIG. 2) of the next transmission buffer address and the next reception buffer address, and releases and reuses the memory buffer for which the transmission processing and the reception processing have been completed. Controls and manages what happens.
【0016】ヘッダ処理部5は、送信パケットについて
のヘッダ情報の作成、受信バッファについてのヘッダ情
報の解析を行ない、パケットデータの誤り検出及び回復
処理を制御する。The header processing unit 5 creates header information for a transmission packet, analyzes the header information for a reception buffer, and controls error detection and recovery processing of packet data.
【0017】プロトコル制御部6は、パケットの送信・
受信に関する一連の動作を制御する手段であり、送信時
には受信メモリバッファ3の管理を行なって、送信ぺー
スを制御するようになっている。The protocol control unit 6 transmits and receives packets.
This is a means for controlling a series of operations related to reception, and manages the reception memory buffer 3 at the time of transmission to control the transmission pace.
【0018】(A−2)実施形態の動作 続いて、送信側及び受信側の端末間において実行される
通信プロトコル手順を、図1、図5及び図6を用いて説
明する。なおここで、図1は、送信側のプロトコル処理
部1が受信側との間で実行する主要な処理手順を表した
図であり、図5は、受信側のプロトコル処理部1が送信
側との間で実行する主要な処理手順を表した図である。
また、図6は、図1及び図5の制御に基づいて実現され
る通信プロトコル手順の全体を表す図である。(A-2) Operation of the Embodiment Next, a communication protocol procedure executed between the terminal on the transmitting side and the terminal on the receiving side will be described with reference to FIGS. 1, 5 and 6. Here, FIG. 1 is a diagram showing a main processing procedure executed by the protocol processor 1 on the transmitting side between the transmitting side and the receiving side. FIG. It is a figure showing the main processing procedure performed between.
FIG. 6 is a diagram showing the entire communication protocol procedure realized based on the control of FIGS. 1 and 5.
【0019】なお、以下の説明においては、図6に示す
処理の流れに沿って、本実施形態に係る通信プロトコル
手順を説明する。また、以下の項目記号(a)〜(h)は、
それぞれ図6の該当部分での動作を示している。In the following description, the communication protocol procedure according to the present embodiment will be described along the processing flow shown in FIG. The following item symbols (a) to (h)
Each operation in the corresponding part of FIG. 6 is shown.
【0020】(a)送信開始要求動作 まず、送信側のアプリケーション部からプロトコル処理
部1のプロトコル制御部6に対して「送信開始要求」が
通知される。この「送信開始要求」は、次の(a1)及び
(a2)の情報からなる。(A) Transmission start request operation First, a transmission start request is notified from the application unit on the transmission side to the protocol control unit 6 of the protocol processing unit 1. This “transmission start request” includes the following information (a1) and (a2).
【0021】(a1)送信データを渡す際のデータ単位サ
イズ (a2)最大受渡しレート(例えば、1秒間に最大何回の
データを受渡すか) プロトコル制御部6は、この要求を入力すると、受信側
端末間でのコネクションの設定に必要な情報(一般的に
従来から必要とされている情報)及び送信時のタイムス
タンプを含む要求(以下、「コネクション設定要求」と
いう)をネットワークを介して受信側のプロトコル処理
部16に対して送信する。この送信処理が、図1のステ
ップSP1の処理である。(A1) Data unit size when transmitting transmission data (a2) Maximum transfer rate (for example, how many times data should be transferred per second) When this request is input, the protocol control unit 6 A request including information necessary for setting up a connection between terminals (generally required information in the past) and a time stamp at the time of transmission (hereinafter, referred to as a “connection setting request”) is transmitted via a network to a receiving side. To the protocol processing unit 16. This transmission processing is the processing of step SP1 in FIG.
【0022】(b)コネクション設定要求動作 一方、受信側のプロトコル処理部1においては、受信側
のアプリケーション部からの「受信開始要求」をプロト
コル制御部6で受け、送信側から「コネクション設定要
求」が通知されるのを待ち受ける動作状態になる。この
処理が、図5のステップSP11の処理である。(B) Connection setting request operation On the other hand, in the protocol processing unit 1 on the receiving side, a "reception start request" from the application unit on the receiving side is received by the protocol control unit 6, and a "connection setting request" is received from the transmitting side. Becomes an operation state of waiting for the notification. This process is the process of step SP11 in FIG.
【0023】やがて、「コネクション設定要求」がネッ
トワークを介して受信されたことが確認されると、受信
側のプロトコル制御部6は、コネクション設定の受け入
れ準備を行ない、受信されたタイムスタンプ情報をその
まま含む「コネクション設定確認」を、送信側のプロト
コル制御部6へ返信する。この送信処理が、図5のステ
ップSP12の処理である。When it is confirmed that the “connection setting request” has been received via the network, the protocol control unit 6 on the receiving side prepares for accepting the connection setting, and receives the received time stamp information as it is. A “connection setting confirmation” is returned to the protocol control unit 6 on the transmission side. This transmission process is the process of step SP12 in FIG.
【0024】なおここでのコネクション設定の受け入れ
準備とは、従来のTCPプロトコルで見られるようなア
プリケーションポート番号の割り当て等の処理である。Note that the preparation for accepting the connection setting here is processing such as assignment of an application port number as seen in the conventional TCP protocol.
【0025】(c)リソース確保要求動作 次に、送信側のプロトコル制御部6は、「コネクション
設定確認」が受信されると、受け取った確認に含まれて
いる、「コネクション設定要求」を送出した時点でのタ
イムスタンプ情報とこれに対する確認が到着した時点
(現在)のタイムスタンプ情報から伝送路往復遅延時間
(ラウンドトリップタイム:以下、RTTという)を計
算する。そして、当該プロトコル制御部6は、計算によ
り求めたRTTと、上記(a2)の最大レートと、送受信
データの処理に要する予測処理時間とを次の計算式に代
入し、最大受渡しレートでデータ送信するときに必要と
なるバッファ量を算出する。(C) Resource Securing Request Operation Next, upon receiving the “connection setting confirmation”, the transmitting side protocol control unit 6 sends out the “connection setting request” included in the received confirmation. A round trip time (round trip time: hereinafter, referred to as RTT) is calculated from the time stamp information at the time and the time stamp information at the time when the confirmation of the time arrives (current). Then, the protocol control unit 6 substitutes the calculated RTT, the maximum rate of the above (a2), and the estimated processing time required for processing the transmission / reception data into the following formula, and transmits the data at the maximum delivery rate. Calculate the amount of buffer required when executing.
【0026】バッファ量=(最大受渡しレート)×(RT
T+(送信処理時間+受信処理時間) この処理が、図1のステップSP3の処理である。そし
て、当該量を計算により求めたプロトコル制御部6は、
このバッファ量と上記(a1)の受渡しデータ単位サイズ
を含む「リソース確保要求」を、受信側のプロトコル制
御部6に送信する。この処理が、図1のステップSP4
の処理である。Buffer amount = (maximum delivery rate) × (RT
T + (transmission processing time + reception processing time) This processing is the processing of step SP3 in FIG. Then, the protocol control unit 6 that has calculated the amount is:
A “resource reservation request” including the buffer amount and the size of the data unit to be transferred described in (a1) is transmitted to the protocol controller 6 on the receiving side. This processing corresponds to step SP4 in FIG.
This is the process.
【0027】(d)リソース確保応答動作 受信側のプロトコル制御部6は、前述の(b)で「コネク
ション設定確認」を送出した後、「リソース確保要求」
が受信されるの待ち受ける状態にある。この処理が、図
5のステップSP13の処理である。(D) Resource securing response operation After transmitting the “connection setting confirmation” in the above (b), the protocol control unit 6 on the receiving side transmits the “resource securing request”.
Are waiting to be received. This process is the process of step SP13 in FIG.
【0028】「リソース確保要求」が受信されたことが
確認されると、プロトコル制御部6は、当該プロトコル
メッセージに含まれるバッファ量情報と受渡しデータ単
位サイズをメモリ管理部4に通知し、通信に必要な量の
バッファ領域の確保を要求する。この処理が、図5のス
テップSP14の処理である。When it is confirmed that the “resource securing request” has been received, the protocol control unit 6 notifies the memory management unit 4 of the buffer amount information and the size of the data to be transferred included in the protocol message, and performs the communication. Requests the necessary amount of buffer space. This process is the process of step SP14 in FIG.
【0029】メモリ管理部4は、図3において示したア
プリケーションデータ部の総量が、送信側から要求され
た上記バッファ量になり、かつ、1つのアプリケーショ
ンデータ部のサイズがアプリケーション受渡しデータ単
位サイズになるように、図3に示す構造で領域を受信メ
モリバッファ3上に確保する。ただし、この場合にメモ
リ不足等が起きる場合には、その時点で確保可能な適当
な量のバッファ領域を確保することになる。いずれにし
ても、メモリ管理部4は、実際に確保できた結果をプロ
トコル制御部6に通知する。プロトコル制御部6は、実
際に確保できたバッファ量を情報として含んだ「リソー
ス確保応答」を、送信側へ送信する。この処理が、図5
のステップSP15の処理である。In the memory management section 4, the total amount of the application data section shown in FIG. 3 becomes the buffer amount requested by the transmission side, and the size of one application data section becomes the application transfer data unit size. As described above, an area is secured on the reception memory buffer 3 with the structure shown in FIG. However, in this case, if a memory shortage or the like occurs, an appropriate amount of buffer area that can be secured at that time is secured. In any case, the memory management unit 4 notifies the protocol control unit 6 of the actually secured result. The protocol control unit 6 transmits a “resource securing response” including the actually secured buffer amount as information to the transmitting side. This process is shown in FIG.
Is the process of step SP15.
【0030】この後、プロトコル制御部6は、自装置内
のアプリケーション部に対して「受信開始確認」を通知
し、受信準備が整ったことを通知する。受信側のアプリ
ケーション部は、この通知を受信すると、「次データ受
信開始」をプロトコル制御部6に通知する。「次データ
受信開始」を通知されたプロトコル制御部6は、受信デ
ータ待ちとなる。この処理が、図5のステップSP16
の処理である。Thereafter, the protocol control section 6 notifies the application section in its own device of "confirmation of reception start", and notifies that the preparation for reception is completed. Upon receiving this notification, the receiving-side application unit notifies the protocol control unit 6 of "start of next data reception". The protocol control unit 6 notified of "start of next data reception" waits for reception data. This processing corresponds to step SP16 in FIG.
This is the process.
【0031】(e)送信開始確認動作 送信側のプロトコル制御部6は、受信側から「リソース
確保応答」を受信すると、受信メッセージ中に含まれる
実際に確保されたバッファサイズと受渡しデータ単位サ
イズをメモリ管理部4に通知する。この処理が、図1の
ステップSP5の処理である。(E) Transmission Start Confirmation Operation Upon receiving the “resource reservation response” from the reception side, the protocol control unit 6 on the transmission side determines the actually reserved buffer size and the delivery data unit size contained in the received message. Notify the memory management unit 4. This process is the process of step SP5 in FIG.
【0032】このとき、メモリ管理部4は、前述の(d)
の処理において受信側のメモリ管理部4が行ったのと同
様に通信メモリバッファ2上にバッファ領域を確保す
る。この処理が、図1のステップSP6の処理である。
この後、メモリ管理部4は、自装置内(送信側)のアプ
リケーション部に対し、通信メモリバッファ2上に確保
されている最初のアプリケーションデータ部の先頭アド
レスを、「送信開始確認」として通知する。At this time, the memory management unit 4 executes the above (d)
A buffer area is secured in the communication memory buffer 2 in the same manner as performed by the memory management unit 4 on the receiving side in the process (1). This process is the process of step SP6 in FIG.
Thereafter, the memory management unit 4 notifies the application unit in the own device (transmission side) of the start address of the first application data unit secured in the communication memory buffer 2 as “transmission start confirmation”. .
【0033】(f)「データ送信−1」及び「データ1送
信」動作 前述の(e)での通知を受けた送信側のアプリケーション
部は、受渡しデータサイズ分の送信データを、上記通知
によって特定されたアドレスに対して書き込み、そのこ
とを「データ送信−1」としてプロトコル処理部1に通
知する。ここで、「データ送信−1」は、1回目の送信
データの書込みが完了したことを意味する。またこのと
き、アプリケーション部が書き込むデータサイズは、必
ずしもデータサイズ分である必要はない。(F) "Data transmission -1" and "Data 1 transmission" operations Upon receiving the notification in the above (e), the transmitting-side application section specifies transmission data of the size of the data to be transferred by the notification. The data is written to the received address, and this is notified to the protocol processing unit 1 as "data transmission-1". Here, "data transmission-1" means that the first transmission data writing has been completed. At this time, the data size written by the application unit does not necessarily need to be the data size.
【0034】送信側のプロトコル処理部1では、「デー
タ送信−1」が通知されると、ヘッダ処理部5によっ
て、書き込まれたアプリケーションデータ部を処理して
誤り訂正情報を作成すると共に、パケットシーケンス番
号、送信側ポート番号、受信側ポート番号、パケット種
別等の情報を作成する。ヘッダ処理部5は、この情報
を、通信メモリバッファ2のうち該当するアプリケーシ
ョンデータ部のヘッダ情報部に書き込む。これらの処理
が、図1のステップSP7の処理である。In the transmission-side protocol processing section 1, when "data transmission-1" is notified, the header processing section 5 processes the written application data section to create error correction information, Information such as a number, a port number on the transmission side, a port number on the reception side, and a packet type is created. The header processing section 5 writes this information in the header information section of the corresponding application data section in the communication memory buffer 2. These processes are the process of step SP7 in FIG.
【0035】以上の処理が終了すると、プロトコル制御
部6は、「データ1送信」として通信メモリバッファ2
上に書き込まれているヘッダ情報及びアプリケーション
データを、パケットとして受信側のプロトコル処理部1
へ送信する。このとき、送信されるパケットは、アプリ
ケーション部が書き込みを行なったアプリケーションデ
ータの実データ長に関わらず、確保した1パケット分の
固定長での送信である。この処理が、図1のステップS
P8の処理である。When the above processing is completed, the protocol control unit 6 sets the communication memory buffer 2 as "data 1 transmission".
The header information and application data written on the upper side are converted into packets as a protocol processing unit 1 on the receiving side.
Send to At this time, the transmitted packet has a fixed length of one secured packet regardless of the actual data length of the application data written by the application unit. This processing corresponds to step S in FIG.
This is the process of P8.
【0036】その後、送信側のプロトコル処理部1のメ
モリ管理部4は、通信メモリバッファ2上に存在する次
のアプリケーションデータ部の先頭アドレスを、「次デ
ータ送信開始」としてアプリケーション部に通知する。Thereafter, the memory management section 4 of the protocol processing section 1 on the transmission side notifies the application section of the start address of the next application data section existing in the communication memory buffer 2 as "start of next data transmission".
【0037】ここで、「データ送信−1」及び「次デー
タ送信開始」などの処理は、プログラム上での関数コー
ル及び関数リターンなどに該当する形式で行なわれるこ
とが望ましい。Here, processing such as "data transmission-1" and "start next data transmission" is desirably performed in a format corresponding to a function call and a function return on a program.
【0038】(g)「データ受信−1」、「次データ受信
開始」及び「データ1受信確認」動作 受信側のプロトコル処理部1では、前述の(d)の処理の
後、データが受信されるのを待ち受ける状態になってい
るが、やがて、ネットワークを介して「データ1送信」
が受信されると、当該受信パケットを、受信メモリバッ
ファ3に書き込む。(G) "Data reception-1", "Next data reception start", and "Data 1 reception confirmation" operations The protocol processor 1 on the receiving side receives the data after the above-mentioned process (d). It is in a state of waiting for data, but eventually "data 1 transmission" via the network
Is received, the received packet is written into the reception memory buffer 3.
【0039】この書込みが終了すると、ヘッダ処理部5
がヘッダ解析の他、誤り検出及び訂正処理を行なう。こ
の処理が、図5のステップSP17の処理である。ここ
で検査結果等が正常であれば、メモリ管理部4が、受信
メモリバッファ3に書き込まれた受信パケットのアプリ
ケーションデータ部の先頭アドレスを「データ受信−
1」としてアプリケーション部へ通知する。この処理
が、図5のステップSP18で肯定結果が得られてステ
ップSP19に移行する処理である。When the writing is completed, the header processing unit 5
Performs error detection and correction processing in addition to header analysis. This process is the process of step SP17 in FIG. If the inspection result or the like is normal, the memory management unit 4 sets the start address of the application data portion of the received packet written in the reception memory buffer 3 to “data reception-
Notify the application unit as "1". This process is a process in which a positive result is obtained in step SP18 of FIG. 5 and the process proceeds to step SP19.
【0040】かかる処理が終了すると、「データ受信−
1」によって受信データを渡されたアプリケーション部
は、次データの取得のために「次データ受信開始」を、
そのプロトコル処理部1に対して通知する。なお、この
「次データ受信開始」の通知を受けたメモリ管理部4で
は、アプリケーション部に対して前回通知したアドレス
に該当する受信メモリバッファ3上の領域を再利用のた
めに解放する。When this processing is completed, "Data reception-
The application unit to which the received data is passed by “1” sets “Start next data reception” to acquire the next data.
Notify the protocol processing unit 1. The memory management unit 4 that has received the notification of “start of next data reception” releases the area on the reception memory buffer 3 corresponding to the address previously notified to the application unit for reuse.
【0041】その後、ヘッダ処理部5が応答のヘッダを
作成するので、これをプロトコル処理部1が、「データ
1受信確認」として、送信側のプロトコル処理部1に対
して送信される。After that, the header processing unit 5 creates a response header, which is transmitted to the protocol processing unit 1 on the transmission side by the protocol processing unit 1 as "data 1 reception confirmation".
【0042】ところで、前述の誤り検出処理時において
パケットデータに誤りが検出された場合、ヘッダ処理部
5は、パケットの再送を求めるため、NACKを即座に
送信側に送信し、この際には受信バッファメモリ3への
データ書き込みは行なわない。この処理が、図5におけ
るステップSP18で否定結果が得られ、ステップSP
21に移行する処理である。When an error is detected in the packet data during the above-described error detection processing, the header processing unit 5 immediately transmits a NACK to the transmitting side to request retransmission of the packet. No data writing to the buffer memory 3 is performed. In this process, a negative result is obtained in step SP18 in FIG.
21.
【0043】(h)「コネクション解放要求」及び「コネ
クション解放確認」動作 以後、前述(f)〜(g)の処理が繰り返され、データの送
信が行なわれる。これは、図1のステップSP9−ステ
ップSP7−ステップSP8の繰り返しループ処理及び
図5のステップSP20−ステップSP16−ステップ
SP17−ステップSP18−ステップSP19、21
の繰り返しループ処理に該当する。(H) "Connection release request" and "connection release confirmation" operations After that, the above-mentioned processes (f) to (g) are repeated, and data transmission is performed. This corresponds to the repetitive loop processing of step SP9-step SP7-step SP8 in FIG. 1 and step SP20-step SP16-step SP17-step SP18-step SP19, 21 in FIG.
Corresponds to the repetition loop processing.
【0044】なおこのとき、送信側のプロトコル制御部
6では、受信側で確保されているバッファ量、受信側の
プロトコル処理部1へのパケット送信の回数、その応答
の受信回数から受信側の確保バッファの空き容量を常に
監視し続けている。従って、受信側の受信メモリバッフ
ァ3に空き容量がある限りにおいては、パケットの送信
を送信側のアプリケーション部の要求に応じて送り続け
ることになる。このことを、図6の2回目の送信パケッ
トが1回目の送信パケットの応答を待たずに送出されて
いることが表している。At this time, the protocol control unit 6 on the transmitting side secures the receiving side based on the buffer amount secured on the receiving side, the number of packet transmissions to the protocol processing unit 1 on the receiving side, and the number of receptions of the response. We constantly monitor the free space in the buffer. Therefore, as long as there is free space in the receiving memory buffer 3 on the receiving side, the transmission of the packet continues to be transmitted in response to a request from the application unit on the transmitting side. This indicates that the second transmission packet in FIG. 6 is transmitted without waiting for the response of the first transmission packet.
【0045】またこのとき、送信側のプロトコル処理部
1は、「データ1受信確認」などの正常な受信の確認を
通知する応答が受信された時、送信メモリバッファメモ
リ2のうち該当する部分の領域を管理部4が解放するよ
うになっている。At this time, when a response notifying of normal reception confirmation such as “data 1 reception confirmation” is received, the protocol processing unit 1 on the transmission side transmits the corresponding part of the transmission memory buffer memory 2. The management unit 4 releases the area.
【0046】ただし、このとき、受信側のヘッダ処理部
5が受信されたパケットにデータ誤りを検出し、「デー
タ1受信確認」などで異常応答を示す再送要求(NA
K)を送信側に通知した場合には、受信側のプロトコル
処理部1は、誤りの検出されたパケット以降のデータを
受信メモリバッファ3上に蓄積したままの状態にするよ
う動作する。他方、送信側のプロトコル処理部1は、次
の送信で、即座に該当パケットのみの再送を行なう選択
再送方式による再送を行なう。受信側では、再送パケッ
トの処理を行ない正常が確認された場合には、「データ
1受信確認」を送信側に返信するとともに、蓄積してお
いた受信メモリバッファ3上のアプリケーションデータ
を順次通知して行く。However, at this time, the header processing unit 5 on the receiving side detects a data error in the received packet, and indicates a retransmission request (NA
When K) is notified to the transmitting side, the protocol processing unit 1 on the receiving side operates to keep the data after the packet in which the error is detected stored in the receiving memory buffer 3. On the other hand, in the next transmission, the protocol processing unit 1 on the transmission side performs retransmission by the selective retransmission method in which only the corresponding packet is immediately retransmitted. On the receiving side, when the retransmission packet is processed and normality is confirmed, "data 1 reception confirmation" is returned to the transmitting side and the stored application data in the reception memory buffer 3 is sequentially notified. Go.
【0047】なお、上記の説明において、選択再送方式
については周知の技術であるので特に説明は付加しな
い。また、コネクション解放の手順についても、本実施
形態の本論とは直接関係ないので、これも詳細な説明は
省略する。いずれにしても、一連の処理の終了が確認さ
れると、設定されたコネクションが解放される。この処
理が、図1のステップSP10及び図5のステップSP
22の動作である。In the above description, the selective retransmission method is a well-known technique and will not be further described. Also, the procedure for releasing the connection is not directly related to the main point of the present embodiment, so that the detailed description thereof is also omitted. In any case, when the end of the series of processing is confirmed, the set connection is released. This processing corresponds to step SP10 in FIG. 1 and step SP10 in FIG.
22.
【0048】また、上記の動作説明における各通知メッ
セージなどは説明の簡単化のために明解な名前を付与し
ているが、実際の実装に強制されるものではない。同様
に、通知などの語句も実装方法に制限を与えるものでは
ない。Although each notification message in the above description of the operation is given a clear name for simplification of the description, it is not forced to be actually implemented. Similarly, words such as notifications do not limit the implementation method.
【0049】(A−3)実施形態の効果 以上のように本実施形態によれば、以下に示す効果が得
られる。(A-3) Effects of the Embodiment As described above, according to the present embodiment, the following effects can be obtained.
【0050】(1) まず、第1に、「実施形態の動作」
の(c)において示したように、通信開始に先立って送信
側のプロトコル処理部が、伝送路往復遅延時間(RT
T)とデータ処理時間に基づいて最大受渡しレートでデ
ータ送信をする場合に必要となるバッファ量を算出し、
これを受信側の受信バッファメモリ3上に確保するよう
にしたことにより、また、確保できない場合でも実際に
確保できたバッファ量を送信開始前に送信側に通知する
ようにしたことにより、送信側のアプリケーション部が
最大受渡しレートでデータを送信する合にも、ある時点
で受信されたパケットに対する正常受信(ACK)が送
信側に到着するまでは、送信側が連続してパケットを送
信し続けることが可能となる。つまり、伝送路に空き時
間を作ることなく、パケットを連続的に送信することに
なるので、スループットの向上が期待できる。(1) First, "Operation of Embodiment"
As shown in (c), before starting communication, the protocol processing unit on the transmitting side transmits the round trip delay time (RT
T) and the data processing time, calculate the buffer amount required when transmitting data at the maximum delivery rate,
This is ensured in the receiving buffer memory 3 of the receiving side, and even if it cannot be secured, the actually secured buffer amount is notified to the transmitting side before the start of transmission. Even if the application unit of the above transmits data at the maximum delivery rate, the transmitting side may continue to transmit packets continuously until normal reception (ACK) for the packet received at a certain point of time arrives at the transmitting side. It becomes possible. In other words, packets are continuously transmitted without creating an idle time in the transmission path, and therefore, an improvement in throughput can be expected.
【0051】しかも、コネクションごとにバッファ量の
設定が可能となるので、伝送路の能力速度の許容値まで
のスループットが確保可能である。Moreover, since the buffer amount can be set for each connection, it is possible to secure a throughput up to the permissible value of the transmission line capacity speed.
【0052】また、受信側で受信パケットに誤りを検出
した場合にも、NACKを送信側に通知し、送信側では
選択再送方式による該当パケットのみの再送を、NAC
K受信後に即座に行なう再送方式で行なうことにより、
受信側では、送信側からの再送パケットが到着するまで
に送信側から送り出された全てのパケットを受信メモリ
バッファ3においてバッファリング可能であることか
ら、パケット誤り時にもスループットは低下しない。Also, when an error is detected in a received packet on the receiving side, a NACK is notified to the transmitting side, and the transmitting side retransmits only the corresponding packet by the selective retransmission method.
By performing the retransmission method immediately after receiving K,
On the receiving side, all packets transmitted from the transmitting side can be buffered in the receiving memory buffer 3 until the retransmission packet from the transmitting side arrives. Therefore, even if a packet error occurs, the throughput does not decrease.
【0053】(2) 第2に、送信メモリバッファ2及び受
信メモリバッファ3に固定構造でメモリ領域を確保し、
送受信パケットを固定長で扱い、アプリケーションから
のデータを分割しないことにより、パケット長の計算に
よるオーバヘッド及びパケットに付随するヘッダ部分の
削減、データ分割と組み立てにかかる処理時間の削減が
可能となり、スループットの向上が実現できる。(2) Second, a memory area is secured in the transmission memory buffer 2 and the reception memory buffer 3 with a fixed structure,
By handling transmitted / received packets with a fixed length and not dividing data from the application, it is possible to reduce the overhead due to the calculation of the packet length, reduce the header portion attached to the packet, and reduce the processing time required for data division and assembly, thereby reducing throughput. Improvement can be realized.
【0054】また、より高速化を実現するためのハード
ウェア処理の実現も容易である。Also, it is easy to realize hardware processing for realizing higher speed.
【0055】(3) 第3に、上記(1) の受信バッファ量
と、ACK受信による受信側バッファ量の残量を送信側
で管理するようにしたことにより、受信側の受信データ
の処理ペースに応じて送信側がデータ送信することが可
能となり、受信側バッファのオーバーフローの防止が可
能となる。またその時点での最適なスループットを実現
できるようになる。(3) Thirdly, since the receiving side manages the receiving buffer amount and the remaining amount of the receiving side buffer amount by ACK reception at the transmitting side, the processing speed of the receiving data at the receiving side is increased. , The transmission side can transmit data, and overflow of the reception side buffer can be prevented. Also, the optimum throughput at that time can be realized.
【0056】(4) 第4に、プロトコル処理部内で確保し
たバッファメモリをアドレス通知という形でアプリケー
ション部に公開する方式をとることにより、余分なメモ
リコピーを行なう必要がなくなり、高速なプロトコル処
理が可能となる。(4) Fourth, by adopting a method in which the buffer memory secured in the protocol processing unit is disclosed to the application unit in the form of an address notification, there is no need to perform extra memory copying, and high-speed protocol processing can be performed. It becomes possible.
【0057】(5) 第5に、データ誤りのあるパケット受
信の際には、即座に通信側に再送要求を行なうようにし
たことにより、再送による遅延を最小限に抑えることが
可能となる。(5) Fifth, when a packet having a data error is received, a retransmission request is immediately sent to the communication side, so that delay due to retransmission can be minimized.
【0058】(B)他の実施形態 (B-1) なお、上述の実施形態においては、本方式で実
現されるプロトコル処理部を、OSIレイヤ階層におけ
るネットワーク層及びトランスポート層に適用する場合
について述べたが、本方式を実施する環境としては、実
施形態のような計算処理能力とメモリ装置とを有する計
算機であれば他のレイヤ階層にも適用可能である。(B) Other Embodiments (B-1) In the above embodiment, the case where the protocol processing unit realized by this method is applied to the network layer and the transport layer in the OSI layer hierarchy is described. As described above, the environment in which the present method is implemented can be applied to other layer hierarchies as long as the computer has a calculation processing capability and a memory device as in the embodiment.
【0059】すなわち、本機能の適用としては、通信機
能を具備するコンピュータ端末の内部機能、又は、外部
のフロントエンドプロセッサとしての位置づけである通
信装置等に実装されることとなる。That is, this function is applied to an internal function of a computer terminal having a communication function, or to a communication device positioned as an external front-end processor.
【0060】(B-2) また、上述の実施形態において説
明した方式は、特に、光ファイバを用いた高速、広帯域
ネットワークと呼ばれるネットワークにて適用した場合
に最も効果を発揮する。(B-2) The method described in the above embodiment is most effective particularly when applied to a network called a high-speed, wideband network using optical fibers.
【0061】[0061]
【発明の効果】上述のように、第1の発明によれば、レ
イヤコネクションの設定時に、送信側及び受信側の通信
バッファに必要とされるバッファ量を算出し、当該算出
されたバッファ量を各通信バッファに確保するバッファ
管理手段を通信ネットワークシステムに備えるようにし
たことにより、各コネクションごとに最適な状態で通信
を開始することができる。As described above, according to the first aspect of the present invention, when a layer connection is set, the buffer amounts required for the communication buffers on the transmitting side and the receiving side are calculated, and the calculated buffer amounts are calculated. By providing the communication network system with the buffer management means for securing each communication buffer, communication can be started in an optimum state for each connection.
【0062】また、第2の発明によれば、上位レイヤが
送信データの書込みアドレスを指定するのに先立って、
当該送信データを書き込むべき通信バッファ上のアドレ
スを、その都度、上位レイヤに対して事前に通知する書
込みアドレス管理手段を通信ネットワークシステムに備
えるようにしたことにより、無駄なメモリコピーを行う
おそれを有効に回避でき、その分、スループットを一段
と向上することができる。According to the second invention, prior to the upper layer designating the write address of the transmission data,
By providing the communication network system with a write address management means for notifying the address in the communication buffer to which the transmission data is to be written to the upper layer each time, the possibility of performing unnecessary memory copy is effectively reduced. And the throughput can be further improved accordingly.
【0063】さらに、第3の発明によれば、受信側の通
信バッファに確保されたバッファ量と、受信側から応答
のあった送信データに対する肯定応答の受信回数とに基
づいて、上記受信側の通信バッファに現存するバッファ
残量を常時監視するバッファ残量監視手段を通信ネット
ワークシステムの送信側に備えるようにしたことによ
り、送信側において、受信側の通信バッファのバッファ
残量に余裕があると判断できる限り、肯定応答を待たず
に後続する送信データを送信でき、スループットを向上
させることができる。Further, according to the third aspect of the present invention, based on the buffer amount secured in the communication buffer on the receiving side and the number of times of acknowledgment of the transmission data responded by the receiving side, Since the transmission side of the communication network system is provided with a buffer remaining amount monitoring means for constantly monitoring the remaining buffer amount existing in the communication buffer, it is possible that the transmission side has sufficient buffer remaining amount of the communication buffer on the receiving side. As long as it can be determined, subsequent transmission data can be transmitted without waiting for an acknowledgment, and the throughput can be improved.
【図1】実施形態に係るプロトコル処理部が送信時に使
用する処理手順を示すフローチャートである。FIG. 1 is a flowchart illustrating a processing procedure used at the time of transmission by a protocol processing unit according to an embodiment.
【図2】プロトコル処理部のOSIレイヤ階層上での位
置づけ例を示した図表である。FIG. 2 is a chart showing an example of the positioning of a protocol processing unit on an OSI layer hierarchy.
【図3】プロトコル処理部の構成例を示すブロック図で
ある。FIG. 3 is a block diagram illustrating a configuration example of a protocol processing unit.
【図4】メモリバッファ上に確保する領域の構成例を示
す図表である。FIG. 4 is a table showing a configuration example of an area to be reserved on a memory buffer;
【図5】実施形態に係るプロトコル処理部が受信時に使
用する処理手順を示すフローチャートである。FIG. 5 is a flowchart illustrating a processing procedure used by the protocol processing unit according to the embodiment at the time of reception.
【図6】通信プロトコル手順の基本概念を示す説明図で
ある。FIG. 6 is an explanatory diagram showing a basic concept of a communication protocol procedure.
【符号の説明】 1…プロトコル処理部、2…通信メモリバッファ、3…
受信メモリバッファ、4…メモリ管理部、5…ヘッダ処
理部、6…プロトコル制御部。[Description of Signs] 1 ... Protocol processing unit 2 ... Communication memory buffer
Receive memory buffer, 4 ... Memory management unit, 5 ... Header processing unit, 6 ... Protocol control unit.
Claims (8)
及び受信側の通信バッファに必要とされるバッファ量を
算出し、当該算出されたバッファ量を各通信バッファに
確保するバッファ管理手段を備えることを特徴とする通
信ネットワークシステム。A buffer management means for calculating a buffer amount required for a communication buffer on a transmission side and a reception side at the time of setting a layer connection and securing the calculated buffer amount in each communication buffer; Characteristic communication network system.
延時間と予想データ処理時間とに基づいて、必要とされ
るバッファ量を算出することを特徴とする請求項1に記
載の通信ネットワークシステム。2. The communication network system according to claim 1, wherein said buffer management means calculates a required buffer amount based on a transmission line round trip delay time and an expected data processing time.
送信側のバッファ管理手段が行い、受信側のバッファ管
理手段へ通知することを特徴とする請求項1又は2に記
載の通信ネットワークシステム。3. The calculation of the required buffer amount is as follows:
3. The communication network system according to claim 1, wherein the buffer management unit on the transmission side performs the notification and notifies the buffer management unit on the reception side.
ら通知されただけのバッファ量を通信バッファ内に確保
できない場合、実際に確保することができたバッファ量
を送信側のバッファ管理手段へ通知することを特徴とす
る請求項3に記載の通信ネットワークシステム。4. The buffer management means on the receiving side, if the buffer amount notified by the transmitting side cannot be reserved in the communication buffer, the buffer management means on the transmitting side transfers the buffer amount actually secured to the buffer management means on the transmission side. The communication network system according to claim 3, wherein the notification is performed.
要求する受渡しデータ長にヘッダ長を加算した固定デー
タ長を、基本単位とする構造を上記通信バッファ上に構
築することを特徴とする請求項1〜4のいずれかに記載
の通信ネットワークシステム。5. The communication system according to claim 1, wherein the buffer management means constructs a structure on the communication buffer using a fixed data length obtained by adding a header length to a transfer data length requested by an upper layer as a basic unit. The communication network system according to any one of claims 1 to 4.
ら上記通信バッファに書き込まれたデータを分割するこ
となく送信することを特徴とする請求項5に記載の通信
ネットワークシステム。6. The communication network system according to claim 5, wherein said buffer management means transmits data written from said upper layer to said communication buffer without dividing.
スを指定するのに先立って、当該送信データを書き込む
べき通信バッファ上のアドレスを、その都度、上位レイ
ヤに対して事前に通知する書込みアドレス管理手段を備
えることを特徴とする通信ネットワークシステム。7. A write address management means for notifying an upper layer of an address on a communication buffer to which the transmission data is to be written each time before an upper layer specifies a write address of transmission data. A communication network system comprising:
ファ量と、受信側から応答のあった送信データに対する
肯定応答の受信回数とに基づいて、上記受信側の通信バ
ッファに現存するバッファ残量を常時監視するバッファ
残量監視手段を送信側に備えることを特徴とする通信ネ
ットワークシステム。8. A buffer remaining in the communication buffer on the receiving side based on the buffer amount secured in the communication buffer on the receiving side and the number of times of acknowledgment of transmission data responding from the receiving side. A communication network system comprising a buffer remaining amount monitoring means for constantly monitoring the data on the transmission side.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP9028692A JPH10229429A (en) | 1997-02-13 | 1997-02-13 | Communication network system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP9028692A JPH10229429A (en) | 1997-02-13 | 1997-02-13 | Communication network system |
Publications (1)
Publication Number | Publication Date |
---|---|
JPH10229429A true JPH10229429A (en) | 1998-08-25 |
Family
ID=12255544
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP9028692A Pending JPH10229429A (en) | 1997-02-13 | 1997-02-13 | Communication network system |
Country Status (1)
Country | Link |
---|---|
JP (1) | JPH10229429A (en) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007201702A (en) * | 2006-01-25 | 2007-08-09 | Mitsubishi Electric Corp | Receiver, communication equipment, and communication method |
WO2008029471A1 (en) * | 2006-09-07 | 2008-03-13 | Media Global Links Co., Ltd. | Simultaneous video output system in multicast |
KR100918731B1 (en) | 2001-04-09 | 2009-09-24 | 텔레폰악티에볼라겟엘엠에릭슨(펍) | Method of controlling a queue buffer |
JP2010074854A (en) * | 2009-11-27 | 2010-04-02 | Nec Corp | Communication device, communication system, method of detecting missing packet, and program for detecting missing packet |
US7995517B2 (en) | 2004-03-24 | 2011-08-09 | Lg Electronics Inc. | System and method for transmitting units of messages in a mobile communication system |
US8233483B2 (en) | 2007-08-28 | 2012-07-31 | Nec Corporation | Communication apparatus, communication system, absent packet detecting method and absent packet detecting program |
JP2015522991A (en) * | 2012-05-14 | 2015-08-06 | アドバンスト・マイクロ・ディバイシズ・インコーポレイテッドAdvanced Micro Devices Incorporated | Server node interconnection device and server node interconnection method |
JP2015536592A (en) * | 2012-10-10 | 2015-12-21 | サムスン エレクトロニクス カンパニー リミテッド | Method and apparatus for media data delivery control |
US10116570B2 (en) | 2015-05-29 | 2018-10-30 | Denso Corporation | In-vehicle network system |
-
1997
- 1997-02-13 JP JP9028692A patent/JPH10229429A/en active Pending
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100918731B1 (en) | 2001-04-09 | 2009-09-24 | 텔레폰악티에볼라겟엘엠에릭슨(펍) | Method of controlling a queue buffer |
US7995517B2 (en) | 2004-03-24 | 2011-08-09 | Lg Electronics Inc. | System and method for transmitting units of messages in a mobile communication system |
JP2007201702A (en) * | 2006-01-25 | 2007-08-09 | Mitsubishi Electric Corp | Receiver, communication equipment, and communication method |
WO2008029471A1 (en) * | 2006-09-07 | 2008-03-13 | Media Global Links Co., Ltd. | Simultaneous video output system in multicast |
US8233483B2 (en) | 2007-08-28 | 2012-07-31 | Nec Corporation | Communication apparatus, communication system, absent packet detecting method and absent packet detecting program |
US9178665B2 (en) | 2007-08-28 | 2015-11-03 | Nec Corporation | Communication apparatus, communication system, absent packet detecting method and absent packet detecting program |
JP2010074854A (en) * | 2009-11-27 | 2010-04-02 | Nec Corp | Communication device, communication system, method of detecting missing packet, and program for detecting missing packet |
JP2015522991A (en) * | 2012-05-14 | 2015-08-06 | アドバンスト・マイクロ・ディバイシズ・インコーポレイテッドAdvanced Micro Devices Incorporated | Server node interconnection device and server node interconnection method |
JP2015536592A (en) * | 2012-10-10 | 2015-12-21 | サムスン エレクトロニクス カンパニー リミテッド | Method and apparatus for media data delivery control |
US10356143B2 (en) | 2012-10-10 | 2019-07-16 | Samsung Electronics Co., Ltd. | Method and apparatus for media data delivery control |
US10382515B2 (en) | 2012-10-10 | 2019-08-13 | Samsung Electronics Co., Ltd. | Method and apparatus for media data delivery control |
US10116570B2 (en) | 2015-05-29 | 2018-10-30 | Denso Corporation | In-vehicle network system |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US5519699A (en) | Method of protocol termination and a packet data communication system applied the method | |
US10430374B2 (en) | Selective acknowledgement of RDMA packets | |
JP4611593B2 (en) | Method and apparatus for performing network operations | |
US8724656B2 (en) | Methods and devices for transmitting data between storage area networks | |
EP0472486A2 (en) | System and method for controlling data transmission | |
CN106788911A (en) | A kind of method and apparatus of message retransmission | |
JPH11252179A (en) | Tcp communication high speed device for asymmetrical line | |
JP2006311543A (en) | Method and device for polling transmission state in radio communication system | |
EP1670214A1 (en) | Reliable one-way messaging over request-response transport protocols | |
CN101119183A (en) | Retransmission control method and transmission equipment | |
WO2012030542A1 (en) | Mechanism for autotuning mass data transfer from a sender to a receiver over parallel connections | |
CN109951260A (en) | A kind of data packet sending method and relevant device | |
JPH10229429A (en) | Communication network system | |
CA2514086C (en) | Methods and devices for transmitting data between storage area networks | |
US7007199B2 (en) | Reliable communication method and device | |
JP2003258880A (en) | Network, node, and method for data transfer | |
US7636313B2 (en) | Use of internal buffer to reduce acknowledgement related delays in acknowledgement-based reliable communication protocols | |
CN111447046B (en) | Service data transmission method, device, equipment and storage medium | |
JPH0552106B2 (en) | ||
US20040148422A1 (en) | Communication control method, communication system, and communication apparatus that can improve throughput | |
JP2002290493A (en) | Data transfer system and transmission side and reception side devices | |
JP4510524B2 (en) | Data communication device | |
JP3436100B2 (en) | Communication method | |
CN115834730A (en) | TCP data packet receiving and transmitting method and system supporting priority out-of-order | |
CN117793170A (en) | Data transmission method and system for weak network edge calculation |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080608 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090608 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 8 Free format text: PAYMENT UNTIL: 20090608 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 9 Free format text: PAYMENT UNTIL: 20100608 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 10 Free format text: PAYMENT UNTIL: 20110608 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 10 Free format text: PAYMENT UNTIL: 20110608 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 11 Free format text: PAYMENT UNTIL: 20120608 |
|
EXPY | Cancellation because of completion of term | ||
FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120608 Year of fee payment: 11 |