JPH10336242A - データ通信システム - Google Patents

Abstract

(57)【要約】 【課題】 回線断から復旧した後にアプリケーションに
負荷をかけることなくアプリケーション間通信の再開を
自動的に行う。 【解決手段】 通信処理部３３は、通信を行う相互のア
プリケーションの組にセッションＩＤを割り当て各アプ
リケーションに通知し、各アプリケーション識別情報と
共に通信管理テーブル４０で管理する。また、セッショ
ンＩＤが付加された送信データを受け取ると、通信管理
テーブル４０に基づいてデータを渡すべきアプリケーシ
ョンを特定する。通信処理部１３，３３は、データ送信
時に送信データを送信データ情報保持部１４に保持し、
回線断後復旧後には保持したデータを再送する。また、
データ受信時に受信データをアプリケーションに渡すと
共に受信データ情報保持部３４に一時保持する。但し、
回線復旧後のデータ受信であれば、受信したデータと保
持したデータとを比較し、一致すれば受信データをアプ
リケーションへ渡さない。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データ通信システ
ム、特に通信回線を介したアプリケーション間通信の実
行中に通信回線が切断されたとき並びにその後復旧され
たときの処理に関する。

【０００２】

【従来の技術】図１１は、データ通信システムの一形態
として従来からあるクライアント・サーバシステムの一
例を示したシステム構成図である。図１１において、回
線制御部１，２は、クライアント３、サーバ４それぞれ
において所定の通信プロトコルに基づき通信回線５を介
しての通信処理を行うための手段である。アプリケーシ
ョン実行部６，７は、相互にデータ送受信を行うアプリ
ケーションを実行するための手段であり、実行中の各ア
プリケーションがデータ通信を行うことになる。このク
ライアント・サーバシステムにおいてＴＣＰ／ＩＰプロ
トコルを使用して通信を行う場合、各回線制御部１，２
は、通信相手先（サーバ４、クライアント３）との間の
ソケットをオープンして通信路を確立し、アプリケーシ
ョン間からデータの受け渡しを行う。

【０００３】ところで、無線回線や電話回線などの回線
品質や使用環境によっては、通信回線５がデータ通信中
に一時的に切れてしまう場合がある。回線断中のデータ
送信は、当然ながら正常に終了しないわけであるが、回
線制御部１，２は、このとき所定の通信プロトコルに従
った所定回数のデータの再送を行う。そして、データ再
送中に通信回線５が復旧した場合は、その再送処理によ
りデータ通信が正常に終了するので、各アプリケーショ
ンには正常終了のステータスが返されることになる。こ
れにより、一時的な回線断によっては、各アプリケーシ
ョンに何ら影響を与えずに処理を進めさせることができ
た。

【０００４】

【発明が解決しようとする課題】しかしながら、通信回
線が切断した場合、通信プロトコルレベルでの再送の試
行回数が所定数を越えてしまったりタイムアウトが発生
したりして、結果的に通信プロトコルレベルでは対応し
きれない場合がある。このとき、通信プロトコルは、通
信を行っていたクライアント、サーバ上の各アプリケー
ションに対して、通信エラーが発生したという旨のステ
ータスを返すことになる。このため、各アプリケーショ
ンでは、多くの場合、通信エラーの発生により何らかの
処理を行わなくてはならない。場合によっては、処理の
途中であってもその処理を強制的に終了させなければな
らない。特に、データ送信側においては、データ送信中
に回線断が発生すると、送信データは相手に届いたの
か、それとも通信相手先から発せられる受信確認応答の
受信が失敗したのかなどの切分けも困難であり、データ
の再送をすべきかどうかの判断が難しい。一方、データ
受信側のアプリケーションにとっては、再送により同じ
データを二度受信してしまう場合もあり得る。また、ア
プリケーションの内容によっては、処理を最初からやり
直さなければならないものや、一旦握ったリソースを放
さないことにより二度と通信を再開することができなく
なる場合もあった。

【０００５】このため、アプリケーションを開発する
際、このような様々な事態を想定して復旧処理や再送処
理のルーチンを作成しなければならず、アプリケーショ
ンの開発者に多大な負担をかけていた。

【０００６】また、通信回線が復旧したとき、サーバに
おいて複数のデータ受信アプリケーションが待機してい
た場合、データ送信アプリケーションは、どのデータ受
信アプリケーションと通信路を再形成して処理を再開す
ればよいのか一意に特定できない。このため、データ送
信アプリケーションは、やむを得ずデータ受信アプリケ
ーションを再起動して最初から処理をやり直すことにな
るが、この際、回線断前に行っていた処理結果を破棄し
なければならず効率的でない。場合によっては、どこま
で前回の処理結果を破棄すべきなのか特定できない場合
もあり得る。

【０００７】本発明は以上のような問題を解決するため
になされたものであり、その目的は、回線断から復旧し
た後にアプリケーション間通信の再開を自動的に行うデ
ータ通信システムを提供することにある。

【０００８】

【課題を解決するための手段】以上のような目的を達成
するために、第１の発明に係るデータ通信システムは、
通信回線を介してデータ通信を行うアプリケーションを
実行するアプリケーション実行手段と、所定の通信手順
に基づき回線の接続、切断、復旧処理及びその旨の通知
を行う回線制御手段とを備えた少なくとも２台のコンピ
ュータを有するデータ通信システムにおいて、第１のコ
ンピュータは、前記通信回線を介して相互にデータ通信
を行う相互のアプリケーションの組を識別するための組
識別情報を前記アプリケーションの組に割り当てる組識
別情報管理手段と、組識別情報に各アプリケーションを
特定しうるアプリケーション識別情報を対応させて記憶
する通信管理テーブルと、各アプリケーションに、当該
アプリケーションに割り当てられた組識別情報を通知す
る組識別情報通知手段と、送信するデータを保持するた
めの第１の送信データ保持手段と、内部で動作するアプ
リケーションから組識別情報が付加された送信データを
受け取ったとき、その組識別情報に基づき前記通信管理
テーブルを参照することによってデータ送信先となるア
プリケーションを特定し、前記送信データをその送信先
アプリケーションが動作する前記コンピュータへ送信す
るとともに前記送信データを組識別情報を付加したまま
前記第１の送信データ保持手段に書き込む第１の送信処
理手段と、前記通信回線を介して受信したデータに関す
る情報を保持するための第１の受信データ情報保持手段
と、前記通信回線を介して組識別情報が付加された受信
データを受け取ったとき、その組識別情報に基づき前記
通信管理テーブルを参照することによってデータの渡し
先となるアプリケーションを特定し、前記受信データを
そのアプリケーションに渡すとともに受信データに関す
る情報を前記第１の受信データ情報保持手段に書き込む
第１の受信処理手段とを有し、第１のコンピュータと通
信を行う少なくとも１台の第２のコンピュータは、送信
するデータを保持するための第２の送信データ保持手段
と、内部で動作するアプリケーションから組識別情報が
付加された送信データを、前記第１のコンピュータへ送
信すると共に前記第２の送信データ保持手段に書き込む
第２の送信処理手段と、前記通信回線を介して受信した
データに関する情報を保持するための第２の受信データ
情報保持手段と、前記通信回線を介して受信したデータ
を送信先となるアプリケーションに渡すと共に受信した
データに関する情報を前記第２の受信データ情報保持手
段に書き込む第２の受信処理手段とを有し、前記各送信
処理手段は、通信回線断後、通信回線の復旧を確認した
とき前記送信データ情報保持手段に保持した送信データ
を再送し、前記各受信処理手段は、通信回線復旧後にデ
ータを受信したとき、前記受信データ情報保持手段に保
持した受信したデータに関する情報に基づき、通信回線
復旧後に受信したデータがすでに受信済みであると判断
したときにはアプリケーションへのデータ渡し及び受信
データ情報の前記受信データ情報保持手段への書込みを
行わないようにしたものである。

【０００９】第２の発明に係るデータ通信システムは、
第１の発明において、前記第１のコンピュータは、サー
バコンピュータであり、前記第２のコンピュータは、前
記サーバコンピュータと前記通信回線を介してデータ通
信を相互に行う１乃至複数のクライアントコンピュータ
であるものとする。

【００１０】

【発明の実施の形態】以下、図面に基づいて、本発明の
好適な実施の形態について説明する。

【００１１】図１は、本発明に係るデータ通信システム
の一実施の形態を示した全体構成図である。本実施の形
態では、本発明に係るデータ通信システムを有線若しく
は無線の通信回線５を介して接続されたコンピュータ
（クライアント１０及びサーバ３０）で構成され、ＴＣ
Ｐ／ＩＰに基づきデータ通信を行うクライアント・サー
バシステムに適用した場合の例で説明する。なお、クラ
イアント１０及びサーバ３０は、一般的なコンピュータ
であり、データの送受信を双方向に行うことができる。
また、本実施の形態では、便宜上、１台のクライアント
１０のみを図示する。なお、本実施の形態では、本発明
に係る第１のコンピュータがサーバ３０であり、第２の
コンピュータがクライアント１０である。

【００１２】クライアント１０は、アプリケーション実
行部１１、回線制御部１２、通信処理部１３、送信デー
タ保持部１４及び受信データ情報保持部１５を有してお
り、更に通信処理部３３には、送信処理部１６と受信処
理部１７とが搭載されている。アプリケーション実行部
１１は、通信回線５を介してデータ通信を行うアプリケ
ーションを実行するアプリケーション実行手段である。
回線制御部１２は、回線制御手段として設けられ、所定
の通信手順に基づき回線の接続、切断、復旧処理等の回
線制御、通信制御を行い、更に回線断、復旧等が発生し
た旨の通知を行う。ＴＣＰ／ＩＰの通信プロトコルに基
づく通信を行う場合、サーバ３０との間のソケットをオ
ープンする。送信データ保持部１４は、第２の送信デー
タ保持手段として設けられ、送信処理部１６によるデー
タ送信時に送信するデータを保持するために設けられた
手段である。受信データ情報保持部１５は、第２の受信
データ情報保持手段として設けられ、通信回線５を介し
て受信したデータに関する情報を保持するための手段で
ある。送信処理部１６は、第２の送信処理手段として設
けられ、内部で動作するクライアントアプリケーション
から組識別情報が付加された送信データをサーバ３０へ
送信すると共に送信データ保持部１４に書き込む。受信
処理部１７は、第２の受信処理手段として設けられ、通
信回線５を介して受信したデータを送信先となるサーバ
アプリケーションに渡すと共に受信したデータに関する
情報を受信データ情報保持部１５に書き込むことで保持
する。通信処理部１３は、送信処理部１６と受信処理部
１７を搭載することで各機能を含むと共に一般的な通信
処理機能を有している。

【００１３】サーバ３０は、アプリケーション実行部３
１、回線制御部３２、通信処理部３３、送信データ保持
部３４、受信データ情報保持部３５及び通信管理テーブ
ル４０を有しており、更に通信処理部３３には、送信処
理部３６、受信処理部３７、組識別情報通知部３８及び
組識別情報管理部３９が搭載されている。アプリケーシ
ョン実行部１１は、通信回線５を介してデータ通信を行
うアプリケーションを実行するアプリケーション実行手
段であり、同時に複数の通信アプリケーションを実行す
ることができる。回線制御部１２は、回線制御手段とし
て設けられ、所定の通信手順に基づき回線の接続、切
断、復旧処理等の回線制御、通信制御を行い、更に回線
断、復旧等が発生した旨の通知を行う。ＴＣＰ／ＩＰの
通信プロトコルに基づく通信を行う場合、クライアント
１０との間のソケットをオープンする。

【００１４】送信データ保持部３４は、第１の送信デー
タ保持手段として設けられ、送信処理部３６によるデー
タ送信時に送信するデータを保持するために設けられた
手段である。受信データ情報保持部３５は、第１の受信
データ情報保持手段として設けられ、通信回線５を介し
て受信したデータに関する情報を保持するための手段で
ある。送信処理部３６は、第１の送信処理手段として設
けられ、内部で動作するサーバアプリケーションから組
識別情報が付加された送信データを受け取ると、その組
識別情報に基づき通信管理テーブル４０を参照すること
によってデータ送信先となるクライアントアプリケーシ
ョンを特定し、送信データをそのクライアントアプリケ
ーションが動作するクライアント１０へ送信する。ま
た、送信データを組識別情報を付加したまま送信データ
保持部３４に書き込むことで保持する。受信処理部３７
は、第１の受信処理手段として設けられ、通信回線５を
介して組識別情報が付加された受信データを受け取る
と、その組識別情報に基づき通信管理テーブル４０を参
照することによってデータの渡し先となるアプリケーシ
ョンを特定し、受信データをそのアプリケーションに渡
し、また、受信データに関する情報を受信データ情報保
持部３５に書き込む。組識別情報通知部３８は、組識別
情報通知手段として設けられ、通信を行うクライアント
アプリケーション及びサーバアプリケーションに、その
アプリケーションに割り当てられた組識別情報を通知す
る。組識別情報管理部３９は、組識別情報管理手段とし
て設けられ、通信回線５を介して相互にデータ通信を行
う相互のアプリケーションの組を識別するための組識別
情報を、そのアプリケーションの組に割り当てるなど、
通信路の形成、削除、回線の切断、復旧に伴い、通信管
理テーブル４０の更新を行う。通信処理部３３は、送信
処理部３６と受信処理部３７を搭載することで各機能を
含むと共に一般的な通信処理機能を有している。更に、
通信処理に応じて組識別情報通知部３８及び組識別情報
管理部３９としての機能を発揮する。通信管理テーブル
４０は、組識別情報に各アプリケーションを特定しうる
アプリケーション識別情報を対応させて記憶する。

【００１５】図２は、本実施の形態における通信管理テ
ーブル４０の構成例を示した図である。このテーブルに
おいて、通信を行う各アプリケーションを特定し関連づ
けている。クライアントアプリケーション識別情報とし
ては、クライアント１０側のアプリケーションを特定す
るための識別情報としてＭＡＣアドレス及び使用する通
信ソケットハンドルの番号を含んでいる。本実施の形態
におけるクライアント１０のアプリケーション実行部１
１は、同時には唯一の通信アプリケーションのみを実行
するため、他のクライアントと識別可能なＭＡＣアドレ
スをアプリケーション識別情報として使用するが、複数
動作させるのであれば、ＩＰアドレスやクライアントア
プリケーション名等他の情報も付加する必要がある。サ
ーバアプリケーション識別情報としては、サーバ３０側
のアプリケーションを特定するための識別情報としてサ
ーバ名及び使用する通信ソケットハンドルの番号を含ん
でいる。このアプリケーションの組に各組を識別するた
めの組識別情報としてセッションＩＤを割り当て、更に
このレコードデータの有効“Ｙ”／無効“Ｙ”並びに回
線断中“Ｅ”を示す有効フラグを付加する。なお、本実
施の形態で用いる各アプリケーションの識別情報は例示
であり、システム構成やアプリケーションの構成に応じ
て識別可能な他の情報を用いればよい。

【００１６】上記構成のうち、アプリケーション実行部
１１，３１、通信処理部１３，３３は、各機能を実現す
るアプリケーションソフトウェアをＣＰＵ上で実行する
ことで実現される。また、回線制御部１２，３２は、Ｔ
ＣＰ／ＩＰなどの所定の通信プロトコルに基づいた通信
を実現するためのハードウェア、ソフトウェア等で実現
される。通信管理テーブル４０は、メモリ上に設ける
が、ディスク装置などの読み書き可能な記憶媒体でも実
現可能である。送信データ保持部１４，３４及び受信デ
ータ情報保持部１５，３５も同様である。

【００１７】本実施の形態において特徴的なことは、ア
プリケーション間通信の途中で通信回線５が切断された
後、回線が復旧したときにアプリケーションに負担をか
けることなくデータの再送を行えるようにしたことであ
る。更に、回線復旧時に再接続先となるコンピュータ
（サーバ３０）において複数のアプリケーションが動作
していても、その中から回線断前に通信を行っていたア
プリケーションを一意に特定できるようにしたことであ
る。これにより、通信回線５が復旧した後でもアプリケ
ーションに負荷をかけることなくデータ通信を再開させ
ることができる。

【００１８】次に、本実施の形態における動作について
各フローチャートを用いて説明するが、まず、アプリケ
ーション間に通信路を形成する際に行われる回線接続処
理、回線確立後にクライアント１０がサーバ３０に対し
てデータを正常に送信するときの処理、回線確立後にサ
ーバ３０がクライアント１０に対してデータを正常に送
信するときの処理及びアプリケーション間通信が終了し
通信路を切断する通信終了処理について説明する。その
後にデータ通信中に回線断が発生したときの処理につい
て説明する。

【００１９】図３は、クライアント１０側の通信処理部
１３における処理を示したフローチャートであり、図４
は、サーバ３０の側の通信処理部３３における処理を示
したフローチャートであるが、まず最初に図３及び図４
を用いてアプリケーション間に通信路を形成する際に行
われる回線接続処理についてクライアント１０から接続
要求を出した場合を例にして説明する。

【００２０】クライアント１０において常時稼動してい
る通信処理部１３は、アプリケーション実行部１１で動
作しているアプリケーション（以下、「クライアントア
プリケーション」という）からサーバ３０側のアプリケ
ーション（以下、「サーバアプリケーション」という）
と通信を行うための要求を受け付けると、サーバ３０側
に接続要求を出す（ステップ１００，１０１）。

【００２１】サーバ３０において常時稼動している通信
処理部３３は、通信回線５を介してクライアント１０か
らの接続要求を受け付けると（ステップ２００）、ま
ず、通信管理テーブル４０から空いているエントリを探
してセッションＩＤを取得する（ステップ２０１）。エ
ントリの空きは、有効フラグを参照することで把握でき
る。すなわち、“Ｎ”の有効フラグのエントリを未使用
と判断できる。そして、通信処理部３３は、通信先とな
るサーバアプリケーションを起動する（ステップ２０
２）。接続要求には、クライアント１０側のＭＡＣアド
レス、通信ソケットハンドル番号及び通信相手先となる
サーバ名が含まれているので、これから起動の対象を特
定できる。そして、起動されたサーバアプリケーション
にセッションＩＤを通知する（ステップ２０３）。サー
バアプリケーションが起動されクライアントアプリケー
ションとの通信路が確立されると、通信処理部３３は、
通信管理テーブル４０に各アプリケーションの識別情報
を書き込み（ステップ２０４）、有効フラグを“Ｙ”に
変更することでこのアプリケーション組のエントリの登
録を終えた後（ステップ２０５）、クライアント１０へ
セッションＩＤとともに接続処理の完了を通知する（ス
テップ２０６）。

【００２２】クライアント１０において、通信処理部１
３は、送られてきたセッションＩＤをデータ通信要求元
のアプリケーションに渡す（ステップ１０３）。

【００２３】このようにして、アプリケーション間に通
信路が確立されると、次のようにしてアプリケーション
間通信が行われる。まず、クライアント１０からサーバ
３０へのデータを送信する際に行われる処理（図３のス
テップ１１１、図４のステップ２２１）について図５及
び図６に示したフローチャートを用いて説明するが、こ
こではデータ送信が正常終了したときについて説明す
る。

【００２４】クライアントアプリケーションがサーバア
プリケーションにデータを送信する場合、クライアント
アプリケーションは、送信するデータに通信路形成時に
知らされたセッションＩＤを付加して送信要求を通信処
理部１３に渡すことになる。通信処理部１３は、クライ
アントアプリケーションから送られてきた送信するデー
タ本体とセッションＩＤを受け取ると（ステップ１４
１）、その送信するデータを送信データ保持部１４に書
き込むことで保持した後（ステップ１４２）、データ本
体にセッションＩＤを付加したままサーバ３０へ送信す
る（ステップ１４３，１４４）。なお、送信するデータ
のフォーマットの例を図７に示す。

【００２５】図６において、サーバ３０の通信処理部３
３は、クライアント１０から送られてきたデータを受信
すると（ステップ２６１）、受信データに含まれている
セッションＩＤにより通信管理テーブル４０を検索して
サーバ名を取得することによって通信相手となるサーバ
アプリケーションを特定し（ステップ２６２）、そのア
プリケーションにデータを渡す（ステップ２６３，２６
７）。そして、受信したデータをそのまま受信データ情
報保持部３５に書き込む（ステップ２６８）。なお、前
回のデータ受信処理において受信データ情報保持部３５
に保持した同一セッションＩＤのデータが存在すれば、
それを消去する。この処理を終了すると、正常にデータ
を受信した旨を表す受信確認応答をクライアント１０へ
送出する（ステップ２６９）。なお、この受信確認応答
メッセージのデータフォーマットの例を図８に示す。

【００２６】クライアント１０の通信処理部１３は、サ
ーバ３０から送られてきた受信確認応答を受け取ること
でデータ送信処理が正常に終了したことを確認すると
（ステップ１４７，１４８）、送信データ情報保持部１
４に一時保持しておいたデータを消去する（ステップ１
４９）。このようにして、クライアントアプリケーショ
ンから送出されたデータは、特定のサーバアプリケーシ
ョンに送られる。

【００２７】次に、サーバ３０からクライアント１０へ
のデータ送信処理（図４のステップ２１１、図３のステ
ップ１１１）について図９及び図１０に示したフローチ
ャートを用いて説明するが、ここではデータ送信が正常
終了したときについて説明する。

【００２８】サーバアプリケーションがクライアントア
プリケーションにデータを送信する場合、サーバアプリ
ケーションは、送信するデータに通信路形成時に知らさ
れたセッションＩＤを付加して送信要求を通信処理部３
３に渡すことになる。通信処理部３３は、サーバアプリ
ケーションから送られてきた送信するデータ本体とセッ
ションＩＤを受け取ると（ステップ２７１）、受け取っ
たセッションＩＤにより通信管理テーブル４０を検索し
て通信相手となるクライアントアプリケーションを特定
する（ステップ２７２）。そして、その送信するデータ
を送信データ保持部３４に書き込むことで保持した後
（ステップ２７３）、特定したクライアントアプリケー
ションへ送信する（ステップ２７４，２７５）。送信す
るデータのフォーマットは、図７と同じでよいが、セッ
ションＩＤを必ずしも付加する必要はない。

【００２９】図１０において、クライアント１０の通信
処理部１３は、サーバ３０から送られてきたデータを受
信すると（ステップ１５１）、実行中の特定のアプリケ
ーションにデータを渡す（ステップ１５５）。そして、
受信したデータをそのまま受信データ情報保持部１５に
書き込む（ステップ１５６）。なお、前回のデータ受信
処理において受信データ情報保持部１５に保持したデー
タが存在すれば、それを消去する。この処理を終了する
と、正常にデータを受信した旨を表す受信確認応答をサ
ーバ３０へ送出する（ステップ１５７）。受信確認応答
メッセージのデータフォーマットは、図８と同じであ
る。

【００３０】サーバ３０の通信処理部３３は、クライア
ント１０から送られてきた受信確認応答を受け取ること
でデータ送信処理が正常に終了したことを確認すると
（ステップ２７９，２８０）、送信データ情報保持部３
４に一時保持しておいたデータを消去する（ステップ２
８１）。このようにして、サーバアプリケーションから
送出されたデータは、特定のクライアントアプリケーシ
ョンに送られる。

【００３１】アプリケーション間のデータのやり取りが
完了して通信を終了する場合、クライアントアプリケー
ションは、その切断要求にセッションＩＤを付加して送
出する。通信処理部１３は、このセッションＩＤが付加
された切断要求データをサーバ３０へ送信する（ステッ
プ１００，１３１）。

【００３２】サーバ３０において、通信処理部３３は、
受信データに含まれているセッションＩＤにより通信管
理テーブル４０を検索して通信相手となっていたサーバ
アプリケーションを特定し（ステップ２３１）、その実
行を終了し、又は自ら終了させる（ステップ２３２）。
そして、通信が終了したそのアプリケーションの組のエ
ントリの有効フラグを“Ｎ”に変更する（ステップ２３
３）。なお、このとき、各回線制御部１２，３２は、ア
プリケーション間の通信路を切断する。

【００３３】以上のようにして、アプリケーション間の
通信を行うが、本実施の形態においては、セッションＩ
Ｄをデータに付加してデータ通信を行うことを特徴とし
ている。

【００３４】次に、データ通信中に通信回線５が切断さ
れたとき及び回線が復旧したときの処理について説明す
る。なお、クライアント１０又はサーバ３０のいずれが
データ送信側又はデータ受信側となったとしても行われ
る処理は基本的にはほぼ同様なので、ここではクライア
ント１０がサーバ３０に対してデータを送信したときの
場合を例にして説明する。クライアント１０がデータを
送信して受信応答確認を受信するまでの間に通信回線５
の切断が発生するタイミングとして、クライアント１０
のデータ送信後サーバ３０のデータ受信前に発生する場
合と、クライアント１０が送信したデータをサーバ３０
が受信した後受信確認応答送信後クライアント１０のデ
ータ受信前に発生する場合とが考えられる。ここでは、
まず、クライアント１０のデータ送信後サーバ３０のデ
ータ受信前に回線断が発生した場合のデータ通信処理に
ついて説明する。

【００３５】図５において、アプリケーション実行部１
１により実行されているアプリケーションからデータを
受け取り、そのデータを送信データ情報保持部１４に保
持するとともにサーバ３０へ送信するまでの通信処理部
１３における処理は、上記と同じである（ステップ１４
１〜１４４）。ここで、データを送信したものの受信確
認応答受信前に回線断による通信エラーが発生したとす
る。通信処理部１３は、回線が切れたことを回線制御部
１２からの通知を受けることで知ることができるが、回
線断がサーバ３０によるデータ受信後に発生したのか、
それともデータ受信後受信確認応答送出後に発生したの
かの判別ができない。そこで、通信処理部１３は、回線
断による通信エラーが発生したとき（ステップ１４６）
又はタイムアウトにより受信確認応答を正常に受信でき
なかったとき（ステップ１４７，１４８）、その後に回
線が復旧したときに先ほどの送信したデータを再送する
が、本実施の形態においては、送信データ情報保持部１
４に一時保持したデータを取り出してサーバ３０へ自動
再送することになる（ステップ１４３，１４５）。これ
により、データ送信要求をしたクライアントアプリケー
ションに回線断を知らせることなくデータの再送を行う
ことができるので、当該アプリケーションに回線断並び
のその復旧処理による影響を及ぼさないで済む。なお、
通信処理部１３は、回線が復旧した旨を回線制御部１２
から送られてくることにより知ることができる。

【００３６】ところで、サーバ３０の通信処理部３３
は、通信回線５が切断したという回線制御部３２からの
通知を受け取ると（ステップ２００）、通信管理テーブ
ル４０において“Ｙ”となっている全ての有効フラグを
回線断が発生したことを示すための“Ｅ”に変更する
（ステップ２４１）。

【００３７】回線復旧後、サーバ３０の通信処理部３３
は、クライアント１０から通信回線５を経由して送られ
てきたデータを受け取ることになるが（ステップ２６
１）、ここでの処理ではクライアント１０のデータ送信
後サーバ３０のデータ受信前に回線断が発生しているの
で、ここで受信したデータは、再送時のデータである。
通信処理部３３は、受信データに含まれているセッショ
ンＩＤにより通信管理テーブル４０を検索することによ
ってサーバアプリケーションを特定する（ステップ２６
２）。ここで、通信処理部３３は、通信管理テーブル４
０の該当するエントリの有効フラグを参照して、及び回
線制御部３２からの通知により回線復旧後の処理である
ことを認識することができるので（ステップ２６３）、
有効フラグ“Ｅ”を“Ｙ”に変更した後（ステップ２６
４）、受信したデータと受信データ情報保持部３５に保
持されているデータとを比較する（ステップ２６５）。
再送前にクライアント１０が送出した再送と同一のデー
タは、回線断により受信されていないはずであるから、
この比較処理においてデータは一致しないはずである。
従って、通信処理部３３は、回線復旧後の受信データが
クライアント１０からまだ受け取っていないデータであ
ると判断して、上記と同様に受信データをサーバアプリ
ケーションに渡すとともに受信データ情報保持部３５に
書き込む（ステップ２６７，２６８）。そして、正常に
データを受信した旨を表す受信確認応答をクライアント
１０へ送出する（ステップ２６９）。なお、回線復旧直
後のデータ受信である旨をサーバアプリケーションにデ
ータと共に知らせるようにしてもよい。

【００３８】クライアント１０の通信処理部１３は、サ
ーバ３０から送られてきた受信確認応答を正常に受け取
ると（ステップ１４７，１４８）、送信データ情報保持
部１４に一時保持した送信データを消去する（ステップ
１４９）。

【００３９】次に、クライアント１０が送信したデータ
をサーバ３０が受信した後、サーバ３０が送信した受信
確認応答をクライアント１０が受信する前に回線断が発
生した場合のデータ通信処理について説明する。

【００４０】アプリケーション実行部１１により実行さ
れているアプリケーションからデータを受け取り、その
データを送信データ情報保持部１４に保持するとともに
サーバ３０へ正常に送信するまでの通信処理部１３にお
ける処理は、上記と同じである（ステップ１４１〜１４
４）。

【００４１】一方、サーバ３０の通信処理部３３は、ク
ライアント１０から通信回線５を経由して送られてきた
データを受け取ると（ステップ２６１）、その受信デー
タをセッションＩＤにより特定したサーバアプリケーシ
ョンに渡すとともに（ステップ２６７）、受信データ情
報保持部３５に書き込み（ステップ２６８）、その後、
受信確認応答をクライアント１０へ送出する（ステップ
２６９）。ここまでの処理は、最初に説明したデータ通
信が正常に終了した場合の処理と同じである。

【００４２】ここで、サーバ３０から発せられた受信確
認応答をクライアント１０が受け取る前に回線断が発生
し、その後復旧したとする。このとき、通信処理部１３
は、当然ながら受信確認応答を受け取っていないが、こ
れは、回線断がサーバ３０によるデータ受信後に発生し
たのか、それともデータ受信後受信確認応答送出後に発
生したのかの判別ができない。そこで、通信処理部１３
は、回線断による通信エラーが発生したとき（ステップ
１４６）又はタイムアウトにより受信確認応答を正常に
受信できなかったとき（ステップ１４７，１４８）、回
線が復旧したことを確認した後、送信データ情報保持部
１４に一時保持したデータを取り出してサーバ３０に再
送することになる（ステップ１４３，１４５）。

【００４３】サーバ３０の通信処理部３３は、クライア
ント１０から送られてきたデータを受け取る（ステップ
２６１）。ここで受信したデータは、受信確認応答送出
後に発生した回線断の後に受信したデータであり、再送
時のデータである。通信処理部３３は、受信データに含
まれているセッションＩＤにより通信管理テーブル４０
を検索することによってサーバアプリケーションを特定
する（ステップ２６２）。ここで、通信処理部３３は、
通信管理テーブル４０の該当するエントリの有効フラグ
を参照して、及び回線制御部３２からの通知により回線
復旧後の処理であることを認識することができるので
（ステップ２６３）、有効フラグ“Ｅ”を“Ｙ”に変更
した後（ステップ２６４）、受信したデータと受信デー
タ情報保持部３５に保持されているデータとを比較する
（ステップ２６５）。

【００４４】ところで、回線復旧後に受信したのと同一
のデータは、前述したように、回線断前にすでに受信さ
れ、サーバアプリケーションに渡され、かつ受信データ
情報保持部３５にすでに書き込まれている。従って、比
較するデータの内容は一致することになるので、通信処
理部３３は、受信データをサーバアプリケーションへ渡
す処理（ステップ２６７）及び受信データ情報保持部３
５へ書き込む処理（ステップ２６８）を行わずに受信確
認応答の送出のみを行うことになる（ステップ２６
９）。このように、通常のデータ受信処理において受信
データ情報保持部３５に受信データを一時保持してお
き、回線復旧後における処理において上記比較処理を行
うことで、データが再送されてきたとしてもアプリケー
ションに同じデータを二度渡すことを防止することがで
きる。また、回線断が発生したとしてもデータ通信を自
動的に再開することができるので、アプリケーションに
回線断を知らせる必要もなく、回線断並びのその復旧処
理による影響を及ぼさないで済む。

【００４５】クライアント１０の通信処理部１３は、サ
ーバ３０から送られてきた受信確認応答を正常に受け取
ると（ステップ１４７，１４８）、送信データ情報保持
部１４に一時保持した送信データを消去する（ステップ
１４９）。

【００４６】以上のように、本実施の形態によれば、回
線断がデータ送信時あるいは受信確認応答時に発生した
としても回線復旧後にアプリケーションに負荷をかける
ことなくデータの再送を行うことができるので、回線断
後におけるデータ通信処理を自動的に再開することがで
きる。これにより、データの送信並びに受信をする各ア
プリケーションに回線断に対する復旧、再送等の処理を
含ませる必要がなくなる。

【００４７】また、本実施の形態においては、セッショ
ンＩＤを用いて通信相手を特定しているので、サーバア
プリケーションを再起動し直して処理を最初からやり直
す必要もなく、回線断発生時に中断したところから処理
を再開させることができる。すなわち、通信路が切断さ
れた各アプリケーションは、回線断による通信エラーが
発生したとしても通信回線５が回復するまでの間、処理
を途中で終了させずに待機していればよい。そして、回
線が復旧したとき、回線断前の相手と改めてデータ通信
を再開することになるが、前述したようにデータ送信中
に回線断が発生していれば、データの再送を自動的に行
うことになる。回線復旧時、サーバ３０において待機中
のサーバアプリケーションが複数存在していても、本実
施の形態ではセッションＩＤを用いて通信相手を特定す
るようにしているので、通信管理テーブル４０を参照す
ることによってクライアントアプリケーションと回線断
前に通信をしていたサーバアプリケーションを待機中の
中から一意に特定することができる。そして、回線断発
生時に中断したところから処理を再開すればよい。これ
は、トランザクション処理を行うサーバアプリケーショ
ンにとっては、回線断前に行った処理を無駄にせずに済
むので非常に効果的である。

【００４８】また、送信側となるクライアント１０にお
いては、送信データを一時保持するようにしたので、送
信元のクライアントアプリケーションから再度送信すべ
きデータを送ってもらうことなく回線復旧後におけるデ
ータ再送処理を行うことができる。また、受信確認応答
受信後に一時保持した送信データを消去するようにした
ので、保持するための無駄な容量を使用しないで済む。
特に、本実施の形態では、送信データのフォーマットの
まま保持するようにしたので、再送の際に余計な変換処
理等を行わないで済む。

【００４９】一方、受信側となるサーバ３０において
は、受信データ情報として受信データをそのまま一時保
持するようにし、回線復旧後にはデータ再送によって受
信したデータを保持したデータと比較するようにしたの
で、同じデータをサーバアプリケーションに再度渡すこ
とがない。また、新たに受信データを保持する際、前回
のデータ受信時に保持したデータを消去するようにした
ので、保持するための無駄な容量を使用しないで済む。

【００５０】サーバ３０からクライアント１０へのデー
タ送信時に回線断が発生したときの処理は、クライアン
ト１０がサーバ３０に対してデータを送信したときとほ
ぼ同様である。ただ、サーバ３０に設けられている通信
管理テーブル４０へのアクセス、特に回線復旧直後のデ
ータ送信時に、データ通信を行う相互のアプリケーショ
ンの組に該当する有効フラグを“Ｅ”から“Ｙ”に変更
する処理（ステップ２７６）が含まれることが異なる。

【００５１】なお、通信処理部１３，３３は、データを
送信してから受信確認応答を受信するまでの間に様々な
タイミングで回線断を認識することになるため、回線断
を図５に示したステップ１４６からステップ１４８又は
図９に示したステップ２７８からステップ２８０と異な
る手順で認識するようにしてもよい。この処理手順は、
本発明の設計事項の範囲内である。

【００５２】上記各実施の形態においては、クライアン
ト・サーバシステムを例にして本発明に係るデータ通信
システムを説明したが、コンピュータを接続する通信線
が切断される可能性のある様々な形態のデータ通信シス
テムに適用できることはいうまでもない。また、各実施
の形態では、１台のクライアント１０のみの例で説明し
たが、送受信されるデータにクライアント１０又はアプ
リケーションを識別するための情報（ＭＡＣアドレス、
ＩＰアドレス、アプリケーション名等）を付加すること
によって複数のクライアント１０を接続したシステム構
成においても容易に適用することができる。

【００５３】

【発明の効果】本発明によれば、受信データを一時保持
するようにし、その保持したデータと回線断直後に送ら
れてきたデータとを比較するようにしたので、アプリケ
ーションに同一のデータを二度送信することを防止する
ことができる。

【００５４】また、送信データを一時保持し、データ通
信が正常に終了しなかったときにその一時保持したデー
タを再送するようにしたので、回線断が発生してもデー
タ通信を行っていたアプリケーションに回線断に基づく
復旧処理等をさせることなくデータ通信を再開すること
ができる。

【００５５】また、通信回線を介してデータ通信を行う
相互のアプリケーションの組に組識別情報を割り当て、
データを送信する際にはこの組識別情報を利用して通信
相手を特定するようにしたので、通信回線が切断され復
旧したとき、回線断前に通信をしていたアプリケーショ
ンを一意に特定することができる。このため、アプリケ
ーション間で回線断時から処理を再開することが容易に
できる。

【図面の簡単な説明】

【図１】 本発明に係るデータ通信システムの一実施の
形態を示した全体構成図である。

【図２】 本実施の形態における通信管理テーブルの構
成例を示した図である。

【図３】 本実施の形態においてクライアント側の通信
処理部における処理を示したフローチャートである。

【図４】 本実施の形態においてサーバ側の通信処理部
における処理を示したフローチャートである。

【図５】 本実施の形態においてクライアント側の通信
処理部におけるデータ送信処理を示したフローチャート
である。

【図６】 本実施の形態においてサーバ側の通信処理部
におけるデータ受信処理を示したフローチャートであ
る。

【図７】 本実施の形態において送信するデータのフォ
ーマットの例を示した図である。

【図８】 本実施の形態における受信確認応答のフォー
マットの例を示した図である。

【図９】 本実施の形態においてサーバ側の通信処理部
におけるデータ送信処理を示したフローチャートであ
る。

【図１０】 本実施の形態においてクライアント側の通
信処理部におけるデータ受信処理を示したフローチャー
トである。

【図１１】 従来からあるデータ通信システムの一例を
示したシステム構成図である。

【符号の説明】

５ 通信回線、１０ クライアント、１１，３１ アプ
リケーション実行部、１２，３２ 回線制御部、１３，
３３ 通信処理部、１４，３４ 送信データ情報保持
部、１５，３５ 受信データ情報保持部、１６，３６
送信処理部、１７，３７ 受信処理部、３８ 組織別情
報通知部、３９ 組織別情報管理部、４０通信管理テー
ブル。

Claims (2)

【特許請求の範囲】
1. 【請求項１】 通信回線を介してデータ通信を行うアプ
   リケーションを実行するアプリケーション実行手段と、 所定の通信手順に基づき回線の接続、切断、復旧処理及
   びその旨の通知を行う回線制御手段と、 を備えた少なくとも２台のコンピュータを有するデータ
   通信システムにおいて、 第１のコンピュータは、 前記通信回線を介して相互にデータ通信を行う相互のア
   プリケーションの組を識別するための組識別情報を前記
   アプリケーションの組に割り当てる組識別情報管理手段
   と、 組識別情報に各アプリケーションを特定しうるアプリケ
   ーション識別情報を対応させて記憶する通信管理テーブ
   ルと、 各アプリケーションに、当該アプリケーションに割り当
   てられた組識別情報を通知する組識別情報通知手段と、 送信するデータを保持するための第１の送信データ保持
   手段と、 内部で動作するアプリケーションから組識別情報が付加
   された送信データを受け取ったとき、その組識別情報に
   基づき前記通信管理テーブルを参照することによってデ
   ータ送信先となるアプリケーションを特定し、前記送信
   データをその送信先アプリケーションが動作する前記コ
   ンピュータへ送信するとともに前記送信データを組識別
   情報を付加したまま前記第１の送信データ保持手段に書
   き込む第１の送信処理手段と、 前記通信回線を介して受信したデータに関する情報を保
   持するための第１の受信データ情報保持手段と、 前記通信回線を介して組識別情報が付加された受信デー
   タを受け取ったとき、その組識別情報に基づき前記通信
   管理テーブルを参照することによってデータの渡し先と
   なるアプリケーションを特定し、前記受信データをその
   アプリケーションに渡すとともに受信データに関する情
   報を前記第１の受信データ情報保持手段に書き込む第１
   の受信処理手段と、 を有し、 第１のコンピュータと通信を行う少なくとも１台の第２
   のコンピュータは、 送信するデータを保持するための第２の送信データ保持
   手段と、 内部で動作するアプリケーションから組識別情報が付加
   された送信データを、前記第１のコンピュータへ送信す
   ると共に前記第２の送信データ保持手段に書き込む第２
   の送信処理手段と、 前記通信回線を介して受信したデータに関する情報を保
   持するための第２の受信データ情報保持手段と、 前記通信回線を介して受信したデータを送信先となるア
   プリケーションに渡すと共に受信したデータに関する情
   報を前記第２の受信データ情報保持手段に書き込む第２
   の受信処理手段と、 を有し、 前記各送信処理手段は、通信回線断後、通信回線の復旧
   を確認したとき前記送信データ情報保持手段に保持した
   送信データを再送し、 前記各受信処理手段は、通信回線復旧後にデータを受信
   したとき、前記受信データ情報保持手段に保持した受信
   したデータに関する情報に基づき、通信回線復旧後に受
   信したデータがすでに受信済みであると判断したときに
   はアプリケーションへのデータ渡し及び受信データ情報
   の前記受信データ情報保持手段への書込みを行わないこ
   とを特徴とするデータ通信システム。
2. 【請求項２】 前記第１のコンピュータは、サーバコン
   ピュータであり、 前記第２のコンピュータは、前記サーバコンピュータと
   前記通信回線を介してデータ通信を相互に行う１乃至複
   数のクライアントコンピュータであることを特徴とする
   請求項１記載のデータ通信システム。