Shulou(Shulou.com)06/01 Report--

Transferred from: http://hi.baidu.com/ju_feng/blog/item/b1c41dbf09ad9e0119d81fb0.html

Through Netstat-abn | find ": 443" if there are two network connections with Time_Wait and CLOSE_WAIT status, the service is not available

Solution:

There are only two default connections for 1 HttpWebRequest, so there are only two concurrent requests in the case of multithreading concurrency

You can use System.Net.ServicePointManager.DefaultConnectionLimit = 20

Sets the number of network connection pools for the network HttpWebRequest

2 HttpWebRequest's request that the connection is not released due to network problems will occupy the number of connections in the connection pool, resulting in a reduction in the number of non-connections

You can fix this problem in the following ways:

2.1 set KeepLive detection for ServicePointManager to close the connection if the network does not respond

System.Net.ServicePointManager.SetTcpKeepAlive (true, _ keepLiveTime, _ intervalTime)

3 regular detection of the health status of ServicePoint in HttpWebRequest

/ / ServicePoint point = webReq.ServicePoint

/ / string connectionsGroupName = webReq.ConnectionGroupName

/ / if (point! = null)

/ / {

/ / if (point. > 15)

/ / point.CloseConnectionGroup (connectionsGroupName)

/ /}

4 when using HttpWebRequest, you must ensure that the GetRequestStream and GetResponse objects are closed, otherwise it is easy to cause the connection to be in the CLOSE_WAIT state.

Using (Stream stream = webReq.GetRequestStream ())

{

Stream.Write (buffer, 0, buffer.Length)

}

HttpWebResponse response = null

Try

{

Response = webReq.GetResponse () as HttpWebResponse

}

Finally

{

Try

{

If (response! = null)

Response.Close ()

/ / ServicePoint point = webReq.ServicePoint

/ / string connectionsGroupName = webReq.ConnectionGroupName

/ / if (point! = null)

/ / {

/ / if (point. > 15)

/ / point.CloseConnectionGroup (connectionsGroupName)

/ /}

}

Catch

{

}

}

I am wondering whether there is a way to handle broken (or better: closed) TCP connections that reside in the connection pool (ServicePoint) used by a HttpWebRequest instance. What I have seen on Windows 2003 Server systems is that under certain circumstances, all sockets used to connect to a web service are in CLOSE_WAIT state and all subsequent HttpWebRequests fail with a timeout, no new connections to the web service were opened. Looking at the problem with WireShark, I couldn't see any HTTP traffic even though the application kept on making requests that all ended in a timeout.

I have tried to reproduce this behaviour on a development system by writing a simple HTTP server that closes the socket after it has sent a proper HTTP 1.1 response. If you do this, you will see the same behavior that I have described above. Of course, HTTP 1.1 assumes that by default connections are kept alive unless the server explicitly sends a "Connection: Close" header. Thus, the client-side would assume that the connection should be kept alive although the server (that does not function according to HTTP 1.1) already closed it. What stuns me is that the HttpWebRequest, or more specifically the ServicePoint does not recover from such a situation (on Windows Vista/2003 Server the client-side sockets stay in CLOSE_WAIT until they're killed by the OS, on another development machine running the Windows 7 RC they're killed by the OS rather quickly and are just gone, no new ones will be created in either case).

I have tried various things on the client-side, so far I could not solve this problem (except by disabling keep alive in each HttpWebRequest by setting the "KeepAlive" property to "false"). The following list compiles what I've tried to recover from the situation described above:

-Various combinations of using () blocks to dispose all resources (WebResponse object, stream retrieved by GetResponseStream (), StreamReader that was used to read from the stream), as well as using the WebResponse.Close () method call that do everything required from my understanding of the MSDN documentation.

-Calling CloseConnectionGroup () on the ServicePoint used by the HttpWebRequest to somehow "kill" the connections

-Temporarily disabling keep alives to recover

-Increasing the number of connections in the pool of the ServicePoint so that it doesn't stop the system from functioning properly if some connections die

-Enabling TCP keep alives on the ServicePoint

-Using a lower ConnectionLeaseTimeout on the ServicePoint (works correctly in general, fails to do anything when connections are closed)

Thus, I'd like to ask here whether someone faced similar problems and might know a way to overcome such issues. I'd also like to know whether I am hunting ghosts here, although I still doubt it at the moment. I also don't see how a socket could get into a CLOSE_WAIT state without the remote communication partner closing the connection (i.e. Sending FIN) and I don't understand why Vista/2003 Server do not seem to respond to this by sending a FIN and receiving an ACK to transition from CLOSE_WAIT to LAST_ACK and then to CLOSED. The HTTP server I wrote does not tinker with the LingerState of the TcpClient, default behavior should apply when it comes down to gracefully closing sockets.

Maybe I am missing some very important point about this whole thing, I'd love to be enlightened: -). If you need any further info, I'm happy to supply it.

PS: I have done all of my tests in Visual Studio 2008 linking both .NET 2.0 and .NET 3.5, it doesn't make a difference from what I can tell.

Cheers!

HTTP connection status:

/ KeepLive is activated on the server. The first parameter is that the client enables Keeplive

/ / the second parameter is whether the client closes the network connection.

/ Server: Close_Wait Client:Fin_Wait_2

/ / HttpRequestTest.TestHttpConnect (false, false)

/ Server: Close Client: Time_Wait

/ / HttpRequestTest.TestHttpConnect (false, true)

/ Server: ESTABLISHED Client: ESTABLISHED

/ / HttpRequestTest.TestHttpConnect (true, true)

/ / Server: Close Client: Time_Wait

/ / HttpRequestTest.TestHttpConnect (false, true)

/ / the server shuts down KeepLive. The first parameter is that the client enables Keeplive

/ / the second parameter is whether the client closes the network connection.

/ Server: Close_Wait Client:Fin_Wait_2

/ / HttpRequestTest.TestHttpConnect (false, false)

/ Server: Close Client: Time_Wait

/ / HttpRequestTest.TestHttpConnect (false, true)

/ Server: Close Client: Time_Wait

/ / HttpRequestTest.TestHttpConnect (true, true)

/ Server: Close Client: Time_Wait

/ / HttpRequestTest.TestHttpConnect (false, true)

REF:

Http://social.msdn.microsoft.com/Forums/en-US/netfxnetcom/thread/5c77f187-add4-46cb-a3f8-93e78910eddc

Http://haacked.com/archive/2004/05/15/http-web-request-expect-100-continue.aspx

Http://www.cnblogs.com/zealic/archive/2008/05/01/1107942.html

[@ more@]

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.