2

システムのようなプラグインサンドボックスが欲しいプロジェクトに取り組んでいますが、双方向のリアルタイムクロスプロセス通信の実行に問題があります。最初はオブジェクトメタデータを渡すことができるWCFについて考えましたが、すぐにWCFのサービスクライアントモデルが問題になることに気付きました。しかし、私がすべてのアイデアと質問を置く前に、ここに私が計画したものがあります。

ほとんどの作業を実行するホストアプリケーションが必要です。このhost.exeを呼び出します。host.exeは、プログラムのメインアプリケーションロジックと、プラグインの起動、実行、および強制終了をホストします。プラグインは、MEFを介してプラグインをホストするプラグインプロキシを介してホストされるため、proxy.exeと呼びます。proxy.exeはプラグインdllをロードし、障害を分離する人里離れた環境でそれらをホストし、プラグインが失敗した場合、アプリケーションではなくプロキシを強制終了します。ホストとプロキシは双方向でリアルタイムに通信する必要があります。複数のプロキシホストが存在するため、オブジェクトデータを渡すことができるのが最適です。

それが私が欲しいものの基本的な考え方です。私はこれを行うためのいくつかの方法を考えていました。最初はWCFでしたが、WCFの動作方法は、サービスのサーバーがクライアントに要求/コマンドを送信することが不可能ではないにしても難しいと考えました。次のアイデアはTCPを使用し、ホストをTCPサーバーにして、通信に使用できるメッセージングプロトコルを開発しますが、WCFメタデータの贅沢がなく、複雑なクラス情報を渡すため、問題が発生します。正気を失っている。

私のすべての研究を通して、私は問題を次々と思いついたので、誰かがこの問題の解決策を提案することができれば幸いです。ありがとうございました。

4

3 に答える 3

0

これに対する私の解決策は、おそらくリモーティングでしょう。WCFがこれを同じように行うかどうかはわかりません。ただし、リモート処理はテキストで構成でき、サーバーはオブジェクトにリモートで自由に設定できます。

事前に警告したいと思います。私が言及しているプロジェクトはかなり前のものであるため、これは古い情報である可能性があります(WCFが同じことを行う場合とそうでない場合があります。私の会社は、私にWCFの作業を要求していません)。

オブジェクトをクライアントからサーバーにリモート接続しました。サーバーを(実際には別のマシンで)実行してから、tcpリモーティングを使用して、必要なすべてのオブジェクトをそのアプリケーションに宣言します。

これが楽しい部分です。そのリモートオブジェクトは、非リモートデリゲートオブジェクトを使用していました。オブジェクトを初期化(リモート)すると、サーバーがオブジェクトを作成します。次に、別の(インターフェイスタイプの)オブジェクトをローカルで初期化し、それをリモートオブジェクトにアタッチします。

リモートオブジェクトが私と通信したいとき、それは私にシリアル化可能な情報を送信し、私はそれをより多くのオブジェクトまたはコマンドに構築しました。必要なものは何でも...(おそらくもっとリモートオブジェクト)

とにかく。1つのサーバーと複数のリモートオブジェクトは、すべての標準インターフェイスオブジェクトが定義されたCommonInterface.dllを使用して送受信されます。

これは、すべての目的と目的のために、サーバーとの間で情報を取得したいアプリケーションが、インターフェイスが一致している限り、クラスを実装および処理できるブラインドプラグインのセットアップでした。(シリアル化可能なコマンドデータ付き)

プラグイン(クライアント)がクラッシュした場合、アプリケーション(サーバー)が影響を受ける必要はありません。そのプラグインへのすべての通信をtrycatchでラップするだけで、remotedオブジェクトには、ライブまたはpingスタイルのリリースメカニズムに何らかの時間がかかります。

サンドボックスであなたのシナリオがどのようになるかは本当にわかりませんが、これであなたが求めていることを達成できるかもしれません。

これが.netリモーティングチャットサーバーです。

http://www.codeproject.com/KB/IP/dotnetchatapplication.aspx

これは、私が初めてリモートで作成したのと同じタイプのプロジェクトです。そしてそれをサーバープラグインアーキテクチャに進化させました。私の使用とあなたの使用の違いは、サーバーが私のクライアントであり、サーバーを使用するメインアプリケーションであり、あなたのサーバーが複数のクライアントがプラグインできるようにするメインアプリケーションになることです。

于 2011-10-04T02:00:16.943 に答える
0

私の意見では、さまざまなアプリケーションドメインを使用し、インターフェイスを使用してプラグインと通信し、実際のプロキシオブジェクト参照を使用することをお勧めします。異なるプロセスを使用しないでください。例外は指定されていない限りアプリケーションドメインの境界を越えないため、アプリケーションドメインの分離を通じてプラグインの分離を実現できます。

別の方法として、.NET Remotingなどの非推奨のテクノロジーを使用して、カスタムのマーシャリングと透過的なプロキシオブジェクトの作成を行うことができます。

私の意見では、WCFは重すぎて、リアルタイム処理には遠すぎます

于 2011-10-04T02:00:24.177 に答える
0

プロセス間通信(IPC)。クロスプロセス通信(CPC)と呼ばれるべきものは、MS/Windows固有の既知の概念です。

詳細はこちら

過去に私はRPCとWindowsパイプを使用しました(これはSQLサーバーでも大きなデータセット/結果を転送するために使用されます)

別の通信方法、WCF、ソケット、Pub/Subメッセージングをいつでも試すことができます。たとえば、TibcoRv(ローカルではソケットをバイパスします)。これらは少しやり過ぎだと思います。しかし、あなたの要件には完璧かもしれません。

于 2015-01-29T00:57:01.560 に答える