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 传输的自定义绑定）尝试了它，该应用程序仍然运行良好。但是，当我通过一些跟踪工具检查它时，我发现了一些奇怪的东西。

我在一个方法上调用了 10 次进行了单元测试，该方法通过 ChannelFactory 创建了客户端，并显式添加了所有绑定元素，包括压缩绑定元素。当我第一次在 TcpTrace 中检查响应时，我惊讶地发现所有这 10 条消息都组合在一个请求中。

于是我尝试使用 SvcTraceViewer 检查请求，发现套接字连接一直保持打开状态，直到服务关闭。我查看了处理进度，并相信每个请求的所有消息、通道都已关闭，但连接并未关闭。

该问题仅发生在带有压缩绑定元素的 net tcp 绑定中，如果该元素未添加到绑定或 http 绑定中，一切似乎都很好。

有没有人尝试过该解决方案并看到过同样的问题？我还能做些什么来强制关闭连接吗？我会错过什么吗？

非常感谢，托尼

4

1 回答 1

1

看来微软现在有一篇关于压缩编码器的官方文章：http: //msdn.microsoft.com/en-us/library/ms751458 (v=VS.90).aspx

我测试了一遍，看起来问题已经消失了。这么多天后让我的单元测试运行并不容易:)

于 2010-11-23T01:27:39.357 回答