問題タブ [ipc]

.NET アセンブリをプラグインとして使用する 2 つの無関係なプロセスがあります。ただし、どちらのプロセスもいつでも開始/停止できます。サーバーである特定のプロセスに依存することはできません。実際、1 つのプロセスの複数のコピーが実行されている可能性がありますが、他のプロセスの 1 つのみです。

私は最初にこの記事に基づいて解決策を実装しました。ただし、これには、サーバーを実装するものをクライアントの前に実行する必要があります。

クライアントが最初に実行されたときにサーバーに何らかの通知を実装する最良の方法は何ですか?

C# (.Net 3.5) の子プロセスに SecureString (キャッシュされたパスフレーズ) を渡せるようにしたいのですが、最も安全な方法がわかりません。たとえば、SecureStringを通常の文字列に変換してコマンドライン引数として渡すと、その値はディスクページングを起こしやすくなる可能性があると思います. SecureString の使用について。

代わりに SecureString の IntPtr を渡すことはできますか? リスクを増やさずに名前付きパイプを使用できますか?

これまで、Windows で IPC を実行する必要はありませんでした。プログラムのペア、標準の GUI/CLI アプリ、および Windows サービスを開発しています。アプリはサービスに何をすべきかを伝える必要があります。では、通信がローカルのみであると仮定すると、これら 2 つのプロセスに最適な通信方法は何でしょうか?
最善とは、より堅牢でエラーが発生しにくいという意味であり、最高のパフォーマンスやコーディングの容易さではありません。

注: 標準の TCP ソケット、名前付きパイプ、またはその他の通信手段のみを使用する方法について質問しています。

Vista より前の Windows の以前のバージョンでは、現在ログインしているデスクトップ ユーザーと対話する Windows サービスを使用して、サービスから画面に情報を簡単に表示することができました。Windows Vista では、デスクトップからサービスを分離するためのセキュリティのためにセッション 0 が追加されました。セッション 0 の外部で実行されているサービスとアプリケーションの間で通信する簡単な方法は何ですか? これまでのところ、TCP/IP を使用して 2 つの間の通信を行うことでこれを回避してきましたが、これはちょっとずさんな方法のようです。

私はしばらく前に Win32 コードで IPC を使用しました - クリティカル セクション、イベント、およびセマフォ。

.NET 環境でのシーンはどうですか? 使用可能なすべてのオプションと、いつ使用するか、およびその理由を説明するチュートリアルはありますか?

考えられる IPC メカニズムに関する提案を探しています。

• クロスプラットフォーム(少なくとも Win32 と Linux)
• C++および最も一般的なスクリプト言語(perl、ruby、python など) で簡単に実装できます。
• 最後に、プログラミングの観点から使用するのは簡単です!

私のオプションは何ですか？私は Linux でプログラミングしていますが、将来的には他の OS に移植できるようにしたいと考えています。ソケット、名前付きパイプ、または DBus のようなものを使用することを考えました。

Perl スクリプトの途中で、実行したいシステム コマンドがあります。stdin に入力する必要があるデータを含む文字列があり (コマンドは stdin からの入力のみを受け入れます)、stdout に書き込まれた出力をキャプチャする必要があります。Perl でシステム コマンドを実行するさまざまな方法を調べましたが、そのopen機能は必要なもののようですが、両方ではなく stdin または stdout のみをキャプチャできるようです。

現時点では、私の最善の解決策は、を使用しopen、stdout を一時ファイルにリダイレクトし、コマンドの終了後にファイルから読み取ることです。より良い解決策はありますか？

アプリケーションサーバーとそのクライアント側ライブラリをC++で実装しているときに、Windowsのサーバーシャ​​ットダウン時にクライアントプロセスを停止するためのクリーンで信頼性の高い方法を見つけるのに苦労しています。

サーバーとそのクライアントが同じユーザーの下で実行されていると仮定すると、要件は次のとおりです。

• このソリューションは、次の場合に機能するはずです。
  • クライアントはそれぞれ、コンソールまたはGUIのいずれかを備えている場合があります。
  • ユーザーには特権がない可能性があります。
  • クライアントは応答しなくなるか、応答しなくなる可能性があります（無限ループ、デッドロック）。
  • クライアントはサーバーの子である場合とそうでない場合があります（直接または間接）。
• クライアント側の欠陥によって防止されない限り、クライアントはクリーンに終了する機会（リソースを解放し、一部のデータをディスクに同期する...）と、そうするための妥当な時間を許可されるものとします。
• すべてのクライアントリターンコードは、シャットダウン手順中にサーバーで利用できるようにする必要があります（可能な場合）。
• サーバーは、すべてのクライアントがなくなるまで待機する必要があります。

この編集の時点で、以下の回答の大部分は、サーバーとそのクライアント間で共有メモリ（または別のIPCメカニズム）を使用してシャットダウン命令とクライアントステータスを伝達することを推奨しています。これらのソリューションは機能しますが、クライアントがライブラリを正常に初期化する必要があります。

私が言わなかったことは、サーバーはクライアントを起動するためにも使用され、場合によってはクライアントライブラリをまったく使用しない他のプログラム/スクリプトも使用されるということです。サーバーとクライアント間の適切な通信に依存しないソリューションの方が優れています（可能な場合）。

しばらく前に、次のことを行うCスニペット（MSDNで私が信じている）に出くわしました。

1. シャットダウンするプロセスでCreateRemoteThreadを介してスレッドを開始します。
2. そのスレッドにExitProcessを直接呼び出させました。

残念ながら、今探しているのですが、見つけることができず、検索結果は、このトリックがVistaでは機能しなくなったことを示唆しているようです。これに関する専門家の意見はありますか？

自分のマシンで実行中のプロセスと通信するには、名前付きパイプまたは .NET Remoting を使用する必要がありますか?

サードパーティ アプリケーションは、XML ファイルから Java コードを読み取り、特定のイベントが発生したときにそれを実行します。Java では、同じマシンで実行されている .NET 3.5 アプリケーションに、このイベントが発生したことを伝えたいと考えています。毎回転送されるデータの合計は、おそらく数文字です。

Java を使用して .NET プロセスに何かが発生したことを伝える最善の方法は何ですか?

Java は Windows で名前付きパイプをサポートしていないようです。.NET はネイティブでメモリ マッピングをサポートしていません。また、Web サービスや RMI を含むソリューションはやり過ぎです。