WCF - Socket connection not closed by using WS-Compression with net.tcp binding

Question

Recently I've been working on a WCF app and needs some functionalities to compress the soap message body, so that the size of response from service should be reduced.

After some research, I found an implementation available online from 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, the authors of it created a new binding element 'CompressionBindingElement', associated with its channels related classes.

This compression solution works perfectly in my WCF app, and the size of response was reduced almost 90%, great! I firstly tested it over http binding (means custom binding using http transport) and everything seems good.

Once I tried it via net.tcp binding (custom binding using tcp transport), the app still worked well. However, when I checked it by some tracing tools, I found something weird.

I did a unit test by calling 10 times on a method, which created the client by ChannelFactory, and explicitly added all binding elements, including the compression binding element. When I firstly checked the response in TcpTrace, I was surprised to see that all these 10 messages are combined in a single request.

So I tried SvcTraceViewer to check the request, and found that the socket connection keeps open until the service was shut down. I looked inside the processing progress and believed all messages, channels are closed for each request, but the connection just not closed.

The issue only happened in net tcp binding with a compression binding element, if the element was not added to binding or in http binding everything seems fine.

Has anyone tried that solution and seen the same issue before? Is there anything else I can do to force the connection to close? Could I've missed anything?

Many thanks, Tony

Answer 1

It looks like Microsoft now has an official article on Compression Encoder: http://msdn.microsoft.com/en-us/library/ms751458(v=VS.90).aspx

I tested it over and looks like the problem is gone. It's not that easy to make my unit test run after that many days :)