ERROR_SEM_TIMEOUT

121 (0x79)

The semaphore timeout period has expired.

내가 끊은적도 없고 클라도 아니고 통신량이 많아서 강제적으로 끊어짐.

그렇다고 내 잘못이 아니라고 하기 힘들다.

네트워크 전송량은 늘어나는데 메시지 TPS는 떨어짐.

일정시간 지속되면 끊어지는 녀석들이 생길수있음.

관련 현상은 모니터링쪽 코드 추가해서 관리가 필요함.

listen function

• 12/05/2018
• 5 minutes to read

The listen function places a socket in a state in which it is listening for an incoming connection.

Syntax

C++Copy

int WSAAPI listen( SOCKET s, int backlog );

Parameters

s

A descriptor identifying a bound, unconnected socket.

backlog

The maximum length of the queue of pending connections. If set to SOMAXCONN, the underlying service provider responsible for socket s will set the backlog to a maximum reasonable value. If set to SOMAXCONN_HINT(N) (where N is a number), the backlog value will be N, adjusted to be within the range (200, 65535). Note that SOMAXCONN_HINT can be used to set the backlog to a larger value than possible with SOMAXCONN.

SOMAXCONN_HINT is only supported by the Microsoft TCP/IP service provider. There is no standard provision to obtain the actual backlog value.

SOMAXCONN_HINT(N)라는 매크로가 하나가 더 있다. 큐 조절 가능

http://foroum.gpgstudy.com/forum/viewtopic.php?t=12603

https://www.gpgstudy.com/forum/viewtopic.php?t=20093

https://gpgstudy.com/forum/viewtopic.php?t=3356#p12227

https://gpgstudy.com/forum/viewtopic.php?t=15420

https://gpgstudy.com/forum/viewtopic.php?t=6697

http://w.gpgstudy.com/forum/viewtopic.php?t=7642

http://foroum.gpgstudy.com/forum/viewtopic.php?t=3457

https://www.gpgstudy.com/forum/viewtopic.php?f=18&t=23484

http://foroum.gpgstudy.com/forum/viewtopic.php?t=4380

https://www.gpgstudy.com/forum/viewtopic.php?t=18249

https://www.gpgstudy.com/forum/viewtopic.php?t=24446

https://gpgstudy.com/forum/viewtopic.php?t=19446

4-way-handshake 진입 시 

의외로 FIN_WAIT_1이나 TIME_WAIT가 너무 많이 남는다.

특히 IOCP때 잘못 설계시 종료에 대한 응답이 오지 않는 상태로 남는다.

일정시간 지나면 없어지긴한다. 다만 일시적으로 많이 생기면 불안요소로 남게된다.

링거 걸고 클로즈 소켓 유도(Time_out)해서 RST로 파괴

Graceful Shutdown, Linger Options, and Socket Closure

The following material is provided as clarification for the subject of shutting down socket connections closing the sockets. It is important to distinguish the difference between shutting down a socket connection and closing a socket.

Shutting down a socket connection involves an exchange of protocol messages between the two endpoints, hereafter referred to as a shutdown sequence. Two general classes of shutdown sequences are defined: graceful and abortive (also called hard). In a graceful shutdown sequence, any data that has been queued, but not yet transmitted can be sent prior to the connection being closed. In an abortive shutdown, any unsent data is lost. The occurrence of a shutdown sequence (graceful or abortive) can also be used to provide an FD_CLOSE indication to the associated applications signifying that a shutdown is in progress.

Closing a socket, on the other hand, causes the socket handle to become deallocated so that the application can no longer reference or use the socket in any manner.

In Windows Sockets, both the shutdown function, and the WSASendDisconnect function can be used to initiate a shutdown sequence, while the closesocket function is used to deallocate socket handles and free up any associated resources. Some amount of confusion arises, however, from the fact that the closesocket function implicitly causes a shutdown sequence to occur if it has not already happened. In fact, it has become a rather common programming practice to rely on this feature and to use closesocket to both initiate the shutdown sequence and deallocate the socket handle.

To facilitate this usage, the sockets interface provides for controls by way of the socket option mechanism that allow the programmer to indicate whether the implicit shutdown sequence should be graceful or abortive, and also whether the closesocket function should linger (that is not complete immediately) to allow time for a graceful shutdown sequence to complete. These important distinctions and the ramifications of using closesocket in this manner are still not widely understood.

By establishing appropriate values for the socket options SO_LINGER and SO_DONTLINGER, the following types of behavior can be obtained with the closesocket function:

• Abortive shutdown sequence, immediate return from closesocket.
• Graceful shutdown, delaying return until either shutdown sequence completes or a specified time interval elapses. If the time interval expires before the graceful shutdown sequence completes, an abortive shutdown sequence occurs, and closesocketreturns.
• Graceful shutdown, immediate return—allowing the shutdown sequence to complete in the background. Although this is the default behavior, the application has no way of knowing when (or whether) the graceful shutdown sequence actually completes.

The use of the SO_LINGER and SO_DONTLINGER socket options and the associated linger structure is discussed in more detail in the reference sections on SOL_SOCKET Socket Options and the linger structure.

One technique that can be used to minimize the chance of problems occurring during connection teardown is to avoid relying on an implicit shutdown being initiated by closesocket. Instead, use one of the two explicit shutdown functions, shutdown or WSASendDisconnect. This in turn causes an FD_CLOSE indication to be received by the peer application indicating that all pending data has been received. To illustrate this, the following table shows the functions that would be invoked by the client and server components of an application, where the client is responsible for initiating a graceful shutdown.

일반적인 4way handshake가 아닌 반절 끊기

어디다 사용할까

오버랩IO때 새 소켓 생성을 만들지 않게 연결만 끊고 재활용할때 Shutdown

.

.

.// 나중에

ARP PINRT

netsh interface ipv4 show subinterfaces : MTU 체zm 

APP계층 abc입력 send 호출

TCP계층 TCP헤더에는 포트가 주력 TCP헤더 = [TCP][abc] src:42000 dest:10000
0->50받으면 다시 51(ACK:회신) 보냄