[openrtm-users 01095] Managerのnamingformatの不具合

24 posts / 0 new

Last post

Mon, 2010-02-15 04:53

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01095] Managerのnamingformatの不具合

OpenRTM-aist MLの皆様：
お世話になっております．早大の菅です．

さて，今回は使っている人は少ないかもしれませんが，
Managerのnaming_formatsについてです．

rtc.confに
manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
のように記述するとmanagerのネーミングフォーマットを
変更できるはずですが，
最新の1.0を利用すると，変更したmanagerとともに，
変更前のmanager（これは%h.host_cxt/%n.mgrと同じ）
もサーバーに登録されてしまいます．

（ちなみにinitの引数に-dを付けないと，
managerは隠ぺいされていて
しまいにはterminateされてしまうのですね）

原因究明中ですが，ご報告まで．
お心当たりがございましたらお教えください．

ではでは

Language Undefined

Mon, 2010-02-15 09:37

Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01096] Managerのnamingformatの不具合

菅様

産総研の中島です。

外してたらすいません。
0.4.2の時に同様の現象（C++版でしか確認していませんが。）と
思われるものがありましたので、参考までにコメントします。
（まだ、1.0を使用していないので憶測ですが。）

その時は、
rtc.confで編集しても、cppソース内の以下の部分が
あると、RTCを起動して、RtSystemEditorのNameServiceViewでは、
２つ表示されてしまう症状があったと記憶しています。

ソース内で以下のように「"naming.formats"」コメントアウトすると、
デフォルトの方は消えて、「rtc.conf」で指定した方のみが表示された
と記憶しています。
（RtcBuilderで作成すると、自動的に入る部分でした。rtc-templateとかだと、
入らないみたいですが。）

====[cppファイルの先頭の方の一部抜粋]================
static const char* test_spec[] =
{
　〜〜〜中略〜〜〜
// System Configuration
"corba.name_servers", "localhost:2809",
// "naming.formats", "%n.rtc", #<--ココ
"logger.log_level", "PARANOID",
""
};
========================

以上、報告まで。

> OpenRTM-aist MLの皆様：
> お世話になっております．早大の菅です．
>
> さて，今回は使っている人は少ないかもしれませんが，
> Managerのnaming_formatsについてです．
>
>
> rtc.confに
> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
> のように記述するとmanagerのネーミングフォーマットを
> 変更できるはずですが，
> 最新の1.0を利用すると，変更したmanagerとともに，
> 変更前のmanager（これは%h.host_cxt/%n.mgrと同じ）
> もサーバーに登録されてしまいます．
>
> （ちなみにinitの引数に-dを付けないと，
> managerは隠ぺいされていて
> しまいにはterminateされてしまうのですね）
>
>
> 原因究明中ですが，ご報告まで．
> お心当たりがございましたらお教えください．
>
>
> ではでは
>

Mon, 2010-02-15 10:10

(Reply to #2) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01097] Managerのnamingformatの不具合

産総研の中島様，MLの皆様：
お世話になっております．早大の菅です．

> 外してたらすいません。
> 0.4.2の時に同様の現象（C++版でしか確認していませんが。）と
> 思われるものがありましたので、参考までにコメントします。
> （まだ、1.0を使用していないので憶測ですが。）
>
> その時は、
> rtc.confで編集しても、cppソース内の以下の部分が
> あると、RTCを起動して、RtSystemEditorのNameServiceViewでは、
> ２つ表示されてしまう症状があったと記憶しています。

なるほど．
実はMyModuleInitをコメントアウトしていても，
つまりManager単体で実行しても，
同じ現象が出ることを確認しています．

その場合，main関数のみで，以下のコードです．

%%コードここから
#include
#include

int main (int argc, char** argv)
{
RTC::Manager* manager;
manager = RTC::Manager::init(argc, argv);

manager->activateManager();

manager->runManager();

return 0;
}
%%ここまで

rtcdと同じコードですね．

(2010/02/15 9:37), Yusuke Nakajima wrote:
> 菅様
>
> 産総研の中島です。
>
> 外してたらすいません。
> 0.4.2の時に同様の現象（C++版でしか確認していませんが。）と
> 思われるものがありましたので、参考までにコメントします。
> （まだ、1.0を使用していないので憶測ですが。）
>
> その時は、
> rtc.confで編集しても、cppソース内の以下の部分が
> あると、RTCを起動して、RtSystemEditorのNameServiceViewでは、
> ２つ表示されてしまう症状があったと記憶しています。
>
> ソース内で以下のように「"naming.formats"」コメントアウトすると、
> デフォルトの方は消えて、「rtc.conf」で指定した方のみが表示された
> と記憶しています。
> （RtcBuilderで作成すると、自動的に入る部分でした。rtc-templateとかだと、
> 入らないみたいですが。）
>
> ====[cppファイルの先頭の方の一部抜粋]================
> static const char* test_spec[] =
> {
> 　～～～中略～～～
> // System Configuration
> "corba.name_servers", "localhost:2809",
> // "naming.formats", "%n.rtc", #<--ココ
> "logger.log_level", "PARANOID",
> ""
> };
> ========================
>
> 以上、報告まで。
>
>
>> OpenRTM-aist MLの皆様：
>> お世話になっております．早大の菅です．
>>
>> さて，今回は使っている人は少ないかもしれませんが，
>> Managerのnaming_formatsについてです．
>>
>>
>> rtc.confに
>> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
>> のように記述するとmanagerのネーミングフォーマットを
>> 変更できるはずですが，
>> 最新の1.0を利用すると，変更したmanagerとともに，
>> 変更前のmanager（これは%h.host_cxt/%n.mgrと同じ）
>> もサーバーに登録されてしまいます．
>>
>> （ちなみにinitの引数に-dを付けないと，
>> managerは隠ぺいされていて
>> しまいにはterminateされてしまうのですね）
>>
>>
>> 原因究明中ですが，ご報告まで．
>> お心当たりがございましたらお教えください．
>>
>>
>> ではでは
>>

Mon, 2010-02-15 10:15

Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01098] Managerのnamingformatの不具合

OpenRTM-aist MLの皆様：
早大の菅です．
毎度お騒がせしております．

さて，今回の問題ですが，追加報告です．
rtcdを使って現象をいくつか試していますが，
以下の操作で再現されることがわかりました．

一言で表現すると，ゾンビーの復活です．

初回のrtcdの実行ではnaming_formatsを指定しない，
以下のrtc.confで実行．

corba.nameservers: localhost
naming.formats: %h.host_cxt/%n.rtc
logger.enable: NO
logger.log_level: PARANOID
manager.modules.load_path: ../examples/C++/, ../components/

その後，rtcdを無理やり停止して，ゾンビーを残す．

次にrtc.confを加工する

corba.nameservers: localhost
naming.formats: %h.host_cxt/%n.rtc
logger.enable: NO
logger.log_level: PARANOID
manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
manager.modules.load_path: ../examples/C++/, ../components/

5行目を追加．そして実行すると，
ゾンビーだったmanager.mgrが復活する．
こちらからcreateを呼び出しても可能になってしまいます．

初回の起動でゾンビーがなければ意図通りに動作します．
また，逆の順序で実行しても同様の現象が起こります．

こちらの環境は

Win Vista 32 bit
omniORB4.1.4（OpenRTM同梱版）
OpenRTM-aist 1.0RELEASE
Python 2.6

です．

ではでは
(2010/02/15 4:53), Yuki Suga wrote:
> OpenRTM-aist MLの皆様：
> お世話になっております．早大の菅です．
>
> さて，今回は使っている人は少ないかもしれませんが，
> Managerのnaming_formatsについてです．
>
>
> rtc.confに
> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
> のように記述するとmanagerのネーミングフォーマットを
> 変更できるはずですが，
> 最新の1.0を利用すると，変更したmanagerとともに，
> 変更前のmanager（これは%h.host_cxt/%n.mgrと同じ）
> もサーバーに登録されてしまいます．
>
> （ちなみにinitの引数に-dを付けないと，
> managerは隠ぺいされていて
> しまいにはterminateされてしまうのですね）
>
>
> 原因究明中ですが，ご報告まで．
> お心当たりがございましたらお教えください．
>
>
> ではでは
>

Mon, 2010-02-15 12:43

(Reply to #4) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01099] Managerのnamingformatの不具合

菅様、皆さま

安藤です

rtcdについて、まだドキュメントを書いていないので、
いろいろ混乱させてしまいすみません。
ドキュメントはもう少々お待ちください。

今回の件ですが、ネームサーバ上に残ったマネージャーのゾンビリファレンスが、
そのごrtc.confでマネージャの登録名を変えたにもかかわらず復活してしまう

ということでよろしいでしょうか。

これは、簡潔に言いますと、マネージャーを INS 化したためで、
対処方法としては、ゾンビ化させないで、マネージャはshutdownコマンドで
終了させてください、ということになります。

以下、長文すみません。

> さて，今回の問題ですが，追加報告です．
> rtcdを使って現象をいくつか試していますが，
> 以下の操作で再現されることがわかりました．
>
> 一言で表現すると，ゾンビーの復活です．
>
> 初回のrtcdの実行ではnaming_formatsを指定しない，
> 以下のrtc.confで実行．
>
> corba.nameservers: localhost
> naming.formats: %h.host_cxt/%n.rtc
> logger.enable: NO
> logger.log_level: PARANOID
> manager.modules.load_path: ../examples/C++/, ../components/
>
> その後，rtcdを無理やり停止して，ゾンビーを残す．
>
> 次にrtc.confを加工する
>
> corba.nameservers: localhost
> naming.formats: %h.host_cxt/%n.rtc
> logger.enable: NO
> logger.log_level: PARANOID
> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
> manager.modules.load_path: ../examples/C++/, ../components/
>
> 5行目を追加．そして実行すると，
> ゾンビーだったmanager.mgrが復活する．
> こちらからcreateを呼び出しても可能になってしまいます．
>
> 初回の起動でゾンビーがなければ意図通りに動作します．
> また，逆の順序で実行しても同様の現象が起こります．

詳しく解説しますと、

CORBAオブジェクトは、特に何もしていしなければ、生成されるたびに適当なKey (IDのようなもの)
を持ったオブジェクトとして生成され、ネームサーバに登録されるリファレンスも、
たとえ名前が同じであっても、生成されるたびに異なるKeyのオブジェクトとして
登録されます。

たとえば、ConsoleIn コンポーネントを2回生成したとします。
1回目の生成では、以下のような参照がネームサーバに登録されます。

名前： ConsoleIn0.rtc 参照：(Key: 0x7183618368, IPアドレス： 192.168.1.10, ポート番号：3444)

このプロセスを落として、もう一度起動します。次は、以下のような参照が登録されます。

名前： ConsoleIn0.rtc 参照：(Key: 0x8297427492, IPアドレス： 192.168.1.10, ポート番号：3653)

通常、複数回起動しても同じなのはIPアドレスと名前くらいで、Keyやポート番号はORBやOS
の気分によって変わってしまいます(笑

しかし、rtcdを-dオプション付きで起動すると、マネージャーはマスターマネージャ（後ほど解説します）となり、
のKeyとポート番号が固定されます。(デフォルトでは Key は manager, ポート番号は 2810 になります。)

つまり、マネージャーの名前は、以下のような参照としてネームサーバに登録されます。

名前： hsotname.host_cxt/manager.mgr 参照：(Key： manager, IPアドレス：
192.168.1.10, ポート番号：2810) ・・・ (1)

ここで、マネージャーを強制終了すると、この名前の登録を掃除しないで終了するので、
ネームサーバ上にこの名前がそのまま残ってしまいます。
次に、rtc.confでmanager.naming_formats を変更すると、

名前： hostname.host_cxt/ysuga_net.app_cxt/manager.mgr 参照：(Key： manager,
IPアドレス： 192.168.1.10, ポート番号：2810) ・・・ (2)

として、マネージャが登録されます。

ここで、(1)と(2)の参照（ID、IP、ポート）を比べてみると、まったく同じになっています。
したがって、(1)の参照にアクセスしても、(2)と同じオブジェクトにアクセスすることになります。
そういうわけで、ゾンビ化したマネージャ(1)も、復活してしまう、というわけです。

なお、マネージャをこのようにIDやポート番号を固定したわけは、ネームサーバなして
マネージャやコンポーネントにアクセスするためです。この辺は、以前松坂さんからご意見のあった、
ネームサーバがシステムの single point of failure になることを避ける手段として
ネームサーバに依存しないでシステムを構築する方法を提供したかったためです。

こうすることでマネージャは corbaloc:iiop:hostname:port/manager という URL で常に
アクセスできるようになります。ここでポート番号は固定で 2810 としているので、
ホスト名さえ分かれば、そのノードのマスタマネージャにアクセスできることになります。

ちなみに、こういうオブジェクトの名前付けを INS (Interoperable Naming Service) といいます。

以下は、log出力の例ですが、マネージャのIOR(オブジェクト参照)の情報は、

Feb 15 10:35:40 DEBUG: ManagerServant: Manager's IOR information:
IOR information
Type ID: "IDL:RTM/Manager:1.0"
Profiles:
1. IIOP 1.2 192.168.100.2 2810
Object Key: "manager" = 0x6d616e61676572 (7 bytes)
TAG_ORB_TYPE omniORB
TAG_CODE_SETS char native code set: ISO-8859-1
char conversion code set: UTF-8
wchar native code set: UTF-16
wchar conversion code set: UTF-16

このように、Object Key が "manager" という人間が読める形式になっているのに対し、
以下は ConsoleIn をネームサーバに登録する際のIORなのですが、

IOR information
Type ID: "IDL:openrtm.aist.go.jp/OpenRTM/DataFlowComponent:1.0"
Profiles:
1. IIOP 1.2 192.168.100.2 2810
POA(root) Object Key: "...." = 0x00000000 (4 bytes)
Object Key: "...xK........." = 0xfe94ba784b000015080000000000 (14 bytes)
TAG_ORB_TYPE omniORB
TAG_CODE_SETS char native code set: ISO-8859-1
char conversion code set: UTF-8
wchar native code set: UTF-16
wchar conversion code set: UTF-16

Object Key が 0xfe94ba784b000015080000000000 というORB (というかPOA) が
適当に付けた名前になっています。

ついでですので、マネージャの使い方についても少し説明します。

マネージャにはマスタとスレーブがあります。

・マスタマネージャ：
　　原則1ノードにつき1つだけ存在する。
　　アプリケーション、ノードの外部などからは、マスターマネージャに対して
　　コンポーネントの生成を依頼する。
　　つまり、原則として、このマネージャ自身はコンポーネントを生成・管理しない。
　　実際のコンポーネントの生成は、マスタがスレーブマネージャに依頼する。

・スレーブマネージャ：
　　1ノードに複数存在できる。0個以上のマスターに所属することができる。
　　rtcdを-dなしで起動した場合、マスターがすでに起動していればその配下に入る。
　　コンポーネントはスレーブマネージャ上で生成・管理される。
　　原則、コンポーネントが存在しないスレーブマネージャは存在しない（自動でシャットダウンされる）。
　　-> 菅さんがご指摘されたように、-d オプションなしのrtcdが自動で終了するのはこのためです。
　　マスターマネージャからは、スレーブはポート番号で区別される。
　　つまり、同一ポート番号のスレーブマネージャは、同一のプロセス（逆もしかり）である。

コンポーネント生成の流れは、以下のようになります。

1) RTCが起動される可能性のあるノード上では、rtcd は -d オプション付きで起動されているものとします。
＃Linuxではれば、/etc/init.d 以下の起動スクリプトなどで起動されているイメージ。

2) 何らかのツール、コマンド、アプリケーションが、あるノードに対してコンポーネントを作成したい場合
　まず、そのノードのマスタマネージャのオブジェクトリファレンスを取得します。
　それは、ネームサーバからでもいいですし、corbaloc:iiop:hostname:2810/manager という URL を
ORB::string_to_object() 関数を使ってダイレクトにアクセスしてもかまいません。

3) 何らかのツール、コマンド、アプリケーションが、あるノード上で、コンポーネントを起動する場合、
　そのノードのマスターマネージャに対して create_component() をコールします。
　mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234")

4) manager=localhost:2811 はローカルホスト上の 2811版ポート上で ConsoleIn という
　コンポーネントを起動しなさい、という意味なので、マスターマネージャは、スレーブマネージャを
　2811ポート上で起動し、そのマネージャに対して、create_component("ConsoleIn?instance_name=ConsoleIn1234")
をコールします。

5) スレーブマネージャは、ポート2811上で起動し、ConsoleInを一つ生成します。
　このとき、インスタンス名はConsoleIn1234 に指定されているのでインスタンス名はこの名前になり、
　ネームサーバ上に登録される名前も、この名前になります。

6) さらに、同じプロセス上で、ConsoleIn を起動したければ、
mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1235")
とをマスタマネージャに対してコールすればよく、異なるプロセスで起動したい場合は、
mgr->create_component("ConsoleIn?manager=localhost:2812&instance_name=ConsoleIn1235")
等とすれば、別のプロセス上でConsoleInが起動します。

7) なお、そのノード上で起動しているコンポーネントの参照は、マスターマネージャから、
mgr->get_components() によって取得できます。
　スレーブ上で起動しているすべてのコンポーネントの参照をマスターが収集して返しています。

一応、1.0-RELEASEのrtcdはこのような使い方を意図して実装されています。
まだ、ツールの方でも対応しきれていないので、この使い方が実際利用できるのには
少々時間がかかると思いますが、RTSystemEditorやrtcshellなどで、
簡単にできるようにしていきたいと思います。
＃rtcshellについては、ジェフさんよろしく。

あと、Windows上で起動したrtcdに、RTSystemEditorのmanager viewからアクセスすると、
非常に重いのですが、これはDLLからRTCのプロファイルを取得する操作がWindows
上ではなぜだか非常に遅いために発生しています。（Linuxだと一瞬で終わるのですが。。。）
また、OpenCVをインストールしていない場合、RTCのプロファイルを取得する過程で、
USBcamera*コンポーネントをアクセスした段階で、DLLのエラーダイアログが出てしまい
アクセスがさらに遅くなってしまいます。
OpenCVをインストールするか、USBCameda*.DLLを削除するかすると改善します。

Mon, 2010-02-15 13:23

(Reply to #5) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01101] Managerのnamingformatの不具合

安藤様、皆様：

産総研の原です。
下記のようにネームサーバーのポート番号が固定されているということですが、
2810番のように49151番より下の番号は、勝手につかってはいけません。
IANAというところで管理しています。
また、2810は、
# Ted McFadden
netsteward 2810/tcp Active Net Steward
netsteward 2810/udp Active Net Steward

のようにアプリケーションの登録がなされていますので、変更をお願いいたします。

(2010/02/15 12:43), Ando Noriaki wrote:
> 菅様、皆さま
>
> 安藤です
>
> rtcdについて、まだドキュメントを書いていないので、
> いろいろ混乱させてしまいすみません。
> ドキュメントはもう少々お待ちください。
>
>
> 今回の件ですが、ネームサーバ上に残ったマネージャーのゾンビリファレンスが、
> そのごrtc.confでマネージャの登録名を変えたにもかかわらず復活してしまう
>
> ということでよろしいでしょうか。
>
> これは、簡潔に言いますと、マネージャーを INS 化したためで、
> 対処方法としては、ゾンビ化させないで、マネージャはshutdownコマンドで
> 終了させてください、ということになります。
>
> 以下、長文すみません。
>
>
>> さて，今回の問題ですが，追加報告です．
>> rtcdを使って現象をいくつか試していますが，
>> 以下の操作で再現されることがわかりました．
>>
>> 一言で表現すると，ゾンビーの復活です．
>>
>> 初回のrtcdの実行ではnaming_formatsを指定しない，
>> 以下のrtc.confで実行．
>>
>> corba.nameservers: localhost
>> naming.formats: %h.host_cxt/%n.rtc
>> logger.enable: NO
>> logger.log_level: PARANOID
>> manager.modules.load_path: ../examples/C++/, ../components/
>>
>> その後，rtcdを無理やり停止して，ゾンビーを残す．
>>
>> 次にrtc.confを加工する
>>
>> corba.nameservers: localhost
>> naming.formats: %h.host_cxt/%n.rtc
>> logger.enable: NO
>> logger.log_level: PARANOID
>> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
>> manager.modules.load_path: ../examples/C++/, ../components/
>>
>> 5行目を追加．そして実行すると，
>> ゾンビーだったmanager.mgrが復活する．
>> こちらからcreateを呼び出しても可能になってしまいます．
>>
>> 初回の起動でゾンビーがなければ意図通りに動作します．
>> また，逆の順序で実行しても同様の現象が起こります．
>
>
> 詳しく解説しますと、
>
> CORBAオブジェクトは、特に何もしていしなければ、生成されるたびに適当なKey (IDのようなもの)
> を持ったオブジェクトとして生成され、ネームサーバに登録されるリファレンスも、
> たとえ名前が同じであっても、生成されるたびに異なるKeyのオブジェクトとして
> 登録されます。
>
> たとえば、ConsoleIn コンポーネントを2回生成したとします。
> 1回目の生成では、以下のような参照がネームサーバに登録されます。
>
> 名前： ConsoleIn0.rtc 参照：(Key: 0x7183618368, IPアドレス： 192.168.1.10, ポート番号：3444)
>
> このプロセスを落として、もう一度起動します。次は、以下のような参照が登録されます。
>
> 名前： ConsoleIn0.rtc 参照：(Key: 0x8297427492, IPアドレス： 192.168.1.10, ポート番号：3653)
>
> 通常、複数回起動しても同じなのはIPアドレスと名前くらいで、Keyやポート番号はORBやOS
> の気分によって変わってしまいます(笑
>
> しかし、rtcdを-dオプション付きで起動すると、マネージャーはマスターマネージャ（後ほど解説します）となり、
> のKeyとポート番号が固定されます。(デフォルトでは Key は manager, ポート番号は 2810 になります。)
>
> つまり、マネージャーの名前は、以下のような参照としてネームサーバに登録されます。
>
> 名前： hsotname.host_cxt/manager.mgr 参照：(Key： manager, IPアドレス：
> 192.168.1.10, ポート番号：2810) ・・・ (1)
>
> ここで、マネージャーを強制終了すると、この名前の登録を掃除しないで終了するので、
> ネームサーバ上にこの名前がそのまま残ってしまいます。
> 次に、rtc.confでmanager.naming_formats を変更すると、
>
> 名前： hostname.host_cxt/ysuga_net.app_cxt/manager.mgr 参照：(Key： manager,
> IPアドレス： 192.168.1.10, ポート番号：2810) ・・・ (2)
>
> として、マネージャが登録されます。
>
> ここで、(1)と(2)の参照（ID、IP、ポート）を比べてみると、まったく同じになっています。
> したがって、(1)の参照にアクセスしても、(2)と同じオブジェクトにアクセスすることになります。
> そういうわけで、ゾンビ化したマネージャ(1)も、復活してしまう、というわけです。
>
>
>
> なお、マネージャをこのようにIDやポート番号を固定したわけは、ネームサーバなして
> マネージャやコンポーネントにアクセスするためです。この辺は、以前松坂さんからご意見のあった、
> ネームサーバがシステムの single point of failure になることを避ける手段として
> ネームサーバに依存しないでシステムを構築する方法を提供したかったためです。
>
> こうすることでマネージャは corbaloc:iiop:hostname:port/manager という URL で常に
> アクセスできるようになります。ここでポート番号は固定で 2810 としているので、
> ホスト名さえ分かれば、そのノードのマスタマネージャにアクセスできることになります。
>
> ちなみに、こういうオブジェクトの名前付けを INS (Interoperable Naming Service) といいます。
>
> 以下は、log出力の例ですが、マネージャのIOR(オブジェクト参照)の情報は、
>
> Feb 15 10:35:40 DEBUG: ManagerServant: Manager's IOR information:
> IOR information
> Type ID: "IDL:RTM/Manager:1.0"
> Profiles:
> 1. IIOP 1.2 192.168.100.2 2810
> Object Key: "manager" = 0x6d616e61676572 (7 bytes)
> TAG_ORB_TYPE omniORB
> TAG_CODE_SETS char native code set: ISO-8859-1
> char conversion code set: UTF-8
> wchar native code set: UTF-16
> wchar conversion code set: UTF-16
>
> このように、Object Key が "manager" という人間が読める形式になっているのに対し、
> 以下は ConsoleIn をネームサーバに登録する際のIORなのですが、
>
> IOR information
> Type ID: "IDL:openrtm.aist.go.jp/OpenRTM/DataFlowComponent:1.0"
> Profiles:
> 1. IIOP 1.2 192.168.100.2 2810
> POA(root) Object Key: "...." = 0x00000000 (4 bytes)
> Object Key: "...xK........." = 0xfe94ba784b000015080000000000 (14 bytes)
> TAG_ORB_TYPE omniORB
> TAG_CODE_SETS char native code set: ISO-8859-1
> char conversion code set: UTF-8
> wchar native code set: UTF-16
> wchar conversion code set: UTF-16
>
> Object Key が 0xfe94ba784b000015080000000000 というORB (というかPOA) が
> 適当に付けた名前になっています。
>
>
> ついでですので、マネージャの使い方についても少し説明します。
>
> マネージャにはマスタとスレーブがあります。
>
> ・マスタマネージャ：
> 　　原則1ノードにつき1つだけ存在する。
> 　　アプリケーション、ノードの外部などからは、マスターマネージャに対して
> 　　コンポーネントの生成を依頼する。
> 　　つまり、原則として、このマネージャ自身はコンポーネントを生成・管理しない。
> 　　実際のコンポーネントの生成は、マスタがスレーブマネージャに依頼する。
>
> ・スレーブマネージャ：
> 　　1ノードに複数存在できる。0個以上のマスターに所属することができる。
> 　　rtcdを-dなしで起動した場合、マスターがすでに起動していればその配下に入る。
> 　　コンポーネントはスレーブマネージャ上で生成・管理される。
> 　　原則、コンポーネントが存在しないスレーブマネージャは存在しない（自動でシャットダウンされる）。
> 　　-> 菅さんがご指摘されたように、-d オプションなしのrtcdが自動で終了するのはこのためです。
> 　　マスターマネージャからは、スレーブはポート番号で区別される。
> 　　つまり、同一ポート番号のスレーブマネージャは、同一のプロセス（逆もしかり）である。
>
> コンポーネント生成の流れは、以下のようになります。
>
> 1) RTCが起動される可能性のあるノード上では、rtcd は -d オプション付きで起動されているものとします。
> ＃Linuxではれば、/etc/init.d 以下の起動スクリプトなどで起動されているイメージ。
>
> 2) 何らかのツール、コマンド、アプリケーションが、あるノードに対してコンポーネントを作成したい場合
> 　まず、そのノードのマスタマネージャのオブジェクトリファレンスを取得します。
> 　それは、ネームサーバからでもいいですし、corbaloc:iiop:hostname:2810/manager という URL を
> ORB::string_to_object() 関数を使ってダイレクトにアクセスしてもかまいません。
>
> 3) 何らかのツール、コマンド、アプリケーションが、あるノード上で、コンポーネントを起動する場合、
> 　そのノードのマスターマネージャに対して create_component() をコールします。
> 　mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234")
>
> 4) manager=localhost:2811 はローカルホスト上の 2811版ポート上で ConsoleIn という
> 　コンポーネントを起動しなさい、という意味なので、マスターマネージャは、スレーブマネージャを
> 　2811ポート上で起動し、そのマネージャに対して、create_component("ConsoleIn?instance_name=ConsoleIn1234")
> をコールします。
>
> 5) スレーブマネージャは、ポート2811上で起動し、ConsoleInを一つ生成します。
> 　このとき、インスタンス名はConsoleIn1234 に指定されているのでインスタンス名はこの名前になり、
> 　ネームサーバ上に登録される名前も、この名前になります。
>
> 6) さらに、同じプロセス上で、ConsoleIn を起動したければ、
> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1235")
> とをマスタマネージャに対してコールすればよく、異なるプロセスで起動したい場合は、
> mgr->create_component("ConsoleIn?manager=localhost:2812&instance_name=ConsoleIn1235")
> 等とすれば、別のプロセス上でConsoleInが起動します。
>
> 7) なお、そのノード上で起動しているコンポーネントの参照は、マスターマネージャから、
> mgr->get_components() によって取得できます。
> 　スレーブ上で起動しているすべてのコンポーネントの参照をマスターが収集して返しています。
>
>
> 一応、1.0-RELEASEのrtcdはこのような使い方を意図して実装されています。
> まだ、ツールの方でも対応しきれていないので、この使い方が実際利用できるのには
> 少々時間がかかると思いますが、RTSystemEditorやrtcshellなどで、
> 簡単にできるようにしていきたいと思います。
> ＃rtcshellについては、ジェフさんよろしく。
>
> あと、Windows上で起動したrtcdに、RTSystemEditorのmanager viewからアクセスすると、
> 非常に重いのですが、これはDLLからRTCのプロファイルを取得する操作がWindows
> 上ではなぜだか非常に遅いために発生しています。（Linuxだと一瞬で終わるのですが。。。）
> また、OpenCVをインストールしていない場合、RTCのプロファイルを取得する過程で、
> USBcamera*コンポーネントをアクセスした段階で、DLLのエラーダイアログが出てしまい
> アクセスがさらに遅くなってしまいます。
> OpenCVをインストールするか、USBCameda*.DLLを削除するかすると改善します。
>

Mon, 2010-02-15 14:27

(Reply to #6) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01102] Managerのnamingformatの不具合

原様

安藤です

固定というのは、デフォルトで2810番という意味で、
変更したい場合は、rtc.conf で
corba.master_manager: localhost:49152
のように指定してください。

ちなみに、1024〜49151 は well known ポートではないので、
勝手に使ってはいけない、というほどの強制力はないですよね。
OpenRTMがすごく広まったら、ちゃんと登録しないとだめかもしれませんが（笑

2010年2月15日13:23 Isao Hara :
> 安藤様、皆様：
>
> 産総研の原です。
> 下記のようにネームサーバーのポート番号が固定されているということですが、
> 2810番のように49151番より下の番号は、勝手につかってはいけません。
> IANAというところで管理しています。
> また、2810は、
> # Ted McFadden
> netsteward 2810/tcp Active Net Steward
> netsteward 2810/udp Active Net Steward
>
> のようにアプリケーションの登録がなされていますので、変更をお願いいたします。
>
> (2010/02/15 12:43), Ando Noriaki wrote:
>> 菅様、皆さま
>>
>> 安藤です
>>
>> rtcdについて、まだドキュメントを書いていないので、
>> いろいろ混乱させてしまいすみません。
>> ドキュメントはもう少々お待ちください。
>>
>>
>> 今回の件ですが、ネームサーバ上に残ったマネージャーのゾンビリファレンスが、
>> そのごrtc.confでマネージャの登録名を変えたにもかかわらず復活してしまう
>>
>> ということでよろしいでしょうか。
>>
>> これは、簡潔に言いますと、マネージャーを INS 化したためで、
>> 対処方法としては、ゾンビ化させないで、マネージャはshutdownコマンドで
>> 終了させてください、ということになります。
>>
>> 以下、長文すみません。
>>
>>
>>> さて，今回の問題ですが，追加報告です．
>>> rtcdを使って現象をいくつか試していますが，
>>> 以下の操作で再現されることがわかりました．
>>>
>>> 一言で表現すると，ゾンビーの復活です．
>>>
>>> 初回のrtcdの実行ではnaming_formatsを指定しない，
>>> 以下のrtc.confで実行．
>>>
>>> corba.nameservers: localhost
>>> naming.formats: %h.host_cxt/%n.rtc
>>> logger.enable: NO
>>> logger.log_level: PARANOID
>>> manager.modules.load_path: ../examples/C++/, ../components/
>>>
>>> その後，rtcdを無理やり停止して，ゾンビーを残す．
>>>
>>> 次にrtc.confを加工する
>>>
>>> corba.nameservers: localhost
>>> naming.formats: %h.host_cxt/%n.rtc
>>> logger.enable: NO
>>> logger.log_level: PARANOID
>>> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
>>> manager.modules.load_path: ../examples/C++/, ../components/
>>>
>>> 5行目を追加．そして実行すると，
>>> ゾンビーだったmanager.mgrが復活する．
>>> こちらからcreateを呼び出しても可能になってしまいます．
>>>
>>> 初回の起動でゾンビーがなければ意図通りに動作します．
>>> また，逆の順序で実行しても同様の現象が起こります．
>>
>>
>> 詳しく解説しますと、
>>
>> CORBAオブジェクトは、特に何もしていしなければ、生成されるたびに適当なKey (IDのようなもの)
>> を持ったオブジェクトとして生成され、ネームサーバに登録されるリファレンスも、
>> たとえ名前が同じであっても、生成されるたびに異なるKeyのオブジェクトとして
>> 登録されます。
>>
>> たとえば、ConsoleIn コンポーネントを2回生成したとします。
>> 1回目の生成では、以下のような参照がネームサーバに登録されます。
>>
>> 名前： ConsoleIn0.rtc 参照：(Key: 0x7183618368, IPアドレス： 192.168.1.10, ポート番号：3444)
>>
>> このプロセスを落として、もう一度起動します。次は、以下のような参照が登録されます。
>>
>> 名前： ConsoleIn0.rtc 参照：(Key: 0x8297427492, IPアドレス： 192.168.1.10, ポート番号：3653)
>>
>> 通常、複数回起動しても同じなのはIPアドレスと名前くらいで、Keyやポート番号はORBやOS
>> の気分によって変わってしまいます(笑
>>
>> しかし、rtcdを-dオプション付きで起動すると、マネージャーはマスターマネージャ（後ほど解説します）となり、
>> のKeyとポート番号が固定されます。(デフォルトでは Key は manager, ポート番号は 2810 になります。)
>>
>> つまり、マネージャーの名前は、以下のような参照としてネームサーバに登録されます。
>>
>> 名前： hsotname.host_cxt/manager.mgr 参照：(Key： manager, IPアドレス：
>> 192.168.1.10, ポート番号：2810) ・・・ (1)
>>
>> ここで、マネージャーを強制終了すると、この名前の登録を掃除しないで終了するので、
>> ネームサーバ上にこの名前がそのまま残ってしまいます。
>> 次に、rtc.confでmanager.naming_formats を変更すると、
>>
>> 名前： hostname.host_cxt/ysuga_net.app_cxt/manager.mgr 参照：(Key： manager,
>> IPアドレス： 192.168.1.10, ポート番号：2810) ・・・ (2)
>>
>> として、マネージャが登録されます。
>>
>> ここで、(1)と(2)の参照（ID、IP、ポート）を比べてみると、まったく同じになっています。
>> したがって、(1)の参照にアクセスしても、(2)と同じオブジェクトにアクセスすることになります。
>> そういうわけで、ゾンビ化したマネージャ(1)も、復活してしまう、というわけです。
>>
>>
>>
>> なお、マネージャをこのようにIDやポート番号を固定したわけは、ネームサーバなして
>> マネージャやコンポーネントにアクセスするためです。この辺は、以前松坂さんからご意見のあった、
>> ネームサーバがシステムの single point of failure になることを避ける手段として
>> ネームサーバに依存しないでシステムを構築する方法を提供したかったためです。
>>
>> こうすることでマネージャは corbaloc:iiop:hostname:port/manager という URL で常に
>> アクセスできるようになります。ここでポート番号は固定で 2810 としているので、
>> ホスト名さえ分かれば、そのノードのマスタマネージャにアクセスできることになります。
>>
>> ちなみに、こういうオブジェクトの名前付けを INS (Interoperable Naming Service) といいます。
>>
>> 以下は、log出力の例ですが、マネージャのIOR(オブジェクト参照)の情報は、
>>
>> Feb 15 10:35:40 DEBUG: ManagerServant: Manager's IOR information:
>> IOR information
>> Type ID: "IDL:RTM/Manager:1.0"
>> Profiles:
>> 1. IIOP 1.2 192.168.100.2 2810
>> Object Key: "manager" = 0x6d616e61676572 (7 bytes)
>> TAG_ORB_TYPE omniORB
>> TAG_CODE_SETS char native code set: ISO-8859-1
>> char conversion code set: UTF-8
>> wchar native code set: UTF-16
>> wchar conversion code set: UTF-16
>>
>> このように、Object Key が "manager" という人間が読める形式になっているのに対し、
>> 以下は ConsoleIn をネームサーバに登録する際のIORなのですが、
>>
>> IOR information
>> Type ID: "IDL:openrtm.aist.go.jp/OpenRTM/DataFlowComponent:1.0"
>> Profiles:
>> 1. IIOP 1.2 192.168.100.2 2810
>> POA(root) Object Key: "...." = 0x00000000 (4 bytes)
>> Object Key: "...xK........." = 0xfe94ba784b000015080000000000 (14 bytes)
>> TAG_ORB_TYPE omniORB
>> TAG_CODE_SETS char native code set: ISO-8859-1
>> char conversion code set: UTF-8
>> wchar native code set: UTF-16
>> wchar conversion code set: UTF-16
>>
>> Object Key が 0xfe94ba784b000015080000000000 というORB (というかPOA) が
>> 適当に付けた名前になっています。
>>
>>
>> ついでですので、マネージャの使い方についても少し説明します。
>>
>> マネージャにはマスタとスレーブがあります。
>>
>> ・マスタマネージャ：
>> 原則1ノードにつき1つだけ存在する。
>> アプリケーション、ノードの外部などからは、マスターマネージャに対して
>> コンポーネントの生成を依頼する。
>> つまり、原則として、このマネージャ自身はコンポーネントを生成・管理しない。
>> 実際のコンポーネントの生成は、マスタがスレーブマネージャに依頼する。
>>
>> ・スレーブマネージャ：
>> 1ノードに複数存在できる。0個以上のマスターに所属することができる。
>> rtcdを-dなしで起動した場合、マスターがすでに起動していればその配下に入る。
>> コンポーネントはスレーブマネージャ上で生成・管理される。
>> 原則、コンポーネントが存在しないスレーブマネージャは存在しない（自動でシャットダウンされる）。
>> -> 菅さんがご指摘されたように、-d オプションなしのrtcdが自動で終了するのはこのためです。
>> マスターマネージャからは、スレーブはポート番号で区別される。
>> つまり、同一ポート番号のスレーブマネージャは、同一のプロセス（逆もしかり）である。
>>
>> コンポーネント生成の流れは、以下のようになります。
>>
>> 1) RTCが起動される可能性のあるノード上では、rtcd は -d オプション付きで起動されているものとします。
>> ＃Linuxではれば、/etc/init.d 以下の起動スクリプトなどで起動されているイメージ。
>>
>> 2) 何らかのツール、コマンド、アプリケーションが、あるノードに対してコンポーネントを作成したい場合
>> まず、そのノードのマスタマネージャのオブジェクトリファレンスを取得します。
>> それは、ネームサーバからでもいいですし、corbaloc:iiop:hostname:2810/manager という URL を
>> ORB::string_to_object() 関数を使ってダイレクトにアクセスしてもかまいません。
>>
>> 3) 何らかのツール、コマンド、アプリケーションが、あるノード上で、コンポーネントを起動する場合、
>> そのノードのマスターマネージャに対して create_component() をコールします。
>> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234")
>>
>> 4) manager=localhost:2811 はローカルホスト上の 2811版ポート上で ConsoleIn という
>> コンポーネントを起動しなさい、という意味なので、マスターマネージャは、スレーブマネージャを
>> 2811ポート上で起動し、そのマネージャに対して、create_component("ConsoleIn?instance_name=ConsoleIn1234")
>> をコールします。
>>
>> 5) スレーブマネージャは、ポート2811上で起動し、ConsoleInを一つ生成します。
>> このとき、インスタンス名はConsoleIn1234 に指定されているのでインスタンス名はこの名前になり、
>> ネームサーバ上に登録される名前も、この名前になります。
>>
>> 6) さらに、同じプロセス上で、ConsoleIn を起動したければ、
>> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1235")
>> とをマスタマネージャに対してコールすればよく、異なるプロセスで起動したい場合は、
>> mgr->create_component("ConsoleIn?manager=localhost:2812&instance_name=ConsoleIn1235")
>> 等とすれば、別のプロセス上でConsoleInが起動します。
>>
>> 7) なお、そのノード上で起動しているコンポーネントの参照は、マスターマネージャから、
>> mgr->get_components() によって取得できます。
>> スレーブ上で起動しているすべてのコンポーネントの参照をマスターが収集して返しています。
>>
>>
>> 一応、1.0-RELEASEのrtcdはこのような使い方を意図して実装されています。
>> まだ、ツールの方でも対応しきれていないので、この使い方が実際利用できるのには
>> 少々時間がかかると思いますが、RTSystemEditorやrtcshellなどで、
>> 簡単にできるようにしていきたいと思います。
>> ＃rtcshellについては、ジェフさんよろしく。
>>
>> あと、Windows上で起動したrtcdに、RTSystemEditorのmanager viewからアクセスすると、
>> 非常に重いのですが、これはDLLからRTCのプロファイルを取得する操作がWindows
>> 上ではなぜだか非常に遅いために発生しています。（Linuxだと一瞬で終わるのですが。。。）
>> また、OpenCVをインストールしていない場合、RTCのプロファイルを取得する過程で、
>> USBcamera*コンポーネントをアクセスした段階で、DLLのエラーダイアログが出てしまい
>> アクセスがさらに遅くなってしまいます。
>> OpenCVをインストールするか、USBCameda*.DLLを削除するかすると改善します。
>>
>

Mon, 2010-02-15 14:52

(Reply to #7) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01103] Managerのnamingformatの不具合

安藤さん：

原です。Well Knownポートは、仰る通り強制力はありません。
しかし、OMG等に持って行き標準化を進めていところの実装で
登録せずに、しかもすでに登録してある　Well Known ポート番号を
使っているのはいかがなものでしょうか？

本来なら、きちんと登録して決めてあげる方がよいと思います。
私は、Internetでのマナーかなと思います。

逆に、OpenRTMを全く知らない人が、このような実装を見たときに
「あー、知らないんだな」と思われる方が嫌かと思いますが。

2010年2月15日14:27 Ando Noriaki :
> 原様
>
> 安藤です
>
> 固定というのは、デフォルトで2810番という意味で、
> 変更したい場合は、rtc.conf で
> corba.master_manager: localhost:49152
> のように指定してください。
>
> ちなみに、1024〜49151 は well known ポートではないので、
> 勝手に使ってはいけない、というほどの強制力はないですよね。
> OpenRTMがすごく広まったら、ちゃんと登録しないとだめかもしれませんが（笑
>
>
>
>
> 2010年2月15日13:23 Isao Hara :
>> 安藤様、皆様：
>>
>> 産総研の原です。
>> 下記のようにネームサーバーのポート番号が固定されているということですが、
>> 2810番のように49151番より下の番号は、勝手につかってはいけません。
>> IANAというところで管理しています。
>> また、2810は、
>> # Ted McFadden
>> netsteward 2810/tcp Active Net Steward
>> netsteward 2810/udp Active Net Steward
>>
>> のようにアプリケーションの登録がなされていますので、変更をお願いいたします。
>>
>> (2010/02/15 12:43), Ando Noriaki wrote:
>>> 菅様、皆さま
>>>
>>> 安藤です
>>>
>>> rtcdについて、まだドキュメントを書いていないので、
>>> いろいろ混乱させてしまいすみません。
>>> ドキュメントはもう少々お待ちください。
>>>
>>>
>>> 今回の件ですが、ネームサーバ上に残ったマネージャーのゾンビリファレンスが、
>>> そのごrtc.confでマネージャの登録名を変えたにもかかわらず復活してしまう
>>>
>>> ということでよろしいでしょうか。
>>>
>>> これは、簡潔に言いますと、マネージャーを INS 化したためで、
>>> 対処方法としては、ゾンビ化させないで、マネージャはshutdownコマンドで
>>> 終了させてください、ということになります。
>>>
>>> 以下、長文すみません。
>>>
>>>
>>>> さて，今回の問題ですが，追加報告です．
>>>> rtcdを使って現象をいくつか試していますが，
>>>> 以下の操作で再現されることがわかりました．
>>>>
>>>> 一言で表現すると，ゾンビーの復活です．
>>>>
>>>> 初回のrtcdの実行ではnaming_formatsを指定しない，
>>>> 以下のrtc.confで実行．
>>>>
>>>> corba.nameservers: localhost
>>>> naming.formats: %h.host_cxt/%n.rtc
>>>> logger.enable: NO
>>>> logger.log_level: PARANOID
>>>> manager.modules.load_path: ../examples/C++/, ../components/
>>>>
>>>> その後，rtcdを無理やり停止して，ゾンビーを残す．
>>>>
>>>> 次にrtc.confを加工する
>>>>
>>>> corba.nameservers: localhost
>>>> naming.formats: %h.host_cxt/%n.rtc
>>>> logger.enable: NO
>>>> logger.log_level: PARANOID
>>>> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
>>>> manager.modules.load_path: ../examples/C++/, ../components/
>>>>
>>>> 5行目を追加．そして実行すると，
>>>> ゾンビーだったmanager.mgrが復活する．
>>>> こちらからcreateを呼び出しても可能になってしまいます．
>>>>
>>>> 初回の起動でゾンビーがなければ意図通りに動作します．
>>>> また，逆の順序で実行しても同様の現象が起こります．
>>>
>>>
>>> 詳しく解説しますと、
>>>
>>> CORBAオブジェクトは、特に何もしていしなければ、生成されるたびに適当なKey (IDのようなもの)
>>> を持ったオブジェクトとして生成され、ネームサーバに登録されるリファレンスも、
>>> たとえ名前が同じであっても、生成されるたびに異なるKeyのオブジェクトとして
>>> 登録されます。
>>>
>>> たとえば、ConsoleIn コンポーネントを2回生成したとします。
>>> 1回目の生成では、以下のような参照がネームサーバに登録されます。
>>>
>>> 名前： ConsoleIn0.rtc 参照：(Key: 0x7183618368, IPアドレス： 192.168.1.10, ポート番号：3444)
>>>
>>> このプロセスを落として、もう一度起動します。次は、以下のような参照が登録されます。
>>>
>>> 名前： ConsoleIn0.rtc 参照：(Key: 0x8297427492, IPアドレス： 192.168.1.10, ポート番号：3653)
>>>
>>> 通常、複数回起動しても同じなのはIPアドレスと名前くらいで、Keyやポート番号はORBやOS
>>> の気分によって変わってしまいます(笑
>>>
>>> しかし、rtcdを-dオプション付きで起動すると、マネージャーはマスターマネージャ（後ほど解説します）となり、
>>> のKeyとポート番号が固定されます。(デフォルトでは Key は manager, ポート番号は 2810 になります。)
>>>
>>> つまり、マネージャーの名前は、以下のような参照としてネームサーバに登録されます。
>>>
>>> 名前： hsotname.host_cxt/manager.mgr 参照：(Key： manager, IPアドレス：
>>> 192.168.1.10, ポート番号：2810) ・・・ (1)
>>>
>>> ここで、マネージャーを強制終了すると、この名前の登録を掃除しないで終了するので、
>>> ネームサーバ上にこの名前がそのまま残ってしまいます。
>>> 次に、rtc.confでmanager.naming_formats を変更すると、
>>>
>>> 名前： hostname.host_cxt/ysuga_net.app_cxt/manager.mgr 参照：(Key： manager,
>>> IPアドレス： 192.168.1.10, ポート番号：2810) ・・・ (2)
>>>
>>> として、マネージャが登録されます。
>>>
>>> ここで、(1)と(2)の参照（ID、IP、ポート）を比べてみると、まったく同じになっています。
>>> したがって、(1)の参照にアクセスしても、(2)と同じオブジェクトにアクセスすることになります。
>>> そういうわけで、ゾンビ化したマネージャ(1)も、復活してしまう、というわけです。
>>>
>>>
>>>
>>> なお、マネージャをこのようにIDやポート番号を固定したわけは、ネームサーバなして
>>> マネージャやコンポーネントにアクセスするためです。この辺は、以前松坂さんからご意見のあった、
>>> ネームサーバがシステムの single point of failure になることを避ける手段として
>>> ネームサーバに依存しないでシステムを構築する方法を提供したかったためです。
>>>
>>> こうすることでマネージャは corbaloc:iiop:hostname:port/manager という URL で常に
>>> アクセスできるようになります。ここでポート番号は固定で 2810 としているので、
>>> ホスト名さえ分かれば、そのノードのマスタマネージャにアクセスできることになります。
>>>
>>> ちなみに、こういうオブジェクトの名前付けを INS (Interoperable Naming Service) といいます。
>>>
>>> 以下は、log出力の例ですが、マネージャのIOR(オブジェクト参照)の情報は、
>>>
>>> Feb 15 10:35:40 DEBUG: ManagerServant: Manager's IOR information:
>>> IOR information
>>> Type ID: "IDL:RTM/Manager:1.0"
>>> Profiles:
>>> 1. IIOP 1.2 192.168.100.2 2810
>>> Object Key: "manager" = 0x6d616e61676572 (7 bytes)
>>> TAG_ORB_TYPE omniORB
>>> TAG_CODE_SETS char native code set: ISO-8859-1
>>> char conversion code set: UTF-8
>>> wchar native code set: UTF-16
>>> wchar conversion code set: UTF-16
>>>
>>> このように、Object Key が "manager" という人間が読める形式になっているのに対し、
>>> 以下は ConsoleIn をネームサーバに登録する際のIORなのですが、
>>>
>>> IOR information
>>> Type ID: "IDL:openrtm.aist.go.jp/OpenRTM/DataFlowComponent:1.0"
>>> Profiles:
>>> 1. IIOP 1.2 192.168.100.2 2810
>>> POA(root) Object Key: "...." = 0x00000000 (4 bytes)
>>> Object Key: "...xK........." = 0xfe94ba784b000015080000000000 (14 bytes)
>>> TAG_ORB_TYPE omniORB
>>> TAG_CODE_SETS char native code set: ISO-8859-1
>>> char conversion code set: UTF-8
>>> wchar native code set: UTF-16
>>> wchar conversion code set: UTF-16
>>>
>>> Object Key が 0xfe94ba784b000015080000000000 というORB (というかPOA) が
>>> 適当に付けた名前になっています。
>>>
>>>
>>> ついでですので、マネージャの使い方についても少し説明します。
>>>
>>> マネージャにはマスタとスレーブがあります。
>>>
>>> ・マスタマネージャ：
>>> 原則1ノードにつき1つだけ存在する。
>>> アプリケーション、ノードの外部などからは、マスターマネージャに対して
>>> コンポーネントの生成を依頼する。
>>> つまり、原則として、このマネージャ自身はコンポーネントを生成・管理しない。
>>> 実際のコンポーネントの生成は、マスタがスレーブマネージャに依頼する。
>>>
>>> ・スレーブマネージャ：
>>> 1ノードに複数存在できる。0個以上のマスターに所属することができる。
>>> rtcdを-dなしで起動した場合、マスターがすでに起動していればその配下に入る。
>>> コンポーネントはスレーブマネージャ上で生成・管理される。
>>> 原則、コンポーネントが存在しないスレーブマネージャは存在しない（自動でシャットダウンされる）。
>>> -> 菅さんがご指摘されたように、-d オプションなしのrtcdが自動で終了するのはこのためです。
>>> マスターマネージャからは、スレーブはポート番号で区別される。
>>> つまり、同一ポート番号のスレーブマネージャは、同一のプロセス（逆もしかり）である。
>>>
>>> コンポーネント生成の流れは、以下のようになります。
>>>
>>> 1) RTCが起動される可能性のあるノード上では、rtcd は -d オプション付きで起動されているものとします。
>>> ＃Linuxではれば、/etc/init.d 以下の起動スクリプトなどで起動されているイメージ。
>>>
>>> 2) 何らかのツール、コマンド、アプリケーションが、あるノードに対してコンポーネントを作成したい場合
>>> まず、そのノードのマスタマネージャのオブジェクトリファレンスを取得します。
>>> それは、ネームサーバからでもいいですし、corbaloc:iiop:hostname:2810/manager という URL を
>>> ORB::string_to_object() 関数を使ってダイレクトにアクセスしてもかまいません。
>>>
>>> 3) 何らかのツール、コマンド、アプリケーションが、あるノード上で、コンポーネントを起動する場合、
>>> そのノードのマスターマネージャに対して create_component() をコールします。
>>> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234")
>>>
>>> 4) manager=localhost:2811 はローカルホスト上の 2811版ポート上で ConsoleIn という
>>> コンポーネントを起動しなさい、という意味なので、マスターマネージャは、スレーブマネージャを
>>> 2811ポート上で起動し、そのマネージャに対して、create_component("ConsoleIn?instance_name=ConsoleIn1234")
>>> をコールします。
>>>
>>> 5) スレーブマネージャは、ポート2811上で起動し、ConsoleInを一つ生成します。
>>> このとき、インスタンス名はConsoleIn1234 に指定されているのでインスタンス名はこの名前になり、
>>> ネームサーバ上に登録される名前も、この名前になります。
>>>
>>> 6) さらに、同じプロセス上で、ConsoleIn を起動したければ、
>>> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1235")
>>> とをマスタマネージャに対してコールすればよく、異なるプロセスで起動したい場合は、
>>> mgr->create_component("ConsoleIn?manager=localhost:2812&instance_name=ConsoleIn1235")
>>> 等とすれば、別のプロセス上でConsoleInが起動します。
>>>
>>> 7) なお、そのノード上で起動しているコンポーネントの参照は、マスターマネージャから、
>>> mgr->get_components() によって取得できます。
>>> スレーブ上で起動しているすべてのコンポーネントの参照をマスターが収集して返しています。
>>>
>>>
>>> 一応、1.0-RELEASEのrtcdはこのような使い方を意図して実装されています。
>>> まだ、ツールの方でも対応しきれていないので、この使い方が実際利用できるのには
>>> 少々時間がかかると思いますが、RTSystemEditorやrtcshellなどで、
>>> 簡単にできるようにしていきたいと思います。
>>> ＃rtcshellについては、ジェフさんよろしく。
>>>
>>> あと、Windows上で起動したrtcdに、RTSystemEditorのmanager viewからアクセスすると、
>>> 非常に重いのですが、これはDLLからRTCのプロファイルを取得する操作がWindows
>>> 上ではなぜだか非常に遅いために発生しています。（Linuxだと一瞬で終わるのですが。。。）
>>> また、OpenCVをインストールしていない場合、RTCのプロファイルを取得する過程で、
>>> USBcamera*コンポーネントをアクセスした段階で、DLLのエラーダイアログが出てしまい
>>> アクセスがさらに遅くなってしまいます。
>>> OpenCVをインストールするか、USBCameda*.DLLを削除するかすると改善します。
>>>
>>

Mon, 2010-02-15 15:14

(Reply to #8) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01104] Managerのnamingformatの不具合

安藤さん, 原さん,

ポート番号の1024〜49151はwell-knownではありません。registered port
numbersとされています。

ただ、well known portを*含めて*そのポート番号の使用は「SHOULD NOT」であっ
て「MUST NOT(あるいはSHALL NOT)」ではありません。「SHOULD NOT」は「NOT
RECOMMENDED」を意味するので(See RFC2119)、解釈としては安藤さんが正しい
です。

もちろん、今のうちからIANAに登録してポート番号を確保しておくのが一番ス
マートな解だとは思います。

…というメールを書いたところに原さんの次のメールが届きましたが、せっか
く書いたので送ってしまいます(笑)。

In article ,
Ando Noriaki writes:
> 原様
>
> 安藤です
>
> 固定というのは、デフォルトで2810番という意味で、
> 変更したい場合は、rtc.conf で
> corba.master_manager: localhost:49152
> のように指定してください。
>
> ちなみに、1024〜49151 は well known ポートではないので、
> 勝手に使ってはいけない、というほどの強制力はないですよね。
> OpenRTMがすごく広まったら、ちゃんと登録しないとだめかもしれませんが（笑
>
>
>
>
> 2010年2月15日13:23 Isao Hara :
> > 安藤様、皆様：
> >
> > 産総研の原です。
> > 下記のようにネームサーバーのポート番号が固定されているということですが、
> > 2810番のように49151番より下の番号は、勝手につかってはいけません。
> > IANAというところで管理しています。
> > また、2810は、
> > # Ted McFadden
> > netsteward 2810/tcp Active Net Steward
> > netsteward 2810/udp Active Net Steward
> >
> > のようにアプリケーションの登録がなされていますので、変更をお願いいたします。
> >
> > (2010/02/15 12:43), Ando Noriaki wrote:
> >> 菅様、皆さま
> >>
> >> 安藤です
> >>
> >> rtcdについて、まだドキュメントを書いていないので、
> >> いろいろ混乱させてしまいすみません。
> >> ドキュメントはもう少々お待ちください。
> >>
> >>
> >> 今回の件ですが、ネームサーバ上に残ったマネージャーのゾンビリファレンスが、
> >> そのごrtc.confでマネージャの登録名を変えたにもかかわらず復活してしまう
> >>
> >> ということでよろしいでしょうか。
> >>
> >> これは、簡潔に言いますと、マネージャーを INS 化したためで、
> >> 対処方法としては、ゾンビ化させないで、マネージャはshutdownコマンドで
> >> 終了させてください、ということになります。
> >>
> >> 以下、長文すみません。
> >>
> >>
> >>> さて，今回の問題ですが，追加報告です．
> >>> rtcdを使って現象をいくつか試していますが，
> >>> 以下の操作で再現されることがわかりました．
> >>>
> >>> 一言で表現すると，ゾンビーの復活です．
> >>>
> >>> 初回のrtcdの実行ではnaming_formatsを指定しない，
> >>> 以下のrtc.confで実行．
> >>>
> >>> corba.nameservers: localhost
> >>> naming.formats: %h.host_cxt/%n.rtc
> >>> logger.enable: NO
> >>> logger.log_level: PARANOID
> >>> manager.modules.load_path: ../examples/C++/, ../components/
> >>>
> >>> その後，rtcdを無理やり停止して，ゾンビーを残す．
> >>>
> >>> 次にrtc.confを加工する
> >>>
> >>> corba.nameservers: localhost
> >>> naming.formats: %h.host_cxt/%n.rtc
> >>> logger.enable: NO
> >>> logger.log_level: PARANOID
> >>> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
> >>> manager.modules.load_path: ../examples/C++/, ../components/
> >>>
> >>> 5行目を追加．そして実行すると，
> >>> ゾンビーだったmanager.mgrが復活する．
> >>> こちらからcreateを呼び出しても可能になってしまいます．
> >>>
> >>> 初回の起動でゾンビーがなければ意図通りに動作します．
> >>> また，逆の順序で実行しても同様の現象が起こります．
> >>
> >>
> >> 詳しく解説しますと、
> >>
> >> CORBAオブジェクトは、特に何もしていしなければ、生成されるたびに適当なKey (IDのようなもの)
> >> を持ったオブジェクトとして生成され、ネームサーバに登録されるリファレンスも、
> >> たとえ名前が同じであっても、生成されるたびに異なるKeyのオブジェクトとして
> >> 登録されます。
> >>
> >> たとえば、ConsoleIn コンポーネントを2回生成したとします。
> >> 1回目の生成では、以下のような参照がネームサーバに登録されます。
> >>
> >> 名前： ConsoleIn0.rtc 参照：(Key: 0x7183618368, IPアドレス： 192.168.1.10, ポート番号：3444)
> >>
> >> このプロセスを落として、もう一度起動します。次は、以下のような参照が登録されます。
> >>
> >> 名前： ConsoleIn0.rtc 参照：(Key: 0x8297427492, IPアドレス： 192.168.1.10, ポート番号：3653)
> >>
> >> 通常、複数回起動しても同じなのはIPアドレスと名前くらいで、Keyやポート番号はORBやOS
> >> の気分によって変わってしまいます(笑
> >>
> >> しかし、rtcdを-dオプション付きで起動すると、マネージャーはマスターマネージャ（後ほど解説します）となり、
> >> のKeyとポート番号が固定されます。(デフォルトでは Key は manager, ポート番号は 2810 になります。)
> >>
> >> つまり、マネージャーの名前は、以下のような参照としてネームサーバに登録されます。
> >>
> >> 名前： hsotname.host_cxt/manager.mgr 参照：(Key： manager, IPアドレス：
> >> 192.168.1.10, ポート番号：2810) ・・・ (1)
> >>
> >> ここで、マネージャーを強制終了すると、この名前の登録を掃除しないで終了するので、
> >> ネームサーバ上にこの名前がそのまま残ってしまいます。
> >> 次に、rtc.confでmanager.naming_formats を変更すると、
> >>
> >> 名前： hostname.host_cxt/ysuga_net.app_cxt/manager.mgr 参照：(Key： manager,
> >> IPアドレス： 192.168.1.10, ポート番号：2810) ・・・ (2)
> >>
> >> として、マネージャが登録されます。
> >>
> >> ここで、(1)と(2)の参照（ID、IP、ポート）を比べてみると、まったく同じになっています。
> >> したがって、(1)の参照にアクセスしても、(2)と同じオブジェクトにアクセスすることになります。
> >> そういうわけで、ゾンビ化したマネージャ(1)も、復活してしまう、というわけです。
> >>
> >>
> >>
> >> なお、マネージャをこのようにIDやポート番号を固定したわけは、ネームサーバなして
> >> マネージャやコンポーネントにアクセスするためです。この辺は、以前松坂さんからご意見のあった、
> >> ネームサーバがシステムの single point of failure になることを避ける手段として
> >> ネームサーバに依存しないでシステムを構築する方法を提供したかったためです。
> >>
> >> こうすることでマネージャは corbaloc:iiop:hostname:port/manager という URL で常に
> >> アクセスできるようになります。ここでポート番号は固定で 2810 としているので、
> >> ホスト名さえ分かれば、そのノードのマスタマネージャにアクセスできることになります。
> >>
> >> ちなみに、こういうオブジェクトの名前付けを INS (Interoperable Naming Service) といいます。
> >>
> >> 以下は、log出力の例ですが、マネージャのIOR(オブジェクト参照)の情報は、
> >>
> >> Feb 15 10:35:40 DEBUG: ManagerServant: Manager's IOR information:
> >> IOR information
> >> Type ID: "IDL:RTM/Manager:1.0"
> >> Profiles:
> >> 1. IIOP 1.2 192.168.100.2 2810
> >> Object Key: "manager" = 0x6d616e61676572 (7 bytes)
> >> TAG_ORB_TYPE omniORB
> >> TAG_CODE_SETS char native code set: ISO-8859-1
> >> char conversion code set: UTF-8
> >> wchar native code set: UTF-16
> >> wchar conversion code set: UTF-16
> >>
> >> このように、Object Key が "manager" という人間が読める形式になっているのに対し、
> >> 以下は ConsoleIn をネームサーバに登録する際のIORなのですが、
> >>
> >> IOR information
> >> Type ID: "IDL:openrtm.aist.go.jp/OpenRTM/DataFlowComponent:1.0"
> >> Profiles:
> >> 1. IIOP 1.2 192.168.100.2 2810
> >> POA(root) Object Key: "...." = 0x00000000 (4 bytes)
> >> Object Key: "...xK........." = 0xfe94ba784b000015080000000000 (14 bytes)
> >> TAG_ORB_TYPE omniORB
> >> TAG_CODE_SETS char native code set: ISO-8859-1
> >> char conversion code set: UTF-8
> >> wchar native code set: UTF-16
> >> wchar conversion code set: UTF-16
> >>
> >> Object Key が 0xfe94ba784b000015080000000000 というORB (というかPOA) が
> >> 適当に付けた名前になっています。
> >>
> >>
> >> ついでですので、マネージャの使い方についても少し説明します。
> >>
> >> マネージャにはマスタとスレーブがあります。
> >>
> >> ・マスタマネージャ：
> >> 原則1ノードにつき1つだけ存在する。
> >> アプリケーション、ノードの外部などからは、マスターマネージャに対して
> >> コンポーネントの生成を依頼する。
> >> つまり、原則として、このマネージャ自身はコンポーネントを生成・管理しない。
> >> 実際のコンポーネントの生成は、マスタがスレーブマネージャに依頼する。
> >>
> >> ・スレーブマネージャ：
> >> 1ノードに複数存在できる。0個以上のマスターに所属することができる。
> >> rtcdを-dなしで起動した場合、マスターがすでに起動していればその配下に入る。
> >> コンポーネントはスレーブマネージャ上で生成・管理される。
> >> 原則、コンポーネントが存在しないスレーブマネージャは存在しない（自動でシャットダウンされる）。
> >> -> 菅さんがご指摘されたように、-d オプションなしのrtcdが自動で終了するのはこのためです。
> >> マスターマネージャからは、スレーブはポート番号で区別される。
> >> つまり、同一ポート番号のスレーブマネージャは、同一のプロセス（逆もしかり）である。
> >>
> >> コンポーネント生成の流れは、以下のようになります。
> >>
> >> 1) RTCが起動される可能性のあるノード上では、rtcd は -d オプション付きで起動されているものとします。
> >> ＃Linuxではれば、/etc/init.d 以下の起動スクリプトなどで起動されているイメージ。
> >>
> >> 2) 何らかのツール、コマンド、アプリケーションが、あるノードに対してコンポーネントを作成したい場合
> >> まず、そのノードのマスタマネージャのオブジェクトリファレンスを取得します。
> >> それは、ネームサーバからでもいいですし、corbaloc:iiop:hostname:2810/manager という URL を
> >> ORB::string_to_object() 関数を使ってダイレクトにアクセスしてもかまいません。
> >>
> >> 3) 何らかのツール、コマンド、アプリケーションが、あるノード上で、コンポーネントを起動する場合、
> >> そのノードのマスターマネージャに対して create_component() をコールします。
> >> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234")
> >>
> >> 4) manager=localhost:2811 はローカルホスト上の 2811版ポート上で ConsoleIn という
> >> コンポーネントを起動しなさい、という意味なので、マスターマネージャは、スレーブマネージャを
> >> 2811ポート上で起動し、そのマネージャに対して、create_component("ConsoleIn?instance_name=ConsoleIn1234")
> >> をコールします。
> >>
> >> 5) スレーブマネージャは、ポート2811上で起動し、ConsoleInを一つ生成します。
> >> このとき、インスタンス名はConsoleIn1234 に指定されているのでインスタンス名はこの名前になり、
> >> ネームサーバ上に登録される名前も、この名前になります。
> >>
> >> 6) さらに、同じプロセス上で、ConsoleIn を起動したければ、
> >> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1235")
> >> とをマスタマネージャに対してコールすればよく、異なるプロセスで起動したい場合は、
> >> mgr->create_component("ConsoleIn?manager=localhost:2812&instance_name=ConsoleIn1235")
> >> 等とすれば、別のプロセス上でConsoleInが起動します。
> >>
> >> 7) なお、そのノード上で起動しているコンポーネントの参照は、マスターマネージャから、
> >> mgr->get_components() によって取得できます。
> >> スレーブ上で起動しているすべてのコンポーネントの参照をマスターが収集して返しています。
> >>
> >>
> >> 一応、1.0-RELEASEのrtcdはこのような使い方を意図して実装されています。
> >> まだ、ツールの方でも対応しきれていないので、この使い方が実際利用できるのには
> >> 少々時間がかかると思いますが、RTSystemEditorやrtcshellなどで、
> >> 簡単にできるようにしていきたいと思います。
> >> ＃rtcshellについては、ジェフさんよろしく。
> >>
> >> あと、Windows上で起動したrtcdに、RTSystemEditorのmanager viewからアクセスすると、
> >> 非常に重いのですが、これはDLLからRTCのプロファイルを取得する操作がWindows
> >> 上ではなぜだか非常に遅いために発生しています。（Linuxだと一瞬で終わるのですが。。。）
> >> また、OpenCVをインストールしていない場合、RTCのプロファイルを取得する過程で、
> >> USBcamera*コンポーネントをアクセスした段階で、DLLのエラーダイアログが出てしまい
> >> アクセスがさらに遅くなってしまいます。
> >> OpenCVをインストールするか、USBCameda*.DLLを削除するかすると改善します。
> >>

Mon, 2010-02-15 15:48

(Reply to #9) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01105] Managerのnamingformatの不具合

安藤です

2810はwell knownではないので、まぁいいんじゃないでしょうか、
というのが僕の考えです。

実は、マネージャ指定で使用する corbaloc 形式ですが、
corbaloc:iiop::/
ののデフォルトは 2809 です。(CORBAの仕様)
でも、たいていのCORBAではネームサーバがこのポートを使っているので、
混乱を避けるために 2810 をデフォルトにしたというわけです。

rtcdにネームサーバを内蔵してしまう、というのも解決策としてはありますね。
javaのorbdは、実際ネームサーバとオブジェクトサーバを兼ねているようですし。

堀さんのおっしゃるようにポート番号を確保してそれを使うのが
いいかもしれませんが、rtcd自体がパブリックなサービスとして
成立するかどうかもわからないので、とりあえず

「何も指定しないと2810番になるけど、使用する状況で適宜rtc.confで変更してください。」

というところでどうでしょうか？

余談ですが、Linuxでは自由に使えるポートとして
$ cat /proc/sys/net/ipv4/ip_local_port_range
32768 61000

つまり、327680〜61000 となっているらしいです。
FreeBSDとかだと、
> sysctl -a|grep portrange
:
net.inet.ip.portrange.last: 65535
net.inet.ip.portrange.first: 49152
:
なんですけどね。

2010年2月15日15:14 Toshio HORI :
> 安藤さん, 原さん,
>
> ポート番号の1024〜49151はwell-knownではありません。registered port
> numbersとされています。
>
> ただ、well known portを*含めて*そのポート番号の使用は「SHOULD NOT」であっ
> て「MUST NOT(あるいはSHALL NOT)」ではありません。「SHOULD NOT」は「NOT
> RECOMMENDED」を意味するので(See RFC2119)、解釈としては安藤さんが正しい
> です。
>
> もちろん、今のうちからIANAに登録してポート番号を確保しておくのが一番ス
> マートな解だとは思います。
>
> …というメールを書いたところに原さんの次のメールが届きましたが、せっか
> く書いたので送ってしまいます(笑)。
>
> // 堀俊夫, 博士(工学) / t.hori@aist.go.jp
> // (独)産業技術総合研究所デジタルヒューマン研究センター主任研究員
> // & OMG Robotics-DTF Robotic Functional Service WG共同座長
> // Web: http://www.dh.aist.go.jp/members/toshi.php
>
> In article ,
> Ando Noriaki writes:
>> 原様
>>
>> 安藤です
>>
>> 固定というのは、デフォルトで2810番という意味で、
>> 変更したい場合は、rtc.conf で
>> corba.master_manager: localhost:49152
>> のように指定してください。
>>
>> ちなみに、1024〜49151 は well known ポートではないので、
>> 勝手に使ってはいけない、というほどの強制力はないですよね。
>> OpenRTMがすごく広まったら、ちゃんと登録しないとだめかもしれませんが（笑
>>
>>
>>
>>
>> 2010年2月15日13:23 Isao Hara :
>> > 安藤様、皆様：
>> >
>> > 産総研の原です。
>> > 下記のようにネームサーバーのポート番号が固定されているということですが、
>> > 2810番のように49151番より下の番号は、勝手につかってはいけません。
>> > IANAというところで管理しています。
>> > また、2810は、
>> > # Ted McFadden
>> > netsteward 2810/tcp Active Net Steward
>> > netsteward 2810/udp Active Net Steward
>> >
>> > のようにアプリケーションの登録がなされていますので、変更をお願いいたします。
>> >
>> > (2010/02/15 12:43), Ando Noriaki wrote:
>> >> 菅様、皆さま
>> >>
>> >> 安藤です
>> >>
>> >> rtcdについて、まだドキュメントを書いていないので、
>> >> いろいろ混乱させてしまいすみません。
>> >> ドキュメントはもう少々お待ちください。
>> >>
>> >>
>> >> 今回の件ですが、ネームサーバ上に残ったマネージャーのゾンビリファレンスが、
>> >> そのごrtc.confでマネージャの登録名を変えたにもかかわらず復活してしまう
>> >>
>> >> ということでよろしいでしょうか。
>> >>
>> >> これは、簡潔に言いますと、マネージャーを INS 化したためで、
>> >> 対処方法としては、ゾンビ化させないで、マネージャはshutdownコマンドで
>> >> 終了させてください、ということになります。
>> >>
>> >> 以下、長文すみません。
>> >>
>> >>
>> >>> さて，今回の問題ですが，追加報告です．
>> >>> rtcdを使って現象をいくつか試していますが，
>> >>> 以下の操作で再現されることがわかりました．
>> >>>
>> >>> 一言で表現すると，ゾンビーの復活です．
>> >>>
>> >>> 初回のrtcdの実行ではnaming_formatsを指定しない，
>> >>> 以下のrtc.confで実行．
>> >>>
>> >>> corba.nameservers: localhost
>> >>> naming.formats: %h.host_cxt/%n.rtc
>> >>> logger.enable: NO
>> >>> logger.log_level: PARANOID
>> >>> manager.modules.load_path: ../examples/C++/, ../components/
>> >>>
>> >>> その後，rtcdを無理やり停止して，ゾンビーを残す．
>> >>>
>> >>> 次にrtc.confを加工する
>> >>>
>> >>> corba.nameservers: localhost
>> >>> naming.formats: %h.host_cxt/%n.rtc
>> >>> logger.enable: NO
>> >>> logger.log_level: PARANOID
>> >>> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
>> >>> manager.modules.load_path: ../examples/C++/, ../components/
>> >>>
>> >>> 5行目を追加．そして実行すると，
>> >>> ゾンビーだったmanager.mgrが復活する．
>> >>> こちらからcreateを呼び出しても可能になってしまいます．
>> >>>
>> >>> 初回の起動でゾンビーがなければ意図通りに動作します．
>> >>> また，逆の順序で実行しても同様の現象が起こります．
>> >>
>> >>
>> >> 詳しく解説しますと、
>> >>
>> >> CORBAオブジェクトは、特に何もしていしなければ、生成されるたびに適当なKey (IDのようなもの)
>> >> を持ったオブジェクトとして生成され、ネームサーバに登録されるリファレンスも、
>> >> たとえ名前が同じであっても、生成されるたびに異なるKeyのオブジェクトとして
>> >> 登録されます。
>> >>
>> >> たとえば、ConsoleIn コンポーネントを2回生成したとします。
>> >> 1回目の生成では、以下のような参照がネームサーバに登録されます。
>> >>
>> >> 名前： ConsoleIn0.rtc 参照：(Key: 0x7183618368, IPアドレス： 192.168.1.10, ポート番号：3444)
>> >>
>> >> このプロセスを落として、もう一度起動します。次は、以下のような参照が登録されます。
>> >>
>> >> 名前： ConsoleIn0.rtc 参照：(Key: 0x8297427492, IPアドレス： 192.168.1.10, ポート番号：3653)
>> >>
>> >> 通常、複数回起動しても同じなのはIPアドレスと名前くらいで、Keyやポート番号はORBやOS
>> >> の気分によって変わってしまいます(笑
>> >>
>> >> しかし、rtcdを-dオプション付きで起動すると、マネージャーはマスターマネージャ（後ほど解説します）となり、
>> >> のKeyとポート番号が固定されます。(デフォルトでは Key は manager, ポート番号は 2810 になります。)
>> >>
>> >> つまり、マネージャーの名前は、以下のような参照としてネームサーバに登録されます。
>> >>
>> >> 名前： hsotname.host_cxt/manager.mgr 参照：(Key： manager, IPアドレス：
>> >> 192.168.1.10, ポート番号：2810) ・・・ (1)
>> >>
>> >> ここで、マネージャーを強制終了すると、この名前の登録を掃除しないで終了するので、
>> >> ネームサーバ上にこの名前がそのまま残ってしまいます。
>> >> 次に、rtc.confでmanager.naming_formats を変更すると、
>> >>
>> >> 名前： hostname.host_cxt/ysuga_net.app_cxt/manager.mgr 参照：(Key： manager,
>> >> IPアドレス： 192.168.1.10, ポート番号：2810) ・・・ (2)
>> >>
>> >> として、マネージャが登録されます。
>> >>
>> >> ここで、(1)と(2)の参照（ID、IP、ポート）を比べてみると、まったく同じになっています。
>> >> したがって、(1)の参照にアクセスしても、(2)と同じオブジェクトにアクセスすることになります。
>> >> そういうわけで、ゾンビ化したマネージャ(1)も、復活してしまう、というわけです。
>> >>
>> >>
>> >>
>> >> なお、マネージャをこのようにIDやポート番号を固定したわけは、ネームサーバなして
>> >> マネージャやコンポーネントにアクセスするためです。この辺は、以前松坂さんからご意見のあった、
>> >> ネームサーバがシステムの single point of failure になることを避ける手段として
>> >> ネームサーバに依存しないでシステムを構築する方法を提供したかったためです。
>> >>
>> >> こうすることでマネージャは corbaloc:iiop:hostname:port/manager という URL で常に
>> >> アクセスできるようになります。ここでポート番号は固定で 2810 としているので、
>> >> ホスト名さえ分かれば、そのノードのマスタマネージャにアクセスできることになります。
>> >>
>> >> ちなみに、こういうオブジェクトの名前付けを INS (Interoperable Naming Service) といいます。
>> >>
>> >> 以下は、log出力の例ですが、マネージャのIOR(オブジェクト参照)の情報は、
>> >>
>> >> Feb 15 10:35:40 DEBUG: ManagerServant: Manager's IOR information:
>> >> IOR information
>> >> Type ID: "IDL:RTM/Manager:1.0"
>> >> Profiles:
>> >> 1. IIOP 1.2 192.168.100.2 2810
>> >> Object Key: "manager" = 0x6d616e61676572 (7 bytes)
>> >> TAG_ORB_TYPE omniORB
>> >> TAG_CODE_SETS char native code set: ISO-8859-1
>> >> char conversion code set: UTF-8
>> >> wchar native code set: UTF-16
>> >> wchar conversion code set: UTF-16
>> >>
>> >> このように、Object Key が "manager" という人間が読める形式になっているのに対し、
>> >> 以下は ConsoleIn をネームサーバに登録する際のIORなのですが、
>> >>
>> >> IOR information
>> >> Type ID: "IDL:openrtm.aist.go.jp/OpenRTM/DataFlowComponent:1.0"
>> >> Profiles:
>> >> 1. IIOP 1.2 192.168.100.2 2810
>> >> POA(root) Object Key: "...." = 0x00000000 (4 bytes)
>> >> Object Key: "...xK........." = 0xfe94ba784b000015080000000000 (14 bytes)
>> >> TAG_ORB_TYPE omniORB
>> >> TAG_CODE_SETS char native code set: ISO-8859-1
>> >> char conversion code set: UTF-8
>> >> wchar native code set: UTF-16
>> >> wchar conversion code set: UTF-16
>> >>
>> >> Object Key が 0xfe94ba784b000015080000000000 というORB (というかPOA) が
>> >> 適当に付けた名前になっています。
>> >>
>> >>
>> >> ついでですので、マネージャの使い方についても少し説明します。
>> >>
>> >> マネージャにはマスタとスレーブがあります。
>> >>
>> >> ・マスタマネージャ：
>> >> 原則1ノードにつき1つだけ存在する。
>> >> アプリケーション、ノードの外部などからは、マスターマネージャに対して
>> >> コンポーネントの生成を依頼する。
>> >> つまり、原則として、このマネージャ自身はコンポーネントを生成・管理しない。
>> >> 実際のコンポーネントの生成は、マスタがスレーブマネージャに依頼する。
>> >>
>> >> ・スレーブマネージャ：
>> >> 1ノードに複数存在できる。0個以上のマスターに所属することができる。
>> >> rtcdを-dなしで起動した場合、マスターがすでに起動していればその配下に入る。
>> >> コンポーネントはスレーブマネージャ上で生成・管理される。
>> >> 原則、コンポーネントが存在しないスレーブマネージャは存在しない（自動でシャットダウンされる）。
>> >> -> 菅さんがご指摘されたように、-d オプションなしのrtcdが自動で終了するのはこのためです。
>> >> マスターマネージャからは、スレーブはポート番号で区別される。
>> >> つまり、同一ポート番号のスレーブマネージャは、同一のプロセス（逆もしかり）である。
>> >>
>> >> コンポーネント生成の流れは、以下のようになります。
>> >>
>> >> 1) RTCが起動される可能性のあるノード上では、rtcd は -d オプション付きで起動されているものとします。
>> >> ＃Linuxではれば、/etc/init.d 以下の起動スクリプトなどで起動されているイメージ。
>> >>
>> >> 2) 何らかのツール、コマンド、アプリケーションが、あるノードに対してコンポーネントを作成したい場合
>> >> まず、そのノードのマスタマネージャのオブジェクトリファレンスを取得します。
>> >> それは、ネームサーバからでもいいですし、corbaloc:iiop:hostname:2810/manager という URL を
>> >> ORB::string_to_object() 関数を使ってダイレクトにアクセスしてもかまいません。
>> >>
>> >> 3) 何らかのツール、コマンド、アプリケーションが、あるノード上で、コンポーネントを起動する場合、
>> >> そのノードのマスターマネージャに対して create_component() をコールします。
>> >> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234")
>> >>
>> >> 4) manager=localhost:2811 はローカルホスト上の 2811版ポート上で ConsoleIn という
>> >> コンポーネントを起動しなさい、という意味なので、マスターマネージャは、スレーブマネージャを
>> >> 2811ポート上で起動し、そのマネージャに対して、create_component("ConsoleIn?instance_name=ConsoleIn1234")
>> >> をコールします。
>> >>
>> >> 5) スレーブマネージャは、ポート2811上で起動し、ConsoleInを一つ生成します。
>> >> このとき、インスタンス名はConsoleIn1234 に指定されているのでインスタンス名はこの名前になり、
>> >> ネームサーバ上に登録される名前も、この名前になります。
>> >>
>> >> 6) さらに、同じプロセス上で、ConsoleIn を起動したければ、
>> >> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1235")
>> >> とをマスタマネージャに対してコールすればよく、異なるプロセスで起動したい場合は、
>> >> mgr->create_component("ConsoleIn?manager=localhost:2812&instance_name=ConsoleIn1235")
>> >> 等とすれば、別のプロセス上でConsoleInが起動します。
>> >>
>> >> 7) なお、そのノード上で起動しているコンポーネントの参照は、マスターマネージャから、
>> >> mgr->get_components() によって取得できます。
>> >> スレーブ上で起動しているすべてのコンポーネントの参照をマスターが収集して返しています。
>> >>
>> >>
>> >> 一応、1.0-RELEASEのrtcdはこのような使い方を意図して実装されています。
>> >> まだ、ツールの方でも対応しきれていないので、この使い方が実際利用できるのには
>> >> 少々時間がかかると思いますが、RTSystemEditorやrtcshellなどで、
>> >> 簡単にできるようにしていきたいと思います。
>> >> ＃rtcshellについては、ジェフさんよろしく。
>> >>
>> >> あと、Windows上で起動したrtcdに、RTSystemEditorのmanager viewからアクセスすると、
>> >> 非常に重いのですが、これはDLLからRTCのプロファイルを取得する操作がWindows
>> >> 上ではなぜだか非常に遅いために発生しています。（Linuxだと一瞬で終わるのですが。。。）
>> >> また、OpenCVをインストールしていない場合、RTCのプロファイルを取得する過程で、
>> >> USBcamera*コンポーネントをアクセスした段階で、DLLのエラーダイアログが出てしまい
>> >> アクセスがさらに遅くなってしまいます。
>> >> OpenCVをインストールするか、USBCameda*.DLLを削除するかすると改善します。
>> >>
>> >
>> >

Mon, 2010-02-15 15:56

(Reply to #10) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01107] Managerのnamingformatの不具合

安藤さん：

原です。下記の件ですが、。２８１０は、すでにWell　Known　Portです。
そのため、前のメールを書いた次第です。
競合を避けるために、やはり別ポートを登録して、変更しべきだと思います。

結局、登録しないまま、別ポートにしても後で登録されて、こちらが非登録＆競合
という状態はよくないと思います。

標準実装の１つにするんでしょう？

2010年2月15日15:48 Ando Noriaki :
> 安藤です
>
> 2810はwell knownではないので、まぁいいんじゃないでしょうか、
> というのが僕の考えです。
>
> 実は、マネージャ指定で使用する corbaloc 形式ですが、
> corbaloc:iiop::/
> ののデフォルトは 2809 です。(CORBAの仕様)
> でも、たいていのCORBAではネームサーバがこのポートを使っているので、
> 混乱を避けるために 2810 をデフォルトにしたというわけです。
>
> rtcdにネームサーバを内蔵してしまう、というのも解決策としてはありますね。
> javaのorbdは、実際ネームサーバとオブジェクトサーバを兼ねているようですし。
>
>
> 堀さんのおっしゃるようにポート番号を確保してそれを使うのが
> いいかもしれませんが、rtcd自体がパブリックなサービスとして
> 成立するかどうかもわからないので、とりあえず
>
> 「何も指定しないと2810番になるけど、使用する状況で適宜rtc.confで変更してください。」
>
> というところでどうでしょうか？
>
>
> 余談ですが、Linuxでは自由に使えるポートとして
> $ cat /proc/sys/net/ipv4/ip_local_port_range
> 32768 61000
>
> つまり、327680〜61000 となっているらしいです。
> FreeBSDとかだと、
>> sysctl -a|grep portrange
> :
> net.inet.ip.portrange.last: 65535
> net.inet.ip.portrange.first: 49152
> :
> なんですけどね。
>
>
>
>
> 2010年2月15日15:14 Toshio HORI :
>> 安藤さん, 原さん,
>>
>> ポート番号の1024〜49151はwell-knownではありません。registered port
>> numbersとされています。
>>
>> ただ、well known portを*含めて*そのポート番号の使用は「SHOULD NOT」であっ
>> て「MUST NOT(あるいはSHALL NOT)」ではありません。「SHOULD NOT」は「NOT
>> RECOMMENDED」を意味するので(See RFC2119)、解釈としては安藤さんが正しい
>> です。
>>
>> もちろん、今のうちからIANAに登録してポート番号を確保しておくのが一番ス
>> マートな解だとは思います。
>>
>> …というメールを書いたところに原さんの次のメールが届きましたが、せっか
>> く書いたので送ってしまいます(笑)。
>>
>> // 堀俊夫, 博士(工学) / t.hori@aist.go.jp
>> // (独)産業技術総合研究所デジタルヒューマン研究センター主任研究員
>> // & OMG Robotics-DTF Robotic Functional Service WG共同座長
>> // Web: http://www.dh.aist.go.jp/members/toshi.php
>>
>> In article ,
>> Ando Noriaki writes:
>>> 原様
>>>
>>> 安藤です
>>>
>>> 固定というのは、デフォルトで2810番という意味で、
>>> 変更したい場合は、rtc.conf で
>>> corba.master_manager: localhost:49152
>>> のように指定してください。
>>>
>>> ちなみに、1024〜49151 は well known ポートではないので、
>>> 勝手に使ってはいけない、というほどの強制力はないですよね。
>>> OpenRTMがすごく広まったら、ちゃんと登録しないとだめかもしれませんが（笑
>>>
>>>
>>>
>>>
>>> 2010年2月15日13:23 Isao Hara :
>>> > 安藤様、皆様：
>>> >
>>> > 産総研の原です。
>>> > 下記のようにネームサーバーのポート番号が固定されているということですが、
>>> > 2810番のように49151番より下の番号は、勝手につかってはいけません。
>>> > IANAというところで管理しています。
>>> > また、2810は、
>>> > # Ted McFadden
>>> > netsteward 2810/tcp Active Net Steward
>>> > netsteward 2810/udp Active Net Steward
>>> >
>>> > のようにアプリケーションの登録がなされていますので、変更をお願いいたします。
>>> >
>>> > (2010/02/15 12:43), Ando Noriaki wrote:
>>> >> 菅様、皆さま
>>> >>
>>> >> 安藤です
>>> >>
>>> >> rtcdについて、まだドキュメントを書いていないので、
>>> >> いろいろ混乱させてしまいすみません。
>>> >> ドキュメントはもう少々お待ちください。
>>> >>
>>> >>
>>> >> 今回の件ですが、ネームサーバ上に残ったマネージャーのゾンビリファレンスが、
>>> >> そのごrtc.confでマネージャの登録名を変えたにもかかわらず復活してしまう
>>> >>
>>> >> ということでよろしいでしょうか。
>>> >>
>>> >> これは、簡潔に言いますと、マネージャーを INS 化したためで、
>>> >> 対処方法としては、ゾンビ化させないで、マネージャはshutdownコマンドで
>>> >> 終了させてください、ということになります。
>>> >>
>>> >> 以下、長文すみません。
>>> >>
>>> >>
>>> >>> さて，今回の問題ですが，追加報告です．
>>> >>> rtcdを使って現象をいくつか試していますが，
>>> >>> 以下の操作で再現されることがわかりました．
>>> >>>
>>> >>> 一言で表現すると，ゾンビーの復活です．
>>> >>>
>>> >>> 初回のrtcdの実行ではnaming_formatsを指定しない，
>>> >>> 以下のrtc.confで実行．
>>> >>>
>>> >>> corba.nameservers: localhost
>>> >>> naming.formats: %h.host_cxt/%n.rtc
>>> >>> logger.enable: NO
>>> >>> logger.log_level: PARANOID
>>> >>> manager.modules.load_path: ../examples/C++/, ../components/
>>> >>>
>>> >>> その後，rtcdを無理やり停止して，ゾンビーを残す．
>>> >>>
>>> >>> 次にrtc.confを加工する
>>> >>>
>>> >>> corba.nameservers: localhost
>>> >>> naming.formats: %h.host_cxt/%n.rtc
>>> >>> logger.enable: NO
>>> >>> logger.log_level: PARANOID
>>> >>> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
>>> >>> manager.modules.load_path: ../examples/C++/, ../components/
>>> >>>
>>> >>> 5行目を追加．そして実行すると，
>>> >>> ゾンビーだったmanager.mgrが復活する．
>>> >>> こちらからcreateを呼び出しても可能になってしまいます．
>>> >>>
>>> >>> 初回の起動でゾンビーがなければ意図通りに動作します．
>>> >>> また，逆の順序で実行しても同様の現象が起こります．
>>> >>
>>> >>
>>> >> 詳しく解説しますと、
>>> >>
>>> >> CORBAオブジェクトは、特に何もしていしなければ、生成されるたびに適当なKey (IDのようなもの)
>>> >> を持ったオブジェクトとして生成され、ネームサーバに登録されるリファレンスも、
>>> >> たとえ名前が同じであっても、生成されるたびに異なるKeyのオブジェクトとして
>>> >> 登録されます。
>>> >>
>>> >> たとえば、ConsoleIn コンポーネントを2回生成したとします。
>>> >> 1回目の生成では、以下のような参照がネームサーバに登録されます。
>>> >>
>>> >> 名前： ConsoleIn0.rtc 参照：(Key: 0x7183618368, IPアドレス： 192.168.1.10, ポート番号：3444)
>>> >>
>>> >> このプロセスを落として、もう一度起動します。次は、以下のような参照が登録されます。
>>> >>
>>> >> 名前： ConsoleIn0.rtc 参照：(Key: 0x8297427492, IPアドレス： 192.168.1.10, ポート番号：3653)
>>> >>
>>> >> 通常、複数回起動しても同じなのはIPアドレスと名前くらいで、Keyやポート番号はORBやOS
>>> >> の気分によって変わってしまいます(笑
>>> >>
>>> >> しかし、rtcdを-dオプション付きで起動すると、マネージャーはマスターマネージャ（後ほど解説します）となり、
>>> >> のKeyとポート番号が固定されます。(デフォルトでは Key は manager, ポート番号は 2810 になります。)
>>> >>
>>> >> つまり、マネージャーの名前は、以下のような参照としてネームサーバに登録されます。
>>> >>
>>> >> 名前： hsotname.host_cxt/manager.mgr 参照：(Key： manager, IPアドレス：
>>> >> 192.168.1.10, ポート番号：2810) ・・・ (1)
>>> >>
>>> >> ここで、マネージャーを強制終了すると、この名前の登録を掃除しないで終了するので、
>>> >> ネームサーバ上にこの名前がそのまま残ってしまいます。
>>> >> 次に、rtc.confでmanager.naming_formats を変更すると、
>>> >>
>>> >> 名前： hostname.host_cxt/ysuga_net.app_cxt/manager.mgr 参照：(Key： manager,
>>> >> IPアドレス： 192.168.1.10, ポート番号：2810) ・・・ (2)
>>> >>
>>> >> として、マネージャが登録されます。
>>> >>
>>> >> ここで、(1)と(2)の参照（ID、IP、ポート）を比べてみると、まったく同じになっています。
>>> >> したがって、(1)の参照にアクセスしても、(2)と同じオブジェクトにアクセスすることになります。
>>> >> そういうわけで、ゾンビ化したマネージャ(1)も、復活してしまう、というわけです。
>>> >>
>>> >>
>>> >>
>>> >> なお、マネージャをこのようにIDやポート番号を固定したわけは、ネームサーバなして
>>> >> マネージャやコンポーネントにアクセスするためです。この辺は、以前松坂さんからご意見のあった、
>>> >> ネームサーバがシステムの single point of failure になることを避ける手段として
>>> >> ネームサーバに依存しないでシステムを構築する方法を提供したかったためです。
>>> >>
>>> >> こうすることでマネージャは corbaloc:iiop:hostname:port/manager という URL で常に
>>> >> アクセスできるようになります。ここでポート番号は固定で 2810 としているので、
>>> >> ホスト名さえ分かれば、そのノードのマスタマネージャにアクセスできることになります。
>>> >>
>>> >> ちなみに、こういうオブジェクトの名前付けを INS (Interoperable Naming Service) といいます。
>>> >>
>>> >> 以下は、log出力の例ですが、マネージャのIOR(オブジェクト参照)の情報は、
>>> >>
>>> >> Feb 15 10:35:40 DEBUG: ManagerServant: Manager's IOR information:
>>> >> IOR information
>>> >> Type ID: "IDL:RTM/Manager:1.0"
>>> >> Profiles:
>>> >> 1. IIOP 1.2 192.168.100.2 2810
>>> >> Object Key: "manager" = 0x6d616e61676572 (7 bytes)
>>> >> TAG_ORB_TYPE omniORB
>>> >> TAG_CODE_SETS char native code set: ISO-8859-1
>>> >> char conversion code set: UTF-8
>>> >> wchar native code set: UTF-16
>>> >> wchar conversion code set: UTF-16
>>> >>
>>> >> このように、Object Key が "manager" という人間が読める形式になっているのに対し、
>>> >> 以下は ConsoleIn をネームサーバに登録する際のIORなのですが、
>>> >>
>>> >> IOR information
>>> >> Type ID: "IDL:openrtm.aist.go.jp/OpenRTM/DataFlowComponent:1.0"
>>> >> Profiles:
>>> >> 1. IIOP 1.2 192.168.100.2 2810
>>> >> POA(root) Object Key: "...." = 0x00000000 (4 bytes)
>>> >> Object Key: "...xK........." = 0xfe94ba784b000015080000000000 (14 bytes)
>>> >> TAG_ORB_TYPE omniORB
>>> >> TAG_CODE_SETS char native code set: ISO-8859-1
>>> >> char conversion code set: UTF-8
>>> >> wchar native code set: UTF-16
>>> >> wchar conversion code set: UTF-16
>>> >>
>>> >> Object Key が 0xfe94ba784b000015080000000000 というORB (というかPOA) が
>>> >> 適当に付けた名前になっています。
>>> >>
>>> >>
>>> >> ついでですので、マネージャの使い方についても少し説明します。
>>> >>
>>> >> マネージャにはマスタとスレーブがあります。
>>> >>
>>> >> ・マスタマネージャ：
>>> >> 原則1ノードにつき1つだけ存在する。
>>> >> アプリケーション、ノードの外部などからは、マスターマネージャに対して
>>> >> コンポーネントの生成を依頼する。
>>> >> つまり、原則として、このマネージャ自身はコンポーネントを生成・管理しない。
>>> >> 実際のコンポーネントの生成は、マスタがスレーブマネージャに依頼する。
>>> >>
>>> >> ・スレーブマネージャ：
>>> >> 1ノードに複数存在できる。0個以上のマスターに所属することができる。
>>> >> rtcdを-dなしで起動した場合、マスターがすでに起動していればその配下に入る。
>>> >> コンポーネントはスレーブマネージャ上で生成・管理される。
>>> >> 原則、コンポーネントが存在しないスレーブマネージャは存在しない（自動でシャットダウンされる）。
>>> >> -> 菅さんがご指摘されたように、-d オプションなしのrtcdが自動で終了するのはこのためです。
>>> >> マスターマネージャからは、スレーブはポート番号で区別される。
>>> >> つまり、同一ポート番号のスレーブマネージャは、同一のプロセス（逆もしかり）である。
>>> >>
>>> >> コンポーネント生成の流れは、以下のようになります。
>>> >>
>>> >> 1) RTCが起動される可能性のあるノード上では、rtcd は -d オプション付きで起動されているものとします。
>>> >> ＃Linuxではれば、/etc/init.d 以下の起動スクリプトなどで起動されているイメージ。
>>> >>
>>> >> 2) 何らかのツール、コマンド、アプリケーションが、あるノードに対してコンポーネントを作成したい場合
>>> >> まず、そのノードのマスタマネージャのオブジェクトリファレンスを取得します。
>>> >> それは、ネームサーバからでもいいですし、corbaloc:iiop:hostname:2810/manager という URL を
>>> >> ORB::string_to_object() 関数を使ってダイレクトにアクセスしてもかまいません。
>>> >>
>>> >> 3) 何らかのツール、コマンド、アプリケーションが、あるノード上で、コンポーネントを起動する場合、
>>> >> そのノードのマスターマネージャに対して create_component() をコールします。
>>> >> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234")
>>> >>
>>> >> 4) manager=localhost:2811 はローカルホスト上の 2811版ポート上で ConsoleIn という
>>> >> コンポーネントを起動しなさい、という意味なので、マスターマネージャは、スレーブマネージャを
>>> >> 2811ポート上で起動し、そのマネージャに対して、create_component("ConsoleIn?instance_name=ConsoleIn1234")
>>> >> をコールします。
>>> >>
>>> >> 5) スレーブマネージャは、ポート2811上で起動し、ConsoleInを一つ生成します。
>>> >> このとき、インスタンス名はConsoleIn1234 に指定されているのでインスタンス名はこの名前になり、
>>> >> ネームサーバ上に登録される名前も、この名前になります。
>>> >>
>>> >> 6) さらに、同じプロセス上で、ConsoleIn を起動したければ、
>>> >> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1235")
>>> >> とをマスタマネージャに対してコールすればよく、異なるプロセスで起動したい場合は、
>>> >> mgr->create_component("ConsoleIn?manager=localhost:2812&instance_name=ConsoleIn1235")
>>> >> 等とすれば、別のプロセス上でConsoleInが起動します。
>>> >>
>>> >> 7) なお、そのノード上で起動しているコンポーネントの参照は、マスターマネージャから、
>>> >> mgr->get_components() によって取得できます。
>>> >> スレーブ上で起動しているすべてのコンポーネントの参照をマスターが収集して返しています。
>>> >>
>>> >>
>>> >> 一応、1.0-RELEASEのrtcdはこのような使い方を意図して実装されています。
>>> >> まだ、ツールの方でも対応しきれていないので、この使い方が実際利用できるのには
>>> >> 少々時間がかかると思いますが、RTSystemEditorやrtcshellなどで、
>>> >> 簡単にできるようにしていきたいと思います。
>>> >> ＃rtcshellについては、ジェフさんよろしく。
>>> >>
>>> >> あと、Windows上で起動したrtcdに、RTSystemEditorのmanager viewからアクセスすると、
>>> >> 非常に重いのですが、これはDLLからRTCのプロファイルを取得する操作がWindows
>>> >> 上ではなぜだか非常に遅いために発生しています。（Linuxだと一瞬で終わるのですが。。。）
>>> >> また、OpenCVをインストールしていない場合、RTCのプロファイルを取得する過程で、
>>> >> USBcamera*コンポーネントをアクセスした段階で、DLLのエラーダイアログが出てしまい
>>> >> アクセスがさらに遅くなってしまいます。
>>> >> OpenCVをインストールするか、USBCameda*.DLLを削除するかすると改善します。
>>> >>
>>> >

Mon, 2010-02-15 17:59

(Reply to #11) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01109] Managerのnamingformatの不具合

安藤です

堀さんも指摘されていますが、
2810 は well known port ではなく regsitered port に含まれます。
http://www.iana.org/assignments/port-numbers

といっても、well known ports も registered ports も、RFC4340を見る限り
"SHOULD NOT be used without IANA registration" なので、
「登録せずに使用することは推奨しない」といったニュアンスかとおもいます。
＃MUST NOT ではないですし。
あと、well known と registerted ポートの違いは、root(もしくは特定のユーザ)
により実行されるサービスか、そうでないかの差くらいしかないようですね。

すぐにIANAに登録するというわけにもいきませんし、そもそもrtcdの枠組みが、
今後も永続的に使われるようになるのか、実験段階なのでわかりません、
したがいまして、解決策としては、以下の案はどうでしょうか？

先ほどのメールで書いたように、もしrtcdの標準ポートを
何かに決めるのであれば、2809番がそのためのポート番号として利用可能です。
(CORBA 3.1 specification formal/2008-01-07)

とりあえず、ソース上では2809をデフォルトにしました。(LERENG_1_0, r1842)
ただし、デフォルトコンフィギュレーションでは以前のままlocalhost:2810です。
rtc.conf でmanager_corba.master_manager を指定しなければ2810、
空の値もしくは無効な値を指定すると2809です。

いかがでしょうか？＞原さん、皆さま

ちなみに、
http://ja.wikipedia.org/wiki/TCP%E3%82%84UDP%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%83%9D%E3%83%BC%E3%83%88%E7%95%AA%E5%8F%B7%E3%81%AE%E4%B8%80%E8%A6%A7
未登録でも、パブリックなサービスのポートとして使用されているポートは
このようにたくさんあります。参考までに。

2010年2月15日15:56 Isao Hara :
> 安藤さん：
>
> 原です。下記の件ですが、。２８１０は、すでにWell　Known　Portです。
> そのため、前のメールを書いた次第です。
> 競合を避けるために、やはり別ポートを登録して、変更しべきだと思います。
>
> 結局、登録しないまま、別ポートにしても後で登録されて、こちらが非登録＆競合
> という状態はよくないと思います。
>
> 標準実装の１つにするんでしょう？
>
>
> 2010年2月15日15:48 Ando Noriaki :
>> 安藤です
>>
>> 2810はwell knownではないので、まぁいいんじゃないでしょうか、
>> というのが僕の考えです。
>>
>> 実は、マネージャ指定で使用する corbaloc 形式ですが、
>> corbaloc:iiop::/
>> ののデフォルトは 2809 です。(CORBAの仕様)
>> でも、たいていのCORBAではネームサーバがこのポートを使っているので、
>> 混乱を避けるために 2810 をデフォルトにしたというわけです。
>>
>> rtcdにネームサーバを内蔵してしまう、というのも解決策としてはありますね。
>> javaのorbdは、実際ネームサーバとオブジェクトサーバを兼ねているようですし。
>>
>>
>> 堀さんのおっしゃるようにポート番号を確保してそれを使うのが
>> いいかもしれませんが、rtcd自体がパブリックなサービスとして
>> 成立するかどうかもわからないので、とりあえず
>>
>> 「何も指定しないと2810番になるけど、使用する状況で適宜rtc.confで変更してください。」
>>
>> というところでどうでしょうか？
>>
>>
>> 余談ですが、Linuxでは自由に使えるポートとして
>> $ cat /proc/sys/net/ipv4/ip_local_port_range
>> 32768 61000
>>
>> つまり、327680〜61000 となっているらしいです。
>> FreeBSDとかだと、
>>> sysctl -a|grep portrange
>> :
>> net.inet.ip.portrange.last: 65535
>> net.inet.ip.portrange.first: 49152
>> :
>> なんですけどね。
>>
>>
>>
>>
>> 2010年2月15日15:14 Toshio HORI :
>>> 安藤さん, 原さん,
>>>
>>> ポート番号の1024〜49151はwell-knownではありません。registered port
>>> numbersとされています。
>>>
>>> ただ、well known portを*含めて*そのポート番号の使用は「SHOULD NOT」であっ
>>> て「MUST NOT(あるいはSHALL NOT)」ではありません。「SHOULD NOT」は「NOT
>>> RECOMMENDED」を意味するので(See RFC2119)、解釈としては安藤さんが正しい
>>> です。
>>>
>>> もちろん、今のうちからIANAに登録してポート番号を確保しておくのが一番ス
>>> マートな解だとは思います。
>>>
>>> …というメールを書いたところに原さんの次のメールが届きましたが、せっか
>>> く書いたので送ってしまいます(笑)。
>>>
>>> // 堀俊夫, 博士(工学) / t.hori@aist.go.jp
>>> // (独)産業技術総合研究所デジタルヒューマン研究センター主任研究員
>>> // & OMG Robotics-DTF Robotic Functional Service WG共同座長
>>> // Web: http://www.dh.aist.go.jp/members/toshi.php
>>>
>>> In article ,
>>> Ando Noriaki writes:
>>>> 原様
>>>>
>>>> 安藤です
>>>>
>>>> 固定というのは、デフォルトで2810番という意味で、
>>>> 変更したい場合は、rtc.conf で
>>>> corba.master_manager: localhost:49152
>>>> のように指定してください。
>>>>
>>>> ちなみに、1024〜49151 は well known ポートではないので、
>>>> 勝手に使ってはいけない、というほどの強制力はないですよね。
>>>> OpenRTMがすごく広まったら、ちゃんと登録しないとだめかもしれませんが（笑
>>>>
>>>>
>>>>
>>>>
>>>> 2010年2月15日13:23 Isao Hara :
>>>> > 安藤様、皆様：
>>>> >
>>>> > 産総研の原です。
>>>> > 下記のようにネームサーバーのポート番号が固定されているということですが、
>>>> > 2810番のように49151番より下の番号は、勝手につかってはいけません。
>>>> > IANAというところで管理しています。
>>>> > また、2810は、
>>>> > # Ted McFadden
>>>> > netsteward 2810/tcp Active Net Steward
>>>> > netsteward 2810/udp Active Net Steward
>>>> >
>>>> > のようにアプリケーションの登録がなされていますので、変更をお願いいたします。
>>>> >
>>>> > (2010/02/15 12:43), Ando Noriaki wrote:
>>>> >> 菅様、皆さま
>>>> >>
>>>> >> 安藤です
>>>> >>
>>>> >> rtcdについて、まだドキュメントを書いていないので、
>>>> >> いろいろ混乱させてしまいすみません。
>>>> >> ドキュメントはもう少々お待ちください。
>>>> >>
>>>> >>
>>>> >> 今回の件ですが、ネームサーバ上に残ったマネージャーのゾンビリファレンスが、
>>>> >> そのごrtc.confでマネージャの登録名を変えたにもかかわらず復活してしまう
>>>> >>
>>>> >> ということでよろしいでしょうか。
>>>> >>
>>>> >> これは、簡潔に言いますと、マネージャーを INS 化したためで、
>>>> >> 対処方法としては、ゾンビ化させないで、マネージャはshutdownコマンドで
>>>> >> 終了させてください、ということになります。
>>>> >>
>>>> >> 以下、長文すみません。
>>>> >>
>>>> >>
>>>> >>> さて，今回の問題ですが，追加報告です．
>>>> >>> rtcdを使って現象をいくつか試していますが，
>>>> >>> 以下の操作で再現されることがわかりました．
>>>> >>>
>>>> >>> 一言で表現すると，ゾンビーの復活です．
>>>> >>>
>>>> >>> 初回のrtcdの実行ではnaming_formatsを指定しない，
>>>> >>> 以下のrtc.confで実行．
>>>> >>>
>>>> >>> corba.nameservers: localhost
>>>> >>> naming.formats: %h.host_cxt/%n.rtc
>>>> >>> logger.enable: NO
>>>> >>> logger.log_level: PARANOID
>>>> >>> manager.modules.load_path: ../examples/C++/, ../components/
>>>> >>>
>>>> >>> その後，rtcdを無理やり停止して，ゾンビーを残す．
>>>> >>>
>>>> >>> 次にrtc.confを加工する
>>>> >>>
>>>> >>> corba.nameservers: localhost
>>>> >>> naming.formats: %h.host_cxt/%n.rtc
>>>> >>> logger.enable: NO
>>>> >>> logger.log_level: PARANOID
>>>> >>> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
>>>> >>> manager.modules.load_path: ../examples/C++/, ../components/
>>>> >>>
>>>> >>> 5行目を追加．そして実行すると，
>>>> >>> ゾンビーだったmanager.mgrが復活する．
>>>> >>> こちらからcreateを呼び出しても可能になってしまいます．
>>>> >>>
>>>> >>> 初回の起動でゾンビーがなければ意図通りに動作します．
>>>> >>> また，逆の順序で実行しても同様の現象が起こります．
>>>> >>
>>>> >>
>>>> >> 詳しく解説しますと、
>>>> >>
>>>> >> CORBAオブジェクトは、特に何もしていしなければ、生成されるたびに適当なKey (IDのようなもの)
>>>> >> を持ったオブジェクトとして生成され、ネームサーバに登録されるリファレンスも、
>>>> >> たとえ名前が同じであっても、生成されるたびに異なるKeyのオブジェクトとして
>>>> >> 登録されます。
>>>> >>
>>>> >> たとえば、ConsoleIn コンポーネントを2回生成したとします。
>>>> >> 1回目の生成では、以下のような参照がネームサーバに登録されます。
>>>> >>
>>>> >> 名前： ConsoleIn0.rtc 参照：(Key: 0x7183618368, IPアドレス： 192.168.1.10, ポート番号：3444)
>>>> >>
>>>> >> このプロセスを落として、もう一度起動します。次は、以下のような参照が登録されます。
>>>> >>
>>>> >> 名前： ConsoleIn0.rtc 参照：(Key: 0x8297427492, IPアドレス： 192.168.1.10, ポート番号：3653)
>>>> >>
>>>> >> 通常、複数回起動しても同じなのはIPアドレスと名前くらいで、Keyやポート番号はORBやOS
>>>> >> の気分によって変わってしまいます(笑
>>>> >>
>>>> >> しかし、rtcdを-dオプション付きで起動すると、マネージャーはマスターマネージャ（後ほど解説します）となり、
>>>> >> のKeyとポート番号が固定されます。(デフォルトでは Key は manager, ポート番号は 2810 になります。)
>>>> >>
>>>> >> つまり、マネージャーの名前は、以下のような参照としてネームサーバに登録されます。
>>>> >>
>>>> >> 名前： hsotname.host_cxt/manager.mgr 参照：(Key： manager, IPアドレス：
>>>> >> 192.168.1.10, ポート番号：2810) ・・・ (1)
>>>> >>
>>>> >> ここで、マネージャーを強制終了すると、この名前の登録を掃除しないで終了するので、
>>>> >> ネームサーバ上にこの名前がそのまま残ってしまいます。
>>>> >> 次に、rtc.confでmanager.naming_formats を変更すると、
>>>> >>
>>>> >> 名前： hostname.host_cxt/ysuga_net.app_cxt/manager.mgr 参照：(Key： manager,
>>>> >> IPアドレス： 192.168.1.10, ポート番号：2810) ・・・ (2)
>>>> >>
>>>> >> として、マネージャが登録されます。
>>>> >>
>>>> >> ここで、(1)と(2)の参照（ID、IP、ポート）を比べてみると、まったく同じになっています。
>>>> >> したがって、(1)の参照にアクセスしても、(2)と同じオブジェクトにアクセスすることになります。
>>>> >> そういうわけで、ゾンビ化したマネージャ(1)も、復活してしまう、というわけです。
>>>> >>
>>>> >>
>>>> >>
>>>> >> なお、マネージャをこのようにIDやポート番号を固定したわけは、ネームサーバなして
>>>> >> マネージャやコンポーネントにアクセスするためです。この辺は、以前松坂さんからご意見のあった、
>>>> >> ネームサーバがシステムの single point of failure になることを避ける手段として
>>>> >> ネームサーバに依存しないでシステムを構築する方法を提供したかったためです。
>>>> >>
>>>> >> こうすることでマネージャは corbaloc:iiop:hostname:port/manager という URL で常に
>>>> >> アクセスできるようになります。ここでポート番号は固定で 2810 としているので、
>>>> >> ホスト名さえ分かれば、そのノードのマスタマネージャにアクセスできることになります。
>>>> >>
>>>> >> ちなみに、こういうオブジェクトの名前付けを INS (Interoperable Naming Service) といいます。
>>>> >>
>>>> >> 以下は、log出力の例ですが、マネージャのIOR(オブジェクト参照)の情報は、
>>>> >>
>>>> >> Feb 15 10:35:40 DEBUG: ManagerServant: Manager's IOR information:
>>>> >> IOR information
>>>> >> Type ID: "IDL:RTM/Manager:1.0"
>>>> >> Profiles:
>>>> >> 1. IIOP 1.2 192.168.100.2 2810
>>>> >> Object Key: "manager" = 0x6d616e61676572 (7 bytes)
>>>> >> TAG_ORB_TYPE omniORB
>>>> >> TAG_CODE_SETS char native code set: ISO-8859-1
>>>> >> char conversion code set: UTF-8
>>>> >> wchar native code set: UTF-16
>>>> >> wchar conversion code set: UTF-16
>>>> >>
>>>> >> このように、Object Key が "manager" という人間が読める形式になっているのに対し、
>>>> >> 以下は ConsoleIn をネームサーバに登録する際のIORなのですが、
>>>> >>
>>>> >> IOR information
>>>> >> Type ID: "IDL:openrtm.aist.go.jp/OpenRTM/DataFlowComponent:1.0"
>>>> >> Profiles:
>>>> >> 1. IIOP 1.2 192.168.100.2 2810
>>>> >> POA(root) Object Key: "...." = 0x00000000 (4 bytes)
>>>> >> Object Key: "...xK........." = 0xfe94ba784b000015080000000000 (14 bytes)
>>>> >> TAG_ORB_TYPE omniORB
>>>> >> TAG_CODE_SETS char native code set: ISO-8859-1
>>>> >> char conversion code set: UTF-8
>>>> >> wchar native code set: UTF-16
>>>> >> wchar conversion code set: UTF-16
>>>> >>
>>>> >> Object Key が 0xfe94ba784b000015080000000000 というORB (というかPOA) が
>>>> >> 適当に付けた名前になっています。
>>>> >>
>>>> >>
>>>> >> ついでですので、マネージャの使い方についても少し説明します。
>>>> >>
>>>> >> マネージャにはマスタとスレーブがあります。
>>>> >>
>>>> >> ・マスタマネージャ：
>>>> >> 原則1ノードにつき1つだけ存在する。
>>>> >> アプリケーション、ノードの外部などからは、マスターマネージャに対して
>>>> >> コンポーネントの生成を依頼する。
>>>> >> つまり、原則として、このマネージャ自身はコンポーネントを生成・管理しない。
>>>> >> 実際のコンポーネントの生成は、マスタがスレーブマネージャに依頼する。
>>>> >>
>>>> >> ・スレーブマネージャ：
>>>> >> 1ノードに複数存在できる。0個以上のマスターに所属することができる。
>>>> >> rtcdを-dなしで起動した場合、マスターがすでに起動していればその配下に入る。
>>>> >> コンポーネントはスレーブマネージャ上で生成・管理される。
>>>> >> 原則、コンポーネントが存在しないスレーブマネージャは存在しない（自動でシャットダウンされる）。
>>>> >> -> 菅さんがご指摘されたように、-d オプションなしのrtcdが自動で終了するのはこのためです。
>>>> >> マスターマネージャからは、スレーブはポート番号で区別される。
>>>> >> つまり、同一ポート番号のスレーブマネージャは、同一のプロセス（逆もしかり）である。
>>>> >>
>>>> >> コンポーネント生成の流れは、以下のようになります。
>>>> >>
>>>> >> 1) RTCが起動される可能性のあるノード上では、rtcd は -d オプション付きで起動されているものとします。
>>>> >> ＃Linuxではれば、/etc/init.d 以下の起動スクリプトなどで起動されているイメージ。
>>>> >>
>>>> >> 2) 何らかのツール、コマンド、アプリケーションが、あるノードに対してコンポーネントを作成したい場合
>>>> >> まず、そのノードのマスタマネージャのオブジェクトリファレンスを取得します。
>>>> >> それは、ネームサーバからでもいいですし、corbaloc:iiop:hostname:2810/manager という URL を
>>>> >> ORB::string_to_object() 関数を使ってダイレクトにアクセスしてもかまいません。
>>>> >>
>>>> >> 3) 何らかのツール、コマンド、アプリケーションが、あるノード上で、コンポーネントを起動する場合、
>>>> >> そのノードのマスターマネージャに対して create_component() をコールします。
>>>> >> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234")
>>>> >>
>>>> >> 4) manager=localhost:2811 はローカルホスト上の 2811版ポート上で ConsoleIn という
>>>> >> コンポーネントを起動しなさい、という意味なので、マスターマネージャは、スレーブマネージャを
>>>> >> 2811ポート上で起動し、そのマネージャに対して、create_component("ConsoleIn?instance_name=ConsoleIn1234")
>>>> >> をコールします。
>>>> >>
>>>> >> 5) スレーブマネージャは、ポート2811上で起動し、ConsoleInを一つ生成します。
>>>> >> このとき、インスタンス名はConsoleIn1234 に指定されているのでインスタンス名はこの名前になり、
>>>> >> ネームサーバ上に登録される名前も、この名前になります。
>>>> >>
>>>> >> 6) さらに、同じプロセス上で、ConsoleIn を起動したければ、
>>>> >> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1235")
>>>> >> とをマスタマネージャに対してコールすればよく、異なるプロセスで起動したい場合は、
>>>> >> mgr->create_component("ConsoleIn?manager=localhost:2812&instance_name=ConsoleIn1235")
>>>> >> 等とすれば、別のプロセス上でConsoleInが起動します。
>>>> >>
>>>> >> 7) なお、そのノード上で起動しているコンポーネントの参照は、マスターマネージャから、
>>>> >> mgr->get_components() によって取得できます。
>>>> >> スレーブ上で起動しているすべてのコンポーネントの参照をマスターが収集して返しています。
>>>> >>
>>>> >>
>>>> >> 一応、1.0-RELEASEのrtcdはこのような使い方を意図して実装されています。
>>>> >> まだ、ツールの方でも対応しきれていないので、この使い方が実際利用できるのには
>>>> >> 少々時間がかかると思いますが、RTSystemEditorやrtcshellなどで、
>>>> >> 簡単にできるようにしていきたいと思います。
>>>> >> ＃rtcshellについては、ジェフさんよろしく。
>>>> >>
>>>> >> あと、Windows上で起動したrtcdに、RTSystemEditorのmanager viewからアクセスすると、
>>>> >> 非常に重いのですが、これはDLLからRTCのプロファイルを取得する操作がWindows
>>>> >> 上ではなぜだか非常に遅いために発生しています。（Linuxだと一瞬で終わるのですが。。。）
>>>> >> また、OpenCVをインストールしていない場合、RTCのプロファイルを取得する過程で、
>>>> >> USBcamera*コンポーネントをアクセスした段階で、DLLのエラーダイアログが出てしまい
>>>> >> アクセスがさらに遅くなってしまいます。
>>>> >> OpenCVをインストールするか、USBCameda*.DLLを削除するかすると改善します。
>>>> >>
>>>> >
>>>> >

Mon, 2010-02-15 18:48

(Reply to #12) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01110] Managerのnamingformatの不具合

安藤さん：

原です。下記の件ですが、Well-known portではなくて、registered port であることは、
知っています。（流れで書いていました。。。。）
また、Must Notであることもわかっています。ただ、２８１０がすでに登録済みであり、
このまま、２８１０を使い続けても、登録できないならば、変更した方がよいと思っていました。
現在の実装では、OmniNamesなので、CORBAのNamingServerのポートを使っている
方がよいと思います。

堀さん：
IANAに登録るすと永続的になるのでしょうか？
そうでないなら、取り合えず登録しておくのも良いかと思いますが。いかがでしょうか？

On 2010/02/15, at 17:59, Ando Noriaki wrote:

> 安藤です
>
> 堀さんも指摘されていますが、
> 2810 は well known port ではなく regsitered port に含まれます。
> http://www.iana.org/assignments/port-numbers
>
> といっても、well known ports も registered ports も、RFC4340を見る限り
> "SHOULD NOT be used without IANA registration" なので、
> 「登録せずに使用することは推奨しない」といったニュアンスかとおもいます。
> ＃MUST NOT ではないですし。
> あと、well known と registerted ポートの違いは、root(もしくは特定のユーザ)
> により実行されるサービスか、そうでないかの差くらいしかないようですね。
>
> すぐにIANAに登録するというわけにもいきませんし、そもそもrtcdの枠組みが、
> 今後も永続的に使われるようになるのか、実験段階なのでわかりません、
> したがいまして、解決策としては、以下の案はどうでしょうか？
>
> 先ほどのメールで書いたように、もしrtcdの標準ポートを
> 何かに決めるのであれば、2809番がそのためのポート番号として利用可能です。
> (CORBA 3.1 specification formal/2008-01-07)
>
> とりあえず、ソース上では2809をデフォルトにしました。(LERENG_1_0, r1842)
> ただし、デフォルトコンフィギュレーションでは以前のままlocalhost:2810です。
> rtc.conf でmanager_corba.master_manager を指定しなければ2810、
> 空の値もしくは無効な値を指定すると2809です。
>
>
> いかがでしょうか？＞原さん、皆さま
>
>
> ちなみに、
> http://ja.wikipedia.org/wiki/TCP%E3%82%84UDP%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%83%9D%E3%83%BC%E3%83%88%E7%95%AA%E5%8F%B7%E3%81%AE%E4%B8%80%E8%A6%A7
> 未登録でも、パブリックなサービスのポートとして使用されているポートは
> このようにたくさんあります。参考までに。
>
>
> 2010年2月15日15:56 Isao Hara :
>> 安藤さん：
>>
>> 原です。下記の件ですが、。２８１０は、すでにWell　Known　Portです。
>> そのため、前のメールを書いた次第です。
>> 競合を避けるために、やはり別ポートを登録して、変更しべきだと思います。
>>
>> 結局、登録しないまま、別ポートにしても後で登録されて、こちらが非登録＆競合
>> という状態はよくないと思います。
>>
>> 標準実装の１つにするんでしょう？
>>
>>
>> 2010年2月15日15:48 Ando Noriaki :
>>> 安藤です
>>>
>>> 2810はwell knownではないので、まぁいいんじゃないでしょうか、
>>> というのが僕の考えです。
>>>
>>> 実は、マネージャ指定で使用する corbaloc 形式ですが、
>>> corbaloc:iiop::/
>>> ののデフォルトは 2809 です。(CORBAの仕様)
>>> でも、たいていのCORBAではネームサーバがこのポートを使っているので、
>>> 混乱を避けるために 2810 をデフォルトにしたというわけです。
>>>
>>> rtcdにネームサーバを内蔵してしまう、というのも解決策としてはありますね。
>>> javaのorbdは、実際ネームサーバとオブジェクトサーバを兼ねているようですし。
>>>
>>>
>>> 堀さんのおっしゃるようにポート番号を確保してそれを使うのが
>>> いいかもしれませんが、rtcd自体がパブリックなサービスとして
>>> 成立するかどうかもわからないので、とりあえず
>>>
>>> 「何も指定しないと2810番になるけど、使用する状況で適宜rtc.confで変更してください。」
>>>
>>> というところでどうでしょうか？
>>>
>>>
>>> 余談ですが、Linuxでは自由に使えるポートとして
>>> $ cat /proc/sys/net/ipv4/ip_local_port_range
>>> 32768 61000
>>>
>>> つまり、327680～61000 となっているらしいです。
>>> FreeBSDとかだと、
>>>> sysctl -a|grep portrange
>>> :
>>> net.inet.ip.portrange.last: 65535
>>> net.inet.ip.portrange.first: 49152
>>> :
>>> なんですけどね。
>>>
>>>
>>>
>>>
>>> 2010年2月15日15:14 Toshio HORI :
>>>> 安藤さん, 原さん,
>>>>
>>>> ポート番号の1024～49151はwell-knownではありません。registered port
>>>> numbersとされています。
>>>>
>>>> ただ、well known portを*含めて*そのポート番号の使用は「SHOULD NOT」であっ
>>>> て「MUST NOT(あるいはSHALL NOT)」ではありません。「SHOULD NOT」は「NOT
>>>> RECOMMENDED」を意味するので(See RFC2119)、解釈としては安藤さんが正しい
>>>> です。
>>>>
>>>> もちろん、今のうちからIANAに登録してポート番号を確保しておくのが一番ス
>>>> マートな解だとは思います。
>>>>
>>>> …というメールを書いたところに原さんの次のメールが届きましたが、せっか
>>>> く書いたので送ってしまいます(笑)。
>>>>
>>>> // 堀俊夫, 博士(工学) / t.hori@aist.go.jp
>>>> // (独)産業技術総合研究所デジタルヒューマン研究センター主任研究員
>>>> // & OMG Robotics-DTF Robotic Functional Service WG共同座長
>>>> // Web: http://www.dh.aist.go.jp/members/toshi.php
>>>>
>>>> In article ,
>>>> Ando Noriaki writes:
>>>>> 原様
>>>>>
>>>>> 安藤です
>>>>>
>>>>> 固定というのは、デフォルトで2810番という意味で、
>>>>> 変更したい場合は、rtc.conf で
>>>>> corba.master_manager: localhost:49152
>>>>> のように指定してください。
>>>>>
>>>>> ちなみに、1024～49151 は well known ポートではないので、
>>>>> 勝手に使ってはいけない、というほどの強制力はないですよね。
>>>>> OpenRTMがすごく広まったら、ちゃんと登録しないとだめかもしれませんが（笑
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2010年2月15日13:23 Isao Hara :
>>>>>> 安藤様、皆様：
>>>>>>
>>>>>> 産総研の原です。
>>>>>> 下記のようにネームサーバーのポート番号が固定されているということですが、
>>>>>> 2810番のように49151番より下の番号は、勝手につかってはいけません。
>>>>>> IANAというところで管理しています。
>>>>>> また、2810は、
>>>>>> # Ted McFadden
>>>>>> netsteward 2810/tcp Active Net Steward
>>>>>> netsteward 2810/udp Active Net Steward
>>>>>>
>>>>>> のようにアプリケーションの登録がなされていますので、変更をお願いいたします。
>>>>>>
>>>>>> (2010/02/15 12:43), Ando Noriaki wrote:
>>>>>>> 菅様、皆さま
>>>>>>>
>>>>>>> 安藤です
>>>>>>>
>>>>>>> rtcdについて、まだドキュメントを書いていないので、
>>>>>>> いろいろ混乱させてしまいすみません。
>>>>>>> ドキュメントはもう少々お待ちください。
>>>>>>>
>>>>>>>
>>>>>>> 今回の件ですが、ネームサーバ上に残ったマネージャーのゾンビリファレンスが、
>>>>>>> そのごrtc.confでマネージャの登録名を変えたにもかかわらず復活してしまう
>>>>>>>
>>>>>>> ということでよろしいでしょうか。
>>>>>>>
>>>>>>> これは、簡潔に言いますと、マネージャーを INS 化したためで、
>>>>>>> 対処方法としては、ゾンビ化させないで、マネージャはshutdownコマンドで
>>>>>>> 終了させてください、ということになります。
>>>>>>>
>>>>>>> 以下、長文すみません。
>>>>>>>
>>>>>>>
>>>>>>>> さて，今回の問題ですが，追加報告です．
>>>>>>>> rtcdを使って現象をいくつか試していますが，
>>>>>>>> 以下の操作で再現されることがわかりました．
>>>>>>>>
>>>>>>>> 一言で表現すると，ゾンビーの復活です．
>>>>>>>>
>>>>>>>> 初回のrtcdの実行ではnaming_formatsを指定しない，
>>>>>>>> 以下のrtc.confで実行．
>>>>>>>>
>>>>>>>> corba.nameservers: localhost
>>>>>>>> naming.formats: %h.host_cxt/%n.rtc
>>>>>>>> logger.enable: NO
>>>>>>>> logger.log_level: PARANOID
>>>>>>>> manager.modules.load_path: ../examples/C++/, ../components/
>>>>>>>>
>>>>>>>> その後，rtcdを無理やり停止して，ゾンビーを残す．
>>>>>>>>
>>>>>>>> 次にrtc.confを加工する
>>>>>>>>
>>>>>>>> corba.nameservers: localhost
>>>>>>>> naming.formats: %h.host_cxt/%n.rtc
>>>>>>>> logger.enable: NO
>>>>>>>> logger.log_level: PARANOID
>>>>>>>> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
>>>>>>>> manager.modules.load_path: ../examples/C++/, ../components/
>>>>>>>>
>>>>>>>> 5行目を追加．そして実行すると，
>>>>>>>> ゾンビーだったmanager.mgrが復活する．
>>>>>>>> こちらからcreateを呼び出しても可能になってしまいます．
>>>>>>>>
>>>>>>>> 初回の起動でゾンビーがなければ意図通りに動作します．
>>>>>>>> また，逆の順序で実行しても同様の現象が起こります．
>>>>>>>
>>>>>>>
>>>>>>> 詳しく解説しますと、
>>>>>>>
>>>>>>> CORBAオブジェクトは、特に何もしていしなければ、生成されるたびに適当なKey (IDのようなもの)
>>>>>>> を持ったオブジェクトとして生成され、ネームサーバに登録されるリファレンスも、
>>>>>>> たとえ名前が同じであっても、生成されるたびに異なるKeyのオブジェクトとして
>>>>>>> 登録されます。
>>>>>>>
>>>>>>> たとえば、ConsoleIn コンポーネントを2回生成したとします。
>>>>>>> 1回目の生成では、以下のような参照がネームサーバに登録されます。
>>>>>>>
>>>>>>> 名前： ConsoleIn0.rtc 参照：(Key: 0x7183618368, IPアドレス： 192.168.1.10, ポート番号：3444)
>>>>>>>
>>>>>>> このプロセスを落として、もう一度起動します。次は、以下のような参照が登録されます。
>>>>>>>
>>>>>>> 名前： ConsoleIn0.rtc 参照：(Key: 0x8297427492, IPアドレス： 192.168.1.10, ポート番号：3653)
>>>>>>>
>>>>>>> 通常、複数回起動しても同じなのはIPアドレスと名前くらいで、Keyやポート番号はORBやOS
>>>>>>> の気分によって変わってしまいます(笑
>>>>>>>
>>>>>>> しかし、rtcdを-dオプション付きで起動すると、マネージャーはマスターマネージャ（後ほど解説します）となり、
>>>>>>> のKeyとポート番号が固定されます。(デフォルトでは Key は manager, ポート番号は 2810 になります。)
>>>>>>>
>>>>>>> つまり、マネージャーの名前は、以下のような参照としてネームサーバに登録されます。
>>>>>>>
>>>>>>> 名前： hsotname.host_cxt/manager.mgr 参照：(Key： manager, IPアドレス：
>>>>>>> 192.168.1.10, ポート番号：2810) ・・・ (1)
>>>>>>>
>>>>>>> ここで、マネージャーを強制終了すると、この名前の登録を掃除しないで終了するので、
>>>>>>> ネームサーバ上にこの名前がそのまま残ってしまいます。
>>>>>>> 次に、rtc.confでmanager.naming_formats を変更すると、
>>>>>>>
>>>>>>> 名前： hostname.host_cxt/ysuga_net.app_cxt/manager.mgr 参照：(Key： manager,
>>>>>>> IPアドレス： 192.168.1.10, ポート番号：2810) ・・・ (2)
>>>>>>>
>>>>>>> として、マネージャが登録されます。
>>>>>>>
>>>>>>> ここで、(1)と(2)の参照（ID、IP、ポート）を比べてみると、まったく同じになっています。
>>>>>>> したがって、(1)の参照にアクセスしても、(2)と同じオブジェクトにアクセスすることになります。
>>>>>>> そういうわけで、ゾンビ化したマネージャ(1)も、復活してしまう、というわけです。
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> なお、マネージャをこのようにIDやポート番号を固定したわけは、ネームサーバなして
>>>>>>> マネージャやコンポーネントにアクセスするためです。この辺は、以前松坂さんからご意見のあった、
>>>>>>> ネームサーバがシステムの single point of failure になることを避ける手段として
>>>>>>> ネームサーバに依存しないでシステムを構築する方法を提供したかったためです。
>>>>>>>
>>>>>>> こうすることでマネージャは corbaloc:iiop:hostname:port/manager という URL で常に
>>>>>>> アクセスできるようになります。ここでポート番号は固定で 2810 としているので、
>>>>>>> ホスト名さえ分かれば、そのノードのマスタマネージャにアクセスできることになります。
>>>>>>>
>>>>>>> ちなみに、こういうオブジェクトの名前付けを INS (Interoperable Naming Service) といいます。
>>>>>>>
>>>>>>> 以下は、log出力の例ですが、マネージャのIOR(オブジェクト参照)の情報は、
>>>>>>>
>>>>>>> Feb 15 10:35:40 DEBUG: ManagerServant: Manager's IOR information:
>>>>>>> IOR information
>>>>>>> Type ID: "IDL:RTM/Manager:1.0"
>>>>>>> Profiles:
>>>>>>> 1. IIOP 1.2 192.168.100.2 2810
>>>>>>> Object Key: "manager" = 0x6d616e61676572 (7 bytes)
>>>>>>> TAG_ORB_TYPE omniORB
>>>>>>> TAG_CODE_SETS char native code set: ISO-8859-1
>>>>>>> char conversion code set: UTF-8
>>>>>>> wchar native code set: UTF-16
>>>>>>> wchar conversion code set: UTF-16
>>>>>>>
>>>>>>> このように、Object Key が "manager" という人間が読める形式になっているのに対し、
>>>>>>> 以下は ConsoleIn をネームサーバに登録する際のIORなのですが、
>>>>>>>
>>>>>>> IOR information
>>>>>>> Type ID: "IDL:openrtm.aist.go.jp/OpenRTM/DataFlowComponent:1.0"
>>>>>>> Profiles:
>>>>>>> 1. IIOP 1.2 192.168.100.2 2810
>>>>>>> POA(root) Object Key: "...." = 0x00000000 (4 bytes)
>>>>>>> Object Key: "...xK........." = 0xfe94ba784b000015080000000000 (14 bytes)
>>>>>>> TAG_ORB_TYPE omniORB
>>>>>>> TAG_CODE_SETS char native code set: ISO-8859-1
>>>>>>> char conversion code set: UTF-8
>>>>>>> wchar native code set: UTF-16
>>>>>>> wchar conversion code set: UTF-16
>>>>>>>
>>>>>>> Object Key が 0xfe94ba784b000015080000000000 というORB (というかPOA) が
>>>>>>> 適当に付けた名前になっています。
>>>>>>>
>>>>>>>
>>>>>>> ついでですので、マネージャの使い方についても少し説明します。
>>>>>>>
>>>>>>> マネージャにはマスタとスレーブがあります。
>>>>>>>
>>>>>>> ・マスタマネージャ：
>>>>>>> 原則1ノードにつき1つだけ存在する。
>>>>>>> アプリケーション、ノードの外部などからは、マスターマネージャに対して
>>>>>>> コンポーネントの生成を依頼する。
>>>>>>> つまり、原則として、このマネージャ自身はコンポーネントを生成・管理しない。
>>>>>>> 実際のコンポーネントの生成は、マスタがスレーブマネージャに依頼する。
>>>>>>>
>>>>>>> ・スレーブマネージャ：
>>>>>>> 1ノードに複数存在できる。0個以上のマスターに所属することができる。
>>>>>>> rtcdを-dなしで起動した場合、マスターがすでに起動していればその配下に入る。
>>>>>>> コンポーネントはスレーブマネージャ上で生成・管理される。
>>>>>>> 原則、コンポーネントが存在しないスレーブマネージャは存在しない（自動でシャットダウンされる）。
>>>>>>> -> 菅さんがご指摘されたように、-d オプションなしのrtcdが自動で終了するのはこのためです。
>>>>>>> マスターマネージャからは、スレーブはポート番号で区別される。
>>>>>>> つまり、同一ポート番号のスレーブマネージャは、同一のプロセス（逆もしかり）である。
>>>>>>>
>>>>>>> コンポーネント生成の流れは、以下のようになります。
>>>>>>>
>>>>>>> 1) RTCが起動される可能性のあるノード上では、rtcd は -d オプション付きで起動されているものとします。
>>>>>>> ＃Linuxではれば、/etc/init.d 以下の起動スクリプトなどで起動されているイメージ。
>>>>>>>
>>>>>>> 2) 何らかのツール、コマンド、アプリケーションが、あるノードに対してコンポーネントを作成したい場合
>>>>>>> まず、そのノードのマスタマネージャのオブジェクトリファレンスを取得します。
>>>>>>> それは、ネームサーバからでもいいですし、corbaloc:iiop:hostname:2810/manager という URL を
>>>>>>> ORB::string_to_object() 関数を使ってダイレクトにアクセスしてもかまいません。
>>>>>>>
>>>>>>> 3) 何らかのツール、コマンド、アプリケーションが、あるノード上で、コンポーネントを起動する場合、
>>>>>>> そのノードのマスターマネージャに対して create_component() をコールします。
>>>>>>> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234")
>>>>>>>
>>>>>>> 4) manager=localhost:2811 はローカルホスト上の 2811版ポート上で ConsoleIn という
>>>>>>> コンポーネントを起動しなさい、という意味なので、マスターマネージャは、スレーブマネージャを
>>>>>>> 2811ポート上で起動し、そのマネージャに対して、create_component("ConsoleIn?instance_name=ConsoleIn1234")
>>>>>>> をコールします。
>>>>>>>
>>>>>>> 5) スレーブマネージャは、ポート2811上で起動し、ConsoleInを一つ生成します。
>>>>>>> このとき、インスタンス名はConsoleIn1234 に指定されているのでインスタンス名はこの名前になり、
>>>>>>> ネームサーバ上に登録される名前も、この名前になります。
>>>>>>>
>>>>>>> 6) さらに、同じプロセス上で、ConsoleIn を起動したければ、
>>>>>>> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1235")
>>>>>>> とをマスタマネージャに対してコールすればよく、異なるプロセスで起動したい場合は、
>>>>>>> mgr->create_component("ConsoleIn?manager=localhost:2812&instance_name=ConsoleIn1235")
>>>>>>> 等とすれば、別のプロセス上でConsoleInが起動します。
>>>>>>>
>>>>>>> 7) なお、そのノード上で起動しているコンポーネントの参照は、マスターマネージャから、
>>>>>>> mgr->get_components() によって取得できます。
>>>>>>> スレーブ上で起動しているすべてのコンポーネントの参照をマスターが収集して返しています。
>>>>>>>
>>>>>>>
>>>>>>> 一応、1.0-RELEASEのrtcdはこのような使い方を意図して実装されています。
>>>>>>> まだ、ツールの方でも対応しきれていないので、この使い方が実際利用できるのには
>>>>>>> 少々時間がかかると思いますが、RTSystemEditorやrtcshellなどで、
>>>>>>> 簡単にできるようにしていきたいと思います。
>>>>>>> ＃rtcshellについては、ジェフさんよろしく。
>>>>>>>
>>>>>>> あと、Windows上で起動したrtcdに、RTSystemEditorのmanager viewからアクセスすると、
>>>>>>> 非常に重いのですが、これはDLLからRTCのプロファイルを取得する操作がWindows
>>>>>>> 上ではなぜだか非常に遅いために発生しています。（Linuxだと一瞬で終わるのですが。。。）
>>>>>>> また、OpenCVをインストールしていない場合、RTCのプロファイルを取得する過程で、
>>>>>>> USBcamera*コンポーネントをアクセスした段階で、DLLのエラーダイアログが出てしまい
>>>>>>> アクセスがさらに遅くなってしまいます。
>>>>>>> OpenCVをインストールするか、USBCameda*.DLLを削除するかすると改善します。
>>>>>>>
>>>>>>
>>>>>>

Mon, 2010-02-15 19:48

(Reply to #13) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01111] Managerのnamingformatの不具合

原さん, 安藤さん,

# なぜ僕に聞く(苦笑)。

ポート番号は
http://www.iana.org/cgi-bin/usr-port-number.pl
から登録申請できるようですね。承認されればおそらく永続性は確保できるの
ではないかと思いますが…詳細は不明です。

In article ,
原功 writes:
> 安藤さん：
>
> 原です。下記の件ですが、Well-known portではなくて、registered port であることは、
> 知っています。（流れで書いていました。。。。）
> また、Must Notであることもわかっています。ただ、２８１０がすでに登録済みであり、
> このまま、２８１０を使い続けても、登録できないならば、変更した方がよいと思っていました。
> 現在の実装では、OmniNamesなので、CORBAのNamingServerのポートを使っている
> 方がよいと思います。
>
> 堀さん：
> IANAに登録るすと永続的になるのでしょうか？
> そうでないなら、取り合えず登録しておくのも良いかと思いますが。いかがでしょうか？
>
> On 2010/02/15, at 17:59, Ando Noriaki wrote:
>
> > 安藤です
> >
> > 堀さんも指摘されていますが、
> > 2810 は well known port ではなく regsitered port に含まれます。
> > http://www.iana.org/assignments/port-numbers
> >
> > といっても、well known ports も registered ports も、RFC4340を見る限り
> > "SHOULD NOT be used without IANA registration" なので、
> > 「登録せずに使用することは推奨しない」といったニュアンスかとおもいます。
> > ＃MUST NOT ではないですし。
> > あと、well known と registerted ポートの違いは、root(もしくは特定のユーザ)
> > により実行されるサービスか、そうでないかの差くらいしかないようですね。
> >
> > すぐにIANAに登録するというわけにもいきませんし、そもそもrtcdの枠組みが、
> > 今後も永続的に使われるようになるのか、実験段階なのでわかりません、
> > したがいまして、解決策としては、以下の案はどうでしょうか？
> >
> > 先ほどのメールで書いたように、もしrtcdの標準ポートを
> > 何かに決めるのであれば、2809番がそのためのポート番号として利用可能です。
> > (CORBA 3.1 specification formal/2008-01-07)
> >
> > とりあえず、ソース上では2809をデフォルトにしました。(LERENG_1_0, r1842)
> > ただし、デフォルトコンフィギュレーションでは以前のままlocalhost:2810です。
> > rtc.conf でmanager_corba.master_manager を指定しなければ2810、
> > 空の値もしくは無効な値を指定すると2809です。
> >
> >
> > いかがでしょうか？＞原さん、皆さま
> >
> >
> > ちなみに、
> > http://ja.wikipedia.org/wiki/TCP%E3%82%84UDP%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%83%9D%E3%83%BC%E3%83%88%E7%95%AA%E5%8F%B7%E3%81%AE%E4%B8%80%E8%A6%A7
> > 未登録でも、パブリックなサービスのポートとして使用されているポートは
> > このようにたくさんあります。参考までに。
> >
> >
> > 2010年2月15日15:56 Isao Hara :
> >> 安藤さん：
> >>
> >> 原です。下記の件ですが、。２８１０は、すでにWell　Known　Portです。
> >> そのため、前のメールを書いた次第です。
> >> 競合を避けるために、やはり別ポートを登録して、変更しべきだと思います。
> >>
> >> 結局、登録しないまま、別ポートにしても後で登録されて、こちらが非登録＆競合
> >> という状態はよくないと思います。
> >>
> >> 標準実装の１つにするんでしょう？
> >>
> >>
> >> 2010年2月15日15:48 Ando Noriaki :
> >>> 安藤です
> >>>
> >>> 2810はwell knownではないので、まぁいいんじゃないでしょうか、
> >>> というのが僕の考えです。
> >>>
> >>> 実は、マネージャ指定で使用する corbaloc 形式ですが、
> >>> corbaloc:iiop::/
> >>> ののデフォルトは 2809 です。(CORBAの仕様)
> >>> でも、たいていのCORBAではネームサーバがこのポートを使っているので、
> >>> 混乱を避けるために 2810 をデフォルトにしたというわけです。
> >>>
> >>> rtcdにネームサーバを内蔵してしまう、というのも解決策としてはありますね。
> >>> javaのorbdは、実際ネームサーバとオブジェクトサーバを兼ねているようですし。
> >>>
> >>>
> >>> 堀さんのおっしゃるようにポート番号を確保してそれを使うのが
> >>> いいかもしれませんが、rtcd自体がパブリックなサービスとして
> >>> 成立するかどうかもわからないので、とりあえず
> >>>
> >>> 「何も指定しないと2810番になるけど、使用する状況で適宜rtc.confで変更してください。」
> >>>
> >>> というところでどうでしょうか？
> >>>
> >>>
> >>> 余談ですが、Linuxでは自由に使えるポートとして
> >>> $ cat /proc/sys/net/ipv4/ip_local_port_range
> >>> 32768 61000
> >>>
> >>> つまり、327680～61000 となっているらしいです。
> >>> FreeBSDとかだと、
> >>>> sysctl -a|grep portrange
> >>> :
> >>> net.inet.ip.portrange.last: 65535
> >>> net.inet.ip.portrange.first: 49152
> >>> :
> >>> なんですけどね。
> >>>
> >>>
> >>>
> >>>
> >>> 2010年2月15日15:14 Toshio HORI :
> >>>> 安藤さん, 原さん,
> >>>>
> >>>> ポート番号の1024～49151はwell-knownではありません。registered port
> >>>> numbersとされています。
> >>>>
> >>>> ただ、well known portを*含めて*そのポート番号の使用は「SHOULD NOT」であっ
> >>>> て「MUST NOT(あるいはSHALL NOT)」ではありません。「SHOULD NOT」は「NOT
> >>>> RECOMMENDED」を意味するので(See RFC2119)、解釈としては安藤さんが正しい
> >>>> です。
> >>>>
> >>>> もちろん、今のうちからIANAに登録してポート番号を確保しておくのが一番ス
> >>>> マートな解だとは思います。
> >>>>
> >>>> …というメールを書いたところに原さんの次のメールが届きましたが、せっか
> >>>> く書いたので送ってしまいます(笑)。
> >>>>
> >>>> // 堀俊夫, 博士(工学) / t.hori@aist.go.jp
> >>>> // (独)産業技術総合研究所デジタルヒューマン研究センター主任研究員
> >>>> // & OMG Robotics-DTF Robotic Functional Service WG共同座長
> >>>> // Web: http://www.dh.aist.go.jp/members/toshi.php
> >>>>
> >>>> In article ,
> >>>> Ando Noriaki writes:
> >>>>> 原様
> >>>>>
> >>>>> 安藤です
> >>>>>
> >>>>> 固定というのは、デフォルトで2810番という意味で、
> >>>>> 変更したい場合は、rtc.conf で
> >>>>> corba.master_manager: localhost:49152
> >>>>> のように指定してください。
> >>>>>
> >>>>> ちなみに、1024～49151 は well known ポートではないので、
> >>>>> 勝手に使ってはいけない、というほどの強制力はないですよね。
> >>>>> OpenRTMがすごく広まったら、ちゃんと登録しないとだめかもしれませんが（笑
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2010年2月15日13:23 Isao Hara :
> >>>>>> 安藤様、皆様：
> >>>>>>
> >>>>>> 産総研の原です。
> >>>>>> 下記のようにネームサーバーのポート番号が固定されているということですが、
> >>>>>> 2810番のように49151番より下の番号は、勝手につかってはいけません。
> >>>>>> IANAというところで管理しています。
> >>>>>> また、2810は、
> >>>>>> # Ted McFadden
> >>>>>> netsteward 2810/tcp Active Net Steward
> >>>>>> netsteward 2810/udp Active Net Steward
> >>>>>>
> >>>>>> のようにアプリケーションの登録がなされていますので、変更をお願いいたします。
> >>>>>>
> >>>>>> (2010/02/15 12:43), Ando Noriaki wrote:
> >>>>>>> 菅様、皆さま
> >>>>>>>
> >>>>>>> 安藤です
> >>>>>>>
> >>>>>>> rtcdについて、まだドキュメントを書いていないので、
> >>>>>>> いろいろ混乱させてしまいすみません。
> >>>>>>> ドキュメントはもう少々お待ちください。
> >>>>>>>
> >>>>>>>
> >>>>>>> 今回の件ですが、ネームサーバ上に残ったマネージャーのゾンビリファレンスが、
> >>>>>>> そのごrtc.confでマネージャの登録名を変えたにもかかわらず復活してしまう
> >>>>>>>
> >>>>>>> ということでよろしいでしょうか。
> >>>>>>>
> >>>>>>> これは、簡潔に言いますと、マネージャーを INS 化したためで、
> >>>>>>> 対処方法としては、ゾンビ化させないで、マネージャはshutdownコマンドで
> >>>>>>> 終了させてください、ということになります。
> >>>>>>>
> >>>>>>> 以下、長文すみません。
> >>>>>>>
> >>>>>>>
> >>>>>>>> さて，今回の問題ですが，追加報告です．
> >>>>>>>> rtcdを使って現象をいくつか試していますが，
> >>>>>>>> 以下の操作で再現されることがわかりました．
> >>>>>>>>
> >>>>>>>> 一言で表現すると，ゾンビーの復活です．
> >>>>>>>>
> >>>>>>>> 初回のrtcdの実行ではnaming_formatsを指定しない，
> >>>>>>>> 以下のrtc.confで実行．
> >>>>>>>>
> >>>>>>>> corba.nameservers: localhost
> >>>>>>>> naming.formats: %h.host_cxt/%n.rtc
> >>>>>>>> logger.enable: NO
> >>>>>>>> logger.log_level: PARANOID
> >>>>>>>> manager.modules.load_path: ../examples/C++/, ../components/
> >>>>>>>>
> >>>>>>>> その後，rtcdを無理やり停止して，ゾンビーを残す．
> >>>>>>>>
> >>>>>>>> 次にrtc.confを加工する
> >>>>>>>>
> >>>>>>>> corba.nameservers: localhost
> >>>>>>>> naming.formats: %h.host_cxt/%n.rtc
> >>>>>>>> logger.enable: NO
> >>>>>>>> logger.log_level: PARANOID
> >>>>>>>> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
> >>>>>>>> manager.modules.load_path: ../examples/C++/, ../components/
> >>>>>>>>
> >>>>>>>> 5行目を追加．そして実行すると，
> >>>>>>>> ゾンビーだったmanager.mgrが復活する．
> >>>>>>>> こちらからcreateを呼び出しても可能になってしまいます．
> >>>>>>>>
> >>>>>>>> 初回の起動でゾンビーがなければ意図通りに動作します．
> >>>>>>>> また，逆の順序で実行しても同様の現象が起こります．
> >>>>>>>
> >>>>>>>
> >>>>>>> 詳しく解説しますと、
> >>>>>>>
> >>>>>>> CORBAオブジェクトは、特に何もしていしなければ、生成されるたびに適当なKey (IDのようなもの)
> >>>>>>> を持ったオブジェクトとして生成され、ネームサーバに登録されるリファレンスも、
> >>>>>>> たとえ名前が同じであっても、生成されるたびに異なるKeyのオブジェクトとして
> >>>>>>> 登録されます。
> >>>>>>>
> >>>>>>> たとえば、ConsoleIn コンポーネントを2回生成したとします。
> >>>>>>> 1回目の生成では、以下のような参照がネームサーバに登録されます。
> >>>>>>>
> >>>>>>> 名前： ConsoleIn0.rtc 参照：(Key: 0x7183618368, IPアドレス： 192.168.1.10, ポート番号：3444)
> >>>>>>>
> >>>>>>> このプロセスを落として、もう一度起動します。次は、以下のような参照が登録されます。
> >>>>>>>
> >>>>>>> 名前： ConsoleIn0.rtc 参照：(Key: 0x8297427492, IPアドレス： 192.168.1.10, ポート番号：3653)
> >>>>>>>
> >>>>>>> 通常、複数回起動しても同じなのはIPアドレスと名前くらいで、Keyやポート番号はORBやOS
> >>>>>>> の気分によって変わってしまいます(笑
> >>>>>>>
> >>>>>>> しかし、rtcdを-dオプション付きで起動すると、マネージャーはマスターマネージャ（後ほど解説します）となり、
> >>>>>>> のKeyとポート番号が固定されます。(デフォルトでは Key は manager, ポート番号は 2810 になります。)
> >>>>>>>
> >>>>>>> つまり、マネージャーの名前は、以下のような参照としてネームサーバに登録されます。
> >>>>>>>
> >>>>>>> 名前： hsotname.host_cxt/manager.mgr 参照：(Key： manager, IPアドレス：
> >>>>>>> 192.168.1.10, ポート番号：2810) ・・・ (1)
> >>>>>>>
> >>>>>>> ここで、マネージャーを強制終了すると、この名前の登録を掃除しないで終了するので、
> >>>>>>> ネームサーバ上にこの名前がそのまま残ってしまいます。
> >>>>>>> 次に、rtc.confでmanager.naming_formats を変更すると、
> >>>>>>>
> >>>>>>> 名前： hostname.host_cxt/ysuga_net.app_cxt/manager.mgr 参照：(Key： manager,
> >>>>>>> IPアドレス： 192.168.1.10, ポート番号：2810) ・・・ (2)
> >>>>>>>
> >>>>>>> として、マネージャが登録されます。
> >>>>>>>
> >>>>>>> ここで、(1)と(2)の参照（ID、IP、ポート）を比べてみると、まったく同じになっています。
> >>>>>>> したがって、(1)の参照にアクセスしても、(2)と同じオブジェクトにアクセスすることになります。
> >>>>>>> そういうわけで、ゾンビ化したマネージャ(1)も、復活してしまう、というわけです。
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> なお、マネージャをこのようにIDやポート番号を固定したわけは、ネームサーバなして
> >>>>>>> マネージャやコンポーネントにアクセスするためです。この辺は、以前松坂さんからご意見のあった、
> >>>>>>> ネームサーバがシステムの single point of failure になることを避ける手段として
> >>>>>>> ネームサーバに依存しないでシステムを構築する方法を提供したかったためです。
> >>>>>>>
> >>>>>>> こうすることでマネージャは corbaloc:iiop:hostname:port/manager という URL で常に
> >>>>>>> アクセスできるようになります。ここでポート番号は固定で 2810 としているので、
> >>>>>>> ホスト名さえ分かれば、そのノードのマスタマネージャにアクセスできることになります。
> >>>>>>>
> >>>>>>> ちなみに、こういうオブジェクトの名前付けを INS (Interoperable Naming Service) といいます。
> >>>>>>>
> >>>>>>> 以下は、log出力の例ですが、マネージャのIOR(オブジェクト参照)の情報は、
> >>>>>>>
> >>>>>>> Feb 15 10:35:40 DEBUG: ManagerServant: Manager's IOR information:
> >>>>>>> IOR information
> >>>>>>> Type ID: "IDL:RTM/Manager:1.0"
> >>>>>>> Profiles:
> >>>>>>> 1. IIOP 1.2 192.168.100.2 2810
> >>>>>>> Object Key: "manager" = 0x6d616e61676572 (7 bytes)
> >>>>>>> TAG_ORB_TYPE omniORB
> >>>>>>> TAG_CODE_SETS char native code set: ISO-8859-1
> >>>>>>> char conversion code set: UTF-8
> >>>>>>> wchar native code set: UTF-16
> >>>>>>> wchar conversion code set: UTF-16
> >>>>>>>
> >>>>>>> このように、Object Key が "manager" という人間が読める形式になっているのに対し、
> >>>>>>> 以下は ConsoleIn をネームサーバに登録する際のIORなのですが、
> >>>>>>>
> >>>>>>> IOR information
> >>>>>>> Type ID: "IDL:openrtm.aist.go.jp/OpenRTM/DataFlowComponent:1.0"
> >>>>>>> Profiles:
> >>>>>>> 1. IIOP 1.2 192.168.100.2 2810
> >>>>>>> POA(root) Object Key: "...." = 0x00000000 (4 bytes)
> >>>>>>> Object Key: "...xK........." = 0xfe94ba784b000015080000000000 (14 bytes)
> >>>>>>> TAG_ORB_TYPE omniORB
> >>>>>>> TAG_CODE_SETS char native code set: ISO-8859-1
> >>>>>>> char conversion code set: UTF-8
> >>>>>>> wchar native code set: UTF-16
> >>>>>>> wchar conversion code set: UTF-16
> >>>>>>>
> >>>>>>> Object Key が 0xfe94ba784b000015080000000000 というORB (というかPOA) が
> >>>>>>> 適当に付けた名前になっています。
> >>>>>>>
> >>>>>>>
> >>>>>>> ついでですので、マネージャの使い方についても少し説明します。
> >>>>>>>
> >>>>>>> マネージャにはマスタとスレーブがあります。
> >>>>>>>
> >>>>>>> ・マスタマネージャ：
> >>>>>>> 原則1ノードにつき1つだけ存在する。
> >>>>>>> アプリケーション、ノードの外部などからは、マスターマネージャに対して
> >>>>>>> コンポーネントの生成を依頼する。
> >>>>>>> つまり、原則として、このマネージャ自身はコンポーネントを生成・管理しない。
> >>>>>>> 実際のコンポーネントの生成は、マスタがスレーブマネージャに依頼する。
> >>>>>>>
> >>>>>>> ・スレーブマネージャ：
> >>>>>>> 1ノードに複数存在できる。0個以上のマスターに所属することができる。
> >>>>>>> rtcdを-dなしで起動した場合、マスターがすでに起動していればその配下に入る。
> >>>>>>> コンポーネントはスレーブマネージャ上で生成・管理される。
> >>>>>>> 原則、コンポーネントが存在しないスレーブマネージャは存在しない（自動でシャットダウンされる）。
> >>>>>>> -> 菅さんがご指摘されたように、-d オプションなしのrtcdが自動で終了するのはこのためです。
> >>>>>>> マスターマネージャからは、スレーブはポート番号で区別される。
> >>>>>>> つまり、同一ポート番号のスレーブマネージャは、同一のプロセス（逆もしかり）である。
> >>>>>>>
> >>>>>>> コンポーネント生成の流れは、以下のようになります。
> >>>>>>>
> >>>>>>> 1) RTCが起動される可能性のあるノード上では、rtcd は -d オプション付きで起動されているものとします。
> >>>>>>> ＃Linuxではれば、/etc/init.d 以下の起動スクリプトなどで起動されているイメージ。
> >>>>>>>
> >>>>>>> 2) 何らかのツール、コマンド、アプリケーションが、あるノードに対してコンポーネントを作成したい場合
> >>>>>>> まず、そのノードのマスタマネージャのオブジェクトリファレンスを取得します。
> >>>>>>> それは、ネームサーバからでもいいですし、corbaloc:iiop:hostname:2810/manager という URL を
> >>>>>>> ORB::string_to_object() 関数を使ってダイレクトにアクセスしてもかまいません。
> >>>>>>>
> >>>>>>> 3) 何らかのツール、コマンド、アプリケーションが、あるノード上で、コンポーネントを起動する場合、
> >>>>>>> そのノードのマスターマネージャに対して create_component() をコールします。
> >>>>>>> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234")
> >>>>>>>
> >>>>>>> 4) manager=localhost:2811 はローカルホスト上の 2811版ポート上で ConsoleIn という
> >>>>>>> コンポーネントを起動しなさい、という意味なので、マスターマネージャは、スレーブマネージャを
> >>>>>>> 2811ポート上で起動し、そのマネージャに対して、create_component("ConsoleIn?instance_name=ConsoleIn1234")
> >>>>>>> をコールします。
> >>>>>>>
> >>>>>>> 5) スレーブマネージャは、ポート2811上で起動し、ConsoleInを一つ生成します。
> >>>>>>> このとき、インスタンス名はConsoleIn1234 に指定されているのでインスタンス名はこの名前になり、
> >>>>>>> ネームサーバ上に登録される名前も、この名前になります。
> >>>>>>>
> >>>>>>> 6) さらに、同じプロセス上で、ConsoleIn を起動したければ、
> >>>>>>> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1235")
> >>>>>>> とをマスタマネージャに対してコールすればよく、異なるプロセスで起動したい場合は、
> >>>>>>> mgr->create_component("ConsoleIn?manager=localhost:2812&instance_name=ConsoleIn1235")
> >>>>>>> 等とすれば、別のプロセス上でConsoleInが起動します。
> >>>>>>>
> >>>>>>> 7) なお、そのノード上で起動しているコンポーネントの参照は、マスターマネージャから、
> >>>>>>> mgr->get_components() によって取得できます。
> >>>>>>> スレーブ上で起動しているすべてのコンポーネントの参照をマスターが収集して返しています。
> >>>>>>>
> >>>>>>>
> >>>>>>> 一応、1.0-RELEASEのrtcdはこのような使い方を意図して実装されています。
> >>>>>>> まだ、ツールの方でも対応しきれていないので、この使い方が実際利用できるのには
> >>>>>>> 少々時間がかかると思いますが、RTSystemEditorやrtcshellなどで、
> >>>>>>> 簡単にできるようにしていきたいと思います。
> >>>>>>> ＃rtcshellについては、ジェフさんよろしく。
> >>>>>>>
> >>>>>>> あと、Windows上で起動したrtcdに、RTSystemEditorのmanager viewからアクセスすると、
> >>>>>>> 非常に重いのですが、これはDLLからRTCのプロファイルを取得する操作がWindows
> >>>>>>> 上ではなぜだか非常に遅いために発生しています。（Linuxだと一瞬で終わるのですが。。。）
> >>>>>>> また、OpenCVをインストールしていない場合、RTCのプロファイルを取得する過程で、
> >>>>>>> USBcamera*コンポーネントをアクセスした段階で、DLLのエラーダイアログが出てしまい
> >>>>>>> アクセスがさらに遅くなってしまいます。
> >>>>>>> OpenCVをインストールするか、USBCameda*.DLLを削除するかすると改善します。
> >>>>>>>
> >>>>>>

Mon, 2010-02-15 20:09

(Reply to #14) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01112] Managerのnamingformatの不具合

堀さん：

原です。堀さんが一番詳しいかと思いまして。。。。
永続になるのでしたら、変更は難しそうですね。
しかし、この際決めてしまって、申請してはいかがでしょうか？
OpenRTMのコミュニティが大きくなりすぎると（既になっていないといけないのですが）
変更は難しいと思います。
少なくとも、登録済みのポートは、避けてはいかがでしょうか？
（2809を使い続ければ、CORBAのNamingServiceだと分かる人は分かると思いますが）

On 2010/02/15, at 19:48, Toshio HORI wrote:

> 原さん, 安藤さん,
>
> # なぜ僕に聞く(苦笑)。
>
> ポート番号は
> http://www.iana.org/cgi-bin/usr-port-number.pl
> から登録申請できるようですね。承認されればおそらく永続性は確保できるの
> ではないかと思いますが…詳細は不明です。
>
> // 堀俊夫, 博士(工学) / t.hori@aist.go.jp
> // (独)産業技術総合研究所デジタルヒューマン研究センター主任研究員
> // & OMG Robotics-DTF Robotic Functional Service WG共同座長
> // Web: http://www.dh.aist.go.jp/members/toshi.php
>
> In article ,
> 原功 writes:
>> 安藤さん：
>>
>> 原です。下記の件ですが、Well-known portではなくて、registered port であることは、
>> 知っています。（流れで書いていました。。。。）
>> また、Must Notであることもわかっています。ただ、２８１０がすでに登録済みであり、
>> このまま、２８１０を使い続けても、登録できないならば、変更した方がよいと思っていました。
>> 現在の実装では、OmniNamesなので、CORBAのNamingServerのポートを使っている
>> 方がよいと思います。
>>
>> 堀さん：
>> IANAに登録るすと永続的になるのでしょうか？
>> そうでないなら、取り合えず登録しておくのも良いかと思いますが。いかがでしょうか？
>>
>> On 2010/02/15, at 17:59, Ando Noriaki wrote:
>>
>>> 安藤です
>>>
>>> 堀さんも指摘されていますが、
>>> 2810 は well known port ではなく regsitered port に含まれます。
>>> http://www.iana.org/assignments/port-numbers
>>>
>>> といっても、well known ports も registered ports も、RFC4340を見る限り
>>> "SHOULD NOT be used without IANA registration" なので、
>>> 「登録せずに使用することは推奨しない」といったニュアンスかとおもいます。
>>> ＃MUST NOT ではないですし。
>>> あと、well known と registerted ポートの違いは、root(もしくは特定のユーザ)
>>> により実行されるサービスか、そうでないかの差くらいしかないようですね。
>>>
>>> すぐにIANAに登録するというわけにもいきませんし、そもそもrtcdの枠組みが、
>>> 今後も永続的に使われるようになるのか、実験段階なのでわかりません、
>>> したがいまして、解決策としては、以下の案はどうでしょうか？
>>>
>>> 先ほどのメールで書いたように、もしrtcdの標準ポートを
>>> 何かに決めるのであれば、2809番がそのためのポート番号として利用可能です。
>>> (CORBA 3.1 specification formal/2008-01-07)
>>>
>>> とりあえず、ソース上では2809をデフォルトにしました。(LERENG_1_0, r1842)
>>> ただし、デフォルトコンフィギュレーションでは以前のままlocalhost:2810です。
>>> rtc.conf でmanager_corba.master_manager を指定しなければ2810、
>>> 空の値もしくは無効な値を指定すると2809です。
>>>
>>>
>>> いかがでしょうか？＞原さん、皆さま
>>>
>>>
>>> ちなみに、
>>> http://ja.wikipedia.org/wiki/TCP%E3%82%84UDP%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%83%9D%E3%83%BC%E3%83%88%E7%95%AA%E5%8F%B7%E3%81%AE%E4%B8%80%E8%A6%A7
>>> 未登録でも、パブリックなサービスのポートとして使用されているポートは
>>> このようにたくさんあります。参考までに。
>>>
>>>
>>> 2010年2月15日15:56 Isao Hara :
>>>> 安藤さん：
>>>>
>>>> 原です。下記の件ですが、。２８１０は、すでにWell　Known　Portです。
>>>> そのため、前のメールを書いた次第です。
>>>> 競合を避けるために、やはり別ポートを登録して、変更しべきだと思います。
>>>>
>>>> 結局、登録しないまま、別ポートにしても後で登録されて、こちらが非登録＆競合
>>>> という状態はよくないと思います。
>>>>
>>>> 標準実装の１つにするんでしょう？
>>>>
>>>>
>>>> 2010年2月15日15:48 Ando Noriaki :
>>>>> 安藤です
>>>>>
>>>>> 2810はwell knownではないので、まぁいいんじゃないでしょうか、
>>>>> というのが僕の考えです。
>>>>>
>>>>> 実は、マネージャ指定で使用する corbaloc 形式ですが、
>>>>> corbaloc:iiop::/
>>>>> ののデフォルトは 2809 です。(CORBAの仕様)
>>>>> でも、たいていのCORBAではネームサーバがこのポートを使っているので、
>>>>> 混乱を避けるために 2810 をデフォルトにしたというわけです。
>>>>>
>>>>> rtcdにネームサーバを内蔵してしまう、というのも解決策としてはありますね。
>>>>> javaのorbdは、実際ネームサーバとオブジェクトサーバを兼ねているようですし。
>>>>>
>>>>>
>>>>> 堀さんのおっしゃるようにポート番号を確保してそれを使うのが
>>>>> いいかもしれませんが、rtcd自体がパブリックなサービスとして
>>>>> 成立するかどうかもわからないので、とりあえず
>>>>>
>>>>> 「何も指定しないと2810番になるけど、使用する状況で適宜rtc.confで変更してください。」
>>>>>
>>>>> というところでどうでしょうか？
>>>>>
>>>>>
>>>>> 余談ですが、Linuxでは自由に使えるポートとして
>>>>> $ cat /proc/sys/net/ipv4/ip_local_port_range
>>>>> 32768 61000
>>>>>
>>>>> つまり、327680～61000 となっているらしいです。
>>>>> FreeBSDとかだと、
>>>>>> sysctl -a|grep portrange
>>>>> :
>>>>> net.inet.ip.portrange.last: 65535
>>>>> net.inet.ip.portrange.first: 49152
>>>>> :
>>>>> なんですけどね。
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2010年2月15日15:14 Toshio HORI :
>>>>>> 安藤さん, 原さん,
>>>>>>
>>>>>> ポート番号の1024～49151はwell-knownではありません。registered port
>>>>>> numbersとされています。
>>>>>>
>>>>>> ただ、well known portを*含めて*そのポート番号の使用は「SHOULD NOT」であっ
>>>>>> て「MUST NOT(あるいはSHALL NOT)」ではありません。「SHOULD NOT」は「NOT
>>>>>> RECOMMENDED」を意味するので(See RFC2119)、解釈としては安藤さんが正しい
>>>>>> です。
>>>>>>
>>>>>> もちろん、今のうちからIANAに登録してポート番号を確保しておくのが一番ス
>>>>>> マートな解だとは思います。
>>>>>>
>>>>>> …というメールを書いたところに原さんの次のメールが届きましたが、せっか
>>>>>> く書いたので送ってしまいます(笑)。
>>>>>>
>>>>>> // 堀俊夫, 博士(工学) / t.hori@aist.go.jp
>>>>>> // (独)産業技術総合研究所デジタルヒューマン研究センター主任研究員
>>>>>> // & OMG Robotics-DTF Robotic Functional Service WG共同座長
>>>>>> // Web: http://www.dh.aist.go.jp/members/toshi.php
>>>>>>
>>>>>> In article ,
>>>>>> Ando Noriaki writes:
>>>>>>> 原様
>>>>>>>
>>>>>>> 安藤です
>>>>>>>
>>>>>>> 固定というのは、デフォルトで2810番という意味で、
>>>>>>> 変更したい場合は、rtc.conf で
>>>>>>> corba.master_manager: localhost:49152
>>>>>>> のように指定してください。
>>>>>>>
>>>>>>> ちなみに、1024～49151 は well known ポートではないので、
>>>>>>> 勝手に使ってはいけない、というほどの強制力はないですよね。
>>>>>>> OpenRTMがすごく広まったら、ちゃんと登録しないとだめかもしれませんが（笑
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2010年2月15日13:23 Isao Hara :
>>>>>>>> 安藤様、皆様：
>>>>>>>>
>>>>>>>> 産総研の原です。
>>>>>>>> 下記のようにネームサーバーのポート番号が固定されているということですが、
>>>>>>>> 2810番のように49151番より下の番号は、勝手につかってはいけません。
>>>>>>>> IANAというところで管理しています。
>>>>>>>> また、2810は、
>>>>>>>> # Ted McFadden
>>>>>>>> netsteward 2810/tcp Active Net Steward
>>>>>>>> netsteward 2810/udp Active Net Steward
>>>>>>>>
>>>>>>>> のようにアプリケーションの登録がなされていますので、変更をお願いいたします。
>>>>>>>>
>>>>>>>> (2010/02/15 12:43), Ando Noriaki wrote:
>>>>>>>>> 菅様、皆さま
>>>>>>>>>
>>>>>>>>> 安藤です
>>>>>>>>>
>>>>>>>>> rtcdについて、まだドキュメントを書いていないので、
>>>>>>>>> いろいろ混乱させてしまいすみません。
>>>>>>>>> ドキュメントはもう少々お待ちください。
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 今回の件ですが、ネームサーバ上に残ったマネージャーのゾンビリファレンスが、
>>>>>>>>> そのごrtc.confでマネージャの登録名を変えたにもかかわらず復活してしまう
>>>>>>>>>
>>>>>>>>> ということでよろしいでしょうか。
>>>>>>>>>
>>>>>>>>> これは、簡潔に言いますと、マネージャーを INS 化したためで、
>>>>>>>>> 対処方法としては、ゾンビ化させないで、マネージャはshutdownコマンドで
>>>>>>>>> 終了させてください、ということになります。
>>>>>>>>>
>>>>>>>>> 以下、長文すみません。
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> さて，今回の問題ですが，追加報告です．
>>>>>>>>>> rtcdを使って現象をいくつか試していますが，
>>>>>>>>>> 以下の操作で再現されることがわかりました．
>>>>>>>>>>
>>>>>>>>>> 一言で表現すると，ゾンビーの復活です．
>>>>>>>>>>
>>>>>>>>>> 初回のrtcdの実行ではnaming_formatsを指定しない，
>>>>>>>>>> 以下のrtc.confで実行．
>>>>>>>>>>
>>>>>>>>>> corba.nameservers: localhost
>>>>>>>>>> naming.formats: %h.host_cxt/%n.rtc
>>>>>>>>>> logger.enable: NO
>>>>>>>>>> logger.log_level: PARANOID
>>>>>>>>>> manager.modules.load_path: ../examples/C++/, ../components/
>>>>>>>>>>
>>>>>>>>>> その後，rtcdを無理やり停止して，ゾンビーを残す．
>>>>>>>>>>
>>>>>>>>>> 次にrtc.confを加工する
>>>>>>>>>>
>>>>>>>>>> corba.nameservers: localhost
>>>>>>>>>> naming.formats: %h.host_cxt/%n.rtc
>>>>>>>>>> logger.enable: NO
>>>>>>>>>> logger.log_level: PARANOID
>>>>>>>>>> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
>>>>>>>>>> manager.modules.load_path: ../examples/C++/, ../components/
>>>>>>>>>>
>>>>>>>>>> 5行目を追加．そして実行すると，
>>>>>>>>>> ゾンビーだったmanager.mgrが復活する．
>>>>>>>>>> こちらからcreateを呼び出しても可能になってしまいます．
>>>>>>>>>>
>>>>>>>>>> 初回の起動でゾンビーがなければ意図通りに動作します．
>>>>>>>>>> また，逆の順序で実行しても同様の現象が起こります．
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 詳しく解説しますと、
>>>>>>>>>
>>>>>>>>> CORBAオブジェクトは、特に何もしていしなければ、生成されるたびに適当なKey (IDのようなもの)
>>>>>>>>> を持ったオブジェクトとして生成され、ネームサーバに登録されるリファレンスも、
>>>>>>>>> たとえ名前が同じであっても、生成されるたびに異なるKeyのオブジェクトとして
>>>>>>>>> 登録されます。
>>>>>>>>>
>>>>>>>>> たとえば、ConsoleIn コンポーネントを2回生成したとします。
>>>>>>>>> 1回目の生成では、以下のような参照がネームサーバに登録されます。
>>>>>>>>>
>>>>>>>>> 名前： ConsoleIn0.rtc 参照：(Key: 0x7183618368, IPアドレス： 192.168.1.10, ポート番号：3444)
>>>>>>>>>
>>>>>>>>> このプロセスを落として、もう一度起動します。次は、以下のような参照が登録されます。
>>>>>>>>>
>>>>>>>>> 名前： ConsoleIn0.rtc 参照：(Key: 0x8297427492, IPアドレス： 192.168.1.10, ポート番号：3653)
>>>>>>>>>
>>>>>>>>> 通常、複数回起動しても同じなのはIPアドレスと名前くらいで、Keyやポート番号はORBやOS
>>>>>>>>> の気分によって変わってしまいます(笑
>>>>>>>>>
>>>>>>>>> しかし、rtcdを-dオプション付きで起動すると、マネージャーはマスターマネージャ（後ほど解説します）となり、
>>>>>>>>> のKeyとポート番号が固定されます。(デフォルトでは Key は manager, ポート番号は 2810 になります。)
>>>>>>>>>
>>>>>>>>> つまり、マネージャーの名前は、以下のような参照としてネームサーバに登録されます。
>>>>>>>>>
>>>>>>>>> 名前： hsotname.host_cxt/manager.mgr 参照：(Key： manager, IPアドレス：
>>>>>>>>> 192.168.1.10, ポート番号：2810) ・・・ (1)
>>>>>>>>>
>>>>>>>>> ここで、マネージャーを強制終了すると、この名前の登録を掃除しないで終了するので、
>>>>>>>>> ネームサーバ上にこの名前がそのまま残ってしまいます。
>>>>>>>>> 次に、rtc.confでmanager.naming_formats を変更すると、
>>>>>>>>>
>>>>>>>>> 名前： hostname.host_cxt/ysuga_net.app_cxt/manager.mgr 参照：(Key： manager,
>>>>>>>>> IPアドレス： 192.168.1.10, ポート番号：2810) ・・・ (2)
>>>>>>>>>
>>>>>>>>> として、マネージャが登録されます。
>>>>>>>>>
>>>>>>>>> ここで、(1)と(2)の参照（ID、IP、ポート）を比べてみると、まったく同じになっています。
>>>>>>>>> したがって、(1)の参照にアクセスしても、(2)と同じオブジェクトにアクセスすることになります。
>>>>>>>>> そういうわけで、ゾンビ化したマネージャ(1)も、復活してしまう、というわけです。
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> なお、マネージャをこのようにIDやポート番号を固定したわけは、ネームサーバなして
>>>>>>>>> マネージャやコンポーネントにアクセスするためです。この辺は、以前松坂さんからご意見のあった、
>>>>>>>>> ネームサーバがシステムの single point of failure になることを避ける手段として
>>>>>>>>> ネームサーバに依存しないでシステムを構築する方法を提供したかったためです。
>>>>>>>>>
>>>>>>>>> こうすることでマネージャは corbaloc:iiop:hostname:port/manager という URL で常に
>>>>>>>>> アクセスできるようになります。ここでポート番号は固定で 2810 としているので、
>>>>>>>>> ホスト名さえ分かれば、そのノードのマスタマネージャにアクセスできることになります。
>>>>>>>>>
>>>>>>>>> ちなみに、こういうオブジェクトの名前付けを INS (Interoperable Naming Service) といいます。
>>>>>>>>>
>>>>>>>>> 以下は、log出力の例ですが、マネージャのIOR(オブジェクト参照)の情報は、
>>>>>>>>>
>>>>>>>>> Feb 15 10:35:40 DEBUG: ManagerServant: Manager's IOR information:
>>>>>>>>> IOR information
>>>>>>>>> Type ID: "IDL:RTM/Manager:1.0"
>>>>>>>>> Profiles:
>>>>>>>>> 1. IIOP 1.2 192.168.100.2 2810
>>>>>>>>> Object Key: "manager" = 0x6d616e61676572 (7 bytes)
>>>>>>>>> TAG_ORB_TYPE omniORB
>>>>>>>>> TAG_CODE_SETS char native code set: ISO-8859-1
>>>>>>>>> char conversion code set: UTF-8
>>>>>>>>> wchar native code set: UTF-16
>>>>>>>>> wchar conversion code set: UTF-16
>>>>>>>>>
>>>>>>>>> このように、Object Key が "manager" という人間が読める形式になっているのに対し、
>>>>>>>>> 以下は ConsoleIn をネームサーバに登録する際のIORなのですが、
>>>>>>>>>
>>>>>>>>> IOR information
>>>>>>>>> Type ID: "IDL:openrtm.aist.go.jp/OpenRTM/DataFlowComponent:1.0"
>>>>>>>>> Profiles:
>>>>>>>>> 1. IIOP 1.2 192.168.100.2 2810
>>>>>>>>> POA(root) Object Key: "...." = 0x00000000 (4 bytes)
>>>>>>>>> Object Key: "...xK........." = 0xfe94ba784b000015080000000000 (14 bytes)
>>>>>>>>> TAG_ORB_TYPE omniORB
>>>>>>>>> TAG_CODE_SETS char native code set: ISO-8859-1
>>>>>>>>> char conversion code set: UTF-8
>>>>>>>>> wchar native code set: UTF-16
>>>>>>>>> wchar conversion code set: UTF-16
>>>>>>>>>
>>>>>>>>> Object Key が 0xfe94ba784b000015080000000000 というORB (というかPOA) が
>>>>>>>>> 適当に付けた名前になっています。
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ついでですので、マネージャの使い方についても少し説明します。
>>>>>>>>>
>>>>>>>>> マネージャにはマスタとスレーブがあります。
>>>>>>>>>
>>>>>>>>> ・マスタマネージャ：
>>>>>>>>> 原則1ノードにつき1つだけ存在する。
>>>>>>>>> アプリケーション、ノードの外部などからは、マスターマネージャに対して
>>>>>>>>> コンポーネントの生成を依頼する。
>>>>>>>>> つまり、原則として、このマネージャ自身はコンポーネントを生成・管理しない。
>>>>>>>>> 実際のコンポーネントの生成は、マスタがスレーブマネージャに依頼する。
>>>>>>>>>
>>>>>>>>> ・スレーブマネージャ：
>>>>>>>>> 1ノードに複数存在できる。0個以上のマスターに所属することができる。
>>>>>>>>> rtcdを-dなしで起動した場合、マスターがすでに起動していればその配下に入る。
>>>>>>>>> コンポーネントはスレーブマネージャ上で生成・管理される。
>>>>>>>>> 原則、コンポーネントが存在しないスレーブマネージャは存在しない（自動でシャットダウンされる）。
>>>>>>>>> -> 菅さんがご指摘されたように、-d オプションなしのrtcdが自動で終了するのはこのためです。
>>>>>>>>> マスターマネージャからは、スレーブはポート番号で区別される。
>>>>>>>>> つまり、同一ポート番号のスレーブマネージャは、同一のプロセス（逆もしかり）である。
>>>>>>>>>
>>>>>>>>> コンポーネント生成の流れは、以下のようになります。
>>>>>>>>>
>>>>>>>>> 1) RTCが起動される可能性のあるノード上では、rtcd は -d オプション付きで起動されているものとします。
>>>>>>>>> ＃Linuxではれば、/etc/init.d 以下の起動スクリプトなどで起動されているイメージ。
>>>>>>>>>
>>>>>>>>> 2) 何らかのツール、コマンド、アプリケーションが、あるノードに対してコンポーネントを作成したい場合
>>>>>>>>> まず、そのノードのマスタマネージャのオブジェクトリファレンスを取得します。
>>>>>>>>> それは、ネームサーバからでもいいですし、corbaloc:iiop:hostname:2810/manager という URL を
>>>>>>>>> ORB::string_to_object() 関数を使ってダイレクトにアクセスしてもかまいません。
>>>>>>>>>
>>>>>>>>> 3) 何らかのツール、コマンド、アプリケーションが、あるノード上で、コンポーネントを起動する場合、
>>>>>>>>> そのノードのマスターマネージャに対して create_component() をコールします。
>>>>>>>>> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234")
>>>>>>>>>
>>>>>>>>> 4) manager=localhost:2811 はローカルホスト上の 2811版ポート上で ConsoleIn という
>>>>>>>>> コンポーネントを起動しなさい、という意味なので、マスターマネージャは、スレーブマネージャを
>>>>>>>>> 2811ポート上で起動し、そのマネージャに対して、create_component("ConsoleIn?instance_name=ConsoleIn1234")
>>>>>>>>> をコールします。
>>>>>>>>>
>>>>>>>>> 5) スレーブマネージャは、ポート2811上で起動し、ConsoleInを一つ生成します。
>>>>>>>>> このとき、インスタンス名はConsoleIn1234 に指定されているのでインスタンス名はこの名前になり、
>>>>>>>>> ネームサーバ上に登録される名前も、この名前になります。
>>>>>>>>>
>>>>>>>>> 6) さらに、同じプロセス上で、ConsoleIn を起動したければ、
>>>>>>>>> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1235")
>>>>>>>>> とをマスタマネージャに対してコールすればよく、異なるプロセスで起動したい場合は、
>>>>>>>>> mgr->create_component("ConsoleIn?manager=localhost:2812&instance_name=ConsoleIn1235")
>>>>>>>>> 等とすれば、別のプロセス上でConsoleInが起動します。
>>>>>>>>>
>>>>>>>>> 7) なお、そのノード上で起動しているコンポーネントの参照は、マスターマネージャから、
>>>>>>>>> mgr->get_components() によって取得できます。
>>>>>>>>> スレーブ上で起動しているすべてのコンポーネントの参照をマスターが収集して返しています。
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 一応、1.0-RELEASEのrtcdはこのような使い方を意図して実装されています。
>>>>>>>>> まだ、ツールの方でも対応しきれていないので、この使い方が実際利用できるのには
>>>>>>>>> 少々時間がかかると思いますが、RTSystemEditorやrtcshellなどで、
>>>>>>>>> 簡単にできるようにしていきたいと思います。
>>>>>>>>> ＃rtcshellについては、ジェフさんよろしく。
>>>>>>>>>
>>>>>>>>> あと、Windows上で起動したrtcdに、RTSystemEditorのmanager viewからアクセスすると、
>>>>>>>>> 非常に重いのですが、これはDLLからRTCのプロファイルを取得する操作がWindows
>>>>>>>>> 上ではなぜだか非常に遅いために発生しています。（Linuxだと一瞬で終わるのですが。。。）
>>>>>>>>> また、OpenCVをインストールしていない場合、RTCのプロファイルを取得する過程で、
>>>>>>>>> USBcamera*コンポーネントをアクセスした段階で、DLLのエラーダイアログが出てしまい
>>>>>>>>> アクセスがさらに遅くなってしまいます。
>>>>>>>>> OpenCVをインストールするか、USBCameda*.DLLを削除するかすると改善します。
>>>>>>>>>
>>>>>>>>
>>>>>>>>

Mon, 2010-02-15 23:43

(Reply to #15) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01116] Managerのnamingformatの不具合

OpenRTM-aist MLの皆様：
早大の菅です．
お世話になっております．

ポート番号の話ですが，ひとつお聞きしたいことがあります．
すみません，RTMの規格とか，よくわかっていないのかもしれません．
良ければ教えてください．

現状で原様，堀様，安藤様がお話している内容は，
RTミドルウエアの規格としてポート番号をとるのか否か，
という話なのでしょうか？

ただ，RTミドルウエア自体は，OMGでPIMで定義されている規格でしょうから，
本来はCORBAなどの通信層に依存しない規格のはずです．
たとえばEJBでの実装なんて可能なのでは？なんて思っていますが…

そこで問題なのですが，
IPプロトコル前提のポート番号を登録する必要って何なのですか？

たとえばOpenRTM-aistの実装では，
既存CORBAサービスとの共存が難しいのですか？

ならばそれはOpenRTM-aistの問題でしょうから，
ポートを登録していないと問題が起こるのは，
OpenRTM-aistですよね？

そこらへんで，どのレベルで議論されているのか，
はたから見て良くわかりませんでした．すみません．

もし，ポート番号取得の必要性があるなら，
それは絶対に取るべきだと思います．
デファクトではなく，デジュレを行くのが
RTミドルウエアの本道だと思います．

なんて，偉そうなことを言ってしまってすみません．

ではでは

(2010/02/15 20:09), 原功 wrote:
> 堀さん：
>
> 原です。堀さんが一番詳しいかと思いまして。。。。
> 永続になるのでしたら、変更は難しそうですね。
> しかし、この際決めてしまって、申請してはいかがでしょうか？
> OpenRTMのコミュニティが大きくなりすぎると（既になっていないといけないのですが）
> 変更は難しいと思います。
> 少なくとも、登録済みのポートは、避けてはいかがでしょうか？
> （2809を使い続ければ、CORBAのNamingServiceだと分かる人は分かると思いますが）
>
> On 2010/02/15, at 19:48, Toshio HORI wrote:
>
>> 原さん, 安藤さん,
>>
>> # なぜ僕に聞く(苦笑)。
>>
>> ポート番号は
>> http://www.iana.org/cgi-bin/usr-port-number.pl
>> から登録申請できるようですね。承認されればおそらく永続性は確保できるの
>> ではないかと思いますが…詳細は不明です。
>>
>> // 堀俊夫, 博士(工学) / t.hori@aist.go.jp
>> // (独)産業技術総合研究所デジタルヒューマン研究センター主任研究員
>> //& OMG Robotics-DTF Robotic Functional Service WG共同座長
>> // Web: http://www.dh.aist.go.jp/members/toshi.php
>>
>> In article,
>> 原功 writes:
>>> 安藤さん：
>>>
>>> 原です。下記の件ですが、Well-known portではなくて、registered port であることは、
>>> 知っています。（流れで書いていました。。。。）
>>> また、Must Notであることもわかっています。ただ、２８１０がすでに登録済みであり、
>>> このまま、２８１０を使い続けても、登録できないならば、変更した方がよいと思っていました。
>>> 現在の実装では、OmniNamesなので、CORBAのNamingServerのポートを使っている
>>> 方がよいと思います。
>>>
>>> 堀さん：
>>> IANAに登録るすと永続的になるのでしょうか？
>>> そうでないなら、取り合えず登録しておくのも良いかと思いますが。いかがでしょうか？
>>>
>>> On 2010/02/15, at 17:59, Ando Noriaki wrote:
>>>
>>>> 安藤です
>>>>
>>>> 堀さんも指摘されていますが、
>>>> 2810 は well known port ではなく regsitered port に含まれます。
>>>> http://www.iana.org/assignments/port-numbers
>>>>
>>>> といっても、well known ports も registered ports も、RFC4340を見る限り
>>>> "SHOULD NOT be used without IANA registration" なので、
>>>> 「登録せずに使用することは推奨しない」といったニュアンスかとおもいます。
>>>> ＃MUST NOT ではないですし。
>>>> あと、well known と registerted ポートの違いは、root(もしくは特定のユーザ)
>>>> により実行されるサービスか、そうでないかの差くらいしかないようですね。
>>>>
>>>> すぐにIANAに登録するというわけにもいきませんし、そもそもrtcdの枠組みが、
>>>> 今後も永続的に使われるようになるのか、実験段階なのでわかりません、
>>>> したがいまして、解決策としては、以下の案はどうでしょうか？
>>>>
>>>> 先ほどのメールで書いたように、もしrtcdの標準ポートを
>>>> 何かに決めるのであれば、2809番がそのためのポート番号として利用可能です。
>>>> (CORBA 3.1 specification formal/2008-01-07)
>>>>
>>>> とりあえず、ソース上では2809をデフォルトにしました。(LERENG_1_0, r1842)
>>>> ただし、デフォルトコンフィギュレーションでは以前のままlocalhost:2810です。
>>>> rtc.conf でmanager_corba.master_manager を指定しなければ2810、
>>>> 空の値もしくは無効な値を指定すると2809です。
>>>>
>>>>
>>>> いかがでしょうか？＞原さん、皆さま
>>>>
>>>>
>>>> ちなみに、
>>>> http://ja.wikipedia.org/wiki/TCP%E3%82%84UDP%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%83%9D%E3%83%BC%E3%83%88%E7%95%AA%E5%8F%B7%E3%81%AE%E4%B8%80%E8%A6%A7
>>>> 未登録でも、パブリックなサービスのポートとして使用されているポートは
>>>> このようにたくさんあります。参考までに。
>>>>
>>>>
>>>> 2010年2月15日15:56 Isao Hara:
>>>>> 安藤さん：
>>>>>
>>>>> 原です。下記の件ですが、。２８１０は、すでにWell　Known　Portです。
>>>>> そのため、前のメールを書いた次第です。
>>>>> 競合を避けるために、やはり別ポートを登録して、変更しべきだと思います。
>>>>>
>>>>> 結局、登録しないまま、別ポートにしても後で登録されて、こちらが非登録＆競合
>>>>> という状態はよくないと思います。
>>>>>
>>>>> 標準実装の１つにするんでしょう？
>>>>>
>>>>>
>>>>> 2010年2月15日15:48 Ando Noriaki:
>>>>>> 安藤です
>>>>>>
>>>>>> 2810はwell knownではないので、まぁいいんじゃないでしょうか、
>>>>>> というのが僕の考えです。
>>>>>>
>>>>>> 実は、マネージャ指定で使用する corbaloc 形式ですが、
>>>>>> corbaloc:iiop::/
>>>>>> ののデフォルトは 2809 です。(CORBAの仕様)
>>>>>> でも、たいていのCORBAではネームサーバがこのポートを使っているので、
>>>>>> 混乱を避けるために 2810 をデフォルトにしたというわけです。
>>>>>>
>>>>>> rtcdにネームサーバを内蔵してしまう、というのも解決策としてはありますね。
>>>>>> javaのorbdは、実際ネームサーバとオブジェクトサーバを兼ねているようですし。
>>>>>>
>>>>>>
>>>>>> 堀さんのおっしゃるようにポート番号を確保してそれを使うのが
>>>>>> いいかもしれませんが、rtcd自体がパブリックなサービスとして
>>>>>> 成立するかどうかもわからないので、とりあえず
>>>>>>
>>>>>> 「何も指定しないと2810番になるけど、使用する状況で適宜rtc.confで変更してください。」
>>>>>>
>>>>>> というところでどうでしょうか？
>>>>>>
>>>>>>
>>>>>> 余談ですが、Linuxでは自由に使えるポートとして
>>>>>> $ cat /proc/sys/net/ipv4/ip_local_port_range
>>>>>> 32768 61000
>>>>>>
>>>>>> つまり、327680～61000 となっているらしいです。
>>>>>> FreeBSDとかだと、
>>>>>>> sysctl -a|grep portrange
>>>>>> :
>>>>>> net.inet.ip.portrange.last: 65535
>>>>>> net.inet.ip.portrange.first: 49152
>>>>>> :
>>>>>> なんですけどね。
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2010年2月15日15:14 Toshio HORI:
>>>>>>> 安藤さん, 原さん,
>>>>>>>
>>>>>>> ポート番号の1024～49151はwell-knownではありません。registered port
>>>>>>> numbersとされています。
>>>>>>>
>>>>>>> ただ、well known portを*含めて*そのポート番号の使用は「SHOULD NOT」であっ
>>>>>>> て「MUST NOT(あるいはSHALL NOT)」ではありません。「SHOULD NOT」は「NOT
>>>>>>> RECOMMENDED」を意味するので(See RFC2119)、解釈としては安藤さんが正しい
>>>>>>> です。
>>>>>>>
>>>>>>> もちろん、今のうちからIANAに登録してポート番号を確保しておくのが一番ス
>>>>>>> マートな解だとは思います。
>>>>>>>
>>>>>>> …というメールを書いたところに原さんの次のメールが届きましたが、せっか
>>>>>>> く書いたので送ってしまいます(笑)。
>>>>>>>
>>>>>>> // 堀俊夫, 博士(工学) / t.hori@aist.go.jp
>>>>>>> // (独)産業技術総合研究所デジタルヒューマン研究センター主任研究員
>>>>>>> //& OMG Robotics-DTF Robotic Functional Service WG共同座長
>>>>>>> // Web: http://www.dh.aist.go.jp/members/toshi.php
>>>>>>>
>>>>>>> In article,
>>>>>>> Ando Noriaki writes:
>>>>>>>> 原様
>>>>>>>>
>>>>>>>> 安藤です
>>>>>>>>
>>>>>>>> 固定というのは、デフォルトで2810番という意味で、
>>>>>>>> 変更したい場合は、rtc.conf で
>>>>>>>> corba.master_manager: localhost:49152
>>>>>>>> のように指定してください。
>>>>>>>>
>>>>>>>> ちなみに、1024～49151 は well known ポートではないので、
>>>>>>>> 勝手に使ってはいけない、というほどの強制力はないですよね。
>>>>>>>> OpenRTMがすごく広まったら、ちゃんと登録しないとだめかもしれませんが（笑
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2010年2月15日13:23 Isao Hara:
>>>>>>>>> 安藤様、皆様：
>>>>>>>>>
>>>>>>>>> 産総研の原です。
>>>>>>>>> 下記のようにネームサーバーのポート番号が固定されているということですが、
>>>>>>>>> 2810番のように49151番より下の番号は、勝手につかってはいけません。
>>>>>>>>> IANAというところで管理しています。
>>>>>>>>> また、2810は、
>>>>>>>>> # Ted McFadden
>>>>>>>>> netsteward 2810/tcp Active Net Steward
>>>>>>>>> netsteward 2810/udp Active Net Steward
>>>>>>>>>
>>>>>>>>> のようにアプリケーションの登録がなされていますので、変更をお願いいたします。
>>>>>>>>>
>>>>>>>>> (2010/02/15 12:43), Ando Noriaki wrote:
>>>>>>>>>> 菅様、皆さま
>>>>>>>>>>
>>>>>>>>>> 安藤です
>>>>>>>>>>
>>>>>>>>>> rtcdについて、まだドキュメントを書いていないので、
>>>>>>>>>> いろいろ混乱させてしまいすみません。
>>>>>>>>>> ドキュメントはもう少々お待ちください。
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 今回の件ですが、ネームサーバ上に残ったマネージャーのゾンビリファレンスが、
>>>>>>>>>> そのごrtc.confでマネージャの登録名を変えたにもかかわらず復活してしまう
>>>>>>>>>>
>>>>>>>>>> ということでよろしいでしょうか。
>>>>>>>>>>
>>>>>>>>>> これは、簡潔に言いますと、マネージャーを INS 化したためで、
>>>>>>>>>> 対処方法としては、ゾンビ化させないで、マネージャはshutdownコマンドで
>>>>>>>>>> 終了させてください、ということになります。
>>>>>>>>>>
>>>>>>>>>> 以下、長文すみません。
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> さて，今回の問題ですが，追加報告です．
>>>>>>>>>>> rtcdを使って現象をいくつか試していますが，
>>>>>>>>>>> 以下の操作で再現されることがわかりました．
>>>>>>>>>>>
>>>>>>>>>>> 一言で表現すると，ゾンビーの復活です．
>>>>>>>>>>>
>>>>>>>>>>> 初回のrtcdの実行ではnaming_formatsを指定しない，
>>>>>>>>>>> 以下のrtc.confで実行．
>>>>>>>>>>>
>>>>>>>>>>> corba.nameservers: localhost
>>>>>>>>>>> naming.formats: %h.host_cxt/%n.rtc
>>>>>>>>>>> logger.enable: NO
>>>>>>>>>>> logger.log_level: PARANOID
>>>>>>>>>>> manager.modules.load_path: ../examples/C++/, ../components/
>>>>>>>>>>>
>>>>>>>>>>> その後，rtcdを無理やり停止して，ゾンビーを残す．
>>>>>>>>>>>
>>>>>>>>>>> 次にrtc.confを加工する
>>>>>>>>>>>
>>>>>>>>>>> corba.nameservers: localhost
>>>>>>>>>>> naming.formats: %h.host_cxt/%n.rtc
>>>>>>>>>>> logger.enable: NO
>>>>>>>>>>> logger.log_level: PARANOID
>>>>>>>>>>> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
>>>>>>>>>>> manager.modules.load_path: ../examples/C++/, ../components/
>>>>>>>>>>>
>>>>>>>>>>> 5行目を追加．そして実行すると，
>>>>>>>>>>> ゾンビーだったmanager.mgrが復活する．
>>>>>>>>>>> こちらからcreateを呼び出しても可能になってしまいます．
>>>>>>>>>>>
>>>>>>>>>>> 初回の起動でゾンビーがなければ意図通りに動作します．
>>>>>>>>>>> また，逆の順序で実行しても同様の現象が起こります．
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 詳しく解説しますと、
>>>>>>>>>>
>>>>>>>>>> CORBAオブジェクトは、特に何もしていしなければ、生成されるたびに適当なKey (IDのようなもの)
>>>>>>>>>> を持ったオブジェクトとして生成され、ネームサーバに登録されるリファレンスも、
>>>>>>>>>> たとえ名前が同じであっても、生成されるたびに異なるKeyのオブジェクトとして
>>>>>>>>>> 登録されます。
>>>>>>>>>>
>>>>>>>>>> たとえば、ConsoleIn コンポーネントを2回生成したとします。
>>>>>>>>>> 1回目の生成では、以下のような参照がネームサーバに登録されます。
>>>>>>>>>>
>>>>>>>>>> 名前： ConsoleIn0.rtc 参照：(Key: 0x7183618368, IPアドレス： 192.168.1.10, ポート番号：3444)
>>>>>>>>>>
>>>>>>>>>> このプロセスを落として、もう一度起動します。次は、以下のような参照が登録されます。
>>>>>>>>>>
>>>>>>>>>> 名前： ConsoleIn0.rtc 参照：(Key: 0x8297427492, IPアドレス： 192.168.1.10, ポート番号：3653)
>>>>>>>>>>
>>>>>>>>>> 通常、複数回起動しても同じなのはIPアドレスと名前くらいで、Keyやポート番号はORBやOS
>>>>>>>>>> の気分によって変わってしまいます(笑
>>>>>>>>>>
>>>>>>>>>> しかし、rtcdを-dオプション付きで起動すると、マネージャーはマスターマネージャ（後ほど解説します）となり、
>>>>>>>>>> のKeyとポート番号が固定されます。(デフォルトでは Key は manager, ポート番号は 2810 になります。)
>>>>>>>>>>
>>>>>>>>>> つまり、マネージャーの名前は、以下のような参照としてネームサーバに登録されます。
>>>>>>>>>>
>>>>>>>>>> 名前： hsotname.host_cxt/manager.mgr 参照：(Key： manager, IPアドレス：
>>>>>>>>>> 192.168.1.10, ポート番号：2810) ・・・ (1)
>>>>>>>>>>
>>>>>>>>>> ここで、マネージャーを強制終了すると、この名前の登録を掃除しないで終了するので、
>>>>>>>>>> ネームサーバ上にこの名前がそのまま残ってしまいます。
>>>>>>>>>> 次に、rtc.confでmanager.naming_formats を変更すると、
>>>>>>>>>>
>>>>>>>>>> 名前： hostname.host_cxt/ysuga_net.app_cxt/manager.mgr 参照：(Key： manager,
>>>>>>>>>> IPアドレス： 192.168.1.10, ポート番号：2810) ・・・ (2)
>>>>>>>>>>
>>>>>>>>>> として、マネージャが登録されます。
>>>>>>>>>>
>>>>>>>>>> ここで、(1)と(2)の参照（ID、IP、ポート）を比べてみると、まったく同じになっています。
>>>>>>>>>> したがって、(1)の参照にアクセスしても、(2)と同じオブジェクトにアクセスすることになります。
>>>>>>>>>> そういうわけで、ゾンビ化したマネージャ(1)も、復活してしまう、というわけです。
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> なお、マネージャをこのようにIDやポート番号を固定したわけは、ネームサーバなして
>>>>>>>>>> マネージャやコンポーネントにアクセスするためです。この辺は、以前松坂さんからご意見のあった、
>>>>>>>>>> ネームサーバがシステムの single point of failure になることを避ける手段として
>>>>>>>>>> ネームサーバに依存しないでシステムを構築する方法を提供したかったためです。
>>>>>>>>>>
>>>>>>>>>> こうすることでマネージャは corbaloc:iiop:hostname:port/manager という URL で常に
>>>>>>>>>> アクセスできるようになります。ここでポート番号は固定で 2810 としているので、
>>>>>>>>>> ホスト名さえ分かれば、そのノードのマスタマネージャにアクセスできることになります。
>>>>>>>>>>
>>>>>>>>>> ちなみに、こういうオブジェクトの名前付けを INS (Interoperable Naming Service) といいます。
>>>>>>>>>>
>>>>>>>>>> 以下は、log出力の例ですが、マネージャのIOR(オブジェクト参照)の情報は、
>>>>>>>>>>
>>>>>>>>>> Feb 15 10:35:40 DEBUG: ManagerServant: Manager's IOR information:
>>>>>>>>>> IOR information
>>>>>>>>>> Type ID: "IDL:RTM/Manager:1.0"
>>>>>>>>>> Profiles:
>>>>>>>>>> 1. IIOP 1.2 192.168.100.2 2810
>>>>>>>>>> Object Key: "manager" = 0x6d616e61676572 (7 bytes)
>>>>>>>>>> TAG_ORB_TYPE omniORB
>>>>>>>>>> TAG_CODE_SETS char native code set: ISO-8859-1
>>>>>>>>>> char conversion code set: UTF-8
>>>>>>>>>> wchar native code set: UTF-16
>>>>>>>>>> wchar conversion code set: UTF-16
>>>>>>>>>>
>>>>>>>>>> このように、Object Key が "manager" という人間が読める形式になっているのに対し、
>>>>>>>>>> 以下は ConsoleIn をネームサーバに登録する際のIORなのですが、
>>>>>>>>>>
>>>>>>>>>> IOR information
>>>>>>>>>> Type ID: "IDL:openrtm.aist.go.jp/OpenRTM/DataFlowComponent:1.0"
>>>>>>>>>> Profiles:
>>>>>>>>>> 1. IIOP 1.2 192.168.100.2 2810
>>>>>>>>>> POA(root) Object Key: "...." = 0x00000000 (4 bytes)
>>>>>>>>>> Object Key: "...xK........." = 0xfe94ba784b000015080000000000 (14 bytes)
>>>>>>>>>> TAG_ORB_TYPE omniORB
>>>>>>>>>> TAG_CODE_SETS char native code set: ISO-8859-1
>>>>>>>>>> char conversion code set: UTF-8
>>>>>>>>>> wchar native code set: UTF-16
>>>>>>>>>> wchar conversion code set: UTF-16
>>>>>>>>>>
>>>>>>>>>> Object Key が 0xfe94ba784b000015080000000000 というORB (というかPOA) が
>>>>>>>>>> 適当に付けた名前になっています。
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ついでですので、マネージャの使い方についても少し説明します。
>>>>>>>>>>
>>>>>>>>>> マネージャにはマスタとスレーブがあります。
>>>>>>>>>>
>>>>>>>>>> ・マスタマネージャ：
>>>>>>>>>> 原則1ノードにつき1つだけ存在する。
>>>>>>>>>> アプリケーション、ノードの外部などからは、マスターマネージャに対して
>>>>>>>>>> コンポーネントの生成を依頼する。
>>>>>>>>>> つまり、原則として、このマネージャ自身はコンポーネントを生成・管理しない。
>>>>>>>>>> 実際のコンポーネントの生成は、マスタがスレーブマネージャに依頼する。
>>>>>>>>>>
>>>>>>>>>> ・スレーブマネージャ：
>>>>>>>>>> 1ノードに複数存在できる。0個以上のマスターに所属することができる。
>>>>>>>>>> rtcdを-dなしで起動した場合、マスターがすでに起動していればその配下に入る。
>>>>>>>>>> コンポーネントはスレーブマネージャ上で生成・管理される。
>>>>>>>>>> 原則、コンポーネントが存在しないスレーブマネージャは存在しない（自動でシャットダウンされる）。
>>>>>>>>>> -> 菅さんがご指摘されたように、-d オプションなしのrtcdが自動で終了するのはこのためです。
>>>>>>>>>> マスターマネージャからは、スレーブはポート番号で区別される。
>>>>>>>>>> つまり、同一ポート番号のスレーブマネージャは、同一のプロセス（逆もしかり）である。
>>>>>>>>>>
>>>>>>>>>> コンポーネント生成の流れは、以下のようになります。
>>>>>>>>>>
>>>>>>>>>> 1) RTCが起動される可能性のあるノード上では、rtcd は -d オプション付きで起動されているものとします。
>>>>>>>>>> ＃Linuxではれば、/etc/init.d 以下の起動スクリプトなどで起動されているイメージ。
>>>>>>>>>>
>>>>>>>>>> 2) 何らかのツール、コマンド、アプリケーションが、あるノードに対してコンポーネントを作成したい場合
>>>>>>>>>> まず、そのノードのマスタマネージャのオブジェクトリファレンスを取得します。
>>>>>>>>>> それは、ネームサーバからでもいいですし、corbaloc:iiop:hostname:2810/manager という URL を
>>>>>>>>>> ORB::string_to_object() 関数を使ってダイレクトにアクセスしてもかまいません。
>>>>>>>>>>
>>>>>>>>>> 3) 何らかのツール、コマンド、アプリケーションが、あるノード上で、コンポーネントを起動する場合、
>>>>>>>>>> そのノードのマスターマネージャに対して create_component() をコールします。
>>>>>>>>>> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234")
>>>>>>>>>>
>>>>>>>>>> 4) manager=localhost:2811 はローカルホスト上の 2811版ポート上で ConsoleIn という
>>>>>>>>>> コンポーネントを起動しなさい、という意味なので、マスターマネージャは、スレーブマネージャを
>>>>>>>>>> 2811ポート上で起動し、そのマネージャに対して、create_component("ConsoleIn?instance_name=ConsoleIn1234")
>>>>>>>>>> をコールします。
>>>>>>>>>>
>>>>>>>>>> 5) スレーブマネージャは、ポート2811上で起動し、ConsoleInを一つ生成します。
>>>>>>>>>> このとき、インスタンス名はConsoleIn1234 に指定されているのでインスタンス名はこの名前になり、
>>>>>>>>>> ネームサーバ上に登録される名前も、この名前になります。
>>>>>>>>>>
>>>>>>>>>> 6) さらに、同じプロセス上で、ConsoleIn を起動したければ、
>>>>>>>>>> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1235")
>>>>>>>>>> とをマスタマネージャに対してコールすればよく、異なるプロセスで起動したい場合は、
>>>>>>>>>> mgr->create_component("ConsoleIn?manager=localhost:2812&instance_name=ConsoleIn1235")
>>>>>>>>>> 等とすれば、別のプロセス上でConsoleInが起動します。
>>>>>>>>>>
>>>>>>>>>> 7) なお、そのノード上で起動しているコンポーネントの参照は、マスターマネージャから、
>>>>>>>>>> mgr->get_components() によって取得できます。
>>>>>>>>>> スレーブ上で起動しているすべてのコンポーネントの参照をマスターが収集して返しています。
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 一応、1.0-RELEASEのrtcdはこのような使い方を意図して実装されています。
>>>>>>>>>> まだ、ツールの方でも対応しきれていないので、この使い方が実際利用できるのには
>>>>>>>>>> 少々時間がかかると思いますが、RTSystemEditorやrtcshellなどで、
>>>>>>>>>> 簡単にできるようにしていきたいと思います。
>>>>>>>>>> ＃rtcshellについては、ジェフさんよろしく。
>>>>>>>>>>
>>>>>>>>>> あと、Windows上で起動したrtcdに、RTSystemEditorのmanager viewからアクセスすると、
>>>>>>>>>> 非常に重いのですが、これはDLLからRTCのプロファイルを取得する操作がWindows
>>>>>>>>>> 上ではなぜだか非常に遅いために発生しています。（Linuxだと一瞬で終わるのですが。。。）
>>>>>>>>>> また、OpenCVをインストールしていない場合、RTCのプロファイルを取得する過程で、
>>>>>>>>>> USBcamera*コンポーネントをアクセスした段階で、DLLのエラーダイアログが出てしまい
>>>>>>>>>> アクセスがさらに遅くなってしまいます。
>>>>>>>>>> OpenCVをインストールするか、USBCameda*.DLLを削除するかすると改善します。
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>

Tue, 2010-02-16 01:38

(Reply to #16) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01118] Managerのnamingformatの不具合

菅様、皆様

安藤です

ご意見ありがとうございます。

> ポート番号の話ですが，ひとつお聞きしたいことがあります．
> すみません，RTMの規格とか，よくわかっていないのかもしれません．
> 良ければ教えてください．
>
> 現状で原様，堀様，安藤様がお話している内容は，
> RTミドルウエアの規格としてポート番号をとるのか否か，
> という話なのでしょうか？

簡単にいえば、マスタマネージャのデフォルトポートが2810になってるけど、
それって、割り当て済みポート番号なので、まずいんじゃないの？ということです。
僕としては、rtcd なんてまだ実験段階なので、適当なポート番号で
いいんじゃないの？まずかったらrtc.confで変えられるんだし。という考え方です。

> ただ，RTミドルウエア自体は，OMGでPIMで定義されている規格でしょうから，
> 本来はCORBAなどの通信層に依存しない規格のはずです．
> たとえばEJBでの実装なんて可能なのでは？なんて思っていますが…

おっしゃる通り、OMGの仕様はPIMが基本です。ただし、OMGで決まっているのは
RTCの規格だけで、一方今回の話題はRTCを管理するRTMのサービスの一つである
マネージャについてです。いまのところ、マネージャについては標準は何も決まっていません。

> そこで問題なのですが，
> IPプロトコル前提のポート番号を登録する必要って何なのですか？
> たとえばOpenRTM-aistの実装では，
> 既存CORBAサービスとの共存が難しいのですか？

現状、2809をrtcdが使うと、ネームサーバ（omniNames）は他の番号を使わないといけません。
＃複数のプロセス(=ORB)が一つのポートを共有することはできませんので。
rtcd上にマネージャとネームサービスを共存させることは原理的には可能です。
ネームサービスを自前で実装して、rtcd上でネームサービスオブジェクトを
生成してあげればいいだけですので。そうすると、

ネームサーバには、corbaloc:iiop::2809/NameService
マネージャには、corbaloc:iiop::2809/manager

でアクセスできるようになります。

ちなみに、ネームサーバ自体もどのポートがデフォルトかは、おそらく決まっていない
と思われます。決まっているのは、先ほど申し上げたように、

corbaloc:iiop::/
というINSのURL指定時に、が省略された時は 2809がデフォルトね、

とCORBAの仕様書に1行だけ書いてあることだけです。

omniNames はこれをネームサーバのデフォルトポート番号として利用しているだけで、
2809がデフォルトポートでないネームサーバを持つCORBA実装も存在します。

> ならばそれはOpenRTM-aistの問題でしょうから，
> ポートを登録していないと問題が起こるのは，
> OpenRTM-aistですよね？

ポート番号自体は、何番でもよくて、しかも一般ユーザにはあまり関係ありません。
ミドルウエア（というかマネージャ）を実装する人、ツールを実装する人の間で
コンセンサスができていれば済む問題です。で、そういう人は普通、ドキュメント、
ソース、仕様書を隅々まで読むでしょうから、それほど混乱しないんじゃないでしょうか？

原さんのおっしゃるように、これらの「実装する人」というのが多くなったら
収集がつかなくなるから、いまのうちに登録して決めておいた方がいい、
というのは正論なのですが、そもそもrtcdあるいはマネージャって何？という、まだ
何者なのか仕様も明確になっていない段階で番号を登録する必要性をそれほど感じません。

また、上で菅さんがおっしゃったように、RTCおよびRTMにはEJB実装とか、.NET remote実装
などといった様々なPSMが考えられます。（実際、セックの池添さんは.NET remote版など
も実装されていたりします。）そうしたときに、実装毎にマネージャがある場合には、
それぞれにポート番号が必要になりますが、その場合はどうしたらいいでしょうか？

さらに、X Window Systemのように、複数のポート番号をまとめて確保するのか、
一つだけでいいのか、といったことも現状では確定していません。
rtcdの使い方でも書きましたが、マスタマネージャだけでなく、スレーブもポート番号を
明示してやる必要があるので、本当ならスレーブのための番号も確保すべきでしょう。

> そこらへんで，どのレベルで議論されているのか，
> はたから見て良くわかりませんでした．すみません．
>
> もし，ポート番号取得の必要性があるなら，
> それは絶対に取るべきだと思います．
> デファクトではなく，デジュレを行くのが
> RTミドルウエアの本道だと思います．

現在、OMGのRobotics DTFのInfra.WGでRTC Deployment and Dynamic Reconfiguration
という、RTCのマネージャやディレクトリサービスに関する標準を作ろうとしているところです。
（これには、今日、松坂さんからの質問に返答した際に添付したRTCProfileやRTSProfileなどの
仕様記述方式も含まれる予定です。）

その仕様では、rtcdで実装しているマネージャのようなものや、ネームサービスのようなものの
仕様が正式に策定される見込みですが、そうなったら、「CORBA PSMの場合のマネージャ
のデフォルトポートはxxxx番です」という文言を仕様に盛り込むというのも意味があるかもしれません。

ただし、それも可能かどうかは、一緒に標準化を進めている韓国グループの意向
（彼らはCORBAを使っていません）や、その他標準化に関わる組織の意向等が
関わってくるので、なんとも言えません。

そういうわけで、もしポート番号を正式に登録するとしても、
標準化の仕様策定が進んでからにしたほうがいいのではないでしょうか。

> なんて，偉そうなことを言ってしまってすみません．
>
> ではでは
>
>
> (2010/02/15 20:09), 原功 wrote:
>>
>> 堀さん：
>>
>> 原です。堀さんが一番詳しいかと思いまして。。。。
>> 永続になるのでしたら、変更は難しそうですね。
>> しかし、この際決めてしまって、申請してはいかがでしょうか？
>> OpenRTMのコミュニティが大きくなりすぎると（既になっていないといけないのですが）
>> 変更は難しいと思います。
>> 少なくとも、登録済みのポートは、避けてはいかがでしょうか？
>> （2809を使い続ければ、CORBAのNamingServiceだと分かる人は分かると思いますが）
>>
>> On 2010/02/15, at 19:48, Toshio HORI wrote:
>>
>>> 原さん, 安藤さん,
>>>
>>> # なぜ僕に聞く(苦笑)。
>>>
>>> ポート番号は
>>> http://www.iana.org/cgi-bin/usr-port-number.pl
>>> から登録申請できるようですね。承認されればおそらく永続性は確保できるの
>>> ではないかと思いますが…詳細は不明です。
>>>
>>> // 堀俊夫, 博士(工学) / t.hori@aist.go.jp
>>> // (独)産業技術総合研究所デジタルヒューマン研究センター主任研究員
>>> //& OMG Robotics-DTF Robotic Functional Service WG共同座長
>>> // Web: http://www.dh.aist.go.jp/members/toshi.php
>>>
>>> In article,
>>> 原功 writes:
>>>>
>>>> 安藤さん：
>>>>
>>>> 原です。下記の件ですが、Well-known portではなくて、registered port であることは、
>>>> 知っています。（流れで書いていました。。。。）
>>>> また、Must Notであることもわかっています。ただ、２８１０がすでに登録済みであり、
>>>> このまま、２８１０を使い続けても、登録できないならば、変更した方がよいと思っていました。
>>>> 現在の実装では、OmniNamesなので、CORBAのNamingServerのポートを使っている
>>>> 方がよいと思います。
>>>>
>>>> 堀さん：
>>>> IANAに登録るすと永続的になるのでしょうか？
>>>> そうでないなら、取り合えず登録しておくのも良いかと思いますが。いかがでしょうか？
>>>>
>>>> On 2010/02/15, at 17:59, Ando Noriaki wrote:
>>>>
>>>>> 安藤です
>>>>>
>>>>> 堀さんも指摘されていますが、
>>>>> 2810 は well known port ではなく regsitered port に含まれます。
>>>>> http://www.iana.org/assignments/port-numbers
>>>>>
>>>>> といっても、well known ports も registered ports も、RFC4340を見る限り
>>>>> "SHOULD NOT be used without IANA registration" なので、
>>>>> 「登録せずに使用することは推奨しない」といったニュアンスかとおもいます。
>>>>> ＃MUST NOT ではないですし。
>>>>> あと、well known と registerted ポートの違いは、root(もしくは特定のユーザ)
>>>>> により実行されるサービスか、そうでないかの差くらいしかないようですね。
>>>>>
>>>>> すぐにIANAに登録するというわけにもいきませんし、そもそもrtcdの枠組みが、
>>>>> 今後も永続的に使われるようになるのか、実験段階なのでわかりません、
>>>>> したがいまして、解決策としては、以下の案はどうでしょうか？
>>>>>
>>>>> 先ほどのメールで書いたように、もしrtcdの標準ポートを
>>>>> 何かに決めるのであれば、2809番がそのためのポート番号として利用可能です。
>>>>> (CORBA 3.1 specification formal/2008-01-07)
>>>>>
>>>>> とりあえず、ソース上では2809をデフォルトにしました。(LERENG_1_0, r1842)
>>>>> ただし、デフォルトコンフィギュレーションでは以前のままlocalhost:2810です。
>>>>> rtc.conf でmanager_corba.master_manager を指定しなければ2810、
>>>>> 空の値もしくは無効な値を指定すると2809です。
>>>>>
>>>>>
>>>>> いかがでしょうか？＞原さん、皆さま
>>>>>
>>>>>
>>>>> ちなみに、
>>>>>
>>>>> http://ja.wikipedia.org/wiki/TCP%E3%82%84UDP%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%83%9D%E3%83%BC%E3%83%88%E7%95%AA%E5%8F%B7%E3%81%AE%E4%B8%80%E8%A6%A7
>>>>> 未登録でも、パブリックなサービスのポートとして使用されているポートは
>>>>> このようにたくさんあります。参考までに。
>>>>>
>>>>>
>>>>> 2010年2月15日15:56 Isao Hara:
>>>>>>
>>>>>> 安藤さん：
>>>>>>
>>>>>> 原です。下記の件ですが、。２８１０は、すでにWell　Known　Portです。
>>>>>> そのため、前のメールを書いた次第です。
>>>>>> 競合を避けるために、やはり別ポートを登録して、変更しべきだと思います。
>>>>>>
>>>>>> 結局、登録しないまま、別ポートにしても後で登録されて、こちらが非登録＆競合
>>>>>> という状態はよくないと思います。
>>>>>>
>>>>>> 標準実装の１つにするんでしょう？
>>>>>>
>>>>>>
>>>>>> 2010年2月15日15:48 Ando Noriaki:
>>>>>>>
>>>>>>> 安藤です
>>>>>>>
>>>>>>> 2810はwell knownではないので、まぁいいんじゃないでしょうか、
>>>>>>> というのが僕の考えです。
>>>>>>>
>>>>>>> 実は、マネージャ指定で使用する corbaloc 形式ですが、
>>>>>>> corbaloc:iiop::/
>>>>>>> ののデフォルトは 2809 です。(CORBAの仕様)
>>>>>>> でも、たいていのCORBAではネームサーバがこのポートを使っているので、
>>>>>>> 混乱を避けるために 2810 をデフォルトにしたというわけです。
>>>>>>>
>>>>>>> rtcdにネームサーバを内蔵してしまう、というのも解決策としてはありますね。
>>>>>>> javaのorbdは、実際ネームサーバとオブジェクトサーバを兼ねているようですし。
>>>>>>>
>>>>>>>
>>>>>>> 堀さんのおっしゃるようにポート番号を確保してそれを使うのが
>>>>>>> いいかもしれませんが、rtcd自体がパブリックなサービスとして
>>>>>>> 成立するかどうかもわからないので、とりあえず
>>>>>>>
>>>>>>> 「何も指定しないと2810番になるけど、使用する状況で適宜rtc.confで変更してください。」
>>>>>>>
>>>>>>> というところでどうでしょうか？
>>>>>>>
>>>>>>>
>>>>>>> 余談ですが、Linuxでは自由に使えるポートとして
>>>>>>> $ cat /proc/sys/net/ipv4/ip_local_port_range
>>>>>>> 32768 61000
>>>>>>>
>>>>>>> つまり、327680〜61000 となっているらしいです。
>>>>>>> FreeBSDとかだと、
>>>>>>>>
>>>>>>>> sysctl -a|grep portrange
>>>>>>>
>>>>>>> :
>>>>>>> net.inet.ip.portrange.last: 65535
>>>>>>> net.inet.ip.portrange.first: 49152
>>>>>>> :
>>>>>>> なんですけどね。
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2010年2月15日15:14 Toshio HORI:
>>>>>>>>
>>>>>>>> 安藤さん, 原さん,
>>>>>>>>
>>>>>>>> ポート番号の1024〜49151はwell-knownではありません。registered port
>>>>>>>> numbersとされています。
>>>>>>>>
>>>>>>>> ただ、well known portを*含めて*そのポート番号の使用は「SHOULD NOT」であっ
>>>>>>>> て「MUST NOT(あるいはSHALL NOT)」ではありません。「SHOULD NOT」は「NOT
>>>>>>>> RECOMMENDED」を意味するので(See RFC2119)、解釈としては安藤さんが正しい
>>>>>>>> です。
>>>>>>>>
>>>>>>>> もちろん、今のうちからIANAに登録してポート番号を確保しておくのが一番ス
>>>>>>>> マートな解だとは思います。
>>>>>>>>
>>>>>>>> …というメールを書いたところに原さんの次のメールが届きましたが、せっか
>>>>>>>> く書いたので送ってしまいます(笑)。
>>>>>>>>
>>>>>>>> // 堀俊夫, 博士(工学) / t.hori@aist.go.jp
>>>>>>>> // (独)産業技術総合研究所デジタルヒューマン研究センター主任研究員
>>>>>>>> //& OMG Robotics-DTF Robotic Functional Service WG共同座長
>>>>>>>> // Web: http://www.dh.aist.go.jp/members/toshi.php
>>>>>>>>
>>>>>>>> In
>>>>>>>> article,
>>>>>>>> Ando Noriaki writes:
>>>>>>>>>
>>>>>>>>> 原様
>>>>>>>>>
>>>>>>>>> 安藤です
>>>>>>>>>
>>>>>>>>> 固定というのは、デフォルトで2810番という意味で、
>>>>>>>>> 変更したい場合は、rtc.conf で
>>>>>>>>> corba.master_manager: localhost:49152
>>>>>>>>> のように指定してください。
>>>>>>>>>
>>>>>>>>> ちなみに、1024〜49151 は well known ポートではないので、
>>>>>>>>> 勝手に使ってはいけない、というほどの強制力はないですよね。
>>>>>>>>> OpenRTMがすごく広まったら、ちゃんと登録しないとだめかもしれませんが（笑
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2010年2月15日13:23 Isao Hara:
>>>>>>>>>>
>>>>>>>>>> 安藤様、皆様：
>>>>>>>>>>
>>>>>>>>>> 産総研の原です。
>>>>>>>>>> 下記のようにネームサーバーのポート番号が固定されているということですが、
>>>>>>>>>> 2810番のように49151番より下の番号は、勝手につかってはいけません。
>>>>>>>>>> IANAというところで管理しています。
>>>>>>>>>> また、2810は、
>>>>>>>>>> # Ted McFadden
>>>>>>>>>> netsteward 2810/tcp Active Net Steward
>>>>>>>>>> netsteward 2810/udp Active Net Steward
>>>>>>>>>>
>>>>>>>>>> のようにアプリケーションの登録がなされていますので、変更をお願いいたします。
>>>>>>>>>>
>>>>>>>>>> (2010/02/15 12:43), Ando Noriaki wrote:
>>>>>>>>>>>
>>>>>>>>>>> 菅様、皆さま
>>>>>>>>>>>
>>>>>>>>>>> 安藤です
>>>>>>>>>>>
>>>>>>>>>>> rtcdについて、まだドキュメントを書いていないので、
>>>>>>>>>>> いろいろ混乱させてしまいすみません。
>>>>>>>>>>> ドキュメントはもう少々お待ちください。
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 今回の件ですが、ネームサーバ上に残ったマネージャーのゾンビリファレンスが、
>>>>>>>>>>> そのごrtc.confでマネージャの登録名を変えたにもかかわらず復活してしまう
>>>>>>>>>>>
>>>>>>>>>>> ということでよろしいでしょうか。
>>>>>>>>>>>
>>>>>>>>>>> これは、簡潔に言いますと、マネージャーを INS 化したためで、
>>>>>>>>>>> 対処方法としては、ゾンビ化させないで、マネージャはshutdownコマンドで
>>>>>>>>>>> 終了させてください、ということになります。
>>>>>>>>>>>
>>>>>>>>>>> 以下、長文すみません。
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> さて，今回の問題ですが，追加報告です．
>>>>>>>>>>>> rtcdを使って現象をいくつか試していますが，
>>>>>>>>>>>> 以下の操作で再現されることがわかりました．
>>>>>>>>>>>>
>>>>>>>>>>>> 一言で表現すると，ゾンビーの復活です．
>>>>>>>>>>>>
>>>>>>>>>>>> 初回のrtcdの実行ではnaming_formatsを指定しない，
>>>>>>>>>>>> 以下のrtc.confで実行．
>>>>>>>>>>>>
>>>>>>>>>>>> corba.nameservers: localhost
>>>>>>>>>>>> naming.formats: %h.host_cxt/%n.rtc
>>>>>>>>>>>> logger.enable: NO
>>>>>>>>>>>> logger.log_level: PARANOID
>>>>>>>>>>>> manager.modules.load_path: ../examples/C++/, ../components/
>>>>>>>>>>>>
>>>>>>>>>>>> その後，rtcdを無理やり停止して，ゾンビーを残す．
>>>>>>>>>>>>
>>>>>>>>>>>> 次にrtc.confを加工する
>>>>>>>>>>>>
>>>>>>>>>>>> corba.nameservers: localhost
>>>>>>>>>>>> naming.formats: %h.host_cxt/%n.rtc
>>>>>>>>>>>> logger.enable: NO
>>>>>>>>>>>> logger.log_level: PARANOID
>>>>>>>>>>>> manager.naming_formats: %h.host_cxt/ysuga_net.app_cxt/%n.mgr
>>>>>>>>>>>> manager.modules.load_path: ../examples/C++/, ../components/
>>>>>>>>>>>>
>>>>>>>>>>>> 5行目を追加．そして実行すると，
>>>>>>>>>>>> ゾンビーだったmanager.mgrが復活する．
>>>>>>>>>>>> こちらからcreateを呼び出しても可能になってしまいます．
>>>>>>>>>>>>
>>>>>>>>>>>> 初回の起動でゾンビーがなければ意図通りに動作します．
>>>>>>>>>>>> また，逆の順序で実行しても同様の現象が起こります．
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 詳しく解説しますと、
>>>>>>>>>>>
>>>>>>>>>>> CORBAオブジェクトは、特に何もしていしなければ、生成されるたびに適当なKey (IDのようなもの)
>>>>>>>>>>> を持ったオブジェクトとして生成され、ネームサーバに登録されるリファレンスも、
>>>>>>>>>>> たとえ名前が同じであっても、生成されるたびに異なるKeyのオブジェクトとして
>>>>>>>>>>> 登録されます。
>>>>>>>>>>>
>>>>>>>>>>> たとえば、ConsoleIn コンポーネントを2回生成したとします。
>>>>>>>>>>> 1回目の生成では、以下のような参照がネームサーバに登録されます。
>>>>>>>>>>>
>>>>>>>>>>> 名前： ConsoleIn0.rtc 参照：(Key: 0x7183618368, IPアドレス： 192.168.1.10,
>>>>>>>>>>> ポート番号：3444)
>>>>>>>>>>>
>>>>>>>>>>> このプロセスを落として、もう一度起動します。次は、以下のような参照が登録されます。
>>>>>>>>>>>
>>>>>>>>>>> 名前： ConsoleIn0.rtc 参照：(Key: 0x8297427492, IPアドレス： 192.168.1.10,
>>>>>>>>>>> ポート番号：3653)
>>>>>>>>>>>
>>>>>>>>>>> 通常、複数回起動しても同じなのはIPアドレスと名前くらいで、Keyやポート番号はORBやOS
>>>>>>>>>>> の気分によって変わってしまいます(笑
>>>>>>>>>>>
>>>>>>>>>>> しかし、rtcdを-dオプション付きで起動すると、マネージャーはマスターマネージャ（後ほど解説します）となり、
>>>>>>>>>>> のKeyとポート番号が固定されます。(デフォルトでは Key は manager, ポート番号は 2810 になります。)
>>>>>>>>>>>
>>>>>>>>>>> つまり、マネージャーの名前は、以下のような参照としてネームサーバに登録されます。
>>>>>>>>>>>
>>>>>>>>>>> 名前： hsotname.host_cxt/manager.mgr 参照：(Key： manager, IPアドレス：
>>>>>>>>>>> 192.168.1.10, ポート番号：2810) ・・・ (1)
>>>>>>>>>>>
>>>>>>>>>>> ここで、マネージャーを強制終了すると、この名前の登録を掃除しないで終了するので、
>>>>>>>>>>> ネームサーバ上にこの名前がそのまま残ってしまいます。
>>>>>>>>>>> 次に、rtc.confでmanager.naming_formats を変更すると、
>>>>>>>>>>>
>>>>>>>>>>> 名前： hostname.host_cxt/ysuga_net.app_cxt/manager.mgr 参照：(Key：
>>>>>>>>>>> manager,
>>>>>>>>>>> IPアドレス： 192.168.1.10, ポート番号：2810) ・・・ (2)
>>>>>>>>>>>
>>>>>>>>>>> として、マネージャが登録されます。
>>>>>>>>>>>
>>>>>>>>>>> ここで、(1)と(2)の参照（ID、IP、ポート）を比べてみると、まったく同じになっています。
>>>>>>>>>>> したがって、(1)の参照にアクセスしても、(2)と同じオブジェクトにアクセスすることになります。
>>>>>>>>>>> そういうわけで、ゾンビ化したマネージャ(1)も、復活してしまう、というわけです。
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> なお、マネージャをこのようにIDやポート番号を固定したわけは、ネームサーバなして
>>>>>>>>>>> マネージャやコンポーネントにアクセスするためです。この辺は、以前松坂さんからご意見のあった、
>>>>>>>>>>> ネームサーバがシステムの single point of failure になることを避ける手段として
>>>>>>>>>>> ネームサーバに依存しないでシステムを構築する方法を提供したかったためです。
>>>>>>>>>>>
>>>>>>>>>>> こうすることでマネージャは corbaloc:iiop:hostname:port/manager という URL で常に
>>>>>>>>>>> アクセスできるようになります。ここでポート番号は固定で 2810 としているので、
>>>>>>>>>>> ホスト名さえ分かれば、そのノードのマスタマネージャにアクセスできることになります。
>>>>>>>>>>>
>>>>>>>>>>> ちなみに、こういうオブジェクトの名前付けを INS (Interoperable Naming Service) といいます。
>>>>>>>>>>>
>>>>>>>>>>> 以下は、log出力の例ですが、マネージャのIOR(オブジェクト参照)の情報は、
>>>>>>>>>>>
>>>>>>>>>>> Feb 15 10:35:40 DEBUG: ManagerServant: Manager's IOR information:
>>>>>>>>>>> IOR information
>>>>>>>>>>> Type ID: "IDL:RTM/Manager:1.0"
>>>>>>>>>>> Profiles:
>>>>>>>>>>> 1. IIOP 1.2 192.168.100.2 2810
>>>>>>>>>>> Object Key: "manager" = 0x6d616e61676572 (7 bytes)
>>>>>>>>>>> TAG_ORB_TYPE omniORB
>>>>>>>>>>> TAG_CODE_SETS char native code set: ISO-8859-1
>>>>>>>>>>> char conversion code set: UTF-8
>>>>>>>>>>> wchar native code set: UTF-16
>>>>>>>>>>> wchar conversion code set: UTF-16
>>>>>>>>>>>
>>>>>>>>>>> このように、Object Key が "manager" という人間が読める形式になっているのに対し、
>>>>>>>>>>> 以下は ConsoleIn をネームサーバに登録する際のIORなのですが、
>>>>>>>>>>>
>>>>>>>>>>> IOR information
>>>>>>>>>>> Type ID: "IDL:openrtm.aist.go.jp/OpenRTM/DataFlowComponent:1.0"
>>>>>>>>>>> Profiles:
>>>>>>>>>>> 1. IIOP 1.2 192.168.100.2 2810
>>>>>>>>>>> POA(root) Object Key: "...." = 0x00000000 (4 bytes)
>>>>>>>>>>> Object Key: "...xK........." =
>>>>>>>>>>> 0xfe94ba784b000015080000000000 (14 bytes)
>>>>>>>>>>> TAG_ORB_TYPE omniORB
>>>>>>>>>>> TAG_CODE_SETS char native code set: ISO-8859-1
>>>>>>>>>>> char conversion code set: UTF-8
>>>>>>>>>>> wchar native code set: UTF-16
>>>>>>>>>>> wchar conversion code set: UTF-16
>>>>>>>>>>>
>>>>>>>>>>> Object Key が 0xfe94ba784b000015080000000000 というORB (というかPOA) が
>>>>>>>>>>> 適当に付けた名前になっています。
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ついでですので、マネージャの使い方についても少し説明します。
>>>>>>>>>>>
>>>>>>>>>>> マネージャにはマスタとスレーブがあります。
>>>>>>>>>>>
>>>>>>>>>>> ・マスタマネージャ：
>>>>>>>>>>> 原則1ノードにつき1つだけ存在する。
>>>>>>>>>>> アプリケーション、ノードの外部などからは、マスターマネージャに対して
>>>>>>>>>>> コンポーネントの生成を依頼する。
>>>>>>>>>>> つまり、原則として、このマネージャ自身はコンポーネントを生成・管理しない。
>>>>>>>>>>> 実際のコンポーネントの生成は、マスタがスレーブマネージャに依頼する。
>>>>>>>>>>>
>>>>>>>>>>> ・スレーブマネージャ：
>>>>>>>>>>> 1ノードに複数存在できる。0個以上のマスターに所属することができる。
>>>>>>>>>>> rtcdを-dなしで起動した場合、マスターがすでに起動していればその配下に入る。
>>>>>>>>>>> コンポーネントはスレーブマネージャ上で生成・管理される。
>>>>>>>>>>> 原則、コンポーネントが存在しないスレーブマネージャは存在しない（自動でシャットダウンされる）。
>>>>>>>>>>> -> 菅さんがご指摘されたように、-d オプションなしのrtcdが自動で終了するのはこのためです。
>>>>>>>>>>> マスターマネージャからは、スレーブはポート番号で区別される。
>>>>>>>>>>> つまり、同一ポート番号のスレーブマネージャは、同一のプロセス（逆もしかり）である。
>>>>>>>>>>>
>>>>>>>>>>> コンポーネント生成の流れは、以下のようになります。
>>>>>>>>>>>
>>>>>>>>>>> 1) RTCが起動される可能性のあるノード上では、rtcd は -d オプション付きで起動されているものとします。
>>>>>>>>>>> ＃Linuxではれば、/etc/init.d 以下の起動スクリプトなどで起動されているイメージ。
>>>>>>>>>>>
>>>>>>>>>>> 2) 何らかのツール、コマンド、アプリケーションが、あるノードに対してコンポーネントを作成したい場合
>>>>>>>>>>> まず、そのノードのマスタマネージャのオブジェクトリファレンスを取得します。
>>>>>>>>>>> それは、ネームサーバからでもいいですし、corbaloc:iiop:hostname:2810/manager という URL を
>>>>>>>>>>> ORB::string_to_object() 関数を使ってダイレクトにアクセスしてもかまいません。
>>>>>>>>>>>
>>>>>>>>>>> 3) 何らかのツール、コマンド、アプリケーションが、あるノード上で、コンポーネントを起動する場合、
>>>>>>>>>>> そのノードのマスターマネージャに対して create_component() をコールします。
>>>>>>>>>>>
>>>>>>>>>>> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234")
>>>>>>>>>>>
>>>>>>>>>>> 4) manager=localhost:2811 はローカルホスト上の 2811版ポート上で ConsoleIn という
>>>>>>>>>>> コンポーネントを起動しなさい、という意味なので、マスターマネージャは、スレーブマネージャを
>>>>>>>>>>>
>>>>>>>>>>> 2811ポート上で起動し、そのマネージャに対して、create_component("ConsoleIn?instance_name=ConsoleIn1234")
>>>>>>>>>>> をコールします。
>>>>>>>>>>>
>>>>>>>>>>> 5) スレーブマネージャは、ポート2811上で起動し、ConsoleInを一つ生成します。
>>>>>>>>>>> このとき、インスタンス名はConsoleIn1234 に指定されているのでインスタンス名はこの名前になり、
>>>>>>>>>>> ネームサーバ上に登録される名前も、この名前になります。
>>>>>>>>>>>
>>>>>>>>>>> 6) さらに、同じプロセス上で、ConsoleIn を起動したければ、
>>>>>>>>>>>
>>>>>>>>>>> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1235")
>>>>>>>>>>> とをマスタマネージャに対してコールすればよく、異なるプロセスで起動したい場合は、
>>>>>>>>>>>
>>>>>>>>>>> mgr->create_component("ConsoleIn?manager=localhost:2812&instance_name=ConsoleIn1235")
>>>>>>>>>>> 等とすれば、別のプロセス上でConsoleInが起動します。
>>>>>>>>>>>
>>>>>>>>>>> 7) なお、そのノード上で起動しているコンポーネントの参照は、マスターマネージャから、
>>>>>>>>>>> mgr->get_components() によって取得できます。
>>>>>>>>>>> スレーブ上で起動しているすべてのコンポーネントの参照をマスターが収集して返しています。
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 一応、1.0-RELEASEのrtcdはこのような使い方を意図して実装されています。
>>>>>>>>>>> まだ、ツールの方でも対応しきれていないので、この使い方が実際利用できるのには
>>>>>>>>>>> 少々時間がかかると思いますが、RTSystemEditorやrtcshellなどで、
>>>>>>>>>>> 簡単にできるようにしていきたいと思います。
>>>>>>>>>>> ＃rtcshellについては、ジェフさんよろしく。
>>>>>>>>>>>
>>>>>>>>>>> あと、Windows上で起動したrtcdに、RTSystemEditorのmanager viewからアクセスすると、
>>>>>>>>>>> 非常に重いのですが、これはDLLからRTCのプロファイルを取得する操作がWindows
>>>>>>>>>>> 上ではなぜだか非常に遅いために発生しています。（Linuxだと一瞬で終わるのですが。。。）
>>>>>>>>>>> また、OpenCVをインストールしていない場合、RTCのプロファイルを取得する過程で、
>>>>>>>>>>> USBcamera*コンポーネントをアクセスした段階で、DLLのエラーダイアログが出てしまい
>>>>>>>>>>> アクセスがさらに遅くなってしまいます。
>>>>>>>>>>> OpenCVをインストールするか、USBCameda*.DLLを削除するかすると改善します。
>>>>>>>>>>>
>>>>>>>>>>

Tue, 2010-02-16 09:01

(Reply to #17) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01119] Managerのnamingformatの不具合

http-equiv="Content-Type">

菅様、安藤様、皆様：

ご意見ありがとうございます。

下記の議論ですが、産総研以外の方からご意見頂きたかったので敢えてMLに投げさせて

頂きました。

また、下記の件では私の方で少し勘違いがあったようです。私は、マスターマネージャーがNamingService

も行っていると思っていました。現在に実装では、異なるのですね。

それでは、2809を使うのは良くないと思います。しかし、適当なポートというのもいかがなものでしょうか？

将来的に、変わる可能性があるのは否めませんが、まず仕様をきちんと決めないといつまでたっても「まだ何者

なのかも明確になってない段階」が続くのではないでしょうか？

本来は、実装する前の段階で十分に議論し明確化をしないと、「まだ、検討段階なのね」といって使われない

気がします。

実際に、1.0のリリース前で、RCの段階でも十分使えることをアナウンスしても、企業の方にはなかなか

使って頂けなかったのでは？

また、ポート自体が何番でも良いのであれば、固定でなくてもよいのでは？NamingServerに登録されるのですから

多のオブジェクトは名前で参照で十分なはずではないでしょうか？

(10/02/16 1:38), Ando Noriaki wrote:

cite="mid:fc5ebb701002150838k41fa74dck37e71c48e1288e96@mail.gmail.com"
type="cite">

菅様、皆様

安藤です

ご意見ありがとうございます。

ポート番号の話ですが，ひとつお聞きしたいことがあります．
すみません，RTMの規格とか，よくわかっていないのかもしれません．
良ければ教えてください．

現状で原様，堀様，安藤様がお話している内容は，
RTミドルウエアの規格としてポート番号をとるのか否か，
という話なのでしょうか？

簡単にいえば、マスタマネージャのデフォルトポートが2810になってるけど、
それって、割り当て済みポート番号なので、まずいんじゃないの？ということです。
僕としては、rtcd なんてまだ実験段階なので、適当なポート番号で
いいんじゃないの？まずかったらrtc.confで変えられるんだし。という考え方です。

ただ，RTミドルウエア自体は，OMGでPIMで定義されている規格でしょうから，
本来はCORBAなどの通信層に依存しない規格のはずです．
たとえばEJBでの実装なんて可能なのでは？なんて思っていますが…

おっしゃる通り、OMGの仕様はPIMが基本です。ただし、OMGで決まっているのは
RTCの規格だけで、一方今回の話題はRTCを管理するRTMのサービスの一つである
マネージャについてです。いまのところ、マネージャについては標準は何も決まっていません。

そこで問題なのですが，
IPプロトコル前提のポート番号を登録する必要って何なのですか？
たとえばOpenRTM-aistの実装では，
既存CORBAサービスとの共存が難しいのですか？

現状、2809をrtcdが使うと、ネームサーバ（omniNames）は他の番号を使わないといけません。
＃複数のプロセス(=ORB)が一つのポートを共有することはできませんので。
rtcd上にマネージャとネームサービスを共存させることは原理的には可能です。
ネームサービスを自前で実装して、rtcd上でネームサービスオブジェクトを
生成してあげればいいだけですので。そうすると、

ネームサーバには、corbaloc:iiop:<host_name>:2809/NameService
マネージャには、corbaloc:iiop:<host_name>:2809/manager

でアクセスできるようになります。

ちなみに、ネームサーバ自体もどのポートがデフォルトかは、おそらく決まっていない
と思われます。決まっているのは、先ほど申し上げたように、

corbaloc:iiop:<host_name>:<port_number>/<obj_key>
というINSのURL指定時に、<port_number> が省略された時は 2809がデフォルトね、

とCORBAの仕様書に1行だけ書いてあることだけです。

omniNames はこれをネームサーバのデフォルトポート番号として利用しているだけで、
2809がデフォルトポートでないネームサーバを持つCORBA実装も存在します。

ならばそれはOpenRTM-aistの問題でしょうから，
ポートを登録していないと問題が起こるのは，
OpenRTM-aistですよね？

ポート番号自体は、何番でもよくて、しかも一般ユーザにはあまり関係ありません。
ミドルウエア（というかマネージャ）を実装する人、ツールを実装する人の間で
コンセンサスができていれば済む問題です。で、そういう人は普通、ドキュメント、
ソース、仕様書を隅々まで読むでしょうから、それほど混乱しないんじゃないでしょうか？

原さんのおっしゃるように、これらの「実装する人」というのが多くなったら
収集がつかなくなるから、いまのうちに登録して決めておいた方がいい、
というのは正論なのですが、そもそもrtcdあるいはマネージャって何？という、まだ
何者なのか仕様も明確になっていない段階で番号を登録する必要性をそれほど感じません。

また、上で菅さんがおっしゃったように、RTCおよびRTMにはEJB実装とか、.NET remote実装
などといった様々なPSMが考えられます。（実際、セックの池添さんは.NET remote版など
も実装されていたりします。）そうしたときに、実装毎にマネージャがある場合には、
それぞれにポート番号が必要になりますが、その場合はどうしたらいいでしょうか？

さらに、X Window Systemのように、複数のポート番号をまとめて確保するのか、
一つだけでいいのか、といったことも現状では確定していません。
rtcdの使い方でも書きましたが、マスタマネージャだけでなく、スレーブもポート番号を
明示してやる必要があるので、本当ならスレーブのための番号も確保すべきでしょう。

そこらへんで，どのレベルで議論されているのか，
はたから見て良くわかりませんでした．すみません．

もし，ポート番号取得の必要性があるなら，
それは絶対に取るべきだと思います．
デファクトではなく，デジュレを行くのが
RTミドルウエアの本道だと思います．

現在、OMGのRobotics DTFのInfra.WGでRTC Deployment and Dynamic Reconfiguration
という、RTCのマネージャやディレクトリサービスに関する標準を作ろうとしているところです。
（これには、今日、松坂さんからの質問に返答した際に添付したRTCProfileやRTSProfileなどの
仕様記述方式も含まれる予定です。）

その仕様では、rtcdで実装しているマネージャのようなものや、ネームサービスのようなものの
仕様が正式に策定される見込みですが、そうなったら、「CORBA PSMの場合のマネージャ
のデフォルトポートはxxxx番です」という文言を仕様に盛り込むというのも意味があるかもしれません。

ただし、それも可能かどうかは、一緒に標準化を進めている韓国グループの意向
（彼らはCORBAを使っていません）や、その他標準化に関わる組織の意向等が
関わってくるので、なんとも言えません。

そういうわけで、もしポート番号を正式に登録するとしても、
標準化の仕様策定が進んでからにしたほうがいいのではないでしょうか。

なんて，偉そうなことを言ってしまってすみません．

ではでは

Tue, 2010-02-16 11:44

(Reply to #18) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01120] Managerのnamingformatの不具合

安藤です

将来的に番号を取得する方向で考えたいと思います。
8568番がちょうど？空いています。

2010年2月16日9:01 Isao Hara :
> 菅様、安藤様、皆様：
>
> ご意見ありがとうございます。
> 下記の議論ですが、産総研以外の方からご意見頂きたかったので敢えてMLに投げさせて
> 頂きました。
>
> また、下記の件では私の方で少し勘違いがあったようです。私は、マスターマネージャーがNamingService
> も行っていると思っていました。現在に実装では、異なるのですね。
> それでは、2809を使うのは良くないと思います。しかし、適当なポートというのもいかがなものでしょうか？
> 将来的に、変わる可能性があるのは否めませんが、まず仕様をきちんと決めないといつまでたっても「まだ何者
> なのかも明確になってない段階」が続くのではないでしょうか？
> 本来は、実装する前の段階で十分に議論し明確化をしないと、「まだ、検討段階なのね」といって使われない
> 気がします。
> 実際に、1.0のリリース前で、RCの段階でも十分使えることをアナウンスしても、企業の方にはなかなか
> 使って頂けなかったのでは？
>
> また、ポート自体が何番でも良いのであれば、固定でなくてもよいのでは？NamingServerに登録されるのですから
> 多のオブジェクトは名前で参照で十分なはずではないでしょうか？
>
> (10/02/16 1:38), Ando Noriaki wrote:
>
> 菅様、皆様
> 安藤です
> ご意見ありがとうございます。
>
>
> ポート番号の話ですが，ひとつお聞きしたいことがあります．
> すみません，RTMの規格とか，よくわかっていないのかもしれません．
> 良ければ教えてください．
> 現状で原様，堀様，安藤様がお話している内容は，
> RTミドルウエアの規格としてポート番号をとるのか否か，
> という話なのでしょうか？
>
>
> 簡単にいえば、マスタマネージャのデフォルトポートが2810になってるけど、
> それって、割り当て済みポート番号なので、まずいんじゃないの？ということです。
> 僕としては、rtcd なんてまだ実験段階なので、適当なポート番号で
> いいんじゃないの？まずかったらrtc.confで変えられるんだし。という考え方です。
>
>
> ただ，RTミドルウエア自体は，OMGでPIMで定義されている規格でしょうから，
> 本来はCORBAなどの通信層に依存しない規格のはずです．
> たとえばEJBでの実装なんて可能なのでは？なんて思っていますが…
>
>
> おっしゃる通り、OMGの仕様はPIMが基本です。ただし、OMGで決まっているのは
> RTCの規格だけで、一方今回の話題はRTCを管理するRTMのサービスの一つである
> マネージャについてです。いまのところ、マネージャについては標準は何も決まっていません。
>
>
> そこで問題なのですが，
> IPプロトコル前提のポート番号を登録する必要って何なのですか？
> たとえばOpenRTM-aistの実装では，
> 既存CORBAサービスとの共存が難しいのですか？
>
>
> 現状、2809をrtcdが使うと、ネームサーバ（omniNames）は他の番号を使わないといけません。
> ＃複数のプロセス(=ORB)が一つのポートを共有することはできませんので。
> rtcd上にマネージャとネームサービスを共存させることは原理的には可能です。
> ネームサービスを自前で実装して、rtcd上でネームサービスオブジェクトを
> 生成してあげればいいだけですので。そうすると、
> ネームサーバには、corbaloc:iiop::2809/NameService
> マネージャには、corbaloc:iiop::2809/manager
> でアクセスできるようになります。
> ちなみに、ネームサーバ自体もどのポートがデフォルトかは、おそらく決まっていない
> と思われます。決まっているのは、先ほど申し上げたように、
> corbaloc:iiop::/
> というINSのURL指定時に、が省略された時は 2809がデフォルトね、
> とCORBAの仕様書に1行だけ書いてあることだけです。
> omniNames はこれをネームサーバのデフォルトポート番号として利用しているだけで、
> 2809がデフォルトポートでないネームサーバを持つCORBA実装も存在します。
>
>
> ならばそれはOpenRTM-aistの問題でしょうから，
> ポートを登録していないと問題が起こるのは，
> OpenRTM-aistですよね？
>
>
> ポート番号自体は、何番でもよくて、しかも一般ユーザにはあまり関係ありません。
> ミドルウエア（というかマネージャ）を実装する人、ツールを実装する人の間で
> コンセンサスができていれば済む問題です。で、そういう人は普通、ドキュメント、
> ソース、仕様書を隅々まで読むでしょうから、それほど混乱しないんじゃないでしょうか？
> 原さんのおっしゃるように、これらの「実装する人」というのが多くなったら
> 収集がつかなくなるから、いまのうちに登録して決めておいた方がいい、
> というのは正論なのですが、そもそもrtcdあるいはマネージャって何？という、まだ
> 何者なのか仕様も明確になっていない段階で番号を登録する必要性をそれほど感じません。
> また、上で菅さんがおっしゃったように、RTCおよびRTMにはEJB実装とか、.NET remote実装
> などといった様々なPSMが考えられます。（実際、セックの池添さんは.NET remote版など
> も実装されていたりします。）そうしたときに、実装毎にマネージャがある場合には、
> それぞれにポート番号が必要になりますが、その場合はどうしたらいいでしょうか？
> さらに、X Window Systemのように、複数のポート番号をまとめて確保するのか、
> 一つだけでいいのか、といったことも現状では確定していません。
> rtcdの使い方でも書きましたが、マスタマネージャだけでなく、スレーブもポート番号を
> 明示してやる必要があるので、本当ならスレーブのための番号も確保すべきでしょう。
>
>
> そこらへんで，どのレベルで議論されているのか，
> はたから見て良くわかりませんでした．すみません．
> もし，ポート番号取得の必要性があるなら，
> それは絶対に取るべきだと思います．
> デファクトではなく，デジュレを行くのが
> RTミドルウエアの本道だと思います．
>
>
> 現在、OMGのRobotics DTFのInfra.WGでRTC Deployment and Dynamic Reconfiguration
> という、RTCのマネージャやディレクトリサービスに関する標準を作ろうとしているところです。
> （これには、今日、松坂さんからの質問に返答した際に添付したRTCProfileやRTSProfileなどの
> 仕様記述方式も含まれる予定です。）
> その仕様では、rtcdで実装しているマネージャのようなものや、ネームサービスのようなものの
> 仕様が正式に策定される見込みですが、そうなったら、「CORBA PSMの場合のマネージャ
> のデフォルトポートはxxxx番です」という文言を仕様に盛り込むというのも意味があるかもしれません。
> ただし、それも可能かどうかは、一緒に標準化を進めている韓国グループの意向
> （彼らはCORBAを使っていません）や、その他標準化に関わる組織の意向等が
> 関わってくるので、なんとも言えません。
> そういうわけで、もしポート番号を正式に登録するとしても、
> 標準化の仕様策定が進んでからにしたほうがいいのではないでしょうか。
>
>
> なんて，偉そうなことを言ってしまってすみません．
> ではでは

Mon, 2010-02-15 22:05

(Reply to #19) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01113] Managerのnamingformatの不具合

安藤様、皆様

ジェフです。

rtcshellではマネージャはまだネームサーバだけでアクセスできます。ただいま以下の流れを試しました：

$ rtmgr manager.mgr load
/home/geoff/share/OpenRTM-aist/examples/rtcs/ConsoleIn.so ConsoleInInit
$ rtcat manager.mgr
Name: manager
Instance name: manager
Process ID: 29600
Naming format: %h.host_cxt/%n.mgr
Refstring path: /var/log/rtcmanager.ref
Components precreate:
Modules:
Load path: ./
Config path:
Preload:
Init function prefix:
Init function suffix:
Download allowed:
Absolute path allowed: YES
OS:
Version: #2 SMP PREEMPT Thu Feb 4 08:08:28 JST 2010
Architecture: x86_64
Release: 2.6.31-gentoo-r6-gb
Host name: odyssey
Name: Linux
Loaded modules:
Filepath: /home/geoff/share/OpenRTM-aist/examples/rtcs/ConsoleIn.so
Loadable modules:
$ rtmgr manager.mgr create
ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234
[1] 29698
$
[1]+ Done rtmgr manager.mgr create
ConsoleIn?manager=localhost:2811
$ rtls ../
odyssey.host_cxt/ ConsoleIn0.rtc

コンポーネントは作成していますが、名前はConsoleIn1234ではなくてConsoleIn0です。そして、netstatに見たら、ポート2811には何もありません。たぶんConsoleIn0はマスターマネージャに機動しています。

次のバージョンをちゃんと以下のように使えるようにしたいと思います。

ところで、githubからrtcshellの一番新しいバージョンをダウンロードしたら、rtdelでゾンビーを消すことができます。

On Mon, 15 Feb 2010 12:43 +0900, "Ando Noriaki"
wrote:
> コンポーネント生成の流れは、以下のようになります。
>
> 1) RTCが起動される可能性のあるノード上では、rtcd は -d オプション付きで起動されているものとします。
> ＃Linuxではれば、/etc/init.d 以下の起動スクリプトなどで起動されているイメージ。
>
> 2) 何らかのツール、コマンド、アプリケーションが、あるノードに対してコンポーネントを作成したい場合
> 　まず、そのノードのマスタマネージャのオブジェクトリファレンスを取得します。
> 　それは、ネームサーバからでもいいですし、corbaloc:iiop:hostname:2810/manager という URL を
> ORB::string_to_object() 関数を使ってダイレクトにアクセスしてもかまいません。
>
> 3) 何らかのツール、コマンド、アプリケーションが、あるノード上で、コンポーネントを起動する場合、
> 　そのノードのマスターマネージャに対して create_component() をコールします。
> 　mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234")
>
> 4) manager=localhost:2811 はローカルホスト上の 2811版ポート上で ConsoleIn という
> 　コンポーネントを起動しなさい、という意味なので、マスターマネージャは、スレーブマネージャを
> 　2811ポート上で起動し、そのマネージャに対して、create_component("ConsoleIn?instance_name=ConsoleIn1234")
> をコールします。
>
> 5) スレーブマネージャは、ポート2811上で起動し、ConsoleInを一つ生成します。
> 　このとき、インスタンス名はConsoleIn1234 に指定されているのでインスタンス名はこの名前になり、
> 　ネームサーバ上に登録される名前も、この名前になります。
>
> 6) さらに、同じプロセス上で、ConsoleIn を起動したければ、
> mgr->create_component("ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1235")
> とをマスタマネージャに対してコールすればよく、異なるプロセスで起動したい場合は、
> mgr->create_component("ConsoleIn?manager=localhost:2812&instance_name=ConsoleIn1235")
> 等とすれば、別のプロセス上でConsoleInが起動します。
>
> 7) なお、そのノード上で起動しているコンポーネントの参照は、マスターマネージャから、
> mgr->get_components() によって取得できます。
> 　スレーブ上で起動しているすべてのコンポーネントの参照をマスターが収集して返しています。
>
>
> 一応、1.0-RELEASEのrtcdはこのような使い方を意図して実装されています。
> まだ、ツールの方でも対応しきれていないので、この使い方が実際利用できるのには
> 少々時間がかかると思いますが、RTSystemEditorやrtcshellなどで、
> 簡単にできるようにしていきたいと思います。
> ＃rtcshellについては、ジェフさんよろしく。

Mon, 2010-02-15 22:25

(Reply to #20) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01114] Managerのnamingformatの不具合

ジェフ様

安藤です

> $ rtmgr manager.mgr create
> ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234
> [1] 29698
> $
> [1]+ Done rtmgr manager.mgr create
> ConsoleIn?manager=localhost:2811
> $ rtls ../
> odyssey.host_cxt/ ConsoleIn0.rtc

この部分ですが、?や&がshellでextractされてませんか？
single quote などで囲まないと、引数として正しく渡らないのでは？

$ rtmgr manager.mgr create
'ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234'

Mon, 2010-02-15 22:40

(Reply to #21) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01115] Managerのnamingformatの不具合

安藤様

ジェフです。

やっぱりそうですね。（まだ時差ぼけあるでしょうか？;）

$ rtmgr manager.mgr create
'ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234'
$ rtls ../
odyssey.host_cxt/ ConsoleIn1234.rtc

netstatにはポート2811はまだ出力されませんけど。スレーブマネージャはlistenしますか？

On Mon, 15 Feb 2010 22:25 +0900, "Ando Noriaki"
wrote:
> ジェフ様
>
> 安藤です
>
> > $ rtmgr manager.mgr create
> > ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234
> > [1] 29698
> > $
> > [1]+ Done rtmgr manager.mgr create
> > ConsoleIn?manager=localhost:2811
> > $ rtls ../
> > odyssey.host_cxt/ ConsoleIn0.rtc
>
> この部分ですが、?や&がshellでextractされてませんか？
> single quote などで囲まないと、引数として正しく渡らないのでは？
>
> $ rtmgr manager.mgr create
> 'ConsoleIn?manager=localhost:2811&instance_name=ConsoleIn1234'
>
>

Tue, 2010-02-16 00:13

(Reply to #22) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01117] Managerのnamingformatの不具合

ジェフさん

安藤です

Windowsで試しましたが、コンポーネントは別プロセスで起動できました。
netstatの出力結果は以下の通りです。タスクマネージャで見ても、
rtcdが2つ起動していました。

C:\Python26\Scripts>setns
C:\Python26\Scripts>set RTCTREE_NAMESERVERS=localhost
C:\Python26\Scripts>rtls
[01;34mlocalhost/ [00m
C:\Python26\Scripts>rtcwd localhost
C:\Python26\Scripts>rtls
[01;34mcf-y7.host_cxt/ [00m [01;34mmanager.mgr/ [00m
C:\Python26\Scripts>rtmgr manager.mgr create "ConsoleIn?manager=localhost:42000&
instance_name=ConsoleIn42000"
C:\Python26\Scripts>netstat -a
Active Connections
Proto Local Address Foreign Address State
TCP cf-y7:epmap cf-y7:0 LISTENING
TCP cf-y7:microsoft-ds cf-y7:0 LISTENING
TCP cf-y7:902 cf-y7:0 LISTENING
TCP cf-y7:912 cf-y7:0 LISTENING
TCP cf-y7:2809 cf-y7:0 LISTENING
TCP cf-y7:2810 cf-y7:0 LISTENING
TCP cf-y7:2869 cf-y7:0 LISTENING
TCP cf-y7:3389 cf-y7:0 LISTENING
TCP cf-y7:5027 cf-y7:0 LISTENING
TCP cf-y7:6000 cf-y7:0 LISTENING
TCP cf-y7:42000 cf-y7:0 LISTENING
　略
C:\Python26\Scripts>

ちなみに、rtc.conf で
manager.modules.load_path: ../examples/C++/
のように、DLLやsoへのパスを通しておけば、loadしなくてもcreateできます。
あと、rtcd と rtcprof にパスが通っていますか？

rtcshell　を Windows でいじってみたのですが、以下の部分を直さないと動きませんでした。
僕の環境だけでしょうか？
１) settmp.bat 内で環境変数をセットしてますが" が入ると動かない
set RTCSH_CWD="/localhost" ・・・×
set RTCSH_CWD=/localhost ・・・○

２） rtcwd.bat 内で引数を rtcwd.pyに渡していない。
３） rtmgr.py のmainの引数args？argv?が使われていない
　これはもしかして勘違いかもしれませんが。parsargs が直接 sys.argv から
　引数を取ってる？
４） Windowsとは関係ありませんが、Linuxでは環境変数をセットするのに
　export を使っていますね。csh系で動かないのは僕としてはちょっと悲しいです（笑

以下は差分です。Linuxでは動かないかもしれませんがとりあえず。。。

Mon, 2010-03-08 18:16

(Reply to #23) Permalink

root

Offline

Last seen: 1 day 7 hours ago

Joined: 2009-06-23 14:31

[openrtm-users 01152] Managerのnamingformatの不具合

安藤様

ジェフです。

ご報告ありがとうございます。「del settmp.bat」の問題以外は直しました。新
しいバージョンはgithubでチェックアウトできます。

On 16/02/10 00:13, Ando Noriaki wrote:
> ジェフさん
>
> 安藤です
>
> rtcshell　を Windows でいじってみたのですが、以下の部分を直さないと動きませんでした。
> 僕の環境だけでしょうか？
> １) settmp.bat 内で環境変数をセットしてますが" が入ると動かない
> set RTCSH_CWD="/localhost" ・・・×
> set RTCSH_CWD=/localhost ・・・○
>
> ２） rtcwd.bat 内で引数を rtcwd.pyに渡していない。
> ３） rtmgr.py のmainの引数args？argv?が使われていない
> 　これはもしかして勘違いかもしれませんが。parsargs が直接 sys.argv から
> 　引数を取ってる？
> ４） Windowsとは関係ありませんが、Linuxでは環境変数をセットするのに
> 　export を使っていますね。csh系で動かないのは僕としてはちょっと悲しいです（笑
>
> あと、最後の del settmp.bat で settmp.bat がなぜか削除されていないみたいです。

RT-Component	153.5
RT-Middleware	35
Tools	22
Documentation	2

OpenRTM-aist

[openrtm-users 01095] Managerのnamingformatの不具合

Download

latest Releases : 2.0.0-RELESE

Number of Projects

Choreonoid

OpenHRP3

OpenRTP

AIST RTC collection

TORK

DAQ-Middleware

Navigation

News

About us

Search form

Download

latest Releases : 2.0.0-RELESE

Number of Projects

Choreonoid

OpenHRP3

OpenRTP

AIST RTC collection

TORK

DAQ-Middleware