기억창고

http://upaper.net/rosagigantea/1042923

국내 전자책 판매 및 yes24등 출판도 대행해주고 있는것 같더군요.

아직 ECN이 발급이 안되서 일반 인터넷 서점에서 구입이 안되지만, 조만간 될 것으로 보입니다.

지금 만들어 놓은 책 원고는 A4로 작성 했지만, 막상 가제본 만들때 보니

A4는 좀 부담스러운 크기더군요.

그래서 그것보다 약간 작은 4x8 배판으로 설정 했습니다.

이미 원고 작성된 상태에서 4x8 (188x254) 사이즈를 만들기는 어려워서 pdf 축소 인쇄를 사용해서 등록했습니다.

기존 크기에서 90%로 인쇄되었는데, 보는데 문제는 없어서 다행이란 생각이 들었습니다.

문제는 맞춤법인데, 개인 출판이다 보니, 전문적으로 교정해 주는 절차가 없어서,

직업 원고를 웹사이트의 맞춤법 교정 사이트로 2번씩 돌려보고, 그 원고를 여러번 읽었지만, 볼 때마다 오타가 생기네요. 

맞춤법으로 보기 언짢으신 분들께 미리 사과 드립니다.

또한 제가 현재 회사일 대문에, 책에 대한 질문을 받아드리기 어려운 점도 양해 부탁 드립니다.

<도착한 교보문고 퍼플 pod 책>

안의 내용, 인쇄 상태가 양호 합니다

소스 코드는 하이라이트를 했었지만, 책값 절감을 위해 흑백 인쇄를 하였습니다.

왼쪽이 교보문고 pod (4x8배판 인쇄)와 오른쪽 가제본으로 인쇄 업소에서 맡긴 A4판 입니다.

온라인 게임과 콘솔 / PC게임 이 두 가지 차이점은 무엇일까요?
당연한 이야기지만, 온라인 게임은 네트워크망을 사용해서 불특정 다수와 관계를 맺어가면서 즐기는 게임입니다.

그에 반해 콘솔 PC게임은 자신 홀로 게임 세계에 들어가 즐기는 게임이죠.

게임을 하다 보면, 이것저것 막힐 때가 있을 겁니다. PC 게임 같은 경우 데이터 파일을 헥사 파일로 열어서 특정 수치를 변조하여 초반부터 최고 레벨로 플레이를 하는 행위가 가능합니다.

하지만 온라인 게임의 경우는 조금 문제가 있습니다.
내 행동이 다른 이들에게 영향을 주는 게임이다 보니, 내가 게임이 지루하다고 내 캐릭터 레벨을 10에서 100으로 올려버리면, 다른 유저들이 힘들게 올린 100레벨은 무의미해지죠 박탈감이 심해져서 열심히 일한 개미(열정적인 유저들을) 떠나게 합니다.
그래서, 이런 치팅을 하지 못하도록 막아야 할 필요성이 생깁니다. 어떤 처리를 넣으면 좋을까요?

역사적으로 봤을 때, 인류는 이런 고민을 상당히 오래전부터 하였습니다.
오랜 예부터 특히 군대에서 적군이 눈치채지 않고 인접 아군에게 작전 지시를 내리는데,
전령이 적군에게 사로잡힐 경우를 대비해서 사용했던 암호화가 바로 그것입니다.

며칠 몇 시에 어느 곳으로 이동해서 어디를 공략해야 한다는 전술 명령을 산 건너 있는 부대장에게 전달해야 하는데,
이 작전 문서를 평문으로 보내면 어떻게 될까요?
전령병이 산을 넘다가 적에게 포로로 잡히면, 이 작전이 무산되거나, 혹은 명령서를 바꿔서 보내 작전이 원하는 대로 움직이지 않을 것이고 결국 전쟁에서 패배라고 말 것입니다.
그래서 옛날부터 이런 작전 문서의 문자를 암호화하여 난센스 문장을 써서 전달하는 시저 암호나 에니그마 같은 것이 나왔습니다.

서버 프로그램도 같습니다. 사실 클라이언트 프로그램이 유저에게 제공되는 순간, 이 클라이언트 프로그램은 소스까지 모두 제공한 거로 보셔야 합니다.

(자세한 건 리버싱 엔지니어링을 공부해 보세요) 그러므로 서버에 접속하는 프로그램이 반드시 제공한 클라이언트일 확신이 없으며, 이 클라이언트가 가짜라는 가정하여야 하고, 패킷은 난독화(Obfuscation)시켜서 송수신해야 합니다.

그러면, 키를 넣어 변조시킨 뒤, 다시 같은 키를 넣어 원래대로 데이터를 만드는 방법을 어떻게 하면 좋을까요?
일반적으로 자주 사용되는 방법은 XOR 연산입니다.

XOR는 배타적 연산으로 2개의 명제 중 하나만 참일 때 참을 출력하는 로직입니다.
이를 이용해서 3변수를 사용하지 않고 2변수 만으로도 swap 함수를 만들 수 있죠.
그럼 이제 특정 Key를 만들어서 패킷데이터에 XOR연산을 하면 사람이 알아보기 힘든 값이 나오겠군요.

해커들이 보고 한숨 쉴 수 있도록 작업해 봅시다.

패킷 난독화 소스를 서버 라이브러리에 추가하였습니다. 실제 구현 소스는 아래와 같습니다.

XOR 연산 킷값으로 ‘T’ 라는 단어를 주었습니다.
하지만 이 경우 해커가 key값을 0~255까지 XOR연산 테스트 하는 것만으로도 Key값이 확인 될 겁니다.

대부분 해커들은 채팅 메시지를 테스트 삼아 (‘aaaaa’입력 했을 때 패킷을 캡쳐 해서 분석) 이 XOR 키 값을 찾아갑니다.

그러므로 채팅 메시지는 별도로 암호화 처리 하는 것도 좋은 방법이라고 생각되지만,
여러 단어를 XOR값으로 테스트 하다 보면 쉽게 Key값을 알아 차리 겠군요.
좀 더 복잡하게 해서 해커를 혼란스럽게 만들어 봅시다.
...

지금까지 서버 프로그램을 만들고 서버끼리 데이터를 주고받는 것까지 테스트하였습니다.

하지만 실제 온라인 게임이라 하지는 못하죠.

온라인 게임을 만드는데 서버만으로는 만들 수 없습니다.

당연히 클라이언트 프로그램도 만들어야겠죠.

그래서 여기서는 간단한 더미 클라이언트를 만들어 보는 시간을 가지려 합니다.
여기서 더미(Dummy)는 가짜라는 말입니다.

일반적으로 온라인 게임에서는 더미 클라이언트랑 클라이언트를 따로 만들게 됩니다. 왜냐구요?

실제 서버 프로그래밍에서도 성능 개선 등을 할 때, 수백, 수천 대의 클라이언트를 접속할 방법이 없으므로, 로직이 같은 간단한 더미 클라이언트를 수백 개 띄어 서버에 접속시켜 테스트하는 방법을 주로 사용합니다.

물론 이를 완벽하게 신뢰하기에는 네트워크 특성상 불가능하니 여력이 되는 온라인 게임은 공개 테스트 서버 등에 먼저 업데이트를 해서 추가될 내용에 이상이 없는지 확인 작업을 진행합니다.

그런데 테스트를 위해서 클라이언트를 2개 만들어야 한다니, 클라이언트 프로그래머는 야근하라는 걸까요? 물론 그렇지 않습니다. 그래픽 출력 부분만 잘 만들어 위의 Log처럼 전략적으로 구동방식을 교체할 수 있도록 하면 좋은 구조겠죠.
보통 클라이언트 프로그램은 아래와 같은 큰 모듈들의 조합으로 이루어졌습니다.

그럼 이제부터 클라이언트를 만들도록 해봅시다.
테스트 용도로 만드니까 클라이언트는 C#으로 제작하려고 합니다.
MFC나 WinAPI를 사용해서 만드셔도 상관은 없지만, 제 생각으로는 이종(異種)언어들간의 패킷을 주고받게 하는 것을 만들어 보는 것도 나중에 모바일 게임 작성 등에 좀 더 공부가 될 거로 생각하기 때문에 C#을 선택했습니다.

소스를 참고하셔서 클라이언트를 C 이외의 언어, Java나 Objective-C, Swift로 만들어 보시는 것도 큰 공부가 될 것으로 생각합니다.

지금까지 게임 서버를 만들기 위한 코드를 작성해 왔습니다.

지금 완성된 모듈로도 어느 정도 게임 서버 구실이 나올 수 있을 겁니다.

그럼 실제 게임 서버는 어떤 구조로 되어 있을까요?
간략하게 로그인에 처리 및 서버 부팅 단계를 그려 보았습니다.

개인적으로 경험한 회사는 별로 없지만, 대부분의 게임 서버는 위와 같은 구조로 돌아갑니다.

처음 서버가 뜨면, 정해진 ip/port를 받아서 통신할 준비를 하며, 다른 서버군 (모니터닝 서버나, 아이템 샵 서버, 게임 월드 서버 등……)에게 자신이 실행 중이라는 사실을 알립니다.

당연히 DB 처리가 있으면, DB 연결도 해야 하겠네요,
게임 서버라면 게임 데이터를 읽어서 각각의 실행 객체를 생성하는 작업을 진행합니다.
이후, IOCP 에코 서버와 같이, 클라이언트 접속을 기다려서, 클라이언트가 붙으면 세션을 만들고, 패킷을 분석해서 적절한 처리를 해줍니다.

이제 위의 엑티비티 다이어그램을 참고로 지금까지 작성한 라이브러리를 사용해서 진짜 게임 서버 프로그램을 만들어 봅시다. 테스트로 서버프로그램 2개만 생성해 봅시다.

하나는 LoginServer이고, 다른 하나는 DB와 연결을 직접 하는 DBAgent 입니다. 
DB처리 서버를 분리 하느냐고요?
최근 추세는 DB와 연결하는 서버를 따로 두어서 DB에 데이터를 받거나 읽는 처리는 DBAgent라는 서버로 분리하는 추세입니다.

이렇게 분리하면 아래와 같은 이점이 있습니다.
1. 게임 로직과 DB 처리 로직을 분리 할 수 있습니다.

2. DB라는 것이 물리적으로 다른 서버에 구축되어 있으므로 게임 로직상 DB를 거치게 되면 DB의 응답이 올 때까지 로직이 멈추게 구현할 수 있습니다.
물론 체감이 느껴지진 않지만 이로 인해 서버 공격 (DB 처리가 많이 드는 행동을 집단으로 한다던가)가 발생 할 수 있습니다. 만약 분리를 한다면, DB 데이터 요청도 일종의 서버 패킷처리와 같이할 수 있으므로 로직 작성 시 위와 같은 비 동기화 처리가 자연히 고려되어 작성하게 됩니다.

3. DB처리만으로 보면 아주 간단한 처리이므로 만들어놓고 문제가 생기지 않는 이상 건드릴 필요 없습니다. 즉 관리 이슈가 많이 줄어듭니다.

이를 바탕으로 만들려고 하는 간이 서버 구조는 아래와 같습니다.