3

最近、私は WCF アプリに取り組んでおり、サービスからの応答のサイズを小さくするために、soap メッセージの本文を圧縮する機能が必要です。

いくつかの調査の後、http://weblogs.asp.net/cibrax/archive/2006/03/29/WS_2D00_Compression-for-WCF.aspx'> http://weblogs.asp.net/からオンラインで入手できる実装を見つけました。 cibrax/archive/2006/03/29/WS_2D00_Compression-for-WCF.aspxの作成者は、チャネル関連のクラスに関連付けられた新しいバインド要素「CompressionBindingElement」を作成しました。

この圧縮ソリューションは私の WCF アプリで完全に機能し、応答のサイズはほぼ 90% 縮小されました。最初に http バインディング (http トランスポートを使用したカスタム バインディングを意味します) でテストしましたが、すべて問題ないようです。

net.tcp バインディング (tcp トランスポートを使用したカスタム バインディング) で試してみたところ、アプリは引き続き正常に動作しました。しかし、いくつかのトレース ツールで確認したところ、奇妙なことがわかりました。

ChannelFactory によってクライアントを作成し、圧縮バインディング要素を含むすべてのバインディング要素を明示的に追加するメソッドを 10 回呼び出して単体テストを行いました。最初に TcpTrace で応答を確認したとき、これら 10 個のメッセージすべてが 1 つの要求にまとめられていることに驚きました。

そのため、SvcTraceViewer でリクエストを確認しようとしたところ、サービスがシャットダウンされるまでソケット接続が開いたままになっていることがわかりました。処理の進行状況を調べたところ、すべてのメッセージ、チャネルはリクエストごとに閉じられていると信じていましたが、接続は閉じられていませんでした。

この問題は、要素がバインディングに追加されていない場合、または http バインディングですべて問題ないように見える場合、圧縮バインディング要素を使用したネット tcp バインディングでのみ発生しました。

誰かがその解決策を試して、同じ問題を見たことがありますか? 接続を強制的に閉じるために他にできることはありますか? 私は何かを逃した可能性がありますか？

どうもありがとう、トニー

4

1 に答える 1

1

Microsoft が Compression Encoder に関する公式記事を公開しているようです: http://msdn.microsoft.com/en-us/library/ms751458(v=VS.90).aspx

私はそれをテストしましたが、問題はなくなったようです。何日も経ってから単体テストを実行するのは簡単ではありません:)

于 2010-11-23T01:27:39.357 に答える