WCF async call return a 10054 error: "An existing connection was forcibly closed by the remote host"

I have a WCF consumed by a Windows Mobile 5.0 or above application with .NET Compact Framework 2.0 SP2 and C#.

When the application consume a asynchronous "method" it throws that message. This is also the stackTrace of inner exception:

at System.Net.Sockets.Socket.ReceiveNoCheck()
at System.Net.Sockets.Socket.Receive()
at System.Net.Connection.Read()
at System.Net.HttpWebRequest.fillBuffer()
at System.Net.HttpWebRequest.getLine()
at System.Net.HttpWebRequest.parseResponse()
at System.Net.HttpWebRequest.startReceiving()
at System.Net.Connection.startReceiving()
at WorkItem.doWork()
at System.Threading.Timer.ring()

The message from the exception is:

"Unable to read data from the transport connection."

And its stackTrace is:

at System.Net.HttpWebRequest.finishGetResponse()
at System.Net.HttpWebRequest.GetResponse()
at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse()
at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse()
at System.Web.Services.Protocols.SoapHttpClientProtocol.doInvoke()
at System.Web.Services.Protocols.SoapHttpClientProtocol.doAsyncInvoke()
at WorkItem.doWork()
at System.Threading.Timer.ring()

What's happening?

If you need more details tell me!

Update:

I have two computers and on both the same error happens. One of then is a Windows 7 Ultimate 64bit, and the other is a Windows Vista Home开发者_开发问答 Premium 32 bit. Maybe it is something releated to code...

Thank you.

This site had an answer that worked for me, using three parts:

1. Disable KeepAlive

   webRequest.KeepAlive = false;

2. Set ProtocolVersion to Version10

   webRequest.ProtocolVersion = HttpVersion.Version10;

3. Limiting the number of service points (ServicePoint is null until GetResponse() is called)

   webRequest.ServicePoint.ConnectionLimit = 1;

For socket exceptions like this, we usually need to capture network traffic using Wireshark or Microsoft Network Monitor to troubleshoot. Only when such information is available we can say what happens on the wire (or wireless).

I've seen this happen when the interval between calls is longer than the HTTP keep-alive timeout and/or some intervening NAT session timeout. The server or middlebox closes the connection, and the client doesn't notice until it tries to reuse the connection. It's appropriate to retry in this case.