産総研　清水様、安藤様

中央大学の小島です。
ご教授ありがとうございます。

> > サービスポートでのサービス実装は、
> > CORBAサーバントそのままですので、
> > 当然、競合状態があることを前提で
> > ユーザが実装すべきだと私は思います。
> > 私の場合、リエントラントでないサービスの実装を
> > するときは、mutexでロックをかけるようにしています。
>
> 私も、サービスのプロバイダ側の実装はそうすべきだと思います。
>

そうですね。当然、競合状態のことをかんがえて設計すべきですね。
基本的なことだったようで恐縮です。競合状態の解消については、mutexを使うことでひとまず解決したいと思います。

ただ、質問したような問題に関しては、mutexにより解決ができますが、別の問題として
接続コンポーネントが増えると、ロックを待ち状態の時間は必然的に増えてしまうと思います。
そうなると、高速な制御周期を持つようなコンポーネントを接続した場合、問題を引き起こしかねないのではないでしょうか。
（この問題についても設計について議論があるかとおもいますが・・・）

また、今後、そういったコンポーネントは、作成者が必ずしも使うわけではないと思いますので、
あらかじめ、接続制限をしておくことで、このような問題を回避できるのではと思います。

> > > 中略
>
> ただし、ポート(プロバイダインターフェースではなく)自身には、何らかの接続制限
> を行う機能があってもよいのではないかと考えています。
> 次のバージョンではそういった機能も入れたいと思います。

是非入れていただけると、幸いです。

> いま、考えているのは、rtc.confないしはコンポーネントごとのconfigurationファイルに
>
> rtc.conf
> # 接続を2接続まで許す
> mycomponent.port.port0.max_connection: 2
> # 接続制限なし
> mycomponent.port.port1.max_connection: -1
>
> このように記述することで、接続数に制限をかけられるようする方法です。
>
> これ以外にも何かいい方法がありましたら是非ともアドバイス
> 頂ければと存じます。

可能であれば、rtc.confなどで設定するだけでなく、ソースファイルにも、接続数の制限ができることは実装できませんでしょうか？
その方が、作成時に仕様を決定でき、作成者の意図を反映しやすいのではないでしょうか？

他にもあればいいなと思うことは、
識別キーが一致しなければ、接続できないような仕組みもあってもいいのではないでしょうか？

現在のポートですと、同じ型のインターフェースであれば、接続可能です。
しかし、場合によっては、用途が違うため接続したくないこともあるでしょうし、
セキュリティ上の問題で、接続させたくないこともあると思います。

とくにセキュリティを欠けたい場合には、定期的に変更する必要があるので、
インターフェース型を変えて接続できないというような実装よりも、
識別キーを変更することで接続できなくなるような仕組みの方が
保守性が高いと思いましたが、いかがでしょうか？

既にお考えかもしれませんし、勉強はしているのですが
まだまだ知識も足りないため、的はずれなことを言っていたら
申し訳ございません。

今後ともよろしくお願いいたします。