Reference code is https://msdn.microsoft.com/en-us/library/system.net.sockets.socketasynceventargs (v=versus 110). Aspx wrote

The service side Listen 2000
Found a TCP client testing tools created 2000 clients connect server and send the data at the same time, all broken after a few seconds, 7, 8 successive repeatedly so the client can't connect the server,
See the server or in the LISTENING state netstat TCP 127.0.0.1:20000 0.0.0.0:0 LISTENING

Could you tell me how to troubleshoot this problem under the? Or what operation can lead to this problem?

CodePudding user response:

The server did not do, the client disconnect processing, socket server in the client disconnected after 5-10 or in the connection state, so in 2000 the client even when they fail!

CodePudding user response:

See if there is a lot of not completely broken connections

CodePudding user response:

You can use first tool, or program self-examination in some debugging data, such as memory usage, number of threads, thread count and IOCP thread pool of worker threads, etc.,

Also consider, change m_maxNumberAcceptedClients to Semaphor Slim , it takes up several support to view the current signal,
If the signal occupies number has not been released, can lead to m_maxNumberAcceptedClients. WaitOne (); Blocked, leading to not continue to the next, the client can't connect the server,

There is code throws an exception if ProcessReceive and ProcessSend, will lead to CloseClientSocket (e); Didn't have a chance to get called, can lead to the connection of signal is going to occupy, has not been released,

CodePudding user response:

The server to do disconnect detection, such as writing is unusual, says disconnect, released at this time to connect the server, otherwise it will affect the connection back,

CodePudding user response:

The service side look at the connection of the netstat all kinds of state data,
The client also use netstat to see the connection status,
Doubt that connection

CodePudding user response:

TCP connection session after the break, take the initiative to open one will enter a state of timewait, for 120-240 seconds (depending on the operating system), in the meantime the session of the source port (random port) is not available, until the port number is released (see "TCP - IP," a book), a TCP connection to your client is too frequent, pressure test should be used to simulate multiple clients machine, instead of one,

Can use the netstat command to view the network session state,

CodePudding user response:

reference github_36000833 reply: 3/f

you can use first tool, or program self-examination in some debugging data, such as memory usage, number of threads, thread count and IOCP thread pool of worker threads, etc.,

Also consider, change m_maxNumberAcceptedClients to Semaphor Slim , it takes up several support to view the current signal,
If the signal occupies number has not been released, can lead to m_maxNumberAcceptedClients. WaitOne (); Blocked, leading to not continue to the next, the client can't connect the server,

There is code throws an exception if ProcessReceive and ProcessSend, will lead to CloseClientSocket (e); Didn't have a chance to get called, can lead to the connection it hadn't been released, the number of signal occupy

is truly the semaphore problem, I just use SemaphoreSlim to see, each take a reconnection will increase the number, ProcessReceive and ProcessSend seems to be no exception, has examined the is the token in the CloseClientSocket Socket. The Close (); Cast defect in semaphore didn't release, token=null, when the client number is greater than the server to monitor the number of this problem, as will appear when in ProcessAccept AcceptSocket. RemoteEndPoint is null, the cast defect in semaphore didn't release, please comment in ProcessAccept AcceptSocket. RemoteEndPoint=null circumstances do handle more appropriate? Direct return can also lead to a semaphore not released

CodePudding user response:

Like this?
Try
{
}
The catch (... )
{
CloseClientSocket (e);
}

Or if the logical fit, put finally block?

CodePudding user response:

If CloseClientSocket (e); Will throw exceptions, that is similar to the following code?

 private void CloseClientSocket (SocketAsyncEventArgs e) 
{
AsyncUserToken token=e.U serToken as AsyncUserToken; 

//close the socket associated with the client 
Try 
{
Token. Socket. Shutdown (SocketShutdown. Send); 
Token. Socket. The Close (); 
} 
//throws the if the client process has already closed 
The catch (Exception) {} 
Finally//& lt; - 
{
//decrement the counter keeping track of the total number of clients connected to the server 
Interlocked. Decrement (ref m_numConnectedSockets); 

//Free the SocketAsyncEventArg so they can be reused by another client 
M_readWritePool. Push (e); 

M_maxNumberAcceptedClients. Release (); 
} 
Console. WriteLine (" A client has had been disconnected from the server. There are {0} clients connected to the server ", m_numConnectedSockets); 
} 

CodePudding user response:

I estimate is your client after all disconnect server connection is still not broken, you can try to define a disconnected request, destroyed notification server connection

CodePudding user response:

reference 5 floor water 2 reply:

server look at the connection of the netstat various state data volume,
The client also use netstat to see the connection status,
Suspected connection fill the

I see server with netstat - ano in the listening state, the client then none

CodePudding user response:

refer to 6th floor datafansbj response:

TCP connection session after the break, take the initiative to open one will enter a state of timewait, for 120-240 seconds (depending on the operating system), in the meantime the session of the source port (random port) is not available, until the port number is released (see "TCP - IP," a book), a TCP connection to your client is too frequent, pressure test should be used to simulate multiple clients machine, instead of one,

You can use the netstat command to view the network session state,

client is turned off, I use netstat - ano see server in the listening state, then there is no client list, the connection should be cut clean?

CodePudding user response:

refer to the eighth floor github_36000833 response:

like this?
Try
{
}
The catch (... )
{
CloseClientSocket (e);
}

Or if the logical fit, put finally block?

I added determine the front in the ProcessAccept

 if (e.A cceptSocket. RemoteEndPoint==null) 
{
M_maxNumberAcceptedClients. Release (); 
StartAccept (e); 
return; 
} 

tried a few times seems to be no problem... I didn't understand why sometimes when an asynchronous connection trigger RemoteEndPoint is null, the problem on the client connection number is greater than the server monitoring at the same time, and then closed at the same time all client RemoteEndPoint occurs is null

CodePudding user response:

nullnullnullnullnullnullnullnullnullnullnullnullnullnull