JPH07250100A - 広域網を用いたｌａｎ間の相互通信方式及びこれに用いる相互接続装置 - Google Patents
広域網を用いたｌａｎ間の相互通信方式及びこれに用いる相互接続装置Info
- Publication number
- JPH07250100A JPH07250100A JP6038738A JP3873894A JPH07250100A JP H07250100 A JPH07250100 A JP H07250100A JP 6038738 A JP6038738 A JP 6038738A JP 3873894 A JP3873894 A JP 3873894A JP H07250100 A JPH07250100 A JP H07250100A
- Authority
- JP
- Japan
- Prior art keywords
- area network
- wide area
- interconnection device
- protocol
- lan
- 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
- Small-Scale Networks (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
(57)【要約】
【目的】 広域網を介して複数のＬＡＮを接続する場合
において、系統全体のスループットを良好に保持し得る
ＬＡＮ間の相互接続方式を提供する。 【構成】 送信側及び受信側の相互接続装置においてＬ
ＡＮ側のプロトコルのトランスポート層のフロー制御を
実現することにより、このトランスポート層までを終端
して、送信側のＬＡＮと送信側の相互接続装置、送信側
の相互接続装置と受信側の相互接続装置及び受信側の相
互接続装置と受信側のＬＡＮとの間で、それぞれ独立に
データのフロー制御を行なうようにしたものである。
において、系統全体のスループットを良好に保持し得る
ＬＡＮ間の相互接続方式を提供する。 【構成】 送信側及び受信側の相互接続装置においてＬ
ＡＮ側のプロトコルのトランスポート層のフロー制御を
実現することにより、このトランスポート層までを終端
して、送信側のＬＡＮと送信側の相互接続装置、送信側
の相互接続装置と受信側の相互接続装置及び受信側の相
互接続装置と受信側のＬＡＮとの間で、それぞれ独立に
データのフロー制御を行なうようにしたものである。
Description
【０００１】
【産業上の利用分野】本発明は広域網を用いたＬＡＮ間
の相互通信方式及びこれに用いる相互接続装置に関し、
特に伝送遅延の大きな広域網を介して複数のＬＡＮを接
続する場合に適用して有用なものである。
の相互通信方式及びこれに用いる相互接続装置に関し、
特に伝送遅延の大きな広域網を介して複数のＬＡＮを接
続する場合に適用して有用なものである。
【０００２】
【従来の技術】図６に示すように、地理的に離れた複数
のＬＡＮ（Local Area Network）１，２を相互に接続し
てデータ通信を行う場合、相互接続装置３，４を設置
し、電話網、パケット交換公衆データ網、サービス総合
ディジタル網、あるいは専用線といった広域網５を経由
して接続することが一般的に行なわれている。
のＬＡＮ（Local Area Network）１，２を相互に接続し
てデータ通信を行う場合、相互接続装置３，４を設置
し、電話網、パケット交換公衆データ網、サービス総合
ディジタル網、あるいは専用線といった広域網５を経由
して接続することが一般的に行なわれている。
【０００３】従来技術に係るこの種のネットワークにお
ける相互接続装置３，４ではＬＡＮ１，２内で使用され
るプロトコルと広域網４で使用されるプロトコルとの間
のプロトコル変換を行なうことにより、ＬＡＮ１，２の
相互接続を実現する。
ける相互接続装置３，４ではＬＡＮ１，２内で使用され
るプロトコルと広域網４で使用されるプロトコルとの間
のプロトコル変換を行なうことにより、ＬＡＮ１，２の
相互接続を実現する。
【０００４】現在、この種の相互接続装置３，４として
広く使用されているものは、ルータと呼ばれ、図７のＯ
ＳＩ参照モデルに示すように、このモデルにおける物理
層からネットワーク層までのプロトコル変換を実現して
いる。
広く使用されているものは、ルータと呼ばれ、図７のＯ
ＳＩ参照モデルに示すように、このモデルにおける物理
層からネットワーク層までのプロトコル変換を実現して
いる。
【０００５】かかる相互接続装置３，４を用いて、ＬＡ
Ｎ１，２の相互接続を行なった場合、ＬＡＮ１，２に接
続された計算機１ａ，２ａにおけるトランスポート層か
ら応用層までのプロトコルの手順については、計算機１
ａ，２ａ間で直接やりとりされ、相互接続装置３，４は
全く関与しない。
Ｎ１，２の相互接続を行なった場合、ＬＡＮ１，２に接
続された計算機１ａ，２ａにおけるトランスポート層か
ら応用層までのプロトコルの手順については、計算機１
ａ，２ａ間で直接やりとりされ、相互接続装置３，４は
全く関与しない。
【０００６】また、ファイル転送など、大量データの信
頼性の高い転送を実現するためには、受信能力に応じた
割合でデータを送信させるためのフロー制御や、送信し
たデータの受信確認、伝送誤りが生じたデータの再送な
どを行なう誤り制御をサポートする必要がある。
頼性の高い転送を実現するためには、受信能力に応じた
割合でデータを送信させるためのフロー制御や、送信し
たデータの受信確認、伝送誤りが生じたデータの再送な
どを行なう誤り制御をサポートする必要がある。
【０００７】ＬＡＮ１，２においては、ネットワーク層
以下のプロトコルは、フロー制御や誤り制御を行なわな
いコネクションレス型のプロトコルを用い、トランスポ
ート層において、コネクションを用い、コネクション上
を流れるデータに対して、フロー制御や誤り制御を行な
うプロトコルを使用するのが一般的である。例えば、Ｌ
ＡＮ１，２のプロトコルとして現在広く普及しているＴ
ＣＰ／ＩＰ（Transmission Control Protocol （以下、
ＴＣＰと略称する）/ Internet Protocol （以下、ＩＰ
と略称する））においても、ネットワーク層のＩＰまで
のプロトコルは、コネクションレス型で、トランスポー
ト層のＴＣＰにおいて、フロー制御の機能がサポートさ
れている。
以下のプロトコルは、フロー制御や誤り制御を行なわな
いコネクションレス型のプロトコルを用い、トランスポ
ート層において、コネクションを用い、コネクション上
を流れるデータに対して、フロー制御や誤り制御を行な
うプロトコルを使用するのが一般的である。例えば、Ｌ
ＡＮ１，２のプロトコルとして現在広く普及しているＴ
ＣＰ／ＩＰ（Transmission Control Protocol （以下、
ＴＣＰと略称する）/ Internet Protocol （以下、ＩＰ
と略称する））においても、ネットワーク層のＩＰまで
のプロトコルは、コネクションレス型で、トランスポー
ト層のＴＣＰにおいて、フロー制御の機能がサポートさ
れている。
【０００８】このようなプロトコルを用いたＬＡＮ１，
２を、従来の相互接続装置３，４で、広域網５を介して
相互接続した場合、フロー制御は計算機１ａ，２ａ間で
行なわれることになる。
２を、従来の相互接続装置３，４で、広域網５を介して
相互接続した場合、フロー制御は計算機１ａ，２ａ間で
行なわれることになる。
【０００９】一方、フロー制御を実現するためには、従
来より、ウインドウに基づくフロー制御方式が広く用い
られている。この方式では、確実なデータ転送を実現す
るために、送信側から送信されたデータに対して受信側
が確認応答パケットを用いて、データパケットを正しく
受信したことを通知する。更に、データ転送の効率を高
めるために、送信側は複数のデータパケットを確認応答
パケットを待つことなく連続的に送信することが許され
ている。この連続的に送信することのできるデータパケ
ットの数は、ウインドウサイズと呼ばれている。
来より、ウインドウに基づくフロー制御方式が広く用い
られている。この方式では、確実なデータ転送を実現す
るために、送信側から送信されたデータに対して受信側
が確認応答パケットを用いて、データパケットを正しく
受信したことを通知する。更に、データ転送の効率を高
めるために、送信側は複数のデータパケットを確認応答
パケットを待つことなく連続的に送信することが許され
ている。この連続的に送信することのできるデータパケ
ットの数は、ウインドウサイズと呼ばれている。
【００１０】このようなウインドウに基づくフロー制御
方式を用いた場合、伝送路の伝送速度に見あったスルー
プットでデータを転送するためには、次のようにしてウ
インドウサイズの大きさを決定する必要がある。すなわ
ち、送信側がデータパケットを送信し、そのデータパケ
ットに対する確認応答のためのパケットを受信するまで
の時間は、受信側での処理時間を無視すると伝送路の往
復の遅延時間となる。そこで、データパケットの大きさ
とウインドウサイズの積を、往復の伝送遅延時間と伝送
路の伝送速度の積よりも大きな値に設定することによ
り、伝送誤りが発生しないことを条件として送信側が連
続的にデータパケットを送信することができる。
方式を用いた場合、伝送路の伝送速度に見あったスルー
プットでデータを転送するためには、次のようにしてウ
インドウサイズの大きさを決定する必要がある。すなわ
ち、送信側がデータパケットを送信し、そのデータパケ
ットに対する確認応答のためのパケットを受信するまで
の時間は、受信側での処理時間を無視すると伝送路の往
復の遅延時間となる。そこで、データパケットの大きさ
とウインドウサイズの積を、往復の伝送遅延時間と伝送
路の伝送速度の積よりも大きな値に設定することによ
り、伝送誤りが発生しないことを条件として送信側が連
続的にデータパケットを送信することができる。
【００１１】
【発明が解決しようとする課題】ところが、上述の如く
相互接続装置３，４において物理層からネットワーク層
までのプロトコル変換を行なう方法では、広域網５の伝
送遅延の影響により充分な通信速度が得られないという
問題点があった。
相互接続装置３，４において物理層からネットワーク層
までのプロトコル変換を行なう方法では、広域網５の伝
送遅延の影響により充分な通信速度が得られないという
問題点があった。
【００１２】さらに詳言すると、従来のＬＡＮ１，２で
使用されるプロトコルでは、一般的に、トランスポート
層においてウインドウに基づくフロー制御が行われ、ウ
インドウサイズ等のパラメータについては伝送遅延が小
さい同一ＬＡＮ１，２内の通信に最適化されたものが設
定されており、これがそのまま広域網５上においても使
用される。このため、往復の伝送遅延と伝送速度の積に
比較してデータパケットの大きさとウインドウサイズの
積が小さくなり、送信側応用プロセスにおいて確認応答
待ちが発生する。
使用されるプロトコルでは、一般的に、トランスポート
層においてウインドウに基づくフロー制御が行われ、ウ
インドウサイズ等のパラメータについては伝送遅延が小
さい同一ＬＡＮ１，２内の通信に最適化されたものが設
定されており、これがそのまま広域網５上においても使
用される。このため、往復の伝送遅延と伝送速度の積に
比較してデータパケットの大きさとウインドウサイズの
積が小さくなり、送信側応用プロセスにおいて確認応答
待ちが発生する。
【００１３】図８は、この問題点を示す図であり、ウイ
ンドウサイズを３と仮定した場合のデータパケットと確
認応答パケットのシーケンスを示している。同図に示す
ように、受信側からの確認応答待ちのため大きな無駄な
時間が生じており、広域網５の伝送遅延のために、確認
応答パケットの受信待ちの状態が生じた場合は、データ
転送のスループットは、 （データパケットの大きさ×ウインドウサイズ）／（往
復の伝送遅延） となり、伝送路の伝送速度によらず一定となる。
ンドウサイズを３と仮定した場合のデータパケットと確
認応答パケットのシーケンスを示している。同図に示す
ように、受信側からの確認応答待ちのため大きな無駄な
時間が生じており、広域網５の伝送遅延のために、確認
応答パケットの受信待ちの状態が生じた場合は、データ
転送のスループットは、 （データパケットの大きさ×ウインドウサイズ）／（往
復の伝送遅延） となり、伝送路の伝送速度によらず一定となる。
【００１４】ＴＣＰでは、送受信用のバッファメモリ、
即ち上記の式における（データパケットの大きさ×ウイ
ンドウサイズ）の値として、通常４キロバイト、大量デ
ータ転送のためのオプションを指定しても２４キロバイ
トしか準備しないのが一般的である。また、データパケ
ットの大きさは約１５００バイトであり、ウインドウサ
イズは２〜１６の値になる。
即ち上記の式における（データパケットの大きさ×ウイ
ンドウサイズ）の値として、通常４キロバイト、大量デ
ータ転送のためのオプションを指定しても２４キロバイ
トしか準備しないのが一般的である。また、データパケ
ットの大きさは約１５００バイトであり、ウインドウサ
イズは２〜１６の値になる。
【００１５】例として、往復の伝送遅延が１５０msecの
伝送路を使用してＬＡＮ１，２間を相互接続する場合を
考えると、従来の相互接続方式を用いた場合のスループ
ットは、約２１３Ｋbit/s 〜１．２５Ｍbit/s となる。
これは、例えばＬＡＮ１，２間の接続のために、２Ｍbi
t/s の回線を用意しても、その特性を充分発揮できず低
いスループットでしかデータ通信ができないことにな
る。
伝送路を使用してＬＡＮ１，２間を相互接続する場合を
考えると、従来の相互接続方式を用いた場合のスループ
ットは、約２１３Ｋbit/s 〜１．２５Ｍbit/s となる。
これは、例えばＬＡＮ１，２間の接続のために、２Ｍbi
t/s の回線を用意しても、その特性を充分発揮できず低
いスループットでしかデータ通信ができないことにな
る。
【００１６】このような問題点は、今後広域網５が更に
高速化され、４５Ｍbit/s や１５６Ｍbit/s の伝送速度
が提供されるに伴なってより顕著な問題となる。
高速化され、４５Ｍbit/s や１５６Ｍbit/s の伝送速度
が提供されるに伴なってより顕著な問題となる。
【００１７】本発明は、上記従来技術に鑑み、広域網を
介して複数のＬＡＮを接続する場合において、全体のス
ループットを良好に保持し得るＬＡＮ間の相互接続方式
及びその相互接続装置を提供することを目的とする。
介して複数のＬＡＮを接続する場合において、全体のス
ループットを良好に保持し得るＬＡＮ間の相互接続方式
及びその相互接続装置を提供することを目的とする。
【００１８】
【課題を解決するための手段】上記目的を達成する第１
の発明の構成は、複数のＬＡＮを相互接続装置及び広域
網を介して接続することによりＬＡＮ間の通信を実現し
た広域網を用いたＬＡＮ間の相互通信方式において、送
信側のＬＡＮと送信側の相互接続装置、送信側の相互接
続装置と受信側の相互接続装置及び受信側の相互接続装
置と受信側のＬＡＮの間でそれぞれ独立にデータのフロ
ー制御を行なって、独立に、データの受信を表わす確認
応答を送出することを特徴とする。
の発明の構成は、複数のＬＡＮを相互接続装置及び広域
網を介して接続することによりＬＡＮ間の通信を実現し
た広域網を用いたＬＡＮ間の相互通信方式において、送
信側のＬＡＮと送信側の相互接続装置、送信側の相互接
続装置と受信側の相互接続装置及び受信側の相互接続装
置と受信側のＬＡＮの間でそれぞれ独立にデータのフロ
ー制御を行なって、独立に、データの受信を表わす確認
応答を送出することを特徴とする。
【００１９】第２の発明の構成は、送信側及び受信側の
相互接続装置において、ＬＡＮ側のプロトコルのＯＳＩ
参照モデルにおけるトランスポート層のフロー制御を実
現することによりトランスポート層までを終端するとと
もに、送信側及び受信側の相互接続装置では、ＬＡＮ側
のプロトコルとは異なる広域網用のプロトコルにより通
信を行なうようにしたことを特徴とする。
相互接続装置において、ＬＡＮ側のプロトコルのＯＳＩ
参照モデルにおけるトランスポート層のフロー制御を実
現することによりトランスポート層までを終端するとと
もに、送信側及び受信側の相互接続装置では、ＬＡＮ側
のプロトコルとは異なる広域網用のプロトコルにより通
信を行なうようにしたことを特徴とする。
【００２０】第３の発明の構成は、広域網を介して複数
のＬＡＮを接続するとともに、ＬＡＮ側と広域網側のプ
ロトコルを相互に変換して相互通信を可能とする相互接
続装置において、ＬＡＮ内で使用されるＬＡＮ側のプロ
トコルのフロー制御を終端する終端手段と、広域網上で
使用される広域網側のプロトコルのフロー制御のパラメ
ータを該広域網の伝送速度及び伝送遅延に対して最適に
設定した最適化手段とを有することを特徴とする。
のＬＡＮを接続するとともに、ＬＡＮ側と広域網側のプ
ロトコルを相互に変換して相互通信を可能とする相互接
続装置において、ＬＡＮ内で使用されるＬＡＮ側のプロ
トコルのフロー制御を終端する終端手段と、広域網上で
使用される広域網側のプロトコルのフロー制御のパラメ
ータを該広域網の伝送速度及び伝送遅延に対して最適に
設定した最適化手段とを有することを特徴とする。
【００２１】第４の発明の構成は、終端手段は、ＬＡＮ
側のプロトコルのトランスポート層のフロー制御機能を
用いることにより実現し、最適化手段は広域網側のプロ
トコルのバッファリング機能を用いることにより実現し
たものであることを特徴とする。
側のプロトコルのトランスポート層のフロー制御機能を
用いることにより実現し、最適化手段は広域網側のプロ
トコルのバッファリング機能を用いることにより実現し
たものであることを特徴とする。
【００２２】
【作用】上記構成の本発明においては、送信側のＬＡＮ
と送信側の相互接続装置、送信側の相互接続装置と受信
側の相互接続装置及び受信側の相互接続装置と受信側の
ＬＡＮの間でそれぞれ独立にデータの受信を表わす確認
応答を送出する。また、それぞれ独立の３個の部分で各
部分に固有の態様で最も効率の良い通信を行なう。
と送信側の相互接続装置、送信側の相互接続装置と受信
側の相互接続装置及び受信側の相互接続装置と受信側の
ＬＡＮの間でそれぞれ独立にデータの受信を表わす確認
応答を送出する。また、それぞれ独立の３個の部分で各
部分に固有の態様で最も効率の良い通信を行なう。
【００２３】具体的には、相互通信装置で、ＬＡＮ側の
プロトコルのトランスポート層のフロー制御を実現する
とともに、広域網を介した相互接続装置間の通信は、Ｌ
ＡＮ側のプロトコルとは異なるプロトコルを用いて実現
する。
プロトコルのトランスポート層のフロー制御を実現する
とともに、広域網を介した相互接続装置間の通信は、Ｌ
ＡＮ側のプロトコルとは異なるプロトコルを用いて実現
する。
【００２４】かくして、ＬＡＮ内で使用されるプロトコ
ルのフロー制御を相互接続装置において終端し、広域網
では、その広域網に最適なフロー制御パラメータにより
通信を行なう。
ルのフロー制御を相互接続装置において終端し、広域網
では、その広域網に最適なフロー制御パラメータにより
通信を行なう。
【００２５】
【実施例】以下本発明の実施例を図面に基づき詳細に説
明する。図１は、本発明の実施例に係る相互通信方式を
そのプロトコル構成例とともに示す説明図である。同図
に示すように、本実施例では、ＬＡＮ１，２のプロトコ
ルとして、ＴＣＰ／ＩＰを対象とした場合の例を示して
いる。なお、ＴＣＰにおいては、処理の単位となるひと
まとまりのデータはセグメントと呼ばれるが、ここでは
混乱をさけるためにパケットという用語に統一する。
明する。図１は、本発明の実施例に係る相互通信方式を
そのプロトコル構成例とともに示す説明図である。同図
に示すように、本実施例では、ＬＡＮ１，２のプロトコ
ルとして、ＴＣＰ／ＩＰを対象とした場合の例を示して
いる。なお、ＴＣＰにおいては、処理の単位となるひと
まとまりのデータはセグメントと呼ばれるが、ここでは
混乱をさけるためにパケットという用語に統一する。
【００２６】相互接続装置１３，１４は、広域網５を介
して複数のＬＡＮ１，２を接続し、ＬＡＮ１，２側と広
域網５側のプロトコルを相互に変換して相互通信を可能
とするとともに、ＬＡＮ１，２内で使用されるＬＡＮ
１，２側のプロトコルのフロー制御を終端する終端手段
と、広域網５上で使用される広域網５側のプロトコルの
フロー制御のパラメータを該広域網５の伝送速度及び伝
送遅延に対して最適に設定した最適化手段とを有する。
して複数のＬＡＮ１，２を接続し、ＬＡＮ１，２側と広
域網５側のプロトコルを相互に変換して相互通信を可能
とするとともに、ＬＡＮ１，２内で使用されるＬＡＮ
１，２側のプロトコルのフロー制御を終端する終端手段
と、広域網５上で使用される広域網５側のプロトコルの
フロー制御のパラメータを該広域網５の伝送速度及び伝
送遅延に対して最適に設定した最適化手段とを有する。
【００２７】すなわち、相互接続装置１３，１４は、Ｌ
ＡＮ１，２に対して、ＴＣＰまでの通信プロトコルの処
理を実行し、ＴＣＰのコネクションを終端する。また、
相互接続装置１３，１４は、広域網５側に対して、物理
層からネットワーク層までのプロトコルとして、ＩＴＵ
−Ｔ勧告Ｘ.2５で規定されるプロトコル（以下単にＸ.2
５と呼ぶ）を使用する。更に、強制データ転送等のＴＣ
Ｐ独自の機能を、ＬＡＮ１，２に接続された計算機１
ａ，２ａの間で通知するために、相互接続装置１３，１
４間で専用に用いられる相互接続用トランスポートプロ
トコル（相互接続用ＴＰ）を導入する。
ＡＮ１，２に対して、ＴＣＰまでの通信プロトコルの処
理を実行し、ＴＣＰのコネクションを終端する。また、
相互接続装置１３，１４は、広域網５側に対して、物理
層からネットワーク層までのプロトコルとして、ＩＴＵ
−Ｔ勧告Ｘ.2５で規定されるプロトコル（以下単にＸ.2
５と呼ぶ）を使用する。更に、強制データ転送等のＴＣ
Ｐ独自の機能を、ＬＡＮ１，２に接続された計算機１
ａ，２ａの間で通知するために、相互接続装置１３，１
４間で専用に用いられる相互接続用トランスポートプロ
トコル（相互接続用ＴＰ）を導入する。
【００２８】広域網５を介した相互接続装置１３，１４
間でのデータのやりとりのために、以下のような手順が
用いられる。すなわち、データの転送においては、ＴＣ
ＰのコネクションをＸ.2５のバーチャルコールに対応さ
せ、広域網５上では、Ｘ.2５のレイヤ２及びレイヤ３で
フロー制御を行う。充分なウインドウサイズを確保する
ため、レイヤ２及びレイヤ３ともにモジュロ１２８によ
る動作を行い、レイヤ２の最大アウトスタンディング情
報フレーム数、及びレイヤ３のウインドウサイズの最大
値として１２７をサポートする。また、ＴＣＰのデータ
パケットを分割することなく転送可能とするため、レイ
ヤ３の最大パケットサイズは２０４８オクテットとす
る。更に、受信側の相互接続装置１４においては、デー
タを受信する都度、レイヤ２では受信可監視フレームを
返し、レイヤ３では受信可パケットを返す。
間でのデータのやりとりのために、以下のような手順が
用いられる。すなわち、データの転送においては、ＴＣ
ＰのコネクションをＸ.2５のバーチャルコールに対応さ
せ、広域網５上では、Ｘ.2５のレイヤ２及びレイヤ３で
フロー制御を行う。充分なウインドウサイズを確保する
ため、レイヤ２及びレイヤ３ともにモジュロ１２８によ
る動作を行い、レイヤ２の最大アウトスタンディング情
報フレーム数、及びレイヤ３のウインドウサイズの最大
値として１２７をサポートする。また、ＴＣＰのデータ
パケットを分割することなく転送可能とするため、レイ
ヤ３の最大パケットサイズは２０４８オクテットとす
る。更に、受信側の相互接続装置１４においては、デー
タを受信する都度、レイヤ２では受信可監視フレームを
返し、レイヤ３では受信可パケットを返す。
【００２９】図２は、本実施例におけるデータ転送時の
シーケンスの概要を示している。同図に示すように、相
互接続装置１３は、ＴＣＰプロトコルに従って、送信側
の計算機１ａからデータパケットを受信すると、送信側
に対して直ちに確認応答パケットを返すとともに、広域
網５へデータパケットを中継する。
シーケンスの概要を示している。同図に示すように、相
互接続装置１３は、ＴＣＰプロトコルに従って、送信側
の計算機１ａからデータパケットを受信すると、送信側
に対して直ちに確認応答パケットを返すとともに、広域
網５へデータパケットを中継する。
【００３０】広域網５を介した相互接続装置１３，１４
間では、十分に大きなウインドウサイズを設定し、デー
タパケットを受信する都度、確認応答を行うことにより
送信側の相互接続装置１３で確認応答待ちが発生しない
ようにする。
間では、十分に大きなウインドウサイズを設定し、デー
タパケットを受信する都度、確認応答を行うことにより
送信側の相互接続装置１３で確認応答待ちが発生しない
ようにする。
【００３１】受信側の相互接続装置１４はデータパケッ
トを受信側の計算機２ａにＴＣＰのフロー制御を実行し
つつ中継する。受信側の計算機２ａからの確認応答パケ
ットについては、相互接続装置１４内で処理され、広域
網側へは転送されない。
トを受信側の計算機２ａにＴＣＰのフロー制御を実行し
つつ中継する。受信側の計算機２ａからの確認応答パケ
ットについては、相互接続装置１４内で処理され、広域
網側へは転送されない。
【００３２】このように、送信側の計算機１ａと相互接
続装置１３間、広域網５を介した相互接続装置１３，１
４間、及び相互接続装置１４と受信側の計算機２ａ間
で、最適なフロー制御を各々独立に行うことにより確実
かつ効率的なデータ転送を行うことができる。
続装置１３間、広域網５を介した相互接続装置１３，１
４間、及び相互接続装置１４と受信側の計算機２ａ間
で、最適なフロー制御を各々独立に行うことにより確実
かつ効率的なデータ転送を行うことができる。
【００３３】相互接続装置１３，１４における送受信用
のバッファメモリとしては、広域網５の伝送速度と往復
の伝送遅延の積以上のものを準備する必要がある。ま
た、広域網上で使用すべきウインドウサイズは、ウイン
ドウサイズ＝（往復の伝送遅延×伝送速度）／（データ
パケットの大きさ）により決定される。
のバッファメモリとしては、広域網５の伝送速度と往復
の伝送遅延の積以上のものを準備する必要がある。ま
た、広域網上で使用すべきウインドウサイズは、ウイン
ドウサイズ＝（往復の伝送遅延×伝送速度）／（データ
パケットの大きさ）により決定される。
【００３４】例として、伝送速度２Ｍbit/s 、往復の伝
送遅延が１５０ｍsec の通信回線を使用する場合を考え
ると、送受信用バッファメモリとして３８ＫＢ以上を確
保し、イーサネット上のデータパケットの最大長が約１
５００オクテットであることから、広域網５上でのウイ
ンドウサイズは２７以上とすることが必要となる。
送遅延が１５０ｍsec の通信回線を使用する場合を考え
ると、送受信用バッファメモリとして３８ＫＢ以上を確
保し、イーサネット上のデータパケットの最大長が約１
５００オクテットであることから、広域網５上でのウイ
ンドウサイズは２７以上とすることが必要となる。
【００３５】図３は、ＴＣＰコネクション確立時のシー
ケンスを示している。ＴＣＰにおいては、そのパケット
の種別や強制データ転送の要求等を示すビット列がＴＣ
Ｒヘッダ内のコードフィールドとして設定され、コネク
ションの確立は、送信側の計算機１ａと受信側の計算機
２ａの間で、ＳＹＮ（ＳＹＮｃｈｒｏｎｉｚａｔｉｏ
ｎ）パケット（コードフィールド内のＳＹＮビットが１
に設定されたパケット）、ＳＹＮ−ＡＣＫパケット（Ｓ
ＹＮビットとＡＣＫビットが１に設定されたパケッ
ト）、ＡＣＫパケット（ＡＣＫビットが１に設定された
パケット）を交換する、３ウェイハンドシェークにより
行われる。
ケンスを示している。ＴＣＰにおいては、そのパケット
の種別や強制データ転送の要求等を示すビット列がＴＣ
Ｒヘッダ内のコードフィールドとして設定され、コネク
ションの確立は、送信側の計算機１ａと受信側の計算機
２ａの間で、ＳＹＮ（ＳＹＮｃｈｒｏｎｉｚａｔｉｏ
ｎ）パケット（コードフィールド内のＳＹＮビットが１
に設定されたパケット）、ＳＹＮ−ＡＣＫパケット（Ｓ
ＹＮビットとＡＣＫビットが１に設定されたパケッ
ト）、ＡＣＫパケット（ＡＣＫビットが１に設定された
パケット）を交換する、３ウェイハンドシェークにより
行われる。
【００３６】相互接続装置１３は、ＳＹＮパケットを検
出すると送信側との間で３ウェイハンドシェイクを行
い、広域網５側へは発呼要求パケットを送信する。この
発呼要求パケットのコールユーザデータとして、発信側
と受信側の計算機１ａ，２ａのＩＰアドレスとポート番
号の組を通知する。バーチャルコールが確立されると、
相互接続装置１３，１４はＴＣＰコネクションとバーチ
ャルコールの対応を保持し、データ転送フェーズへ移行
する。
出すると送信側との間で３ウェイハンドシェイクを行
い、広域網５側へは発呼要求パケットを送信する。この
発呼要求パケットのコールユーザデータとして、発信側
と受信側の計算機１ａ，２ａのＩＰアドレスとポート番
号の組を通知する。バーチャルコールが確立されると、
相互接続装置１３，１４はＴＣＰコネクションとバーチ
ャルコールの対応を保持し、データ転送フェーズへ移行
する。
【００３７】図４は、ＴＣＰコネクションの解放時のシ
ーケンスを示している。ＴＣＰにおいては、コネクショ
ンの解放は、送信側の計算機１ａと受信側の計算機２ａ
の間でＦＩＮパケット（コードフィールド内のＦＩＮビ
ットが１に設定されたパケット）、ＦＩＮ−ＡＣＫパケ
ット（ＦＩＮビットとＡＣＫビットが１に設定されたパ
ケット）、ＡＣＫパケットを通知しあうことにより行わ
れる。
ーケンスを示している。ＴＣＰにおいては、コネクショ
ンの解放は、送信側の計算機１ａと受信側の計算機２ａ
の間でＦＩＮパケット（コードフィールド内のＦＩＮビ
ットが１に設定されたパケット）、ＦＩＮ−ＡＣＫパケ
ット（ＦＩＮビットとＡＣＫビットが１に設定されたパ
ケット）、ＡＣＫパケットを通知しあうことにより行わ
れる。
【００３８】相互接続装置１３は、ＦＩＮパケットを検
出すると、バッファリングしたデータをすべて転送した
後にバーチャルコールを解放する。
出すると、バッファリングしたデータをすべて転送した
後にバーチャルコールを解放する。
【００３９】相互接続装置１４では、ＬＡＮ２内に存在
する複数の計算機２ａのデータ転送を中継する必要があ
る。また、ＵＤＰ（User Datagram Protocl)等、ＴＣＰ
以外のトランスポート層プロトコルのデータも中継する
必要がある。このため、相互接続装置１３，１４間で
は、計算機１ａ，２ａと相互接続装置１３，１４との間
に確立される個々のＴＣＰコネクションと一対一に対応
づけられるバーチャルコールとともに、ＴＣＰ以外のパ
ケットを転送するための独立なバーチャルコールをひと
つ確立する。
する複数の計算機２ａのデータ転送を中継する必要があ
る。また、ＵＤＰ（User Datagram Protocl)等、ＴＣＰ
以外のトランスポート層プロトコルのデータも中継する
必要がある。このため、相互接続装置１３，１４間で
は、計算機１ａ，２ａと相互接続装置１３，１４との間
に確立される個々のＴＣＰコネクションと一対一に対応
づけられるバーチャルコールとともに、ＴＣＰ以外のパ
ケットを転送するための独立なバーチャルコールをひと
つ確立する。
【００４０】図５は、ＬＡＮ１側から受信したひとつの
パケットに対する相互接続装置１３の処理アルゴリズム
を示すフローチャートである。
パケットに対する相互接続装置１３の処理アルゴリズム
を示すフローチャートである。
【００４１】（１） パケットのＩＰヘッダに含まれる
ＰＲＯＴＯＣＯＬフィールドの値から、そのパケットが
ＴＣＰのパケットか、若しくはそれ以外であるかを検出
する（ステップＳ1 ）。
ＰＲＯＴＯＣＯＬフィールドの値から、そのパケットが
ＴＣＰのパケットか、若しくはそれ以外であるかを検出
する（ステップＳ1 ）。
【００４２】（２） ＴＣＰパケットでない場合、事前
に確立した独立のバーチャルコールにより転送する（ス
テップＳ2 ）。
に確立した独立のバーチャルコールにより転送する（ス
テップＳ2 ）。
【００４３】（３） ステップＳ1 の処理によりＴＣＰ
パケットであると判断された場合には、ＩＰヘッダ中の
アドレスフィールドから、パケットの送信側の計算機１
ａと受信側の計算機２ａのＩＰアドレスを取得する。ま
た、ＴＣＰヘッダから送信側と受信側のポート番号を取
得する（ステップＳ3 ）。
パケットであると判断された場合には、ＩＰヘッダ中の
アドレスフィールドから、パケットの送信側の計算機１
ａと受信側の計算機２ａのＩＰアドレスを取得する。ま
た、ＴＣＰヘッダから送信側と受信側のポート番号を取
得する（ステップＳ3 ）。
【００４４】（４） ＴＣＰヘッダ内のコードフィール
ドのビットをチェックする（ステップＳ4 ）。
ドのビットをチェックする（ステップＳ4 ）。
【００４５】（５） ＳＹＮパケットあるいはＳＹＮ−
ＡＣＫパケットであるかを否かを判断する（ステップＳ
5 ）。
ＡＣＫパケットであるかを否かを判断する（ステップＳ
5 ）。
【００４６】（６） ステップＳ5 の処理の結果、ＳＹ
ＮパケットあるいはＳＹＮ−ＡＣＫパケットである場合
には、ＳＹＮ−ＡＣＫパケットであるか否かを判断す
る。（ステップＳ6 ）。
ＮパケットあるいはＳＹＮ−ＡＣＫパケットである場合
には、ＳＹＮ−ＡＣＫパケットであるか否かを判断す
る。（ステップＳ6 ）。
【００４７】（７） ＳＹＮ−ＡＣＫパケットの場合、
受信したＳＹＮ−ＡＣＫパケットに対する確認応答を行
って、３ウェイハンドシェークを完結する（ステップＳ
7 ）。
受信したＳＹＮ−ＡＣＫパケットに対する確認応答を行
って、３ウェイハンドシェークを完結する（ステップＳ
7 ）。
【００４８】（８） ステップＳ6 の処理の結果、ＳＹ
Ｎ−ＡＣＫパケットでない場合、新たなＴＣＰコネクシ
ョンの確立要求であるため、受信側の計算機２ａが存在
するＬＡＮ２の相互接続装置１４に対して、新規のバー
チャルコールを確立する（ステップＳ8 ）。
Ｎ−ＡＣＫパケットでない場合、新たなＴＣＰコネクシ
ョンの確立要求であるため、受信側の計算機２ａが存在
するＬＡＮ２の相互接続装置１４に対して、新規のバー
チャルコールを確立する（ステップＳ8 ）。
【００４９】（９） 次に、送信側の計算機１ａに対し
てＳＹＮ−ＡＣＫパケットを送信し、受信したＳＹＮパ
ケットに対する処理を終了する（ステップＳ9 ）。
てＳＹＮ−ＡＣＫパケットを送信し、受信したＳＹＮパ
ケットに対する処理を終了する（ステップＳ9 ）。
【００５０】（10） ステップＳ5 の処理の結果、ＳＹ
ＮパケットでもＳＹＮ−ＡＣＫパケットでもない場合、
送信側のＩＰアドレスとポート番号、及び受信側のＩＰ
アドレスとポート番号から、対応する広域網５上のバー
チャルコールを決定する（ステップＳ10）。
ＮパケットでもＳＹＮ−ＡＣＫパケットでもない場合、
送信側のＩＰアドレスとポート番号、及び受信側のＩＰ
アドレスとポート番号から、対応する広域網５上のバー
チャルコールを決定する（ステップＳ10）。
【００５１】（11） 受信したＴＣＰパケットがＦＩＮ
パケットあるいはＦＩＮ−ＡＣＫパケットであるか否か
を判断する（ステップＳ11）。
パケットあるいはＦＩＮ−ＡＣＫパケットであるか否か
を判断する（ステップＳ11）。
【００５２】（12） ステップＳ11の処理の結果、ＦＩ
ＮパケットあるいはＦＩＮ−ＡＣＫパケットである場合
には、ＦＩＮ−ＡＣＫパケットであるか否かを判断する
（ステップＳ12）。
ＮパケットあるいはＦＩＮ−ＡＣＫパケットである場合
には、ＦＩＮ−ＡＣＫパケットであるか否かを判断する
（ステップＳ12）。
【００５３】（13） ステップＳ12の処理の結果ＦＩＮ
−ＡＣＫパケットである場合、バーチャルコールを解放
するとともに、ＬＡＮ１側へ確認応答を返す（ステップ
Ｓ13，Ｓ7 ）。
−ＡＣＫパケットである場合、バーチャルコールを解放
するとともに、ＬＡＮ１側へ確認応答を返す（ステップ
Ｓ13，Ｓ7 ）。
【００５４】（14） ステップＳ13の処理の結果ＦＩＮ
−ＡＣＫパケットでない場合、まずＬＡＮ１側にＡＣＫ
バケットを送信する（ステップＳ14）。
−ＡＣＫパケットでない場合、まずＬＡＮ１側にＡＣＫ
バケットを送信する（ステップＳ14）。
【００５５】（15） 次に、相互接続装置１３内でその
ＴＣＰコネクションのデータパケットがバッファリング
されていればすべて広域網５側に送信し、その後ＦＩＮ
パケットを受信したことを相手側の相互接続装置１４に
通知する（ステップＳ15）。
ＴＣＰコネクションのデータパケットがバッファリング
されていればすべて広域網５側に送信し、その後ＦＩＮ
パケットを受信したことを相手側の相互接続装置１４に
通知する（ステップＳ15）。
【００５６】（16） ステップＳ11の処理の結果、ＦＩ
ＮパケットでもＦＩＮ−ＡＣＫパケットでもない場合に
は、コードフィールド内の他のビットをチェックし、必
要に応じ次の処理を行う（ステップＳ16）。
ＮパケットでもＦＩＮ−ＡＣＫパケットでもない場合に
は、コードフィールド内の他のビットをチェックし、必
要に応じ次の処理を行う（ステップＳ16）。
【００５７】ＵＲＧ（URGent）ビットがセットされてい
る場合には、相互接続装置間に専用のトランスポート層
プロトコルの機能を使用して、帯域外データを通知す
る。
る場合には、相互接続装置間に専用のトランスポート層
プロトコルの機能を使用して、帯域外データを通知す
る。
【００５８】ＰＳＨ（PuSH）ビットがセットされている
場合には、同様にして強制データ配送が要求されている
ことを通知する。
場合には、同様にして強制データ配送が要求されている
ことを通知する。
【００５９】ＲＳＴ（ReSeT)ビットがセットされている
場合には、相互接続装置１３，１４内でそのＴＣＰコネ
クションのデータパケットがバッファリングされていれ
ばすべて廃棄した後、相互接続装置１３，１４間に専用
のトランスポート層プロトコルの機能を使用して、コネ
クションのリセットが要求されていることを通知する。
場合には、相互接続装置１３，１４内でそのＴＣＰコネ
クションのデータパケットがバッファリングされていれ
ばすべて廃棄した後、相互接続装置１３，１４間に専用
のトランスポート層プロトコルの機能を使用して、コネ
クションのリセットが要求されていることを通知する。
【００６０】（17） データパケットを、そのＴＣＰコ
ネクションに対応する対応するバーチャルコールを使用
して中継する（テップＳ17）。
ネクションに対応する対応するバーチャルコールを使用
して中継する（テップＳ17）。
【００６１】（18） 送信側の計算機１ａに対して確認
応答を行う（ステップＳ7 ）。
応答を行う（ステップＳ7 ）。
【００６２】
【発明の効果】以上実施例とともに詳細に説明したよう
に本発明によれば、ＬＡＮ内で使用されるプロトコルの
フロー制御を相互接続装置において終端し、広域網上で
は、その広域網に最適なフロー制御パラメータにより通
信を行なうこととしたので、既存の応用プログラムに何
らの変更を加えることなく、伝送遅延の大きな広域網を
介して、その伝送速度に近い通信速度により通信を行な
える効果が期待できる。
に本発明によれば、ＬＡＮ内で使用されるプロトコルの
フロー制御を相互接続装置において終端し、広域網上で
は、その広域網に最適なフロー制御パラメータにより通
信を行なうこととしたので、既存の応用プログラムに何
らの変更を加えることなく、伝送遅延の大きな広域網を
介して、その伝送速度に近い通信速度により通信を行な
える効果が期待できる。
【図１】本発明の実施例に係る相互通信方式をそのプロ
トコル構成例とともに示す説明図。
トコル構成例とともに示す説明図。
【図２】上記実施例におけるデータ転送時のシーケンス
の概要を示す説明図。
の概要を示す説明図。
【図３】上記実施例におけるＴＣＰコネクション確立時
のシーケンスを示す説明図。
のシーケンスを示す説明図。
【図４】上記実施例におけるＴＣＰコネクション解放時
のシーケンスを示す説明図。
のシーケンスを示す説明図。
【図５】ＬＡＮ側から受信したひとつのパケットに対す
る相互接続装置の処理アルゴリズムを示すフローチャー
ト。
る相互接続装置の処理アルゴリズムを示すフローチャー
ト。
【図６】広域網を用いたＬＡＮ間の相互通信方式を概念
的に示す説明図。
的に示す説明図。
【図７】図６に示す場合におけるＯＳＩ参照モデルのプ
ロトコルを示す説明図。
ロトコルを示す説明図。
【図８】図６に示す場合の従来技術における通信時のシ
ーケンスを示す説明図。
ーケンスを示す説明図。
１，２ ＬＡＮ １ａ，２ａ 計算機 ５ 広域網 １３，１４ 相互接続装置
Claims (4)
- 【請求項１】 複数のＬＡＮを相互接続装置及び広域網
を介して接続することによりＬＡＮ間の通信を実現した
広域網を用いたＬＡＮ間の相互通信方式において、 送信側のＬＡＮと送信側の相互接続装置、送信側の相互
接続装置と受信側の相互接続装置及び受信側の相互接続
装置と受信側のＬＡＮの間でそれぞれ独立にデータのフ
ロー制御を行なって、独立に、データの受信を表わす確
認応答を送出することを特徴とする広域網を用いたＬＡ
Ｎ間の相互通信方式。 - 【請求項２】 送信側及び受信側の相互接続装置におい
て、ＬＡＮ側のプロトコルのＯＳＩ参照モデルにおける
トランスポート層のフロー制御を実現することによりト
ランスポート層までを終端するとともに、送信側及び受
信側の相互接続装置では、ＬＡＮ側のプロトコルとは異
なる広域網用のプロトコルにより通信を行なうようにし
たことを特徴とする［請求項１］に記載の広域網を用い
たＬＡＮ間の相互通信方式。 - 【請求項３】 広域網を介して複数のＬＡＮを接続する
とともに、ＬＡＮ側と広域網側のプロトコルを相互に変
換して相互通信を可能とする相互接続装置において、 ＬＡＮ内で使用されるＬＡＮ側のプロトコルのフロー制
御を終端する終端手段と、 広域網上で使用される広域網側のプロトコルのフロー制
御のパラメータを該広域網の伝送速度及び伝送遅延に対
して最適に設定した最適化手段とを有することを特徴と
する相互接続装置。 - 【請求項４】 終端手段は、ＬＡＮ側のプロトコルのト
ランスポート層のフロー制御機能を用いることにより実
現し、最適化手段は広域網側のプロトコルのバッファリ
ング機能を用いることにより実現したものであることを
特徴とする［請求項３］に記載の相互接続装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP6038738A JPH07250100A (ja) | 1994-03-09 | 1994-03-09 | 広域網を用いたｌａｎ間の相互通信方式及びこれに用いる相互接続装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP6038738A JPH07250100A (ja) | 1994-03-09 | 1994-03-09 | 広域網を用いたｌａｎ間の相互通信方式及びこれに用いる相互接続装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH07250100A true JPH07250100A (ja) | 1995-09-26 |
Family
ID=12533670
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP6038738A Pending JPH07250100A (ja) | 1994-03-09 | 1994-03-09 | 広域網を用いたｌａｎ間の相互通信方式及びこれに用いる相互接続装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH07250100A (ja) |
Cited By (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09114781A (ja) * | 1995-10-13 | 1997-05-02 | Sony Corp | 端末装置、受信方法、サーバ、送信方法、送受信装置、および送受信方法 |
| KR100320395B1 (ko) * | 1998-02-27 | 2002-01-15 | 클라크 3세 존 엠. | 네트워크용 흐름 제어방법 |
| JP2005136684A (ja) * | 2003-10-30 | 2005-05-26 | Nippon Telegr & Teleph Corp <Ntt> | データ転送方法とｔｃｐプロキシ装置およびそれを用いたネットワークシステム |
| JP2005192157A (ja) * | 2003-12-26 | 2005-07-14 | Digital Design Co Ltd | データ通信方法及びデータ通信システム |
| JP2005348107A (ja) * | 2004-06-03 | 2005-12-15 | Kddi Corp | データ通信装置 |
| JP2007129749A (ja) * | 2006-12-18 | 2007-05-24 | Sony Corp | 通話システム、端末装置、サーバ及び通話方法 |
| US7295512B2 (en) | 2001-06-14 | 2007-11-13 | Hitachi, Ltd. | Performance enhanced TCP communication system |
| JP2010098430A (ja) * | 2008-10-15 | 2010-04-30 | Sumitomo Electric Ind Ltd | 通信装置 |
| WO2011037245A1 (ja) * | 2009-09-24 | 2011-03-31 | 日本電気株式会社 | 通信データ伝送装置、通信データ伝送システム、通信データ伝送方法、及び通信データ伝送プログラム |
| JP4826827B2 (ja) * | 2005-02-28 | 2011-11-30 | 日本電気株式会社 | 通信装置、通信システム、通信方法、及びプログラム |
| WO2013011689A1 (ja) * | 2011-07-19 | 2013-01-24 | 日本電気株式会社 | 伝送システム、ルーティング制御装置およびルーティング制御方法 |
| JP2013247632A (ja) * | 2012-05-29 | 2013-12-09 | Mitsubishi Electric Corp | Ｔｃｐ通信高速化装置 |
| JP2016144159A (ja) * | 2015-02-04 | 2016-08-08 | アンリツネットワークス株式会社 | 通信システム及び通信方法 |
| WO2016157914A1 (ja) * | 2015-04-02 | 2016-10-06 | 日本電気株式会社 | ネットワークシステム、通信制御方法、及び、記録媒体 |
| US11855894B2 (en) | 2020-10-06 | 2023-12-26 | Mitsubishi Electric Corporation | Control system, server, terminal device, control device, communication control method, and recording medium |
-
1994
- 1994-03-09 JP JP6038738A patent/JPH07250100A/ja active Pending
Cited By (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09114781A (ja) * | 1995-10-13 | 1997-05-02 | Sony Corp | 端末装置、受信方法、サーバ、送信方法、送受信装置、および送受信方法 |
| KR100320395B1 (ko) * | 1998-02-27 | 2002-01-15 | 클라크 3세 존 엠. | 네트워크용 흐름 제어방법 |
| US7295512B2 (en) | 2001-06-14 | 2007-11-13 | Hitachi, Ltd. | Performance enhanced TCP communication system |
| JP2005136684A (ja) * | 2003-10-30 | 2005-05-26 | Nippon Telegr & Teleph Corp <Ntt> | データ転送方法とｔｃｐプロキシ装置およびそれを用いたネットワークシステム |
| JP2005192157A (ja) * | 2003-12-26 | 2005-07-14 | Digital Design Co Ltd | データ通信方法及びデータ通信システム |
| JP2005348107A (ja) * | 2004-06-03 | 2005-12-15 | Kddi Corp | データ通信装置 |
| JP4826827B2 (ja) * | 2005-02-28 | 2011-11-30 | 日本電気株式会社 | 通信装置、通信システム、通信方法、及びプログラム |
| US8250643B2 (en) | 2005-02-28 | 2012-08-21 | Nec Corporation | Communication device, communication system, communication method, and program |
| JP2007129749A (ja) * | 2006-12-18 | 2007-05-24 | Sony Corp | 通話システム、端末装置、サーバ及び通話方法 |
| JP2010098430A (ja) * | 2008-10-15 | 2010-04-30 | Sumitomo Electric Ind Ltd | 通信装置 |
| WO2011037245A1 (ja) * | 2009-09-24 | 2011-03-31 | 日本電気株式会社 | 通信データ伝送装置、通信データ伝送システム、通信データ伝送方法、及び通信データ伝送プログラム |
| JPWO2011037245A1 (ja) * | 2009-09-24 | 2013-02-21 | 日本電気株式会社 | 通信データ伝送装置、通信データ伝送システム、通信データ伝送方法、及び通信データ伝送プログラム |
| US8761605B2 (en) | 2009-09-24 | 2014-06-24 | Nec Corporation | Communication data transmission equipment, a communication data transmission system, a communication data transmission method and a communication data transmission program |
| WO2013011689A1 (ja) * | 2011-07-19 | 2013-01-24 | 日本電気株式会社 | 伝送システム、ルーティング制御装置およびルーティング制御方法 |
| JP5672385B2 (ja) * | 2011-07-19 | 2015-02-18 | 日本電気株式会社 | 伝送システム、ルーティング制御装置および通信装置、並びにルーティング制御方法および通信方法 |
| US9608861B2 (en) | 2011-07-19 | 2017-03-28 | Nec Corporation | Transmission system, routing control device and method for controlling routing |
| JP2013247632A (ja) * | 2012-05-29 | 2013-12-09 | Mitsubishi Electric Corp | Ｔｃｐ通信高速化装置 |
| JP2016144159A (ja) * | 2015-02-04 | 2016-08-08 | アンリツネットワークス株式会社 | 通信システム及び通信方法 |
| WO2016157914A1 (ja) * | 2015-04-02 | 2016-10-06 | 日本電気株式会社 | ネットワークシステム、通信制御方法、及び、記録媒体 |
| US11855894B2 (en) | 2020-10-06 | 2023-12-26 | Mitsubishi Electric Corporation | Control system, server, terminal device, control device, communication control method, and recording medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Hamzeh et al. | Point-to-point tunneling protocol (PPTP) | |
| JP3430509B2 (ja) | データ通信システム及び方法 | |
| AU2002251937B2 (en) | A Dual Proxy Approach to TCP Performance Improvements Over a Wireless Interface | |
| JP4829896B2 (ja) | データ破壊を避けることによる改善されたネットワーク性能のための方法、システム及び物品 | |
| US6075796A (en) | Methods and apparatus for providing improved quality of packet transmission in applications such as internet telephony | |
| US8843654B2 (en) | Data packet transfer over wide area network in fast and reliable manner | |
| US6487689B1 (en) | Receiver initiated recovery algorithm (RIRA) for the layer 2 tunneling protocol (L2TP) | |
| EP1344359B1 (en) | Method of enhancing the efficiency of data flow in communication systems | |
| JP2002290459A (ja) | パケット転送装置および方法 | |
| US5805818A (en) | System for acknowledging availability of neighbor node using data packet containing data that is ordinarily fowarded to neighbor node | |
| WO2014037760A1 (zh) | 增加数据流传输的方法和系统 | |
| US6535515B1 (en) | TCP communication speed improving system | |
| JP3603256B2 (ja) | インターネットプロトコルネットワークを介するファクシミリデータ伝送方法及びその中継装置 | |
| CN102801692B (zh) | 一种基于分裂连接的传输控制协议优化方法及系统 | |
| JPH10117215A (ja) | ネットワーク間接続方法及びその装置 | |
| JP3711156B2 (ja) | ファイル転送方法 | |
| EP1069735A2 (en) | A sender initiated recovery algorithm (SIRA) for the layer 2 tunneling protocol (L2TP) | |
| WO2004091148A1 (ja) | 無線アクセスシステムにおける移動端末と無線アクセスポイント | |
| US7623546B1 (en) | Latency improvement for file transfers over network connections | |
| JP4505575B2 (ja) | 通信システム、ゲートウェイ送信装置、ゲートウェイ受信装置、送信方法、受信方法および情報記録媒体 | |
| JP4764394B2 (ja) | データ中継システム、データ中継方法およびデータ中継装置 | |
| JP3665309B2 (ja) | 通信システム、通信装置及び通信方法 | |
| JPH0983775A (ja) | ファクシミリ装置 | |
| Hamzeh et al. | RFC2637: Point-to-Point Tunneling Protocol | |
| Chanson et al. | LNTP: An Efficient Transport Protocol for Local Area Networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20000905 |