JPH1198161A - 伝送路二重化処理方式 - Google Patents

伝送路二重化処理方式

Info

Publication number
JPH1198161A
JPH1198161A JP25165897A JP25165897A JPH1198161A JP H1198161 A JPH1198161 A JP H1198161A JP 25165897 A JP25165897 A JP 25165897A JP 25165897 A JP25165897 A JP 25165897A JP H1198161 A JPH1198161 A JP H1198161A
Authority
JP
Japan
Prior art keywords
transmission
data
connection
transmission line
reception
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.)
Granted
Application number
JP25165897A
Other languages
English (en)
Other versions
JP3403021B2 (ja
Inventor
Kazuo Hotta
和男 堀田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP25165897A priority Critical patent/JP3403021B2/ja
Priority to GB9820101A priority patent/GB2332346B/en
Priority to AU85164/98A priority patent/AU718251B2/en
Priority to US09/154,043 priority patent/US6396806B1/en
Publication of JPH1198161A publication Critical patent/JPH1198161A/ja
Application granted granted Critical
Publication of JP3403021B2 publication Critical patent/JP3403021B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B1/00—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
    • H04B1/74—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission for increasing reliability, e.g. using redundant or spare channels or apparatus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/02—Arrangements for detecting or preventing errors in the information received by diversity reception
    • H04L1/06—Arrangements for detecting or preventing errors in the information received by diversity reception using space diversity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1608—Error detection by comparing the output signals of redundant hardware
    • G06F11/1625—Error detection by comparing the output signals of redundant hardware in communications, e.g. transmission, interfaces
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Communication Control (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)

Abstract

(57)【要約】 【課題】伝送路二重化処理方式において、片方の伝送路
で異常が発生した場合も、伝送を停止することなく、継
続することが可能になる。。 【解決手段】第１、第２の伝送路によって二重化された
二重化伝送路を、複数の端末機器間に配設し、ＴＣＰプ
ロトコルを用いてストリーム単位列のデータを、前記端
末機器間に送受信可能にした伝送路二重化処理方式にお
いて、前記各伝送路にそれぞれ前記ストリーム単位列の
データを同時に送信する送信送信手段と、前記送信手段
により送信されたデータのうち先に到着したデータのみ
を生かす受信手段と、前記両伝送路のいずれかに異常が
発生したことを検出する異常検出手段と、前記異常検出
手段により伝送路の異常発生が検出されたとき、該異常
発生した伝送路を開路し、残りの正常な伝送路により送
信受信を行う伝送路切換手段を具備した伝送路二重化処
理方式。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、ソケットインタフ
ェースライブラリを使用してＴＣＰ（Transmission Con
trol Protocol ）プロトコルより上位層でデータ伝送を
行い、汎用パソコン、ワークステーション等で容易に動
作することが可能な伝送路二重化処理方式に関する。
【０００２】
【従来の技術】複数のパソコン間を二重化された伝送路
（Ethernet）により信号を送受信可能に構成したものの
例として、図１に示すものがある。図１は、３台のパソ
コンＰＣ１，ＰＣ２，ＰＣ３相互間が二重化されたＡ系
伝送路（以下単にＡ系と称する場合もある）ＢＡ，Ｂ系
伝送路（以下単にＢ系と称する場合もある）ＢＢにより
接続され、各パソコンにはアプリケーションプログラム
を格納したソフトウェア格納部Ｓ１，Ｓ２，Ｓ３と、デ
バイスドライバＤ１，Ｄ２，Ｄ３と、Ｉ／Ｏ例えば通信
用プロトコルが格納されたイーサネットカード挿入部Ｅ
１，Ｅ２、Ｅ３，Ｅ４、Ｅ５，Ｅ６を備えている。
【０００３】図３３は従来の伝送二重化方式の一例を説
明するため送受信データの流れ図で、図１のハード構成
に対応するソフトウエァの構成を示している。図中１
１，１２は図１のパソコンＰＣ１，ＰＣ２内のソフトウ
ェア格納部Ｓ１，Ｓ２に格納されたアプリケーション、
２１，２２はデバイスドライバＤ１，Ｄ２に格納された
二重化処理部、３１，３２はイーサネットカード挿入部
Ｅ１，Ｅ２、Ｅ３，Ｅ４に格納されたＴＣＰプロトコ
ル、４１，４２はイーサネットカード挿入部Ｅ１，Ｅ
２、Ｅ３，Ｅ４に格納されたＩＰプロトコルである。
【０００４】ＴＣＰプロトコル３１，３２は、コネクシ
ョン（二重化された両方の伝送路）を予め確立し、その
コネクションを用いて伝送する方式である。この場合、
伝送データはブロック単位列ではなく、ストリーム単位
列である。
【０００５】ここで、ブロック単位列とは、通信におけ
る伝送の一かたまりで、データの他に伝送制御文字を含
む単位が複数個からなるデータのことを指している。ス
トリーム単位は、大量のデータをブロックやパケットな
どのかたまりではなく、単なるビット列と考えてバイト
単位が複数個からなるデータのことを指している。
【０００６】このような構成のものにおいて、ＴＣＰプ
ロトコル３１，３２を使用して二重化処理部２１，２２
により二重化処理を行う場合、片方の伝送路例えばＢＡ
でコネクションを確立して伝送を行う。この伝送路ＢＡ
に異常が発生した場合には、反対系の伝送路ＢＢのコネ
クションを確立して伝送を継続している。
【０００７】
【発明が解決しょうとする課題】ＴＣＰプロトコル３
１，３２は、伝送路ＢＡに異常が発生した場合でも送信
のリトライを行う。ＴＣＰプロトコル３１，３２の利用
者は、ＴＣＰプロトコル３１，３２がストリーム単位列
のデータ，，を取り扱うため、ＴＣＰプロトコル
３１，３２に対して要求した送信データのうち、どの部
分までが送信が完了し、どの部分がリトライ処理を行っ
ているのかを知ることができない。
【０００８】伝送路ＢＡが正常のときは、一方の端末機
器ＰＣ１から他方の端末機器ＰＣ２に向けてデータが
，，の順に送信すると、端末機器ＰＣ２ではデー
タが，，の順に受信される。
【０００９】ところが、伝送路ＢＡに異常が発生する
と、伝送路ＢＢ側に切り換わりデータが，，のよ
うに送信されるが、端末機器ＰＣ２では受信されるデー
タが，，の順にならず、，，のように順序が
でたらめになる。
【００１０】従って、片方の伝送路に異常が発生した場
合でも、ＴＣＰプロトコルが行うリトライ処理が終了す
るまで反対系の伝送路を使用し、コネクションの確率を
行うことができない。ＴＣＰプロトコルのリトライ時間
は、通常５〜６分であるため、その間、反対系の伝送路
に切り換えることができず伝送が停止する。
【００１１】本発明はこのような実状に基づいてなされ
たもので、二重化された伝送路の片方で異常が発生した
場合でも、伝送が停止することなく継続することができ
る伝送二重化方式を提供することを目的としている。
【００１２】
【課題を解決するための手段】前記目的を達成するた
め、請求項１に対応する発明は、第１、第２の伝送路に
よって二重化された二重化伝送路を、複数の端末機器間
に配設し、ＴＣＰプロトコルを用いてストリーム単位列
のデータを、前記端末機器間に送受信可能にした伝送路
二重化処理方式において、前記各伝送路にそれぞれ前記
ストリーム単位列のデータを同時に送信する送信送信手
段と、前記送信手段により送信されたデータのうち先に
到着したデータのみを生かす受信手段と、前記両伝送路
のいずれかに異常が発生したことを検出する異常検出手
段と、前記異常検出手段により伝送路の異常発生が検出
されたとき、該異常発生した伝送路を開路し、残りの正
常な伝送路により送信受信を行う伝送路切換手段とを具
備したことを特徴とする伝送路二重化処理方式である。
【００１３】前記目的を達成するため、請求項２に対応
する発明は、前記異常検出手段により伝送路の異常発生
が検出されたとき、該異常発生直前の前記データを保存
する読み出し可能なデータ保存手段を、さらに具備した
ことを特徴とする請求項１記載の伝送路二重化処理方式
である。
【００１４】前記目的を達成するため、請求項３に対応
する発明は、前記受信手段は、データ受信時、前記両伝
送路単位でかつ前記各伝送路毎に受信データサイズを計
測すると共に、該計測値の差分を求め、最初に該差分デ
ータのみを受信し、該計測値の差分がなくなったら次に
新規データを受信することを特徴とする請求項１記載の
伝送路二重化処理方式である。
【００１５】前記目的を達成するため、請求項４に対応
する発明は、前記異常検出手段は、前記データ受信時、
前記両伝送路単位でかつ前記各伝送路毎に受信データサ
イズを計測すると共に、該計測値の差分を求め、該差分
データが規定値を越えたとき、該差分を保持している前
記伝送路は異常と判断するものである請求項１記載の伝
送路二重化処理方式である。
【００１６】前記目的を達成するため、請求項５に対応
する発明は、前記異常検出手段が伝送路の異常を検出
し、内部で前記両伝送路の開路を行った場合、定期的に
前記両伝送路の再確立要求を行い、伝送路が正常に復帰
し、前記両伝送路が確立された場合、再び該両伝送路を
使用して送受信を行うことを特徴とする請求項１記載の
請求項１記載の伝送路二重化処理方式である。
【００１７】前記目的を達成するため、請求項６に対応
する発明は、前記両伝送路の再確立時、ヘッダデータを
受信し、正常の伝送路の受信手段に入っている受信サイ
ズ分のデータを受信するまで、該再確立した伝送路は使
用せず、ヘッダに入っている受信サイズ分のデータを反
対系が受信してはじめて、再確立した前記両伝送路を使
用することを特徴とする請求項５記載の伝送路二重化処
理方式である。
【００１８】請求項１〜請求項５のいずれかに対応する
発明によれば、二重化された伝送路の片方で異常が発生
した場合でも、伝送が停止することなく継続することが
できる。
【００１９】請求項６に対応する発明によれば、請求項
１の作用に加えて、ストリームデータの順序が崩れるこ
とがない。
【００２０】
【発明の実施の形態】以下、本発明の実施形態について
図面を参照して説明する。
【００２１】図２は本発明による伝送路二重化処理方式
の一実施形態を説明するため送受信データの流れ図で、
図１のハード構成に対応するソフトウエァの構成を示し
ている。図中１１，１２は図１のパソコンＰＣ１，ＰＣ
２内のソフトウェア格納部Ｓ１，Ｓ２に格納されたアプ
リケーション、５１，５２はデバイスドライバＤ１，Ｄ
２に格納された二重化処理部、３１，３２はイーサネッ
トカード挿入部Ｅ１，Ｅ２、Ｅ３，Ｅ４に格納されたＴ
ＣＰプロトコル、４１，４２はイーサネットカード挿入
部Ｅ１，Ｅ２、Ｅ３，Ｅ４に格納されたＩＰプロトコル
である。
【００２２】ＴＣＰプロトコル３１，３２は、コネクシ
ョン（二重化された両方の伝送路）を予め確立し、その
コネクションを用いて伝送する方式である。この場合、
伝送データはブロック単位列ではなく、ストリーム単位
列である。
【００２３】本実施形態の二重化処理方式は、ソケット
の作成処理Ｚ１、ソケットへの名前付け処理Ｚ２、接続
の受け入れ許可処理Ｚ３、コネクションの確立処理Ｚ
４、送信処理Ｚ５、受信処理Ｚ６、コネクションの片系
切断処理Ｚ７、コネクションの再確立処理Ｚ８、コネク
ション確立後の処理Ｚ９からなっている。
【００２４】以下、これらについて説明する。
【００２５】コネクションの確立処理Ｚ８は、二重化さ
れた伝送路ＢＡ，ＢＢを、それぞれ常に伝送ができるよ
うにコネクションを確立しておくことである。送信処理
Ｚ５は、送信側では同じデータを両方の伝送路（両方の
コネクション）に送信することである。
【００２６】受信処理Ｚ６は受信側では、先着優先でデ
ータを二重化処理利用者（以後アプリケーションまたは
ユーザアプリケーションと称する場合もある）に通知す
ることである。
【００２７】コネクションの片系切断処理Ｚ７は、この
状態で、片方の伝送路に異常が発生した場合、その異常
系のコネクションを開路（中断）し、残りの正常な伝送
路のみを使用し、送受信を行う。コネクションの切断を
行った異常系は、コネクションの再確立要求を定期的に
行うことである。
【００２８】コネクション確立後の処理Ｚ９は、伝送路
が正常に復帰した場合、再び両方の伝送路を使用し、送
受信を行うことである。
【００２９】このような構成のものにおいて、図２に示
すように常に両系で送受信するための系を切り換える必
要がない。また、例え同じようにデータを受信後にＡ
系が異常となっても、Ｂ系でＡ系と同じデータを受信で
きるため、アプリケーションからの送信データを確実に
相手へ届けることができる。従って、図３に示すよう
に、Ａ系またはＢ系のいずれかから届いた正常データの
組み合わせにより、送信されたデータを正常な形で受信
可能である。
【００３０】図４（ａ）は二重化処理で使用する管理情
報を格納するコネクション管理テーブルの構成を示すも
のである。
【００３１】図４（ｂ）は図４（ａ）のコネクション管
理テーブルの具体的構成を示すもので、この管理テーブ
ルは、コネクションの二重化を制御するために使用する
テーブルである。管理テーブルは、図中に示す内容が格
納され、２５６ノード分のものを示している。
【００３２】図４に示した管理テーブルの中味中身は図
５の通りである。
【００３３】なお、図５において、送信カウンタ、受信
カウンタの共通事項として、範囲は０〜２の３１乗（２
ギガ）という項目がある。
【００３４】図６は、送信差分バッファを示すもので、
１コネクション当り最大サイズで１メガバイトとなって
いる。
【００３５】図７は、コネクション管理テーブルを基
に、二重化処理を実現するための手順の概要を示す図で
あり、説明する上で図３に示すコネクション管理テーブ
ルを用いるが、正式用語ではなく、省略した用語を使用
している。また、ＩＰアドレスは下位１バイトを使用し
て説明している。
【００３６】＜ソケットの作成処理Ｚ１＞図８は、ソケ
ットの作成処理、すなわち、ソケットの作成から図３の
コネクション管理テーブルへの格納までを説明するため
の図である。この処理は、ソケットを一つ作成し、次の
１）〜５）の手順で空いている図３のコネクション管理
テーブルを探し、情報を設定する。使用するソケットラ
イブラリは、Ｓｏｃｋｅｔ関数である。
【００３７】１）ソケットの取得 いま、新ソケット（１２０）＝Ｓｏｃｋｅｔ（）のと
き、 ２）空きテーブルを検索 すなわち、コネクション管理テーブルから空きテーブル
を検索する。
【００３８】３）ＩＮＤＸ＝３に空きあり ４）取得したソケットを空きテーブルのＡ系用ソケット
へ格納する。まだ、コネクションが確立されていないの
で、クライアント側かサーバ側かわからない。従って、
使用状態は０とする。ソケットはＴＣＰ用として作成し
たものとする。 ５）戻り値はＩＮＤＸとする。この例では、３を戻り値
とする。ユーザアプリは以後このＩＮＤＸ番号を使用し
て要求を行ってくる。
【００３９】＜ソケットへの名前付け処理＞図９は、ソ
ケットへの名前付け処理（バインド処理）の手順を説明
するための図で、次の１）〜４）の手順で行われる。
【００４０】ユーザアプリから指定のあったポート番
号、ＩＰアドレスでバインド（ソケットへの名前付け処
理）する。この場合、使用するソケットライブラリはｂ
ｉｎｄ関数である。
【００４１】１）ユーザアプリからソケット３番をポー
ト番号１０００、ＩＰアドレス０．０．０．０でバイン
ドする。一般的に受動的コネクションの確立の場合、ど
のノードから接続要求があるかわからないので、ＩＰア
ドレスを０．０．０．０でバインドする。
【００４２】２）アプリから指定のあるソケットはコネ
クション管理テーブルのインデックス番号である。
【００４３】３）Ａ系用ソケットを取り出し、ユーザア
プリから指定のあったポート番号１０００、ＩＰアドレ
ス０．０．０．０とバインドする。
【００４４】４）バインドしたポート番号、ＩＰアドレ
スを格納する。
【００４５】＜接続の受け入れ許可処理Ｚ３＞図１０
は、接続の受け入れ許可の処理の流れを説明するための
図であり、次の１）〜３）の手順で行われる。すなわ
ち、ユーザアプリから指定のあったソケットがリモート
から接続要求を受け入れる用意があることを宣言する。
この場合、使用するソケットライブラリは、ｌｉｓｔｅ
ｎ関数である。この処理は、コネクションの受動的接続
を行うときに必要な処理である。この処理を行った後、
ユーザアプリは、受動的コネクション接続処理を行うの
が一般的な処理である。従って、接続の受け入れ許可処
理で要求のあったソケットを代表ソケットにする。
【００４６】１）アプリから指定のあるソケットは、コ
ネクション管理テーブルのインデックス番号である。
【００４７】２）Ａ系用ソケットを取り出し、ユーザア
プリから指定のあったパラメータでｌｉｓｔｅｎを発行
する。
【００４８】３）ソケットの状態を代表ソケットとす
る。
【００４９】＜コネクションの確立＞図１１〜図１８
は、コネクションの確立との流れと、コネクション管理
テーブルの状態を示すもので、コネクション確立後は、
後述するコネクション確立後の処理を、１）〜８）の手
順で行われる。
【００５０】＜コネクションの確立処理Ｚ４＞図１１
は、Ａ系コネクションの確立要求を説明するための図で
あり、図１１では１）の手順が行われる。
【００５１】１）ユーザアプリからコネクションの確立
要求があると、まずＡ系の接続要求を行う。サーバ側で
は代表ソケットで待ち合わせをしているものとする。
【００５２】図１２は、Ａ系コネクションの確立を説明
するための図であり、図１２では２）の手順が行われ
る。
【００５３】２）サーバ側で要求が受け付けられるコネ
クションが確立できたとき、新たなソケットが割り振ら
れる。
【００５４】図１３は、Ａ系コネクションの情報の読み
出しを説明するための図であり、図１３では３）の手順
が行われる。
【００５５】３）コネクションが確立されたら相手ＩＰ
アドレス、自分ポート番号、相手ポート番号を読み出し
コクネション管理テーブルに格納する。
【００５６】図１４は、Ｂ系ソケットの作成を説明する
ための図であり、図１４では４）の手順を行う。
【００５７】４）Ｂ系のコネクション確立するためにク
ライアント側ではＢ系用のソケットを作成し、Ａ系のポ
ート番号とバインドする。
【００５８】図１５は、Ｂ系コネクションの確立要求を
説明するための図であり、図１５では、５）の手順を行
う。
【００５９】５）Ｂ系コネクションの確立要求を行う。
Ａ系と同様に代表ソケットに対して要求を行う。Ｂ系の
ＩＰアドレスはＡ系のアドレス＋８０ｈとする。
【００６０】図１６は、Ｂ系コネクションの確立要求を
説明するための図であり、図１６では、６）の手順を行
う。
【００６１】６）サーバ側で要求が受け付けられ、コネ
クションが確立できた時、新たなソケットが割り振られ
る。
【００６２】図１７は、Ｂ系コネクションの情報の読み
出しを説明するための図であり、図１７では７）の手順
が行われる。
【００６３】７）コネクションが確立されたら相手ＩＰ
アドレス、自分ポート番号、相手ポート番号を読み出
す。サーバ側では相手ＩＰアドレスと相手ポート番号で
コネクション管理テーブルを検索し、ペアのソケットが
あるかどうかをチェックする。図１８は、Ｂ系コネクシ
ョンの情報の格納を説明するための図であり、図１８で
は、８）の手順を行う。
【００６４】８）読み出した相手ＩＰアドレス、自分ポ
ート番号、相手ポート番号をコネクション管理テーブル
へ格納する。サーバ側でペアを検索した結果、ペアがな
ければ、新規登録し、あればそこへ追加する。
【００６５】＜送信処理（ＴＣＰ）Ｚ５＞次に、送信処
理（ＴＣＰ）、すなわちストリーム型（ＴＣＰ）ソケッ
トの送信処理を説明する。
【００６６】１１）送信要求時、差分データがあれば、
まずそれを送信する。
【００６７】１２）送信処理ではＡ系、Ｂ系に同じデー
タを送出する。送信が正常に終了したら、図１４のコネ
クション管理テーブルのＡ系送信カウンタ、Ｂ系送信カ
ウンタに今回送信できたサイズを加えると同時に、Ａ系
送信カウンタ、Ｂ系送信カウンタの多い方の値を送信カ
ウンタに格納をする。
【００６８】１３）ユーザアプリへは、ＴＣＰへ受け付
けられたサイズを戻すが、今回送信できた多い方の系の
サイズを戻す。
【００６９】１４）もし、両系に送信した結果、ＴＣＰ
へ受け付けられたサイズが異なった場合、少なかった系
は多い系との差分をコネクション管理テーブルの送信差
分保存バッファへコピーする。この差分のことを送信差
分データと呼ぶ。
【００７０】１５）送信差分データが１メガバイトを越
えた場合は、差分のある系のコネクションを開路（切
断）する。
【００７１】１６）送信差分保存バッファにあるデータ
を送信するタイミングは、次回の送信時か、後述する多
重待ちで差分のある系が書き込み許可（送信可能）にな
ったときである。
【００７２】以上が送信処理の概要である。送信要求
時、差分データがあるかないかで処理が変わってくる。
差分データがある場合と、差分データがない場合の処理
について、図１９〜図２３を参照して説明する。
【００７３】図１９は、送信要求時、差分データがない
場合の処理１を説明するための図である。
【００７４】図１９（ａ）は、差分データがない時（Ａ
系送信カウンタSendーA、Ｂ系送信カウンタSendーB、送信
カウンタSendの３つの値が１０２４バイトと等しい場合
ので、差分データがないといえる）のコネクション管理
テーブルを示している。
【００７５】図１９（ｂ）は、図１９（ａ）の状態でユ
ーザアプリから２５６バイトの送信要求があった場合の
データの流れを示す図である。図１９（ｃ）は、送信後
のコネクション管理テーブルを示すもので、SendーA、Se
ndーB、Sendの値が共に１２８０バイトに変化している。
【００７６】図２０は、送信要求時、差分データがない
場合の処理２を説明するための図である。
【００７７】前述のようにＡ系、Ｂ系に送信した結果、
ＴＣＰからの戻り値（送信できたサイズ）が等しい時
は、差分は発生しない。図２０（ａ）はこの場合のコネ
クション管理テーブルを示している。図２０（ｂ）は、
この状態でユーザアプリから２５６バイトの送信があっ
た場合の信号の流れを示している。図２０（ｃ）は、該
送信後のコネクション管理テーブルを示すもので、この
場合にはSendの値が変化する。
【００７８】図２１は、差分データがある場合の送信処
理１を説明するための図である。
【００７９】差分データがある時にユーザアプリから２
５６バイトの送信要求があった場合、ここでは例として
Ｂ系に５１２バイトの差分データがあったとする。図２
１（ａ）は、Ｂ系に５１２バイト差分データがある場合
のコネクション管理テーブルを示している。ただし、Ａ
系の送信サイズを１０２４バイトとした場合である。
【００８０】このようにＢ系に差分データがあるという
ことは、Ａ系送信カウンタよりＢ系送信カウンタの値の
方が小さいことからわかる。差分のサイズが５１２バイ
トであることは、Ａ系送信カウンタとＢ系送信カウンタ
の引き算でわかる。
【００８１】１） この場合、ユーザアプリからのデー
タ（２５６バイト）を送信する前に、まず差分データを
送信する。図２１（ｂ）はこの場合の信号の流れを示す
図である。
【００８２】図２２は、差分データがない場合の送信処
理を説明するための図である。
【００８３】２） １）の結果、Ｂ系の差分データがな
くなった場合は、ユーザアプリから要求のあった２５６
バイトを両系に送信する。
【００８４】図２３は、差分データがある場合の送信処
理２を説明するための図である。
【００８５】３） １）の結果Ｂ系の差分データがまだ
ある場合、差分データがある時にユーザアプリから要求
のあった２５６バイトは次のようにする。すなわち、Ａ
系はそのまま送信し、Ｂ系は差分データにキューイング
（Ｑｕｅｕｅｉｎｇ）ｑする（但しＡ系で送信できたサ
イズ）。
【００８６】１）の結果差分データの残りが２００バイ
トで、今回Ａ系に２５６バイトで送信できた場合の信号
の流れを示している。
【００８７】＜受信処理（ＴＣＰ）Ｚ６＞次に、受信処
理（ＴＣＰ）、すなわち、ストリーム型（ＴＣＰ）ソケ
ットの受信処理について説明する。
【００８８】２１）Ａ系−＞Ｂ系の順でデータを受信す
る。
【００８９】２２）差分データのある系の受信処理は、
最初に差分データのみを受信する。差分データがなくな
ったら、次に新規データの受信を行う。
【００９０】２３）差分データのない系の受信処理は、
新規データの受信のみを行う。
【００９１】２４）データを受信したら、コネクション
管理テーブルのｎ系受信カウンタと、受信カウンタをカ
ウントアップする。ただし、差分データのみ受信した場
合は、受信カウンタはカウントアップさせない。
【００９２】２５）受信した差分データは破棄する。新
規に受信したデータは、ユーザアプリに通知する。
【００９３】２６）差分データを受信する場合は、受信
用ダミーバッファを使用する。新規データを受信する場
合は、ユーザアプリから指定のあった受信バッファを使
用する。
【００９４】なお、ここでは新規データとは破棄しない
データのことを指す。差分データとは片系で受信してい
るが、もう一方の片系では受信していないデータのこと
を指す。
【００９５】以下、以上述べた受信処理について図２４
〜図２６を参照して説明する。
【００９６】図２４は、差分がないときの受信処理を示
す図である。
【００９７】ａ） 図２４（ａ）は受信サイズに差分が
ないときに、両系で１２８バイトのデータを受信した場
合で、Ａ系、Ｂ系と１０２４バイト受信している時のコ
ネクション管理テーブルを示している。
【００９８】１） 図２４（ｂ）は、差分がないときの
受信処理を示す図である。Ａ系−＞Ｂ系の順でデータを
読み出す。Ａ系は新規データとなるので、ユーザアプリ
から渡される受信バッファを使用してＴＣＰから受信す
る。Ｂ系はＡ系受信後は差分データとなるので、受信用
ダミーバッファを使用してＴＣＰから受信する。
【００９９】図２４（ｃ）はデータ受信後におけるコネ
クション管理テーブルの状態を示している。
【０１００】図２５は差分があるときの受信処理を説明
するための図である。
【０１０１】ｂ） 図２５（ａ）は受信に差分があると
きに両系で２５６バイトのデータを受信した場合で、こ
こでは例としてＡ系に１２８バイトの差分があったとす
る。そして、Ａ系に１２８バイトの差分データがある場
合の、コネクション管理テーブルの状態を示している。
ただし、Ｂ系の受信サイズを１０２４バイトとする。
【０１０２】Ａ系に差分データがあるということは、図
２５（ｂ）において、受信カウント値［図２５（ａ）の
Ｒｅｃｖに相当］よりＡ系受信カウンタ値の方が小さい
ことより分かる。差分のサイズが１２８バイトであるこ
とは、受信カウンタの値とＡ系受信カウンタの値の引き
算で分かる。
【０１０３】図２５（ｂ）において、次のような順序で
処理を行う。
【０１０４】４１）Ａ系−＞Ｂ系の順でデータを読み出
す。Ａ系は差分のある系なので、まず差分サイズ分を受
信用ダミーバッファを使用してＴＣＰから受信する。
【０１０５】４２）差分データ受信後、新規データの受
信を行う。新規データは、ユーザアプリから渡される受
信バッファを使用してＴＣＰから受信する。
【０１０６】４３）Ａ系受信後、Ｂ系は差分データとな
るので、受信用ダミーバッファを使用してＴＣＰから受
信する。
【０１０７】図２５（ｃ）は、４１）においてＡ系受信
後のコネクション管理テーブルの状態を示している。図
２５（ｄ）は、４２）においてＢ系受信後のコネクショ
ン管理テーブルの状態を示している。
【０１０８】ここで、差分ならびに差分の算出方法は、
次の通りである。
【０１０９】５１）どちらの系に差分があるかの判定方
法 ａ）受信カウンタとＡ系受信カウンタが同じであれば、
Ａ系受信カウンタ＞Ｂ系受信カウンタとなり、Ｂ系に差
分がある。
【０１１０】ｂ）受信カウンタとＢ系受信カウンタが同
じであれば、Ａ系受信カウンタ＜Ｂ系受信カウンタとな
り、Ａ系に差分がある。
【０１１１】ｃ）受信カウンタとＡ系受信カウンタとＢ
系受信カウンタが同じであれば、Ａ系受信カウンタ＝Ｂ
系受信カウンタとなり、差分はない。
【０１１２】５２）差分の算出方法 ａ）（大きい系のカウンタの値＞小さい系のカウンタの
値）の場合 差分＝大きい系のカウンタ−小さい系のカウンタ ｂ）（大きい系のカウンタの値＜小さい系のカウンタの
値）の場合 差分＝２の３１乗−（小さい系のカウンタの値−大きい
系のカウンタの値） ＜コネクションの片系の切断処理Ｚ７＞次に、コネクシ
ョンの片系の切断処理について、図２６を参照して説明
する。すなわち、二重化処理では、両系コネクション接
続中に片系異常を検出した場合、そのコネクションを切
断する処理を行う。
【０１１３】ここで、「片系異常」とは次の２項目を指
している。
【０１１４】ｘ）送信データの差分が１メガバイト以上
となった時 ｙ）送信要求時のエラーでコネクションの切断を検出し
た時（既に相手系が切断している場合） 片系コネクションの切断を行った後、コネクション管理
テーブルのフィールドを初期化する。図２６は片系コネ
クション切断時のコネクション管理テーブルを示すもの
で、図２６（ａ）は両系正常時を示し、また図２６
（ｂ）は片系切断時を示している。
【０１１５】＜コネクションの再確立処理Ｚ８＞次に、
図２７を参照して、送信要求時にコネクションの再確立
要求について説明する。図２７（ａ）は送信時にコネク
ションの再確立を行う際の動作を示す図である。いま、
片系のコネクションが切断されている場合、二重化処理
では切断されている系についてコネクションの再確立を
行う。再確立を行うタイミングは、ユーザからの送信
（ＴＣＰ）または受信（ＴＣＰ）要求時とする。
【０１１６】送信または受信要求時コネクション再確立
の処理として以下のことを行う。
【０１１７】６１）Ａ／Ｂ系交信ステータス内部処理ス
テータスをチェックし、異常の場合には再確立処理は行
わず、正常時のみ行う。
【０１１８】６２）コネクション管理テーブルより、ソ
ケットが「サーバ側」の場合は再確立処理は行わない。
クライアント側（コネクションを確立した側）からのみ
行う。
【０１１９】６３）コネクション管理テーブルをチェッ
クし、コネクション確立要求が行える状態ならば、ソケ
ットを取得し、正常系の自ポート番号とバインドし、コ
ネクション確立要求を行う。コネクションの確立要求が
行える状態の診断は、図２７（ｂ）の通りである。な
お、この時、正常系の方は、送信または受信処理を行
う。
【０１２０】図２７（ｂ）は、コネクション管理テーブ
ルより、コネクションの再確立が行える状態かどうかの
判断結果を示す図である。図中○は値が設定されている
ことを示し、×は未使用（−１が入っている）状態を示
し、−は何の値でもよいことを示している。
【０１２１】図２７（ｂ）において、の時は、コネク
ションの再確立要求を発行する。の時は、コネクショ
ンの確立要求に対する接続の確認を行う。，の時は
何もしない。
【０１２２】＜コネクション確立後の処理Ｚ９＞次に、
図２８〜図３２によりコネクション確立後の処理につい
て説明する。
【０１２３】新たに、コネクションが接続された時（再
確立も含む）、二重化処理ではコネクションを確立した
系とは反対の系（単に逆系と称する）の送信サイズをコ
ネクションが接続されている相手に伝える処理を行う。
【０１２４】この処理を行うのは、コネクションが接続
されたことを認識した時に行う。また、受信側では、コ
ネクションの確立後１回目の受信については、ヘッダの
み読み出す。そして、ヘッダに入っている送信サイズ分
のデータを逆系が受信するまで受信処理は行わない。
【０１２５】以上のことを図２８〜図３２を用いて説明
する。図２８は、コネクション確立後の送信処理を説明
するための図で、図２８（ａ），（ｂ）はＢ系のコネク
ションが確立（再確立）しない場合と、コネクションが
確立（再確立）した場合のコネクション管理テーブルを
示す図であり、図２８（ｃ）はコネクション確立後の送
信処理を示す図である。
【０１２６】図２９は、コネクション確立後の受信処理
を説明するための図で、（ａ）はＢ系のコネクションが
確立（再確立）した場合のコネクション管理テーブルを
示す図であり、（ｂ）はコネクション確立後のヘッダ受
信を示す図である。
【０１２７】図２９に示すように、受信後はヘッダから
相手送信サイズを読み出し、コネクション管理テーブル
に格納し、受信は受信用ダミーバッファを使用してＴＣ
Ｐから受信する。
【０１２８】図３０は、ヘッダ受信後、相手系の受信の
待ち合わせ処理を説明するための図で、図３０（ａ）は
その時のコネクション管理テーブルを示す図であり、図
３０（ｂ）はコネクション確立後のヘッダ受信を示す図
である。ヘッダを受信したら、そこに入っている相手系
の送信サイズ分のデータを受信するまで、受信を待ち合
わせる。この例だと、Ａ系が１２８０バイト受信するま
でＢ系は受信処理は行わない。ただし、ヘッダに入って
いるサイズが−１の場合は待ち合わせは行わない。
【０１２９】図３１は通常の受信処理再開を説明するた
めの図であり、図３１（ａ）はその時のコネクション管
理テーブルを示す図であり、図３１（ｂ）はコネクショ
ン確立後のヘッダ受信を示す図である。ヘッダに入って
いる相手系の送信サイズ分のデータを受信した後は通常
の受信処理を行う。この例だと、Ａ系が１２８０バイト
受信したら通常の受信処理となる。
【０１３０】図３２は、待ち合わせ解除の判定方法を説
明するための図で、図３２（ａ）は両カウンタの大小関
係のパターンを示す図であり、図３２（ｂ）は待ち合わ
せ解除の判定方法を説明するための図である。図３２
（ａ）に示すように、逆系の待ち合わせ解除の判定方法
は、ヘッダに入っている相手の送信サイズと逆系の受信
カウンタの大小関係によって判定する。これと共に、３
２ビットのカウンタ（ただしそのうち３１ビット使用）
なので、２ギガバイトまで達すると、０に戻る。そのた
め、カウンタが１周したかしていないかで判定方法が異
なってくる。両カウンタの大小関係は図３２（ａ）に示
す５つのパターンがある。
【０１３１】図３２（ｂ）は待ち合わせ解除の判定方法
を説明するための図であり、両カウンタの差とはｎＭバ
イト以上の差があった場合を「大」、なかった場合を
「小」としている。つまり、「大」の時はどちらかのカ
ウンタが１周している場合で、「小」の時はどちらのカ
ウンタも１周していない場合である。
【０１３２】次に、本発明の伝送路二重化処理方式の概
略の作用について説明する。
【０１３３】１）前述した＜コネクション確立処理＞で
説明したように、コネクションを確立する側で、２つの
確立するコネクションで使用するポート番号を同じもの
を使用する。
【０１３４】２）両伝送路を使用し、２つのコネクショ
ンを確立する。
【０１３５】３）コネクションが確立されたら、前述し
た＜コネクション確立後の処理＞で説明した各コネクシ
ョン毎に反対系のコネクションで現在受信しているデー
タバイト数を送信する。ここで、送信するデータは、ヘ
ッダデータと称する。
【０１３６】４）前述した＜送信処理＞で説明したよう
に、両方の伝送路のコネクションが確立されている場合
の送信は同一データを両方のコネクションに対して送信
する。
【０１３７】５）両方の伝送路に送信した結果、片方の
系の送信が失敗した場合は、そのデータをバッファに保
存する。以降、このバッファを差分バッファ、差分バッ
ファに格納したデータを送信差分データと称する。次回
の送信要求時、この差分データを送信する。
【０１３８】６）前述した＜受信処理＞で説明したよう
に、受信側では、先着優先でデータをアプリケーション
に通知する。データ受信時、コネクション単位で受信デ
ータサイズを管理するカウンタを設け、カウントアップ
する。
【０１３９】７）先着優先でデータを破棄するか否かの
判定は、６）で使用したカウンタを基に行う。このこと
について、具体例を説明する。現在、片方の伝送路（伝
送路Ａと称する）の受信カウンタが１００バイト、他方
の伝送路（伝送路Ｂと称する）の受信カウンタが５０バ
イトだったとする。この時、伝送路Ｂで１００バイトの
データを受信した場合、前半の５０バイトはすでに伝送
路Ａで受信通知を行っているデータなので破棄し、後半
の５０バイトのデータは新規に受信したデータなので、
アプリケーションへ通知する。このように、まず反対系
との差分を受信し、そのデータは破棄する。反対系と比
べて多く受信したデータをアプリケーションへ通知す
る。
【０１４０】８）５）で格納する送信差分データが、差
分バッファの容量を越える場合、その差分バッファを保
持しているコネクションの伝送路は異常と判断し、コネ
クションを切断する。
【０１４１】９）前述した＜コネクションの片系切断処
理＞で説明したように、８）のように、片方の伝送路の
異常を検出し、内部でコネクションの切断を行った場
合、定期的にコネクションの再確立要求を行う。伝送路
が正常に復帰し、コネクションが確立された場合、再び
両方の伝送路を使用して送受信を行う。
【０１４２】１０）前述した＜コネクションの再確立後
の処理＞で説明したように、コネクションの再確立時、
３）で説明したヘッダデータを受信する。反対の伝送路
（正常に使用していた系）がそこに入っている受信サイ
ズ分のデータを受信するまで、再確立したコネクション
は使用しない。ヘッダに入っている受信サイズ分のデー
タを反対系が受信し始めて再確立したコネクションを使
用する。これは、ストリームデータが壊れるのを防ぐた
めである。
【０１４３】以上述べた実施形態によれば、伝送路二重
化処理方式において、片方の伝送路で異常が発生した場
合も、ＴＣＰのリトライ終了を待たずして（伝送を停止
することなく）、継続することが可能になる。
【０１４４】
【発明の効果】本発明によれば、伝送路二重化処理方式
において、片方の伝送路で異常が発生した場合も、伝送
を停止することなく、継続することが可能になる。
【図面の簡単な説明】
【図１】本発明の伝送路二重化処理方式のハード構成を
示す図。
【図２】本発明の伝送路二重化処理方式の信号の流れを
説明するための図。
【図３】本発明の実施形態の作用効果を説明するための
図。
【図４】本発明の実施形態で使用する管理情報のデータ
構成を示す図。
【図５】図４の用語の意味を説明するための図。
【図６】図４の送信差分バッファを説明するための図。
【図７】図４のコネクション管理テーブルに使用する略
語の説明図。
【図８】本発明の実施形態のソケット作成処理を説明す
るための図。
【図９】本発明の実施形態のソケットへの名前付け処理
を説明するための図。
【図１０】本発明の実施形態の接続の受け入れ許可の処
理の流れを説明するための図。
【図１１】本発明の実施形態のコネクション確立の流れ
と状態を説明するための図。
【図１２】本発明の実施形態のコネクション確立の流れ
と状態を説明するための図。
【図１３】本発明の実施形態のコネクション確立の流れ
と状態を説明するための図。
【図１４】本発明の実施形態のコネクション確立の流れ
と状態を説明するための図。
【図１５】本発明の実施形態のコネクション確立の流れ
と状態を説明するための図。
【図１６】本発明の実施形態のコネクション確立の流れ
と状態を説明するための図。
【図１７】本発明の実施形態のコネクション確立の流れ
と状態を説明するための図。
【図１８】本発明の実施形態のコネクション確立の流れ
と状態を説明するための図。
【図１９】本発明の実施形態の送信処理を説明するため
の図。
【図２０】本発明の実施形態の送信処理を説明するため
の図。
【図２１】本発明の実施形態の送信処理を説明するため
の図。
【図２２】本発明の実施形態の送信処理を説明するため
の図。
【図２３】本発明の実施形態の送信処理を説明するため
の図。
【図２４】本発明の実施形態の受信処理を説明するため
の図。
【図２５】本発明の実施形態の受信処理を説明するため
の図。
【図２６】本発明の実施形態のコネクションの片系切断
処理を説明するための図。
【図２７】本発明の実施形態のコネクションの片系切断
処理を説明するための図。
【図２８】本発明の実施形態のコネクション確立後の処
理を説明するための図。
【図２９】本発明の実施形態のコネクション確立後の処
理を説明するための図。
【図３０】本発明の実施形態のコネクション確立後の処
理を説明するための図。
【図３１】本発明の実施形態のコネクション確立後の処
理を説明するための図。
【図３２】本発明の実施形態のコネクション確立後の処
理を説明するための図。
【図３３】従来の伝送路二重化処理方式の信号の流れを
説明するための図。
【符号の説明】
ＢＡ，ＢＢ…伝送路 ＰＣ１〜ＰＣ３…パソコン Ｓ１，Ｓ２，Ｓ３…ソフトウェア格納部 Ｄ１，Ｄ２，Ｄ３…デバイスドライバ Ｅ１〜Ｅ６…イーサネットカード挿入部 １１，１２…アプリケーション ３１，３２…ＴＣＰプロトコル ４１，４２…ＩＰプロトコル ５１，５２…二重化処理部

Claims (6)

    【特許請求の範囲】
  1. 【請求項１】 第１、第２の伝送路によって二重化され
    た二重化伝送路を、複数の端末機器間に配設し、ＴＣＰ
    プロトコルを用いてストリーム単位列のデータを、前記
    端末機器間に送受信可能にした伝送路二重化処理方式に
    おいて、 前記各伝送路にそれぞれ前記ストリーム単位列のデータ
    を同時に送信する送信送信手段と、 前記送信手段により送信されたデータのうち先に到着し
    たデータのみを生かす受信手段と、 前記両伝送路のいずれかに異常が発生したことを検出す
    る異常検出手段と、 前記異常検出手段により伝送路の異常発生が検出された
    とき、該異常発生した伝送路を開路し、残りの正常な伝
    送路により送信受信を行う伝送路切換手段と、 を具備したことを特徴とする伝送路二重化処理方式。
  2. 【請求項２】 前記異常検出手段により伝送路の異常発
    生が検出されたとき、該異常発生直前の前記データを保
    存する読み出し可能なデータ保存手段を、 さらに具備したことを特徴とする請求項１記載の伝送路
    二重化処理方式。
  3. 【請求項３】 前記受信手段は、データ受信時、前記両
    伝送路単位でかつ前記各伝送路毎に受信データサイズを
    計測すると共に、該計測値の差分を求め、最初に該差分
    データのみを受信し、該計測値の差分がなくなったら次
    に新規データを受信することを特徴とする請求項１記載
    の伝送路二重化処理方式。
  4. 【請求項４】 前記異常検出手段は、前記データ受信
    時、前記両伝送路単位でかつ前記各伝送路毎に受信デー
    タサイズを計測すると共に、該計測値の差分を求め、該
    差分データが規定値を越えたとき、該差分を保持してい
    る前記伝送路は異常と判断するものである請求項１記載
    の伝送路二重化処理方式。
  5. 【請求項５】 前記異常検出手段が伝送路の異常を検出
    し、内部で前記両伝送路の開路を行った場合、定期的に
    前記両伝送路の再確立要求を行い、伝送路が正常に復帰
    し、前記両伝送路が確立された場合、再び該両伝送路を
    使用して送受信を行うことを特徴とする請求項１記載の
    伝送路二重化処理方式。
  6. 【請求項６】 前記両伝送路の再確立時、ヘッダデータ
    を受信し、正常の伝送路の受信手段に入っている受信サ
    イズ分のデータを受信するまで、該再確立した伝送路は
    使用せず、ヘッダに入っている受信サイズ分のデータを
    反対系が受信してはじめて、再確立した前記両伝送路を
    使用することを特徴とする請求項５記載の伝送路二重化
    処理方式。
JP25165897A 1997-09-17 1997-09-17 伝送路二重化処理方式 Expired - Lifetime JP3403021B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP25165897A JP3403021B2 (ja) 1997-09-17 1997-09-17 伝送路二重化処理方式
GB9820101A GB2332346B (en) 1997-09-17 1998-09-15 Transmission line duplexing processing method and apparatus
AU85164/98A AU718251B2 (en) 1997-09-17 1998-09-16 Transmission line duplexing processing method and apparatus thereof, and recording medium for recording its processing procedure
US09/154,043 US6396806B1 (en) 1997-09-17 1998-09-16 Transmission line duplexing processing method and apparatus thereof, and recording medium for recording its processing procedure

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP25165897A JP3403021B2 (ja) 1997-09-17 1997-09-17 伝送路二重化処理方式

Publications (2)

Publication Number Publication Date
JPH1198161A true JPH1198161A (ja) 1999-04-09
JP3403021B2 JP3403021B2 (ja) 2003-05-06

Family

ID=17226100

Family Applications (1)

Application Number Title Priority Date Filing Date
JP25165897A Expired - Lifetime JP3403021B2 (ja) 1997-09-17 1997-09-17 伝送路二重化処理方式

Country Status (4)

Country Link
US (1) US6396806B1 (ja)
JP (1) JP3403021B2 (ja)
AU (1) AU718251B2 (ja)
GB (1) GB2332346B (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017134783A1 (ja) * 2016-02-03 2017-08-10 三菱電機株式会社 制御システム及び制御ユニット

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7013305B2 (en) 2001-10-01 2006-03-14 International Business Machines Corporation Managing the state of coupling facility structures, detecting by one or more systems coupled to the coupling facility, the suspended state of the duplexed command, detecting being independent of message exchange
EP1538812A1 (en) * 2003-12-01 2005-06-08 Alcatel System for redundantly exchanging information parts
CN108895195B (zh) * 2018-07-23 2019-11-26 中国矿业大学 一种气动调节阀智能故障诊断系统的控制方法
CN109683059B (zh) * 2018-12-30 2021-06-22 国网北京市电力公司 确定线损异常的方法及装置、存储介质、处理器

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4931922A (en) * 1981-10-01 1990-06-05 Stratus Computer, Inc. Method and apparatus for monitoring peripheral device communications
JPS62105550A (ja) 1985-11-01 1987-05-16 Fujitsu Ltd 回線切換方式
JP2892351B2 (ja) 1987-12-29 1999-05-17 富士通株式会社 ソースプログラム変換装置
JPH02250538A (ja) 1989-03-24 1990-10-08 Shinko Electric Co Ltd 多重伝送網通信システム
US5323144A (en) * 1989-04-19 1994-06-21 Hitachi Cable Limited Duplexed bus type network with failure changeover
JPH02308638A (ja) 1989-05-24 1990-12-21 Toshiba Corp 二重化伝送路の診断装置
JP2732674B2 (ja) * 1989-07-10 1998-03-30 株式会社東芝 データ伝送装置
JPH04275735A (ja) * 1991-03-04 1992-10-01 Fujitsu Ltd ２重化通信システム
JPH05235803A (ja) * 1992-02-25 1993-09-10 Nec Eng Ltd 伝送路終端回路
JPH0621925A (ja) 1992-07-02 1994-01-28 Hitachi Ltd 多重化伝送路通信制御方式
JPH0629961A (ja) 1992-07-13 1994-02-04 Yokogawa Electric Corp 冗長化データ通信システム
JPH08223185A (ja) * 1995-02-08 1996-08-30 Toshiba Corp 二重化伝送路切換方式
JPH09130408A (ja) 1995-11-01 1997-05-16 Hitachi Ltd ネットワークインタフェース装置
US5867689A (en) * 1996-05-01 1999-02-02 Mci Communications Corporation Method and apparatus for emulating a digital cross-connect switch network using a flexible topology to test MCS network management

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017134783A1 (ja) * 2016-02-03 2017-08-10 三菱電機株式会社 制御システム及び制御ユニット
JPWO2017134783A1 (ja) * 2016-02-03 2018-03-15 三菱電機株式会社 制御システム及び制御ユニット
US10845788B2 (en) 2016-02-03 2020-11-24 Mitsubishi Electric Corporatioon Control system and control unit

Also Published As

Publication number Publication date
JP3403021B2 (ja) 2003-05-06
AU8516498A (en) 1999-04-01
GB9820101D0 (en) 1998-11-11
US6396806B1 (en) 2002-05-28
GB2332346B (en) 2000-05-10
GB2332346A (en) 1999-06-16
AU718251B2 (en) 2000-04-13

Similar Documents

Publication Publication Date Title
US8176187B2 (en) Method, system, and program for enabling communication between nodes
US5195181A (en) Message processing system having separate message receiving and transmitting processors with message processing being distributed between the separate processors
US9794196B2 (en) Application-controlled network packet classification
US6724762B2 (en) System and method for implementing multi-pathing data transfers in a system area network
US7640364B2 (en) Port aggregation for network connections that are offloaded to network interface devices
US7966380B2 (en) Method, system, and program for forwarding messages between nodes
US7787383B2 (en) Method and apparatus for monitoring a connection in a peer-to-peer network
JP3857317B2 (ja) 自動交渉の進捗モニタ
US7447198B1 (en) Link trunking and measuring link latency in fibre channel fabric
MXPA04010437A (es) Sistema, metodo y producto para administrar transferencias de datos en una red.
US20040260841A1 (en) Method, apparatus, and system for internet protocol communication over intelligent platform management bus
KR20020060623A (ko) 데이터를 전송하기 위한 신뢰성 있는 프로토콜을 제공하는방법 및 장치
JP3608905B2 (ja) データ通信システム及びデータ通信方法
JP3403021B2 (ja) 伝送路二重化処理方式
JPH02241150A (ja) データ通信方法
JP5148441B2 (ja) 計算機間相互結合網における通信経路の冗長化と切り替え方法、この方法を実現するサーバ装置、そのサーバモジュール、および、そのプログラム
Poulton Packet Switching and x. 25 networks
US7925758B1 (en) Fibre accelerated pipe data transport
Device SAM-2 Section 4.3 The SCSI client-server model
JP2654524B2 (ja) Ｌａｎの接続ポート切り替え方式
Recommendation Session Service Definition for Open Systems Interconnection for CCITT Applications
JPH05122277A (ja) ロジカルリンクコントロールタイプ３処理方式
Lai et al. Communication protocol
JPS6366103B2 (ja)
Hafner et al. IPS Julian Satran Internet Draft Daniel Smith Document: draft-ietf-ips-iSCSI-08a. txt Kalman Meth Category: standards-track Ofer Biran

Legal Events

Date Code Title Description
FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080229

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090228

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100228

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100228

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110228

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120229

Year of fee payment: 9

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120229

Year of fee payment: 9

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130228

Year of fee payment: 10

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140228

Year of fee payment: 11

EXPY Cancellation because of completion of term