CLOSE_WAIT
클라이언트가 데이타를 전송함과 동시에 close할 경우 FIN이 붙어서 동시에 전송되는 경우가 있다.
이때 서버는 CLOSE_WAIT 상태로 계속남아있어서 이 패턴이 반복되면 통신자체가 되지 않게된다.
1. send 이후 약간의 시간을 두고 close하거나
2. send/recv/close 패턴의 경우는 문제가 없어보인다.
3. SO_LINGER 옵션을 이용하면 된다.
TIME_WAIT
TCP의 서버 프로그램을 종료한 바로뒤 다시 서버를 기동하면 bind에서 에러(Address aleady in use)로 끝날 때가 있다. 서버에서 active close를 한 경우(클라이언트가 active close하면 상관없음). 이때는 2 * MST를 기다려야한다.
이 문제는 TCP 자체 사양에 의하여 일어나는 문제로서 TCP의 TIME_WAIT상태가 bind를 fail시킨다.
가만히 생각해보면 TIME_WAIT상태가 없다면, 서버가 끝나자 마자 동일 포트를 다른 프로그램이 바인드해서 원래 서버와 통신하던 클라이언트의 정보를 읽을 수 있는 문제가 발생할 수 있다.
TIMW_WAIT상태로 남아있는 TCP세션이 있더라도 bind하려면 setsockopt로 SO_REUSEADDR을 켠다.
클라이언트가 데이타를 전송함과 동시에 close할 경우 FIN이 붙어서 동시에 전송되는 경우가 있다.
이때 서버는 CLOSE_WAIT 상태로 계속남아있어서 이 패턴이 반복되면 통신자체가 되지 않게된다.
1. send 이후 약간의 시간을 두고 close하거나
2. send/recv/close 패턴의 경우는 문제가 없어보인다.
3. SO_LINGER 옵션을 이용하면 된다.
TIME_WAIT
TCP의 서버 프로그램을 종료한 바로뒤 다시 서버를 기동하면 bind에서 에러(Address aleady in use)로 끝날 때가 있다. 서버에서 active close를 한 경우(클라이언트가 active close하면 상관없음). 이때는 2 * MST를 기다려야한다.
이 문제는 TCP 자체 사양에 의하여 일어나는 문제로서 TCP의 TIME_WAIT상태가 bind를 fail시킨다.
가만히 생각해보면 TIME_WAIT상태가 없다면, 서버가 끝나자 마자 동일 포트를 다른 프로그램이 바인드해서 원래 서버와 통신하던 클라이언트의 정보를 읽을 수 있는 문제가 발생할 수 있다.
TIMW_WAIT상태로 남아있는 TCP세션이 있더라도 bind하려면 setsockopt로 SO_REUSEADDR을 켠다.