Massive increase in new TCP connections # in .NET 4.5 over 4.0?

Question

I am currently testing my WPF / WCF client application in .NET 4.5 vs 4.0 with the goal of final outputting 4.5 to all client machines. The WCF part uses BasicHttpBinding / SOAP.

When testing two client versions under the same conditions (Win7, etc.), we observe an increase in "new TCP connections" by 10 times to the endpoint of the SOAP server. 4.0 clients install ~ 450 per hour, and 4.5 clients install ~ 6000. Since we are connecting to a remote server, this causes problems because establishing a new TCP connection adds a lot of delay to the web service call.

With 4.0, we preconfigured the ServicePointManager client settings to maximize the reuse of TCP connections and expected these settings to apply to 4.5.

My application usually makes one call at a time, perhaps every 10 seconds on average - with queues of 10 simultaneous calls every few minutes.

I looked through the list of changes and cannot find links to corrections / changes made to this part of .NET. Can anyone shed light on what can happen here?

 ServicePointManager.UseNagleAlgorithm = true; ServicePointManager.Expect100Continue = false; ServicePointManager.DefaultConnectionLimit = 50; ServicePointManager.MaxServicePointIdleTime = 10000; Binding binding = new BasicHttpBinding { SendTimeout = TimeSpan.FromSeconds(_settings.SendTimeout), ReceiveTimeout = TimeSpan.FromSeconds(_settings.SendTimeout), MaxReceivedMessageSize = 1024 * 1024 * 10, MaxBufferSize = 1024 * 1024 * 10, MaxBufferPoolSize = 1024 * 1024 * 100, Security = { Mode = BasicHttpSecurityMode.TransportCredentialOnly, Message = { ClientCredentialType = BasicHttpMessageCredentialType.UserName }, Transport = { ClientCredentialType = HttpClientCredentialType.Basic }, }, }; 

Answer 1

This issue has been fixed with these fixes:

Win7: http://support.microsoft.com/kb/2846044 Win8: http://support.microsoft.com/kb/2846046

We tested the Win7 patch as working.

Answer 2

This is due to the regression that was introduced to fix another problem. This is due to alternating responses to the transfer-coding from the server.

For those using HttpWebRequest directly, you can work around this problem by making sure your application reads the entire response stream. This means that you need to call the Read or BeginRead method on the stream until it returns 0 as the number of bytes read.

For those using packaging technology such as WCF, no workaround was found on the client side. If you have access to the server, you can change your server to send a response based on the content, rather than a fragmented response, which should allow you to avoid problematic code paths to the client.

A fix for this problem has been identified and will be widely distributed in the upcoming structure update. If this blocks you, contact Microsoft Support.