JP2004192358A

JP2004192358A - Two-way communication method for transmitting/receiving between terminal and center side device, and program for two-way communication

Info

Publication number: JP2004192358A
Application number: JP2002359979A
Authority: JP
Inventors: Hitoshi Suzuki; 仁鈴木; Tomoteru Shirasawa; 智輝白沢; Hiroyuki Kanazawa; 宏幸金澤; Toshio Hirayama; 俊雄平山; Yuichi Tsujita; 祐一辻田
Original assignee: Fujitsu Ltd; Japan Atomic Energy Research Institute; Hitachi East Japan Solutions Ltd
Current assignee: Fujitsu Ltd; Japan Atomic Energy Agency; Hitachi Solutions East Japan Ltd
Priority date: 2002-12-11
Filing date: 2002-12-11
Publication date: 2004-07-08

Abstract

<P>PROBLEM TO BE SOLVED: To provide a communication method by which the use environment of a host side application is loosely restricted. <P>SOLUTION: In communication between a terminal and a server, a protocol approved by a firewall is used, and processing is prepared individually for reception and transmission. In the processing for reception and transmission, data is encapsulated by each stateless protocol, permitting two-way asynchronous communications. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

【０００１】
【発明の属する技術分野】
本発明は、端末とセンタ側の装置との間の双方向の通信技術に関する。
【０００２】
【従来の技術】
一般的にクライアント側の端末とセンタ側の装置であるサーバの間の双方向通信には、ソケット方式が広く使われている。ソケットとは、ネットワークにおける接続とデータの送信と受信を受け持つ機能である。ネットワーク上で通信を行う場合、通信を行うコンピュータ間で接続を確立する必要があり、ソケットはその接続の機能と、接続された状態でのデータの送信と受信の機能、接続の切断の機能を有している。
【０００３】
ソケットを使用してクライアント側の端末とセンタ側の装置であるサーバの間の双方向通信を行う場合の例を以下に示す。まず初めに、センタ側の装置であるサーバは、ネットワークを介してクライアント側の端末に対して何らかのサービスを提供する。またセンタ側の装置であるサーバでは、そのサービスに対応したポート番号を用意し、常にクライアント側の端末からの接続を待ち受けているようにする。例えばＷｅｂサーバであれば、クライアント側の端末のブラウザからの要求に対して、ＨＴＭＬページを送信するサービスを提供しており、ポート番号８０番を使用していることが多い。
【０００４】
次にクライアント側の端末は、ネットワークを介してセンタ側の装置であるサーバに対して何らかのサービスを要求し、またその応答に対して処理を行う。またその際クライアント側の端末では、そのサービスに対応したポート番号を使用して、ネットワークを介してサーバに対して接続を行う。例えばＷｅｂクライアント側の端末のブラウザであれば、ポート番号として８０番を使用してサーバに接続する。それからサーバに対してＨＴＭＬページの送信を要求し、その結果としてサーバからＨＴＭＬページが送信された場合、ブラウザ側でそのＨＴＭＬページの内容を表示する。
【０００５】
図１において、センタ側の装置であるサーバ１５０では、サーバのソケット１６０を使用し、サービスに対応した固定のポート番号を使用し、クライアント側の端末１１０からの接続を待ち受ける。クライアント側の端末１１０のソケット１２０からその固定ポートに対して接続した場合、サーバ１５０のソケット１６０は、新たにそのクライアント側の端末のソケット１２０と通信するためのセンタ側の装置であるサーバのソケット１７０を作成し、そのサーバのソケット１７０がクライアント側の端末のソケット１２０との通信を行う。この一連の処理の間、サーバ１５０で接続を待ち受けていたサーバのソケット１６０は、この新しいサーバのソケット１７０を作成した後、再度クライアント側端末からの接続を待ち受けている。
【０００６】
サーバのソケット１６０は、クライアント側端末からの接続毎にその端末に対応したサーバのソケット１７０を順次作成する。クライアント側端末との通信を行うサーバのソケット１７０では、対応するクライアント側端末のソケット１２０に対して、ソケット１２０から送信されたデータ１０１を受信データ１０１として受信したり、端末のソケット１２０に対して送信するデータ１０３を送信することができる。またサーバのソケット１７０と端末のソケット１２０間のデータの送信と受信は非同期に行うことができる。この送信と受信の処理が終了した場合には、端末１１０のソケット１２０との接続１８０を切断する。
【０００７】
上述したとおり、端末１１０のソケット１２０では、サービスに対応したポート番号を使用し、サーバ１５０に対して接続する。サーバ１５０での処理により、サーバ１５０のソケット１７０と接続した端末のソケット１２０では、サーバのソケット１７０に対して、ソケット１７０から送信されたデータ１０３を受信データ１０３として受信したり、サーバのソケット１７０に対して送信するデータ１０１を送信することができる。またクライアント側の端末のソケット１２０からサーバのソケット１７０に対してデータの送信と受信は非同期に行うことができる。処理が終了した場合にはサーバのソケット１７０との接続１８０を切断する。
【０００８】
このように上記サーバとクライアント側の端末へのソケットの適用により、クライアント側の端末とセンタ側の装置であるサーバの間で双方向の通信を行うことができる。
【０００９】
このようなクライアント側の端末とセンタ側の装置であるサーバとの間で双方向の通信ができる構成においては、通信は単なるデータの送信と受信だけではなく、新規にデータの構成と内容をクライアント側端末とサーバの間で、プロトコルとして決めることにより、その構成の上で動作するアプリケーションを作成することが可能である。
【００１０】
その実装例の一つとしてＲＰＣ（Remote Procedure Call）がある。ＲＰＣとは、遠隔手続き呼出しであり、プログラムの一部の手続きの実行を、ネットワークに接続した別のマシンに委託するメカニズムである。そのメカニズムは、クライアント側の端末とセンタ側の装置であるサーバとでプロトコルを定め、クライアント側の端末側からデータを送信してセンタ側の装置であるサーバ側の関数を呼び出し、その関数の結果を、上記端末側がサーバ側から受信するというものである。
【００１１】
図２において、クライアント側の端末２１０とセンタ側の装置であるサーバ２５０との間でプロトコルを定める。次に端末２１０ではＲＰＣのプロトコルに従い、サーバ２５０において呼び出す関数とその関数に渡す引数を指定するデータ２０１を作成する。データ２０１はソケットにより作成されたソケット通信路２９０を使用して、サーバ２５０に対して送信される。サーバ２５０では、端末２１０から送信されたデータ２０１を受信し、ＲＰＣのプロトコルに従いデータの内容を解析する。データ内容の解析により、サーバ２５０で呼び出す関数と関数に渡す引数が取得される。なお、以下に示す英数字「Ｓ」はシステム動作手順であるステップを意味している。その後、サーバ２５０では取得した関数に対して取得した引数を渡してステップＳ２６０で、その指定された関数を引数付きで呼び出す。その結果をＲＰＣのプロトコルに従いクライアント側の端末への送信用データ２０３として作成する。次にそのデータをソケット通信路２９０を使用して、クライアント端末２１０に対して送信する。クライアント端末２１０では、サーバ２５０によって送信された関数呼び出しの結果のデータ２０３を取得する。
【００１２】
上記ＲＰＣにおいて、クライアント側端末からセンタ側のサーバへの手続きの要求を行う処理が１つの場合は、端末からサーバへの手続きの呼び出しの送信と、その結果を端末がサーバから受信するタイミングは同期を取っていても非同期であっても性能は変らない。しかし複数の独立したＲＰＣの処理を行う場合に、ネットワークの資源を有効に使用するため等の理由から、クライアント側端末とセンタ側サーバの接続を複数行わずに、１つの接続の上で、クライアント側端末からサーバへの手続きの要求を行う処理を複数行う必要がある。その場合に、クライアント側端末からセンタ側サーバへの手続きの呼び出しの送信処理と、その送信に対する結果を端末がセンタ側サーバから受信するタイミングで同期を取ったとすると、次の問題が生じる。例えばあるセンタ側サーバ上の手続きの呼び出しがサーバ上で時間がかかった場合、独立した別のＲＰＣによる処理の次の呼び出しが、その分遅れてしまうなど、性能に影響する問題が生じる。
【００１３】
また、機能としても独立したＲＰＣの処理に関しては、他の処理に影響されないようにすることが必要である。上述した理由により、クライアント側端末からセンタ側サーバへの手続きの要求を行う処理が複数の場合には、非同期での通信が求められる。非同期の通信が可能であれば、独立したＲＰＣの処理で、ある手続きの呼び出しに時間がかかった場合でも、別のＲＰＣの、手続きの呼び出しには影響を及ぼさない。またＲＰＣに限らず、クライアント側の端末とセンタ側のサーバの間での双方向の通信は、性能や機能の面から非同期での通信が望ましい。
【００１４】
このような状況下で、現状のソケットが使用されているクライアント側端末とセンタ側サーバでの通信では、ソケットがデータの送信と受信を非同期で行うことができる。そのため、クライアント側の端末とセンタ側のサーバで、送信と受信を行う処理を、例えばスレッドを使用して個別に作成することにより、上記で求められるような双方向の非同期での通信が可能である。
【００１５】
次にソケットが使用されているクライアント側の端末とセンタ側のサーバの通信において、クライアント端末とサーバとで、送信と受信を行う処理を、例えばスレッドとして個別に作成することにより、双方向の非同期での通信を行う例を図３に示す。
【００１６】
図３は、クライアント側の端末３１０とセンタ側のサーバ３５０の間の通信を、ソケット通信路３９０を使用して行う場合の例である。この例では、端末３１０とサーバ３５０において送信と受信の処理を個別にスレッドで処理することにより、双方向で非同期の通信を行うことに関して述べる。
【００１７】
まず実装について説明する。端末３１０において、ソケット通信路３９０を用いて送信と受信を行う。その処理を、それぞれ端末の送信スレッド３２０、端末の受信スレッド３３０で実装している。またセンタ側のサーバ３５０において、ソケット通信路３９０を用いて送信を行う処理と受信を行う処理を、それぞれサーバの送信スレッド３７０、サーバの受信スレッド３６０で実装している。
【００１８】
次に通信方式に関して述べる。まずクライアント側の端末３１０で、センタ側のサーバ３５０へ送信するデータ３０１が発生し送信が必要になったとする。その場合には、端末３１０の送信スレッド３２０において、ソケット通信路３９０を使用してデータ３０１を送信する。またクライアント側の端末３１０でセンタ側のサーバ３５０からのデータの受信が必要になった場合には、端末３１０の受信スレッド３３０において、ソケット通信路３９０を使用してデータを受信する。この場合、センタ側のサーバ３５０からクライアント側の端末３１０に対してデータ３０３が送信されている場合には端末３１０はデータ３０３をクライアントの受信スレッド３３０で受信することになる。
【００１９】
また、センタ側のサーバ３５０で、クライアント側の端末３１０へ送信するデータ３０３が発生し送信が必要になったとする。その場合には、サーバ３５０の送信スレッド３７０においてソケット通信路３９０を使用してデータ３０３を送信する。またセンタ側のサーバ３５０で端末３１０からのデータの受信が必要になった場合には、サーバ３５０の受信スレッド３６０においてソケット通信路３９０を使用してデータを受信する。この場合、端末３１０からサーバ３５０に対してデータ３０１が送信されている場合にはサーバ３５０はサーバの受信スレッド３６０でデータ３０１を受信することになる。
【００２０】
現在、一般にインターネットに接続している企業や組織の多くは、セキュリティ上の理由からファイアウォールを使用し、ファイアウォール経由でインターネットに接続している。ファイアウォールとは、インターネットを経由した不特定多数のセンタ側の装置であるサーバへのアクセスに対して、通過点を設定し、そこで全ての入出力をチェックするハードウェアとソフトウェアのことである。このファイアウォールにより、許可されていない通信を遮断し、許可している通信を通過させたりすることが可能である。ところが、このファイアウォールではステートレスなプロトコルであるＨＴＴＰやＨＴＴＰＳのみ使用できるように制限していることが多い。
【００２１】
その理由としては、ブラウザを利用して外部から企業の紹介等のホームページへのアクセスを可能としても、それ以外のＦＴＰ（ファイル転送プロトコル）等のプロトコルは許可せず、そのことにより内部のファイルの流出や外部から内部へのファイルの侵入を防ぐことができるからである。このような事情から、外部からはブラウザで上述の企業や組織のＷｅｂセンタ側の装置であるサーバにアクセスしてホームページを閲覧することはできても、ファイル転送はできないようにすることができる。
【００２２】
なお、ＨＴＴＰ（HyperText Transfer Protocol）やＨＴＴＰＳ（Hypertext Transfer Protocol Security）は、ＷｅｂサーバとＷｅｂクライアント（ブラウザ）との間でデータをやりとりするためのプロトコルである。またホームページ等Ｗｅｂブラウザで表示されるデータは、センタ側のサーバ上にＨＴＭＬ（HyperText Markup Language）形式で作成され保存されている。ＨＴＭＬ形式で作成されるＨｙｐｅｒｔｅｘｔとは、文章や画像などに加え、例えばＷｅｂブラウザで表示したときに下線のついた文字があり、その文字を選択すると、他の文章が表示可能となるような、他の情報を関連付けした文書のことである。
【００２３】
上述のＨＴＴＰやＨＴＴＰＳはＨＴＭＬページの表示用のプロトコルであり、ステートレスなプロトコルの１つである。ステートレスなプロトコルとは、クライアント側の端末とセンタ側のサーバとの通信において、通信の開始は必ずクライアント側の端末から行い、端末からの要求の度に新しく接続を確立し、またクライアント側の端末が次回接続したときにはセンタ側のサーバは前回の接続や処理結果を記憶していないプロトコルのことである。そのため処理の流れは、例えば「クライアント側の端末からデータを送信し、センタ側のサーバではそのデータを受信し、その後でそのデータをセンタ側のサーバが処理し、その結果をセンタ側のサーバがクライアント側の端末に送信し、クライアント側の端末がそのデータを受信する」となる。この流れは１リクエスト１レスポンスの形になっている。
【００２４】
一般のＷｅｂブラウザとＷｅｂサーバにおいて、上述で述べた処理の流れは例えば次のようになる。まず、最初にＷｅｂブラウザに対して企業または組織のトップページとして公開されているＵＲＬ（Uniform Resource Locator：インターネットにおける情報の「住所」）を指定する。クライアントの端末であるブラウザは、ＵＲＬの内容を解析し、目的のＷｅｂサーバに対して接続を行う。Ｗｅｂサーバとの接続が完了すると、クライアント側の端末はＨＴＴＰプロトコルを使用してセンタ側のサーバに対してＨＴＭＬ形式のデータの送信を要求する。センタ側のサーバはこの要求に対して、指定されたＨＴＭＬ形式のデータを取得してクライアント側の端末に対してデータを送信する。クライアント側の端末ではセンタ側のサーバから送られたデータを受信し、その後、そのデータの内容に従ってフォントサイズの設定や色の設定を行い、トップページの表示を行う。その後ブラウザを使用して他のページを表示する場合には、上記の接続とデータの送受信を再度繰り返し行うことにより、ページの表示を行うことになる。なお、ＨＴＴＰＳは、ＨＴＴＰに関してセキュリティを付加したプロトコルであり、クライアント側の端末とセンタ側のサーバの間でデータの暗号化と復号化等を行う。
【００２５】
また以前はファイアウォールでのプロトコルの制限がなくクライアント側の端末とセンタ側のサーバの間でソケットを使用することができた。しかしながら、現状においてはセキュリティを考慮してファイアウォールを設定することが必要となってきている。従って、ファイアフォールを設定することにより、使用できるプロトコルが、ＨＴＴＰまたはＨＴＴＰＳに制限されることになる。この状況において、例えば、以前に動作していた、ソケットを使用することによって実装されたクライアント側の端末とセンタ側のサーバの間、の双方向で非同期な通信を行う構成の上で実装されたＲＰＣ等のアプリケーションを動かす要求がある。このように、センタ側のサーバがファイアウォールを経由してネットワークに接続されている状態で、ファイアウォールの制限によりステートレスなプロトコルであるＨＴＴＰまたはＨＴＴＰＳしか使用できない構成の上でも、双方向の非同期通信が動作するように、ソケットを使用していた以前の機能を利用できればたいへん便利である。
【００２６】
ファイアウォールを介して接続する端末とセンタ装置間の通信技術を開示する文献としては次のものがある（例えば、特許文献１参照）。
【００２７】
特許文献１には、二方向的なプロセス対プロセスのバイトストリームのプロトコルに関する技術が記載されており、詳細には次の内容が開示されている。
「ファイアウォールが使用されているネットワーク環境において分散型プログラミングを利用するための、ファイアウォールを通過する両方向プロセス・トゥ・プロセス・バイト・ストリーム・プロトコル」
【００２８】
【特許文献１】
特表２００２−５１７８５７号公報（段落〔０００８〕−〔０００９〕）
【００２９】
【発明が解決しようとする課題】
上記従来技術では上位のアプリケーションの機能と密接に連携して通信を実現しており、ファイアウォールを使用する環境で使用できるプロトコルによる通信では同期通信しか実現できていない。すなわち上位アプリケーションの使用環境が厳しく制限される。できるだけ使用環境が緩やかなことが望ましい。
【００３０】
本発明の目的は、上位のアプリケーションの、使用環境の制限が緩やかな通信方式を提供することである。すなわち、上位のアプリケーションが例えばサブルーチンのように自由度を持って扱える通信技術を提供することである。
【００３１】
【課題を解決するための手段】
本発明による解決手段の１つは、端末とセンタ側の装置であるサーバとの通信において、端末からの処理結果の返信依頼に基づきセンタ側装置が送信を行うことである。
【００３２】
本発明による解決手段の他の１つは、端末からの処理結果の返信依頼を、処理結果が得られない場合に、繰り返し送信することである。
【００３３】
本発明によるさらに他の解決手段は、端末からの処理結果の返信依頼を、上位のプログラムの条件を満たすまで、繰り返し送信することである。本発明の他の解決手段は、クライアント側の端末とセンタ側装置とで、受信用と送信用の処理が相互に干渉することなく独立に任意のタイミングで処理するようにしたことである。その他の解決手段は、以下の、実施の形態の説明、の中で記述する。本発明によれば、上位アプリケーションの使用環境に係る自由度を確保できる。
【００３４】
また以下に説明の実施の形態では次のような具体的な実施例の効果がある。
以前からソケットを通信の基盤として使用していたＲＰＣ（Remote ProcedureCall）のような上位アプリケーションを、本発明の通信方式、例えばＨＴＴＰまたはＨＴＴＰＳ等を使用した通信を基盤とするシステムに、容易に移行することができ、たいへん利用し易くなる。
【００３５】
【発明の実施の形態】
上記従来の技術の欄で説明したごとく、セキュリティを考慮すると、ファイアウォールを端末とセンタ側装置との間に設けることが必要である。ファイアフォールを設けると、使用できるプロトコルがＨＴＴＰまたはＨＴＴＰＳなど、特定のものに制限されることになる。
【００３６】
以前からソケット方式が使用されている場合、ソケット方式を使用していたことによって端末とセンタ側のサーバとの間ですでに利用されていた、双方向で非同期な通信を行う構成を前提として既に実装されているＲＰＣ等のアプリケーションを、セキュリティを強化したファイアウォールを有するシステムで動作させてほしいとの要求が考えられる。このように、センタ側の装置がファイアウォールを経由してネットワークに接続されている状態で、ファイアウォールの制限によりステートレスなプロトコルであるＨＴＴＰまたはＨＴＴＰＳしか使用できない構成の上でも、双方向の非同期通信が動作するようにでき、さらにソケットを使用していた以前のアプリケーション機能を利用できればたいへん便利である。
【００３７】
また以下に説明する実施の形態では次のような考え方を考慮している。クライアント側の端末とセンタ側の装置、例えばサーバあるいはホストコンピュータ、の間で、ＨＴＴＰやＨＴＴＰＳしか使用できない環境において、ＨＴＴＰやＨＴＴＰＳはステートレスなプロトコルであるために、クライアント側の端末からの要求の度に新しく接続を確立し、クライアント側の端末が次回接続したときにはセンタ側の装置(以下代表してサーバと記す)は前回の接続や処理結果を記憶していないという問題がある。この問題を解決することが必要であり、この解決には、セッション管理という方法が考えられる。
【００３８】
セッション管理では、センタ側のサーバ側でクライアント側の端末を管理し、クライアント側の端末の、以前の接続時の状況を管理する。そのため、例えば最初の接続でセンタ側のサーバに対して検索用の条件を送信しておき、次回の接続でその検索処理の結果をセンタ側のサーバから受信する、その結果を使用して次の接続では再度検索条件を絞り込んでセンタ側のサーバに送信する、といったような、以前の接続時の状況から今回の接続に対応したデータを送信および受信することが可能となる。しかしセッション管理においても、ＨＴＴＰやＨＴＴＰＳの１リクエスト１レスポンス方式は変わらない。そのため、この一連の処理に関しては、センタ側のサーバとクライアント側の端末では同期を取る必要があり、新たな課題が生じる。以下の実施の形態で説明する技術ではこのような課題に対して、図１１から図１２の説明で後述するように上位のアプリケーションにより簡単に対応できる。
【００３９】
以下に説明する本発明の実施の形態では、例えばセンタ側のサーバがファイアウォールを経由してネットワークに接続されている状態で、ファイアウォールの制限によりステートレスなプロトコルであるＨＴＴＰやＨＴＴＰＳしか使用できない場合において、クライアント側の端末とセンタ側のサーバとの間で双方向の非同期な通信を提供し、その上でＲＰＣ等のアプリケーションが双方向で非同期な通信を行って動作することを可能とする技術を提案している。
【００４０】
また以下の実施の形態は、例えばネットワークを介して接続されたクライアント側の端末とセンタ側のサーバとの間でファイアウォールの制限のためにステートレスなプロトコルであるＨＴＴＰやＨＴＴＰＳしか使用できない環境に対して、双方向の非同期な通信を行うアプリケーションを作成するための基盤の技術を提案している。
【００４１】
次に本発明の一実施例について図４〜図１０の図面を用いて説明する。
まず初めに、図４に示すシステムは、ネットワーク４３０を介してセンタ側の装置であるホストコンピュータ、例えばサーバ４１０とクライアント側の端末４４０が接続されている。センタ側の装置であるサーバ４１０はファイアウォール４２０を介してネットワーク４３０に接続している。一般に１つのセンタ側装置に接続するクライアント側の端末は１個以上であり、センタ側の装置はネットワークを介して接続する複数のクライアント側の端末４４０に対して並列的にサービスを提供する。インターネットに接続するセンタ側の装置であるサーバ４１０は、インターネットの特性上、不特定多数からのアクセスが想定される。そのためこの実施例では、セキュリティの強化の面からファイアウォール４２０を介してネットワーク４３０と接続している。このファイアウォール４２０はセキュリティを強化するために、クライアント側の端末４４０と接続可能なプロトコルをＨＴＴＰやＨＴＴＰＳといったステートレスなプロトコルに限定している。
【００４２】
図５に、クライアント側の端末とセンタ側の装置であるサーバとの間で、双方向で非同期な通信を行うための準備を行う処理のフローを示す。まず初めにクライアント側の端末４４０はステップ５２０でステートレスなプロトコルでサーバ４１０に接続する。ステップＳ５２２で端末４４０はリクエスト５２４をサーバ４１０に送信する。リクエスト５２４には、ストリーム通信の開始を要求する内容が入っている。次にそのリクエスト５２４を受信したサーバ４１０では、ステップＳ５６０で、接続を行ったクライアント側の端末を一意に識別できる識別情報を作成する。ステップＳ５６２で、サーバ４１０はこの識別情報をレスポンス５６１によって端末４４０に送信する。
【００４３】
端末４４０では、上記識別情報を受信し、次の通信からこの識別情報を使用する。すなわちサーバ４１０へのデータの送信またはサーバ４１０からのデータの受信といった、サーバとのストリームの処理を行う場合にこの識別情報を使用する。またセンタ側のサーバ４１０では、複数のクライアント側の端末からの接続がある場合でも、上記識別情報によりクライアント側の端末を識別することが可能になる。
【００４４】
双方向で非同期な通信を行うための準備が終了した後は、クライアント側の端末４４０からセンタ側のサーバ４１０へのデータの送信、またはクライアント側のサーバからのデータの受信が行われる。
その送受信は、クライアント側の端末４４０とセンタ側のサーバ４１０でそれぞれ相互に干渉することなく独立に任意のタイミングで行われる。
これは例えば、スレッドを使用することにより、双方向で非同期な通信が実現される。
【００４５】
以下に、クライアント側の端末４４０からセンタ側の装置であるサーバ４１０へのデータの送信と、クライアント側の端末４４０でのサーバ４１０からのデータの受信の処理を説明する。
【００４６】
図６は、クライアント側の端末４４０からセンタ側の装置であるサーバ４１０へのデータの送信方法のフローを示す。
最初にクライアント側の端末４４０からステートレスなプロトコルで、サーバ４１０に接続する。次にステップＳ６２０でクライアント側の端末を一意に識別できる識別情報とデータを伝送情報に設定して、クライアント側の端末からセンタ側のサーバへ、リクエスト６２１として送信する。センタ側のサーバ４１０ではその情報を受信し、ステップＳ６６０でクライアント側の端末を識別する識別情報を使用し、クライアント側の端末４４０からのデータを受信する準備をする。その後、センタ側の装置であるサーバ４１０ではステップＳ６７０でクライアント側の端末４４０から送信されたデータを受信する。
【００４７】
センタ側の装置であるサーバ４１０ではそのデータを受信した後で、ステップＳ６８０で、正しくデータを受信したことを表すデータを作成しレスポンス６８１としてクライアント側の端末４４０に送信する。クライアント側の端末はセンタ側の装置であるサーバに対して送信するデータが発生する度に上記のデータ送信方式に従いデータの送信を行う。
【００４８】
図７に、クライアント側の端末４４０からセンタ側の装置であるサーバ４１０に対してデータを送信する処理で使用される、ＨＴＴＰのリクエスト７１０（第１のカプセル化したデータ）とそのレスポンス７２０（第２のカプセル化したデータ）の内容を示す。ＨＴＴＰリクエスト７１０には、データのＨＴＴＰプロトコルによる通信情報のカプセル化により次の情報が設定されている。すなわちそれは、ＨＴＴＰヘッダ、センタ側の装置であるサーバ４１０がクライアント側の端末４４０を一意に識別する情報、このＨＴＴＰリクエストがクライアント側の端末４４０からセンタ側のサーバ４１０へのデータの送信であることを表す情報、および送信するデータ７１１の各情報である。
またＨＴＴＰレスポンス７２０には、ＨＴＴＰヘッダとセンタ側の装置であるサーバで設定した送信処理の成否が設定されている。
【００４９】
図８に、センタ側のサーバ４１０からのデータを受信するクライアント側の端末４４０の受信方法を示す。
まず、クライアント側の端末４４０からステートレスなプロトコルでセンタ側の装置であるサーバ４１０に接続し、ステップＳ８２０でクライアント側の端末４４０を一意に識別できる情報をリクエスト８２１としてセンタ側の装置であるサーバ４１０に送信する。
次にセンタ側の装置であるサーバ４１０ではその情報を受信した後で、ステップＳ８６０でクライアント側の端末４４０へのデータ送信の準備としてクライアント側の端末へ送信するデータを検索する。
【００５０】
検索した結果、データが有る場合には、センタ側の装置であるサーバ４１０はステップＳ８７０でクライアント側の端末４４０に対してそのデータをレスポンス８７１として送信する。
【００５１】
データが無い場合には、センタ側のサーバ４１０はリクエスト８２１が届いてから一定時間内かどうかの判定を行うステップＳ８８０を行う。ステップＳ８８０では現在の時間が、リクエストがサーバ４１０に届いてから一定時間内かどうかを確認し、一定時間内であればデータの検索を行うステップＳ８６０を続けて行う。一定時間を過ぎた場合には、ステップＳ８９０の処理に移りデータが無かったことを、クライアントにレスポンス８９１で送信する。上述したとおり、センタ側の装置であるサーバ４１０は、一定時間内にデータが有る場合には、ステップＳ８７０でクライアント側の端末４４０に対してそのデータをレスポンスＳ８７１として送信する。
【００５２】
検索処理Ｓ８６０で一定時間を過ぎた場合には、センタ側の装置であるサーバ４１０はステップＳ８９０でクライアント側の端末４４０に対してデータが無かったことを表すデータをレスポンス８９１として送信する。次にステップＳ８９１では本実施の処理を呼び出す上位のアプリケーションの要求処理を満たすか否かを判断する。その要求処理とは要求データの受信を完了した場合などである。要求処理を満足した場合は本処理を終了し、満足しない場合はステップＳ８２０に戻る。なおステップＳ８９１は上位のアプリケーションの使用方法によっては無くてもかまわない。一方クライアント側の端末４４０は、クライアント側の端末とセンタ側のサーバが通信を開始した直後、または一旦上記データ受信方式に従いデータ受信のリクエストを発行しレスポンスが返ってきた後で、常に上記のデータ受信方式に従いデータの受信を行う。
【００５３】
クライアント側の端末４４０からセンタ側のサーバ４１０へのリクエストは、クライアント側端末の上位のアプリケーションで終了を指示するまで続けられる。
【００５４】
図９は、クライアント側の端末４４０がセンタ側の装置であるサーバ４１０からデータを受信する処理で使用されるＨＴＴＰのリクエストとレスポンスのデータの内容を示している。
ＨＴＴＰリクエスト９１０（第３のカプセル化したデータ）では、データのＨＴＴＰプロトコルによる通信情報のカプセル化により次の情報が設定されている。すなわちそれは、ＨＴＴＰヘッダ、センタ側の装置であるサーバがクライアント側の端末を一意に識別する情報、このＨＴＴＰリクエストでクライアント側の端末４４０がセンタ側の装置であるサーバ４１０からデータを受信することを表す情報である。
【００５５】
ＨＴＴＰレスポンス９２０（第４のカプセル化したデータ）では、図８の８７０でセンタ側のサーバ４１０からクライアント側の端末４４０に送信されるＨＴＴＰレスポンス８７１のデータの内容を示している。そこでは、受信データがあることを表す情報と、センタ側のサーバ４１０からクライアント側の端末４４０に送信するデータ９２１を設定している。一方、ＨＴＴＰレスポンス９３０（第４のカプセル化したデータ）では、図８の８９０でセンタ側の装置４１０からクライアント側の端末４４０に送信されるＨＴＴＰレスポンス８９１のデータの内容を示している。
ここでは、受信データがないことを表す情報を設定している。
【００５６】
図１０は、本発明によるクライアント側の端末４４０とセンタ側の装置であるサーバ４１０との間の通信を独立した２本のＨＴＴＰ通信である送信用ＨＴＴＰ通信１１１０と受信用ＨＴＴＰ通信１１２０を使用して行う構成を示す。この構成では、クライアント側の端末４４０とセンタ側のサーバ４１０において送信と受信の処理を個別に独立して行う方法を示している。
【００５７】
その方法は、スレッドで送信および受信に関する処理を行うことにより、双方向で非同期の通信を行うことである。以下、その処理を説明する。まずその処理の実装に関して述べる。クライアント側の端末４４０においては、送信用ＨＴＴＰ通信１１１０を使用して送信を行う処理をクライアント側の端末４４０の送信スレッド１０２０で、受信用ＨＴＴＰ通信１１２０を使用して受信を行う処理をクライアント側の端末４４０の受信スレッド１０３０で実装している。またセンタ側の装置であるサーバ４１０においては、送信用ＨＴＴＰ通信１１１０を使用して受信を行う処理をサーバ４１０の受信スレッド１０６０、受信用ＨＴＴＰ通信１１２０を使用して送信を行う処理をサーバ４１０の送信スレッド１０７０で実装している。
【００５８】
次に処理の流れについて説明する。まずクライアント側の端末４４０で、センタ側の装置であるサーバ４１０へ送信するデータ１００１が上位のアプリケーションで発生し、送信が必要になった場合に次の処理を行う。
このデータ１００１は例えばある目的の演算処理をセンタ側装置に行わせるものである。
【００５９】
上記データの送信では、クライアント側の端末４４０の送信スレッド１０２０を使用して送信を開始し、送信用ＨＴＴＰ通信１１１０を使用して図６に示す方式でデータ１００１をセンタ側の装置であるサーバ４１０に対して送信する。データ１００１は図７のＨＴＴＰリクエストの送信するデータ７１１に相当する。サーバ４１０に送信するデータはリクエスト６２１であり、その結果をサーバからレスポンス６８１として受信する。
【００６０】
またクライアント側の端末４４０では、クライアント側の端末の受信スレッド１０３０によりセンタ側のサーバ４１０からのデータ１００３の受信処理を行う。
この受信処理は図８に示す方式で、まず受信要求を表すリクエストをセンタ側のサーバ４１０に送信する。
【００６１】
この受信要求を表すリクエストは、クライアント側の端末４４０の通信開始直後、または一旦クライアント側の端末の受信スレッド１０３０でセンタ側のサーバ４１０からのレスポンスを受け取った後で、常にセンタ側のサーバ４１０に対して送信しておく。次にセンタ側のサーバ４１０からライアント側の端末４４０に対して、送信するべきデータ１００３が送られた場合には、クライアント側の端末４４０はデータ１００３をセンタ側の装置であるサーバ４１０から受信する。サーバのデータ１００３は例えば上記データ１００１に基づく演算処理の結果として発生したデータであり、上記演算処理が終了すると上記端末４４０の識別情報が付加されて保持される。サーバ４１０は、図８のステップＳ８６０でこのデータの有無、すなわちリクエストされた演算処理の終了の有無および処理結果としてのデータの有無を検索する。上記処理結果であるデータ１００３を上記識別情報に基づく検索により見つけると、上述のとおり、そのデータ１００３を受信スレッド１０３０へ送信する。データ１００３は図９のＨＴＴＰレスポンスの受信するデータ９２１に相当する。クライアント端末４４０に送信するデータはレスポンス８７１であり、その要求はクライアント端末４４０からリクエスト８２１として受信する。
【００６２】
すなわち、センタ側の装置であるサーバ４１０ではリクエストに基づく処理を行った結果、クライアント側の端末４４０へ送信するべきデータ１００３が発生した場合には、このデータを送信するため、サーバ４１０の送信スレッド１０７０を使用して送信を開始し、受信用ＨＴＴＰ通信１１２０を使用してデータを送信する。
【００６３】
データの送信は、以下のステップの処理により実行される。
そのステップは、センタ側の装置であるサーバ４１０で、クライアント側の端末４４０に対する識別可能な情報等のデータを設定し、その情報をもとに図８のデータの検索でデータの取得が行われる。
またセンタ側のサーバ４１０は、クライアント側の端末４４０からのデータの受信が必要になった場合に、サーバ４１０の受信スレッド１０６０を使用して受信を開始し、送信用ＨＴＴＰ通信１１１０を使用してデータ１００１を受信する。
【００６４】
上述のように本実施例では、送信用ＨＴＴＰ通信路１１１０と受信用通信路１１２０を確保し続けることができる。この処理の終了処理は、例えば端末４４０の上位のアプリケーションプログラムが終了を判断し、指示した場合その中断命令によって実施される。
【００６５】
以上、述べたように上記実施の形態によれば、ファイアウォールを通過するステートレスなプロトコルを用いて双方向で非同期な通信を実行できる。さらに、本方法は機能が独立しており、関数化できるので、上位アプリケーションとの密着度が少なく、上位アプリケーションからサブルーチン的に用いることができる。そのために、他の通信方法を使用していたシステムを本実施例の方式を用いたシステムに移行することが容易である。
【００６６】
また、本実施例の方式で部分的に同期処理を実行するように上位のアプリケーションで調整することも、本実施例の機能独立性の高さから用意に実現できる。上位のアプリケーションから本発明の実施例の方法を用いて、部分的に同期処理を行う方法を図１１と図１２を用いて説明する。まず、図１１は非同期で動作する本実施例で説明した関数を非同期処理で用いる上位アプリケーションの使用例である。Ｓｕｂ１、Ｓｕｂ２、Ｓｕｂ３は本実施例の方法で動作する関数、ａｒｇ１、ａｒｇ２、ａｒｇ３はその関数の引数、Ｐｒｉｄ１、Ｐｒｉｄ２、Ｐｒｉｄ３は各関数が取得したプロセスｉｄである。まずステップＳ１１０１で関数Ｓｕｂ１をコールする。続いてステップＳ１１０２で関数Ｓｕｂ２をコールし、さらに続いてステップＳ１１０３で関数Ｓｕｂ３をコールする。この処理によりステップＳ１１０１からステップＳ１１０３は、それぞれ非同期で動作する。
【００６７】
図１２は非同期で動作する本実施例で説明した関数を同期処理で用いる上位アプリケーションの使用例である。Ｓｕｂ１、Ｓｕｂ２、Ｓｕｂ３は本実施例の方法で動作する関数、ａｒｇ１、ａｒｇ２、ａｒｇ３はその関数の引数、Ｐｒｉｄ１、Ｐｒｉｄ２、Ｐｒｉｄ３は各関数が取得したプロセスｉｄである。まずステップＳ１１０１で関数Ｓｕｂ１をコールする。ついでステップＳ１２０２でプロセスＰｒｉｄ１が終了するまで待機する。プロセスＰｒｉｄ１の終了を確認したのちステップＳ１２０３で関数Ｓｕｂ２をコールする。同様にステップＳ１２０４でプロセスＰｒｉｄ２が終了するまで処理を止めて待機する。プロセスＰｒｉｄ２が終了するのを確認したのち、ステップＳ１２０５で関数Ｓｕｂ３をコールする。この一連の処理によりステップＳ１２０１、ステップＳ１２０３、ステップＳ１２０５は、それぞれ同期をとって順番に動作する。
【００６８】
また本実施例に関して、例えばクライアント側の端末をＪａｖａ（Ｒ）のアプレット、センタ側の装置であるサーバをＪａｖａ（Ｒ）のサーブレットで実装することも可能である。
その場合には、以下のような方法でクライアント側の端末とセンタ側の装置であるサーバの間の、データの送信と受信に関して保守・点検や異常が発生した場合の原因を確認する方法が実装できる。
【００６９】
まずクライアント側の端末側では、Ｊａｖａ（Ｒ）コンソールに対して、送信用のＨＴＴＰ通信のリクエストとレスポンスの内容と、受信用のＨＴＴＰ通信のリクエストとレスポンスの内容を出力する。次にセンタ側の装置であるサーバ側では、送信用のＨＴＴＰ通信と受信用のＨＴＴＰ通信によりクライアント側の端末から送信されたリクエストと、クライアント側の端末に返却するレスポンスの内容を、サーブレットの使用するログファイルに出力する。
このようにクライアント側の端末とセンタ側の装置であるサーバの上記出力を合わせて確認することにより、データが正確に送信または受信されているかを確認することができる。
【００７０】
さらに、これまでにクライアント側の端末とセンタ側のサーバにおいてソケット等のファイアウォールなどのセキュリティ機能を通過できない通信機能を使用してアプリケーションを開発していた場合においても前述の方法を用いることで、ファイアウォールを通過する双方向の非同期な通信を行うアプリケーションへの移行がたいへん簡単になる。
【００７１】
【発明の効果】
本発明では、自由度の大きい通信方式あるいは通信方式に係る技術を提供できる。
また上記実施の形態に記載の技術によれば、ファイアウォールによる制限を意識せずに、双方向の非同期な通信を行うアプリケーションを作成することがたいへん簡単になる。
【図面の簡単な説明】
【図１】クライアント側の端末とセンタ側の装置であるサーバの間をソケットで接続した場合の処理の例を示す図である。
【図２】クライアント側の端末とセンタ側の装置であるサーバの間の、通信の基盤をソケットで作成した場合で、上位のアプリケーションとしてＲＰＣを実装した場合の処理の例を示す図である。
【図３】クライアント側の端末とセンタ側の装置であるサーバの間の、通信の基盤をソケットで作成した場合で、スレッドを使用することにより双方向で非同期の通信を行う例を示す図である。
【図４】クライアント側の端末とセンタ側の装置であるサーバがネットワークにより接続されていることを示す図である。
【図５】クライアント側の端末とセンタ側の装置であるサーバが通信の準備を行う処理を示す図である。
【図６】クライアント側の端末からセンタ側の装置であるサーバに対してデータを送信する処理を示す図である。
【図７】クライアント側の端末からセンタ側の装置であるサーバに対してデータを送信する処理で使用されるＨＴＴＰのリクエストとレスポンスのデータの内容を示す図である。
【図８】クライアント側の端末がセンタ側の装置であるサーバからデータを受信する処理を示す図である。
【図９】クライアント側の端末がセンタ側の装置であるサーバからデータを受信する処理で使用されるＨＴＴＰのリクエストとレスポンスのデータの内容を示す図である。
【図１０】クライアント側の端末とセンタ側の装置であるサーバの間の、通信の基盤をＨＴＴＰ通信で作成した場合で、スレッドを使用することにより双方向で非同期の通信を行う例を示す図である。
【図１１】上位アプリケーションの非同期処理での使用例である。
【図１２】上位アプリケーションの同期処理での使用例である。
【符号の説明】
１０１・・・クライアント側の端末からセンタ側のサーバに送信するデータおよびセンタ側のサーバが受信するデータ、１０３・・・センタ側のサーバからクライアント側の端末に送信するデータおよびクライアント側の端末が受信するデータ、１１０・・・クライアント側の端末、１２０・・・クライアント側の端末のソケット、１５０・・・センタ側の装置であるサーバ、１６０・・・センタ側のサーバのソケット、１７０・・・作成されたサーバのソケット、１８０・・・クライアントとサーバのソケットによる接続、２０１・・・ＲＰＣに従い作成された端末からサーバに送信するデータおよびサーバが受信するデータ、２０３・・・ＲＰＣに従い作成された端末に送信するデータおよびクライアント側の端末が受信するデータ、２１０・・・クライアント側の端末、２５０・・・センタ側のサーバ、２９０・・・ソケット通信路、３０１・・・クライアント側の端末からサーバに送信するデータおよびサーバが受信するデータ、３０３・・・サーバからクライアント側の端末に送信するデータおよびクライアント側の端末が受信するデータ、３１０・・・クライアント側の端末、３２０・・・クライアント側の端末の送信スレッド、３３０・・・クライアント側の端末の受信スレッド、３５０・・・センタ側のサーバ、３６０・・・センタ側の装置であるサーバの受信スレッド、３７０・・・サーバの送信スレッド、３９０・・・ソケット通信路、４１０・・・センタ側のサーバ、４２０・・・ファイアウォール、４３０・・・ネットワーク、４４０・・・クライアント側の端末、５２４・・・クライアント側の端末からのリクエスト、５６１・・・サーバからのレスポンス、６２１・・・クライアント側の端末からのリクエスト、６８１・・・サーバからのレスポンス、７１０・・・クライアント側の端末からデータを送信する場合のＨＴＴＰリクエスト、７１１・・・クライアントがサーバに送信するデータ、７２０・・・クライアント側の端末からデータを送信する場合のＨＴＴＰレスポンス、８２１・・・クライアント側の端末からのリクエスト、８７１・・・センタ側の装置であるサーバからのレスポンス、８９１・・・センタ側の装置であるサーバからのレスポンス、９１０・・・クライアント側の端末がデータを受信する場合のＨＴＴＰリクエスト、９２０・・・センタ側の装置であるサーバがクライアント側の端末に送信するデータがある場合のＨＴＴＰレスポンス、９２１・・・サーバがクライアントに送信するデータ、９３０・・・センタ側の装置であるサーバがクライアント側の端末に送信するデータがない場合のＨＴＴＰレスポンス、１００１・・・クライアント側の端末からセンタ側の装置であるサーバに送信するデータ、１００３・・・センタ側の装置であるサーバからクライアント側の端末に送信するデータ、１０２０・・・クライアント側の端末の送信スレッド、１０３０・・・クライアント側の端末の受信スレッド、１０６０・・・センタ側の装置であるサーバの受信スレッド、１０７０・・・センタ側の装置であるサーバの送信スレッド、１１１０・・・送信用ＨＴＴＰ通信、１１２０・・・受信用ＨＴＴＰ通信[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a bidirectional communication technology between a terminal and a device on the center side.
[0002]
[Prior art]
Generally, a socket method is widely used for two-way communication between a terminal on the client side and a server as a device on the center side. The socket is a function that handles connection and transmission and reception of data in a network. When communicating on a network, it is necessary to establish a connection between the communicating computers, and the socket has the function of the connection, the function of transmitting and receiving data while connected, and the function of disconnecting the connection. Have.
[0003]
An example in which bidirectional communication is performed between a terminal on the client side and a server as a device on the center side using a socket will be described below. First, a server, which is a device on the center side, provides some service to a terminal on the client side via a network. Also, the server, which is a device on the center side, prepares a port number corresponding to the service and always waits for a connection from the terminal on the client side. For example, a Web server provides a service for transmitting an HTML page in response to a request from a browser of a client terminal, and often uses a port number of 80.
[0004]
Next, the terminal on the client side requests some service from the server, which is a device on the center side, via the network, and processes the response. At that time, the client terminal uses a port number corresponding to the service to connect to the server via the network. For example, in the case of a browser of a terminal on the Web client side, a port number 80 is used to connect to the server. Then, the server requests the server to transmit the HTML page. As a result, when the HTML page is transmitted from the server, the content of the HTML page is displayed on the browser side.
[0005]
In FIG. 1, a server 150 as a device on the center side uses a socket 160 of the server, uses a fixed port number corresponding to a service, and waits for a connection from a terminal 110 on a client side. When a connection is made from the socket 120 of the client terminal 110 to the fixed port, the socket 160 of the server 150 is a server socket that is a device on the center side for newly communicating with the socket 120 of the client terminal. 170 is created, and the socket 170 of the server communicates with the socket 120 of the terminal on the client side. During this series of processes, the socket 160 of the server that has been waiting for a connection in the server 150 has created a socket 170 for this new server, and is again waiting for a connection from the client terminal.
[0006]
For the server socket 160, a server socket 170 corresponding to the terminal is sequentially created for each connection from the client terminal. In the socket 170 of the server that communicates with the client terminal, the data 101 transmitted from the socket 120 is received as received data 101 for the corresponding socket 120 of the client terminal. The data 103 to be transmitted can be transmitted. Transmission and reception of data between the server socket 170 and the terminal socket 120 can be performed asynchronously. When the transmission and reception processes are completed, the connection 180 between the terminal 110 and the socket 120 is disconnected.
[0007]
As described above, the socket 120 of the terminal 110 connects to the server 150 using the port number corresponding to the service. As a result of the processing in the server 150, the socket 120 of the terminal connected to the socket 170 of the server 150 receives the data 103 transmitted from the socket 170 as received data 103, Can be transmitted. Data transmission and reception from the client terminal socket 120 to the server socket 170 can be performed asynchronously. When the processing is completed, the connection 180 with the socket 170 of the server is disconnected.
[0008]
As described above, by applying the socket to the server and the terminal on the client side, two-way communication can be performed between the terminal on the client side and the server as the device on the center side.
[0009]
In such a configuration in which bidirectional communication can be performed between the client terminal and the server serving as the center device, communication is not merely transmission and reception of data, but a new data configuration and contents are transmitted to the client. By deciding as a protocol between the terminal and the server, it is possible to create an application that operates on that configuration.
[0010]
One of the implementation examples is RPC (Remote Procedure Call). RPC is a remote procedure call, and is a mechanism for entrusting execution of some procedures of a program to another machine connected to a network. The mechanism defines a protocol between the client terminal and the server that is the center device, transmits data from the client terminal, calls the server function that is the center device, and returns the result of the function. Is received from the server by the terminal.
[0011]
In FIG. 2, a protocol is determined between a terminal 210 on the client side and a server 250 which is a device on the center side. Next, the terminal 210 creates data 201 specifying a function to be called in the server 250 and arguments to be passed to the function according to the RPC protocol. The data 201 is transmitted to the server 250 using the socket communication path 290 created by the socket. The server 250 receives the data 201 transmitted from the terminal 210 and analyzes the contents of the data according to the RPC protocol. By analyzing the data content, a function to be called by the server 250 and arguments to be passed to the function are obtained. It should be noted that the following alphanumeric characters “S” mean steps which are system operation procedures. Thereafter, the server 250 passes the acquired argument to the acquired function, and calls the specified function with the argument in step S260. The result is created as transmission data 203 to the client terminal according to the RPC protocol. Next, the data is transmitted to the client terminal 210 using the socket communication path 290. The client terminal 210 acquires the data 203 of the result of the function call transmitted by the server 250.
[0012]
In the above RPC, when there is one process for requesting a procedure from the client terminal to the server on the center side, the transmission of the procedure call from the terminal to the server and the timing at which the terminal receives the result from the server are synchronized. The performance does not change regardless of whether it is taken or asynchronous. However, in the case of performing a plurality of independent RPC processes, the client side terminal and the center side server are not connected a plurality of times, and the client It is necessary to perform a plurality of processes for requesting a procedure from the side terminal to the server. In this case, if the process of transmitting the procedure call from the client terminal to the center server and the timing at which the terminal receives the result of the transmission from the center server are synchronized, the following problem occurs. For example, if a procedure call on a certain server on the center side takes a long time on the server, the next call for processing by another independent RPC will be delayed by that much, causing a problem that affects performance.
[0013]
In addition, it is necessary to make the RPC process independent as a function unaffected by other processes. For the reasons described above, when there are a plurality of processes for requesting a procedure from the client terminal to the center server, asynchronous communication is required. If asynchronous communication is possible, even if it takes time to call a procedure in independent RPC processing, it will not affect the call to a procedure of another RPC. In addition to the RPC, the bidirectional communication between the terminal on the client side and the server on the center side is desirably an asynchronous communication in terms of performance and functions.
[0014]
In such a situation, in communication between the client-side terminal using the current socket and the center-side server, the socket can asynchronously transmit and receive data. For this reason, by separately creating, for example, a thread using a thread to perform transmission and reception processing between the client-side terminal and the center-side server, bidirectional asynchronous communication as required above can be performed. is there.
[0015]
Next, in the communication between the client-side terminal and the center-side server in which the socket is used, the client terminal and the server separately perform transmission and reception processes, for example, as threads, thereby enabling bidirectional asynchronous communication. FIG. 3 shows an example in which the communication is performed by the communication.
[0016]
FIG. 3 shows an example in which communication between the client-side terminal 310 and the center-side server 350 is performed using the socket communication path 390. In this example, a description will be given of bidirectional and asynchronous communication by processing the transmission and reception processes separately in the terminal 310 and the server 350 by using threads.
[0017]
First, the implementation will be described. In the terminal 310, transmission and reception are performed using the socket communication path 390. The processing is implemented by the transmission thread 320 of the terminal and the reception thread 330 of the terminal, respectively. Further, in the server 350 on the center side, a process of performing transmission using the socket communication path 390 and a process of performing reception are implemented by a server transmission thread 370 and a server reception thread 360, respectively.
[0018]
Next, the communication method will be described. First, it is assumed that data 301 to be transmitted to the server 350 on the center side is generated on the terminal 310 on the client side and transmission is necessary. In this case, the transmission thread 320 of the terminal 310 transmits the data 301 using the socket communication path 390. When the client terminal 310 needs to receive data from the server 350 on the center side, the reception thread 330 of the terminal 310 receives data using the socket communication path 390. In this case, when the data 303 is transmitted from the server 350 on the center side to the terminal 310 on the client side, the terminal 310 receives the data 303 by the reception thread 330 of the client.
[0019]
It is also assumed that data 303 to be transmitted to the terminal 310 on the client side is generated in the server 350 on the center side, and transmission is required. In that case, the transmission thread 370 of the server 350 transmits the data 303 using the socket communication path 390. When the server 350 on the center side needs to receive data from the terminal 310, the data is received using the socket communication path 390 in the reception thread 360 of the server 350. In this case, when the data 301 is transmitted from the terminal 310 to the server 350, the server 350 receives the data 301 by the receiving thread 360 of the server.
[0020]
At present, many companies and organizations generally connected to the Internet use a firewall for security reasons and connect to the Internet through the firewall. A firewall refers to hardware and software for setting a passing point and checking all inputs and outputs there for access to an unspecified number of servers on the center side via the Internet. With this firewall, it is possible to block unauthorized communication and pass allowed communication. However, in many cases, this firewall restricts the use of only stateless protocols such as HTTP and HTTPS.
[0021]
The reason is that even if a browser can be used to access a homepage such as an introduction of a company from the outside, other protocols such as FTP (File Transfer Protocol) are not permitted. This is because it is possible to prevent a file from leaking out or intruding from the outside into the inside. Under such circumstances, it is possible to prevent a file from being transferred even if the user can access the server, which is a device on the Web center side of the company or organization described above, with a browser from the outside and browse the home page.
[0022]
Note that HTTP (HyperText Transfer Protocol) and HTTPS (Hypertext Transfer Protocol Security) are protocols for exchanging data between a Web server and a Web client (browser). Data displayed on a Web browser such as a homepage is created and stored in HTML (HyperText Markup Language) format on a server on the center side. Hypertext created in the HTML format includes, for example, text that is underlined when displayed on a Web browser in addition to text and images, and when the character is selected, another text can be displayed. This is a document to which other information is associated.
[0023]
The above-described HTTP and HTTPS are protocols for displaying HTML pages, and are one of stateless protocols. A stateless protocol is a communication between a client terminal and a server at the center, where communication is always initiated from the client terminal, and a new connection is established each time a request is made from the terminal. When the next connection is made, the server on the center side does not store the previous connection or processing result. For this reason, the processing flow is, for example, "transmit data from the client terminal, receive the data at the server on the center side, and then process the data on the server on the center side, and the server on the center side processes the result. The data is transmitted to the client terminal, and the client terminal receives the data. " This flow is in the form of one request and one response.
[0024]
In a general Web browser and Web server, the flow of the processing described above is, for example, as follows. First, a URL (Uniform Resource Locator: “address” of information on the Internet) that is disclosed as a top page of a company or organization to a Web browser is specified. A browser, which is a client terminal, analyzes the contents of the URL and connects to a target Web server. When the connection with the Web server is completed, the terminal on the client side requests transmission of data in HTML format to the server on the center side using the HTTP protocol. In response to this request, the server on the center side acquires the specified HTML format data and transmits the data to the terminal on the client side. The client terminal receives the data sent from the center server, and then sets the font size and color according to the contents of the data, and displays the top page. Thereafter, when another page is displayed using the browser, the page is displayed by repeating the above connection and transmission / reception of data again. Note that HTTPS is a protocol with security added to HTTP, and performs encryption and decryption of data between a terminal on the client side and a server on the center side.
[0025]
Previously, there was no restriction on the protocol in the firewall, and sockets could be used between the terminal on the client side and the server on the center side. However, at present, it is necessary to set a firewall in consideration of security. Therefore, by setting the firewall, the protocol that can be used is limited to HTTP or HTTPS. In this situation, for example, it was implemented on a configuration that performs bidirectional and asynchronous communication between a client-side terminal and a center-side server that were previously implemented by using sockets and that was implemented using sockets. There is a request to run an application such as RPC. In this way, in a state where the server on the center side is connected to the network via the firewall, bidirectional asynchronous communication operates even in a configuration in which only a stateless protocol, HTTP or HTTPS, can be used due to firewall restrictions. It would be very useful if you could take advantage of the old features that used sockets.
[0026]
There are the following documents that disclose communication technology between a terminal connected through a firewall and a center device (for example, see Patent Document 1).
[0027]
Patent Literature 1 discloses a technology related to a protocol of a bidirectional process-to-process byte stream, and specifically discloses the following content.
"A two-way process-to-process byte stream protocol through firewalls to take advantage of distributed programming in network environments where firewalls are used"
[0028]
[Patent Document 1]
JP-T-2002-517857 (paragraphs [0008]-[0009])
[0029]
[Problems to be solved by the invention]
In the above prior art, communication is realized in close cooperation with the function of a higher-level application, and only synchronous communication can be realized in communication using a protocol that can be used in an environment using a firewall. That is, the usage environment of the host application is severely restricted. It is desirable that the use environment is as gentle as possible.
[0030]
An object of the present invention is to provide a communication method in which the use environment of a higher-level application is moderately restricted. In other words, it is an object of the present invention to provide a communication technique in which a higher-level application can be handled with a degree of freedom like a subroutine.
[0031]
[Means for Solving the Problems]
One of the solutions according to the present invention is that, in communication between a terminal and a server which is a device on the center side, the center side device transmits based on a request for returning a processing result from the terminal.
[0032]
Another solution according to the present invention is to repeatedly transmit a request for returning a processing result from a terminal when the processing result cannot be obtained.
[0033]
Still another solution according to the present invention is to repeatedly transmit a request for returning a processing result from a terminal until the condition of a higher-order program is satisfied. Another solution of the present invention is that the processing for reception and the processing for transmission are independently performed at an arbitrary timing between the client-side terminal and the center-side device without mutual interference. Other solutions are described in the following description of the embodiments. According to the present invention, it is possible to secure the degree of freedom relating to the usage environment of the host application.
[0034]
In the embodiment described below, there are the effects of the following specific examples.
A higher-level application such as RPC (Remote Procedure Call), which previously used a socket as a communication base, can be easily transferred to a system based on communication using the communication method of the present invention, for example, HTTP or HTTPS. Can be very easy to use.
[0035]
BEST MODE FOR CARRYING OUT THE INVENTION
As described in the section of the related art, when considering security, it is necessary to provide a firewall between the terminal and the center-side device. Providing a firewall limits the protocols that can be used to specific ones, such as HTTP or HTTPS.
[0036]
If the socket method has been used for a long time, the two-way asynchronous communication that has already been used between the terminal and the server on the center side due to the use of the socket method has already been assumed. There is a demand that an application such as an RPC that is mounted be operated on a system having a firewall with enhanced security. As described above, in a state where the center-side device is connected to the network via the firewall, bidirectional asynchronous communication operates even in a configuration in which only a stateless protocol, HTTP or HTTPS, can be used due to firewall restrictions. It would be very useful to be able to do so, and to take advantage of the old application features that used sockets.
[0037]
In the embodiment described below, the following concept is considered. In an environment where only HTTP or HTTPS can be used between a client-side terminal and a center-side device, for example, a server or a host computer, HTTP or HTTPS is a stateless protocol. A new connection is established, and when the client terminal connects next time, there is a problem that the device on the center side (hereinafter, referred to as a server) does not store the previous connection or the processing result. It is necessary to solve this problem, and for this solution, a method called session management can be considered.
[0038]
In the session management, the server on the center side manages the terminal on the client side, and the state of the terminal on the client side at the time of the previous connection is managed. Therefore, for example, the search condition is transmitted to the server on the center side in the first connection, and the result of the search processing is received from the server on the center side in the next connection. In the connection, it is possible to transmit and receive data corresponding to the current connection from the situation at the time of the previous connection, such as narrowing down the search condition again and transmitting it to the server on the center side. However, even in session management, the one-request one-response method of HTTP or HTTPS does not change. Therefore, regarding this series of processing, it is necessary to synchronize the server on the center side and the terminal on the client side, and a new problem arises. In the technology described in the following embodiments, such a problem can be easily dealt with by a higher-level application as described later with reference to FIGS.
[0039]
In the embodiment of the present invention described below, for example, in a state where a server on the center side is connected to a network via a firewall and only the stateless protocols HTTP and HTTPS can be used due to firewall restrictions, Proposal of technology that provides bidirectional asynchronous communication between the client terminal and the center server, and enables applications such as RPC to operate by performing bidirectional asynchronous communication. are doing.
[0040]
Further, the following embodiment is applicable to an environment in which only a stateless protocol, such as HTTP or HTTPS, can be used to restrict a firewall between a client terminal and a center server connected via a network. Has proposed a basic technology for creating applications that perform two-way asynchronous communication.
[0041]
Next, an embodiment of the present invention will be described with reference to FIGS.
First, in the system shown in FIG. 4, a host computer as a device on the center side, for example, a server 410 and a terminal 440 on the client side are connected via a network 430. The server 410, which is a device on the center side, is connected to the network 430 via the firewall 420. Generally, the number of client-side terminals connected to one center-side device is one or more, and the center-side device provides services in parallel to a plurality of client-side terminals 440 connected via a network. The server 410, which is a device on the center side connected to the Internet, is assumed to be accessed from an unspecified number of people due to the characteristics of the Internet. Therefore, in this embodiment, the network is connected to the network 430 via the firewall 420 to enhance security. In order to enhance security, the firewall 420 limits a protocol connectable to the client terminal 440 to a stateless protocol such as HTTP or HTTPS.
[0042]
FIG. 5 shows a flow of processing for preparing for performing bidirectional and asynchronous communication between a client-side terminal and a server as a center-side device. First, in step 520, the client terminal 440 connects to the server 410 using a stateless protocol. In step S522, the terminal 440 transmits the request 524 to the server 410. The request 524 contains the content requesting the start of the stream communication. Next, in step S560, the server 410 that has received the request 524 creates identification information that can uniquely identify the connected client-side terminal. In step S562, server 410 transmits this identification information to terminal 440 by response 561.
[0043]
The terminal 440 receives the identification information and uses the identification information from the next communication. In other words, the identification information is used when processing a stream with the server, such as transmitting data to the server 410 or receiving data from the server 410. The server 410 on the center side can identify the terminal on the client side based on the identification information even when there are connections from a plurality of terminals on the client side.
[0044]
After the preparation for performing bidirectional asynchronous communication is completed, data is transmitted from the client terminal 440 to the center server 410 or data is received from the client server.
The transmission / reception is performed at an arbitrary timing independently without mutual interference between the client-side terminal 440 and the center-side server 410.
For example, bidirectional and asynchronous communication is realized by using a thread.
[0045]
Hereinafter, a process of transmitting data from the client-side terminal 440 to the server 410 as the center-side device and a process of receiving data from the server 410 at the client-side terminal 440 will be described.
[0046]
FIG. 6 shows a flow of a method of transmitting data from the terminal 440 on the client side to the server 410 which is a device on the center side.
First, the terminal 440 on the client side connects to the server 410 using a stateless protocol. Next, in step S620, identification information and data that can uniquely identify the client terminal are set as transmission information, and transmitted from the client terminal to the center server as a request 621. The server 410 on the center side receives the information, and prepares to receive data from the terminal 440 on the client side by using the identification information for identifying the terminal on the client side in step S660. After that, the server 410, which is the device on the center side, receives the data transmitted from the terminal 440 on the client side in step S670.
[0047]
After receiving the data, the server 410 on the center side creates data indicating that the data has been correctly received in step S680, and transmits it as a response 681 to the terminal 440 on the client side. The client terminal transmits data in accordance with the above-described data transmission method each time data to be transmitted to the server, which is a device on the center side, occurs.
[0048]
FIG. 7 shows an HTTP request 710 (first encapsulated data) and a response 720 (first encapsulated data) used in the process of transmitting data from the client-side terminal 440 to the server 410 as the center-side device. 2 encapsulated data). The following information is set in the HTTP request 710 by encapsulating communication information of the data by the HTTP protocol. That is, the HTTP header, information that the server 410 as the center device uniquely identifies the client terminal 440, and that the HTTP request is transmission of data from the client terminal 440 to the center server 410. And information of data 711 to be transmitted.
In the HTTP response 720, an HTTP header and the success or failure of the transmission process set by the server which is a device on the center side are set.
[0049]
FIG. 8 shows a receiving method of the terminal 440 on the client side for receiving data from the server 410 on the center side.
First, the terminal 440 on the client side connects to the server 410 as the center side device using a stateless protocol, and in step S820, information that can uniquely identify the terminal 440 on the client side is set as a request 821 as the request 821. Send to
Next, after receiving the information, the server 410 serving as the center device searches for data to be transmitted to the client terminal in preparation for transmitting data to the client terminal 440 in step S860.
[0050]
As a result of the search, if there is data, the server 410, which is the device on the center side, transmits the data as a response 871 to the terminal 440 on the client side in step S870.
[0051]
If there is no data, the server 410 on the center side performs step S880 of determining whether or not the request 821 has arrived within a predetermined time. In step S880, it is checked whether the current time is within a certain time after the request arrives at the server 410, and if it is within the certain time, step S860 for searching for data is continuously performed. If the predetermined time has elapsed, the process proceeds to step S890, and the absence of data is transmitted to the client in response 891. As described above, when there is data within a certain period of time, the server 410, which is a device on the center side, transmits the data as a response S871 to the terminal 440 on the client side in step S870.
[0052]
If the predetermined time has elapsed in the search processing S860, the server 410 as the center apparatus transmits data indicating that there is no data to the client terminal 440 as a response 891 in step S890. Next, in step S891, it is determined whether or not the request processing of the upper application that calls the processing of the present embodiment is satisfied. The request processing is, for example, when reception of request data is completed. If the request processing is satisfied, this processing ends, and if not, the flow returns to step S820. Step S891 may be omitted depending on the method of using the higher-level application. On the other hand, immediately after the client terminal and the center server start communication, or after a request for data reception has been issued and a response has been returned according to the data reception method, the terminal 440 on the client side always has the above data. Data is received according to the receiving method.
[0053]
The request from the client-side terminal 440 to the center-side server 410 is continued until an application on the client-side terminal instructs termination.
[0054]
FIG. 9 shows the contents of HTTP request and response data used in the process in which the client terminal 440 receives data from the server 410 as the center device.
In the HTTP request 910 (third encapsulated data), the following information is set by encapsulating communication information of the data by the HTTP protocol. That is, the HTTP header, information that the server as the center device uniquely identifies the client terminal, and that the client terminal 440 receives data from the server 410 as the center device by this HTTP request. This is the information to represent.
[0055]
The HTTP response 920 (fourth encapsulated data) indicates the data content of the HTTP response 871 transmitted from the server 410 on the center side to the terminal 440 on the client side at 870 in FIG. Here, information indicating that there is received data and data 921 to be transmitted from the server 410 on the center side to the terminal 440 on the client side are set. On the other hand, the HTTP response 930 (fourth encapsulated data) indicates the data content of the HTTP response 891 transmitted from the device 410 on the center side to the terminal 440 on the client side at 890 in FIG.
Here, information indicating that there is no received data is set.
[0056]
FIG. 10 shows the communication between the client-side terminal 440 and the server 410 as the center-side device using two independent HTTP communications, the transmission HTTP communication 1110 and the reception HTTP communication 1120 according to the present invention. The following shows the configuration performed. This configuration shows a method in which the client terminal 440 and the center server 410 perform transmission and reception processes individually and independently.
[0057]
The method is to perform bidirectional asynchronous communication by performing processing related to transmission and reception by a thread. Hereinafter, the processing will be described. First, the implementation of the processing will be described. In the client-side terminal 440, the process of transmitting using the transmission HTTP communication 1110 is performed by the transmission thread 1020 of the client-side terminal 440, and the process of performing reception using the reception HTTP communication 1120 is performed by the client. It is implemented in the receiving thread 1030 of the terminal 440. Also, in the server 410, which is a device on the center side, the process of performing reception using the transmission HTTP communication 1110 is performed by the reception thread 1060 of the server 410, and the process of performing transmission using the reception HTTP communication 1120 is performed by the server 410. This is implemented in the transmission thread 1070.
[0058]
Next, a processing flow will be described. First, when data 1001 to be transmitted to the server 410 as a device on the center side is generated by a higher-level application at the terminal 440 on the client side and transmission is required, the following processing is performed.
The data 1001 is for, for example, causing the center-side device to perform a certain purpose of arithmetic processing.
[0059]
In the data transmission, transmission is started using the transmission thread 1020 of the client terminal 440, and the data 1001 is transmitted using the transmission HTTP communication 1110 in the method shown in FIG. Send to Data 1001 corresponds to the data 711 transmitted by the HTTP request in FIG. The data transmitted to the server 410 is a request 621, and the result is received as a response 681 from the server.
[0060]
In the terminal 440 on the client side, reception processing of the data 1003 from the server 410 on the center side is performed by the reception thread 1030 of the terminal on the client side.
In this reception processing, a request indicating a reception request is first transmitted to the server 410 on the center side by the method shown in FIG.
[0061]
The request representing the reception request is always sent to the center server 410 immediately after the communication of the client terminal 440 starts or after a response is received from the center server 410 by the reception thread 1030 of the client terminal. To be sent. Next, when data 1003 to be transmitted is sent from the server 410 on the center side to the terminal 440 on the client side, the terminal 440 on the client side receives the data 1003 from the server 410 which is a device on the center side. . The server data 1003 is, for example, data generated as a result of arithmetic processing based on the data 1001, and when the arithmetic processing ends, the identification information of the terminal 440 is added and held. In step S860 of FIG. 8, the server 410 searches for the presence or absence of this data, that is, the presence or absence of the end of the requested arithmetic processing and the presence or absence of data as a processing result. When the data 1003 as the processing result is found by the search based on the identification information, the data 1003 is transmitted to the receiving thread 1030 as described above. Data 1003 corresponds to the data 921 received by the HTTP response in FIG. The data transmitted to the client terminal 440 is a response 871, and the request is received as a request 821 from the client terminal 440.
[0062]
That is, when the server 410 serving as the center device performs processing based on the request and, as a result, data 1003 to be transmitted to the client terminal 440 is generated, the transmission thread of the server 410 is used to transmit the data. Transmission is started using 1070 and data is transmitted using the HTTP communication for reception 1120.
[0063]
Data transmission is performed by the following steps.
In this step, data such as identifiable information for the client-side terminal 440 is set in the server 410, which is a device on the center side, and data is obtained by searching the data in FIG. 8 based on the information. .
When it becomes necessary to receive data from the terminal 440 on the client side, the server 410 on the center side starts reception using the receiving thread 1060 of the server 410 and uses the HTTP communication 1110 for transmission. The data 1001 is received.
[0064]
As described above, in the present embodiment, it is possible to continue to secure the transmission HTTP communication path 1110 and the reception communication path 1120. The termination processing of this processing is executed by, for example, an interruption command of the higher-level application program of the terminal 440, when it determines the termination and gives an instruction.
[0065]
As described above, according to the above-described embodiment, bidirectional and asynchronous communication can be performed using a stateless protocol that passes through a firewall. Further, since the method has independent functions and can be functioned, the method has a low degree of close contact with a higher-level application and can be used as a subroutine from the higher-level application. Therefore, it is easy to transfer a system using another communication method to a system using the method of the present embodiment.
[0066]
Further, adjustment by an upper-level application so as to partially execute the synchronization processing in the method of the present embodiment can be easily realized from the high function independence of the present embodiment. A method for partially performing a synchronization process from a higher-level application using the method of the embodiment of the present invention will be described with reference to FIGS. First, FIG. 11 shows a usage example of a higher-level application that uses the functions described in the present embodiment that operate asynchronously in asynchronous processing. Sub1, Sub2, and Sub3 are functions operated by the method of the present embodiment, arg1, arg2, and arg3 are arguments of the function, and Prid1, Prid2, and Prid3 are process ids obtained by each function. First, in step S1101, the function Sub1 is called. Subsequently, in step S1102, the function Sub2 is called, and subsequently, in step S1103, the function Sub3 is called. By this processing, steps S1101 to S1103 operate asynchronously.
[0067]
FIG. 12 shows an example of use of a higher-level application that uses the functions described in the present embodiment that operate asynchronously in synchronous processing. Sub1, Sub2, and Sub3 are functions operated by the method of the present embodiment, arg1, arg2, and arg3 are arguments of the function, and Prid1, Prid2, and Prid3 are process ids obtained by each function. First, in step S1101, the function Sub1 is called. Next, in step S1202, the process waits until the process Prid1 ends. After confirming the end of the process Prid1, the function Sub2 is called in step S1203. Similarly, in step S1204, the process is stopped and waits until the process Prid2 ends. After confirming that the process Prid2 has ended, the function Sub3 is called in step S1205. By this series of processing, steps S1201, S1203, and S1205 operate sequentially in synchronization with each other.
[0068]
In this embodiment, for example, it is also possible to mount the client terminal with a Java (R) applet and the center side device with a Java (R) servlet.
In such a case, the following methods are implemented to check the cause of the maintenance and inspection of data transmission and reception between the client-side terminal and the server that is the center-side device, and the cause of any abnormalities. it can.
[0069]
First, the client terminal outputs the contents of the transmission HTTP communication request and response and the reception HTTP communication request and response to the Java (R) console. Next, the server, which is a device on the center side, uses the servlet to transmit the request transmitted from the terminal on the client side and the contents of the response returned to the terminal on the client side by the HTTP communication for transmission and the HTTP communication for reception. Output to a log file.
In this way, by checking the above output of the client side terminal and the server which is the center side device together, it is possible to check whether data is transmitted or received correctly.
[0070]
Furthermore, even if the client terminal and the server at the center have developed applications using communication functions that cannot pass through security functions such as firewalls such as sockets, the above method can be used. It is very easy to move to an application that performs two-way asynchronous communication passing through.
[0071]
【The invention's effect】
According to the present invention, a communication method having a high degree of freedom or a technique related to the communication method can be provided.
Further, according to the technology described in the above embodiment, it is very easy to create an application that performs bidirectional asynchronous communication without being aware of restrictions imposed by a firewall.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating an example of processing when a terminal on a client side and a server as a device on a center side are connected by a socket.
FIG. 2 is a diagram illustrating an example of processing in a case where a communication base between a client-side terminal and a server which is a center-side device is created by a socket, and RPC is implemented as a higher-order application.
FIG. 3 is a diagram illustrating an example of performing bidirectional asynchronous communication by using a thread when a communication base between a client terminal and a server as a center apparatus is created by a socket. is there.
FIG. 4 is a diagram showing that a terminal on the client side and a server as a device on the center side are connected via a network.
FIG. 5 is a diagram illustrating a process in which a terminal on the client side and a server as a device on the center side prepare for communication.
FIG. 6 is a diagram showing a process of transmitting data from a terminal on the client side to a server which is a device on the center side.
FIG. 7 is a diagram illustrating the contents of HTTP request and response data used in a process of transmitting data from a client terminal to a server that is a center device.
FIG. 8 is a diagram showing a process in which a terminal on the client side receives data from a server which is a device on the center side.
FIG. 9 is a diagram showing contents of HTTP request and response data used in a process in which a client terminal receives data from a server which is a center device.
FIG. 10 is a diagram showing an example in which bidirectional asynchronous communication is performed by using a thread when a communication base between a terminal on the client side and a server which is a device on the center side is created by HTTP communication. It is.
FIG. 11 is an example of use in asynchronous processing of a higher-level application.
FIG. 12 is an example of use in a synchronization process of a host application.
[Explanation of symbols]
101: Data transmitted from the client side terminal to the center side server and data received by the center side server; 103: Data transmitted from the center side server to the client side terminal and the client side terminal Data to be received, 110: terminal on the client side, 120: socket on the terminal on the client side, 150: server as a device on the center side, 160: socket on the server on the center side, 170 ... · Created server socket, 180: Connection by client and server socket, 201: Data transmitted from terminal to server and data received by server created according to RPC, 203: Created according to RPC Data to be sent to the client terminal and data to be received by the client terminal, 0: terminal on the client side, 250: server on the center side, 290: socket communication path, 301: data transmitted from the terminal on the client side to the server and data received by the server, 303 ... Data transmitted from the server to the client terminal and data received by the client terminal, 310: client terminal, 320: transmission thread of the client terminal, 330: client terminal , Receiving thread of 350, a server on the center side, 360, receiving thread of a server which is a device on the center side, 370, transmitting thread of server, 390, socket communication path, 410, center Side server, 420 ... firewall, 430 ... network, 440 ... client 524: Request from client-side terminal, 561: Response from server, 621: Request from client-side terminal, 681: Response from server, 710: Client HTTP request when transmitting data from the terminal on the client side, 711... Data transmitted from the client to the server, 720... HTTP response when transmitting data from the terminal on the client side, 821. Request from terminal, 871... Response from server as center-side device, 891... Response from server as center-side device, 910... When client terminal receives data HTTP request, 920 ... HTTP response when there is data to be transmitted to the client side terminal, 921... Data transmitted from the server to the client, 930... When there is no data transmitted from the server as the center side device to the client side terminal 1001 ... data transmitted from the client terminal to the server which is the center device, 1003 ... data transmitted from the server which is the center device to the client terminal, 1020 ... A transmission thread of the client-side terminal, 1030... A reception thread of the client-side terminal, 1060... A reception thread of the server as the center-side device, 1070. 1110: HTTP communication for transmission, 1120: HTTP communication for reception

Claims

A communication method for performing communication between a device on the center side and a terminal through a firewall,
Based on the transmission from the terminal, the center-side device creates identification information, the center-side device transmits the created identification information, and the terminal receives this,
A request having the data with the identification information added is transmitted from the terminal to the device on the center side, and the device on the center side receives the request having the data, sends a response to the terminal based on the reception of the data, and The device performs processing based on the received data,
The terminal makes a request for returning a processing result to the center device, and the center device checks the presence or absence of the processing result in response to the request from the terminal, and transmits the presence or absence of the processing result or the processing result. Response to the above terminal,
If the response indicates that there is no processing result, the terminal makes a request for returning the processing result to the center-side device,
A terminal that repeats transmission of a request from the terminal for returning the processing result and investigation of the presence or absence of a processing result for the request and transmission of a response to the terminal performed by the center-side device. A two-way communication system for transmitting and receiving data between the device and the center.

A communication method for performing communication between a device on the center side and a terminal through a firewall,
Upon receiving the transmission from the terminal, the center-side device creates identification information, and the center-side device transmits the created identification information to the terminal,
A request having the data to which the identification information is added is received from the terminal, and the center-side device performs a process based on the received data,
A request for returning the processing result is received from the terminal, the device on the center side checks the presence or absence of the processing result regarding the request from the terminal, performs the presence or absence of the processing result or sends a response for transmitting the processing result to the terminal,
Each time the center-side device receives a request for returning a processing result from the terminal, the device repeats checking for the presence or absence of a processing result for the request and transmitting a response to the terminal. A two-way communication method for transmitting and receiving data to and from the equipment on the center side.

3. A two-way communication system for transmitting and receiving between a terminal and a device on the center side according to claim 2, wherein transmission and reception are performed based on HTTP or HTTPS.

A communication method for performing communication between a device on the center side and a terminal through a firewall,
The terminal requests the center device for identification information, receives the identification information from the center device,
The terminal transmits a processing request having data to which the identification information is added to the center-side device,
The terminal transmits a request for returning a processing result of the processing request to the center-side device,
The terminal receives a response indicating the presence or absence of a processing result or a processing result with respect to the request from the center-side device,
When the response indicates that there is no processing result, the terminal transmits a request for returning the processing result to the center-side device, receives the response,
The terminal is configured to repeat transmission of a request for returning the processing result when the response indicates that there is no processing result, for transmitting and receiving between the terminal and the center-side device. Two-way communication system.

5. The two-way communication system for transmitting and receiving between a terminal and a center-side device according to claim 4, wherein transmission and reception are performed based on HTTP or HTTPS.

A program for performing communication between a center-side device and a terminal, wherein a system having a computer has the following functions by executing the program, and is a program for two-way communication.
Based on the transmission from the terminal, the center-side device creates identification information, and the center-side device transmits the identification information to the terminal,
Performing transmission with the first encapsulated data having the identification information from the terminal to the center-side device,
The center-side device transmits the second encapsulated data to the terminal as a response based on the data reception,
The terminal performs transmission with the third encapsulated data to the center side for returning a processing result of the transmission with the first encapsulated data,
In response to the transmission with the third encapsulated data from the terminal, the center-side device transmits the presence or absence of the processing result or the fourth encapsulated data for transmitting the processing result to the terminal,
When the fourth encapsulated data indicates that there is no processing result, the terminal transmits to the center side the third encapsulated data for returning the processing result,
When the fourth encapsulated data indicates that there is no processing result, the transmission from the terminal for returning the processing result and the operation of the center-side device based on the transmission are repeated.

A program for performing communication between the center-side device and the terminal, wherein the system having a computer has a function for performing two-way communication by executing the present program,
Receiving the first encapsulated data having the identification information of the terminal from the terminal, and transmitting the second encapsulated data to the terminal as a response based on the reception of the data;
The third encapsulated data is received from the terminal as a request for returning the processing result, and the device on the center side transmits the fourth encapsulated data to the terminal for the presence or absence of the processing result or for transmitting the processing result. And
The center-side device repeats the transmission of the fourth encapsulated data each time it receives the third encapsulated data for returning the processing result from the terminal.