tcp 소켓 프로그래밍 질문입니다.

TCP connection이 연결되어있는 서버-클라이언트가 있는데요..

클라이언트가 비정상적으로 종료되면

Tcp 서버가 connection이 끊어진것을(close)

모를수도 있나요? 인터넷에서 관련된 내용을 찾았는데요..

어떤 상황에서 발생할수 있는지 조언 좀 부탁 드릴께요

=======================================

2. How can I detect that the other end of a TCP connection has
crashed? Can I use "keepalives" for this?

Detecting crashed systems over TCP/IP is difficult. TCP doesn't
require any transmission over a connection if the application
isn't sending anything, and many of the media over which TCP/IP is
used (e.g. Ethernet) don't provide a reliable way to determine
whether a particular host is up.

If a server doesn't hear from a client,
it could be because it has nothing to say, some network
between the server and client may be down,

the server or client's network interface may be disconnected,
or the client may have crashed.

Network failures are often temporary
(a thin Ethernet will appear down while someone is adding a link to the daisy
chain, and it often takes a few minutes for new routes to stabilize when a router goes down)
and TCP connections shouldn't be dropped as a result.

Keepalives are a feature of the sockets API that requests that an
empty packet be sent periodically over an idle connection; this
should evoke an acknowledgement from the remote system if it is
still up, a reset if it has rebooted, and a timeout if it is down.
These are not normally sent until the connection has been idle for
a few hours. The purpose isn't to detect a crash immediately, but
to keep unnecessary resources from being allocated forever.

If more rapid detection of remote failures is required, this
should be implemented in the application protocol. There is no
standard mechanism for this, but an example is requiring clients
to send a "no-op" message every minute or two. An example protocol
that uses this is X Display Manager Control Protocol (XDMCP), part
of the X Window System, Version 11; the XDM server managing a
session periodically sends a Sync command to the display server,
which should evoke an application-level response, and resets the
session if it doesn't get a response (this is actually an example
of a poor implementation, as a timeout can occur if another client
"grabs" the server for too long).