えちょ記

語らないブログ

SHIORI PLUGIN

SHIORI

昨日の仕様書だけだと、関係者以外ではさっぱりわけがわからないので。
.NETでSHIORIを作っています。アンマネージ＜＞マネージ境界を繋ぐためにラッパーDLLを間に入れることで実装を実現しているのですが、SHIORIの仕様上において問題が発生するポイントがあります。ラッパーDLL自体のネットワーク更新が出来ないのです。

前提となる制約条件

「マネージDLLのアンロードは、アプリケーションドメイン単位でしか行われない」。一旦読み込んだマネージDLLは、読み込まれたアプリケーションドメイン自体が破棄されるまでその開放が行われません。これは.NETフレームワークの仕様であり、制約となります。

ラッパーDLLの役割と制約

その役割は、「ゴースト専用のアプリケーションドメインを作成し、そこにマネージ実装DLLを読み込むこと」です。SHIORI APIのアンロードが発生した場合、ゴースト専用ドメインは開放されますので、その段階で実装DLLは開放されます。
しかし、ラッパーDLL自体は当然ながら本体のアプリケーションドメインに属することになります。したがって一旦読み込まれたら最後、アンマネージDLLのようにフリーライブラリを実行したとしても、マネージ部分が開放されないためDLLファイル本体はずっと本体が起動した状態のままになります。

ネットワーク更新とゴースト削除の問題

この状態でネットワーク更新が行われ、その対象にラッパーDLLが含まれた場合、ネットワーク更新はおそらく失敗に終わります。上書きが出来ない状態になっているためです。
同様にゴースト削除も出来ません。ラッパーDLLが削除できないためです。ただし、SSPにおいてはDLLが削除できない場合においてもゴースト削除そのものは成功するとのことです。ディレクトリに残骸が残りますが、よほど気持ち悪く思うユーザーがいない限り問題は無いだろう、とのこと。

ラッパーDLLに求められるもの

とにかく、ラッパーDLLは一度リリースしたが最後、絶対に更新してはいけないファイルとなります。そのため、その実装はなるべく小さく、そしてカンペキな完成度が求められます。万が一修正する必要が発生してしまったら、もうDLLとその中のインターフェースクラスの名前を変えてしまわないといけません。

どうせなら本体側に持たせられないか？

さて、こうなると考えられる策のひとつとして、ラッパーDLLは本体側が管理するモジュールとする、という解決策が考えられます。.NET SHIORIの場合のみ、通常のDLL呼び出しではなく、本体側が所有するラッパーDLLに処理を丸投げして、そちらからゴーストを起動してしまえばいいのではないか？という事を考えました。
ついでに、ソレとは別に議題にあがっていた、「SHIORIを本体プラグインにして、ゴーストから切り離す」という話も考慮して、SHIORI_PLUGINとしてインターフェースを考えてみた次第です。
ポナパルトさんいわく、「DLLさえ提供されるなら、むしろやってみたかったことのひとつ」と良いお返事がいただけましたので、仮に作るとしたらこんな感じかなー、とAPI考えて見ました。

このAPIで何が出来るか

  • ゴースト側ではなく、本体側でSHIORIを持つことが出来ます。
  • その派生で、.NET SHIORIインターフェースを本体側に持つことが出来ます。

さて

えーと、仕様は多分これでいいと思うんですが、実装がまだちょっと追いついておりません。うかべん終わってちょっと脱力中なので、とりあえず来週末くらいまでものはお待ちくださいませ。ああ物は投げないでっっ