소켓의 우아한 연결종료
TCP에서는 연결과정보다 중요한 것이 종료과정이다.
연결과정에서는 큰 변수가 발생하지 않지만 종료과정에서는 예상치 못한 일이 발생할 수 있기 때문이다.
따라서 종료과정은 명확해야한다. 이번에 설명하는 Half-close는 명확한 종료를위해 반드시 알아야한다.
일방적인 연결종료의 문제점
리눅스의 close 함수호출과 윈도우의 closesocket 함수 호출은 완전종료를 의미한다. 완전 종료라는 것은 데이터를 전송하는 것은 물론, 수신하는 것조차 더 이상 불가능한 상황을 의미한다.
때문에 한쪽에서의 일방적인 close 또는 closesocket 함수 호출은 경우에 따라서 우아해 보이지 못할 수 있다.
위 그림은 양방향으로 통신하고 있는 두 호스트의 상황을 묘사한 것이다.
상황은 이렇다. 호스트 A가 마지막 데이터를 전송하고 나서 close 함수의 호출을 통해 연결을 종료하였다. 때문에 그 이후부터 호스트 A는 호스트 B가 전송하는 데이터를 수신하지 못한다.
그말은 즉, 데이터 수신과 관련된 함수의 호출 자체가 불가능하다. 때문에 결국엔 호스트 B가 전송한, 호스트 A가 반드시 수신해야할 데이터라 할지라도 그냥 소멸되고 만다.
이러한 문제를 해결을 위해서 데이터의 송수신에 사용되는 스트림의 일부만 종료(Half-close)하는 방법이 제공되고 있다.
일부를 종료한다는 것은 전송은 가능하지만 수신을 불가능한 상황, 혹은 수신은 가능하지만 전송은 불가능한 상황을 뜻한다. 말 그대로 스트림의 반만 닫는 것이다.
소켓과 스트림(stream)
소켓을 통해서 두 호스트가 연결되면, 그 다음부터는 상호간에 데이터의 송수신이 가능한 상태가 된다.
그리고 바로 이러한 상태를 가리켜 '스트림이 형성된 상태'라 한다. 즉, 두 소켓이 연결되어서 데이터의 송수신이 가능한 상태를 일종의 스트림으로 보는 것이다.
스트림은 물의 흐름을 의미하지만, 물의 흐름은 한쪽 방향으로만 형성된다.
마찬가지로 소켓의 스트림 역시 한쪽 방향으로만 데이터의 이동이 가능하기 때문에 양방향 통신을 위해서는 다음 그림에서 보이듯 두 개의 스트림이 필요하다.
때문에 두 호스트간에 소켓이 연결되면, 각 호스트 별로 입력 스트림과 출력 스트림이 형성된다.
물론 한 호스트의 입력 스트림은 다른 호스트의 출력 스트림으로 이어지고, 한 호스트의 출력 스트림은 다른 호스트의 입력 스트림으로 이어진다. 그리고 우리가 이번 Chapter에서 하고자하는 우아한 종료는 한번에 이 두스트림을 모두 끊어버리는 것이 아니라, 이 중 하나의 스트림만 끊는 것이다.
물론 리눅스 close 함수와 윈도우의 closesocket 함수는 두 가지 스트림을 동시에 끊어버리기 때문에 우아한 연결종료와는 거리가 멀다.
우아한 종료를 위한 shutdown 함수
그럼 이제 우아한 종료, 즉 Half-close에 사용되는 함수를 소개하겠다. 다음 shutdown 함수가 스트림의 일부를 종료하는데 사용되는 함수이다.
#include <sys/socket.h>
int shutdown(int sock, int howto); // 성공시 0, 실패시 -1 반환- sock : 종료할 소켓의 파일 디스크립터 전달
- howto : 종료방법에 대한 정보 전달
위 함수 호출 시 두번째 매개변수에 전달되는 인자에 따라 종료의 방법이 결정된다. 두번째 매개변수에 전달될 수 있는 인자의 종류는 다음과 같다.
- SHUT_RD : 입력 스트림 종료
- SHUT_WR : 출력 스트림 종료
- SHUR_RDWR : 입출력 스트림 종료
shutdown 함수의 두번째 인자로 SHUT_RD가 전달되면 입력 스트림이 종료되어 더 이상 데이터를 수신할 수 없는 상태가 된다. 혹 데이터가 입력버퍼에 전달되더라도 그냥 지워져버릴 뿐만 아니라 입력 관련 함수의 호출도 더 이상은 허용이 안된다. 반면 SHUT_WR가 두번째 인자로 전달되면 출력 스트림이 종료되어 더 이상의 데이터 전송이 불가능해진다.
단! 출력 버퍼에 아직 전송되지 못한 상태로 남아있는 데이터가 존재하면 해당 데이터는 목적지로 전송된다. 마지막으로 SHUT_RDWR가 전달되면 입력 스트림과 출력 스트림이 모두 종료되는데, 이는 shutdown 함수를 한번은 SHUT_RD를 인자로, 또 한번은 SHUT_WR을 인자로 두번 호출한 것과 같다.
Half-close가 필요한 이유
소켓을 반만 닫는다는 것에 대한 의미는 설명을 했지만, 아직 풀어야할 궁금증이 남아있다.
"그냥 데이터를 주고받기에 충분한 만큼 연결을 유지했다가 종료하면 되지 않나?
급히 종료하지만 않으면 Half-close가 필요하지는 않을 것 같은데..."
전혀 틀린 말은 아니지만, 충분한 시간적 여유를 둬서 송수신을 완료하고 난 다음에 연결을 종료해도 되는 상황에서 굳이 Half-close를 활용할 필요가 없다. 그러나 다음과 같은 상황을 생각해보자.
"클라이언트가 서버에 접속하면 서버는 약속된 파일을 클라이언트에게 전송하고,
클라이언트는 파일을 잘 수신했다는 의미로 문자열 'Thank you'를 서버에 전송한다."
여기서 문자열 "Thank you"의 전달은 사실상 불필요한 일이지만, 연결종료 직전에 클라이언트가 서버에 전송해야할 데이터가 존재하는 상황으로 확대해석하기 바란다. 그런데 이 상황에 대한 프로그램의 구현도 그리 간단하지는 않다.
파일을 전송하는 서버는 단순히 파일 데이터를 연속해서 전송하면 되지만, 클라이언트는 언제까지 데이터를 수신해야 할지 알 수 없기 때문이다. 클라이언트 입장에서는 무턱대고 계속해서 입력함수를 호출할 수도 없는 노릇이다.
그랬다가는 블로킹 상태(호출된 함수가 반환하지 않는 상태)에 빠질 수 있기 때문이다.
"서버와 클라이언트 사이에 파일의 끝을 의미하는 문자 하나를 약속하면 되지 않나?"
이것도 어울리지 않는 상황이다. 약속으로 정해진 문자와 일치하는 데이터가 파일에 존재할 수 있기 때문이다.
이러한 문제의 해결을 위해서 서버는 파일의 전송이 끝났음을 알리는 목적으로 EOF를 마지막에 전송해야 한다.
클라이언트는 EOF의 수신을 함수의 반환 값을 통해 확인이 가능하기 때문에 파일에 저장된 데이터와 중복될 일도 없다.
그럼 이제 남은 문제는 하나이다. 서버는 어떻게 EOF를 전달할 수 있을까?
"출력 스트림을 종료하면 상태 호스트로 EOF가 전송된다"
물론 close 함수호출을 통해 입출력 스트림을 모두 종료해줘도 EOF는 전송되지만, 이럴 경우 상대방이 전송하는 데이터를 더 이상 수신 못한다는 문제가 있다. 즉, close 함수 호출을 통해 스트림을 종료하면 클라이언트가 마지막으로 보내는 문자열 "Thank you"를 수신할 수 없다. 따라서 shutdown 함수 호출을 통해서 서버의 출력 스트림만 Half-close 해야하는 것이다. 이럴 경우 EOF도 전송되고 입력 스트림은 여전히 살아있어서 데이터의 수신도 가능하다. 그럼 지금까지 설명한 내용을 바탕으로 실제 파일을 송수신하는 서버와 클라이언트를 구현해보자.
Half-close 기반의 파일 전송 프로그램
위에서 언급한 파일전송 서버, 클라이언트의 데이터 흐름을 정리하면 다음과 같다. 이 흐름에 맞게 예제를 작성해볼텐데, 이를 통해 EOF 전달의 필요성과 Half-close의 필요성을 인식하면 된다.
먼저 서버 프로그램을 작성해보자.
// file_server.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#define BUF_SIZE 30
void error_handling(char* message);
int main(int argc, char* argv[])
{
int serv_sd, clnt_sd;
FILE *fp;
char buf[BUF_SIZE];
int read_cnt;
struct sockaddr_in serv_adr, clnt_adr;
socklen_t clnt_adr_sz;
if(argc != 2)
{
printf("Usage : %s <port> \n", argv[0]);
exit(1);
}
fp = fopen("file_server.c", "rb");
serv_sd = socket(PF_INET, SOCK_STREAM, 0);
memset(&serv_adr, 0, sizeof(serv_adr));
serv_adr.sin_family = AF_INET;
serv_adr.sin_addr.s_addr = htonl(INADDR_ANY);
serv_adr.sin_port = htons(atoi(argv[1]));
bind(serv_sd, (struct sockaddr*)&serv_adr, sizeof(serv_adr));
listen(serv_sd, 5);
clnt_adr_sz = sizeof(clnt_adr);
clnt_sd = accept(serv_sd, (struct sockaddr*)&clnt_adr, &clnt_adr_sz);
while(1)
{
read_cnt = fread((void*)buf, 1, BUF_SIZE, fp);
if(read_cnt < BUF_SIZE)
{
write(clnt_sd, buf, read_cnt);
break;
}
write(clnt_sd, buf, BUF_SIZE);
}
shutdown(clnt_sd, SHUT_WR);
read(clnt_sd, buf, BUF_SIZE);
printf("Message from client : %s \n", buf);
fclose(fp);
close(clnt_sd);
close(serv_sd);
return 0;
}
void error_handling(char* message)
{
fputs(message, stderr);
fputc('\n', stderr);
exit(1);
}
// file_client.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#define BUF_SIZE 30
void error_handling(char* message);
int main(int argc, char* argv[])
{
int sd;
FILE *fp;
char buf[BUF_SIZE];
int read_cnt;
struct sockaddr_in serv_adr;
if(argc != 3)
{
printf("Usage : %s <IP> <Port>\n", argv[0]);
exit(1);
}
fp = fopen("receve.dat", "wb");
sd = socket(PF_INET, SOCK_STREAM, 0);
memset(&serv_adr, 0, sizeof(serv_adr));
serv_adr.sin_family = AF_INET;
serv_adr.sin_addr.s_addr = inet_addr(argv[1]);
serv_adr.sin_port = htons(atoi(argv[2]));
connect(sd, (struct sockaddr*)&serv_adr, sizeof(serv_adr));
while((read_cnt = read(sd, buf, BUF_SIZE )) != 0)
fwrite((void*)buf, 1, read_cnt, fp);
puts("Received file data");
write(sd, "Thank you", 10);
fclose(fp);
close(sd);
return 0;
}
void error_handling(char* message)
{
fputs(message, stderr);
fputc('\n', stderr);
exit(1);
}
예제의 실행 결과이다. 서버를 열고 클라이언트를 실행하면 파일 데이터를 받았다는 출력문과 메세지를 받아서 땡큐가 동시에 출력될것이다.
클라이언트와 서버에서 동시에 출력된다면 실행파일이있는 디렉터리에 receive.dat 파일이 만들어져있을 것이다.
nano recive.dat 으로 receive의 파일을 확인해보면 file_server.c 코드가 그대로 복사되있는 것을 확인할 수 있다.
따라서 file_server.c 의 코드가 파일전송을통해 receive.dat 라는 이름의 파일로 잘 복사된 것을 확인할 수 있다.
'개발자과정준비 > TCP IP Socket Programming' 카테고리의 다른 글
| [Socket 프로그래밍] 9. 소켓의 다양한 옵션 (0) | 2021.06.24 |
|---|---|
| [Socket 프로그래밍] 8. 도메인 이름과 인터넷 주소 (0) | 2021.06.23 |
| [Socket 프로그래밍] 6. UDP 기반 서버/클라이언트 (0) | 2021.06.21 |
| [Socket 프로그래밍] 5. TCP 기반 서버/클라이언트 2 (1) | 2021.06.18 |
| [Socket 프로그래밍] 4. TCP 기반 서버/클라이언트 1 (0) | 2021.06.17 |
