도데체 소켓이 안 끊기는 이유는... 멀까요?

정말 외람된 말인데요? ^^;;

실제로 해보셨나요?

위 그림을 보면.. 최소한.. 서버가 close를 했을때..

FIN은 날림니다. 헌데.. 날리질 않는군요..

그러니.. 아싸리.. 종료를 위한 어떤 상태로도 전환이 안됩니다.

한번 해보세여~~~ 만약 된다면.. 제가 먼가 큰 착각을 하고 있는거겠죠??

문제는.. 랜선이 뽑힌 사용자를 서버가 polling 해서 끊는다 (close)

한다 해도..

다음 정상적인 사용자가 바로 접속할때.. 랜선 뽑힌 사용자의 sockfd를

accept에서 그대로 줘서... poll 이나 select에서.. 문제가 생긴다는 겁니당.

답변을 위한 질문좀 하겠습니다.

* 가정
1) 서버 IP : 1.1.1.1
2) 서버 port : 1111
3) Lan cable을 절단(뽑음!)할 클라이언트 IP : 3.3.3.3
4) Lan cable을 절단(뽑음!)할 클라이언트 port : 3333
5) 즉, tcp 5 association ( protocol, src ip, src port, dst ip, dst port)
=> (tcp, 1.1.1.1, 1111, 3.3.3.3, 3333)
6) 서버에서 5)의 5튜플정보를 파일시스템에 연동한 socket descriptor = 36
7) 현재 상태를 테스트 준비 상태라고 함
8) 클라이언트의 랜선을 뽑는다.
9) 8일때, 클라이언트(3.3.3.3)의 3333번 포트로 동작하는 프로그램의 변화, 즉, (tcp, 1.1.1.1, 1111, 3.3.3.3, 3333) 의 상태는 어떻게 되는가?
10) 8일때, 서버(1.1.1.1)의 (tcp, 1.1.1.1, 1111, 3.3.3.3, 3333) 의 상태는 ESTABLISHED이다! 이 접속은 36번 소켓디스크립터로 관리되었었다. 그리고, 랜선을 뽑은 후에도 계속 상태변화가 없다(프로그램에 이벤트도 발생하지 않으며, 따라서 연결종료시에 발생할 이벤트 처리도 안하며, netstat명령으로 보아도 상태변화 없다).
11) 제3의 클라이언트(2.2.2.2)에서 서버접속을 시도했다.
연결 레코드는 (tcp, 1.1.1.1, 1111, 2.2.2.2, ????)이다. 그런데, accept()가 리턴한 소켓 디스크립터는 36이다!

위와 같다는 얘기인가요?
질문의 데이터가 조금 부족합니다. 좀 채워서 질문해주시면....