問題タブ [netnamedpipebinding]

netNamedPipeBinding で WCF サービスを使用して、大量のデータ (オブジェクトの非常に長いリスト) をクライアント (もちろん同じマシン上にあります) に転送しています。問題は、呼び出し全体で約 250 MB のデータを転送するのに約 20 秒かかることです。これは 1 秒あたり約 10 + MB です。メモリを共有すると、転送速度がはるかに高速になると予想していました。パフォーマンスと転送速度を向上させる方法を知っている人はいますか? ここに私のapp.configファイルがあります:

どうもありがとう！

相互に通信し、コマンドを実行し、データをやり取りする必要がある複数のインスタンスを持つ C# プログラムがあります。現在、これは非常に面倒な WM_COPYDATA を使用して実現されています。NetNamedPipeBindings を使用して、これを WCF システムにアップグレードしたいと考えています。しかし、どのような設定を試しても、リエントラント二重通信が機能しません。

これは通常の WCF 呼び出しです。

そして、これは私が欲しいものです:

重要なのは、proxy.foo を呼び出すクライアント スレッドを、proxy.baz を呼び出すスレッドと同じにすることです。Windows メッセージの場合、これは当然のことです。しかし、どのような設定を試しても、このパターンを WCF で機能させることはできません。それは可能ですか？

名前付きパイプを使用したコールバックを使用して WCF サービスとクライアントを設計しています。サーバーがクライアントからの要求を処理すると、エラー #109 が発生し、最終的にパイプ接続が中止されました。以下は、サーバー側からのトレース ファイルです。フォントが小さすぎて見えない場合は、簡単に説明します。

赤でマークされた 3 つの例外は、クライアントからサーバーへの要求が行われたときに発生しました。関数は非常に単純で、1 つの文字列変数をサーバーに渡します。このエラーは #109 (3 つの連続する例外、その数字が何かを意味する場合) であり、それ以上の情報は得られません。そして、このアクティビティでは、パイプ接続が最終的に中止されました。また、奇妙なことに、「Receive bytes on connection...」、「Processing message」の後に次のアクティビティが表示されます。これは実際に実行され、サーバー側の処理が渡されたパラメーターで呼び出されたことを意味します。これはデバッガーで確認できます。これは、サーバー側で操作が渡された文字列を取得したためです。また、操作関数内で試してみると

それは実際には If 文に入ります。これは、チャネルがこれまでのところ実際に有効であることを意味していると思います。

助けてくれてありがとう！

名前付きパイプバインディングを使用してコールバックを使用するWCFサービスを設計しています。また、クライアントからサービスを呼び出すと、サーバー側のトレースで「パイプからの読み取り中にエラーが発生しました：認識されないエラー109」というエラーが表示され、最終的にパイプ接続が中止されました。しかし、何が問題を引き起こしたのか、私にはまったくわかりません。トレースでは、スタックトレース以外の情報は提供されません。

スタックトレースで別の109エラー

トレースアクティビティフローに基づく操作の戻り値と関係があるのではないかと思いました。ただし、操作の戻りタイプをvoidと宣言しても、このエラーが発生します。もう1つは、コールバックを使用していますが、操作内でコールバックを呼び出さないことです。

助けていただければ幸いです。または、中止されたパイプ接続をデバッグする方法を教えてください。もっと詳細な情報を取得する方法があるに違いありません。たとえば、上記の例外をキャッチする方法（サーバー操作内でcatchブロックを試行しても何も取得されず、クライアント側の呼び出し関数も取得されません）。

John Sharp による「Windows Communication Foundation 4」の例に従っています。88 ～ 89 ページに、サービスの登録方法と開始方法が示されています。サービスが開始されません。

自分のホストで net.tcp を使用してサービスを実行できなかったと言う必要があります。これは、ポートが使用されていることに不満があり、これはnamedPipesを使用する必要があるためです。

アプリケーションログのエラーは

あなたの助けに感謝します。

名前付きパイプを使用して、2つのプロセス間で大きなファイル（〜8ギガ）を転送するWCFサービスを構築しています。

ストリーミングモードで小さなファイルを転送するというコンセプトがあります。より大きなファイルの場合は、maxReceivedMessageSizeを増やす必要があります。ホストapp.configでbindingConfigurationを問題なく指定できます。

この問題は、クライアントapp.configのクライアントエンドポイントでbindingConfigurationを指定すると発生します。

私が得るエラーメッセージ：

使用されている.Netフレーミングモードは、「net.pipe：// localhost/MyService」ではサポートされていません。詳細については、サーバーログを参照してください。

フレーミングモードシングルトンはサポートされていません。

ホスト構成：

クライアント構成：

私は現在、Windows Server 2008 R2 Datacenter x64 VM 上の IIS 7.5 でホストされている WCF サービス (.Net 4.0) として公開されているサービスを使用して、SOA アーキテクチャでアプリケーションを開発しています (実際には、Amazon EC2 の m1.small インスタンスです)。 ）。これらのサービスはマシン上でローカルに相互に通信するため、最適なパフォーマンスを得るために netNamedPipeBinding を使用するように設定しました。インスタンス化モードは呼び出しごとで、同時実行は複数に設定されています。

現在、200 ミリ秒から 1 秒の間のチャネルを開くときに断続的な遅延が発生するという 2 つの問題に直面しています。

WCF トレースを有効にしましたが、遅延が次のいずれかのエラーとして現れることがわかりました。

System.IO.PipeException: パイプへの書き込み中にエラーが発生しました: パイプを閉じています。(232、0xe8)。

その後、WCF が再試行され、正常に接続されたように見えます (したがって、遅延が発生します)。2 番目の症状は、アクティビティの実行時に 0.5 秒の遅延が発生することです。

処理アクション「http://tempuri.org/IConnectionRegister/ValidateUriRoute」

これについて私が見つけた唯一のことは、TCP ポート共有に関連している可能性があると考える人がいるということですが、私は名前付きパイプを使用しています。TCP ポート共有サービスを無効にしようとしましたが、違いはありませんでした。

興味深いことに、同じランダム ポートの localhost でリッスンする net.tcp を使用するようにすべてのエンドポイントを変更しようとしましたが、ValidateUriRouteアクティビティ内で 0.5 秒の遅延が断続的に発生しました。

私の WCF 構成は次のようになります。

netNamedPipeBinding が安全と見なされるかどうかを知りたい:

一方では、NetNamedPipeBinding はトランスポート層にのみセキュリティを実装し、Microsoft によって推奨されなくなったNTLM (ソース) を使用します (ソース)

一方、名前付きパイプにはリモート コンピューターからアクセスすることはできず、特定のインスタンスへのハンドルを取得できない限り、データの転送に使用されている特定の開いているパイプ インスタンスを傍受したり、それにデータを書き込んだりする方法はありません。心配している。

これが、このソリューションのセキュリティについてどう考えるべきかわからない理由です。

NetNamedPipeBindingがC＃とC ++（ソース）に存在することを確認しました。これを使用してC ++プログラムとC＃アプリケーション間でデータを送信できるかどうか知りたいですか？

名前付きパイプのエンドポイントのセキュリティを制御するにはどうすればよいですか。エンドポイントには、IISアプリプールが実行されているログインとローカルマシンの管理者グループにのみアクセスできるようにする必要がありますか？

私はこれに従い、必要なカスタムバインディングを作成しました：http： //blogs.charteris.com/blogs/chrisdi/archive/2008/06/23/exploring-the-wcf-named-pipe-binding-part-3.aspx

IISアプリプールの部分をどのように実現するのか疑問に思っています。