最近我一直在研究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绑定中，一切似乎都很好。
有没有人尝试过该解决方案并且之前看过同样的问题？我还能做些什么来强制连接关闭吗？我可能错过了什么吗？
非常感谢， 贝
答案 0 :(得分：1)
看起来微软现在有一篇关于压缩编码器的官方文章： http://msdn.microsoft.com/en-us/library/ms751458(v=VS.90).aspx
我对它进行了测试，看起来问题已经消失。在那么多天之后进行我的单元测试并不容易：）