今週は、名前付きパイプの最新情報を取得しようとしてきました。私が解決しようとしているタスクは、外部デバイスからデータベースにデータを送り込むデバイス ドライバーとして機能する既存の Windows サービスがあることです。ここで、このサービスを変更し、オプションのユーザー フロント エンドを (同じマシン上で IPC の形式を使用して) 追加する必要があります。このユーザー フロント エンドは、デバイスと DB の間を通過するデータを監視し、いくつかのコマンドをサービスに送り返すことができます。 .
IPC に関する私の最初のアイデアは、名前付きパイプまたはメモリ マップ ファイルのいずれかでした。これまでのところ、 WCF チュートリアルの基本的なプロセス間通信を使用して、名前付きパイプのアイデアを検討してきました。私の考えは、WCF NamedPipe サービスを実装する追加のスレッドを使用して Windows サービスをセットアップし、それをドライバーの内部へのパイプとして使用することです。
サンプルコードは動作していますが、ここの誰かが私を助けてくれることを望んでいる2つの問題に頭を悩ませることができません:
チュートリアルでは、具体的なクラスを参照するのではなく、typeof(StringReverser) を使用して ServiceHost をインスタンス化します。したがって、サーバーがサービス自体と対話するメカニズムはないようです (host.Open() と host.Close() の行の間)。サーバーと実際にサービスを実装するクラスとの間でリンクを作成し、情報を渡すことは可能ですか? もしそうなら、どのように？
サーバーの 1 つのインスタンスを実行してからクライアントの複数のインスタンスを実行すると、各クライアントがサービス クラスの個別のインスタンスを取得するように見えます。サービスを実装するクラスに状態情報を追加しようとしましたが、名前付きパイプのインスタンス内にのみ保持されました。これはおそらく最初の質問に関連していますが、サービスを実装しているクラスの同じインスタンスを名前付きパイプに強制的に使用させる方法はありますか?
最後に、MMF と名前付きパイプについて何か考えはありますか?
編集 - 解決策について
Tomasrの答えによると、ソリューションは、サービスを実装する具体的なシングルトンクラス（ServiceHost Constructor (Object, Uri[])）を提供するために正しいコンストラクターを使用することにあります。当時私が理解できなかったのは、サービス クラスがスレッド セーフであることを保証するという彼の言及でした。単純にコンストラクターを変更するだけでサーバーがクラッシュし、最終的にはこのブログ エントリInstancecontextmode And Concurrencymodeから InstanceContextMode を理解する道にたどり着きました。正しいコンテキストを設定すると、ソリューションがうまく完了しました。