기억창고

일반적인 네트워크 프로그래밍의 마지막 부분 IOPC 소스는 간단한 에코 서버를 구현한 예제들이 많은데요

대체로 이런 소스를 기능별로 잘 살펴보시면 크게 2가지로 구분되어 있습니다.

우선 윈도에서 통신을 구현하는 API가 있겠고, 각각의 클라이언트 세션 정보를 가지고 있는 객체들이 있습니다.

이 세션에 대해서 직접 제어해야 다른 인위적인 행위 (특정 세션에 데이터 송수신 및 접속 종료 같은)를 할 수 있겠군요.

위의 소스는 정말 간단히 핵심만 구현시켜놓은 형태로 볼 수 있으며, 이를 자동차로 바꿔 보면, 차체 프레임에 바퀴 끼고 엔진만 올린 상태로 볼 수 있습니다. 차야 굴러가겠지만, 실제 공도에 나왔다간 큰일 날 겁니다.
어쨌든 위의 마인드맵과 같이 각 분야를 객체로 표현해 봅시다, 그러면 어느 정도 코드 정리도 되고, 코드가 정리돼야 추가 기능 확장도 쉽겠죠.

그럼 각 분야별로 어떻게 만들어 보면 좋을지 생각해 봅시다.

1. 네트워크 API: 전체 네트워크를 통제하는 역할이 주로 이루어집니다.
2. 세션 정보: 세션은 2 단말기 간의 통신이 연결됨을 나타냅니다.
                   클라이언트에게서 오는 데이터를 받고 전송해야 하는 역할을 해야 합니다.
3. 2번에서 데이터를 받아서 그대로 돌려주면. 에코 서버겠죠?
   여기에 데이터를 변형하는 로직을 분리해서 서버 기능 확장을 하도록 합시다.

이렇게 하면 대략 아래와 같이 생각할 수 있을 것 같군요.

조금은 눈에 들어오시나요?
이제 마인드맵을 그려서 대략 그림이 나왔으니, 각각 설계해봅시다.
설계는 맨 처음 언급했듯이 간단한 Activity랑 Class 다이어그램을 그려 보시기 바랍니다. 그리고 이후 제가 한 것과 비교해 보는 것이 좋을 것 같네요. 

서버는 아래와 같이 처리가 이루어지면 좋을 것 같군요.
Active 다이어그램과 같이 에코 코드의 기본 옵션을 역할별로 나눠 기술했습니다.
여기서 ContetnsProcess, Package 같은 것은 이다음에 기술되어 있으니 같이 보시기 바랍니다.
다음은 Session 역할입니다.

  
어떻게 보면 꽤 당연한 것을 Active로 나타내니 왜 이것을 할 까란 생각이 드실지도 모르겠습니다만, Activity를 그려야 모듈에서 어떤 일이 필요한지 정리되고 이를 바탕으로 Class 다이어그램을 그려야 좀 더 정교하게 그릴 수 있습니다. 물론 구현하다 보니 생각지도 못한 기능을 구현할 때도 있습니다만, 이는 그때그때 다시 그리면 좋겠죠. 한입에 다 먹으려고 하면 체합니다.
지금 설계의 기능을 보시면 소켓 데이터를 가지고 있고, 각각을 구별한 id 값, 접근, 전송, 수신, 끊기 기능을 넣고 있습니다.

다음은 데이터를 어떻게 처리할 것인가에 대해서 생각해 보겠습니다.
데이터는 세션으로부터 와서 이걸 패키징하는 처리와 이 패키징된 데이터를 가지고 실제 프로그램 처리 하는 부분으로 나눠 생각해 봅시다.

패킷 흐름은 recv를 한 이후, 그 byte 데이터(stream이라고 표현합니다)를 패키지로 만들어 낸 뒤, 이것을 패킷 처리 전담 처리에 넣는 과정을 담았습니다.
패키지(Package)는 말 그대로 소포의 의미입니다. 왜 소포 개념을 넣었느냐면, 소포처럼 받은 사람, 보낸 사람의 정보(세션 데이터)와 내용 물(데이터)가 있어야 반대로 나에게 보낸 클라이언트에 결과값을 줄 수 있기 때문입니다.

객체 지향은 말 그대로 소스를 현실 사물과 투과시킴으로써 사람이 좀 더 이해하기 편함에 목적을 두었다고 생각합니다. 그러므로 이런 용어를 사용하였습니다 패키지화하지 않고 내용을 분석해 처리해도 되지만, 네트워크 IO 처리에 부하가 가는 것을 막기 위해 일반적으로는 따로 처리 프로세스를 나눠서 처리합니다.
(보통 소포 물은 집에 와서 확인하지 직접 우체국 가서 찾은 뒤, 내용물 확인하지는 않죠?)

패킷 프로세스 처리는 간단합니다.
초기환경 설정이라 했지만, 내부적으로는 서버마다 오는 패킷을 처리하는 함수들을 등록하는 과정이며, 이를 큐에서 적절히 꺼내 내부 함수에 넘겨주는 역할을 담당합니다.

위의 Active 다이어그램을 바탕으로 클래스 도식화를 해보았습니다.

ContentsProcess Packet을 받아서 처리하는 곳입니다.
밑에 ServerContetsProcess가 있는데, 서버마다 패킷을 받으면 처리할 내용을 담을 것입니다.
Packet도 마찬가지입니다. 이 앞 패킷 처리에서 더 자세히 다룰 예정입니다만, Packet을 상속받아 각각의 ContentsPacket들을 만들어 보낼 것입니다.
Stream이라는 것이 보이는데 이는 데이터를 시리얼라이징(직렬 화) 하는 데 도움을 주는 클래스이며, 역시 이다음 장에 자세히 기술하겠습니다.

아직 저 클래스만으로는 어떻게 돌아가는지 잘 파악이 안되실 거 같지만, 위의 클래스를 바탕으로 서버, 세션, 패킷 클래스를 만들어 보도록 하겠습니다.
그리고 네트워크 라이브러리이므로 다시 라이브러리 프로젝트에서 작업하도록 합시다.

랜덤 함수를 써서 적절히 처리했습니다만, 이러면 정말 될까요?
혹시 rand 함수가 어느 숫자까지 랜덤으로 뽑을 수 있는지 알고 계시나요?

16bit 컴퓨터 당시의 잔재로 생각됩니다만, 왜 하필이면 0~0x7FF로 제한을 두었을까요?
C++의 rand 함수는 아래의 레머(Lehmer)가 고안한 알고리즘을 활용합니다.

f(x) = (A * f(x-1) + C ) mod M

즉, 계산을 통한 난수를 만듭니다. 이를 pseudo-random number, 의사 난수라 합니다.
의사 난수 공식에 사용되는 A, C, M은 정수이며, A가 8로 나눌 때 나머지가 5인 수, C 가 홀수 이면, 0 ~ (M-1)까지의 정수가 M 주기로 한 번씩 나타나는 성질을 이용하죠.

 
이제 무엇이 문제인지 눈치를 채셨나요?

아까 디아블로3의 마법사의 로망 “워의 마법봉” 드랍 확률을 1/1000이라고 합시다. 
그리고 위의 함수 처리로 아이템을 드랍시킨다면,
int itemRatio = rand() % 1000; if (itemRatio == 987) return “워의 마법봉”; 으로 작성되겠죠.

여기서 레퍼런스 랜덤 함수 처리, 0~32767 에서 나오는 숫자 중 %1000을 하게 되면 확률적으로 0~767 id가 33번 나올 때, 768~999까지 32번 나오겠네요.

이거 게임 밸런스가 미묘하게 틀어지기 시작하는군요.
현실적으로 기획자가 이 아이템은 십만 분의 1 확률로 나오도록 처리하도록 해봅시다.
코드 상으로는 아마 int itemRatio = rand() % 100000; 이 되겠군요.
그럼, 과연 32768 ~ 99999의 숫자가 나올까요? 위 id의 게임 아이템은 절대 얻을 수 없겠죠.
또, rand는 시드 값 위 식에서 f(0) 값으로 srand 함수를 사용하여 지금 시각을 주도록 코딩하는데, 이 srand 시드 값은 프로그램 전체에 영향을 미칩니다.

그런데 rand의 난수 범위가 short 최대치 인지라, 이 랜덤 순열은 1주 ~ 2, 3주 러닝 타임을 가진 게임 서버 프로그램에서 난수 순환이 빨리 오겠죠.
결국, 이런 여러 문제로 기본 C언어 (POSIX C이라고 합니다)의 rand 함수는 게임 프로그램에 사용하는 것은 위험한 요소가 많습니다.

그럼 어떻게 하면 좋을까요?

수학자들은 이미 해결을 했습니다.
보통 메르센 트위스터 랜덤(Mersenne Twister random)이라고 해서 RandomMT라고 표현하기도 합니다.

(MT는 Multi Thread 약자가 아닙니다) 난수의 반복주기가 메르센 소수(Mp = 2p - 1 )라 그 품질이 좋고,

이 주기가 2의 19937 제곱 -1이므로 위의 예와 같은 rand() % 1000으로 몇몇 숫자 범위 대에 확률이 낮아지지 않습니다. (오차 범위에 수렴하죠).

게다가 rand 함수보다 빠르기도 합니다. (비트연산 코드입니다) 실제 구현 소스는 아래 사이트에서 열람할 수 있습니다.

 http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html

C++0x11 이후 버전에서는 이 함수를 아예 표준 라이브러리에 포함 시켰습니다.
이를 활용한 클래스는 아래와 같습니다.

잘 보시면 엔진 초기화 할 때, srand 처럼 현재 시각을 넣는데 거기에 현 쓰레드의 hash 번호를 더해서 넣어 주었습니다. 각각 쓰레드 마다 다른 값을 줘야 하기 때문이죠.
아마 현업에서는 이 코드를 직접 구현한 곳이 많을 겁니다.

아니면 이것을 또 개선한 RandomWell을 쓸 겁니다.
여기서는 메르센 트위스터 19937을 사용했지만, 심화로 Random Well 소스를 위의 사이트에서 구해서 작성해 보시는 것도 좋은 경험이라 생각합니다. (생각보다 몇 줄 안 합니다)  

서버 프로그램은 복잡한 시스템이라 많은 로직들이 산재 하고 있습니다.
하지만, 이들 로직을 정리하고 공용화 한다면 라이브러리로 모을 수 있을 것입니다.

여기 라이브러리는 이런 도움되는 간단한 로직 처리들이라고 보시면 됩니다.

드라이버, 니퍼, 펜치, 몽키 스페어나 크레인 없이 철, 고무, 유리만 떨렁 주고 자동차를 만들라고 하면 만들 수 있을까요?
프로그램도 마찬가지 입니다. 거대한 시스템을 구축하기 위해서는 그 시스템에 필요한 기초 로직들이 필요합니다.

보통 Util 이라고 칭하거나, [회사이름]Lib  혹은 [특허명]라이브러리 같은 식으로 사용합니다.
음…… 그런데 무엇부터 만들어야 할까요?
이럴 땐 이전에 말씀드렸던 것처럼, 마인드맵으로 생각을 정리해 봅시다.
전 대략 아래와 같이 생각나서 아래의 것만 여기서 설명해 드리려 합니다.
만약 빠진 것이 있다면 여기서 더 추가하셔서 구현시켜 놓는 편이 좋을 거 같네요.

제가 작성한 책의 코드들을 보시기 전에 아래의 규칙에 의해 책의 소스가 작성되어 있으니 미리 읽어 두셔서 코드 보시는 데 도움이 되셨으면 합니다.
비단 이 책뿐만 아니라 현업에서도 많이 통용되는 규칙이니 소개해 드리려고 합니다.

여기서 보이는 소스의 “if (a = b) {“ 와 같이 {를 내리지 않고 쓰는 스타일을 Egyptian Brackets이라고 불립니다. K&R 스타일인데, 제가 거쳐 왔던 회사가 모두 저런 스타일로 코드를 작성해서 제가 익숙하다 보니 그렇게 작성하였습니다.

 (책 분량 조절도 해야 하고요)

또 많이들 클래스 맴버 변수에 m_ 나, 포인터라는걸 알리는 p 같은 헝가리안 표기법을 사용하시겠지만, 요즘 IDE에서는 변수의 타입을 바로 다른 창이나 툴 팁에 띄울 수 있고, 이러한 표기법은 가끔 코드 리더빌리티(code readability)를 떨어트릴 수 있어서 사용하지 않는 곳도 많습니다.

아래는 이와 관련 토론한 게시글인데, 한 번은 읽어 보시길 추천합니다.
 https://kldp.org/node/46915

표기법은 다른 책들에서 자주 나오는 헝가리안 표기법(pValue)이 대세를 이루기도 하지만,
여기서는 카멜 표기법(valuePointer), 생성된 코드는 스네이크 표기법(value_pointer)을 사용합니다.
익숙하지 않을 것 같다고 생각은 듭니다만, 회사에서는 회사 코드 스타일로 소스를 작성해야 다른 작업 하는 사람들도 헷갈리지 않으므로 미리 연습한다고 생각하시면 좋을 것 같습니다.

회사에서 이렇게 규칙을 정하는 이유는 코드 유지 보수 차원상 팀의 개개인의 제각각의 스타일을 통일하여 비상시 누구라도 다른 사람 feedback을 해주는 시스템을 갖추기 위함입니다.
뉴스에서 표준어를 사용하는 것과 같은 거로 생각해 주시면 좋을 것 같습니다.

입문 책이므로  접근성도 좋고, 비교적 쉽게 개발할 수 있는 Windows에서 개발을 진행하도록 하겠습니다.

윈도우 개발 툴이라면, 역시 Visual Studio를 빼놓을 수 없겠네요.
게다가 최근에는 거의 무료로 풀어버린 Visual Studio Community 2013이 있으니 이 버젼으로 진행하도록 하겠습니다.
물론 이클립스나 다른 툴을 사용해도 컴파일만 되면 큰 문제는 없습니다.

저는 서브 에디터기로 노트패드 플러스를 사용하고 있습니다.

다음은 소스 관리 툴입니다.

SVN은 범용적인 소스 관리 툴로서 이전 작업과 현재 작업 비교등
프로그램 작성에 있어서 undo를 마음껏 해줄 수 있는 툴 입니다.

저도 이 서버 프로그램 작성에 svn을 이용했으며, 최종 리비젼은 130 으로 나오네요. 

다음은 UML툴인 StarUML입니다.
서버 프로그램처럼 복잡한 시스템들이 얽힌 프로그램은 구조를 제대로 작성해 놔야
나중에 더 복잡한 처리, 응용등이 안정성있게 동작하게 됩니다.

이를 시각적으로 구현 시켜주는 툴로서 StarUML을 사용합니다.

마지막으로 원노트 입니다.

프로그램이 크다 보니까 이것 저것 작업 공유를 남길 필요가 있습니다.
DB서버 IP는 무엇이다, 암호는 무엇이다, 어떤 작업을 할때 주의점등...

이런 여러 자료를 문서/캡쳐로 공유 가능하게 해주는 솔루션을 많이 사용하는데,

가정에서는 흔히 접할 수 있는것이 원노트정도로 보시면 좋을 것 같네요.