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

Isao Hara isao-hara ＠ aist.go.jp
2010年 2月 16日 (火) 09:01:31 JST 

菅様、安藤様、皆様：

ご意見ありがとうございます。
下記の議論ですが、産総研以外の方からご意見頂きたかったので敢えて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:<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ミドルウエア始めました
>>  ***************************************/
>>     

-- 

------------------------------------------------------------

産業技術総合研究所 　知能システム研究部門　インタラクションモデリングG

主任研究員 原 功 <Isao-Hara ＠ aist.go.jp <mailto:Isao-Hara ＠ aist.go.jp>>

Isao HARA, Senior Researcher, ISRI, ,AIST,Japan

TEL: +81-29-861-5973 FAX: +81-29-862-6631

-------------- next part --------------
HTMLの添付ファイルを保管しました...
URL: <http://www.openrtm.org/pipermail/openrtm-users/attachments/20100216/ac6d5402/attachment-0001.html>

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