(57)【特許請求の範囲】
【請求項１】
通信対象データを格納する領域を有する送信側バッファを備える送信側装置と、通信対象データを格納する領域を有する受信側バッファを備える、前記送信側装置と異機種の受信側装置との間でデータを通信する方法であって、
通信対象データの内、送信側装置から受信側装置に送信するデータである送信データを送信側バッファに格納するステップと、
送信側バッファから送信データを獲得して、獲得した送信データにシリアル番号を付与し、予め定めたプロトコルを用いて、受信側装置に送信するステップと、
送信側装置から送信されてきたデータを受信側バッファに格納するステップと、
受信側バッファからデータを獲得して、獲得したデータに対して、受信処理手順を定めた受信処理プログラムにしたがって受信処理した処理結果を表す応答データを、シリアル番号順に、前記予め定めたプロトコルを用いて、送信側装置に送信するステップと、
受信側装置から前記応答データとして送信側装置に送信された通信データのシリアル番号が連番であるか否かを判定し、連番でないときに、異常時処理を行い、連番であるときに、前記受信処理の対象となったデータを前記受信側バッファから削除するとともに、前記受信側バッファから削除されたデータに対応する前記送信側バッファ内のデータも、前記送信側バッファから削除するステップと、を含むデータ通信方法。
【請求項２】
請求項１において、前記異常時処理は、送信側装置または受信側装置が行う送信処理をリトライする処理であること、を特徴とするデータ通信方法。
【請求項３】
通信対象データを格納する領域を有する送信側バッファを備える送信側装置と、通信対象データを格納する領域を有する受信側バッファを備える、前記送信側装置と異機種の受信側装置との間でデータを通信するシステムであって、
前記送信側装置は、
通信対象データの内、送信側装置から受信側装置に送信するデータである送信データを、送信側バッファに格納する、第１の格納処理手段と、
送信側バッファから送信データを獲得して、獲得した送信データにシリアル番号を付与し、予め定めたプロトコルを用いて、受信側装置に送信する、第１の送信処理手段と、
受信側装置から応答データとして送信された通信データのシリアル番号が連番であるか否かを判定し、連番でないときに、異常時処理を行い、連番であるときに、前記送信データを前記送信側バッファから削除する第１の処理手段と、を備え、また、
前記受信側装置は、
送信側装置から送信されてきた送信データを受信側バッファに格納する、第２の格納処理手段と、
受信側バッファからデータを獲得して、獲得したデータに対して、受信処理手順を定めた受信処理プログラムにしたがって受信処理した処理結果を表す応答データを、シリアル番号順に、前記予め定めたプロトコルを用いて、送信側装置に送信する、第２の送信処理手段と、
前記第１の処理手段が、前記受信データのシリアル番号が連番であると判断した場合には、前記受信処理の対象となったデータを前記受信用バッファから削除する第２の処理手段と、を備える、データ通信システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データ通信技術に係わり、特に、異機種の情報処理装置間でのデータ通信を行う際に、通信データの欠落等の発生を防止し、データ通信を確実に行うことや、異常な通信処理の発生時には、通信処理をリトライするような異常時処理を行うことを可能とする、データ通信技術に関する。
【０００２】
【従来の技術】
近年、マルチメディアシステム等の技術発展に伴い、マルチメディアデータ等の各種のデータを、異機種の情報処理装置間で通信するため、各種のデータ通信方法が提案されている。
一般に、異機種の情報処理装置間でデータ通信を行うためには、採用する通信プロトコルを予め定めておき、送信側装置および受信側装置がデータの送信・受信を行う際に、予め定めたプロトコルに適合するようにデータを生成して、装置間でのデータ通信処理を行っている。
【０００３】
このような通信方法を採用する通信システムの一例を、図１０を参照して説明する。
図１０は、異機種の情報処理装置である、コンピュータＡおよびコンピュータＢの間で、データ通信を行う通信システムを、機能ブロック図で示したものである。
【０００４】
実際には、各機能部は、各種の処理や各構成要素の動作制御を行うＣＰＵ（中央処理装置）、ＣＰＵを動作させるためのプログラム等を格納したＲＯＭ、各種の処理に対するワークエリアや各種データの格納領域を備えるＲＡＭ等を、有したハードウエア構成にて実現される。
コンピュータＡは、送信処理プログラム（アプリケーション）とクライアント側送信部との間のインターフェイスとして機能するＡＰＩ（アプリケーション）部１２と、通信対象となるデータを格納する領域を有する送信側バッファ１４と、送信処理機能を有するクライアント側送信部１６と、コンピュータＢ側から送信されてきた受信処理結果を格納するＤＢ（データーベース）１８とを有している。同様に、コンピュータＢは、受信処理プログラム（アプリケーション）とサーバ側受信部との間のインターフェイスとして機能するＡＰＩ（アプリケーション）部２２と、通信対象となるデータを格納する領域を有する受信バッファ２４と、受信処理機能を有するサーバ側受信部２６とを有している。さらに、両コンピュータは、光ファイバ等の伝送媒体で構成される通信網であるＬＡＮ２８によって、通信可能に接続されている。
【０００５】
さて、このようなシステムが、データ通信を行う際の動作について、その概要を説明する。
まず、ＡＰＩ部１２が送信処理プログラムを起動すると、該プログラムによって与えられた送信データは、送信側バッファ部に格納される（▲１▼）。
なお、送信処理プログラムが、順次生成する送信データは、送信バッファ部１４に、順次、格納されることになる。次に、ＡＰＩ部１２は、クライアント側送信部１６に、データ送信依頼のメッセージを発行する（▲２▼）。
【０００６】
そして、メッセージを受け取ったクライアント側送信部１６は、送信側バッファ１４から、順次、送信データを獲得して、獲得したデータをＬＡＮ２８を介して、サーバ側受信部２６に送信する（▲３▼）。
このとき、クライアント側送信部１６は、送信すべきデータが、コンピュータＢ側で受信可能となるように、当該データが、予め定めたプロトコルに適合するようなデ─タ加工を行い、加工したデータをＬＡＮ３０上に送出する。
【０００７】
さて、データを受信したサーバ側受信部２６は、受信データを受信側バッファ２４に格納し（▲４▼）、ＡＰＩ部２２に対して、処理依頼のメッセージを発行する（▲５▼）。
そして、メッセージを受け取ったＡＰＩ部２２は、受信側バッファ２４から受信データを獲得して（▲６▼）、獲得したデータに対する処理を行う。
【０００８】
サーバ側受信部２６は、この処理結果を受け取り、ＬＡＮ２８を介して、クライアント側送信部１６に、処理結果を送信する（▲７▼）。
クライアント側送信部１６は、受け取った処理結果を、ＤＢ（データーベース）１８に格納する。
なお、サーバ側受信部２６は、受信側バッファ２４内の受信データを削除し（▲８▼）、また、クライアント側送信部１６は、送信側バッファ１４内の送信データを削除する（▲９▼）。
【０００９】
以上のように、従来では、このようなシステム構成で、異機種の情報処理装置間でのデータ通信を行っていた。
ところで、以上の説明では、１つの送信データに注目して、システムの動作の流れについて説明したが、実際には、送信データが順次生成されて、上述したような通信処理が順次行われて、データ通信が実行されている。
【００１０】
【発明が解決しようとする課題】
しかしながら、このような通信方法によれば、通信対象となるデータが、順次、適切に通信処理されたかを、簡易な方法で判断する術がなく、正常な動作が行われなくなる場合があっても、装置自体が異常動作を検出できないため、データ欠落等が生じたまま、通信処理が継続されてしまうという問題があった。
【００１１】
なお、パリティチエック等の方法により、正常な通信処理が行われているか否かを調べる方法もあるが、データ線等のハードウエア物量の増大やソフトウエア容量の増加を招き、システムコストの向上を招いていた。
よって、データフレームの構成を変更する等の簡易な手法によって、通信データの欠落等の発生を防止し、異機種の情報処理装置間でのデータ通信を確実に行うとともに、異常な通信処理を行っているシステムに対する、予め定めた処理である異常時処理を行うことが可能な、データ通信方法の実現が望まれていた。
【００１２】
そこで、本発明は、通信データのフィールド中に、簡易な情報を定義することによって、情報処理装置間でのデータ通信が確実に行えるとともに、異常通信処理を行っているシステムに対して、異常時処理を行うことが可能な、データ通信方法を提供することを目的とする。
また、本発明の他の目的は、送信側装置および受信側装置の間で、データ通信が行えない場合等に、通信処理を自動再開させる、データ通信方法を提供することにある。
【００１３】
【課題を解決するための手段】
上記課題を解決し、本発明の目的を達成するため、請求項１記載の発明は、通信対象データを格納する領域を有する送信側バッファを備える送信側装置と、通信対象データを格納する領域を有する受信側バッファを備える、前記送信側装置と異機種の受信側装置との間でデータを通信する方法であって、
通信対象データの内、送信側装置から受信側装置に送信するデータである送信データを送信側バッファに格納するステップと、
送信側バッファから送信データを獲得して、獲得した送信データにシリアル番号を付与し、予め定めたプロトコルを用いて、受信側装置に送信するステップと、
送信側装置から送信されてきたデータを受信側バッファに格納するステップと、
受信側バッファからデータを獲得して、獲得したデータに対して、受信処理手順を定めた受信処理プログラムにしたがって受信処理した処理結果を表す応答データを、シリアル番号順に、前記予め定めたプロトコルを用いて、送信側装置に送信するステップと、
受信側装置から前記応答データとして送信側装置に送信された通信データのシリアル番号が連番であるか否かを判定し、連番でないときに、異常時処理を行い、連番であるときに、前記受信処理の対象となったデータを前記受信側バッファから削除するとともに、前記受信側バッファから削除されたデータに対応する前記送信側バッファ内のデータも、前記送信側バッファから削除するステップと、を含むデータ通信方法である。
【００１４】
また、請求項２記載の発明は、前記異常時処理が、送信側装置または受信側装置が行う送信処理をリトライする処理であること、を特徴とするデータ通信方法である。
さらに、請求項３記載の発明は、通信対象データを格納する領域を有する送信側バッファを備える送信側装置と、通信対象データを格納する領域を有する受信側バッファを備える、前記送信側装置と異機種の受信側装置との間でデータを通信するシステムであって、
前記送信側装置は、
通信対象データの内、送信側装置から受信側装置に送信するデータである送信データを、送信側バッファに格納する、第１の格納処理手段と、
送信側バッファから送信データを獲得して、獲得した送信データにシリアル番号を付与し、予め定めたプロトコルを用いて、受信側装置に送信する、第１の送信処理手段と、
受信側装置から応答データとして送信された通信データのシリアル番号が連番であるか否かを判定し、連番でないときに、異常時処理を行い、連番であるときに、前記送信データを前記送信側バッファから削除する第１の処理手段と、を備え、また、
前記受信側装置は、
送信側装置から送信されてきた送信データを受信側バッファに格納する、第２の格納処理手段と、
受信側バッファからデータを獲得して、獲得したデータに対して、受信処理手順を定めた受信処理プログラムにしたがって受信処理した処理結果を表す応答データを、シリアル番号順に、前記予め定めたプロトコルを用いて、送信側装置に送信する、第２の送信処理手段と、
前記第１の処理手段が、前記受信データのシリアル番号が連番であると判断した場合には、前記受信処理の対象となったデータを前記受信用バッファから削除する第２の処理手段と、を備える、データ通信システムである。
【００１５】
【発明の実施の形態】
以下、本発明の実施形態を、図面を参照しつつ説明する。
図１は、本発明にかかるデータ通信方法を用いて、異機種の情報処理装置である、コンピュータＣおよびコンピュータＤの間で、データ通信を行う通信システムを、機能ブロック図で示したものである。
【００１６】
また、図２は、両コンピュータ（送信側装値、受信側装置に対応する）の、具体的なハードウエア構成例を示したハードウエア構成図である。
図２に示すように、各コンピュータは、各種の処理や構成要素の動作制御を行うＣＰＵ（中央処理装置）５２と、ＣＰＵを動作させるためのプログラム等を格納したＲＯＭ５３と、各種の処理に対するワークエリアや各種データの格納領域を備えるＲＡＭ５４と、通信を行うためのＩ／Ｆ（インターフェイス）回路５５と、各種データ等を格納しておくためのハードディスク（ＨＤ）５６と、データ通信不可能状態等の動作状態情報を含む、各種の情報を表示するためのＣＲＴ５７と、装置を操作するためのキーボード５８とを有し、各構成要素は、構成要素間での情報の伝送路として機能するシステムバス５９に接続されている。
【００１７】
また、例えば、ＲＯＭ５３内には、本発明にかかる通信処理を行うためのプログラム、ＣＲＴ５７を使用しての表示処理を行うためのプログラム、キーボード５８を介して与えられる各種のコマンドに、対応した処理を行うためのプログラム等が、格納されている。
そして、ＣＰＵ５２は、ＲＯＭ５３内に格納されているプログラムにしたがった動作を行うように構成されている。
【００１８】
なお、キーボードを介して与えるコマンドとしては、送信処理および受信処理の起動、停止、再開等が挙げられる。また、送信データは、送信処理プログラムの実行により、自動的に、送信側バッファ３４に格納するようにしておくのが一般的であるが、キーボードを介して与えるようにすることも考えられる。
また、表示処理を行うことによって、ＣＲＴ５７に表示する表示内容としては、通信異常が発生した旨の表示や、受け取ったデータの内容の表示等が挙げられる。
【００１９】
さて、先に述べたように、図１は、通信システムの機能ブロック図を示している。このようなブロック図は、ＣＰＵ５２が行う動作を、その機能に注目して記載したものであって、システム動作の理解を容易にするものである。
以下、図１の説明を行い、さらに、他の図面を参照して、各機能部が行う動作、即ち、本発明のデータ通信方法について説明する。
【００２０】
コンピュータＣ（送信側装置）は、送信処理プログラム（アプリケーション）とクライアント機能３６との間のインターフェイスとして機能するＡＰＩ（アプリケーション）部３２と、通信データを格納する送信側バッファ３４と、送信処理機能を有するクライアント機能３６と、コンピュータＤ側から送られてきた処理結果を格納するＤＢ（データーベース）３７と、本装置を操作するために、各種のコマンドを入力するための入力装置３８と、通信異常状態等の動作状態情報を含む情報を表示する表示装置３９と、クライアント機能３６の起動、停止、再開等の動作制御を行うプロセス制御部６１と、を有している。なお、送信側バッファ３４は、送信および受信データを一時的にバッファリングする機能を有している。
【００２１】
図２に示した実際のハードウエア構成と比較すると分かるように、ＡＰＩ部３２、クライアント機能３６およびプロセス制御部６１は、Ｉ／Ｆ（インターフェイス）回路５５と、ＲＡＭ５４のワークエリアと、ＲＯＭ５３に予め格納されたプログラムにしたがって、ＣＰＵ５２が行う処理動作と、で実現される機能である。
【００２２】
また、送信側バッファ３４、ＤＢ３７、入力装置３８、および、表示装置３９は、夫々、ＲＡＭ５４の１部のエリア、ＨＤ５６、ＣＲＴ５７、キーボード５８に対応している。
同様に、コンピュータＤ（受信側装置）は、受信処理プログラム（アプリケーション）とサーバ機能３６との間のインターフェイスとして機能するＡＰＩ（アプリケーション）部４２と、通信データを格納する受信側バッファ４４と、受信処理機能を有するサーバ機能４６と、本装置を操作するために、各種のコマンドを入力するための入力装置４８と、通信異常状態等の動作状態情報を含む情報を表示する表示装置４９と、コンピュータＣ側から送られてきたデータを蓄積するＤＢ（データーベース）５１と、サーバ機能４６の起動、停止、再開等の動作制御を行うプロセス制御部６２と、を有している。
【００２３】
また、受信側バッファ４４は、送信および受信データを一時的にバッファリングする機能を有している。さらに、ＡＰＩ部４２は、通常、複数種類のアプリケーション、即ち、複数種類の受信処理プログラムを保持しており、後に述べる、電文フォーマット中の情報によって、いずれのアプリケーションが選択されるかが規定される。
【００２４】
コンピュータＤの機能ブロックについても、先ほどと同様に、図２に示した実際のハードウエア構成と比較すると分かるように、ＡＰＩ部４２、サーバ機能４６およびプロセス制御部６２は、Ｉ／Ｆ（インターフェイス）回路５５と、ＲＡＭ５４のワークエリアと、ＲＯＭ５３に予め格納されたプログラムにしたがって、ＣＰＵ５２が行う処理動作と、で実現される機能である。
【００２５】
また、送信バッファ部３４、入力装置３８、および、表示装置３９は、夫々、ＲＡＭ５４の１部のエリア、ＣＲＴ５７、キーボード５８に対応している。
また、両コンピュータは、光ファイバ等の伝送媒体で構成される通信網であるＬＡＮ５０によって、通信可能に接続されている。
さて、次に、両コンピュータ間で行われるデータ通信の動作を、図面を参照して説明する。
【００２６】
なお、図１に示すシステムで行うデータ通信は、アプリケーションや、ＣＰＵ等のハードウエアが異なる、異機種のコンピュータ間でのデータ通信を想定している。
まず、コンピュータＣのＡＰＩ部３２が行う動作を、図３を参照して説明する。ＡＰＩ部３２は、アプリケーションである送信処理プログラムからの呼び出しによって動作を行い、送信側バッファ３４に、送信データを登録し、送信依頼を行う旨のメッセージをクライアント機能宛に発行する動作を行う。これについて、詳細に説明する。
【００２７】
まず、ステップＳ１００において、送信処理プログラムは、「送信データの登録」処理を呼び出す。これに対して、ステップＳ１０６で、ＡＰＩ部３２は、バッファの空き状態を調べ、ステップＳ１０８にて、送信側バッファ３４が満杯である場合には、満杯状態であるとして、ステップＳ１００に戻り、ステップＳ１０２において、満杯状態であると判断される間は、ステップＳ１００における処理を、暫く待ってから再度行う。
【００２８】
一方、ステップＳ１０８において、送信側バッファ３４が満杯でないと判断された場合には、送信データを送信側バッファ３４に登録（格納）して、送信データの登録処理を行い、正常な登録処理を行ったとして、ステップＳ１００にブランチする。
次に、ステップＳ１０２において、送信側バッファ３４が満杯状態でないと判断された場合には、ステップＳ１０４に進み、「送信依頼」処理を呼び出す。
【００２９】
これに対応して、ステップＳ１１２において、送信依頼メッセージを作成し、ついで、ステップＳ１１４において、サーバ機能との通信経路の状態を調査する。そして、ステップＳ１１６において、通信経路が遮断中であると判断した場合には、異常終了であると判断して、ステップＳ１０４に戻る。一方、ステップＳ１１６において、通信経路が遮断中でないと判断した場合には、ステップＳ１１８に進み、クライアント機能宛に、メッセージを発行して、正常終了であるとして、ステップＳ１０４に戻る。
【００３０】
以上が、ＡＰＩ部３２が行う処理である。
次に、受信側のコンピュータＤのＡＰＩ部４２が行う動作を、図４を参照して説明しておくことにする。
ＡＰＩ部４２は、アプリケーションである受信処理プログラムの呼び出しによって動作を行い、サーバ機能４６からの、受信処理依頼の旨のメッセージを受け取って、受信側バッファ４４から受信データを獲得して、獲得した受信データを受信プログラム内に取り込むとともに、受信済のデータを受信バッファ４４から抹消する動作を行う。また、受信済のデータをＤＢ５１に格納する動作も行う。
【００３１】
以下、この動作について、詳細に説明する。
まず、ステップＳ１２０において、受信処理プログラムは、「データの受信」処理を呼び出す。これに対して、ステップＳ１２４で、ＡＰＩ部４２は、受信側バッファ４４の空き状態を調べ、ステップＳ１２６にて、受信側バッファ４４内にデータが存在すると判断した場合には、ステップＳ１２８において、コンピュータＣから送られてきた送信データを、受信側バッファ４４から読み出し、正常終了して、ステップＳ１２０に戻る。
【００３２】
一方、ステップＳ１２６において、受信側バッファ４４内にデータが存在しないと判断した場合には、ステップＳ１３０に進み、メッセージの受信待ちを行ってから、ステップＳ１２４にブランチし、データの受信動作を継続する。
次に、データの受信の呼び出しが完了したのち、ステップＳ１２２において、受信したデータをＤＢ５１等に格納する。
【００３３】
そして、ステップＳ１２３において、「受信済データの抹消」を呼び出す。これに対して、ＡＰＩ部４２は、受信側バッファ４４上の受信済データを抹消して、不要な受信データを廃棄する。
以上が、ＡＰＩ部４２が行う処理である。
次に、図５に示したフローチャートにしたがって、コンピュータＣ３０のクライアント機能が行う処理について、説明する。
【００３４】
クライアント機能３６は、送信依頼メッセージを受け取ることによって、送信側バッファ３４に格納されている送信データを、所定のフォーマットを有するデータである電文にして、サーバ機能４６に、ソケット通信する動作を行う。
なお、クライアント機能が行う、このような動作は、プロセス制御部５２の制御により行われる。なお、プロセス制御部５２は、例えば、ユーザが入力装置３８を介して与えたコマンドによって、クライアント機能３６を起動、停止、再開するようにしておけばよい。
【００３５】
また、データ通信は、仮想上の回線である論理回線を使用するものとし、後に述べるように、使用する論理回線を定める情報が、通信データのフィールド上に存在するような、データフォーマットになっている。
まず、最初に、ステップＳ１４０において、稼働中の状態を、例えばＤＢ３７の空きエリアに、ファイルとして格納する。なお、ここで、稼働中の状態とは、異常通信時から復旧して稼働した状態、手動操作による停止状態から復旧して稼働した状態等の、各種の状態が挙げられる。
【００３６】
次に、ステップＳ１４２において、ソケット通信を行うための領域を、例えば、送信側バッファ３４の一部のエリアに確保する。
次に、ステップＳ１４４において、サーバ機能４６との通信経路の確立を行い、ステップＳ１４５において、通信経路が確立されたか否かを判定する。
そして、通信経路の確立不可能な場合には、ステップＳ１７２に進み、通信制御コンポーネントであるクライアント機能３６の自動復旧を行う。ここでの自動復旧は、再度、通信経路の確立を行うべく、ステップＳ１４４に進むことである。一方、通信経路の確立が行われた場合には、ステップＳ１４６進む。
【００３７】
ステップＳ１４６では、送信側バッファ３４のデータ格納状態を調査し、さらに、ステップＳ１４８において、サーバ機能４６に対して送信すべきデータが存在するか否かを判断する。送信すべきデータが存在しない場合には、ステップＳ１６６に進み、送信すべきデータが存在する場合には、ステップＳ１５０において、シリアル番号が発番済か否かを調べる。
【００３８】
シリアル番号が発番済の場合には、ステップＳ１５４に進み、シリアル番号が未発番の場合には、ステップＳ１５２に進み、シリアル番号が連番になるように、発番してからステップＳ１５４に進む。なお、クライアント機能３６は、送信側バッファ３４の記憶エリアの一部を使用して、送信電文の発番済のシリアル番号の値の保持、更新を行う。
【００３９】
ステップＳ１５４において、電文を編集し、編集した電文を、サーバ機能４６に送信する。
さて、ここで、図７を参照して、送信電文のデータフォーマットについて説明する。本電文は、ヘッダ部と、シリアル番号および実際のデータを有するデータ部７６とからなる。
【００４０】
ヘッダ部は、異機種間でデータ通信を行うため採用するプロトコルである、ＴＣＰ／ＩＰ等のプロトコル識別子７０と、送信電文であるか応答電文であるかを示す情報である、電文識別子７１と、送信データの発信元の装置を識別する情報である、ホスト名７２と、サーバ機能およびクライアント機能間の通信で使用する仮想上の回線である論理回線の識別子である論理回線番号７３と、コンピュータＤ側に存在する通信相手である、複数のアプリケーションのうちのいずれを選択するかを定める情報である情報コード７４と、電文の長さを示す情報である電文長７５とからなる。
【００４１】
なお、電文識別子７１としては、例えば、送信電文を「０１」、応答電文を「１０」とするデジタルデータを採用すればよく、また、ホスト名７２としては、送信側装置固有に予め定めたデジタルデータを採用すればよい。
また、論理回線番号７３は、回線固有に定めたデジタルデータを採用すればよく、情報コード７４は、通信相手を定めるデジタルデータ、電文長７５は、電文の長さを規定するデジタルデータを採用すればよい。
【００４２】
シリアル番号としては、初期値を「１」として、順次、１だけ増分されるデジタルデータを採用すればよい。なお、通信プロトコルとしては、ＢＳＣ等の他のプロトコルを採用してもよいことは、言うまでもない。
このように、ステップＳ１５４では、クライアント機能３６は、送信データを、図７に示したような、フォーマットになるように加工する処理を行う。
【００４３】
次に、ステップＳ１５６において、送信異常が発生したか否かを調べ、通信異常が発生した場合には、ステップＳ１７２に進み、一方、通信異常が発生していない場合には、ステップＳ１５８に進み、サーバ機能４６からの応答電文の受信待ちを行う。
なお、ステップＳ１５６における、通信異常の発生の判断は、例えば、クライアント機能３６が、回線異常を検出した場合等に、通信異常が発生したと判断するようにしておけばよい。もちろん、他の態様によって、通信異常の発生を判断してもよい。
【００４４】
また、ステップＳ１５６からステップＳ１７２に進んだ際に行われる、クライアント機能３６の自動復旧としては、例えば、現在使用している通信経路を遮断して、所定時間が経過するのを待ち、さらに、ステップＳ１４４に進んで、新たな通信経路を使用した通信処理（リトライ）を行うことが挙げられる。
次に、ステップＳ１５８において、応答電文を受信した際に、ステップＳ１６０において、通信異常を判断する。ここでの通信異常の判断は、応答電文中のシリアル番号が連番になっているか否かや、後に述べる応答電文が有する応答コードを参照して判定する。
【００４５】
シリアル番号による、通信異常の判定を行うために、クライアント機能３６は、送信側バッファ３４の記憶エリアの一部を使用して、受信した応答電文のシリアル番号の値の保持、更新を行い、受信した応答電文のシリアル番号が、保持されている、最も新しいシリアル番号の連番になるか否かを判断すればよい。
即ち、クライアント機能３６は、シリアル番号が連番になっていない場合、例えば、「１番」の次に、「３番」となるような、欠番の発生や、シリアル番号のダブルナンバリングが発生した場合等には、通信異常が発生したとして、ステップＳ１７２に進む。
【００４６】
また、応答コードにより通信異常を判定するためには、クライアント機能３６は、応答コードの内容を判断して、異常判定を行う。
そして、通信異常でない場合には、ステップＳ１６２に進み、一方、通信異常である場合には、ステップＳ１７２に進む。なお、ステップＳ１６０からステップＳ１７２に進んだ際に行われる、クライアント機能３６の自動復旧としては、例えば、現在使用している通信経路を遮断して、所定時間が経過するのを待ち、さらに、ステップＳ１４４に進んで、新たな通信経路を使用したリトライ処理を行うことが挙げられる。
【００４７】
次に、ステップＳ１６２においては、サーバ機能４６から、受信側バッファ４４が満杯の旨の応答である、バッファ満杯の応答電文が送られてきたか否かを判定し、かかる電文が送られてきた場合には、ステップＳ１６６に進み、一方、かかる電文が送られてこない場合には、ステップＳ１６４に進み、現在のシリアル番号を有する送信電文を、送信側バッファ３４から削除する。これに続いて、削除した送信電文に対応する応答電文を、ＤＢ３７に格納する処理を行う。
【００４８】
そして、ステップＳ１６６では、メッセージの受信待ちを行い、停止指示命令が与えられていないかを、ステップＳ１６８にて判断する。
停止指示が与えられていない場合には、メッセージを受信すると、ステップＳ１４６にブランチして、電文送信の処理を継続する。一方、停止指示命令が与えられている場合には、ステップＳ１７０に進み、クライアント機能３６を正常停止の状態にして、クライアント機能３６の処理を終了する。
【００４９】
なお、電文、応答電文、現在のシリアル番号、自動復旧の有無等の各種の情報を、表示装置３９に表示可能に、表示処理のプログラムを予め生成しておき、当該プログラムを、所定のコマンドの投入に対応して、実行可能にしておくのが好ましい。
以上が、クライアント機能３６が行う処理である。
【００５０】
次に、図６を参照して、サーバ機能が行う動作について説明する。
サーバ機能は、クライアント機能から送られてくる電文に基づいて、受信側バッファにデータを登録して、該当する受信処理プログラムに、処理依頼のメッセージを発行し、さらに、処理結果に基づいて応答電文を作成して、クライアント機能に送り返す動作を行う。なお、サーバ機能も、プロセス制御部６２により、その動作が制御される。このような制御は、例えば、入力装置４８を介して、与える、起動、再開、終了等の指示に対応して行われる。以下、動作説明を詳細に行う。
【００５１】
まず、ステップＳ１８０において、稼働中の状態を、例えばＤＢ５１の空きエリアに、ファイルとして格納する。なお、ここで、稼働中の状態とは、異常通信時から復旧して稼働した状態、手動操作による停止状態から復旧して稼働した状態等の、各種の状態が挙げられる。
次に、ステップＳ１８２において、受信側バッファ４４のデータの格納状態を調べる。
【００５２】
次に、ステップＳ１８４において、受信済の電文に対するシリアル番号を把握する。
なお、サーバ機能４６は、受信側バッファ４４の記憶エリアの一部を使用して、受信済の電文に対するシリアル番号の値の保持、更新を行う。
次に、ステップＳ１８６において、ソケット通信を行うための領域を、例えば、受信側バッファ４４の一部のエリアに確保し、ステップＳ１８８において、通信経路の確立待ちを行い、通信経路が確立されれば、ステップＳ１９０に進む。
【００５３】
ステップＳ１９０では、プロセス制御部６２からの停止指示が存在するか否かを判定し、存在する場合には、ステップＳ１９２に進み、正常停止し、正常停止の状態を、稼働中の状態として記憶し、処理を終了する。
一方、プロセス制御部６２からの停止指示が存在しない場合には、ステップＳ１９４に進んで、クライアント機能から電文が送られてくるのを待つ。
【００５４】
電文が送られてきた場合、ステップＳ１９６において、再度、プロセス制御部６２からの停止指示が存在するか否かを判定し、存在する場合には、ステップＳ１９２に進んで、所定の処理後、処理を終了する。一方、停止指示が存在しない場合には、ステップＳ１９８に進み、送られてきた電文が異常なデータか否かを判断する。
【００５５】
ここでの通信異常の判断は、電文のフォーマットを参照して、フォーマットが異常であるかや、電文長が、所定値以上であるか等によって判断する。そして、異常データと判断されたときには、ステップＳ２００に進み、異常扱いを行うか否かを判定する。そして、異常扱いをする場合には、ステップＳ２０２において、異常停止を行い、異常データをＤＢ５１に格納しておくとともに、異常停止の状態を、稼働中の状態として記憶し、処理を終了する。なお、ステップＳ２０２において、異常扱いしない場合には、ステップＳ２０４に進み、当該異常データを破棄するとともに、当該異常データを受信済である旨の応答電文を作成して、ステップＳ２２４に進む。
【００５６】
一方、ステップＳ１９８において、異常データでないと判断された場合には、ステップＳ２１０に進み、シリアル番号を参照して、受信済のデータか否かを判断する。既に、受信済のデータである場合には、ステップＳ２０６において、当該電文を受信済である旨の応答電文を作成して、ステップＳ２２４に進む。
また、受信済のデータでない場合には、ステップＳ２１２において、受信側バッファ４４のデータ格納状態を調べ、ステップＳ２１４に進む。ステップＳ２１４において、受信側バッファ４４が満杯であると判定された場合、ステップＳ２０８に進み、バッファ満杯の旨の応答電文を作成して、ステップＳ２２４に進む。
【００５７】
一方、受信側バッファ４４が満杯でないと判定された場合には、ステップＳ２１６に進み、受信した電文である受信データを、受信側バッファ４４に登録する。
次に、ステップＳ２１８において、受信データからシリアル番を獲得して、現在保持されているシリアル番号の値を更新する。
【００５８】
次に、ステップＳ２２０において、受信データの情報コードを参照して、対応する処理プログラム宛のメッセージを、作成、発行する。
そして、ステップＳ２２２において、正常処理の応答電文を作成する。
さて、ここで、図８を参照して、応答電文のデータフォーマットについて説明する。本電文は、ヘッダ部と、シリアル番号および実際のデータを有するデータ部８６とからなる。
【００５９】
ヘッダ部は、異機種間でデータ通信を行うため採用するプロトコルである、ＴＣＰ／ＩＰ等のプロトコル識別子８０と、送信電文であるか応答電文であるかを示す情報である電文識別子８１と、応答電文の発信元の装置を識別する情報であるホスト名８２と、サーバ機能およびクライアント機能間の通信で使用する仮想上の回線である論理回線の識別子である論理回線番号８３と、コンピュータＤ側に存在する通信相手である、複数のアプリケーションのうちのいずれを選択したものかを示す情報である情報コード８４と、送られてきた電文に対する処理状態を示すコードである応答コード８５とからなる。
【００６０】
なお、電文識別子８１としては、例えば、送信電文を「０１」、応答電文を「１０」とするデジタルデータを採用すればよく、また、ホスト名８２としては、受信側装置固有に予め定めたデジタルデータを採用すればよい。
また、論理回線番号８３は、回線固有に定めたデジタルデータを採用すればよく、情報コード８４は、通信相手を定めるデジタルデータである。シリアル番号としては、初期値を「１」として、順次、１だけ増分されるデジタルデータを採用すればよい。
【００６１】
さて、応答コード８５は、図８（ｂ）に示すように、電文の処理状態に応じて、応答電文に付されるコードである。例えば、ステップＳ２２２においては、正常処理を行ったので、コード「ＯＫ」が付されるし、また、ステップＳ２０４においては、フォーマットエラー等が発生しているので、コード「ＭＥＲＲＯＲ」等が付される。なお、コード「ＦＥＲＲＯＲ」が示す、振り分け異常とは、サーバ側に定義されていない情報コードが送られてきたことを意味する。
【００６２】
このように、クライアント機能３６は、図８（ａ）に示したような、フォーマットを有する応答電文の生成処理を行う。
次に、ステップＳ２２４において、サーバ機能４６は、ＬＡＮ５０を介して、クライアント機能３６側に、作成した応答電文を送信する。
そして、ステップＳ２２６において、通信異常が発生したか否かを判定する。
【００６３】
即ち、通信異常が発生してない場合には、ステップＳ１９４にブランチして、電文待ち動作を行い、一方、通信異常が発生した場合には、ステップＳ２２８に進む。なお、ここでの通信異常の発生の判断は、例えば、サーバ機能４６が、例えば、クライアント機能３６が、回線異常を検出した場合等に、通信異常が発生したと判断するようにしておけばよい。もちろん、他の態様によって、通信異常の発生を判断してもよい。
【００６４】
なお、ステップＳ２２８における、自動復旧処理は、例えば、現在使用している通信経路を遮断して、所定時間が経過するのを待ち、さらに、ステップＳ１８８に進んで、新たな通信経路を使用した通信処理（リトライ）を行うことが挙げられる。なお、電文、応答電文、現在のシリアル番号、自動復旧の有無等の各種の情報を、表示装置４９に表示可能に、表示処理のプログラムを予め生成しておき、当該プログラムを、所定のコマンドの投入に対応して、実行可能にしておくのが好ましい。
【００６５】
以上の処理が、サーバ機能が行う処理である。
次に、プロセス制御部６１、６２が、夫々、入力装置３８、４８を介して与えるコマンドによって行う、クライアント機能３６、サーバ機能４６の動作の制御について、図９を参照して説明する。
まず、ステップＳ３００において、プロセス制御部６１（６２）は、通信制御コンポーネントであるクライアント機能３６（サーバ機能４６）の稼働状態を、論理回線単位に調べ、さらに、ステップＳ３０２において、論理回線単位の調査結果を、表示装置３９（４９）に一覧表示する。
【００６６】
次に、ステップＳ３０４において、入力装置３８（４８）を介して、論理回線単位に、「停止、再開、終わり」の、動作指示コマンドを入力する。
ステップＳ３０６において、「終わり」なるコマンドが入力されたと判定されると、当該論理回線を使用しての通信処理を終了し、一方、それ以外のときには、ステップＳ３０８に進む。
【００６７】
ステップＳ３０８においては、指定した動作指示と、稼働状態との一致を調べ、一致していれば、ステップＳ３１６に進み、一方、一致していない場合には、ステップＳ３１０に進む。入力された動作指示コマンドが、停止指示である場合には、ステップＳ３１２に進んで、該当する通信制御コンポーネントであるクライアント機能３６（サーバ機能４６）を停止して、ステップＳ３１６に進む。
【００６８】
一方、入力された動作指示コマンドが、停止指示でない場合には、ステップＳ３１４に進んで、該当する通信制御コンポーネントであるクライアント機能３６（サーバ機能４６）を起動する。そして、ステップＳ３１６においては、入力された動作指示コマンドに対応する動作制御を行って、ステップＳ３００にブランチし、プロセス制御部の動作を継続させる。
【００６９】
なお、このような図９に示す一連の動作は、入力装置を介して与えるコマンドによって、強制終了するようにしておけばよい。
以上の説明によれば、本発明にかかる通信処理は、以下のように行われる。
まず、クライアント機能３６は、ＡＰＩ部３２から与えられる送信データを送信側バッファ３４に格納する。次に、クライアント機能３６は、送信側バッファ３４から送信データを獲得して、獲得した送信データにシリアル番号を付与し、予め定めたプロトコルを用いて、受信側装置であるコンピュータＤに送信する。
【００７０】
そして、受信側装置であるコンピュータＤのサーバ機能４６は、送信されてきたデータを受信側バッファ４４に格納する。
次に、サーバ機能４６は、受信側バッファからデータを獲得して、ＡＰＩ部４２に渡し、ＡＰＩ部４２は、獲得したデータに対して、受信処理手順を定めた受信処理プログラムにしたがって受信処理した処理結果を、サーバ機能４６に渡す。
【００７１】
次に、サーバ機能４６は、応答データを、シリアル番号順に、前記予め定めたプロトコルを用いて、送信側装置であるコンピュータＣに送信する。
そして、クライアント機能３６は、応答データとして送信されてきた通信データのシリアル番号が連番であるか否かを判定し、連番でないときに、異常時処理を行う。一方、連番であるときには、サーバ機能４６は、前記受信処理の対象となったデータを受信側バッファ４４から削除する。
【００７２】
この時、クライアント機能３６は、受信側バッファ４４から削除されたデータに対応する送信側バッファ３４内のデータを、送信側バッファ３４から削除する。
このような処理を行うことによって、機種が異なる送信側装置と受信側装置との間で、本発明にかかるデータ通信が行われることになる。
【００７３】
なお、本実施形態において、請求項１、２記載の各ステップは、図３乃至図６に記載した一連のステップ内に含まれる。
また、請求項３記載の第１の格納処理手段は、ステップＳ１００、１０６から１１０までのステップを含むステップに対応し、第１の送信処理手段は、ステップＳ１０４、ステップＳ１１２から１１８、ステップＳ１４０から１５４までのステップを含むステップに対応し、さらに、第１の処理手段は、ステップＳ１５８、１６０、１６４、１７２のステップを含むステップに対応する。
【００７４】
さらに、第２の格納処理手段は、ステップＳ２１６を含むステップに対応し、第２の送信処理手段は、ステップＳ１２０、ステップＳ１２４から１２８、ステップＳ２１８から２２４までのステップを含むステップに対応し、さらに、第２の処理手段は、ステップＳ１３２を含むステップに対応する。
なお、図１に示すシステム構成では、いわゆる１対１型の通信システムとなっているが、他のコンピュータを、さらに、ＬＡＮ５０に接続して、「Ｎ対Ｍ型（但し、Ｎ，Ｍは、自然数）」の通信システムを構成しても、本発明の通信方法を適用することが可能である。これについては、データフォーマット中の、ホスト名７２、８２を参照して、クライアント機能３６およびサーバ機能４６が、ＬＡＮ５０上を伝送するデータのうちで、自装置に必要なデータを獲得する処理を行うように、処理プログラムを格納し、該処理プログラムを実行可能な構成にしておけばよい。したがって、図１に示すシステムは、本発明の理解の容易化のために採用した、システム構成の一例にすぎない。
【００７５】
以上のように、本発明によれば、シリアル番号を用いて、データ欠落防止や通信異常が発生した場合に行う異常時処理を自動的に行うデータ通信方法を実現できることになる。
【００７６】
【発明の効果】
以上説明してきたように、請求項１記載の発明によれば、通信データのフィールド中に、シリアル番号を与えて、該シリアル番号の連番状態を考慮して、処理を行うことによって、通信データの欠落等の発生を防止し、異機種の情報処理装置間でのデータ通信を確実に行うことを可能とするとともに、異常通信を行っているシステムに対する異常時処理を自動で行うことも可能とする、データ通信方法を実現できる。
【００７７】
また、請求項２記載の発明によれば、送信側装置および受信側装置の間で、データ通信が行えない場合等に、通信処理をリトライすることによって、通信処理を自動再開させることを特徴とするデータ通信方法が実現可能になる。
さらに、請求項３記載の発明によれば、本発明にかかる通信方法を使用し、通信データの欠落等の発生を防止し、異機種の情報処理装置間でのデータ通信を確実に行うことを可能とするシステムを実現できる。
【図面の簡単な説明】
【図１】本発明にかかる通信システムの機能ブロック図である。
【図２】送信側および受信側装置のハードウエア構成図である。
【図３】ＡＰＩ部３２が行う処理を示すフローチャートである。
【図４】ＡＰＩ部４２が行う処理を示すフローチャートである。
【図５】クライアント機能が行う処理を示すフローチャートである。
【図６】サーバ機能が行う処理を示すフローチャートである。
【図７】電文フォーマットの説明図である。
【図８】応答電文フォーマットの説明図である。
【図９】プロセス制御部が行う処理を示すフローチャートである。
【図１０】従来例の説明図である。
【符号の説明】
１０  コンピュータＡ
１２  ＡＰＩ部
１４  送信側バッファ
１６  クライアント側送信部
２０  コンピュータＢ
２２  ＡＰＩ部
２４  受信側バッファ
２６  サーバ側受信部
２８  ＬＡＮ
３０  コンピュータＣ
３２  ＡＰＩ部
３４  送信側バッファ
３６  クライアント機能
３７  データーベース（ＤＢ）
３８  入力装置
３９  表示装置
４０  コンピュータＤ
４２  ＡＰＩ部
４４  受信側バッファ
４６  サーバ機能
４８  入力装置
４９  表示装置
５０  ＬＡＮ
５２  ＣＰＵ
５３  ＲＯＭ
５４  ＲＡＭ
５５  Ｉ／Ｆ（インターフェイス）回路
５６  ハードディスク
５７  ＣＲＴ
５８  キーボード
５９  システムバス
６１  プロセス制御部
６２  プロセス制御部
【図１】
0003600344.tif 000002
【図２】
0003600344.tif 000003
【図３】
0003600344.tif 000004
【図４】
0003600344.tif 000005
【図５】
0003600344.tif 000006
【図６】
0003600344.tif 000007
【図７】
0003600344.tif 000008
【図８】
0003600344.tif 000009
【図９】
0003600344.tif 000010
【図１０】
0003600344.tif 000011