ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
なんだか最近、いろんなサイト上にペーパークラフトの兜を作ってサッカー日本代表を応援しようとか言う広告が出てくるのですが、流行らないものを無理やり流行らせようとしているごり押し感しかしないため非常に不快です。
それはさておき、RTM講習会等でファイアウォールを切れとか強要されますが、多分嫌な人もいるかもしれないので、ファイアウォールを切らなかった場合の動作について説明します。
まず、以下のように2台のマシンを用意してマシン1ではファイアウォールが有効、マシン2ではファイアウォールが無効の場合を考えます。
なお、RTシステムエディタがマシン2で動作している場合は、マシン2側からポート1への接続がブロックされるためコネクタの接続は不可能です。
コネクタを接続するときのシーケンス図が以下のようになっています。
RTシステムエディタからポート1のconnect関数を呼び出して、さらにポート1は内部のnotify_connect関数を呼び出します。さらにポート1からポート2のnotify_connect関数を呼び出すという流れになっています。
この場合はポート1からポート2に接続しにいっているので、問題なく接続できます。
しかし、以下のようにコネクタプロファイルに登録したポートのリストの順番が変わりポート2がポート1のnotify_connect関数を呼び出す場合は、ファイアウォールにブロックされるため接続できません。
RTシステムエディタがポート2のconnect関数を呼び出した場合も、ポート2からポート1のnotify_connect関数がリモート呼び出しできないため接続不可です。
このためファイアウォールを有効にした場合のポートの接続には注意が必要ですが、現状RTシステムエディタの機能としてどちらのポートのconnect関数を呼ぶのか、ポートの登録順をどうするかなどの設定はできないため、自分で接続するためのコードを書くしかありません。
そしてデータ転送時の動作ですが、以下のようにPush型接続で通信する場合、マシン1からマシン2に接続しにいくので、問題なく接続できます。
これがPull型接続の場合にはマシン2からマシン1に接続しにいくのでブロックされます。
マシン2でファイアウォールが有効になっている場合、Push型接続はマシン1からマシン2に接続しにいくのでブロックされます。
Pull型接続の場合はマシン2からマシン1に接続しにいくので、問題なく通信できます。
このため、以下のようにインポート、アウトポートでPush型、Pull型を使い分けることで、ファイアウォールが有効な場合でも理論上は通信ができます。
なぜ理論上はと言ったかというと、現状のOpenRTM-aistの実装の問題によりマシン2からマシン1に接続しにいく場合があるからです。
OpenRTM-aistはポートのプロファイル取得時等にポートのオブジェクトの存在確認を行い、オブジェクトが存在しない場合は切断するという処理を実行しています。
マシン2のRTCでその処理が実行された場合、オブジェクトの存在確認時にマシン1へ接続しにいってしまうためブロックされてしまいます。
ちなみにファイアウォールを有効にした場合でも何故か外部のRTCと接続できたり、ネットワークを切り替えたら通信できなくなる場合がありますが、単純にファイアウォールの設定が原因であることが多いです。このページの手順で確認すると、例えばPythonはプライベートがチェックされていて、パブリックにはチェックが無い場合があります。このためパブリックネットワークに接続した場合はファイアウォールにブロックされてしまいます。
ちなみにサービスポートを使用する場合、マシン2のRTCからマシン1のRTCのサービスは呼び出すことはできないため注意が必要になります。
マシン1、マシン2でファイアウォールが有効の場合は、通常の方法では相互通信はできません。
会津大が開発しているようなメッセージブローカをサーバーに配置する仕組みが必要になります。
ただし、この場合でもRTシステムエディタからの操作、サービスポートの利用はできないため、何かしら新しい仕組みが必要になります。
と言うか、ここまで長々と説明しておいてなんですが、ポート番号指定でRTCを起動してもらってファイアウォールの設定してもらう方が簡単です。
そうした場合に外部からRTCを操作されてしまう可能性があるわけですが、ファイアウォールで特定IPアドレス以外制限するようにして、さらにSSL暗号化を有効にしてもらうぐらいしか対策は無いです。
違う話になりますが、以下のようにマシン1とマシン2が内部ネットワークにある場合は、現状のOpenRTM-aistの仕組みでは通信できないため諦めましょう。
ポートフォワーディングを設定したらできるかもしれませんが、両方のルーターで設定する必要があるためあまり現実的ではないように思います。
どうしてもこの構成で通信したかったら、メッセージブローカを配置したサーバーを作るか、UDPホールパンチングをするデータポートでも作ってもらうしかなさそうです。あるいはVPN接続するというのはOpenRTMでは昔から行われているようですが、それも色々と面倒くさいのであまりやりたくありません。メッセージブローカのサーバーを使う場合は誰かが用意したものを使うという選択肢もありますが、VPNを使う場合は自前で色々と準備しなければならないのであまりお勧めはできません。
ちなみに、片方のマシンが外部からアクセスできる場合は、Pull型通信を駆使することで通信できます。理論上はですが。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
それはさておき、RTM講習会等でファイアウォールを切れとか強要されますが、多分嫌な人もいるかもしれないので、ファイアウォールを切らなかった場合の動作について説明します。
まず、以下のように2台のマシンを用意してマシン1ではファイアウォールが有効、マシン2ではファイアウォールが無効の場合を考えます。
なお、RTシステムエディタがマシン2で動作している場合は、マシン2側からポート1への接続がブロックされるためコネクタの接続は不可能です。
コネクタを接続するときのシーケンス図が以下のようになっています。
RTシステムエディタからポート1のconnect関数を呼び出して、さらにポート1は内部のnotify_connect関数を呼び出します。さらにポート1からポート2のnotify_connect関数を呼び出すという流れになっています。
この場合はポート1からポート2に接続しにいっているので、問題なく接続できます。
しかし、以下のようにコネクタプロファイルに登録したポートのリストの順番が変わりポート2がポート1のnotify_connect関数を呼び出す場合は、ファイアウォールにブロックされるため接続できません。
RTシステムエディタがポート2のconnect関数を呼び出した場合も、ポート2からポート1のnotify_connect関数がリモート呼び出しできないため接続不可です。
このためファイアウォールを有効にした場合のポートの接続には注意が必要ですが、現状RTシステムエディタの機能としてどちらのポートのconnect関数を呼ぶのか、ポートの登録順をどうするかなどの設定はできないため、自分で接続するためのコードを書くしかありません。
そしてデータ転送時の動作ですが、以下のようにPush型接続で通信する場合、マシン1からマシン2に接続しにいくので、問題なく接続できます。
これがPull型接続の場合にはマシン2からマシン1に接続しにいくのでブロックされます。
マシン2でファイアウォールが有効になっている場合、Push型接続はマシン1からマシン2に接続しにいくのでブロックされます。
Pull型接続の場合はマシン2からマシン1に接続しにいくので、問題なく通信できます。
このため、以下のようにインポート、アウトポートでPush型、Pull型を使い分けることで、ファイアウォールが有効な場合でも理論上は通信ができます。
なぜ理論上はと言ったかというと、現状のOpenRTM-aistの実装の問題によりマシン2からマシン1に接続しにいく場合があるからです。
OpenRTM-aistはポートのプロファイル取得時等にポートのオブジェクトの存在確認を行い、オブジェクトが存在しない場合は切断するという処理を実行しています。
マシン2のRTCでその処理が実行された場合、オブジェクトの存在確認時にマシン1へ接続しにいってしまうためブロックされてしまいます。
ちなみにファイアウォールを有効にした場合でも何故か外部のRTCと接続できたり、ネットワークを切り替えたら通信できなくなる場合がありますが、単純にファイアウォールの設定が原因であることが多いです。このページの手順で確認すると、例えばPythonはプライベートがチェックされていて、パブリックにはチェックが無い場合があります。このためパブリックネットワークに接続した場合はファイアウォールにブロックされてしまいます。
ちなみにサービスポートを使用する場合、マシン2のRTCからマシン1のRTCのサービスは呼び出すことはできないため注意が必要になります。
マシン1、マシン2でファイアウォールが有効の場合は、通常の方法では相互通信はできません。
会津大が開発しているようなメッセージブローカをサーバーに配置する仕組みが必要になります。
ただし、この場合でもRTシステムエディタからの操作、サービスポートの利用はできないため、何かしら新しい仕組みが必要になります。
と言うか、ここまで長々と説明しておいてなんですが、ポート番号指定でRTCを起動してもらってファイアウォールの設定してもらう方が簡単です。
そうした場合に外部からRTCを操作されてしまう可能性があるわけですが、ファイアウォールで特定IPアドレス以外制限するようにして、さらにSSL暗号化を有効にしてもらうぐらいしか対策は無いです。
違う話になりますが、以下のようにマシン1とマシン2が内部ネットワークにある場合は、現状のOpenRTM-aistの仕組みでは通信できないため諦めましょう。
ポートフォワーディングを設定したらできるかもしれませんが、両方のルーターで設定する必要があるためあまり現実的ではないように思います。
どうしてもこの構成で通信したかったら、メッセージブローカを配置したサーバーを作るか、UDPホールパンチングをするデータポートでも作ってもらうしかなさそうです。あるいはVPN接続するというのはOpenRTMでは昔から行われているようですが、それも色々と面倒くさいのであまりやりたくありません。メッセージブローカのサーバーを使う場合は誰かが用意したものを使うという選択肢もありますが、VPNを使う場合は自前で色々と準備しなければならないのであまりお勧めはできません。
ちなみに、片方のマシンが外部からアクセスできる場合は、Pull型通信を駆使することで通信できます。理論上はですが。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
この記事にコメントする
