共有メモリ バッファーのサイズを管理する (または十分に事前に割り当てる) 必要があるため、共有メモリを使用するのはより困難です。また、そこに配置したデータ構造を手動で管理する必要があります。ただし、テストして動作させると、シンプルなため、使用とテストが簡単になります。
リモート ルートを使用する場合は、名前付きパイプを使用した単一システム通信に、TCP または HTTP チャネルの代わりに IpcChannel を使用できます。http://msdn.microsoft.com/en-us/library/4b3scst2.aspx. このソリューションの問題点は、プロセスがエンドポイントを登録できるレジストリ タイプのソリューション (共有メモリまたはその他の永続ストア) を考え出す必要があることです。そうすれば、それらを探しているときに、システムで実行されているすべてのエンドポイントを照会する方法を見つけることができ、探しているものを見つけることができます。Remoting を使用する利点は、シリアル化とメソッド呼び出しがすべて非常に簡単であることです。また、ネットワーク上の複数のマシンに移動する場合は、スイッチを切り替えるだけで、代わりにネットワーク チャネルを使用できます。短所は、「リモート」呼び出しと「ローカル」呼び出しを明確に区別しないと、リモート処理がイライラする可能性があることです。
私は WCF についてあまり知りませんが、それも調べる価値があるかもしれません。スパイダーセンスは、おそらくこの問題に対するよりエレガントな解決策があると言っています...多分。
または、他のすべてのプロセスとは別に、起動される「サーバー」プロセスを作成して (システム Mutex を使用して複数のプロセスが起動されないようにする)、すべてのプロセスの仲介および登録ハブとして機能することができます。他のプロセス。
イベント (Pub/Sub) のパブリッシュ-サブスクライブ モデルを検討する必要があるもう 1 つのこと。この手法は、イベント ソースが使用可能になる前に起動されるリスナーがあり、イベントの登録を待ちたくない場合に役立ちます。「サーバー」プロセスは、イベント レジストリを処理して、パブリッシャーとサブスクライバーをリンクします。
IPC（.netかどうか）を処理する方法はたくさんあり、TCP / HTTPトンネル経由は1つの方法です...しかし、非常に悪い選択になる可能性があります（状況や環境によって異なります）。
共有メモリと名前付きパイプは2つの方法です（もちろん、.Netで実行できます）。これは、より良いソリューションになる可能性があります。.Net FrameworkにはIPCクラスもあります...しかし、AppDomainの問題があるため、個人的には好きではありません...
全二重 IPC を実行するための信頼性が高く、シンプルで高速な方法を探しながら、IPC で使用可能なすべてのオプションを 2 日間かけて調べました。Codeplex.comで見つけた IPCLibrary は、これまでのところ、私が試したすべてのオプションの中で完全に機能しています。すべてわずか 7 行のコードです。:D 誰かが全二重 IPC を見つけようとしてこれに出くわした場合は、時間を大幅に節約して、このライブラリを試してみてください。ソース コードを取得し、data.dll をコンパイルして、指定された例に従います。
HTH、サークル
サーバーとクライアントを両側でホストし、最初に登場した人がサーバーになるのはなぜですか? サーバーがドロップアウトすると、まだアクティブなクライアントが役割を切り替えます。
ガロさんに同意。
pub/sub サービスを使用すると、優れたソリューションになります。これは明らかに、このサービスが他の 2 つのサービスよりも前に稼働している必要があることを意味します。
pub/sub をスキップしたい場合は、エンドポイントが異なる両方のアプリケーションにサービスを実装するだけです。いずれかのアプリケーションが起動されると、IPC プロキシ経由で他の既知のオブジェクトにアクセスしようとします。プロキシが失敗した場合、他のオブジェクトは稼働していません。
-スコット