JP3608905B2 - データ通信システム及びデータ通信方法 - Google Patents
データ通信システム及びデータ通信方法 Download PDFInfo
- Publication number
- JP3608905B2 JP3608905B2 JP13993697A JP13993697A JP3608905B2 JP 3608905 B2 JP3608905 B2 JP 3608905B2 JP 13993697 A JP13993697 A JP 13993697A JP 13993697 A JP13993697 A JP 13993697A JP 3608905 B2 JP3608905 B2 JP 3608905B2
- Authority
- JP
- Japan
- Prior art keywords
- communication
- application
- data
- identification information
- line
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Maintenance And Management Of Digital Transmission (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、データ通信システム、特に通信回線を介したアプリケーション間通信の実行中に通信回線が切断されたとき並びにその後復旧されたときの処理に関する。
【０００２】
【従来の技術】
図１２は、データ通信システムの一形態として従来からあるクライアント・サーバシステムの一例を示したシステム構成図である。図１２において、回線制御部１，２は、それぞれクライアント３、サーバ４において所定の通信プロトコルに基づき通信回線５を介しての通信処理を行うための手段である。アプリケーション実行部６，７は、相互にデータ送受信を行うアプリケーションを実行するための手段であり、実行中の各アプリケーションがデータ通信を行うことになる。
【０００３】
従来のクライアント・サーバシステムにおいて例えばＴＣＰ／ＩＰプロトコルに基づき通信を行う場合、各回線制御部１，２は、通信相手先（サーバ４、クライアント３）との間のソケットをオープンして通信路を確立し、アプリケーション間から／へのデータの受け渡しを行う。
【０００４】
ところで、無線回線や電話回線などの回線品質や使用環境によっては、通信回線５がデータ通信中に一時的に切れてしまう場合がある。通信プロトコルには、データ再送機能を有しているものも少なくないため、一時的な切断であれば、アプリケーションに通信エラーステータスを返すことなく通信プロトコルレベルで自動復旧して対応することも可能であるが、通信プロトコルレベルでの再送の試行回数が所定数を越えてしまったりタイムアウトが発生したりして、結果的に通信プロトコルレベルで対応がしきれない場合がある。
【０００５】
その後、通信回線５が復旧したとき、各アプリケーションは、通信路を再形成し処理を再開することになるが、例えばクライアント３で動作していたデータ送信アプリケーションは、回線断前に通信をしていたサーバ４で待機中のデータ受信アプリケーションと予め決めていた手順に従い通信路を再形成して通信を再開することになる。
【０００６】
【発明が解決しようとする課題】
しかしながら、従来においては、回線が復旧したとき、サーバにおいて複数のデータ受信アプリケーションが待機していた場合、データ送信アプリケーションは、どのデータ受信アプリケーションと通信路を再形成して処理を再開すればよいのか一意に特定できない。このため、データ送信アプリケーションは、やむを得ずデータ受信アプリケーションを再起動して最初から処理をやり直すことになるが、この際、回線断前に行っていた処理結果を破棄しなければならず効率的でない。場合によっては、どこまで前回の処理結果を破棄すべきなのか特定できない場合もあり得る。
【０００７】
本発明は以上のような問題を解決するためになされたものであり、その目的は、回線断から復旧した後にアプリケーション間通信の再開を自動的に行うデータ通信システム及びデータ通信方法を提供することにある。
【０００８】
【課題を解決するための手段】
以上のような目的を達成するために、第１の発明に係るデータ通信システムは、通信回線を介して他のアプリケーションとの間でデータ通信を双方向に行うアプリケーションを実行するアプリケーション実行手段と、所定の通信手順に基づき回線の接続、切断、復旧処理及びその旨の通知を行う回線制御手段とを備えたコンピュータを有するデータ通信システムにおいて、通信回線を介して相互にデータ通信を行うアプリケーションの組を識別するための組識別情報に、組を構成する各アプリケーションの識別情報を対応させて記憶する通信管理テーブルと、アプリケーションの間に通信路が確立された時点で当該通信路が確立されたアプリケーションの組に対して、当該アプリケーションの組を識別するための組識別情報を割り当て前記通信管理テーブルに登録する組識別情報管理手段と、アプリケーションが動作する前記各コンピュータに設けられ、アプリケーション間のデータ通信処理を行う通信処理手段とを有し、前記通信処理手段は、通信路が確立されたときに組識別情報が割り当てられた各アプリケーションに対して、その割り当てた組識別情報を通知し、前記アプリケーション実行手段は、組を構成する他方のアプリケーションに対して送信する通信データに、前記通信処理手段から通知された組識別情報を付加し、前記通信処理手段は、一方のアプリケーションから送信された通信データに付加されている組識別情報に基づき前記通信管理テーブルを検索することによって通信データの送信先となるアプリケーションを特定するものである。
【０００９】
第２の発明に係るデータ通信システムは、少なくとも２台のコンピュータを有するデータ通信システムにおいて、第１のコンピュータは、第２のコンピュータにおいて動作する第２のアプリケーションとの間で通信回線を介してデータ通信を双方向に行う第１のアプリケーションを実行する第１のアプリケーション実行手段と、所定の通信手順に基づき回線の接続、切断、復旧処理及びその旨の通知を行う第１の回線制御手段と、通信回線を介して相互にデータ通信を行う第１及び第２のアプリケーションの組を識別するための組識別情報に、組を構成する各アプリケーションの識別情報を対応させて記憶する通信管理テーブルと、第１及び第２のアプリケーションの間に通信路が確立された時点で当該通信路が確立された第１及び第２のアプリケーションの組に対して、当該第１及び第２のアプリケーションの組を識別するための組識別情報を割り当て前記通信管理テーブルに登録する組識別情報管理手段と、第１及び第２のアプリケーション間のデータ通信処理を行う第１の通信処理手段とを有し、第１のコンピュータと通信を行う少なくとも１台の第２のコンピュータは、第１のコンピュータにおいて動作する第１のアプリケーションとの間で通信回線を介してデータ通信を双方向に行う第２のアプリケーションを実行する第２のアプリケーション実行手段と、所定の通信手順に基づき回線の接続、切断、復旧処理及びその旨の通知を行う第２の回線制御手段と、第１及び第２のアプリケーション間のデータ通信処理を行う第２の通信処理手段とを有し、前記第１の通信処理手段は、通信路が確立されたときに組識別情報が割り当てられた第１のアプリケーション及び前記第２の通信処理手段に対して、その割り当てた組識別情報を通知し、前記第１のアプリケーション実行手段は、第１のアプリケーションと組を構成する第２のアプリケーションに対して送信する通信データに、前記第１の通信処理手段から通知された組識別情報を付加し、前記第１の通信処理手段は、一方のアプリケーションから送信された通信データに付加されている組識別情報に基づき前記通信管理テーブルを検索することによって通信データの送信先となるアプリケーションを特定し、前記第２の通信処理手段は、通信路が確立されたときに組識別情報が割り当てられた第２のアプリケーションに対して、その割り当てた組識別情報を通知し、前記第２のアプリケーション実行手段は、第２のアプリケーションと組を構成する第１のアプリケーションに対して送信する通信データに、前記第２の通信処理手段から通知された組識別情報を付加し、前記第２の通信処理手段は、第２のアプリケーションから送られてきた通信データを前記第１のコンピュータへ送信し、また前記第１のコンピュータから送られてきた通信データを前記第１の通信処理手段により特定された第２のアプリケーションへ送信するものである。
【００１０】
第３の発明に係るデータ通信方法は、通信回線を介して接続された各コンピュータ上のアプリケーション間でデータ通信を双方向に行わせるデータ通信システムにおいて、通信回線を介して相互にデータ通信を行うアプリケーション間に通信路が確立された時点で、当該通信路が確立されたアプリケーションの組を識別するための組識別情報を当該アプリケーションの組に割り当て、その割り当てた組識別情報に当該組を構成する各アプリケーションの識別情報を対応させて通信管理テーブルに登録すると共に、当該組を構成する各アプリケーションに対して、その割り当てた組識別情報を通知する通信路確立時ステップと、アプリケーション間でデータ通信を行う際に、組を構成する他方のアプリケーションに対して送信する通信データに、前記通信路確立時ステップにより通知された組識別情報を付加するステップと、一方のアプリケーションから送信された通信データに付加された組識別情報に基づき前記通信管理テーブルを検索することによって当該通信データの送信先となるアプリケーションを特定するステップとを含むものである。
【００１１】
第４の発明に係るデータ通信システムは、第１又は２の発明において、前記コンピュータは、送信データを保持するための送信データ保持手段を有し、前記通信処理手段は、アプリケーションから渡された送信データを前記送信データ保持手段に一時保持するものである。
【００１２】
第５の発明に係るデータ通信システムは、第２の発明において、前記第１のコンピュータにおける前記第１の通信処理手段は、回線断が発生したときにその旨を示すフラグ情報を組識別情報に付加して前記通信管理テーブルに記憶し、回線復旧直後のデータ通信時に回線復旧直後のデータである旨をデータ受信側のアプリケーションに通知するものである。
【００１５】
第６の発明に係るデータ通信システムは、第２の発明において、前記第１のコンピュータは、サーバコンピュータであり、前記第２のコンピュータは、前記サーバコンピュータと前記通信回線を介してデータ通信を相互に行う１乃至複数のクライアントコンピュータであるものとする。
【００１６】
【発明の実施の形態】
以下、図面に基づいて、本発明の好適な実施の形態について説明する。
【００１７】
実施の形態１．
図１は、本発明に係るデータ通信システムの実施の形態１を示した全体構成図である。本実施の形態では、本発明に係るデータ通信システムを有線若しくは無線の通信回線５を介して接続されたコンピュータ（クライアント１０及びサーバ３０）で構成され、ＴＣＰ／ＩＰに基づきデータ通信を行うクライアント・サーバシステムに適用した場合の例で説明する。なお、クライアント１０及びサーバ３０は、一般的なコンピュータであり、データの送受信を双方向に行うことができる。また、本実施の形態では、便宜上、１台のクライアント１０のみを図示する。なお、本実施の形態では、第１のコンピュータがサーバ３０であり、第２のコンピュータがクライアント１０である。
【００１８】
クライアント１０は、アプリケーション実行部１１、回線制御部１２及び通信処理部１３を有している。アプリケーション実行部１１は、通信回線５を介してデータ通信を行うアプリケーションを実行するアプリケーション実行手段である。回線制御部１２は、回線制御手段として設けられ、所定の通信手順に基づき回線の接続、切断、復旧処理等の回線制御、通信制御を行い、更に回線断、復旧等が発生した旨の通知を行う。ＴＣＰ／ＩＰの通信プロトコルに基づく通信を行う場合、サーバ３０との間のソケットをオープンする。通信処理部１３は、通信処理手段として設けられ、アプリケーション間のデータ通信処理を行う。また、詳細は後述するが、アプリケーションに対してそのアプリケーションに割り当てられた組識別情報を通知する。
【００１９】
サーバ３０は、アプリケーション実行部３１、回線制御部３２、通信処理部３３、組識別情報管理部３４及び通信管理テーブル３５を有している。アプリケーション実行部１１は、通信回線５を介してデータ通信を行うアプリケーションを実行するアプリケーション実行手段であり、同時に複数の通信アプリケーションを実行することができる。回線制御部１２は、回線制御手段として設けられ、所定の通信手順に基づき回線の接続、切断、復旧処理等の回線制御、通信制御を行い、更に回線断、復旧等が発生した旨の通知を行う。ＴＣＰ／ＩＰの通信プロトコルに基づく通信を行う場合、クライアント１０との間のソケットをオープンする。通信処理部３３は、通信処理手段として設けられ、アプリケーション間のデータ通信処理を行う。また、詳細は後述するが、アプリケーションに対してそのアプリケーションに割り当てられた組識別情報を通知する。組識別情報管理部３４は、通信回線５を介して相互にデータ通信を行う相互のアプリケーションの組を識別するための組識別情報をそのアプリケーション組に割り当てる組識別情報管理手段であり、本実施の形態においては、通信処理部３３に組み込まれている。すなわち、本実施の形態における通信処理部３３は、通信処理機能と共に組識別情報管理機能を有している。通信管理テーブル３５は、組識別情報に各アプリケーションを特定しうるアプリケーション識別情報を対応させて記憶する。このテーブルへの情報設定及び管理は、通信処理部３３が行う。
【００２０】
図２は、本実施の形態における通信管理テーブル３５の構成例を示した図である。このテーブルにおいて、通信を行う各アプリケーションを特定し関連づけている。クライアントアプリケーション識別情報としては、クライアント１０側のアプリケーションを特定するための識別情報としてＭＡＣアドレス及び使用する通信ソケットハンドルの番号を含んでいる。本実施の形態におけるクライアント１０のアプリケーション実行部１１は、同時には唯一つの通信アプリケーションのみを実行するため、他のクライアントと識別可能なＭＡＣアドレスをアプリケーション識別情報として使用するが、複数動作させるのであれば、ＩＰアドレスやクライアントアプリケーション名等他の情報も付加する必要がある。サーバアプリケーション識別情報としては、サーバ３０側のアプリケーションを特定するための識別情報としてサーバ名及び使用する通信ソケットハンドルの番号を含んでいる。このアプリケーションの組に各組を識別するための組識別情報としてセッションＩＤを割り当て、更にこのレコードデータの有効“Ｙ”／無効“Ｎ”を示す有効フラグを付加する。なお、本実施の形態で用いる各アプリケーションの識別情報は例示であり、それぞれに識別機能を有するものであれば他の情報を用いてもよい。
【００２１】
上記構成のうち、アプリケーション実行部１１，３１、通信処理部１３，３３及び組識別情報管理部３４は、各機能を実現するアプリケーションソフトウェアをＣＰＵ上で実行することで実現される。また、回線制御部１２，３２は、ＴＣＰ／ＩＰなどの所定の通信プロトコルに基づいた通信を実現するためのハードウェア、ソフトウェア等で実現される。通信管理テーブル３５は、メモリ上に設けるが、ディスク装置などの読み書き可能な記憶媒体でも実現可能である。
【００２２】
本実施の形態において特徴的なことは、通信を行う各アプリケーションの組にセッションＩＤを割り当て、データ送信を行う際には、このＩＤを指定して送信先を特定するようにしたことである。これにより、回線が切断した後でも回線断前に通信をしていた相手を回線復旧後においても一意に特定することができる。このため、アプリケーション間で相互にやり取りを行うことで途中であったアプリケーションの処理を継続して行うことができるようになる。
【００２３】
図３は、クライアント１０側の通信処理部１３における処理を示したフローチャートであり、図４は、サーバ３０の側の通信処理部３３における処理を示したフローチャートである。次に、これらの図を用いて本実施の形態における動作について説明するが、まず、通信路を確立し、データ通信が正常に行われ、正常に終了するときの処理から説明する。
【００２４】
クライアント１０において常時稼動している通信処理部１３は、アプリケーション実行部１１で動作しているアプリケーション（以下、「クライアントアプリケーション」という）からサーバ３０側のアプリケーション（以下、「サーバアプリケーション」という）と通信を行うための要求を受け付けると、サーバ３０側に接続要求を出す（ステップ１００，１０１）。
【００２５】
サーバ３０において常時稼動している通信処理部３３は、通信回線５を介してクライアント１０からの接続要求を受け付けると（ステップ２００）、まず、通信管理テーブル３５から空いているエントリを探してセッションＩＤを取得する（ステップ２０１）。エントリの空きは、有効フラグを参照することで把握できる。すなわち、“Ｎ”の有効フラグのエントリを未使用と判断できる。そして、通信処理部３３は、通信先となるサーバアプリケーションを起動する（ステップ２０２）。接続要求には、クライアント１０側のＭＡＣアドレス、通信ソケットハンドル番号及び通信相手先となるサーバ名が含まれているので、これから起動の対象を特定できる。そして、起動されたサーバアプリケーションにセッションＩＤを通知する（ステップ２０３）。サーバアプリケーションが起動されクライアントアプリケーションとの通信路が確立されると、通信処理部３３は、通信管理テーブル３５に各アプリケーションの識別情報を書き込み（ステップ２０４）、有効フラグを“Ｙ”に変更することでこのアプリケーション組のエントリの登録を終えた後（ステップ２０５）、クライアント１０へセッションＩＤとともに接続処理の完了を通知する（ステップ２０６）。
【００２６】
クライアント１０において、通信処理部１３は、送られてきたセッションＩＤをデータ通信要求元のアプリケーションに渡す（ステップ１０３）。
【００２７】
このようにして、アプリケーション間に通信路が確立されると、次のようにしてデータの送受信が行われる。
【００２８】
クライアントアプリケーションがサーバアプリケーションにデータを送信する場合、クライアントアプリケーションは、送信するデータに通信路形成時に知らされたセッションＩＤを付加して送信要求を通信処理部１３に渡すことになる。通信処理部１３は、このセッションＩＤが付加されたデータをサーバ３０へ送信する（ステップ１００，１１１）。
【００２９】
サーバ３０において、通信処理部３３は、クライアント１０からデータを受信すると（ステップ２００）、受信データに含まれているセッションＩＤにより通信管理テーブル３５を検索してサーバ名を取得することによって通信相手となるサーバアプリケーションを特定し（ステップ２１１）、そのアプリケーションにデータを渡す（ステップ２１２）。このようにして、クライアントアプリケーションから送出されたデータは、特定のサーバアプリケーションに送られる。
【００３０】
一方、サーバアプリケーションがクライアントアプリケーションにデータを送信する場合、サーバアプリケーションは、送信するデータにセッションＩＤを付加して送出する。通信処理部３３は、受け取ったセッションＩＤにより通信管理テーブル３５を検索して通信相手となるクライアントアプリケーションを特定し（ステップ２２１）、そのアプリケーションが動作するクライアント１０にデータを送信する（ステップ２２２）。
【００３１】
クライアント１０において、通信処理部１３は、サーバ３０からデータを受信すると（ステップ１００）、通信相手となるクライアントアプリケーションにデータを渡す（ステップ１２１）。このようにして、サーバアプリケーションから送出されたデータは、特定のクライアントアプリケーションに送られる。
【００３２】
アプリケーション間のデータのやり取りが完了して通信を終了する場合、クライアントアプリケーションは、その切断要求にセッションＩＤを付加して送出する。通信処理部１３は、このセッションＩＤが付加された切断要求データをサーバ３０へ送信する（ステップ１００，１３１）。
【００３３】
サーバ３０において、通信処理部３３は、受信データに含まれているセッションＩＤにより通信管理テーブル３５を検索して通信相手となっていたサーバアプリケーションを特定し（ステップ２３１）、その実行を終了し、又は自ら終了させる（ステップ２３２）。そして、通信を終了したそのアプリケーションの組のエントリの有効フラグを“Ｎ”に変更する（ステップ２３３）。なお、このとき、各回線制御部１２，３２は、アプリケーション間の通信路を切断する。
【００３４】
以上のようにして、アプリケーション間の通信を行うが、本実施の形態においては、セッションＩＤを管理するための通信管理テーブル３５を設け、セッションＩＤを利用して通信相手を特定してデータの送受信を行うことを特徴としている。
【００３５】
次に、データ通信中に通信回線５が切断されたとき及び回線が復旧したときの処理について説明する。
【００３６】
まず、クライアント１０の通信処理部１３は、クライアントアプリケーションからの依頼によりデータを送信しようとするが（ステップ１００，１１１）、通信回線５が切断されているのでデータを正常に送信することはできない。本実施の形態では、通信処理部１３のエラー処理としてその旨をクライアントアプリケーションに返すようにしてもよい（ステップ１１２，１１３）。これにより、クライアントアプリケーションは、状況に応じたエラー発生時の処理を行うことができる。特に、通信処理部３３は、回線制御部１２から通信回線５が切断／復旧したというの通知を受けるので、クライアントアプリケーションに通信回線５が復旧した旨の通知をしてデータの再送をさせることができる（ステップ１００，１１１）。
【００３７】
一方、サーバ３０の通信処理部３３は、サーバアプリケーションからの依頼によりデータを送信しようとするが（ステップ２００，２２１，２２２）、回線が切断されているのでデータを正常に送信することはできない。本実施の形態では、通信処理部３３のエラー処理としてその旨をサーバアプリケーションに返すようにしてもよい（ステップ２２３，２２４）。これにより、サーバアプリケーションは、状況に応じたエラー発生時の処理を行うことができる。その後、通信処理部３３は、回線制御部３２から通知を受けることで通信回線５が復旧したことを知ることができる。ここで、通信処理部３３は、サーバアプリケーションに通信回線５が復旧した旨の通知をしてデータの再送をさせることができる（ステップ２００，２２１，２２２）。
【００３８】
このようにして、通信回線５が切断された後もアプリケーション間通信を再開することができるが、本実施の形態においては、セッションＩＤを用いて通信相手を特定しているので、サーバアプリケーションを再起動し直して処理を最初からやり直す必要もなく、回線断発生時に中断したところから処理を再開させることができる。すなわち、通信路が切断されたアプリケーションは、回線断による通信エラーが発生したとしても通信回線５が回復するまでの間、処理を途中で終了させずに待機していればよい。そして、回線が復旧したとき、回線断前の相手と改めてデータ通信を再開することになるが、サーバ３０において待機中のサーバアプリケーションが複数存在していても、本実施の形態ではセッションＩＤを用いて通信相手を特定するようにしているので、通信管理テーブル３５を参照することによってクライアントアプリケーションと回線断前に通信をしていたサーバアプリケーションを待機中の中から一意に特定することができる。そして、回線断発生時に中断したところから処理を再開すればよい。これは、トランザクション処理を行うサーバアプリケーションにとっては、回線断前に行った処理を無駄にせずに済むので非常に効果的である。
【００３９】
なお、本実施の形態においては、１台のクライアント１０のみを通信回線５に接続した場合の例で説明したが、複数台接続した場合も適用することは可能である。
【００４０】
また、本実施の形態では、アプリケーションに対してセッションＩＤを伝え、アプリケーションに送信すべきデータにセッションＩＤを付加させるようにしたが、通信処理部１３がクライアント１０におけるセッションＩＤを一括管理し、サーバ３０への送出前に送信データに付加するようにしてもよい。
【００４１】
実施の形態２．
上記実施の形態１では、回線断が発生した後の復旧処理は、基本的には通信を行うアプリケーションの組に委ねていた。すなわち、処理を通信エラー発生として終了させたり、回線復旧まで待機してデータの再送を行うこともアプリケーションに任せていた。本実施の形態では、図５に示したように、クライアント１０及びサーバ３０に、送信データを保持するための送信データ保持部１４，３６をそれぞれ設け、各通信処理部１３，３３に、データ送信時にアプリケーションから渡された送信データを送信データ保持部１４，３６に一時保持させるようにしたことを特徴としている。
【００４２】
図６及び図７は、各通信処理部１３，３３におけるデータ送信処理を示したフローチャートであり、図３におけるステップ１００，１１１〜１１３及び図４におけるステップ２００，２２１〜２２４に置き換わるフローである。但し、同じ処理には、同じ符号を付ける。次に、本実施の形態における動作について説明するが、各通信処理部１３，３３におけるその他の通信処理は、図３、４と同じであるので説明を省略する。
【００４３】
クライアントアプリケーションがサーバアプリケーションにデータを送信する場合、クライアントアプリケーションは、送信するデータにセッションＩＤを付加して送出する。通信処理部１３は、このセッションＩＤが付加されたデータを受け取ると（ステップ１００）、そのデータを送信データ保持部１４に書き込むことで一時保持する（ステップ１１４）。その後、通信処理部１３は、データをサーバ３０へ送信するが（ステップ１１１）、回線断による通信エラーが発生した場合（ステップ１１２）、通信回線５が復旧するまで待機し、通信回線５の復旧を確認した後、送信データ保持部１４に一時保持したデータを取り出す（ステップ１１５）。そして、その取り出したデータを再送する（ステップ１１１）。
【００４４】
一方、サーバアプリケーションがクライアントアプリケーションにデータを送信する場合、サーバアプリケーションは、送信するデータにセッションＩＤを付加して送出する。通信処理部３３は、このセッションＩＤが付加されたデータを受け取ると（ステップ２００）、その受け取ったセッションＩＤにより通信管理テーブル３５を検索して通信相手となるクライアントアプリケーションを特定するとともに（ステップ２２１）、そのデータを送信データ保持部３６に書き込むことで一時保持する（ステップ２２５）。その後、通信処理部１３は、データをクライアント１０へ送信するが（ステップ２２２）、回線断による通信エラーが発生した場合（ステップ２２３）、通信回線５が復旧するまで待機し、通信回線５の復旧を確認した後、送信データ保持部３６に一時保持したデータを取り出す（ステップ２２６）。そして、その取り出したデータを再送する（ステップ２２２）。
【００４５】
以上のようにして、本実施の形態によれば、送信データを一時保持して、データ送信時に回線断が発生したとしても、回線復旧後に一時保持したデータを取り出して再送するようにしたので、データを送信するアプリケーションに回線断を知らせることなく再送を行うことができる。このため、アプリケーションは、回線断に基づく処理を用意しておく必要がないため、アプリケーションの開発者にかかる負担を軽減することができる。
【００４６】
なお、送信データ保持部１４，３６は、メモリ又はディスク装置などの読み書き可能な記憶媒体で実現することができる。
【００４７】
実施の形態３．
本実施の形態では、通信回線５が復旧した後、最初にクライアント１０からデータが送られてきたとき、回線復旧直後のデータである旨をサーバアプリケーションに通知するようにしたことを特徴としている。このため、本実施の形態において有効フラグには、有効“Ｙ”／無効“Ｎ”の他に回線断中を示す有効フラグ“Ｅ”が設定できるようにする。この有効フラグ“Ｅ”は、次のようにして設定される。すなわち、通信処理部３３は、通信回線５が切断したという回線制御部３２からの通知を受け取ると、通信管理テーブル３５において“Ｙ”となっている全ての有効フラグを回線断が発生したことを示すための“Ｅ”に変更することになる。
【００４８】
以下、この処理について図８に示したフローチャートを用いて説明する。なお、図８のフローチャートは、図４におけるステップ２００，２１１，２１２に置き換わるフローである。
【００４９】
サーバ３０において、通信処理部３３は、クライアント１０からデータを受信すると（ステップ２００）、受信データに含まれているセッションＩＤにより通信管理テーブル３５を検索して通信相手となるサーバアプリケーションを特定する（ステップ２１１）。このとき、このアプリケーションの組のエントリの有効フラグも参照する。有効フラグが“Ｙ”であり“Ｅ”でなければ、受信したデータを特定したサーバアプリケーションに渡す（ステップ２１２）。有効フラグが“Ｅ”であれば、データ受信の直前に通信回線５が切断されていたと判断できるので（ステップ２１３）、その旨を受信データと共にサーバアプリケーションに渡す（ステップ２１４）。そして、通信管理テーブル３５における当該アプリケーションの組の“Ｅ”となっている有効フラグを“Ｙ”に変更する（ステップ２１５）。
【００５０】
本実施の形態によれば、回線復旧直後のデータ通信時に回線復旧直後のデータである旨をサーバアプリケーションに通知することで、データ通信の再開であることを知らせることができる。これにより、サーバアプリケーションは、適切な再開処理を行い、その後に回線断前の処理を継続して行うことができる。
【００５１】
なお、本実施の形態では、クライアント１０がデータ送信を行うようにしたが、サーバ３０からクライアント１０にデータを送信する場合にも適用することができる。この場合、通信処理部３３は、サーバアプリケーションからセッションＩＤが付加されたデータを受け取ると、受け取ったセッションＩＤにより通信管理テーブル３５を検索して特定したクライアントアプリケーションにデータを送信することになるが、この際、該当するエントリの有効フラグが“Ｅ”であれば、データ送信の直前に通信回線５が切断されていたと判断できるので、その旨を送信データと共にクライアントアプリケーションに渡すことができる。そして、通信管理テーブル３５における当該アプリケーションの組の“Ｅ”となっている有効フラグを“Ｙ”に変更する。このようにして、クライアントアプリケーションに対しても回線復旧後における処理であることを知らせることができる。
【００５２】
また、本実施の形態では、“Ｅ”を設定可能とすることで有効フラグを有効利用して回線断の発生を通信処理部３３に知らせるようにしているが、有効フラグとは別個に回線断が発生した旨を示すフラグ情報を設けて組識別情報に付加して記憶するようにしてもよい。
【００５３】
実施の形態４．
上記各実施の形態においては、クライアントとサーバとの間の通信回線が切断した場合、その間の通信回線が復旧するのを待ってアプリケーション通信を再開するようにしていた。本実施の形態では、その間の通信回線５の回復を待たずに、クライアントがサーバと行っていたデータ通信を、他のクライアントがそのクライアントに代行して処理を継続できるようにしたことを特徴としている。
【００５４】
図９は、本実施の形態におけるクライアント・サーバシステムの全体構成図である。図９には、通信回線５に２台のクライアント１０−１，１０−２を接続したシステムが示されている。なお、各クライアント１０−１，１０−２の構成は、実施の形態１に示したクライアントと同一構成である。
【００５５】
図１０は、本実施の形態におけるサーバ３０の通信処理部３３の接続要求を受け付けたときの処理を示したフローチャートであり、図４に示したステップ２００〜２０６に置き換わるフローである。次に、このフローチャートに基づき、第２のコンピュータであるクライアント１０−１がサーバ３０と通信を行っているときに、その間の通信回線５が切断され、第３のコンピュータであるクライアント１０−２がクライアント１０−１の代わりにサーバ３０とのアプリケーション間通信を引き継ぐ場合を例にして本実施の形態における動作について説明する。
【００５６】
まず、クライアント１０−１は、実施の形態１と同様の手順でサーバ３０との間で通信路を形成し、データ通信を行っている。但し、サーバ３０へ送られる接続要求には、ＭＡＣアドレスの代わりに論理名がクライアントアプリケーション識別情報として含まれている。ＴＣＰ／ＩＰの場合、ＩＰアドレスを論理名として使用することができる。このＩＰアドレスを用いた本実施の形態における通信管理テーブル３５の内容例を図１１に示す。
【００５７】
ここで、クライアント１０−１とサーバ３０との間の通信回線５が切断されたとする。なお、通信処理部３３の回線切断時処理によりこのアプリケーション組のエントリの有効フラグは“Ｅ”に変更される。クライアント１０−２は、その回線断をクライアント１０−１からの通知を受けたり、自ら回線状況を監視するなど何らかの方法で知ると、クライアント１０−１において通信をしていたのと同一クライアントアプリケーションから接続要求を送出させる。この接続要求処理については、実施の形態１と同一である。但し、前述したとおり、クライアント１０−２からサーバ３０へ送られる接続要求には、共通のＩＰアドレスが指定されている。なお、クライアント１０−２は、このＩＰアドレスをクライアント１０−１からの通知を受けたり、予め設定しておくなどして知っている。
【００５８】
図１０において、サーバ３０の通信処理部３３は、クライアント１０−２からの接続要求を受信すると（ステップ２００）、通信管理テーブル３５を参照し、送られてきた接続要求に指定されたＩＰアドレスを含み、かつ有効フラグが“Ｅ”のエントリを検索する。この内容のエントリが存在しなければ、新規な接続要求であると判断し、実施の形態１で示した通常の接続要求処理を行う（ステップ２０７，２０１〜２０６）。一方、該当するエントリが存在すれば、他のクライアント１０−２がクライアント１０−１の代わりに処理を継続するための再接続要求であると判断する（ステップ２０７）。なお、送信元がクライアント１０−１であれば、送られてくるのは接続要求ではなく送信データのはずである。また、受け取ったデータに含まれているＭＡＣアドレスを参照してクライアント１０−１からのデータでないことを知ることができる。他のクライアント１０−２からの接続要求である場合、通信路は新規に形成されるため、通信処理部３３は、通信管理テーブル３５のソケットハンドルを更新する（ステップ２０８）。そして、再接続である旨を待機中のサーバアプリケーションへ通知する（ステップ２０９）。これにより、サーバアプリケーションは、再接続要求であることによる適切な処理を行うことができる。そして、通信処理部３３は、通信管理テーブル３５の有効フラグを“Ｅ”から“Ｙ”に変更し（ステップ２０５）、クライアント１０−１のクライアントアプリケーションとの組で使用していたセッションＩＤをクライアント１０−１へ通知する（ステップ２０６）。この後、クライアント１０−２のクライアントアプリケーションとサーバ３０のサーバアプリケーションは、通信を行うことができるようになるが、各アプリケーションとも再接続である旨を知っているので、アプリケーション間でやり取りを行い、クライアント１０−１のアプリケーションとした処理を途中からでも引き継ぐことができる。
【００５９】
以上のように、本実施の形態によれば、クライアントアプリケーションの識別情報にＩＰアドレスを用いることによって通信回線が切断された後も他のクライアントによって処理を継続させることができる。また、他のクライアントからの再接続である旨をサーバアプリケーションに伝えることができるので、サーバアプリケーションに適切な再接続処理を行わせることができる。
【００６０】
なお、本実施の形態では、論理名としてＩＰアドレスを用いたが、別途論理名を設定するようにしてもよい。
【００６１】
上記各実施の形態においては、クライアント・サーバシステムを例にして本発明に係るデータ通信システムを説明したが、コンピュータを接続する通信線が切断される可能性のある様々な形態のデータ通信システムに適用できることはいうまでもない。また、クライアント・サーバシステムの特性からして通信管理テーブル３５を接続要求を受けるであろうサーバ３０側に設けるようにしたが、通信管理テーブル３５を接続要求する側に設けるようにしても、また、散在させても本発明を適用することができる。
【００６２】
【発明の効果】
本発明によれば、通信回線を介してデータ通信を行うアプリケーションの組に組識別情報を割り当て、データを送信する際にはこの組識別情報を利用して通信相手を特定するようにしたので、通信回線が切断され復旧したとき、回線断前に通信をしていたアプリケーションを一意に特定することができる。このため、アプリケーション間で回線断時から処理を再開することが容易にできる。
【００６３】
また、送信データを一時保持して、データ送信時に回線断が発生したとしても、回線復旧後に一時保持したデータを取りだして再送するようにしたので、データを送信するアプリケーションに回線断を知らせることなく再送を行うことができる。
【００６４】
また、回線復旧直後のデータ通信である旨をデータ受信側のアプリケーションに通知するようにしたので、データを受信する側のアプリケーションは、適切な再開処理を行うことができる。
【図面の簡単な説明】
【図１】実施の形態１におけるクライアント・サーバシステムを示した全体構成図である。
【図２】実施の形態１における通信管理テーブルの構成例を示した図である。
【図３】実施の形態１においてクライアント側の通信処理部における処理を示したフローチャートである。
【図４】実施の形態１においてサーバ側の通信処理部における処理を示したフローチャートである。
【図５】実施の形態２におけるクライアント・サーバシステムを示した全体構成図である。
【図６】実施の形態２においてクライアント側の通信処理部におけるデータ送信処理を示したフローチャートである。
【図７】実施の形態２においてサーバ側の通信処理部におけるデータ送信処理を示したフローチャートである。
【図８】実施の形態３においてサーバ側の通信処理部におけるデータ受信処理を示したフローチャートである。
【図９】実施の形態４におけるクライアント・サーバシステムを示した全体構成図である。
【図１０】実施の形態４においてサーバの通信処理部の接続要求処理を示したフローチャートである。
【図１１】実施の形態４における通信管理テーブルの構成例を示した図である。
【図１２】従来からあるデータ通信システムの一例を示したシステム構成図である。
【符号の説明】
５ 通信回線、１０，１０−１，１０−２ クライアント、１１，３１ アプリケーション実行部、１２，３２ 回線制御部、１３，３３ 通信処理部、１４，３６ 送信データ保持部、３０ サーバ、３４ 組識別情報管理部、３５ 通信管理テーブル。
【発明の属する技術分野】
本発明は、データ通信システム、特に通信回線を介したアプリケーション間通信の実行中に通信回線が切断されたとき並びにその後復旧されたときの処理に関する。
【０００２】
【従来の技術】
図１２は、データ通信システムの一形態として従来からあるクライアント・サーバシステムの一例を示したシステム構成図である。図１２において、回線制御部１，２は、それぞれクライアント３、サーバ４において所定の通信プロトコルに基づき通信回線５を介しての通信処理を行うための手段である。アプリケーション実行部６，７は、相互にデータ送受信を行うアプリケーションを実行するための手段であり、実行中の各アプリケーションがデータ通信を行うことになる。
【０００３】
従来のクライアント・サーバシステムにおいて例えばＴＣＰ／ＩＰプロトコルに基づき通信を行う場合、各回線制御部１，２は、通信相手先（サーバ４、クライアント３）との間のソケットをオープンして通信路を確立し、アプリケーション間から／へのデータの受け渡しを行う。
【０００４】
ところで、無線回線や電話回線などの回線品質や使用環境によっては、通信回線５がデータ通信中に一時的に切れてしまう場合がある。通信プロトコルには、データ再送機能を有しているものも少なくないため、一時的な切断であれば、アプリケーションに通信エラーステータスを返すことなく通信プロトコルレベルで自動復旧して対応することも可能であるが、通信プロトコルレベルでの再送の試行回数が所定数を越えてしまったりタイムアウトが発生したりして、結果的に通信プロトコルレベルで対応がしきれない場合がある。
【０００５】
その後、通信回線５が復旧したとき、各アプリケーションは、通信路を再形成し処理を再開することになるが、例えばクライアント３で動作していたデータ送信アプリケーションは、回線断前に通信をしていたサーバ４で待機中のデータ受信アプリケーションと予め決めていた手順に従い通信路を再形成して通信を再開することになる。
【０００６】
【発明が解決しようとする課題】
しかしながら、従来においては、回線が復旧したとき、サーバにおいて複数のデータ受信アプリケーションが待機していた場合、データ送信アプリケーションは、どのデータ受信アプリケーションと通信路を再形成して処理を再開すればよいのか一意に特定できない。このため、データ送信アプリケーションは、やむを得ずデータ受信アプリケーションを再起動して最初から処理をやり直すことになるが、この際、回線断前に行っていた処理結果を破棄しなければならず効率的でない。場合によっては、どこまで前回の処理結果を破棄すべきなのか特定できない場合もあり得る。
【０００７】
本発明は以上のような問題を解決するためになされたものであり、その目的は、回線断から復旧した後にアプリケーション間通信の再開を自動的に行うデータ通信システム及びデータ通信方法を提供することにある。
【０００８】
【課題を解決するための手段】
以上のような目的を達成するために、第１の発明に係るデータ通信システムは、通信回線を介して他のアプリケーションとの間でデータ通信を双方向に行うアプリケーションを実行するアプリケーション実行手段と、所定の通信手順に基づき回線の接続、切断、復旧処理及びその旨の通知を行う回線制御手段とを備えたコンピュータを有するデータ通信システムにおいて、通信回線を介して相互にデータ通信を行うアプリケーションの組を識別するための組識別情報に、組を構成する各アプリケーションの識別情報を対応させて記憶する通信管理テーブルと、アプリケーションの間に通信路が確立された時点で当該通信路が確立されたアプリケーションの組に対して、当該アプリケーションの組を識別するための組識別情報を割り当て前記通信管理テーブルに登録する組識別情報管理手段と、アプリケーションが動作する前記各コンピュータに設けられ、アプリケーション間のデータ通信処理を行う通信処理手段とを有し、前記通信処理手段は、通信路が確立されたときに組識別情報が割り当てられた各アプリケーションに対して、その割り当てた組識別情報を通知し、前記アプリケーション実行手段は、組を構成する他方のアプリケーションに対して送信する通信データに、前記通信処理手段から通知された組識別情報を付加し、前記通信処理手段は、一方のアプリケーションから送信された通信データに付加されている組識別情報に基づき前記通信管理テーブルを検索することによって通信データの送信先となるアプリケーションを特定するものである。
【０００９】
第２の発明に係るデータ通信システムは、少なくとも２台のコンピュータを有するデータ通信システムにおいて、第１のコンピュータは、第２のコンピュータにおいて動作する第２のアプリケーションとの間で通信回線を介してデータ通信を双方向に行う第１のアプリケーションを実行する第１のアプリケーション実行手段と、所定の通信手順に基づき回線の接続、切断、復旧処理及びその旨の通知を行う第１の回線制御手段と、通信回線を介して相互にデータ通信を行う第１及び第２のアプリケーションの組を識別するための組識別情報に、組を構成する各アプリケーションの識別情報を対応させて記憶する通信管理テーブルと、第１及び第２のアプリケーションの間に通信路が確立された時点で当該通信路が確立された第１及び第２のアプリケーションの組に対して、当該第１及び第２のアプリケーションの組を識別するための組識別情報を割り当て前記通信管理テーブルに登録する組識別情報管理手段と、第１及び第２のアプリケーション間のデータ通信処理を行う第１の通信処理手段とを有し、第１のコンピュータと通信を行う少なくとも１台の第２のコンピュータは、第１のコンピュータにおいて動作する第１のアプリケーションとの間で通信回線を介してデータ通信を双方向に行う第２のアプリケーションを実行する第２のアプリケーション実行手段と、所定の通信手順に基づき回線の接続、切断、復旧処理及びその旨の通知を行う第２の回線制御手段と、第１及び第２のアプリケーション間のデータ通信処理を行う第２の通信処理手段とを有し、前記第１の通信処理手段は、通信路が確立されたときに組識別情報が割り当てられた第１のアプリケーション及び前記第２の通信処理手段に対して、その割り当てた組識別情報を通知し、前記第１のアプリケーション実行手段は、第１のアプリケーションと組を構成する第２のアプリケーションに対して送信する通信データに、前記第１の通信処理手段から通知された組識別情報を付加し、前記第１の通信処理手段は、一方のアプリケーションから送信された通信データに付加されている組識別情報に基づき前記通信管理テーブルを検索することによって通信データの送信先となるアプリケーションを特定し、前記第２の通信処理手段は、通信路が確立されたときに組識別情報が割り当てられた第２のアプリケーションに対して、その割り当てた組識別情報を通知し、前記第２のアプリケーション実行手段は、第２のアプリケーションと組を構成する第１のアプリケーションに対して送信する通信データに、前記第２の通信処理手段から通知された組識別情報を付加し、前記第２の通信処理手段は、第２のアプリケーションから送られてきた通信データを前記第１のコンピュータへ送信し、また前記第１のコンピュータから送られてきた通信データを前記第１の通信処理手段により特定された第２のアプリケーションへ送信するものである。
【００１０】
第３の発明に係るデータ通信方法は、通信回線を介して接続された各コンピュータ上のアプリケーション間でデータ通信を双方向に行わせるデータ通信システムにおいて、通信回線を介して相互にデータ通信を行うアプリケーション間に通信路が確立された時点で、当該通信路が確立されたアプリケーションの組を識別するための組識別情報を当該アプリケーションの組に割り当て、その割り当てた組識別情報に当該組を構成する各アプリケーションの識別情報を対応させて通信管理テーブルに登録すると共に、当該組を構成する各アプリケーションに対して、その割り当てた組識別情報を通知する通信路確立時ステップと、アプリケーション間でデータ通信を行う際に、組を構成する他方のアプリケーションに対して送信する通信データに、前記通信路確立時ステップにより通知された組識別情報を付加するステップと、一方のアプリケーションから送信された通信データに付加された組識別情報に基づき前記通信管理テーブルを検索することによって当該通信データの送信先となるアプリケーションを特定するステップとを含むものである。
【００１１】
第４の発明に係るデータ通信システムは、第１又は２の発明において、前記コンピュータは、送信データを保持するための送信データ保持手段を有し、前記通信処理手段は、アプリケーションから渡された送信データを前記送信データ保持手段に一時保持するものである。
【００１２】
第５の発明に係るデータ通信システムは、第２の発明において、前記第１のコンピュータにおける前記第１の通信処理手段は、回線断が発生したときにその旨を示すフラグ情報を組識別情報に付加して前記通信管理テーブルに記憶し、回線復旧直後のデータ通信時に回線復旧直後のデータである旨をデータ受信側のアプリケーションに通知するものである。
【００１５】
第６の発明に係るデータ通信システムは、第２の発明において、前記第１のコンピュータは、サーバコンピュータであり、前記第２のコンピュータは、前記サーバコンピュータと前記通信回線を介してデータ通信を相互に行う１乃至複数のクライアントコンピュータであるものとする。
【００１６】
【発明の実施の形態】
以下、図面に基づいて、本発明の好適な実施の形態について説明する。
【００１７】
実施の形態１．
図１は、本発明に係るデータ通信システムの実施の形態１を示した全体構成図である。本実施の形態では、本発明に係るデータ通信システムを有線若しくは無線の通信回線５を介して接続されたコンピュータ（クライアント１０及びサーバ３０）で構成され、ＴＣＰ／ＩＰに基づきデータ通信を行うクライアント・サーバシステムに適用した場合の例で説明する。なお、クライアント１０及びサーバ３０は、一般的なコンピュータであり、データの送受信を双方向に行うことができる。また、本実施の形態では、便宜上、１台のクライアント１０のみを図示する。なお、本実施の形態では、第１のコンピュータがサーバ３０であり、第２のコンピュータがクライアント１０である。
【００１８】
クライアント１０は、アプリケーション実行部１１、回線制御部１２及び通信処理部１３を有している。アプリケーション実行部１１は、通信回線５を介してデータ通信を行うアプリケーションを実行するアプリケーション実行手段である。回線制御部１２は、回線制御手段として設けられ、所定の通信手順に基づき回線の接続、切断、復旧処理等の回線制御、通信制御を行い、更に回線断、復旧等が発生した旨の通知を行う。ＴＣＰ／ＩＰの通信プロトコルに基づく通信を行う場合、サーバ３０との間のソケットをオープンする。通信処理部１３は、通信処理手段として設けられ、アプリケーション間のデータ通信処理を行う。また、詳細は後述するが、アプリケーションに対してそのアプリケーションに割り当てられた組識別情報を通知する。
【００１９】
サーバ３０は、アプリケーション実行部３１、回線制御部３２、通信処理部３３、組識別情報管理部３４及び通信管理テーブル３５を有している。アプリケーション実行部１１は、通信回線５を介してデータ通信を行うアプリケーションを実行するアプリケーション実行手段であり、同時に複数の通信アプリケーションを実行することができる。回線制御部１２は、回線制御手段として設けられ、所定の通信手順に基づき回線の接続、切断、復旧処理等の回線制御、通信制御を行い、更に回線断、復旧等が発生した旨の通知を行う。ＴＣＰ／ＩＰの通信プロトコルに基づく通信を行う場合、クライアント１０との間のソケットをオープンする。通信処理部３３は、通信処理手段として設けられ、アプリケーション間のデータ通信処理を行う。また、詳細は後述するが、アプリケーションに対してそのアプリケーションに割り当てられた組識別情報を通知する。組識別情報管理部３４は、通信回線５を介して相互にデータ通信を行う相互のアプリケーションの組を識別するための組識別情報をそのアプリケーション組に割り当てる組識別情報管理手段であり、本実施の形態においては、通信処理部３３に組み込まれている。すなわち、本実施の形態における通信処理部３３は、通信処理機能と共に組識別情報管理機能を有している。通信管理テーブル３５は、組識別情報に各アプリケーションを特定しうるアプリケーション識別情報を対応させて記憶する。このテーブルへの情報設定及び管理は、通信処理部３３が行う。
【００２０】
図２は、本実施の形態における通信管理テーブル３５の構成例を示した図である。このテーブルにおいて、通信を行う各アプリケーションを特定し関連づけている。クライアントアプリケーション識別情報としては、クライアント１０側のアプリケーションを特定するための識別情報としてＭＡＣアドレス及び使用する通信ソケットハンドルの番号を含んでいる。本実施の形態におけるクライアント１０のアプリケーション実行部１１は、同時には唯一つの通信アプリケーションのみを実行するため、他のクライアントと識別可能なＭＡＣアドレスをアプリケーション識別情報として使用するが、複数動作させるのであれば、ＩＰアドレスやクライアントアプリケーション名等他の情報も付加する必要がある。サーバアプリケーション識別情報としては、サーバ３０側のアプリケーションを特定するための識別情報としてサーバ名及び使用する通信ソケットハンドルの番号を含んでいる。このアプリケーションの組に各組を識別するための組識別情報としてセッションＩＤを割り当て、更にこのレコードデータの有効“Ｙ”／無効“Ｎ”を示す有効フラグを付加する。なお、本実施の形態で用いる各アプリケーションの識別情報は例示であり、それぞれに識別機能を有するものであれば他の情報を用いてもよい。
【００２１】
上記構成のうち、アプリケーション実行部１１，３１、通信処理部１３，３３及び組識別情報管理部３４は、各機能を実現するアプリケーションソフトウェアをＣＰＵ上で実行することで実現される。また、回線制御部１２，３２は、ＴＣＰ／ＩＰなどの所定の通信プロトコルに基づいた通信を実現するためのハードウェア、ソフトウェア等で実現される。通信管理テーブル３５は、メモリ上に設けるが、ディスク装置などの読み書き可能な記憶媒体でも実現可能である。
【００２２】
本実施の形態において特徴的なことは、通信を行う各アプリケーションの組にセッションＩＤを割り当て、データ送信を行う際には、このＩＤを指定して送信先を特定するようにしたことである。これにより、回線が切断した後でも回線断前に通信をしていた相手を回線復旧後においても一意に特定することができる。このため、アプリケーション間で相互にやり取りを行うことで途中であったアプリケーションの処理を継続して行うことができるようになる。
【００２３】
図３は、クライアント１０側の通信処理部１３における処理を示したフローチャートであり、図４は、サーバ３０の側の通信処理部３３における処理を示したフローチャートである。次に、これらの図を用いて本実施の形態における動作について説明するが、まず、通信路を確立し、データ通信が正常に行われ、正常に終了するときの処理から説明する。
【００２４】
クライアント１０において常時稼動している通信処理部１３は、アプリケーション実行部１１で動作しているアプリケーション（以下、「クライアントアプリケーション」という）からサーバ３０側のアプリケーション（以下、「サーバアプリケーション」という）と通信を行うための要求を受け付けると、サーバ３０側に接続要求を出す（ステップ１００，１０１）。
【００２５】
サーバ３０において常時稼動している通信処理部３３は、通信回線５を介してクライアント１０からの接続要求を受け付けると（ステップ２００）、まず、通信管理テーブル３５から空いているエントリを探してセッションＩＤを取得する（ステップ２０１）。エントリの空きは、有効フラグを参照することで把握できる。すなわち、“Ｎ”の有効フラグのエントリを未使用と判断できる。そして、通信処理部３３は、通信先となるサーバアプリケーションを起動する（ステップ２０２）。接続要求には、クライアント１０側のＭＡＣアドレス、通信ソケットハンドル番号及び通信相手先となるサーバ名が含まれているので、これから起動の対象を特定できる。そして、起動されたサーバアプリケーションにセッションＩＤを通知する（ステップ２０３）。サーバアプリケーションが起動されクライアントアプリケーションとの通信路が確立されると、通信処理部３３は、通信管理テーブル３５に各アプリケーションの識別情報を書き込み（ステップ２０４）、有効フラグを“Ｙ”に変更することでこのアプリケーション組のエントリの登録を終えた後（ステップ２０５）、クライアント１０へセッションＩＤとともに接続処理の完了を通知する（ステップ２０６）。
【００２６】
クライアント１０において、通信処理部１３は、送られてきたセッションＩＤをデータ通信要求元のアプリケーションに渡す（ステップ１０３）。
【００２７】
このようにして、アプリケーション間に通信路が確立されると、次のようにしてデータの送受信が行われる。
【００２８】
クライアントアプリケーションがサーバアプリケーションにデータを送信する場合、クライアントアプリケーションは、送信するデータに通信路形成時に知らされたセッションＩＤを付加して送信要求を通信処理部１３に渡すことになる。通信処理部１３は、このセッションＩＤが付加されたデータをサーバ３０へ送信する（ステップ１００，１１１）。
【００２９】
サーバ３０において、通信処理部３３は、クライアント１０からデータを受信すると（ステップ２００）、受信データに含まれているセッションＩＤにより通信管理テーブル３５を検索してサーバ名を取得することによって通信相手となるサーバアプリケーションを特定し（ステップ２１１）、そのアプリケーションにデータを渡す（ステップ２１２）。このようにして、クライアントアプリケーションから送出されたデータは、特定のサーバアプリケーションに送られる。
【００３０】
一方、サーバアプリケーションがクライアントアプリケーションにデータを送信する場合、サーバアプリケーションは、送信するデータにセッションＩＤを付加して送出する。通信処理部３３は、受け取ったセッションＩＤにより通信管理テーブル３５を検索して通信相手となるクライアントアプリケーションを特定し（ステップ２２１）、そのアプリケーションが動作するクライアント１０にデータを送信する（ステップ２２２）。
【００３１】
クライアント１０において、通信処理部１３は、サーバ３０からデータを受信すると（ステップ１００）、通信相手となるクライアントアプリケーションにデータを渡す（ステップ１２１）。このようにして、サーバアプリケーションから送出されたデータは、特定のクライアントアプリケーションに送られる。
【００３２】
アプリケーション間のデータのやり取りが完了して通信を終了する場合、クライアントアプリケーションは、その切断要求にセッションＩＤを付加して送出する。通信処理部１３は、このセッションＩＤが付加された切断要求データをサーバ３０へ送信する（ステップ１００，１３１）。
【００３３】
サーバ３０において、通信処理部３３は、受信データに含まれているセッションＩＤにより通信管理テーブル３５を検索して通信相手となっていたサーバアプリケーションを特定し（ステップ２３１）、その実行を終了し、又は自ら終了させる（ステップ２３２）。そして、通信を終了したそのアプリケーションの組のエントリの有効フラグを“Ｎ”に変更する（ステップ２３３）。なお、このとき、各回線制御部１２，３２は、アプリケーション間の通信路を切断する。
【００３４】
以上のようにして、アプリケーション間の通信を行うが、本実施の形態においては、セッションＩＤを管理するための通信管理テーブル３５を設け、セッションＩＤを利用して通信相手を特定してデータの送受信を行うことを特徴としている。
【００３５】
次に、データ通信中に通信回線５が切断されたとき及び回線が復旧したときの処理について説明する。
【００３６】
まず、クライアント１０の通信処理部１３は、クライアントアプリケーションからの依頼によりデータを送信しようとするが（ステップ１００，１１１）、通信回線５が切断されているのでデータを正常に送信することはできない。本実施の形態では、通信処理部１３のエラー処理としてその旨をクライアントアプリケーションに返すようにしてもよい（ステップ１１２，１１３）。これにより、クライアントアプリケーションは、状況に応じたエラー発生時の処理を行うことができる。特に、通信処理部３３は、回線制御部１２から通信回線５が切断／復旧したというの通知を受けるので、クライアントアプリケーションに通信回線５が復旧した旨の通知をしてデータの再送をさせることができる（ステップ１００，１１１）。
【００３７】
一方、サーバ３０の通信処理部３３は、サーバアプリケーションからの依頼によりデータを送信しようとするが（ステップ２００，２２１，２２２）、回線が切断されているのでデータを正常に送信することはできない。本実施の形態では、通信処理部３３のエラー処理としてその旨をサーバアプリケーションに返すようにしてもよい（ステップ２２３，２２４）。これにより、サーバアプリケーションは、状況に応じたエラー発生時の処理を行うことができる。その後、通信処理部３３は、回線制御部３２から通知を受けることで通信回線５が復旧したことを知ることができる。ここで、通信処理部３３は、サーバアプリケーションに通信回線５が復旧した旨の通知をしてデータの再送をさせることができる（ステップ２００，２２１，２２２）。
【００３８】
このようにして、通信回線５が切断された後もアプリケーション間通信を再開することができるが、本実施の形態においては、セッションＩＤを用いて通信相手を特定しているので、サーバアプリケーションを再起動し直して処理を最初からやり直す必要もなく、回線断発生時に中断したところから処理を再開させることができる。すなわち、通信路が切断されたアプリケーションは、回線断による通信エラーが発生したとしても通信回線５が回復するまでの間、処理を途中で終了させずに待機していればよい。そして、回線が復旧したとき、回線断前の相手と改めてデータ通信を再開することになるが、サーバ３０において待機中のサーバアプリケーションが複数存在していても、本実施の形態ではセッションＩＤを用いて通信相手を特定するようにしているので、通信管理テーブル３５を参照することによってクライアントアプリケーションと回線断前に通信をしていたサーバアプリケーションを待機中の中から一意に特定することができる。そして、回線断発生時に中断したところから処理を再開すればよい。これは、トランザクション処理を行うサーバアプリケーションにとっては、回線断前に行った処理を無駄にせずに済むので非常に効果的である。
【００３９】
なお、本実施の形態においては、１台のクライアント１０のみを通信回線５に接続した場合の例で説明したが、複数台接続した場合も適用することは可能である。
【００４０】
また、本実施の形態では、アプリケーションに対してセッションＩＤを伝え、アプリケーションに送信すべきデータにセッションＩＤを付加させるようにしたが、通信処理部１３がクライアント１０におけるセッションＩＤを一括管理し、サーバ３０への送出前に送信データに付加するようにしてもよい。
【００４１】
実施の形態２．
上記実施の形態１では、回線断が発生した後の復旧処理は、基本的には通信を行うアプリケーションの組に委ねていた。すなわち、処理を通信エラー発生として終了させたり、回線復旧まで待機してデータの再送を行うこともアプリケーションに任せていた。本実施の形態では、図５に示したように、クライアント１０及びサーバ３０に、送信データを保持するための送信データ保持部１４，３６をそれぞれ設け、各通信処理部１３，３３に、データ送信時にアプリケーションから渡された送信データを送信データ保持部１４，３６に一時保持させるようにしたことを特徴としている。
【００４２】
図６及び図７は、各通信処理部１３，３３におけるデータ送信処理を示したフローチャートであり、図３におけるステップ１００，１１１〜１１３及び図４におけるステップ２００，２２１〜２２４に置き換わるフローである。但し、同じ処理には、同じ符号を付ける。次に、本実施の形態における動作について説明するが、各通信処理部１３，３３におけるその他の通信処理は、図３、４と同じであるので説明を省略する。
【００４３】
クライアントアプリケーションがサーバアプリケーションにデータを送信する場合、クライアントアプリケーションは、送信するデータにセッションＩＤを付加して送出する。通信処理部１３は、このセッションＩＤが付加されたデータを受け取ると（ステップ１００）、そのデータを送信データ保持部１４に書き込むことで一時保持する（ステップ１１４）。その後、通信処理部１３は、データをサーバ３０へ送信するが（ステップ１１１）、回線断による通信エラーが発生した場合（ステップ１１２）、通信回線５が復旧するまで待機し、通信回線５の復旧を確認した後、送信データ保持部１４に一時保持したデータを取り出す（ステップ１１５）。そして、その取り出したデータを再送する（ステップ１１１）。
【００４４】
一方、サーバアプリケーションがクライアントアプリケーションにデータを送信する場合、サーバアプリケーションは、送信するデータにセッションＩＤを付加して送出する。通信処理部３３は、このセッションＩＤが付加されたデータを受け取ると（ステップ２００）、その受け取ったセッションＩＤにより通信管理テーブル３５を検索して通信相手となるクライアントアプリケーションを特定するとともに（ステップ２２１）、そのデータを送信データ保持部３６に書き込むことで一時保持する（ステップ２２５）。その後、通信処理部１３は、データをクライアント１０へ送信するが（ステップ２２２）、回線断による通信エラーが発生した場合（ステップ２２３）、通信回線５が復旧するまで待機し、通信回線５の復旧を確認した後、送信データ保持部３６に一時保持したデータを取り出す（ステップ２２６）。そして、その取り出したデータを再送する（ステップ２２２）。
【００４５】
以上のようにして、本実施の形態によれば、送信データを一時保持して、データ送信時に回線断が発生したとしても、回線復旧後に一時保持したデータを取り出して再送するようにしたので、データを送信するアプリケーションに回線断を知らせることなく再送を行うことができる。このため、アプリケーションは、回線断に基づく処理を用意しておく必要がないため、アプリケーションの開発者にかかる負担を軽減することができる。
【００４６】
なお、送信データ保持部１４，３６は、メモリ又はディスク装置などの読み書き可能な記憶媒体で実現することができる。
【００４７】
実施の形態３．
本実施の形態では、通信回線５が復旧した後、最初にクライアント１０からデータが送られてきたとき、回線復旧直後のデータである旨をサーバアプリケーションに通知するようにしたことを特徴としている。このため、本実施の形態において有効フラグには、有効“Ｙ”／無効“Ｎ”の他に回線断中を示す有効フラグ“Ｅ”が設定できるようにする。この有効フラグ“Ｅ”は、次のようにして設定される。すなわち、通信処理部３３は、通信回線５が切断したという回線制御部３２からの通知を受け取ると、通信管理テーブル３５において“Ｙ”となっている全ての有効フラグを回線断が発生したことを示すための“Ｅ”に変更することになる。
【００４８】
以下、この処理について図８に示したフローチャートを用いて説明する。なお、図８のフローチャートは、図４におけるステップ２００，２１１，２１２に置き換わるフローである。
【００４９】
サーバ３０において、通信処理部３３は、クライアント１０からデータを受信すると（ステップ２００）、受信データに含まれているセッションＩＤにより通信管理テーブル３５を検索して通信相手となるサーバアプリケーションを特定する（ステップ２１１）。このとき、このアプリケーションの組のエントリの有効フラグも参照する。有効フラグが“Ｙ”であり“Ｅ”でなければ、受信したデータを特定したサーバアプリケーションに渡す（ステップ２１２）。有効フラグが“Ｅ”であれば、データ受信の直前に通信回線５が切断されていたと判断できるので（ステップ２１３）、その旨を受信データと共にサーバアプリケーションに渡す（ステップ２１４）。そして、通信管理テーブル３５における当該アプリケーションの組の“Ｅ”となっている有効フラグを“Ｙ”に変更する（ステップ２１５）。
【００５０】
本実施の形態によれば、回線復旧直後のデータ通信時に回線復旧直後のデータである旨をサーバアプリケーションに通知することで、データ通信の再開であることを知らせることができる。これにより、サーバアプリケーションは、適切な再開処理を行い、その後に回線断前の処理を継続して行うことができる。
【００５１】
なお、本実施の形態では、クライアント１０がデータ送信を行うようにしたが、サーバ３０からクライアント１０にデータを送信する場合にも適用することができる。この場合、通信処理部３３は、サーバアプリケーションからセッションＩＤが付加されたデータを受け取ると、受け取ったセッションＩＤにより通信管理テーブル３５を検索して特定したクライアントアプリケーションにデータを送信することになるが、この際、該当するエントリの有効フラグが“Ｅ”であれば、データ送信の直前に通信回線５が切断されていたと判断できるので、その旨を送信データと共にクライアントアプリケーションに渡すことができる。そして、通信管理テーブル３５における当該アプリケーションの組の“Ｅ”となっている有効フラグを“Ｙ”に変更する。このようにして、クライアントアプリケーションに対しても回線復旧後における処理であることを知らせることができる。
【００５２】
また、本実施の形態では、“Ｅ”を設定可能とすることで有効フラグを有効利用して回線断の発生を通信処理部３３に知らせるようにしているが、有効フラグとは別個に回線断が発生した旨を示すフラグ情報を設けて組識別情報に付加して記憶するようにしてもよい。
【００５３】
実施の形態４．
上記各実施の形態においては、クライアントとサーバとの間の通信回線が切断した場合、その間の通信回線が復旧するのを待ってアプリケーション通信を再開するようにしていた。本実施の形態では、その間の通信回線５の回復を待たずに、クライアントがサーバと行っていたデータ通信を、他のクライアントがそのクライアントに代行して処理を継続できるようにしたことを特徴としている。
【００５４】
図９は、本実施の形態におけるクライアント・サーバシステムの全体構成図である。図９には、通信回線５に２台のクライアント１０−１，１０−２を接続したシステムが示されている。なお、各クライアント１０−１，１０−２の構成は、実施の形態１に示したクライアントと同一構成である。
【００５５】
図１０は、本実施の形態におけるサーバ３０の通信処理部３３の接続要求を受け付けたときの処理を示したフローチャートであり、図４に示したステップ２００〜２０６に置き換わるフローである。次に、このフローチャートに基づき、第２のコンピュータであるクライアント１０−１がサーバ３０と通信を行っているときに、その間の通信回線５が切断され、第３のコンピュータであるクライアント１０−２がクライアント１０−１の代わりにサーバ３０とのアプリケーション間通信を引き継ぐ場合を例にして本実施の形態における動作について説明する。
【００５６】
まず、クライアント１０−１は、実施の形態１と同様の手順でサーバ３０との間で通信路を形成し、データ通信を行っている。但し、サーバ３０へ送られる接続要求には、ＭＡＣアドレスの代わりに論理名がクライアントアプリケーション識別情報として含まれている。ＴＣＰ／ＩＰの場合、ＩＰアドレスを論理名として使用することができる。このＩＰアドレスを用いた本実施の形態における通信管理テーブル３５の内容例を図１１に示す。
【００５７】
ここで、クライアント１０−１とサーバ３０との間の通信回線５が切断されたとする。なお、通信処理部３３の回線切断時処理によりこのアプリケーション組のエントリの有効フラグは“Ｅ”に変更される。クライアント１０−２は、その回線断をクライアント１０−１からの通知を受けたり、自ら回線状況を監視するなど何らかの方法で知ると、クライアント１０−１において通信をしていたのと同一クライアントアプリケーションから接続要求を送出させる。この接続要求処理については、実施の形態１と同一である。但し、前述したとおり、クライアント１０−２からサーバ３０へ送られる接続要求には、共通のＩＰアドレスが指定されている。なお、クライアント１０−２は、このＩＰアドレスをクライアント１０−１からの通知を受けたり、予め設定しておくなどして知っている。
【００５８】
図１０において、サーバ３０の通信処理部３３は、クライアント１０−２からの接続要求を受信すると（ステップ２００）、通信管理テーブル３５を参照し、送られてきた接続要求に指定されたＩＰアドレスを含み、かつ有効フラグが“Ｅ”のエントリを検索する。この内容のエントリが存在しなければ、新規な接続要求であると判断し、実施の形態１で示した通常の接続要求処理を行う（ステップ２０７，２０１〜２０６）。一方、該当するエントリが存在すれば、他のクライアント１０−２がクライアント１０−１の代わりに処理を継続するための再接続要求であると判断する（ステップ２０７）。なお、送信元がクライアント１０−１であれば、送られてくるのは接続要求ではなく送信データのはずである。また、受け取ったデータに含まれているＭＡＣアドレスを参照してクライアント１０−１からのデータでないことを知ることができる。他のクライアント１０−２からの接続要求である場合、通信路は新規に形成されるため、通信処理部３３は、通信管理テーブル３５のソケットハンドルを更新する（ステップ２０８）。そして、再接続である旨を待機中のサーバアプリケーションへ通知する（ステップ２０９）。これにより、サーバアプリケーションは、再接続要求であることによる適切な処理を行うことができる。そして、通信処理部３３は、通信管理テーブル３５の有効フラグを“Ｅ”から“Ｙ”に変更し（ステップ２０５）、クライアント１０−１のクライアントアプリケーションとの組で使用していたセッションＩＤをクライアント１０−１へ通知する（ステップ２０６）。この後、クライアント１０−２のクライアントアプリケーションとサーバ３０のサーバアプリケーションは、通信を行うことができるようになるが、各アプリケーションとも再接続である旨を知っているので、アプリケーション間でやり取りを行い、クライアント１０−１のアプリケーションとした処理を途中からでも引き継ぐことができる。
【００５９】
以上のように、本実施の形態によれば、クライアントアプリケーションの識別情報にＩＰアドレスを用いることによって通信回線が切断された後も他のクライアントによって処理を継続させることができる。また、他のクライアントからの再接続である旨をサーバアプリケーションに伝えることができるので、サーバアプリケーションに適切な再接続処理を行わせることができる。
【００６０】
なお、本実施の形態では、論理名としてＩＰアドレスを用いたが、別途論理名を設定するようにしてもよい。
【００６１】
上記各実施の形態においては、クライアント・サーバシステムを例にして本発明に係るデータ通信システムを説明したが、コンピュータを接続する通信線が切断される可能性のある様々な形態のデータ通信システムに適用できることはいうまでもない。また、クライアント・サーバシステムの特性からして通信管理テーブル３５を接続要求を受けるであろうサーバ３０側に設けるようにしたが、通信管理テーブル３５を接続要求する側に設けるようにしても、また、散在させても本発明を適用することができる。
【００６２】
【発明の効果】
本発明によれば、通信回線を介してデータ通信を行うアプリケーションの組に組識別情報を割り当て、データを送信する際にはこの組識別情報を利用して通信相手を特定するようにしたので、通信回線が切断され復旧したとき、回線断前に通信をしていたアプリケーションを一意に特定することができる。このため、アプリケーション間で回線断時から処理を再開することが容易にできる。
【００６３】
また、送信データを一時保持して、データ送信時に回線断が発生したとしても、回線復旧後に一時保持したデータを取りだして再送するようにしたので、データを送信するアプリケーションに回線断を知らせることなく再送を行うことができる。
【００６４】
また、回線復旧直後のデータ通信である旨をデータ受信側のアプリケーションに通知するようにしたので、データを受信する側のアプリケーションは、適切な再開処理を行うことができる。
【図面の簡単な説明】
【図１】実施の形態１におけるクライアント・サーバシステムを示した全体構成図である。
【図２】実施の形態１における通信管理テーブルの構成例を示した図である。
【図３】実施の形態１においてクライアント側の通信処理部における処理を示したフローチャートである。
【図４】実施の形態１においてサーバ側の通信処理部における処理を示したフローチャートである。
【図５】実施の形態２におけるクライアント・サーバシステムを示した全体構成図である。
【図６】実施の形態２においてクライアント側の通信処理部におけるデータ送信処理を示したフローチャートである。
【図７】実施の形態２においてサーバ側の通信処理部におけるデータ送信処理を示したフローチャートである。
【図８】実施の形態３においてサーバ側の通信処理部におけるデータ受信処理を示したフローチャートである。
【図９】実施の形態４におけるクライアント・サーバシステムを示した全体構成図である。
【図１０】実施の形態４においてサーバの通信処理部の接続要求処理を示したフローチャートである。
【図１１】実施の形態４における通信管理テーブルの構成例を示した図である。
【図１２】従来からあるデータ通信システムの一例を示したシステム構成図である。
【符号の説明】
５ 通信回線、１０，１０−１，１０−２ クライアント、１１，３１ アプリケーション実行部、１２，３２ 回線制御部、１３，３３ 通信処理部、１４，３６ 送信データ保持部、３０ サーバ、３４ 組識別情報管理部、３５ 通信管理テーブル。
Claims (6)
- 通信回線を介して他のアプリケーションとの間でデータ通信を双方向に行うアプリケーションを実行するアプリケーション実行手段と、
所定の通信手順に基づき回線の接続、切断、復旧処理及びその旨の通知を行う回線制御手段と、
を備えたコンピュータを有するデータ通信システムにおいて、
通信回線を介して相互にデータ通信を行うアプリケーションの組を識別するための組識別情報に、組を構成する各アプリケーションの識別情報を対応させて記憶する通信管理テーブルと、
アプリケーションの間に通信路が確立された時点で当該通信路が確立されたアプリケーションの組に対して、当該アプリケーションの組を識別するための組識別情報を割り当て前記通信管理テーブルに登録する組識別情報管理手段と、
アプリケーションが動作する前記各コンピュータに設けられ、アプリケーション間のデータ通信処理を行う通信処理手段と、
を有し、
前記通信処理手段は、通信路が確立されたときに組識別情報が割り当てられた各アプリケーションに対して、その割り当てた組識別情報を通知し、
前記アプリケーション実行手段は、組を構成する他方のアプリケーションに対して送信する通信データに、前記通信処理手段から通知された組識別情報を付加し、
前記通信処理手段は、一方のアプリケーションから送信された通信データに付加されている組識別情報に基づき前記通信管理テーブルを検索することによって通信データの送信先となるアプリケーションを特定することを特徴とするデータ通信システム。 - 少なくとも２台のコンピュータを有するデータ通信システムにおいて、
第１のコンピュータは、
第２のコンピュータにおいて動作する第２のアプリケーションとの間で通信回線を介してデータ通信を双方向に行う第１のアプリケーションを実行する第１のアプリケーション実行手段と、
所定の通信手順に基づき回線の接続、切断、復旧処理及びその旨の通知を行う第１の回線制御手段と、
通信回線を介して相互にデータ通信を行う第１及び第２のアプリケーションの組を識別するための組識別情報に、組を構成する各アプリケーションの識別情報を対応させて記憶する通信管理テーブルと、
第１及び第２のアプリケーションの間に通信路が確立された時点で当該通信路が確立された第１及び第２のアプリケーションの組に対して、当該第１及び第２のアプリケーションの組を識別するための組識別情報を割り当て前記通信管理テーブルに登録する組識別情報管理手段と、
第１及び第２のアプリケーション間のデータ通信処理を行う第１の通信処理手段と、
を有し、
第１のコンピュータと通信を行う少なくとも１台の第２のコンピュータは、
第１のコンピュータにおいて動作する第１のアプリケーションとの間で通信回線を介してデータ通信を双方向に行う第２のアプリケーションを実行する第２のアプリケーション実行手段と、
所定の通信手順に基づき回線の接続、切断、復旧処理及びその旨の通知を行う第２の回線制御手段と、
第１及び第２のアプリケーション間のデータ通信処理を行う第２の通信処理手段と、
を有し、
前記第１の通信処理手段は、通信路が確立されたときに組識別情報が割り当てられた第１のアプリケーション及び前記第２の通信処理手段に対して、その割り当てた組識別情報を通知し、
前記第１のアプリケーション実行手段は、第１のアプリケーションと組を構成する第２のアプリケーションに対して送信する通信データに、前記第１の通信処理手段から通知された組識別情報を付加し、
前記第１の通信処理手段は、一方のアプリケーションから送信された通信データに付加されている組識別情報に基づき前記通信管理テーブルを検索することによって通信データの送信先となるアプリケーションを特定し、
前記第２の通信処理手段は、通信路が確立されたときに組識別情報が割り当てられた第２のアプリケーションに対して、その割り当てた組識別情報を通知し、
前記第２のアプリケーション実行手段は、第２のアプリケーションと組を構成する第１のアプリケーションに対して送信する通信データに、前記第２の通信処理手段から通知された組識別情報を付加し、
前記第２の通信処理手段は、第２のアプリケーションから送られてきた通信データを前記第１のコンピュータへ送信し、また前記第１のコンピュータから送られてきた通信データを前記第１の通信処理手段により特定された第２のアプリケーションへ送信することを特徴とするデータ通信システム。 - 通信回線を介して接続された各コンピュータ上のアプリケーション間でデータ通信を双方向に行わせるデータ通信システムにおいて、
通信回線を介して相互にデータ通信を行うアプリケーション間に通信路が確立された時点で、当該通信路が確立されたアプリケーションの組を識別するための組識別情報を当該アプリケーションの組に割り当て、その割り当てた組識別情報に当該組を構成する各アプリケーションの識別情報を対応させて通信管理テーブルに登録すると共に、当該組を構成する各アプリケーションに対して、その割り当てた組識別情報を通知する通信路確立時ステップと、
アプリケーション間でデータ通信を行う際に、組を構成する他方のアプリケーションに対して送信する通信データに、前記通信路確立時ステップにより通知された組識別情報を付加するステップと、
一方のアプリケーションから送信された通信データに付加された組識別情報に基づき前記通信管理テーブルを検索することによって当該通信データの送信先となるアプリケーションを特定するステップと、
を含むことを特徴とするデータ通信方法。 - 前記コンピュータは、送信データを保持するための送信データ保持手段を有し、
前記通信処理手段は、アプリケーションから渡された送信データを前記送信データ保持手段に一時保持することを特徴とする請求項１又は２いずれかに記載のデータ通信システム。 - 前記第１のコンピュータにおける前記第１の通信処理手段は、回線断が発生したときにその旨を示すフラグ情報を組識別情報に付加して前記通信管理テーブルに記憶し、回線復旧直後のデータ通信時に回線復旧直後のデータである旨をデータ受信側のアプリケーションに通知することを特徴とする請求項２記載のデータ通信システム。
- 前記第１のコンピュータは、サーバコンピュータであり、
前記第２のコンピュータは、前記サーバコンピュータと前記通信回線を介してデータ通信を相互に行う１乃至複数のクライアントコンピュータであることを特徴とする請求項２記載のデータ通信システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP13993697A JP3608905B2 (ja) | 1997-05-29 | 1997-05-29 | データ通信システム及びデータ通信方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP13993697A JP3608905B2 (ja) | 1997-05-29 | 1997-05-29 | データ通信システム及びデータ通信方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10336272A JPH10336272A (ja) | 1998-12-18 |
| JP3608905B2 true JP3608905B2 (ja) | 2005-01-12 |
Family
ID=15257128
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP13993697A Expired - Fee Related JP3608905B2 (ja) | 1997-05-29 | 1997-05-29 | データ通信システム及びデータ通信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3608905B2 (ja) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100309256B1 (ko) * | 1999-10-25 | 2001-11-02 | 서평원 | 게이트웨이 시스템에서 세션 식별자 설정 방법 |
| WO2001077844A1 (fr) * | 2000-04-10 | 2001-10-18 | Fujitsu Limited | Systeme de traitement d'informations et serveur associe |
| US7080404B2 (en) * | 2002-04-01 | 2006-07-18 | Microsoft Corporation | Automatic re-authentication |
| US7149220B2 (en) * | 2002-04-25 | 2006-12-12 | International Business Machines Corporation | System, method, and product for managing data transfers in a network |
| US7529823B2 (en) * | 2003-03-27 | 2009-05-05 | Microsoft Corporation | Notifications for shared resources |
| US20040260594A1 (en) * | 2003-06-18 | 2004-12-23 | Maddox Edward P. | Maintenance and inspection system and method |
| JP4785338B2 (ja) * | 2003-09-18 | 2011-10-05 | 株式会社野村総合研究所 | データ転送方法、通信システム、および通信装置 |
| US7594018B2 (en) * | 2003-10-10 | 2009-09-22 | Citrix Systems, Inc. | Methods and apparatus for providing access to persistent application sessions |
| JP4965562B2 (ja) * | 2006-04-13 | 2012-07-04 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 組込機器による外部との通信を代行サーバにより制御させる技術 |
| JP5069722B2 (ja) | 2009-06-19 | 2012-11-07 | 株式会社エヌ・ティ・ティ・ドコモ | 移動通信端末、及びデータダウンロード方法 |
| CN108803502B (zh) | 2017-04-27 | 2022-07-26 | 横河电机株式会社 | 数据收集装置及***、数据服务器、数据收集方法及计算机可读取的非易失性的记录介质 |
-
1997
- 1997-05-29 JP JP13993697A patent/JP3608905B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH10336272A (ja) | 1998-12-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7929422B2 (en) | Method of moving a transport connection among network hosts | |
| US7526549B2 (en) | Cluster data port services for clustered computer system | |
| JP4515800B2 (ja) | メッセージ交換システムにおける可用性および拡張性をアプリケーションに透過的に向上させる方法 | |
| JP3254405B2 (ja) | ホスト間の接続を維持する方法 | |
| US6061807A (en) | Methods systems and computer products for error recovery of endpoint nodes | |
| EP0295380A2 (en) | Method of disseminating network state information | |
| JP2004032224A (ja) | サーバ引継システムおよびその方法 | |
| US7801029B2 (en) | System for selecting routes for retransmission in a network | |
| EP1584172A1 (en) | Message transfer using multiplexed connections in an osi-tp environment | |
| JP2002202953A (ja) | プロセス障害またはシステム障害後の回復 | |
| JP3608905B2 (ja) | データ通信システム及びデータ通信方法 | |
| US6880013B2 (en) | Permanent TCP connections across system reboots | |
| WO2012009936A1 (zh) | 集群管理***及方法 | |
| US7178051B2 (en) | Method for synchronous support of fault-tolerant and adaptive communication | |
| US7191356B2 (en) | Method for asynchronous support of fault-tolerant and adaptive communication | |
| WO2012127644A1 (ja) | 通信ノード装置システム、装置、及び方法 | |
| US7689702B1 (en) | Methods and apparatus for coordinating processing of network connections between two network protocol stacks | |
| US20030145050A1 (en) | Node self-start in a decentralized cluster | |
| JP4757670B2 (ja) | システム切替方法、その計算機システム及びプログラム | |
| US5894547A (en) | Virtual route synchronization | |
| JP3498666B2 (ja) | データ転送装置、データ転送システム、データ転送方法及び記憶媒体 | |
| JP3088683B2 (ja) | データ通信システム | |
| US8549345B1 (en) | Methods and apparatus for recovering from a failed network interface card | |
| JP2007141129A (ja) | システム切替方法、その計算機システム及びプログラム | |
| JP3403021B2 (ja) | 伝送路二重化処理方式 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040715 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20040715 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041012 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071022 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081022 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091022 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091022 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101022 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111022 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121022 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131022 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |