JPH0738612A - ゲートウェイ - Google Patents
ゲートウェイInfo
- Publication number
- JPH0738612A JPH0738612A JP5157763A JP15776393A JPH0738612A JP H0738612 A JPH0738612 A JP H0738612A JP 5157763 A JP5157763 A JP 5157763A JP 15776393 A JP15776393 A JP 15776393A JP H0738612 A JPH0738612 A JP H0738612A
- Authority
- JP
- Japan
- Prior art keywords
- data
- flow control
- transmission
- network
- header
- 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
Abstract
(57)【要約】
【目的】 相手先への重複データの送信による、インタ
ネット全体の伝送効率の低下、及び、余分な課金を防止
する。 【構成】 送信元からの再送データを検出し、フロー制
御中に再送データを受信した場合は、通信用バッファ１
０上から再送データを破棄する。
ネット全体の伝送効率の低下、及び、余分な課金を防止
する。 【構成】 送信元からの再送データを検出し、フロー制
御中に再送データを受信した場合は、通信用バッファ１
０上から再送データを破棄する。
Description
【０００１】
【産業上の利用分野】本発明は、伝送速度差（処理能力
差）があり、プロトコルの異なるネットワーク間を相互
接続（インタネット）するゲートウェイに係り、特に、
フロー制御による無駄なデータの送信に関する問題を低
減して、データ伝送の効率を図ることが可能なゲートウ
ェイに関する。
差）があり、プロトコルの異なるネットワーク間を相互
接続（インタネット）するゲートウェイに係り、特に、
フロー制御による無駄なデータの送信に関する問題を低
減して、データ伝送の効率を図ることが可能なゲートウ
ェイに関する。
【０００２】
【従来の技術】最近、ＬＡＮ（ローカル・エリア・ネッ
トワーク）間を広域網（例えば、ＩＳＤＮ、パケット
網）を介して相互接続するインタネットが普及してい
る。今後、更なる普及が予想され、複数のネットワーク
間を相互接続する範囲は、企業内から企業間、業界内か
ら業界間、国内から国外へと拡大している。
トワーク）間を広域網（例えば、ＩＳＤＮ、パケット
網）を介して相互接続するインタネットが普及してい
る。今後、更なる普及が予想され、複数のネットワーク
間を相互接続する範囲は、企業内から企業間、業界内か
ら業界間、国内から国外へと拡大している。
【０００３】図１は、ＬＡＮ間をＤＤＸ網で接続した一
例のブロック図である。この図１において、ネットワー
クＮ１０、Ｎ１２は、それぞれイーサネットであり、ネ
ットワークＮ１１は、ＤＤＸ網（パケット網）である。
例のブロック図である。この図１において、ネットワー
クＮ１０、Ｎ１２は、それぞれイーサネットであり、ネ
ットワークＮ１１は、ＤＤＸ網（パケット網）である。
【０００４】前記ネットワークＮ１０、Ｎ１２には、そ
れぞれ３台のエンドシステム２０a、２０b が接続され
ている。これらエンドシステム２０a 、２０b は、それ
ぞれ独立した端末（コンピュータ）である。
れぞれ３台のエンドシステム２０a、２０b が接続され
ている。これらエンドシステム２０a 、２０b は、それ
ぞれ独立した端末（コンピュータ）である。
【０００５】前記ネットワークＮ１０とネットワークＮ
１１とは、ゲートウェイ３０a により接続され、ネット
ワークＮ１２とネットワークＮ１１とは、ゲートウェイ
３０b により接続され、ネットワークＮ１０、Ｎ１２間
は、ネットワークＮ１１で相互接続（インタネット）さ
れている。
１１とは、ゲートウェイ３０a により接続され、ネット
ワークＮ１２とネットワークＮ１１とは、ゲートウェイ
３０b により接続され、ネットワークＮ１０、Ｎ１２間
は、ネットワークＮ１１で相互接続（インタネット）さ
れている。
【０００６】ここで、ネットワークＮ１０、Ｎ１２は伝
送速度が１０ＭＢＰＳであり、ネットワークＮ１１の伝
送速度は２．４〜４８ＫＢＰＳである。即ち、ネットワ
ークＮ１０、Ｎ１２とネットワークＮ１１との伝送速度
差は、少なくとも２００倍以上である。
送速度が１０ＭＢＰＳであり、ネットワークＮ１１の伝
送速度は２．４〜４８ＫＢＰＳである。即ち、ネットワ
ークＮ１０、Ｎ１２とネットワークＮ１１との伝送速度
差は、少なくとも２００倍以上である。
【０００７】更に、ネットワークＮ１０、Ｎ１２とネッ
トワークＮ１１との間には、プロトコルの差異もある。
図１の例では、エンドシステムはＴＣＰ／ＩＰプロトコ
ル、ゲートウェイ３０a 、３０b 間はＸ．２５プロトコ
ルである。ここで、Ｘ．２５プロトコルのフロー制御
（データ受信可・不可制御）は、ＲＲ（Receive Read
y）、ＲＮＲ（Receive Not Ready ）パケットによって
行われる。つまり、ＲＮＲパケットを受信したゲートウ
ェイは、ＲＲパケットを受信するまで送信が禁止され
る。
トワークＮ１１との間には、プロトコルの差異もある。
図１の例では、エンドシステムはＴＣＰ／ＩＰプロトコ
ル、ゲートウェイ３０a 、３０b 間はＸ．２５プロトコ
ルである。ここで、Ｘ．２５プロトコルのフロー制御
（データ受信可・不可制御）は、ＲＲ（Receive Read
y）、ＲＮＲ（Receive Not Ready ）パケットによって
行われる。つまり、ＲＮＲパケットを受信したゲートウ
ェイは、ＲＲパケットを受信するまで送信が禁止され
る。
【０００８】なお、エンドシステム２０a 、２０b 間
は、例えば業界標準のＴＣＰ／ＩＰプロトコルで通信し
合う。このプロトコルは、図２で示すヘッダを有してい
る。このＴＣＰ／ＩＰプロトコルの特徴は、送信データ
の中に、ヘッダの内容（シークエンス（ＳＥＱ）番号、
確認（ＡＣＫ）番号、ウィンドウサイズ）でフロー制御
の役割を果たすことである。
は、例えば業界標準のＴＣＰ／ＩＰプロトコルで通信し
合う。このプロトコルは、図２で示すヘッダを有してい
る。このＴＣＰ／ＩＰプロトコルの特徴は、送信データ
の中に、ヘッダの内容（シークエンス（ＳＥＱ）番号、
確認（ＡＣＫ）番号、ウィンドウサイズ）でフロー制御
の役割を果たすことである。
【０００９】インタネットにおいて、エンドシステム２
０a 、２０b 間では、ネットワークＮ１０、Ｎ１２、Ｎ
１１が単一ネットワークであるように扱われ、エンドシ
ステム２０a 、２０b は、中継ネットワークＮ１１を意
識しない。よって、ネットワークＮ１１において、ゲー
トウェイ３０a 、３０b 間でフロー制御（受信不可）が
発生していても、エンドシステム２０a 、２０b は、そ
の状況を知ることができない。
０a 、２０b 間では、ネットワークＮ１０、Ｎ１２、Ｎ
１１が単一ネットワークであるように扱われ、エンドシ
ステム２０a 、２０b は、中継ネットワークＮ１１を意
識しない。よって、ネットワークＮ１１において、ゲー
トウェイ３０a 、３０b 間でフロー制御（受信不可）が
発生していても、エンドシステム２０a 、２０b は、そ
の状況を知ることができない。
【００１０】なお、エンドシステム２０a とゲートウェ
イ３０a の間は、イーサネットのプロトコルによってデ
ータが送受信される。その際のデータＤＴＡの構成（プ
ロトコル・スタック）は、図３に示すように、ＴＣＰ／
ＩＰプロトコル・ヘッダを、イーサネット（ＬＡＮ）ヘ
ッダで包んでカプセル化した形を有する。つまり、送信
元エンドシステム２０a は、イーサネット・プロトコル
で、ゲートウェイ３０a と正常にデータ送信が完了した
ことを確認できても、ＴＣＰ／ＩＰプロトコルレベルで
は、正確に宛先エンドシステム２０b にデータが伝送さ
れたか否かは、宛先エンドシステム２０b からの応答を
待つしかない。
イ３０a の間は、イーサネットのプロトコルによってデ
ータが送受信される。その際のデータＤＴＡの構成（プ
ロトコル・スタック）は、図３に示すように、ＴＣＰ／
ＩＰプロトコル・ヘッダを、イーサネット（ＬＡＮ）ヘ
ッダで包んでカプセル化した形を有する。つまり、送信
元エンドシステム２０a は、イーサネット・プロトコル
で、ゲートウェイ３０a と正常にデータ送信が完了した
ことを確認できても、ＴＣＰ／ＩＰプロトコルレベルで
は、正確に宛先エンドシステム２０b にデータが伝送さ
れたか否かは、宛先エンドシステム２０b からの応答を
待つしかない。
【００１１】なお、ゲートウェイ３０a 、３０b 間の
Ｘ．２５プロトコルは、例えば１２８バイト、２５６バ
イト、１０２４バイト長のパケット単位でデータを送受
信する。その結果、送信元２０a からゲートウェイ３０
a へ送信されたデータＤＴＡは、図４で示すように、い
くつかのパケットＤＴ（１）、ＤＴ（２）、ＤＴ（３）
に分割されてゲートウェイ３０b へ送信され、分割受信
したゲートウェイ３０bは、図５に示す如く、パケット
を再度組み立て、図３の形式に戻してから、宛先エンド
システム２０b へ送信する。
Ｘ．２５プロトコルは、例えば１２８バイト、２５６バ
イト、１０２４バイト長のパケット単位でデータを送受
信する。その結果、送信元２０a からゲートウェイ３０
a へ送信されたデータＤＴＡは、図４で示すように、い
くつかのパケットＤＴ（１）、ＤＴ（２）、ＤＴ（３）
に分割されてゲートウェイ３０b へ送信され、分割受信
したゲートウェイ３０bは、図５に示す如く、パケット
を再度組み立て、図３の形式に戻してから、宛先エンド
システム２０b へ送信する。
【００１２】
【発明が解決しようとする課題】伝送速度差があり、プ
ロトコルの異なるネットワーク間を相互接続するインタ
ネットにおいては、通常、ゲートウェイ３０a 、３０b
等に通信用バッファを設け、データを蓄積交換すること
で、伝送速度差やプロトコルの違いによる問題を、ある
程度解決できるが、やはり、ゲートウェイの能力オーバ
ーフロー（バッファ不足、処理能力不足）が発生し、フ
ロー制御（受信不可）になる状況がある。そのフロー制
御時間（受信不可から受信可に回復するまでの時間）に
よっては、エンドシステム２０a 、２０b 間で、タイム
アウトによる再送条件が成立する。その結果、図５に示
す如く、送信元エンドシステム２０a は、データＤＴＡ
を再送する。
ロトコルの異なるネットワーク間を相互接続するインタ
ネットにおいては、通常、ゲートウェイ３０a 、３０b
等に通信用バッファを設け、データを蓄積交換すること
で、伝送速度差やプロトコルの違いによる問題を、ある
程度解決できるが、やはり、ゲートウェイの能力オーバ
ーフロー（バッファ不足、処理能力不足）が発生し、フ
ロー制御（受信不可）になる状況がある。そのフロー制
御時間（受信不可から受信可に回復するまでの時間）に
よっては、エンドシステム２０a 、２０b 間で、タイム
アウトによる再送条件が成立する。その結果、図５に示
す如く、送信元エンドシステム２０a は、データＤＴＡ
を再送する。
【００１３】すると、ゲートウェイ３０a は、再送され
たデータをそのまま受信し、ネットワークＮ１１へ送出
するためのバッファへキューイングし（待ち行列上に並
べ）、フロー制御（受信不可）が回復（ＲＲ）するのを
待つ。
たデータをそのまま受信し、ネットワークＮ１１へ送出
するためのバッファへキューイングし（待ち行列上に並
べ）、フロー制御（受信不可）が回復（ＲＲ）するのを
待つ。
【００１４】従って、ゲートウェイでは、余分なバッフ
ァ（再送データ分の格納）領域が消費されると共に、フ
ロー制御回復（受信可）状況を待って余分なデータがネ
ットワークＮ１１上へ転出され、宛先エンドシステム２
０b は、重複したデータＤＴＡを受信することになり、
全体的な伝送効率が低下すると共に、余分なデータ転送
（再送データ）に伴う課金が発生する等の問題点を有す
る。
ァ（再送データ分の格納）領域が消費されると共に、フ
ロー制御回復（受信可）状況を待って余分なデータがネ
ットワークＮ１１上へ転出され、宛先エンドシステム２
０b は、重複したデータＤＴＡを受信することになり、
全体的な伝送効率が低下すると共に、余分なデータ転送
（再送データ）に伴う課金が発生する等の問題点を有す
る。
【００１５】本発明は、このような余分なデータ格納の
ためのバッファを使用せず、伝送効率の低下や、余分な
課金を防ぐことができるゲートウェイを提供することを
目的とする。
ためのバッファを使用せず、伝送効率の低下や、余分な
課金を防ぐことができるゲートウェイを提供することを
目的とする。
【００１６】
【課題を解決するための手段】本発明は、伝送速度差が
あり、プロトコルの異なるネットワーク間を相互接続
（インタネット）するゲートウェイにおいて、図６に示
す如く、送受信データを格納するための通信用バッファ
１０と、送信元から受信したデータの送出チャネルが、
フロー制御により送信不可状態になっているか否か判断
するフロー制御判定手段１１と、送信元からの再送デー
タを検出する手段１２と、前記フロー制御中に再送デー
タを受信した場合は、前記通信用バッファ１０上から再
送データを破棄する手段１３とを備え、ネットワークへ
の無駄なデータの送出を防ぐことにより、前記課題を解
決したものである。
あり、プロトコルの異なるネットワーク間を相互接続
（インタネット）するゲートウェイにおいて、図６に示
す如く、送受信データを格納するための通信用バッファ
１０と、送信元から受信したデータの送出チャネルが、
フロー制御により送信不可状態になっているか否か判断
するフロー制御判定手段１１と、送信元からの再送デー
タを検出する手段１２と、前記フロー制御中に再送デー
タを受信した場合は、前記通信用バッファ１０上から再
送データを破棄する手段１３とを備え、ネットワークへ
の無駄なデータの送出を防ぐことにより、前記課題を解
決したものである。
【００１７】
【作用】本発明は、プロトコルにはデータにヘッダが付
されていて、ヘッダでデータの同一性が識別できる点に
着目してなされたものである。このようなプロトコルと
して、業界標準となっているＴＣＰ／ＩＰがある。この
プロトコルでは、ＩＰヘッダによってデータの送信元、
宛先エンドシステムが識別され、当該論理チャネルがフ
ロー制御（受信不可）状態になっているか否かが分か
る。更に、ＴＣＰヘッダのシーケンス番号、ＡＣＫ番
号、ＩＰヘッダのデータ長によって、再送データか否か
識別できる。
されていて、ヘッダでデータの同一性が識別できる点に
着目してなされたものである。このようなプロトコルと
して、業界標準となっているＴＣＰ／ＩＰがある。この
プロトコルでは、ＩＰヘッダによってデータの送信元、
宛先エンドシステムが識別され、当該論理チャネルがフ
ロー制御（受信不可）状態になっているか否かが分か
る。更に、ＴＣＰヘッダのシーケンス番号、ＡＣＫ番
号、ＩＰヘッダのデータ長によって、再送データか否か
識別できる。
【００１８】本発明において、通信用バッファ１０は、
送信元からのデータを格納する。次いで、通信用バッフ
ァ１０から取り出したデータのＩＰヘッダから、送信
元、宛先エンドシステムを取り出し、送り出すべきチャ
ネルが、フロー制御により送信不可状態になっているか
否かをフロー制御判定手段１１で判断する。フロー制御
による送信不可チャネルを使用するデータで、送信不可
と判明した場合、再送データ検出手段１２によって、Ｔ
ＣＰヘッダのシーケンス番号、ＡＣＫ番号、ＩＰヘッダ
のデータ長の値が、既に格納されているデータ（送信元
から最も最近受信したデータ）の値と同一か否か判断す
る。同一、即ち再送データと判断された場合、再送デー
タ破棄手段１３によって、そのデータを破棄し、通信用
バッファ１０を空き状態に戻す。
送信元からのデータを格納する。次いで、通信用バッフ
ァ１０から取り出したデータのＩＰヘッダから、送信
元、宛先エンドシステムを取り出し、送り出すべきチャ
ネルが、フロー制御により送信不可状態になっているか
否かをフロー制御判定手段１１で判断する。フロー制御
による送信不可チャネルを使用するデータで、送信不可
と判明した場合、再送データ検出手段１２によって、Ｔ
ＣＰヘッダのシーケンス番号、ＡＣＫ番号、ＩＰヘッダ
のデータ長の値が、既に格納されているデータ（送信元
から最も最近受信したデータ）の値と同一か否か判断す
る。同一、即ち再送データと判断された場合、再送デー
タ破棄手段１３によって、そのデータを破棄し、通信用
バッファ１０を空き状態に戻す。
【００１９】従って、本発明によれば、フロー制御（送
信不可）のため送信元でタイムアウトを検出し、再送さ
れた同一データを、ネットワークに送出することがな
く、即ち、宛先エンドシステムで重複受信することがな
く、ネットワークでの課金を防ぐことができる。
信不可）のため送信元でタイムアウトを検出し、再送さ
れた同一データを、ネットワークに送出することがな
く、即ち、宛先エンドシステムで重複受信することがな
く、ネットワークでの課金を防ぐことができる。
【００２０】本発明を適用した場合の、図５に対応する
データの流れは図７の通りである。
データの流れは図７の通りである。
【００２１】
【実施例】以下、ＬＡＮとＤＤＸ網（Ｘ．２５パケット
網）を相互接続するゲートウェイを例にとって、本発明
の第１実施例を詳細に説明する。
網）を相互接続するゲートウェイを例にとって、本発明
の第１実施例を詳細に説明する。
【００２２】図８において、ＬＡＮ制御の通信制御部５
０は、図７で示すデータＤＴＡを受信し、通信用バッフ
ァ２０に格納する。
０は、図７で示すデータＤＴＡを受信し、通信用バッフ
ァ２０に格納する。
【００２３】中継制御部６０は、通信用バッファ２０か
ら、格納されているデータＤＴＡを取り出し、ＩＰヘッ
ダから宛先アドレスを抽出し、送り出すべき論理チャネ
ルを捜す。論理チャネルが確立されていない場合は、論
理チャネルを確立し、通常の処理をする。
ら、格納されているデータＤＴＡを取り出し、ＩＰヘッ
ダから宛先アドレスを抽出し、送り出すべき論理チャネ
ルを捜す。論理チャネルが確立されていない場合は、論
理チャネルを確立し、通常の処理をする。
【００２４】既に確立されている場合、中継網フロー制
御部２１は、その論理チャネル上でフロー制御（受信不
可）状態が発生しているか否か調べる。フロー制御（受
信不可）状態であると、再送データ検出部２２は、現
在、フロー制御（受信不可）の対象となっている（パケ
ット化して送信中、あるいは送信されようとしてバッフ
ァにキューイングされている）データのＩＰヘッダの送
信、宛先アドレス、データ長、ＴＣＰヘッダのシーケン
ス番号、ＡＣＫ番号が、ＤＴＡのそれと同一か否か調べ
る。
御部２１は、その論理チャネル上でフロー制御（受信不
可）状態が発生しているか否か調べる。フロー制御（受
信不可）状態であると、再送データ検出部２２は、現
在、フロー制御（受信不可）の対象となっている（パケ
ット化して送信中、あるいは送信されようとしてバッフ
ァにキューイングされている）データのＩＰヘッダの送
信、宛先アドレス、データ長、ＴＣＰヘッダのシーケン
ス番号、ＡＣＫ番号が、ＤＴＡのそれと同一か否か調べ
る。
【００２５】同一であれば、再送データ破棄部２３は、
今回のデータＤＴＡを破棄し、通信用バッファ２０から
消去する。その過程は、図７のデータフローの通りであ
る。
今回のデータＤＴＡを破棄し、通信用バッファ２０から
消去する。その過程は、図７のデータフローの通りであ
る。
【００２６】本発明は、この第１実施例に示すプロトコ
ルばかりでなく、ヘッダをカプセル化して伝送するイン
タネット一般に適用できるものである。
ルばかりでなく、ヘッダをカプセル化して伝送するイン
タネット一般に適用できるものである。
【００２７】次に、前記の基本的なゲートウェイへの実
施例を、ネットワーク管理モデルへ適用した、本発明の
第２実施例について説明する。
施例を、ネットワーク管理モデルへ適用した、本発明の
第２実施例について説明する。
【００２８】現在、標準化のネットワーク管理モデル
は、図９で示すように、マネージャ４０がエージェント
（管理対象）４２に問いかけ、エージェント４２が応答
する形態である。更に、エージェント４２は、自らマネ
ージャ４０に報告する（ＴＲＡＰ）機能がある。
は、図９で示すように、マネージャ４０がエージェント
（管理対象）４２に問いかけ、エージェント４２が応答
する形態である。更に、エージェント４２は、自らマネ
ージャ４０に報告する（ＴＲＡＰ）機能がある。
【００２９】これを前記の例に適用すると、マネージャ
４０がエンドシステム２０a 、エージェント４２がエン
ドシステム２０b に相当する。そこで、マネージャ４０
がエージェント４２に問いかけ（ポーリングし）、その
ポーリング・データがフロー制御（受信不可）の対象に
なると、ポーリング・データのタイムアウトとして、ポ
ーリングが再送される状況が考えられる。ポーリング・
データのタイムアウトを、マネージャ４０は、エージェ
ント４２の無応答とみなし、エージェント４２が非活性
状況にあると判断する。なお、システムによっては、ポ
ーリングの再送を繰り返すこともある。
４０がエンドシステム２０a 、エージェント４２がエン
ドシステム２０b に相当する。そこで、マネージャ４０
がエージェント４２に問いかけ（ポーリングし）、その
ポーリング・データがフロー制御（受信不可）の対象に
なると、ポーリング・データのタイムアウトとして、ポ
ーリングが再送される状況が考えられる。ポーリング・
データのタイムアウトを、マネージャ４０は、エージェ
ント４２の無応答とみなし、エージェント４２が非活性
状況にあると判断する。なお、システムによっては、ポ
ーリングの再送を繰り返すこともある。
【００３０】そこで、ゲートウェイ３０a に、図１０に
示す如く、図８で示した機能に、更に、ポーリング・デ
ータか否かを判断するポーリング・データ検出部８０
と、ポーリングのタイムアウトを計測するポーリング・
タイムアウト計測部８２と、エージェント４２の代理機
能として、マネージャ４０に応答するエージェント代理
機能部８４を追加する。
示す如く、図８で示した機能に、更に、ポーリング・デ
ータか否かを判断するポーリング・データ検出部８０
と、ポーリングのタイムアウトを計測するポーリング・
タイムアウト計測部８２と、エージェント４２の代理機
能として、マネージャ４０に応答するエージェント代理
機能部８４を追加する。
【００３１】以下、第２実施例の作用を説明する。
【００３２】前記中継網フロー制御部２１は、第１実施
例と同様に、エンドシステム２０aから受信したデータ
ＤＴＡを送出すべき論理チャネルが、フロー制御（受信
不可）であるか否か判断する。フロー制御（受信不可）
状態であると、ポーリング・データ検出部８０は、その
データが、ネットワークＮ１２上のエンドシステム２０
b （エージェント）へのポーリング・データであるか否
か調べる。ポーリング・データと判明すると、ポーリン
グ・タイムアウト計測部８２は、タイムアウト検出用の
タイマを設定する。タイムがある一定の時間（タイムア
ウト直前）になっても、フロー制御（受信不可）が回復
しないと、エージェント代理機能部８４は、エージェン
ト４２の代わりに、フロー制御（受信不可）のためポー
リング・データをエージェント４２に送出できないこと
を、前記ＴＲＡＰとしてマネージャ４０に報告する。
例と同様に、エンドシステム２０aから受信したデータ
ＤＴＡを送出すべき論理チャネルが、フロー制御（受信
不可）であるか否か判断する。フロー制御（受信不可）
状態であると、ポーリング・データ検出部８０は、その
データが、ネットワークＮ１２上のエンドシステム２０
b （エージェント）へのポーリング・データであるか否
か調べる。ポーリング・データと判明すると、ポーリン
グ・タイムアウト計測部８２は、タイムアウト検出用の
タイマを設定する。タイムがある一定の時間（タイムア
ウト直前）になっても、フロー制御（受信不可）が回復
しないと、エージェント代理機能部８４は、エージェン
ト４２の代わりに、フロー制御（受信不可）のためポー
リング・データをエージェント４２に送出できないこと
を、前記ＴＲＡＰとしてマネージャ４０に報告する。
【００３３】
【発明の効果】以上説明したように、本発明によれば、
フロー制御によって送信が一時中止されている状況下
で、再送データを受信し、同一データを宛先エンドシス
テムに送信することを防ぐと共に、余分な課金を低減す
ることが可能になるという優れた効果を有する。
フロー制御によって送信が一時中止されている状況下
で、再送データを受信し、同一データを宛先エンドシス
テムに送信することを防ぐと共に、余分な課金を低減す
ることが可能になるという優れた効果を有する。
【図１】本発明が適用されるネットワークの例を示す線
図
図
【図２】業界標準のＴＣＰ／ＩＰプロトコルで用いられ
ているＴＣＰ／ＩＰヘッダの構成を示す線図
ているＴＣＰ／ＩＰヘッダの構成を示す線図
【図３】イーサネット・プロトコルで送受信されるデー
タの構成（プロトコル・スタック）を示す線図
タの構成（プロトコル・スタック）を示す線図
【図４】Ｘ．２５プロトコルにより、パケット単位で送
受信されるデータの構成例を示す線図
受信されるデータの構成例を示す線図
【図５】従来例におけるデータの流れを示す線図
【図６】本発明の要旨構成を示す線図
【図７】本発明によるデータの流れの例を示す線図
【図８】本発明の第１実施例の構成を示すブロック線図
【図９】本発明の第２実施例が適用されるネットワーク
・モデルを示す線図
・モデルを示す線図
【図１０】第２実施例の構成を示すブロック線図
Ｎ１０、Ｎ１１、Ｎ１２…ネットワーク １０、２０…通信用バッファ １１…フロー制御判定手段 １２…再送データ検出手段 １３…再送データ破棄手段 ２０a 、２０b …エンドシステム ２１…中継網フロー制御部 ２２…再送データ検出部 ２３…再送データ破棄部 ３０a 、３０b …ゲートウェイ ４０…マネージャ ４２…エージェント
Claims (1)
- 【請求項１】伝送速度差があり、プロトコルの異なるネ
ットワーク間を相互接続するゲートウェイにおいて、 送受信データを格納するための通信用バッファと、 送信元から受信したデータの送出チャネルが、フロー制
御により送信不可状態になっているか否か判断するフロ
ー制御判定手段と、 送信元からの再送データを検出する手段と、 前記フロー制御中に再送データを受信した場合は、前記
通信用バッファ上から再送データを破棄する手段とを備
え、 ネットワークへの無駄なデータの送出を防ぐことを特徴
とするゲートウェイ。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP5157763A JPH0738612A (ja) | 1993-06-29 | 1993-06-29 | ゲートウェイ |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP5157763A JPH0738612A (ja) | 1993-06-29 | 1993-06-29 | ゲートウェイ |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH0738612A true JPH0738612A (ja) | 1995-02-07 |
Family
ID=15656787
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP5157763A Pending JPH0738612A (ja) | 1993-06-29 | 1993-06-29 | ゲートウェイ |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH0738612A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6954797B1 (en) | 1999-02-26 | 2005-10-11 | Nec Corporation | Data Communication method, terminal equipment, interconnecting installation, data communication system and recording medium |
| KR100845821B1 (ko) * | 2005-09-29 | 2008-07-14 | 이노베이티브 소닉 리미티드 | 무선통신시스템에서 저장소 윈도우를 시작하기 위한 방법및 장치 |
| US7529184B2 (en) | 2004-12-01 | 2009-05-05 | Research In Motion Limited | Flow control buffering |
-
1993
- 1993-06-29 JP JP5157763A patent/JPH0738612A/ja active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6954797B1 (en) | 1999-02-26 | 2005-10-11 | Nec Corporation | Data Communication method, terminal equipment, interconnecting installation, data communication system and recording medium |
| US7529184B2 (en) | 2004-12-01 | 2009-05-05 | Research In Motion Limited | Flow control buffering |
| US8509065B2 (en) | 2004-12-01 | 2013-08-13 | Research In Motion Limited | Flow control buffering |
| KR100845821B1 (ko) * | 2005-09-29 | 2008-07-14 | 이노베이티브 소닉 리미티드 | 무선통신시스템에서 저장소 윈도우를 시작하기 위한 방법및 장치 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6741555B1 (en) | Enhancement of explicit congestion notification (ECN) for wireless network applications | |
| US6954797B1 (en) | Data Communication method, terminal equipment, interconnecting installation, data communication system and recording medium | |
| US7369498B1 (en) | Congestion control method for a packet-switched network | |
| US6757248B1 (en) | Performance enhancement of transmission control protocol (TCP) for wireless network applications | |
| Bux et al. | Flow control in local-area networks of interconnected token rings | |
| US7443845B2 (en) | Apparatus and method for a lightweight, reliable, packet-based transport protocol | |
| Nagle | Congestion control in IP/TCP internetworks | |
| US20030135640A1 (en) | Method and system for group transmission and acknowledgment | |
| JPH10262054A (ja) | Ａｔｍ網における端末間フロー制御方法 | |
| US7110418B2 (en) | Method to ensure the quality of preferred communication services, a local network, a station, a local network controller and a program module therefor | |
| US6947435B1 (en) | Radio communication system and apparatus, communication method and program recording medium therefor | |
| JP3032419B2 (ja) | データ転送方法 | |
| JPH0738612A (ja) | ゲートウェイ | |
| EP1505759B1 (en) | Method and device for transmitting/receiving data using acknowledged transport layer protocols | |
| CA2372023A1 (en) | Overload control method for a packet-switched network | |
| Cisco | LLC2 and SDLC Commands | |
| Cisco | LLC2 and SDLC Commands | |
| Cisco | LLC2 and SDLC Commands | |
| Cisco | LLC2 and SDLC Commands | |
| Cisco | LLC2 and SDLC Commands | |
| Cisco | LLC2 and SDLC Commands | |
| Cisco | LLC2 and SDLC Commands | |
| Cisco | LLC2 and SDLC Commands | |
| Clark et al. | RFC0998: NETBLT: A bulk data transfer protocol | |
| JPH0385041A (ja) | Ｃｓｍａ／ｃｄ方式用ブリッジ |