問題タブ [netnamedpipebinding]

I'm having trouble figuring out how to get a named pipe WCF service to work. The service is in a seperate assembly from the executable.

The config looks like this:

I'm using a ChannelFactory to create a proxy to access the service host:

ChannelFactory を作成するときに何が間違っているのかわかりません。設定で「channel1」が見つからないようです。バインディングを手動で作成して ChannelFactory コンストラクターに渡すと、ファクトリとプロキシは作成されますが、LoadData() の呼び出しは失敗します (タイムアウト)。

ここで私が間違っていることを誰かが見ることができますか?

編集: 上記の app.config を編集して、両方のエンドポイントがまったく同じデータを持つようにしました。これで Channelfactory の問題は解決しました。ただし、上記のサービス メソッドの呼び出しは依然としてタイムアウトします。

今週は、名前付きパイプの最新情報を取得しようとしてきました。私が解決しようとしているタスクは、外部デバイスからデータベースにデータを送り込むデバイス ドライバーとして機能する既存の Windows サービスがあることです。ここで、このサービスを変更し、オプションのユーザー フロント エンドを (同じマシン上で IPC の形式を使用して) 追加する必要があります。このユーザー フロント エンドは、デバイスと DB の間を通過するデータを監視し、いくつかのコマンドをサービスに送り返すことができます。 .

IPC に関する私の最初のアイデアは、名前付きパイプまたはメモリ マップ ファイルのいずれかでした。これまでのところ、 WCF チュートリアルの基本的なプロセス間通信を使用して、名前付きパイプのアイデアを検討してきました。私の考えは、WCF NamedPipe サービスを実装する追加のスレッドを使用して Windows サービスをセットアップし、それをドライバーの内部へのパイプとして使用することです。

サンプルコードは動作していますが、ここの誰かが私を助けてくれることを望んでいる2つの問題に頭を悩ませることができません:

1. チュートリアルでは、具体的なクラスを参照するのではなく、typeof(StringReverser) を使用して ServiceHost をインスタンス化します。したがって、サーバーがサービス自体と対話するメカニズムはないようです (host.Open() と host.Close() の行の間)。サーバーと実際にサービスを実装するクラスとの間でリンクを作成し、情報を渡すことは可能ですか? もしそうなら、どのように？

2. サーバーの 1 つのインスタンスを実行してからクライアントの複数のインスタンスを実行すると、各クライアントがサービス クラスの個別のインスタンスを取得するように見えます。サービスを実装するクラスに状態情報を追加しようとしましたが、名前付きパイプのインスタンス内にのみ保持されました。これはおそらく最初の質問に関連していますが、サービスを実装しているクラスの同じインスタンスを名前付きパイプに強制的に使用させる方法はありますか?

3. 最後に、MMF と名前付きパイプについて何か考えはありますか?

編集 - 解決策について

Tomasrの答えによると、ソリューションは、サービスを実装する具体的なシングルトンクラス（ServiceHost Constructor (Object, Uri[])）を提供するために正しいコンストラクターを使用することにあります。当時私が理解できなかったのは、サービス クラスがスレッド セーフであることを保証するという彼の言及でした。単純にコンストラクターを変更するだけでサーバーがクラッシュし、最終的にはこのブログ エントリInstancecontextmode And Concurrencymodeから InstanceContextMode を理解する道にたどり着きました。正しいコンテキストを設定すると、ソリューションがうまく完了しました。

WCF のドキュメントには、"Net Named Pipe" バインディングを使用して、単一のマシンで高速なプロセス間通信を行うことができると記載されています。マシン間の通信には使用できません。

Net Named Pipe バインディングを使用すると、サービスがネットワークの外部からの攻撃から保護されるかどうかを知りたいです。答えはノーだと言われました。Net Named Pipe バインディングは、同じマシン上のプロセス間通信に使用されることを意図していますが、他のマシンからのアクセスを許可するためにハッキングされる可能性があります。それは正確ですか？

WCF の専門家の皆様、ご意見をお聞かせください。Net Named Pipe バインディングを使用すると、サービスが他のマシンからの不正アクセスから本質的に保護されるのでしょうか?

Web サイトで WCF 名前付きパイプを使用しようとしていますが、次のエラーで失敗します。

メッセージを受け入れることができる net.pipe://localhost/mypipename でリッスンしているエンドポイントはありませんでした。これは、多くの場合、アドレスまたは SOAP アクションが正しくないことが原因です。詳細については、InnerException (存在する場合) を参照してください。

および InnerException:

メッセージを与える別の内部例外がありaccess deniedます。

私の Web サイトはなりすましを使用しており、インターネットを見回すと、これは関連しているように見えますが、修正方法がわかりません。

誰にもアイデアはありますか？

ありがとうマット

他の場所で説明されているように、「net.pipe：// localhostでリッスンしているエンドポイントがありませんでした」というエラーが発生しますが、本当の答えが見つからないようです。

これは問題の優れた識別子です：http： //kennyw.com/indigo/102

WCFを使用する場合、Windows認証はSSPI-Negotiateを介して実行されます。これにより、ほとんどの場合、実際の認証メカニズムとしてKerberosが選択されます。ただし、SSPIに渡されるターゲットSPNがローカルコンピューターアカウント用の整形式SPN（例：host / [dns machine name]）の場合、NegotiateはNTLM（ループバック最適化）を使用し、アクセストークンにはネットワークSIDがありません（およびしたがって、NetNamedPipesで使用できます）。

しかし、それは問題を解決する方法を教えてくれません。プログラムでエンドポイントを作成しています。

私の問題はCreateSpnIdentityにあると思いますが、どの値を使用すればよいかわかりません。

追加情報： より多くのコンテキストのためにこれについて詳しく説明します。Wcfサービスは、NetworkServiceアカウントで実行されているWindowsサービスとしてホストされています（ローカルシステムを試しました）。サービスは、デフォルトのNetNamedPipeBindingコンストラクターを使用して作成されます。

このサービスを使用するSharePointWebパーツを作成しました。キッカーは、SharePointサイトがフォームベースの認証に設定されている場合、またはWindows認証のURLでマシン名のみが使用されている場合、問題はないということです。Windows認証でURLに完全修飾マシン名が使用されている場合にのみ、上記のエラーが発生します。

これは、記事で説明されているNTLM Kerberosの問題に関係していると確信していますが、回避方法がわかりません。

いくつかの WCF サービスで構成されるアプリケーションがあります。その一部は Workflow Foundation (.NET 3.5) で実装されており、その他は単純な C# です。これらのサービスは、パフォーマンス上の理由から、netNamedPipeBinding を介して相互に通信します。問題は、システムの負荷が増加するとすぐに、CommunicationExceptions とその下にある PipeExceptions がますます増えることです。面白いことに、これらのトランザクションは最終的に終了するように見えます。その理由の 1 つは、ワークフローに再試行メカニズムがあるためですが、WCF トレースにこれらのエラーが表示されていても、単純な C# サービスからの呼び出しでさえ成功します。Windows などの名前付きパイプ サブシステムに再試行メカニズムはありますか?

ただし、これらのエラーを修正するか、少なくとも根本的な問題を理解してください。アプリケーションのパフォーマンスと安定性に影響を与えているように感じます。サービス自体から発生する他の例外が見られない場合、これらのエラーの根本原因を正しく診断するにはどうすればよいですか?

ここに私が得る例外のいくつかがあります:

PipeException: パイプからの読み取り中にエラーが発生しました: パイプは終了しました。(109、0x6d)。

と：

PipeException: パイプが閉じられているため、操作を完了できません。これは、パイプの反対側のアプリケーションが終了したことが原因である可能性があります。

TimeoutException 内: パイプからの非同期読み取りが割り当てられたタイムアウト 00:02:00 内に完了しなかったため、パイプ接続が中止されました。この操作に割り当てられた時間は、より長いタイムアウトの一部であった可能性があります。

現在、タイムアウト例外は、システムが負荷の処理に問題を抱えているという事実から発生しているようです。これらの操作は通常非常に小さいですが、その量が問題のようです。それとも、これは以前のパイプ接続が終了し、プールに返されなかった結果でしょうか?

インスタンスの量などを増やすために、WCF 構成で serviceThrottling の動作を試してみましたが、これらのエラーが発生し続けています。任意のヒント？

/EDIT: WCF トレースとメッセージ ログの両方をオンにしました。そこに PipeExceptions と CommunicationExceptions が表示されます。アプリケーション自体はエラーを表示していません。log4net を使用してすべての例外がログに記録されるように、WCF サービスにかなりの機能を追加しました。これらのログにはエラーがまったく表示されません。これはすべてWCFレベルで起こっているようです。

IISで新しいnet.pipeバインディングを追加するとき、バインディング情報フィールドはどのように使用されますか？*を入力するように言われましたが、何に使われているのか知りたいです。

与えられた:
- アプリケーション - デスクトップ GUI (WPF) .NET アプリ
- アプリケーションを監視する Windows サービス (.NET も)

Windows サービスは、アプリケーションが正常であることを確認するために定期的に「ping」を実行します (そうでない場合は、winservice がアプリケーションを再起動します)。
名前付きパイプを介して「ping」を実装するつもりでした。簡単にするために、WCF を使用することにしました。アプリケーションは、WCF サービスをホストします (1 つの操作 Ping が何かを返します)。Windows サービスは、この WCF サービスのクライアントであり、タイマーに基づいて定期的に呼び出します。

Windows 7
では以上です。Windows サービスは LocalService の下で実行されています (セッション #0)。
デスクトップ アプリケーションは、現在ログインしているユーザー (セッション #1) で実行されています。

問題:
Windows サービスは、デスクトップ アプリケーションで作成され、リッスンされている WCF エンドポイント (NetNamedPipeBinding を使用) を認識できません。つまり、wcf プロキシ経由の呼び出しで、「パイプ エンドポイント 'net.pipe://localhost/HeartBeat' がローカル マシンに見つかりませんでした」という例外が発生します。

別のデスクトップ アプリケーション (セッション #1) がエンドポイントを認識できるため、コードは問題ないと確信しています。

明らかに、ここでは、Win32 システム オブジェクトの分離のためのセキュリティ関連の事柄を扱っています。しかし、私が遭遇した制限を回避する方法があるはずです。
私は WCF のアプローチを犠牲にして、生の NamedPipe の方法に進むことができます。

namedPipeバインディングを使用したoneWay呼び出しで、注文された配信を保証することは可能ですか？

namedPipeバインディングを使用して通信するWCFサービス/クライアントがあります。クライアントは、コールバック内のすべてのメソッドがOneWayとしてマークされているコールバックコントラクトを公開しています。このようなもの

サーバー側では、MyOperationメソッドの実装は常に最初にMyCallback1を呼び出し、次にMyCallback2を呼び出しますが、クライアントが誤った順序で呼び出しを受信することがあります（MyCallback2、次にMyCallback1）。

インターネットを検索したところ、ここで説明したように一方向の操作では順序が保証されておらず、メッセージの順序を保証するreliableSessionと呼ばれるものもあります。

信頼できるセッションのためのインターネット上のすべての例はTCPバインディングを使用したものであり（NamedPipeBindingを使用した単一の例ではありません）、tcpBindingにはNetNamedPipeBindingには存在しないReliableSessionというプロパティもあります。したがって、信頼できるセッションがNetNamedPipeBindingで機能することが期待されるかどうかはわかりません。

質問：

信頼できるセッションはnamedPipeBindingで機能しますか？はいの場合、どのように？いいえの場合、注文された配達を保証できる他のアプローチはありますか？

ファイルアップロードコントロールを介してasp.netにファイルをアップロードしています。投稿されたファイルからストリームを取得し、バイト配列に変換してサービスに渡します。次のエラーが表示されます: パイプへの書き込み中にエラーが発生しました: パイプが閉じられています。(232、0xe8)。

Windows サービスでホストされている netNamedPipe バインディングを使用しています。