Custom File Transport 마무리 회고

해당 프로젝트의 0번째 목표는

클라이언트 -> 서버 방향의 Reliable UDP 구조로

충분히 큰 크기(예시로 사용한 건 885MB)의 비디오 파일을
충분히 짧은 시간 내(30초 ~ 1분 이내)에 전송할 것 이었다.

 

오늘 커밋한 시점에서

885 MB 크기의 mp4 파일을 전송하는 데 걸리는 시간을 24초 까지 줄였고.

 

서버 측의 3개 스레드(Listen, Send, Write)와 

클라이언트 측의 2개 스레드(Listen, Send) 모두 정상적으로 종료되는 것 까지 확인했으므로

일단 마무리. (로컬 연결이 아닌 외부 연결로도 작동하는 것까지 확인하긴 해야한다.)

 

해당 R-UDP 구조를 만들기 이전에

TCP 기반의 Echo 서버 - 클라이언트를 만들고,

Protobuf 환경을 만들고, 파일의 메타파일 규칙 작성 등

딴 짓도 많이 했지만

 

우선은 원 목표였던 R-UDP 파일 전송에만 집중하고,

이를 적당히 차트로 표현하자면 다음과 같다.

막상 차트로 표현해보니

크게 복잡하지 않고 간결하다.

 

처음부터 이런 차트를 준비하고 만들기 시작했으면 더 쉽고 빠르게 끝났을 것 같은데,

일단 생각나는대로 적당히 만들고 

고치면서 배워가다보니 시간이 좀 걸렸다.

 

이 과정에서 막혔던 부분들을 헤쳐나가면서 배운 것들을 간단하게 정리해보자면.

1. 콘솔에 로그를 남길 때는 cout 보다는 printf가 더 안정적이다.

이유는 정확히 모르겠으나 짧은 시간 동안 많은 출력이 있을 때는

cout의 동작이 이상할 때가 있다.(한 글자씩 밀려서 출력된다.)

cout을 모두 printf로 바꿔주니 해결되었다.

 

2. 파일을 binary data로 읽을 경우 데이터 형식은 의미가 없다.

char 배열 형식의 포인터 변수에 저장은 하지만

char 형식을 다루듯이 코드를 썼을 때는 전혀 동작하지 않았다.

memcpy를 사용하는 등 메모리로서 다루는 게 맞는 듯 하다.

binary data를 VS 디버거 창에서 읽어낼 수 있는 방법이 따로 있는진 모르겠다.

 

3. UDP 전송이 실패하는 경우

recvfrom이 실행된 이후 send가 실행되는 순서만 지켜진다면

전송이 실패하는 경우는 없었다.

다만 listen thread 측의 recvfrom 보다 send thread 측의 send 속도가 더 빨라져

순서가 보장되지 않는 경우에는 recvfrom이 실행되기 이전의 데이터그램들은 모두 소실된다.

Reliable 구조가 필요한 이유인데,

로컬에서 테스트 할 때는 이 경우 말고는 다른 경우는 없었던 듯 하다.

 

4. 속도 문제

Server측은 Client와 다르게 Listen, Send 쓰레드 외에도 File Write 쓰레드가 하나 더 있는데,

처음 적용 당시에는 Server 측에도 Listen, Send 쓰레드 두 개만 두고 쓰고 있었다.

서버 측 Listen 쓰레드 에서는 recvfrom에서 데이터를 받아내고 다음 recvfrom을 실행하기 까지의

소요 시간이 최대한 짧아야 하므로

서버 측의 Send 쓰레드에서 file write를 하도록 구성했었는데,

이게 속도가 많이 느렸다.(885MB 비디오 전송에 40분 가량)

파일에 데이터 입력을 하는 File Thread를 따로 작성해서 속도 문제는 해결.(24초 가량으로 속도가 빨라짐)

 

그리고 해결해야할 문제들도 아직 많이 남아있다.

1. 메모리 문제

해당 서버는 메타파일을 읽어서 파일의 전체 크기만큼 미리

공간을 준비하는 구조이기 때문에 항상 파일의 크기만큼의 메모리 공간이 필요한데,

파일의 크기가 엄청나게 큰 경우(수십 기가인 경우) 해당 서버 프로그램 혼자서 

메모리를 수십 기가 차지하게 되어버린다.

이건 해결해야할 문제.

 

2. 외부 통신 시 발생할 버그들

로컬 테스트 시에는 통신 속도가 빠르기 때문에 

발생하지 않았던 문제들이 있을 것이다.