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

Ando Noriaki n-ando @ aist.go.jp
2010年 2月 16日 (火) 01:38:04 JST


菅様、皆様

安藤です

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

> ポート番号の話ですが,ひとつお聞きしたいことがあります.
> すみません,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を使っていません)や、その他標準化に関わる組織の意向等が
関わってくるので、なんとも言えません。

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



> なんて,偉そうなことを言ってしまってすみません.
>
> ではでは
>
> /***************************************
>  * 菅 佑樹
>  * ysuga @ ysuga.net
>  * http://www.ysuga.net
>  * お知らせ: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<C93F4A2A-3DE5-4D93-948B-BDB6A635AC2F @ aist.go.jp>,
>>>        原 功<isao-hara @ aist.go.jp>  writes:
>>>>
>>>> 安藤さん:
>>>>
>>>> 原です。下記の件ですが、Well-known portではなくて、registered port であることは、
>>>> 知っています。(流れで書いていました。。。。)
>>>> また、Must Notであることもわかっています。ただ、2810がすでに登録済みであり、
>>>> このまま、2810を使い続けても、登録できないならば、変更した方がよいと思っていました。
>>>> 現在の実装では、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<isao-hara @ aist.go.jp>:
>>>>>>
>>>>>> 安藤さん:
>>>>>>
>>>>>> 原です。下記の件ですが、。2810は、すでにWell Known Portです。
>>>>>> そのため、前のメールを書いた次第です。
>>>>>> 競合を避けるために、やはり別ポートを登録して、変更しべきだと思います。
>>>>>>
>>>>>> 結局、登録しないまま、別ポートにしても後で登録されて、こちらが非登録&競合
>>>>>> という状態はよくないと思います。
>>>>>>
>>>>>> 標準実装の1つにするんでしょう?
>>>>>>
>>>>>>
>>>>>> 2010年2月15日15:48 Ando Noriaki<n-ando @ aist.go.jp>:
>>>>>>>
>>>>>>> 安藤です
>>>>>>>
>>>>>>> 2810はwell knownではないので、まぁいいんじゃないでしょうか、
>>>>>>> というのが僕の考えです。
>>>>>>>
>>>>>>> 実は、マネージャ指定で使用する corbaloc 形式ですが、
>>>>>>> corbaloc:iiop:<host_name>:<port_number>/<key>
>>>>>>> の<port_number>  のデフォルトは 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<t.hori @ aist.go.jp>:
>>>>>>>>
>>>>>>>> 安藤さん, 原さん,
>>>>>>>>
>>>>>>>> ポート番号の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<fc5ebb701002142127w54697cd2ka219dfa106fee3f3 @ mail.gmail.com>,
>>>>>>>>      Ando Noriaki<n-ando @ aist.go.jp>  writes:
>>>>>>>>>
>>>>>>>>> 原様
>>>>>>>>>
>>>>>>>>> 安藤です
>>>>>>>>>
>>>>>>>>> 固定というのは、デフォルトで2810番という意味で、
>>>>>>>>> 変更したい場合は、rtc.conf で
>>>>>>>>> corba.master_manager: localhost:49152
>>>>>>>>> のように指定してください。
>>>>>>>>>
>>>>>>>>> ちなみに、1024〜49151 は well known ポートではないので、
>>>>>>>>> 勝手に使ってはいけない、というほどの強制力はないですよね。
>>>>>>>>> OpenRTMがすごく広まったら、ちゃんと登録しないとだめかもしれませんが(笑
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2010年2月15日13:23 Isao Hara<isao-hara @ aist.go.jp>:
>>>>>>>>>>
>>>>>>>>>> 安藤様、皆様:
>>>>>>>>>>
>>>>>>>>>> 産総研の原です。
>>>>>>>>>> 下記のようにネームサーバーのポート番号が固定されているということですが、
>>>>>>>>>> 2810番のように49151番より下の番号は、勝手につかってはいけません。
>>>>>>>>>> IANAというところで管理しています。
>>>>>>>>>> また、2810は、
>>>>>>>>>> #                          Ted McFadden<mcfadden&dstc.edu.au>
>>>>>>>>>> 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を削除するかすると改善します。
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>>> 産業技術総合研究所 知能システム研究部門 インタラクションモデリングG
>>>>>>>>>> 主任研究員 原  功<Isao-Hara @ aist.go.jp>
>>>>>>>>>> Isao HARA, Senior Researcher, ISRI, AIST,Japan
>>>>>>>>>> TEL: +81-29-861-5973       FAX: +81-29-862-6631
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 安藤慶昭@独立行政法人産業技術総合研究所 知能システム研究部門
>>>>>>>>>   統合知能研究グループ 主任研究員, 博士(工学)
>>>>>>>>>   〒305-8568 つくば市梅園1-1-1 中央第2
>>>>>>>>>   e-mail: n-ando @ aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>>>>>>>>   OpenRTM-aist: http://www.openrtm.org
>>>>>>>>>
>>>>>>>>> Noriaki Ando, Ph.D.
>>>>>>>>>   Senior Research Scientist, RT-Synthesis R.G., ISRI, AIST
>>>>>>>>>   AIST Tsukuba Central 2, Tsukuba, Ibaraki 305-8568 JAPAN
>>>>>>>>>   e-mail: n-ando @ aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>>>>>>>>   OpenRTM-aist: http://www.openrtm.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 安藤慶昭@独立行政法人産業技術総合研究所 知能システム研究部門
>>>>>>>  統合知能研究グループ 主任研究員, 博士(工学)
>>>>>>>  〒305-8568 つくば市梅園1-1-1 中央第2
>>>>>>>  e-mail: n-ando @ aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>>>>>>  OpenRTM-aist: http://www.openrtm.org
>>>>>>>
>>>>>>> Noriaki Ando, Ph.D.
>>>>>>>  Senior Research Scientist, RT-Synthesis R.G., ISRI, AIST
>>>>>>>  AIST Tsukuba Central 2, Tsukuba, Ibaraki 305-8568 JAPAN
>>>>>>>  e-mail: n-ando @ aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>>>>>>  OpenRTM-aist: http://www.openrtm.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ---------
>>>>>> 産業技術総合研究所  知能システム研究部門
>>>>>> インタラクションモデリングG
>>>>>> 主任研究員 原  功<Isao-Hara @ aist.go.jp>
>>>>>> Isao HARA, Senior Research Scientist, ISRI, AIST, Japan
>>>>>> Phone: +81-29-861-5973     Fax: +81-29-862-6631
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 安藤慶昭@独立行政法人産業技術総合研究所 知能システム研究部門
>>>>>   統合知能研究グループ 主任研究員, 博士(工学)
>>>>>   〒305-8568 つくば市梅園1-1-1 中央第2
>>>>>   e-mail: n-ando @ aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>>>>   OpenRTM-aist: http://www.openrtm.org
>>>>>
>>>>> Noriaki Ando, Ph.D.
>>>>>   Senior Research Scientist, RT-Synthesis R.G., ISRI, AIST
>>>>>   AIST Tsukuba Central 2, Tsukuba, Ibaraki 305-8568 JAPAN
>>>>>   e-mail: n-ando @ aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>>>>   OpenRTM-aist: http://www.openrtm.org
>>>>>
>>>>
>>>> ---------
>>>> 産業技術総合研究所  知能システム研究部門
>>>> インタラクションモデリングG
>>>> 主任研究員 原  功<Isao-Hara @ aist.go.jp>
>>>> Isao HARA, Senior Research Scientist, ISRI, AIST, Japan
>>>> Phone: +81-29-861-5973     Fax: +81-29-862-6631
>>>>
>>>>
>>>>
>>>
>>>
>>
>> ---------
>> 産業技術総合研究所  知能システム研究部門
>> インタラクションモデリングG
>> 主任研究員 原  功<Isao-Hara @ aist.go.jp>
>> Isao HARA, Senior Research Scientist, ISRI, AIST, Japan
>> Phone: +81-29-861-5973     Fax: +81-29-862-6631
>>
>>
>>
>>
>> __________ Information from ESET NOD32 Antivirus, version of virus
>> signature database 4867 (20100215) __________
>>
>> The message was checked by ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>>
>>
>>
>
>



-- 
安藤慶昭@独立行政法人産業技術総合研究所 知能システム研究部門
    統合知能研究グループ 主任研究員, 博士(工学)
    〒305-8568 つくば市梅園1-1-1 中央第2
    e-mail: n-ando @ aist.go.jp, web: http://staff.aist.go.jp/n-ando
    OpenRTM-aist: http://www.openrtm.org

Noriaki Ando, Ph.D.
    Senior Research Scientist, RT-Synthesis R.G., ISRI, AIST
    AIST Tsukuba Central 2, Tsukuba, Ibaraki 305-8568 JAPAN
    e-mail: n-ando @ aist.go.jp, web: http://staff.aist.go.jp/n-ando
    OpenRTM-aist: http://www.openrtm.org



openrtm-users メーリングリストの案内