TCP/IP 프로토콜을 연결 지향성 프로토콜이라고 합니다. 즉, 클라이언트가 서버로 데이터를 전송하기 전에 먼저 어느 서버에 접속할지를 결정하고 접속 요청을 하게 됩니다. 서버가 접속 요청을 수락하고 서로 연결이 된다면 이후로 통신을 끊을 때까지 목적지를 언급할 필요 없이 데이터를 전송하면 됩니다. 데이터를 전송할 때마다 매번 목적지를 지정하면서 통신하는 UDP/IP하고는 다른 모습이죠.

이렇게 서버와 접속 후에 데이터를 전송할 때 복잡한 프로토콜을 구성하지 않아도 자료 누락 없이 데이터를 전송할 수 있는 것은 IP 위에서 실행되는 TCP 덕분입니다. 혹시나 잃어 버리거나 잘못 받았다면 TCP/IP가 알아서 받아 주죠. 애플리케이션은 데이터를 잘 받았는지 확인할 필요가 없습니다. 

그렇다면 TCP/IP만 절대적으로 믿고 데이터 통신하면 될까요?

이론으로는 믿어도 되지만, 안타깝게도 현실은 그렇지 못합니다. 분명 서버와 연결되어 있고 몇 시간 전까지만 해도 이상 없이 통신이 되었는데 지금은 이상하게 데이터를 주고 받지 못합니다. 끊기기라도 했으면 끊겼다는 이벤트를 받으면 어찌 해결하겠는데 끊겼다는 이벤트도 없습니다.

경험을 통해 TCP/IP는 편한 프로토콜이지만, 맹신할 수 없는 프로토콜임을 말씀 드립니다. 실제 랜 케이블이 빠졌거나 또는 선이 끊길 수 있습니다. 상대 컴퓨터가 갑자기 꺼질 수 있고 하드디스크가 꽉 차서 통신 중에 멈춤이 발생할 수 있습니다.
생각해 보면 정말 다양한 변수가 많습니다. 그렇다면 어떻게 해야 할까요?
TCP/IP 통신을 하는 클라이언트와 서버를 모두 타이머를 이용하든 다른 방법을 사용해서라도 서로의 연결을 주기적으로 확인해야 합니다.

클라이언트는 자료를 주기적으로 요청한다면 응답 데이터에 대한 타임 아웃 루틴을 이용하여 일정 시간 데이터가 없다면 연결을 스스로 끊고 다시 접속을 시도해야 합니다. 주기적으로 요청하지 않는다면 계속 접속해 있기 보다는 필요할 때 접속해서 자료를 구하고 바로 끊는 것이 안전합니다.

서버는 클라이언트의 최근 요청 시간을 현재 시간과 비교해서 일정 시간 이상 아무런 요구가 없다면 끊는 것이 좋습니다.
경우에 따라서 같은 IP가 접속해 오면 이전 접속을 끊는 경우도 있는데, 이때 주의할 것은 같은 PC에서 두 개 이상의 애플리케애션이 같은 TCP/IP 포트로 접속하지 않는다는 보장이 있어야 합니다. 두 번째 접속이 정상적인 접속을 끊어 버리게 되는 요인이 되니까요.
이 게시물을...