JP2004015081A - 通信制御システム - Google Patents

通信制御システム Download PDF

Info

Publication number
JP2004015081A
JP2004015081A JP2002161342A JP2002161342A JP2004015081A JP 2004015081 A JP2004015081 A JP 2004015081A JP 2002161342 A JP2002161342 A JP 2002161342A JP 2002161342 A JP2002161342 A JP 2002161342A JP 2004015081 A JP2004015081 A JP 2004015081A
Authority
JP
Japan
Prior art keywords
communication
program
series
communication device
control program
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
JP2002161342A
Other languages
English (en)
Other versions
JP3645537B2 (ja
Inventor
Kenji Uchida
打田 建治
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.)
CHORI JOHO SYSTEM CO Ltd
Original Assignee
CHORI JOHO SYSTEM CO Ltd
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 CHORI JOHO SYSTEM CO Ltd filed Critical CHORI JOHO SYSTEM CO Ltd
Priority to JP2002161342A priority Critical patent/JP3645537B2/ja
Publication of JP2004015081A publication Critical patent/JP2004015081A/ja
Application granted granted Critical
Publication of JP3645537B2 publication Critical patent/JP3645537B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Communication Control (AREA)

Abstract

【課題】全銀協手順を、HTTPプロトコル上において運用可能とするシステムを提供する。
【手段】サーバ側の通信装置4は、一連の通信データのやりとりについて、同一のセッションIDを付し、クライエント側の通信装置2は、このセッションIDを返信するようにして、一連をやりとりを特定できるようにしている。また、一連の通信データのやりとりを終了する際には、その旨を互いのアプリケーションに通知するようにしている。
【選択図】 図7

Description

【0001】
【発明の技術分野】
この発明は通信制御システムに関し、特に通信の連続性の管理に関するものである。
【0002】
【従来の技術および課題】
銀行業務に用いるデータの転送プロトコルとして、全銀協手順が知られている。この全銀協手順は、データの交換を行う通信装置間において、まず、通信路を形成した後、交互にデータの交換を行うものである。最後に、通信路を切断して終了する。
【0003】
図1に、全銀協手順の概要を示す。通信を希望する通信装置Aは、伝送制御手順(BSC)のプログラムインターフェイスを使用し、通信装置Bに対してダイヤルをして、回線を接続する。次に、通信装置Aは、開局要求電文を通信装置Bに送信する。これを受けて、通信装置Bは、開局回答電文を返信して開局要求に応じる。さらに、通信装置Aは、開始要求電文を通信装置Bに送信する。これを受けて、通信装置Bは、開始回答電文を返信して開始要求に応じる。
【0004】
このようにして、通信の準備が整うと、通信装置Aは、通信内容をテキスト1〜テキストnとして送信する。これらのテキストの送信を終えると、通信装置Aは、終了要求電文を通信装置Bに送信する。これを受けて、通信装置Bは、終了回答電文を返信する。さらに、通信装置Aは、閉局要求電文を通信装置Bに送信する。これを受けて、通信装置Bは、閉局回答電文を返信する。その後、通信装置Aは回線を切断する。以上のようにして、データの送信が行われる。
【0005】
なお、上記の手順実行中に何らかの障害が発生することがある。たとえば、テキストを所定回数再送しても通信装置Bが正しく受信できない等の障害が生じることがある。このような場合には、障害を検知した通信装置Bが回線を切断する。通信装置Aは、回線が切断されたことにより、障害が発生したことを知ることができる。
【0006】
また、TCP/IPにおいて運用できるよう改良された全銀TCP/IP手順や拡張Z手順も用いられている。全銀TCP/IP手順や拡張Z手順では、物理的な回線の切断に代えて、伝送制御手順(TCP/IP)レベルでの切断により、障害の発生を検知するようにしている。具体的には、TCP/IPのプログラムインターフェイス(ソケットと呼ぶ)での切断を、全銀協手順における物理的な回線の切断に対応させている。
【0007】
いずれにしても、これら従来の方式では、物理的な接続や伝送手順レベルでの接続が通信中は永続的に続くという前提に立っている。したがって、かかる接続が中断した場合には、障害が生じたと判断できるのである。
【0008】
ところで、インターネットの発達により、HTTPプロトコルの重要性が高まっており、上記の全銀協手順もHTTPプロトコルでの運用が望まれている。しかしながら、全銀協手順、全銀TCP/IP手順、拡張Z手順のように物理的な回線の切断、ソケットの切断に基づいて、障害の判断を行う手順を、そのままHTTPプロトコル上で運用することはできない。HTTPプロトコルでは、一連の通信が終了した後も物理的回線としては接続された状態が維持される場合があるからである。したがって、全銀協手順を用いた場合には、物理的回線の接続状態に基づいて、一連の通信の終了や障害の発生を知ることはできない。
【0009】
また、ソケットの接続状態に基づいて判断を行う全銀TCP/IP手順を用いた場合には、次のような問題を生じる。HTTPプロトコルのバージョン1.0においては、1回の通信毎にソケットを切断するように規定されている。つまり、ソケットを接続している間に、1回しか通信文を送ることができず、通信文を複数回送信する場合には、複数回ソケットの接続と切断を繰り返す必要がある。したがって、HTTPプロトコルのバージョン1.0上の通信において、仮に、全銀TCP/IP手順そのものを実装した場合、HTTPプロトコルでは、正常な通信が続いているにもかかわらず、ソケットを切断することにより、TCP/IPコネクションが切断され、全銀TCP/IPでは、障害が発生したと判断してしまうことになる。ただし、全銀TCP/IP手順は、HTTPプロトコルでは規定されていないため、HTTP上で全銀TCP/IP手順を用いるには、何らかの伝送制御プログラムが必要となる。
【0010】
なお、HTTPプロトコルのバージョン1.1においては、ソケットを接続している間に、複数回にわたって通信文を送信することが可能である。したがって、双方の通信装置がHTTPプロトコルのバージョン1.1を用いれば、前述の伝送制御プログラムを実装して、全銀TCP/IP手順を用いることも不可能ではない。
【0011】
しかし、何れか一方の通信装置がバージョン1.0を用いていれば、他方もバージョン1.0に合わせて通信を行わねばならない。したがって、このような場合には、全銀TCP/IP手順を用いることはできない。
【0012】
また、双方が、HTTPプロトコルのバージョン1.1を用いていても、プロキシを介して通信する場合には、互いの通信装置がソケットによって直接接続されないことになる。したがって、一方の通信装置がソケットの切断を行っても、それを、他方の通信装置が知ることができない。よって、双方の通信装置がHTTPプロトコルのバージョン1.1を用いる場合であっても、プロキシを経由する場合等を考慮すると、全銀TCP/IP手順を適用することはできない。
【0013】
この発明は上記のような問題点を解決して、全銀協手順、全銀TCP/IP手順、拡張Z手順などのように一連の通信データのやりとり中において接続の永続性があることを前提とした手順を、HTTPプロトコルなどのように一連の通信データのやりとり中にコネクションの切断が起こりうるようなプロトコル上において運用可能とするシステムを提供することを目的とする。
【0014】
【課題を解決するための手段】
(1)(2)(3)この発明の通信制御システムは、第1の通信装置と、通信路を介して第1の通信装置に接続された第2の通信装置とを備えた通信制御システムであって、
前記第1および第2の通信装置は、一連の通信データのやりとり中に、通信路のコネクションが切断されたことにより障害発生を判断する処理プログラムを備え、
さらに、前記第1および第2の通信装置は、前記一連の通信データのやりとり中に前記コネクションの切断が生じうる通信プロトコルを使用するものであり、
前記コネクションの切断にかかわらず、一連の通信データのやりとりであることを認識可能とするために、セッション識別子を用いて一連の通信データのやりとりを特定する処理を行う制御プログラムを、第1および第2の通信装置に設けたことを特徴としている。
【0015】
したがって、HTTPプロトコルのようにコネクションの切断が起こりうるプロトコルであっても、セッション識別子により、あたかも接続の永続性が維持されているかのように処理することができる。すなわち、一連の通信データのやりとり中において接続の永続性が保持され続けることを前提とした手順を、HTTPプロトコルのように一連の通信データのやりとり中にコネクションの切断が起こりうるようなプロトコル上においても支障なく運用することができる。
【0016】
(4)この発明の通信制御システムは、制御プログラムが、接続の永続性を切断する旨の永続性切断通知を相手方の通信装置に対して送信することを特徴としている。
【0017】
したがって、相手方の通信装置に対して、接続の永続性が失われたことを通知することができ、接続の永続性に基づいて処理を行う従来手順の処理プログラムを用いることが可能となる。
【0018】
(5)この発明の通信制御システムは、制御プログラムが、正常に通信が終了した場合に永続性切断通知を送信することを特徴としている。
【0019】
したがって、相手方の通信装置に対して、通信の正常終了による接続の永続性の喪失を通知することができ、接続の永続性に基づいて通信の終了処理を行う従来手順の処理プログラムを用いることが可能となる。
【0020】
(6)この発明の通信制御システムは、制御プログラムが、障害が発生した場合に前記永続性切断通知を送信することを特徴としている。
【0021】
したがって、相手方の通信装置に対して、障害発生による接続の永続性の喪失を通知することができ、接続の永続性に基づいて障害処理を行う従来手順の処理プログラムを用いることが可能となる。
【0022】
(7)この発明の通信制御システムは、制御プログラムが、相手方からの永続性切断通知を受けると、前記処理プログラムに対してコネクションの切断があった旨の通知を行うことを特徴とするもの。
【0023】
したがって、コネクションの切断に基づいて処理を行う従来手順の処理プログラムを用いることが可能となる。
【0024】
(8)この発明の通信制御システムは、制御プログラムが、相手方の通信装置に対して通信データを送信してから、相手方の通信装置から通信データが送信されてくるまでの時間が、所定時間を超えた場合には、障害が発生したものとすることを特徴としている。
【0025】
したがって、相手方が通信データを送信したにもかかわらず、何らかの要因によって通信データが届かないような場合においても、障害を検出することができる。
【0026】
(9)この発明の通信制御システムは、制御プログラムが、一連の通信データのやりとりの開始から、終了までの時間が、所定時間を超えた場合には、障害が発生したものとすることを特徴としている。
【0027】
したがって、やりとりの開始から終了までの間に、何らかの要因にてやりとりが停止し、双方の通信装置においてこのやりとりの停止を直接検出できないような場合においても、障害の発生を知ることができる。
【0028】
(10)この発明の通信制御システムは、制御プログラムが、一連の通信データのやりとりの開始を通信装置から要求された際に、当該要求に応えられない状況の場合には、当該通信装置に対して他の通信装置の接続先を返答することを特徴としている。
【0029】
したがって、通信を拒否された通信装置は、直ちに他の通信装置に対して通信開始の要求を行うことができる。
【0030】
(11)この発明の通信制御システムは、プロトコルが、HTTPプロトコルであることを特徴としている。
【0031】
したがって、HTTPプロトコル上において、一連の通信データのやりとりの終了を、通信の永続性の切断により判断するような手順を運用することができる。
【0032】
(12)この発明の通信制御システムは、制御プログラムが、HTTPヘッダ部分に、永続性切断通知を記述して相手方通信装置に送信することを特徴としている。
【0033】
したがって、HTTPプロトコル上において、永続性切断通知を送信することができる。
【0034】
(13)この発明の通信制御システムは、セッション識別子が、POSTメソッドのHTTP拡張ヘッダを用いて実現されることを特徴としている。
【0035】
したがって、HTTPプロトコル上において、容易にセッションの連続性を識別することができる。
【0036】
(14)この発明の通信制御方法は、一連の通信データのやりとり中に、コネクションが切断されたことにより障害発生を判断するプログラムを用いつつ、前記一連の通信データのやりとり中に前記コネクションの切断が生じうるプロトコルを使用して、前記一連の通信データのやりとりを行う通信制御方法であって、
前記コネクションの切断にかかわらず、一連の通信データのやりとりであることを認識可能とするために、セッション識別子を用いて一連の通信データのやりとりを特定することを特徴としている。
【0037】
したがって、HTTPプロトコルのようにコネクションの切断が起こりうるプロトコルであっても、セッション識別子により、あたかも接続の永続性が維持されているかのように処理することができる。すなわち、一連の通信データのやりとり中において接続の永続性が保持され続けることを前提とした手順を、HTTPプロトコルのように一連の通信データのやりとり中にコネクションの切断が起こりうるようなプロトコル上においても支障なく運用することができる。
【0038】
この発明において、「接続の永続性の切断」とは、継続的に接続されている状態を切断することをいい、継続的に接続されている通信路の物理的な切断だけでなく、継続的に接続されているソケットの切断等も含む概念である。
【0039】
「コネクションの切断」とは、通信路の物理的な切断だけでなく、ソケットの切断等も含む概念である。
【0040】
「プログラムを記録した記録媒体」とは、プログラムを記録したROM、RAM、フレキシブルディスク、CD−ROM、メモリカード、ハードディスク等の記録媒体をいう。また、電話回線、搬送路等の通信媒体も含む概念である。CPUに接続されて、記録されたプログラムが直接実行されるハードディスクのような記録媒体だけでなく、一旦ハードディスク等にインストールした後に実行されるプログラムを記録したCD−ROM等の記録媒体を含む概念である。
【0041】
「プログラム」とは、CPUにより直接実行可能なプログラムだけでなく、ソース形式のプログラム、圧縮処理がされたプログラム、暗号化されたプログラム等を含む概念である。
【0042】
【発明の実施の形態】
図2に、この発明の一実施形態による通信制御システムの概念図を示す。通信装置2は、アプリケーションプログラム22と制御プログラム24を備えている。また、通信装置4は、アプリケーションプログラム42と制御プログラム44を備えている。両通信装置2、4は、インターネット6を介して接続されている。
【0043】
アプリケーションプログラム22は、制御プログラム24に指令を与えて、アプリケーションプログラム42との間で通信データのやりとりを行う。同様に、アプリケーションプログラム42は、制御プログラム44に指令を与えて、アプリケーションプログラム22との間で通信データのやりとりを行う。
【0044】
制御プログラム24、44は、HTTPプロトコルを用いて通信を行う。制御プログラム24、44は、1回のHTTPリクエスト/レスポンス毎にソケットを切断する。制御プログラム24、44は、セッション識別子を用いて通信データを交換することにより、ソケットの切断によって切り離された各回の通信を関連づけ、一連の通信を特定するようにしている。
【0045】
上記のように、制御プログラム24、44は、1回のHTTPリクエスト/レスポンス毎にコネクションを切断するにもかかわらず、アプリケーションプログラム22、42は、一連の通信データの送受信中には、接続の永続性が維持され続けるものとして処理を実行する。したがって、制御プログラム24は、一連の通信が終了すると、アプリケーション22に対してコネクションが切断された旨を通知する(永続性切断通知)。また、何らかの障害が発生し、通信の続行ができなくなった場合にも、制御プログラム24は、アプリケーション22に対して永続性切断通知を送信する。制御プログラム44も同様の処理を行う。
【0046】
図3に、上記一実施形態による通信データの伝送手順を概念的に示す。送信側のアプリケーションプログラム22は、ファイル名等を指定してファイル伝送指令30を生成する。送信側の制御プログラムの全銀協対応部分は、このファイル伝送指令に基づいて全銀協手順電文32を生成する。さらに、送信側のHTTP対応部分は、この全銀協手順電文32に基づいて、HTTPメッセージ34を生成する。このようにして生成されたHTTPメッセージ34は、インターネットを介して、受信側に送られる。
【0047】
受信側の制御プログラムのHTTP対応部分は、HTTPメッセージ34を受けて、これを解釈する。これとともに、全銀協手順電文32を復元する。受信側の制御プログラムの全銀協対応部分は、全銀協手順電文32を解釈して、通信の制御や全銀協手順電文の受信側アプリケーションへの引き渡しを行う。受信側のアプリケーションは、制御プログラムからの報告を受けて、上位処理を行う。
【0048】
なお、受信側は、受信後に確認等を返信する必要があるので、送信側と受信側は交互に入れ替わることになる。また、1つのファイル伝送指令に対して、複数の電文が作成されるので、上記の処理は、複数回繰り返されることになる。
【0049】
図4に、上記実施形態において用いた通信装置2のハードウエア構成を示す。通信装置2は、CPU52、メモリ54、ディスプレイ56、ハードディスク58、CD−ROMドライブ60、通信部64、キーボード/マウス66を備えている。ハードディスク58には、オペレーティングシステム70(マイクロソフト社のウインドウズ(商標)など)が記録されている。また、制御プログラム72、アプリケーションプログラム74も記録されている。さらに、通信可能な相手先のURLなどを定義した事前定義情報、送信対象となる様々なファイル78が記録されている。CPU52は、制御プログラム等にしたがって処理を行うものである。
【0050】
制御プログラム72、アプリケーションプログラム74は、オペレーティングシステム70と協働して処理を行うものである。また、これらは、CD−ROMドライブ60を介して、CD−ROM62からインストールされたものである。
【0051】
通信部64は、インターネットとの通信を行うための回路部であり、いわゆる、通信ボードと呼ばれているものである。
【0052】
なお、図示しないが、通信装置4も上記通信装置2と同等の構成を有している。
【0053】
図5、図6に、この実施形態による通信制御システムにおける通信データのやりとりを示す。この図においては、通信装置2が通信装置4に対してファイル78を伝送する場合を説明している。この実施形態では、伝送を希望する通信装置2がクライエントになり、伝送を受ける通信装置4がサーバとなるようにしている。
【0054】
まず、通信装置2のアプリケーションプログラム74は、ファイル名、相手側通信装置名等を指定して転送指示を行う(図5の▲1▼)。これを受けて、制御プログラム72は、事前定義情報76を参照して、相手側通信装置のURLを取得する。事前定義情報76には、通信装置名とURLが対応づけて記録されている。制御プログラム72は、取得したURLに基づいて、相手側通信装置4とのソケットを接続する(図5の▲2▼▲2▼’)。これにより、コネクションが確立される。
【0055】
続いて、通信装置2の制御プログラム72は、全銀協手順に基づく開局要求電文を、HTTPメッセージとして送信する(図5の▲3▼)。通信装置4の制御プログラム72は、このHTTPメッセージから、開局要求電文を復元し、アプリケーション74に渡す。アプリケーション74は、通信装置4の事前定義情報76を参照して、開局要求電文中に記載された相手方通信装置が、送受信の権限を有しているか否かを判断する。
【0056】
権限を有していれば、アプリケーション74は、開局回答電文を返信するように制御プログラム72に指令を行う。これを受けて、通信装置4の制御プログラム72は、開局回答電文を送信装置2に送信する。通信装置2の制御プログラムは、この開局回答電文を受信する(図5の▲4▼)。
【0057】
次に、通信装置2の制御プログラム72は送信対象であるファイルのファイル名などを含む開始要求電文を送信し(図5の▲5▼)、これを受けた通信装置4の制御プログラム72は開始回答電文を返信する。
【0058】
以上のようにしてファイル送信の準備が整うと、通信装置2の制御プログラム72は、ファイル78を分割した1または複数のレコードをまとめたテキストを、HTTPメッセージとして送信する(図5の▲6▼)。このHTTPメッセージを受信した通信装置4の制御プログラムは、テキストからレコードを復元して、アプリケーション74に渡す。アプリケーション74は、開始要求電文に記述されていたファイル名を付して、このレコードを記録する。また、通信装置4の制御プログラム72は、全銀協手順に従ってレコードを受信した旨を示す電文を、HTTPメッセージとして返信する。
【0059】
このようにして、1つのレコードの送信が完了すると、通信装置2の制御プログラム72は、次のレコードを送信する。同様に、通信装置4の制御プログラム72は、返信を行う。
【0060】
上記の処理を繰り返して全てのレコードを送信し終えると、通信装置2の制御プログラム72は、全銀協手順に従う終了要求電文を、HTTPメッセージとして送信する(図5の▲7▼)。これに対して、通信装置4の制御プログラム72は、全銀協手順に従う終了回答電文を、HTTPメッセージとして返信する(図5の▲8▼)。
【0061】
さらに、通信装置2の制御プログラム72は、全銀協手順に従う閉局要求電文を、HTTPメッセージとして送信する(図5の▲9▼)。これに対して、通信装置4の制御プログラム72は、全銀協手順に従う閉局回答電文を、HTTPメッセージとして返信する(図5の10)。この際、通信装置4の制御プログラム72は、HTTPヘッダ中に、永続性切断通知を埋め込んで送信する。
【0062】
また、永続性切断通知をヘッダに含む閉局回答電文を受けた通信装置2の制御プログラム72は、ソケットを切断する(図5の11)。さらに、通信装置2の制御プログラム72は、通信装置2のアプリケーションに対して、コネクションが切断された旨を伝える。これにより、通信装置2のアプリケーション74は、一連のやりとりが終了したことを知ることができる。
【0063】
なお、クライエント側となった通信装置2においては、送信に用いたポートに対するソケットのTCPセッション(ファイルディスクリプタ)に対してサーバ側の通信装置4から返答が送られてくる。したがって、そのファイルディスクリプタを保持しておくことにより、たとえ、複数のサーバに対して通信を行っていたとしても、それぞれの通信を区別することができる。
【0064】
また、サーバ側となった通信装置4においては、返信時にセッションIDをHTTPヘッダに記述して送信し、クライエント側の通信装置2は、次回に送信を行う際にはこのセッションIDを付すようにしている。これにより、通信装置4は、たとえ、複数のクライエントに対して通信を行っていたとしても、ぞれの通信を区別することが可能である。
【0065】
図5、図6においては、このセッションIDについての処理の詳細を示していない。また、図5、図6においては、障害を発見するためのタイマ処理の詳細も示していない。図7、図8に、これらセッションIDとタイマに関する処理を含む制御プログラムのフローチャートを示す。
【0066】
まず、クライエントである通信装置2の制御プログラム72(以下クライエント)は、サーバである通信装置4の制御プログラム72(以下サーバ)に対し、HTTPプロトコルにおけるソケットの接続を要求する(ステップS1)。サーバは、要求に応じてソケットの接続を行う(ステップS51)。
【0067】
次に、クライエントは、開局要求メッセージを送信する(ステップS2)。この実施形態では、開局要求メッセージは、図11に示すように、POSTメソッドを用いて行われる。すなわち、ヘッダ部分201にPOSTメソッドによる記述を行い、本文部分202に開局要求電文を記述している。
【0068】
サーバは、この開局要求メッセージを受信する(ステップS52)。これにより、サーバは一連の通信が開始したことを認識し、この一連の通信を特定するためのセッションIDを決定する。サーバは、決定したセッションIDを、相手先通信装置2を特定する情報、ファイル名等と関連づけて、メモリ54に記憶する。次に、サーバは、開局回答メッセージを返信する(ステップS55)。この際、決定したセッションIDをヘッダ中に記述する(ステップS54)。サーバから返送される開局回答メッセージを図11に示す。ヘッダ部分301の拡張HTTPヘッダ(図中では、X−ZGH−Session)の項目に、セッションIDとして、234f4f13aa7525が記述されている。開局回答電文は、本文部分302に記述されている。
【0069】
クライエントは、この開局回答メッセージを受信する(ステップS8)。さらに、クライエントは、受信した開局回答メッセージから、セッションIDを取り出してメモリ54に記憶する(ステップS9)。続いて、クライエントは、開始要求メッセージを送信する(ステップS11)。この際、記憶しておいたセッションIDをヘッダ中に記述する(ステップS10)。図11に、開始要求メッセージを示す。ヘッダ部分203の拡張HTTPヘッダ(図中ではX−ZGH−Session)の項目に、セッションIDとして、234f4f13aa7525が記述されている。開始要求電文は、本文部分204に記述されている。
【0070】
サーバは、この開始要求メッセージを受信する(ステップS60)。さらに、サーバは、受信した開始要求メッセージから、セッションIDを取り出す(ステップS61)。サーバは、このセッションIDに基づいて、いずれのクライエントとの通信であるかを特定する。したがって、複数のクライエントとのやりとりを同時に行っていても、相手方クライエントを特定することができる。
【0071】
サーバは、同じセッションIDをヘッダに付して(ステップS62)、開始回答メッセージを返信する。したがって、一連の通信をセッションIDによって特定することが可能となる。
【0072】
以下、レコードの送信においても同様の処理が行われる。
【0073】
一連の通信を終了する際には、終了要求−終了回答、閉局要求−閉局回答の各メッセージがやりとりされる。これらメッセージのやりとりは、上記と同じようにして、セッションIDが付されて行われる(図8参照)。
【0074】
ただし、閉局する場合には、ソケットの切断を行う必要がある。この実施形態では、図8のステップS75、図11の305に示すように、閉局回答メッセージのヘッダ中の拡張HTTPヘッダ(図中ではX−ZGH−Session)の項目に、永続性切断通知としてcloseを記述している。これを受けたクライエントは、ソケットを切断する。このように、サーバの側から永続性切断通知を行って、これを受けたクライエントが切断処理を行うことにより、クライエントとサーバの双方がコネクションの切断を認識することができる。
【0075】
なお、サーバは、永続性切断通知を行った後、当該通信に対して付していたセッションIDをメモリ54から削除する。また、このセッションIDに関連して記憶していた相手先通信装置2を特定する情報、ファイル名等も削除する(ステップS76)。さらに、アプリケーション74に対して、コネクションが切断された旨を通知する。
【0076】
一方、永続性切断通知を受けたクライエントの制御プログラムは、アプリケーション74に対して、コネクションが切断された旨を通知する。以上のようにして、HTTPプロトコルを用いて、全銀協手順における一連の通信を処理することができる。
【0077】
また、この実施形態では、一連の通信の途中における障害についても、処理できるようにしている。従来の全銀協手順では、障害発生時に、接続を物理的に切断すれば相手方もこれを認識することができた。しかし、HTTPプロトコルでは、そのような認識を行うことができない。この実施形態では、以下のようにして、障害の検出と相手方への通知を実現している。
【0078】
図7のステップS2においてメッセージを送信した後、タイマーをリセットしている。このタイマーは、障害検出のためのタイマーである。このタイマーが所定時間経過するまでに、相手方からのメッセージ(ステップS8参照)が送信されてこなければ、障害が発生したものと判断する。
【0079】
図9に、タイムアウト処理のフローチャートを示す。タイムアウト(タイマーが所定時間経過)になっても相手方からの通信がない場合には、拡張HTTPヘッダにセッションIDおよび永続性切断通知を記述(図中では、X−ZGH−SessionにセッションID、X−ZGH−Connectionにcloseを記述)して、切断メッセージを送信する(ステップS505、S506、S507)。
【0080】
この切断メッセージを受けた相手側通信装置は、このあとのエラー関連処理に使用するため、HTTP拡張ヘッダからセッションIDを取り出し(ステップS504)、その後、ソケットを切断する。
【0081】
自分がサーバ側である場合には、セッションID等をメモリから削除する(ステップS510)。その後、アプリケーション74へのコネクション切断の通知などエラー関連処理を行う(ステップS511)。
【0082】
また、レコードを記録するための容量不足や通信異常などの障害が発生した場合の処理を、図10にフローチャートで示す。まず、障害の発生を検知すると(ステップS600)、セッションID、永続性切断通知をヘッダに記述して(ステップS601、S602)、切断メッセージを送信する(ステップS604)。図12に、切断メッセージのヘッダ部分451を示す。
【0083】
なお、当該通信装置がサーバ側である場合には(ステップS609)、セッションID等をメモリ54から削除する処理を行う(ステップS610)。その後、アプリケーション74へのコネクション切断の通知などのエラー関連処理を行う(ステップS611)。
【0084】
なお、この実施形態では、HTTPプロトコルを使用しているため、HTTPプロトコル特有の障害も生じうる。したがって、これら特有の障害(たとえば、相手先URLの誤り等)が発生した場合も、上記に示す処理によって、コネクションの切断を行うようにしている。
【0085】
また、サーバ側の通信装置が開局要求電文を受信した際に、接続セッション数オーバなどの原因で、当該要求に応えられない場合がある。この場合に、サーバ側の通信装置の制御プログラムは、開局要求電文を送ってきたクライエント側の通信装置に対して、開局に応えられない旨の電文を返信する。この電文返信の際、代替通信先の通信装置のURLをHTTPヘッダに埋め込んで送信するようにしてもよい。これを受けたクライエント側の通信装置は、容易に代替可能な他の通信装置に対して開局要求を行うことができる。
【0086】
この際、クライエント側の制御プログラムは、サーバが開局に応えられない旨を直ちに処理プログラムに知らせず、代替可能な他のサーバから開局に応えられる旨を受信した後、これを処理プログラムに知らせる。また、制御プログラムは、代替可能な他のサーバが全て開局に応えられない場合には、その旨を処理プログラムに知らせる。
【0087】
なお、上記実施形態では、POSTメソッドのHTTP拡張ヘッダにセッションIDを記述するようにしている。しかし、Cookieの項目にセッションIDを記述するようにしてもよい。
【0088】
また、上記実施形態では、全銀協手順をHTTPプロトコル上で実現した場合について説明している。しかし、全銀協手順だけでなく、通信時にのみ接続を行い、通信中は接続を維持するような手順一般に適用することができる。また、HTTPプロトコルだけでなく、1回の通信毎にコネクションを切断するようなプロトコル一般に適用することができる。
【図面の簡単な説明】
【図1】全銀協手順を示す図である。
【図2】この発明の一実施形態による通信制御システムの概要を示す図である。
【図3】この発明の一実施形態による通信の処理概要とデータとを示す図である。
【図4】通信装置のハードウエア構成を示す図である。
【図5】アプリケーションプログラムと制御プログラムの処理内容を示す図である。
【図6】アプリケーションプログラムと制御プログラムの処理内容を示す図である。
【図7】制御プログラムのフローチャートを示す図である。
【図8】制御プログラムのフローチャートを示す図である。
【図9】タイムアウトおよび切断メッセージ受信の際の処理フローチャートを示す図である。
【図10】障害発生の際の処理フローチャートを示す図である。
【図11】メッセージのやりとりを示す図である。
【図12】障害発生時のメッセージのやりとりを示す図である。
【符号の説明】
2・・・通信装置
4・・・通信装置
22・・・アプリケーション
24・・・制御プログラム

Claims (14)

  1. 第1の通信装置と、通信路を介して第1の通信装置に接続された第2の通信装置とを備えた通信制御システムであって、
    前記第1および第2の通信装置は、一連の通信データのやりとり中にを、通信路のコネクションが切断されたことにより障害発生を判断する処理プログラムを備え、
    さらに、前記第1および第2の通信装置は、前記一連の通信データのやりとり中に前記コネクションの切断が生じうる通信プロトコルを使用するものであり、前記コネクションの切断にかかわらず、一連の通信データのやりとりであることを認識可能とするために、セッション識別子を用いて一連の通信データのやりとりを特定する処理を行う制御プログラムを、第1および第2の通信装置に設けたことを特徴とする通信制御システム。
  2. 一連の通信データのやりとり中に、通信路のコネクションが切断されたことにより障害発生を判断する処理プログラムを用いつつ、前記一連の通信データのやりとり中に前記コネクションの切断が生じうるプロトコルによる通信を可能とするための制御プログラムであって、
    前記コネクションの切断にかかわらず、一連の通信データのやりとりであることを認識可能とするために、セッション識別子を用いて一連の通信データのやりとりを特定する処理を行うことを特徴とする制御プログラム。
  3. 請求項2のプログラムを記録した記録媒体。
  4. 請求項1〜3のいずれかのシステム、プログラムまたは記録媒体において、
    前記制御プログラムは、接続の永続性を切断する旨の永続性切断通知を相手方の通信装置に対して送信することを特徴とするもの。
  5. 請求項4のシステム、プログラムまたは記録媒体において、
    前記制御プログラムは、正常に通信が終了した場合に前記永続性切断通知を送信することを特徴とするもの。
  6. 請求項4または5のシステム、プログラムまたは記録媒体において、
    前記制御プログラムは、障害が発生した場合に前記永続性切断通知を送信することを特徴とするもの。
  7. 請求項4〜6のいずれかのシステム、プログラムまたは記録媒体において、
    前記制御プログラムは、相手方からの永続性切断通知を受けると、前記処理プログラムに対してコネクションの切断があった旨の通知を行うことを特徴とするもの。
  8. 請求項1〜7のいずれかのシステム、プログラムまたは記録媒体において、
    前記制御プログラムは、相手方の通信装置に対して通信データを送信してから、相手方の通信装置から通信データが送信されてくるまでの時間が、所定時間を超えた場合には、障害が発生したものとすることを特徴とするもの。
  9. 請求項1〜8のいずれかのシステム、プログラムまたは記録媒体において、
    前記制御プログラムは、一連の通信データのやりとりの開始から、終了までの時間が、所定時間を超えた場合には、障害が発生したものとすることを特徴とするもの。
  10. 請求項1〜9のいずれかのシステム、プログラムまたは記録媒体において、
    前記制御プログラムは、一連の通信データのやりとりの開始を通信装置から要求された際に、当該要求に応えられない状況の場合には、当該通信装置に対して他の通信装置の接続先を返答することを特徴とするもの。
  11. 請求項1〜10のいずれかのシステム、プログラムまたは記録媒体において、
    前記プロトコルは、HTTPプロトコルであることを特徴とするもの。
  12. 請求項11のシステム、プログラムまたは記録媒体において、
    前記制御プログラムは、HTTPヘッダ部分に、前記永続性切断通知を記述して相手方通信装置に送信することを特徴とするもの。
  13. 請求項11または12のシステム、プログラムまたは記録媒体において、
    前記セッション識別子は、POSTメソッドのHTTP拡張ヘッダを用いて実現することを特徴とするもの。
  14. 一連の通信データのやりとり中に、コネクションが切断されたことにより障害発生を判断するプログラムを用いつつ、前記一連の通信データのやりとり中に前記コネクションの切断が生じうるプロトコルを使用して、前記一連の通信データのやりとりを行う通信制御方法であって、
    前記コネクションの切断にかかわらず、一連の通信データのやりとりであることを認識可能とするために、セッション識別子を用いて一連の通信データのやりとりを特定することを特徴とする通信制御方法。
JP2002161342A 2002-06-03 2002-06-03 通信制御システム Expired - Fee Related JP3645537B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2002161342A JP3645537B2 (ja) 2002-06-03 2002-06-03 通信制御システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2002161342A JP3645537B2 (ja) 2002-06-03 2002-06-03 通信制御システム

Publications (2)

Publication Number Publication Date
JP2004015081A true JP2004015081A (ja) 2004-01-15
JP3645537B2 JP3645537B2 (ja) 2005-05-11

Family

ID=30430441

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002161342A Expired - Fee Related JP3645537B2 (ja) 2002-06-03 2002-06-03 通信制御システム

Country Status (1)

Country Link
JP (1) JP3645537B2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006046445A1 (ja) * 2004-10-29 2006-05-04 Matsushita Electric Industrial Co., Ltd. ファイル転送システム、送信機器及び受信装置
WO2006046446A1 (ja) * 2004-10-26 2006-05-04 Matsushita Electric Industrial Co., Ltd. 送信機器、受信機器、およびファイル転送システム
JP2007141129A (ja) * 2005-11-22 2007-06-07 Hitachi Ltd システム切替方法、その計算機システム及びプログラム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006046446A1 (ja) * 2004-10-26 2006-05-04 Matsushita Electric Industrial Co., Ltd. 送信機器、受信機器、およびファイル転送システム
WO2006046445A1 (ja) * 2004-10-29 2006-05-04 Matsushita Electric Industrial Co., Ltd. ファイル転送システム、送信機器及び受信装置
JP2007141129A (ja) * 2005-11-22 2007-06-07 Hitachi Ltd システム切替方法、その計算機システム及びプログラム

Also Published As

Publication number Publication date
JP3645537B2 (ja) 2005-05-11

Similar Documents

Publication Publication Date Title
US6304905B1 (en) Detecting an active network node using an invalid protocol option
US7761588B2 (en) System and article of manufacture for enabling communication between nodes
US7966380B2 (en) Method, system, and program for forwarding messages between nodes
KR101201140B1 (ko) 요구-응답 전송 프로토콜들에 의한 신뢰성 있는 단방향메시징
TWI248268B (en) System and method for monitoring a connection between a server and a passive client device
US7254739B2 (en) Error recovery in a client/server application using two independent sockets for communication
JP3645537B2 (ja) 通信制御システム
US8266253B2 (en) Server system and event message transmission method therefor, client terminal and connection method and program therefor, and recording medium
EP1575236B1 (en) Connectivity confirmation method for network storage device and host computer
CN116015892A (zh) 一种基于私有加密协议流量代理的内网远程桌面访问方法
WO2016161774A1 (zh) 终端应用访问nas的方法及装置
JP3407002B2 (ja) メッセージ中継装置及びメッセージ中継方法
CN107454178B (zh) 数据传输方法及装置
JPH1168884A (ja) 伝送媒体接続装置および制御装置ならびに被制御装置および記憶媒体
CN107948165B (zh) 一种基于私有协议的安全送播系统及方法
Ko et al. Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)
CN102883129B (zh) 视频通信方法及终端
JP2004513418A (ja) 標準デバイス・インタフェース
CN107819648A (zh) 网络配置netconf连接检测方法和装置
JPH11112609A (ja) 通信システムにおける通信障害回復方法ならびに同方法がプログラムされ記録される記録媒体
KR101785385B1 (ko) 네트워크 경로를 관리하는 방법 및 이를 수행하는 네트워크 엔티티
JP2002163122A (ja) 通信処理方法ならびに通信処理プログラムが記録される記録媒体
CN112153087B (zh) 一种第三方网络终端跨Net通讯方法
KR102052892B1 (ko) IoT 환경에서 기밀성과 신뢰성 있는 메시지 통신 시스템 및 방법
CN1494289A (zh) 在媒体网关控制协议中实现事务传输控制的方法

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20050127

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20050131

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20050203

R150 Certificate of patent or registration of utility model

Ref document number: 3645537

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

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

Free format text: PAYMENT UNTIL: 20080210

Year of fee payment: 3

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

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

Free format text: PAYMENT UNTIL: 20090210

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

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

Free format text: PAYMENT UNTIL: 20090210

Year of fee payment: 4

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

Free format text: PAYMENT UNTIL: 20100210

Year of fee payment: 5

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S631 Written request for registration of reclamation of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313631

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

Free format text: PAYMENT UNTIL: 20100210

Year of fee payment: 5

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

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

Free format text: PAYMENT UNTIL: 20110210

Year of fee payment: 6

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

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

Free format text: PAYMENT UNTIL: 20120210

Year of fee payment: 7

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

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

Free format text: PAYMENT UNTIL: 20130210

Year of fee payment: 8

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

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

Free format text: PAYMENT UNTIL: 20140210

Year of fee payment: 9

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R360 Written notification for declining of transfer of rights

Free format text: JAPANESE INTERMEDIATE CODE: R360

R370 Written measure of declining of transfer procedure

Free format text: JAPANESE INTERMEDIATE CODE: R370

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R360 Written notification for declining of transfer of rights

Free format text: JAPANESE INTERMEDIATE CODE: R360

R370 Written measure of declining of transfer procedure

Free format text: JAPANESE INTERMEDIATE CODE: R370

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees