JP2003018181A - 通信システム、通信方法、及び制御プログラム - Google Patents

Abstract

(57)【要約】 【課題】 ネットワークに不必要な負荷をかけることな
く持続的コネクションを維持する。 【解決手段】 リクエストに対するレスポンスを直ぐに
は返さず、所定時間経過した後に返すことによって、持
続的コネクションが切断されるのを防ぐための本来必要
のない状態通知（ダミー通信）の回数を減らす。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークを介
して通信する通信技術に関し、特に、通信コネクション
の維持技術に関する。

【０００２】

【従来の技術】ＬＡＮやインターネットの普及ととも
に、計算機やネットワーク機器だけでなく、種々の機器
をネットワークに接続し、ネットワークを介して情報を
取得したり、或いは機器を制御する技術が普及しつつあ
る。この種の技術としては、例えば、遠隔地の温度計を
読み取ったり、ビデオカメラの雲台を制御したりする技
術が挙げられる。

【０００３】これらの技術は、操作対象機器と操作用機
器の双方がネットワークに接続され、所定の通信プロト
コルで通信することによって実現される。ところが、操
作対象機器と操作用機器が通信できない場合もある。

【０００４】多くの場合、ある組織が自組織のＬＡＮを
インターネットに接続する場合、ファイアウォールと総
称される通信の制限手段をその接続点に設ける。このフ
ァイアウォールは、ＬＡＮをインターネット上の悪意の
利用者から守るために設けられるものであるが、同時
に、ＬＡＮ上の正当な利用者のインターネット利用をも
妨げてしまう場合もある。

【０００５】例えば、ファイアウォールの実現手段の１
つとして、ＬＡＮとインターネットの間で特定の条件
（通信プロトコル、送信元、送信先など）を満たした通
信パケットだけを通過させるように制限することが広く
行われている。この場合、サーバ／クライアントモデル
とストリーム型通信プロトコル（ＴＣＰ／ＩＰ）に特性
に基づいて、ＬＡＮ内のクライアントが通信要求を発し
て、インターネット上のサーバを利用することはできる
ようにするが、逆に、ＬＡＮ上のサーバに対して、イン
ターネットからは通信要求を伝えられないようにするの
が一般的である。従って、ＬＡＮの一般の利用者は、イ
ンターネットからの通信要求を受けるサーバをＬＡＮ上
に置くことはできない。

【０００６】さらに、ファイアウォールでは、ＬＡＮと
インターネットの間で通信パケットをＯＳレベルで（通
信プロトコルスタックで）中継しないように制限するこ
とも行われる。この場合、安全性は高まるが、インター
ネットからＬＡＮ方向だけでなく、ＬＡＮからインター
ネットへ出ていく通信パケットもファイアウォールを通
過できなくなる。

【０００７】そこで、アプリケーションレベルのプログ
ラムで、通信パケット全体ではなく通信すべきデータの
みを中継するようにして、必要なデータの通信を実現す
る。代表的な中継プログラムとしては、ＷＷＷ（Ｗｏｒ
ｌｄ Ｗｉｄｅ Ｗｅｂ）のデータを中継するプロキシ
サーバがあり、多くのファイアウォール上でサービスが
提供されているが、全てのアプリケーションプロトコル
に対して中継プログラムが用意されているわけではな
い。従って、ＬＡＮの一般利用者は、全てのアプリケー
ションプロトコルを利用できるとは限らない。

【０００８】このように、ファイアウォールが機器間に
存在する場合、操作対象機器と操作用機器の間の通信
は、一般に制約されることが多く、機器のネットワーク
の接続先が制限されたり、遠隔操作用の通信プロトコル
がファイアウォールを通過できなかったりすることがあ
る。ファイアウォールの設定を変えることで制約を取り
除くことはできるが、ファイアウォールの安全性を弱め
るので一般に認められないことが多い。また、ファイア
ウォール管理者への依頼事務手続きが煩雑であり、ま
た、管理者が多忙で頻繁な変更には応じられないという
場合も多く、ファイアウォールの設定を変えることは避
けられている。

【０００９】そこで、独自の通信プロトコルを使用する
ことなく、ファイアウォールを通過できるように設定さ
れていることの多いＷＷＷの通信プロトコルＨＴＴＰ
（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔ
ｏｃｏｌ）を用いる方法が考案された。この方法では、
独自のプロトコルをＨＴＴＰのメソッドやデータに変換
したり、或いは埋め込んだりして、ＨＴＴＰとしてファ
イアウォールを通過させ、独自のプロトコルのコマンド
やデータに再構成する。この方法は、機器操作に限ら
ず、音声や動画等の連続データのファイアウォール通過
にも広く用いられている。

【００１０】ところで、ＨＴＴＰは前述のストリーム型
通信プロトコル（ＴＣＰ／ＩＰ）上にサーバ／クライア
ントモデルのアプリケーションプロトコルを構築したも
のであるが、クライアントからのリクエストとサーバか
らのレスポンスの１往復の通信が基本となっている。当
初のプロトコルでは、この１往復の通信を１つのストリ
ーム型通信コネクションに当てており、１つのリクエス
ト毎にストリーム型コネクションを確立する必要があ
り、そのオーバーヘッドが大きかった。

【００１１】そこで、現在のプロトコルでは、持続的コ
ネクションが規定され、１つの通信コネクションを複数
往復分のリクエスト・レスポンス交換に当てられるよう
になっている。さらに、レスポンスが返る前に続けてリ
クエストを送るパイプライン処理も規定されている。

【００１２】

【発明が解決しようとする課題】このように、ＨＴＴＰ
の通信の枠組みを利用することで、ファイアウォール内
部のＬＡＮに接続された操作用機器からインターネット
上の操作対象機器への通信・制御は可能になるが、逆方
向のインターネット上の操作用機器からＬＡＮに接続さ
れた操作対象機器への通信・制御のための通信要求がフ
ァイアウォールを通過できないという問題が引き続き存
在する。

【００１３】さらに、この問題を解決する過程で、持続
的コネクションを用いることにより、通信コネクション
確立処理の回数を低減し、全体的な通信時間を短縮する
ことことが考えられるが、機器間のＨＴＴＰデータを中
継するプロキシサーバで設定される持続的コネクション
の切断タイムアウト時間が、利用者の機器操作や機器の
状態変化の間隔に比べて一般に短いため、操作や状態変
化によって通信の必要が発生した時には既に持続的コネ
クションが切断されていて、持続的コネクションの効果
が得られない場合がある。

【００１４】持続的コネクションの効果を最大限に活か
すためには、タイムアウトにより切断されないようにダ
ミーの通信を行えばよいが、利用者の機器操作や機器の
状態変化の間隔が長い場合は、ダミーの通信量が増えて
しまうという問題がある。

【００１５】本発明は、このような従来技術の問題に鑑
みてなされたもので、その課題は、ネットワークに不必
要な負荷をかけることなく持続的コネクションを維持で
きるようにすることにある。

【００１６】

【課題を解決するための手段】上記課題を解決するた
め、本発明は、持続的コネクションを確立してネットワ
ークを介して通信を行う通信システムにおいて、所定の
要求信号を受信した場合に、所定時間だけ待機した後に
受信応答を返す応答制御手段を備えている。

【００１７】また、本発明は、持続的コネクションを確
立してネットワークを介して通信を行う通信システムに
おける通信方法であって、所定の要求信号を受信した場
合に、所定時間だけ待機した後に受信応答を返す応答制
御工程を備えている。

【００１８】また、本発明は、持続的コネクションを確
立してネットワークを介して通信を行う通信システムに
て実行される制御プログラムであって、所定の要求信号
を受信した場合に、所定時間だけ待機した後に受信応答
を返す内容を有している。

【００１９】

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

【００２０】［第１の実施形態］図１は、本発明を適用
した遠隔操作システムのシステム構成図である。図１に
おいて、１００はインターネットであり、ファイアウォ
ール１１１を介して、ＬＡＮ１１０が接続されている。
インターネット１００には、操作端末１３０、ＬＡＮ１
１０には、被操作装置１２０が接続されている。なお、
ファイアウォール１１１には、プロキシサーバ１１２が
導入されている。

【００２１】被操作装置１２０は、ＣＰＵやメモリやネ
ットワークインタフェースを有するパーソナルコンピュ
ータやワークステーションなどのコンピュータと同等の
機能を有する装置であり、後述する状態通知プログラム
１４１、操作データ収集プログラム１４２および制御プ
ログラム１４３を有する。

【００２２】照明１２２と、ブラインド１２３は、コン
トローラ１２１を介して被操作装置１２０に接続され
る。

【００２３】コントローラ１２１は、制御プログラム１
４３からの制御指令に応じて、照明１２２の点灯・消灯
を制御したり、ブラインド１２３の開閉位置を制御する
とともに、照明１２２の点灯状態や、ブラインド１２３
の開閉位置などの状態情報を状態通知プログラム１４１
に回答したりする。

【００２４】操作端末１３０は、被操作装置１２０と同
様に、ＣＰＵやメモリやネットワークインタフェースを
有するパーソナルコンピュータやワークステーションな
どのコンピュータと同等の機能の手段で構成される装置
で、後述するＨＴＴＰサーバプログラム１５１、操作表
示ＣＧＩプログラム１５２、操作ＣＧＩプログラム１５
３、操作表示ＧＵＩプログラム１５４を有しており、表
示装置１３１とマウスなどの操作入力装置１３２と接続
されている。

【００２５】操作端末１３０上で動作するＨＴＴＰサー
バプログラム１５１は、ＨＴＴＰリクエストに対する応
答やＣＧＩプログラムの実行といった一般的なＷＷＷサ
ーバ機能を有するプログラムであり、操作端末１３０
は、いわゆるＷＷＷサーバとして機能する。なお、ＨＴ
ＴＰサーバプログラム１５１は、持続的コネクションと
パイプライン処理に対応し、特にパイプライン処理にお
いては、ＨＴＴＰの規定に従ってリクエストの到着順に
レスポンスを返すことを保証する機能を有する。

【００２６】操作表示ＧＵＩプログラム１５４は、被操
作装置１２０から送られた装置の状態を表示装置１３１
に表示し、利用者の操作対象に対する操作を操作入力装
置１３２から受け取り、被操作装置１２０に送るための
ＧＵＩを司る。

【００２７】一方、被操作装置１２０上では、状態通知
プログラム１４１と操作データ収集プログラム１４２
が、ＨＴＴＰサーバプログラム１５１にアクセスするこ
とによって、操作端末１３０に向けて状態通知と操作デ
ータ収集依頼が行なわれる。

【００２８】以下、本遠隔操作システムの動作を詳述す
る。

【００２９】図２は、図１に示した遠隔操作システムの
通信シーケンス図である。図２の例では、状態通知サイ
クル、操作伝達サイクルの２本の通信コネクションを使
用し、機器の状態の通知と操作端末からの操作情報の収
集が行なわれる。

【００３０】状態通知サイクルでは、被操作装置１２０
上の状態通知プログラム１４１が、操作端末１３０上の
操作表示ＣＧＩプログラム１５２をアクセスすることで
状態通知を行い（例えば状態情報Ｓ０、Ｓ１を通知
し）、操作端末１３０側では送られた状態情報を元に操
作画面の表示を行う。

【００３１】操作伝達サイクルでは、被操作装置１２０
上の操作データ収集プログラム１４２が、操作端末１３
０上の操作ＣＧＩプログラム１５３をアクセスすること
で、操作伝達要求を行って例えば操作伝達Ｅ０、Ｅ１を
収集し、制御プログラム１４３により、収集に係る操作
伝達情報を元に対象機器を制御する。これらの状態通知
サイクルと操作伝達サイクルは並列に動作する。

【００３２】次に、状態通知サイクルでの被操作装置１
２０の処理について、図３，４のフローチャートに基づ
いて説明する。なお、本フローチャートは、状態通知プ
ログラム１４１の処理を示すものであるが、その詳細を
説明する前に、状態通知プログラム１４１で使用されて
いるタイマ、カウンタについて予め説明しておく。

【００３３】状態通知プログラム１４１は、２種類のタ
イマとそのタイムアウト値、２つのカウンタを有する
（いずれも図示せず）。

【００３４】第１のタイマは、以下で説明する持続的コ
ネクションのタイムアウトを防ぐために用いられ、ＨＴ
ＴＰレスポンスの受信から次のＨＴＴＰリクエストの発
信までの時間を計測する。そのタイムアウト値は可変で
あり、状態通知プログラム１４１自身がこれを変化させ
る。その初期値は一般的なプロキシサーバプログラムの
持続的コネクションのタイムアウト時間よりわずかに短
く設定される。このタイマは状態通知プログラム１４１
につき１個である。以下、このタイマを持続的コネクシ
ョンタイムアウトタイマと呼ぶ。

【００３５】第２のタイマは、ＨＴＴＰサーバプログラ
ム１５１やプロキシサーバプログラム１１２、ネットワ
ークのいずれかに障害が発生した際に状態通知プログラ
ム１４１が無限の待ち状態に陥るのを回避するもので、
ＨＴＴＰリクエストとして状態情報を送信してからその
リクエストに対応するＨＴＴＰレスポンスが返るまでの
時間を計測する。タイムアウト値は、一般のＨＴＴＰに
おけるタイムアウト値と同等に設定され、固定である。
ＨＴＴＰリクエスト１つにつき１つのタイマが割り当て
られ、リクエストの送信とともに計測がスタートし、レ
スポンスの受信とともに計測を終了し、本タイマの割り
当てが解放される。以下、このタイマをＨＴＴＰタイム
アウトタイマと呼ぶ。

【００３６】第１のカウンタは、状態通知プログラム１
４１がＨＴＴＰサーバプログラム１５１からの応答を待
っているＨＴＴＰリクエスト数を数えるもので、その初
期値は０である。以下、このカウンタを応答待ちカウン
タと呼ぶ。

【００３７】第２のカウンタは、送信するＨＴＴＰリク
エストの順序を数えるもので、リクエストデータ中にそ
の値が埋め込まれる。その初期値は、操作表示ＣＧＩプ
ログラム１５２のカウンタの初期値と同じである。以
下、このカウンタを送信順序カウンタと呼ぶ。

【００３８】状態通知プログラム１４１では、まず、Ｈ
ＴＴＰサーバプログラム１５１との間に持続的コネクシ
ョン（ｐｅｒｓｉｓｔｅｎｔ ｃｏｎｎｅｃｔｉｏｎ）
を確立する（ステップＳ１００）。ここでは、利用する
ＨＴＴＰのバージョンに応じた方法により、持続的コネ
クションを確立する。

【００３９】なお、この持続的コネクションは、ファイ
アウォール１１１上のプロキシサーバプログラム１１２
との間で確立され、プロキシサーバプログラム１１２と
ＨＴＴＰサーバプログラム１５１との間は、これとは独
立した持続的コネクションがプロキシサーバプログラム
１１２によって確立される。

【００４０】次に、持続的コネクションのタイムアウト
タイマを０にセットしてスタートさせた後（ステップＳ
１０５）、状態変化があるまで待つ（ステップＳ１１
０）。この状態変化は、例えば、制御プログラム１４３
が、共有メモリ上に確保された状態変化フラグ（図示せ
ず）を状態変化があったときにＯＮにすることで、状態
通知プログラム１４１が検知できる。状態通知プログラ
ム１４１は、状態変化を検知したときは状態変化フラグ
をＯＦＦに戻して、ステップＳ１３０に進むが、この処
理については後述する。

【００４１】ステップＳ１１０で状態変化がなかった場
合は、持続的コネクションタイムアウトタイマを調べ、
所定のタイムアウト値に達しているかどうかを判別する
（ステップＳ１２０）。その結果、所定のタイムアウト
値に達していなければ、ステップＳ１１０に戻る。

【００４２】持続的コネクションタイムアウトタイマ
が、所定のタイムアウト値に達している場合には、持続
的コネクションが切断されるのを防止すべく、状態変化
がなくても状態情報を送信するため（すなわち、ダミー
送信を行うため）、ステップＳ１３０に進む。

【００４３】ステップＳ１３０では、照明１２２の点灯
状態とブラインド１２３の開閉位置の状態情報を収集す
る。この情報収集は、コントローラ１２１を接御する制
御プログラム１４３にその制御情報を要求することによ
って実現されるが、状態変化があった際に制御プログラ
ム１４３が状態情報を格納するバッファを設け、状態通
知プログラム１４１がこのバッファを監視することによ
り、情報収集を行ってもよい。

【００４４】続いて、ステップＳ１４０で、状態情報に
応じた送信情報をＨＴＴＰのＰＯＳＴコマンドを用いて
作成する。例えば、照明１２２がＯＦＦの状態で、ブラ
インド１２３が７０％の開閉位置であり、送信順序カウ
ンタの値が「３」の場合に、操作端末１３０における操
作表示ＣＧＩプログラム１５２のＵＲＬが http://foo.bar.co.jp/cgi-bin/newstatus であれば、以下のようなコマンドを作成する。（「−−−−−」の内部の行） ----- POST http://foo.bar.co.jp/cgi-bin/newstatus HTTP/1.0 Content-Length:37 ＼r＼n send_counter=3＼r＼ｎ light=OFF＼r＼n Blind=70＼r＼n ----- そして、応答待ちカウンタと送信順序カウンタの値をそ
れぞれインクリメントした後（ステップＳ１５０）、持
続的コネクションを用いて、上記送信情報を操作端末１
３０のＨＴＴＰサーバプログラム１５１に向けて送信す
る（ステップＳ１６０）。この通信は、ファイアウォー
ル１１１上のプロキシサーバプログラム１１２によって
中継され、ＨＴＴＰサーバプログラム１５１に届くこと
になる。

【００４５】ＨＴＴＰサーバプログラム１５１は、この
情報を受け取り、操作表示ＣＧＩプログラム１５２を呼
び出す。操作表示ＣＧＩプログラム１５２は、受け取っ
た状態情報に基づいて対象機器の操作画面を更新し、所
定時間後に状態通知プログラム１４１に応答を返す。こ
の詳細は後述する。

【００４６】次に、状態通知プログラム１４１は、状態
変化の有無を判別し（ステップＳ１７０）、状態変化が
有った場合は、ステップＳ１３０に戻り、パイプライン
処理機能を用いて、次のＨＴＴＰリクエストを続けて送
信する。

【００４７】一方、状態変化がなかったな場合は、ＨＴ
ＴＰタイムアウトタイマがタイムアウトしているか否か
を判別し（ステップＳ１８０）、ＨＴＴＰタイムアウト
タイマがタイムアウトしていた場合は、ステップＳ２２
０に進み、必要なエラー処理を行い、持続的コネクショ
ンをクローズして（ステップＳ２３０）、状態通知プロ
グラム１４１の処理を終了する。

【００４８】一方、ＨＴＴＰタイムアウトタイマがタイ
ムアウトしていない場合は、ＨＴＴＰサーバプログラム
１５１からの応答が有ったか否かを判別する（ステップ
Ｓ１９０）。その結果、ＨＴＴＰサーバプログラム１５
１からの応答が未だ無い場合は、ステップＳ１７０に戻
る。

【００４９】一方、ＨＴＴＰサーバプログラム１５１か
らの応答が有った場合は、応答待ちカウンタのカウント
値をデクリメントし（ステップＳ２００）、その応答待
ちカウンタのカウント値が「０」になったか否かを判別
する（ステップＳ２１０）。その結果、カウント値が
「０」になった場合は、ステップＳ１０５に戻り、
「０」にならなかった場合、即ち、現在応答待ちのＨＴ
ＴＰリクエストがない場合は、ステップＳ１７０に戻
る。以上が、状態通知プログラム１４１の処理内容であ
る。

【００５０】次に、状態通知サイクルの操作端末１３０
での処理について説明する。

【００５１】操作端末１３０上で動作しているＨＴＴＰ
サーバプログラム１５１に対し、ＵＲＬパスである /cgi-bin/newstatus が要求されたとき、操作表示ＣＧＩプログラム１５２が
実行されるように設定を行なっておく。そのため、上記
のような要求情報を被操作装置１２０から受け取ると、
操作表示ＣＧＩプログラム１５２が起動される。パイプ
ライン処理により、連続して要求を受け取った際には、
複数の操作表示ＣＧＩプログラム１５２が起動され、同
時に並行して動作する。

【００５２】操作表示ＣＧＩプログラム１５２は、プロ
グラム間の共有メモリ領域に処理順序カウンタを持ち
（図示せず）、同時に動作する操作表示ＣＧＩプログラ
ム１５２間で処理順序を確認するのに用いる。この初期
値は、前述の状態通知プログラム１４１の送信順序カウ
ンタの初期値と同じである。

【００５３】また、操作表示ＣＧＩプログラム１５２
は、プログラム間の共有メモリ領域に図６に示す情報交
換テーブル４０１を持つ。この情報交換テーブル４０１
は、操作表示ＣＧＩプログラム１５２、操作ＣＧＩプロ
グラム１５３、操作表示ＧＵＩプログラム１５４の間で
共有され、データの交換に用いられる。

【００５４】また、操作表示ＣＧＩプログラム１５２
は、タイマを持ち（図示せず）、本プログラムが起動さ
れてからの時間を計測する。このタイマのタイムアウト
時間は、ＨＴＴＰのリクエストを発してからレスポンス
が返るまでＨＴＴＰクライアントやプロキシサーバがタ
イムアウトせずに待つ時間よりわずかに短く設定され
る。一般に、このタイムアウト時間は、持続的コネクシ
ョンの切断タイムアウト時間よりもかなり長い。

【００５５】次に、この操作表示ＣＧＩプログラム１５
２の処理を図５のフローチャートを参照しながら詳細に
説明する。

【００５６】操作表示ＣＧＩプログラム１５２は、ま
ず、上記タイマを「０」にセットし、スタートさせる
（ステップＳ３００）。次に、処理順序カウンタのカウ
ント値を読み込む（ステップＳ３０５）。次に、この処
理順序カウンタのカウント値と、本操作表示ＣＧＩプロ
グラム１５２が起動される際にＨＴＴＰサーバプログラ
ム１５１から渡された送信順序カウンタのカウント値
（すなわち、被操作装置１２０から送られてきた状態情
報の中の送信順序カウンタのカウント値）を比較し、こ
れ以降の処理を行ってもよいか否かを確認する（ステッ
プＳ３１０）。

【００５７】その結果、２つのカウント値が等しく、以
降の処理を行ってもよい場合は、ステップＳ３２０に進
み、送信順序カウンタのカウント値の方が大きく、以降
の処理を行ってはいけない場合は、ステップＳ３０５に
戻り、送信順序カウンタと処理順序カウンタのカウント
値と等しくなるまで待つ。

【００５８】両カウント値が等しくなり、該カウント値
に対応する処理の処理時期が到来した場合は、ステップ
Ｓ３２０で、被操作装置１２０から送られた状態情報を
読込み、その情報を共有メモリ領域に確保した情報交換
テーブル４０１の中の状態欄に書き込む。例えば、前述
の状態情報が送信されてきた場合は、照明がＯＦＦ、ブ
ラインド開閉位置が７０％であるので、図６に示したよ
うに、状態欄のｌｉｇｈｔ欄に「ＯＦＦ」、状態欄のｂ
ｌｉｎｄ欄には「７０」と書き込む。

【００５９】そして、操作表示ＧＵＩプログラム１５４
に操作表示更新要求を行うことで操作画面が更新され
る。なお、共有メモリの代わりに、ファイルを共有して
も良いし、通信ポートを利用してそれぞれのプログラム
間でプロセス間通信を行い、情報の共有を行ってもよ
い。また、操作表示ＧＵＩプログラム１５４を利用する
ことなく、操作表示ＣＧＩプログラム１５２に操作画面
を表示・更新する機能を持たせてもよい。

【００６０】続いて、処理順序カウンタの値をインクリ
メントし（ステップＳ３３０）、上記タイマが所定のタ
イムアウト時間に達するのを待つ（ステップＳ３４
０）。そして、上記タイマが所定のタイムアウト時間に
達すると、ＡＣＫ応答情報を作成して標準出力に出力す
る（ステップＳ３５０）。すると、ＨＴＴＰサーバプロ
グラム１５１によって、被操作装置１２０上の状態通知
プログラム１４１に応答が返される。例えば、以下のよ
うな応答情報を標準出力に出力する。 ----- Content-Type: application/x-newstatus ＼r＼n ok＼r＼n ----- すると、ＨＴＴＰサーバプログラム１５１によって必要
な他の情報が付加され、上記例では次のような応答が返
される。 ----- HTTP/1.0 200 OK Content-Type: application/x-newstatus Content-Length: 4 ＼r＼n ok＼r＼n ----- 以上が、操作表示ＣＧＩプログラム１５２の処理内容で
ある。

【００６１】次に、操作伝達サイクルの被操作装置１２
０での処理について説明する。まず、操作データ収集プ
ログラム１４２の処理を図７のフローチャートを参照し
ながら詳細に説明する。

【００６２】操作データ収集プログラム１４２は、ま
ず、ステップＳ５０１で回線を確保する。続いて、ステ
ップＳ５０２で、操作端末１３０のＨＴＴＰサーバプロ
グラム１５１に向けて操作伝達要求コマンドを送信す
る。例えば、操作端末１３０における操作ＣＧＩプログ
ラム１５３のＵＲＬが http://foo.bar.co.jp/cgi-bin/getoperation の場合、以下のようなコマンドを送信する。 ----- POST http://foo.bar.co.jp/cgi-bin/getoperation HTTP/1.0 Content-Length:6 ＼r ＼n none＼r ＼n ----- ＨＴＴＰサーバプログラム１５１は、この情報を受け取
り、操作ＣＧＩプログラム１５３を呼び出す。操作ＣＧ
Ｉプログラム１５３は操作イベントを待ち、イベントが
発生したら操作情報を返送する。この詳細は後述する。

【００６３】次に、操作データ収集プログラム１４２
は、所定時間の範囲内で操作ＣＧＩプログラム１５３か
らの応答が受信されるまで待つ（ステップＳ５０３，Ｓ
５０５）。また、所定時間待っても応答がない場合に
は、ステップＳ５０４でエラーフラグをＯＮにセットし
て、ステップＳ５０８に進む。

【００６４】ＨＴＴＰサーバプログラム１５１は、操作
ＣＧＩプログラム１５３からの応答を受信すると、受信
データのチェックを行い（ステップＳ５０６）、受信デ
ータが操作データであれば、その操作データを操作デー
タキュー（図示せず）に追加する（ステップＳ５０
７）。

【００６５】例えば、照明１２２をＯＮし、ブラインド
１２３の開閉位置を８０％にするよう操作端末１３０側
で指示された場合、以下のような応答が受信される。 ----- HTTP/1.0 200 OK Content-Type: application/x-getoperation Content-Length: 20 ＼r ＼n light=ON＼r＼n blind=80＼r＼ n ----- 被操作端末１２０では、制御プログラム１４３は、イベ
ントドリブンで動作し、操作データ収集プログラム１４
２は、操作データキューの情報が書き換えられたとき、
操作要求イベントの発生を制御プログラム１４３に通知
する。操作要求イベントの発生が通知されると、制御プ
ログラム１４３は、上記の例の場合、照明１２２の点灯
とブラインド１２３の開閉位置を８０％にする操作情報
を操作データキューより取り出し、コントローラ１２１
を制御し、照明１２２とブラインド１２３を要求通りの
状態に変更する。

【００６６】操作データ収集プログラム１４２は、次
に、回線をクローズ（ステップＳ５０８）する。そし
て、エラーフラグがＯＮにセットされているか否かを判
別し（ステップＳ５０９）、エラーフラグがＯＮにセッ
トされていれば、プログラムを終了し、ＯＦＦにセット
されていれば、プログラムの先頭へ戻り、同様の処理を
繰り返す。以上が、操作データ収集プログラムの処理内
容である。

【００６７】次に、操作伝達サイクルの操作端末１３０
での処理について説明する。

【００６８】状態通知サイクルと同様に、操作端末１３
０上で動作しているＨＴＴＰサーバプログラム１５１に
対し、ＵＲＬパスである /CGI-bin/getoperation が要求されたとき、操作ＣＧＩプログラム１５３が実行
されるように設定を行なっておく。そのため、上記のよ
うな要求を被操作装置１２０から受け取ると、操作ＣＧ
Ｉプログラム１５３が起動される。

【００６９】この操作ＣＧＩプログラム１５３の動作を
図８のフローチャートを参照しながら詳細に説明する。

【００７０】操作ＣＧＩプログラム１５３は、状態通知
サイクルがＨＴＴＰリクエストのタイムアウトで回線が
切断されない最大時間までは、操作イベントを待つ。

【００７１】操作ＣＧＩプログラム１５３は、まず、所
定時間が経過するか（ステップＳ６０１）、或いは、操
作が行なわれ、情報交換テーブル４０１の要求欄が更新
されるまで待つ（ステップＳ６０２）。例えば、ＨＴＴ
Ｐリクエストのタイムアウト時間から往復のネットワー
ク遅延時間を差し引いたものよりも短い時間だけ、操作
イベントを待つ。

【００７２】操作ＣＧＩプログラム１５３は、操作が検
出された場合には、更新された操作要求情報を情報交換
テーブル４０１の中の要求欄より読み取る（ステップＳ
６０３）。ここでは、例えば、照明１２２をＯＮし、ブ
ラインド１２３を８０％にするといった情報を読み込
む。

【００７３】ステップＳ６０４では、読み込んだ操作要
求情報に応じた応答情報を作成し、標準出力に出力す
る。すると、ＨＴＴＰサーバプログラム１５１によって
被操作装置１２０上の操作データ収集プログラム１４２
に応答が返される（ステップＳ６０５）。例えば、以下
のような応答情報を標準出力に出力する。 ----- Content-Type:application/x-getoperation ＼r＼n light=ON＼r＼n blind=80＼r＼n ----- すると、ＨＴＴＰサーバプログラム１５１によって必要
な他の情報が付加され、操作データ収集プログラム１４
２の応答情報で説明したような情報が返される。

【００７４】一方、ステップＳ６０１で所定時間待って
もユーザの操作がなかったと判別された場合は、ステッ
プＳ６０４では、以下のようなｎｏｎｅとしての応答情
報を標準出力に出力する。 ----- Content-Type:application/x-getoperation ＼r＼n none＼r＼n ----- 以上が、操作ＣＧＩプログラムの処理内容である。

【００７５】なお、操作収集データプログラム１４２の
説明では、持続的コネクションを用いないで説明した
が、持続的コネクションを用いるようにすることで、通
信コネクション確立処理の回数を低減し、全体的な通信
時間をより一層、短縮することことが可能となる。

【００７６】この場合、ステップＳ５０１で持続的コネ
クションを確立するようにし、ステップＳ５０８を削除
してコネクションをクローズしないようにし、ステップ
Ｓ５０９からステップＳ５０２に戻るようにすればよ
い。また、操作収集プログラム１４２では、ＨＴＴＰレ
スポンス受信から次のＨＴＴＰリクエスト送信までの時
間間隔がないので、持続的コネクションの維持操作は不
要である。

【００７７】以上、本実施形態によれば、ファイアウォ
ールの内部に被操作装置を設置しても、インターネット
上の操作端末から被操作装置を操作することが可能であ
り、かつ操作ＣＧＩプログラムが利用者の操作による操
作イベントが発生するのを待つので、操作情報の被操作
装置への伝達の遅延が少なくなる。

【００７８】さらに、本実施形態においては、状態通知
プログラム１４１がＨＴＴＰの持続的コネクションとパ
イプライン処理機能を活用して、より遅延なく状態通知
を操作端末１３０に送ることができるが、操作表示ＣＧ
Ｉプログラム１５２がＨＴＴＰリクエストに対するレス
ポンスを直ぐには返さず、所定時間経過した後に返すこ
とによって、持続的コネクションが切断されるのを防ぐ
ための本来必要のない状態通知（ダミー通信）の回数を
減らすことができる。これは、ＨＴＴＰのタイムアウト
時間が持続的コネクションのタイムアウト時間よりも一
般に長く設定されていることを用いたものであり、その
差が大きければ大きいほど効果が絶大となる。

【００７９】［第２の実施形態］第２の実施形態は、第
１の実施形態における操作表示ＣＧＩプログラム１５２
を改良したものであり、所定時間の経過待ちプログラム
の数を減らすことにより，操作端末と被操作装置の双方
において必要となる資源を減らすものである。

【００８０】本実施形態のシステム構成図は、操作表示
ＣＧＩプログラムが本実施形態に特有の操作表示ＣＧＩ
プログラム１６２（図示せず）である以外は図１に示し
た第１の実施形態と同じである。その他のプログラムの
処理は、第１の実施形態と同じであるので、その説明は
省略する。

【００８１】操作表示ＣＧＩプログラム１６２の構成・
動作も基本的には、第１の実施形態の操作表示ＣＧＩプ
ログラム１５２と同じであるので、相違点のみを図５を
適宜読み替えて説明する。

【００８２】操作表示ＣＧＩプログラム１６２も処理順
序カウンタ（図示せず）、図６に示す情報交換テーブル
４０１、タイマ（図示せず）を有し、ＨＴＴＰサーバプ
ログラム１５１によって起動される。パイプライン処理
により、複数起動され、並行動作する場合もある。

【００８３】操作表示ＣＧＩプログラム１６２の処理で
は、タイマが所定時間経過しているか否かを判別するス
テップＳ３４０までの処理は、操作表示ＣＧＩプログラ
ム１５２と同一である。

【００８４】ステップＳ３４０で、所定時間経過してい
ないと判別された場合には、本実施形態に特有な処理ス
テップＳ３４５（図示せず）に進む。

【００８５】持続的コネクションのタイムアウトによる
切断を防ぐには、ＨＴＴＰリクエストのレスポンス待ち
が高々１つあればよい。すなわち、最新のＨＴＴＰリク
エストに対するレスポンスだけを所定時間まで待たせれ
ば十分である。

【００８６】ステップＳ３４５では、再度、処理順序カ
ウンタの値を調べ、この処理順序カウンタのカウント値
と、本操作表示ＣＧＩプログラム１５２が起動される際
にＨＴＴＰサーバプログラム１５１から渡された送信順
序カウンタのカウント値（すなわち、被操作装置１２０
から送られてきた状態情報の中の送信順序カウンタのカ
ウント値）を比較する。その結果、処理順序カウンタの
値の方が「２」以上大きければ、HTTPサーバプログラム
１５１よりも後に起動された操作表示ＣＧＩプログラム
１６２が所定時間経過待ちループに入っていることを意
味するので、この場合は、ステップＳ３５０に進み、Ａ
ＣＫ情報を送信して処理を終了する。

【００８７】一方、処理順序カウンタの値の方が「１」
大きいに過ぎないならば、その後の操作表示ＣＧＩプロ
グラム１６２が所定時間経過待ちループに入っていない
ことを意味するので、この場合は、ステップＳ３４０に
戻り、再び待つ。

【００８８】第２の実施形態によれば、第１の実施形態
の効果に加えて、操作表示ＣＧＩプログラムで比較的長
い待ち状態にあるＨＴＴＰリクエスト／レスポンスの数
が高々１つになることにより、同時に動作する操作表示
ＣＧＩプログラムの数が減り、また、状態通知プログラ
ムにおいてもレスポンス待ちのリクエスト数が減るの
で、操作端末１３０と被操作装置１２０の双方におい
て、必要となるプログラム資源を減少させることが可能
となる。

【００８９】なお、本発明は、上記実施形態に限定され
ることなく、例えば、持続的コネクションを用いてネッ
トワークを介して通信を行うシステムであれば、遠隔操
作システム以外のシステムに適用することも可能であ
る。

【００９０】また、ＨＴＴＰ以外の通信プロトコルを用
いて通信を行うシステムや、ファイアウォール、プロキ
シサーバを利用しないシステムにも適用することができ
る。

【００９１】

【発明の効果】以上説明したように、本発明によれば、
ネットワークに不必要な負荷をかけることなく持続的コ
ネクションを維持することが可能となる。

【００９２】すなわち、リクエストに対するレスポンス
を直ぐには返さず、所定時間経過した後に返すことによ
って、持続的コネクションが切断されるのを防ぐための
本来必要のない状態通知（ダミー通信）の回数を減らす
ことで通信量を減らし、ネットワークに与える負荷を減
らすことが可能となる。

【図面の簡単な説明】

【図１】本発明を適用した遠隔操作システムの概略構成
を示すシステム構成図である。

【図２】図１に示した遠隔操作システムの通信シーケン
ス図である。

【図３】状態通知プログラムの処理を示すフローチャー
トである。

【図４】図３の続きのフローチャートである。

【図５】操作表示ＣＧＩプログラムの処理を示すフロー
チャートである。

【図６】情報交換テーブルの内容例を示す図である。

【図７】操作データ収集プログラムの処理を示すフロー
チャートである。

【図８】操作ＣＧＩプログラムの処理を示すフローチャ
ートである。

【符号の説明】

１００…インターネット １１０…ＬＡＮ １１１…ファイアウォール １１２…プロキシサーバプログラム １２０…被操作装置 １３０…操作端末 １４１…状態通知プログラム １４２…操作データ収集プログラム １４３…制御プログラム １５１…ＨＴＴＰサーバプログラム １５２，１６２…操作表示ＣＧＩプログラム １５３…操作ＣＧＩプログラム １５４…操作表示ＧＵＩプログラム ４０１…情報交換テーブル

フロントページの続き (72)発明者 山川 正 東京都大田区下丸子３丁目30番２号 キヤ ノン株式会社内 Ｆターム(参考） 5B089 GA19 HA06 HA10 HB05 KA17 KB11 KC14 KC29 KF02 KG03 5K030 HA08 HC01 HC14 HD03 HD08 LB01 LB19 5K034 AA07 DD03 EE10 HH01 HH02 LL02

Claims (27)

【特許請求の範囲】
1. 【請求項１】 持続的コネクションを確立してネットワ
   ークを介して通信を行う通信システムにおいて、 所定の要求信号を受信した場合に、所定時間だけ待機し
   た後に受信応答を返す応答制御手段を備えたことを特徴
   とする通信システム。
2. 【請求項２】 前記所定時間は、前記ネットワークや通
   信プロトコルによって規定されるデータ送受信がない期
   間が持続した際の前記持続的コネクションの切断タイム
   アウト時間よりも短く設定されていることを特徴とする
   請求項１に記載の通信システム。
3. 【請求項３】 データ送受信がない期間が所定時間以上
   継続した際に所定のデータ送受信を行って持続的コネク
   ションを維持する維持する維持手段を有することを特徴
   とする請求項１又は２記載の通信システム。
4. 【請求項４】 前記通信システムは、通信プロトコルと
   して、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆ
   ｅｒ Ｐｒｏｔｏｃｏｌ）を使用することを特徴とする
   請求項１〜３の何れかに記載の通信システム。
5. 【請求項５】 前記持続的コネクションとして、前記Ｈ
   ＴＴＰ規定の持続的コネクションを使用することを特徴
   とする請求項４記載の通信システム。
6. 【請求項６】 前記ＨＴＴＰは、該ＨＴＴＰ規定のパイ
   プライン処理を使用することを特徴とする請求項４又は
   ５記載の通信システム。
7. 【請求項７】 前記応答制御手段は、前記パイプライン
   処理により連続して送信されてくる要求信号に対応して
   複数設けられ、該複数の応答制御手段は、並列に動作す
   ることを特徴とする請求項６記載の通信システム。
8. 【請求項８】 前記複数の応答制御手段が並列に動作す
   る際に、所定時間まで待機している応答制御手段の個数
   を制限し、制限個数以上の応答制御手段には直ちに受信
   応答を送信させる制御手段を有することを特徴とする請
   求項７記載の通信システム。
9. 【請求項９】 前記通信システムは、遠隔操作を行う遠
   隔装置装置と、該遠隔操作装置による遠隔操作を受ける
   被操作装置とを有することを特徴とする請求項１〜８の
   何れかに記載の通信システム。
10. 【請求項１０】 前記被操作装置は、ファイアウールを
    介して前記ネットワークに接続されていることを特徴と
    する請求項９記載の通信システム。
11. 【請求項１１】 前記ファイアウールは、プロキシサー
    バ機能を有することを特徴とする請求項１０記載の通信
    システム。
12. 【請求項１２】 前記持続的コネクションは、前記プロ
    キシサーバ機能により予め設定された所定の設定時間に
    基づいて切断されることを特徴とする請求項１〜１１の
    何れかに記載の通信システム。
13. 【請求項１３】 前記応答制御手段は、前記操作装置に
    備えられたことを特徴とする請求項１〜１２の何れかに
    記載の通信システム。
14. 【請求項１４】 持続的コネクションを確立してネット
    ワークを介して通信を行う通信システムにおける通信方
    法であって、 所定の要求信号を受信した場合に、所定時間だけ待機し
    た後に受信応答を返す応答制御工程を備えたことを特徴
    とする通信方法。
15. 【請求項１５】 前記所定時間は、前記ネットワークや
    通信プロトコルによって規定されるデータ送受信がない
    期間が持続した際の前記持続的コネクションの切断タイ
    ムアウト時間よりも短く設定されていることを特徴とす
    る請求項１４記載の通信方法。
16. 【請求項１６】 データ送受信がない期間が所定時間以
    上継続した際に所定のデータ送受信を行って持続的コネ
    クションを維持する維持する維持工程を有することを特
    徴とする請求項１４又は１５記載の通信方法。
17. 【請求項１７】 前記通信システムは、通信プロトコル
    として、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓ
    ｆｅｒ Ｐｒｏｔｏｃｏｌ）を使用することを特徴とす
    る請求項１４〜１６の何れかに記載の通信方法。
18. 【請求項１８】 前記持続的コネクションとして、前記
    ＨＴＴＰ規定の持続的コネクションを使用することを特
    徴とする請求項１７記載の通信方法。
19. 【請求項１９】 前記ＨＴＴＰは、該ＨＴＴＰ規定のパ
    イプライン処理を使用することを特徴とする請求項１７
    又は１８記載の通信方法。
20. 【請求項２０】 前記応答制御工程は、前記パイプライ
    ン処理により連続して送信されてくる要求信号に対応し
    て複数設けられ、該複数の応答制御工程は、並列に動作
    することを特徴とする請求項１９記載の通信方法。
21. 【請求項２１】 前記複数の応答制御工程が並列に動作
    する際に、所定時間まで待機している応答制御工程の個
    数を制限し、制限個数以上の応答制御工程には直ちに受
    信応答を送信させる制御工程を有することを特徴とする
    請求項２０記載の通信方法。
22. 【請求項２２】 前記通信システムは、遠隔操作を行う
    遠隔装置装置と、該遠隔操作装置による遠隔操作を受け
    る被操作装置とを有することを特徴とする請求項１４〜
    ２１の何れかに記載の通信方法。
23. 【請求項２３】 前記被操作装置は、ファイアウールを
    介して前記ネットワークに接続されていることを特徴と
    する請求項２２記載の通信方法。
24. 【請求項２４】 前記ファイアウールは、プロキシサー
    バ機能を有することを特徴とする請求項２３記載の通信
    方法。
25. 【請求項２５】 前記持続的コネクションは、前記プロ
    キシサーバ機能により予め設定された所定の設定時間に
    基づいて切断されることを特徴とする請求項１４〜２４
    の何れかに記載の通信方法。
26. 【請求項２６】 前記応答制御工程は、前記操作装置に
    備えられたことを特徴とする請求項１４〜２５の何れか
    に記載の通信方法。
27. 【請求項２７】 持続的コネクションを確立してネット
    ワークを介して通信を行う通信システムにて実行される
    制御プログラムであって、 所定の要求信号を受信した場合に、所定時間だけ待機し
    た後に受信応答を返す内容を有することを特徴とする制
    御プログラム。