오늘 기술지원 이슈를 하나 받았습니다.

매우 이상한 이슈 이던군요... 어떤 문제인고 하니..

vs2005 Release 빌드 Server에서 Client가 접속이 끊겼을때의 이벤트가 나오지 않는다는 이슈 였습니다.

저는 생각하기를...'아닌데..테스트를 많이 해봤는데..'라고 생각하며 다시 테스트를 했습니다.

그런데, 아니나 다를까 이벤트가 잘오더군요...쩝..

그래서 엔진 패키징 하는 컴퓨터에 접근하여 문제가 생기는 버젼을 빌드하여 테스트 해봤더니...

'헉...이벤트 타이머가 작동을 안하자나....jQuery1520967723500682041_1326957222827?'

이벤트 타이머가 작동을 안하면...모든 이벤트와 처리등이 죽는등의 크리티컬한 문제 였습니다.

그래서 이벤트를 추적...1개 1개...용의자를 좁혀가던중...

'double연산이 이상하게 나오네??? NaN??..헐 나눗셈에서 분모에 0이 들어갔나 보군..'

이라고 생각을...

했는데!! 글쎄 모든 값은 정상인데..꼭 그부분에서만 연산 결과 값이 이상하게 나오던군요..

'이건 뭥미...?^^;'하고.. asm을 보니 캐스팅부분이 이상하게 나오던 부분이 있더군요...

결국 컴파일러 버그...^^; '근데 내컴에선 왜 잘되지? 로직은 똑같은데...'라는 생각이 번쩍!!

하고 드는 순간...버젼을 체크해보니...아니나 다를까 service pack1이 안깔려 있더군요...ㅜ,.ㅜ

결론은 닥.치.고. 서.비.스.팩.깔.아!!!

지난 3월 벤처기업인증에 이어 5월7일자로 기술연구소 인정을 받았습니다.  ^^;

ProudNet을 사용하거나 하실 프로젝트에 좀 더 보탬이 되는 연구개발 열심히 하겠습니다.  축하해주세요~

저번 냥이 술자리 껀의 뒷 이야기를 살살 풀어보려 한다.

바빠서 너무 오랜만에 글을 올려 본다..

먼저 엔진과 컨텐츠의 차이에 대하여 이야기 해보고 싶다.

아는 사람들은 왜 저런 뻔한 소리를 하고 그러냐고 하겠지만 의외로 모르는 사람이 더 많다.

하물며 개발자 중에도 프로그래머 아니면 모르는 사람이 있는데 일반인이야 오죽할까..

엔진하면 무엇이 떠오를까? Engine!! (기관!!)

흔히 자동차 엔진을 많이 생각하리라 생각된다.

냥이 로봇에도 엔진…?!

기계들마다 엔진이 다 들어가는데 프로그램 소스에도 엔진이 들어갈 수 있지 않을까? 꼭 물리적 개념으로 생각하지 말아보자.

크라이 엔진, 언리얼 엔진 이라고 하면 일반 유저도 다 안다.

3D 엔진!

모르면 간첩내지 게임을 하지 않는 사람, 나이 많으신 분, 너무 어린애, 매우 바쁜 삶으로 잠깐씩만 게임으로 시간 때우는 사람......

음.. 은근히 늘어놓으려니 많다. 괜한 짓 했다..

이제 이야기를 조금 확장해 보자.

3D에는 엔진이 있다. 흔히 거 그래픽 구리네 돈 좀 더 쓰지 하는 말을 하곤 한다.

그렇다면 서버 발로 만들었냐 하는 말들이 게시판에 오르는 건 어떻게 생각하는 가? (개발자는 정말로 손으로 만들었다며 아니라고 운다.. ㅠ_ㅜ)

응?

유저가 보지 못하는 서버와 통신을 위한 엔진 있을 것 같아지지 않는가? 그냥 단순히 Send Recv 이걸로만 게임 다 만들 수 있을까?

서버와 클라이언트 간에 많은 데이터가 오가면서 많은 연산이 필요하다. 클라이언트는 결과값을 보여주는 역할이며, 모든 중요연산은 서버가 다 한다.

그렇다면 모든 것은 통신 데이터의 신뢰성과 안전성 있는 하위 개발의 바탕부터 깔려주어야 작업이 가능해 진다는 말이 된다.

물론 3D엔진과 서버엔진이 빵빵 하다고 다는 아니다. 어떻게 쓰느냐가 또한 아주 중요한 문제가 되며 잘 못쓰게 되면 발제(수제의 반대) 서버가 나오기도 한다.

보검을 들고 주먹과 동등하면 암울..

그런고로 3D엔진과 통신엔진이 존재하고 이것을 이용하여 기능들을 구현하는 부분을 컨텐츠라 한다.

‘엔진이 왜 필요하고 중요할까’ 하고 심도 있게 생각해 본 사람이 과연 얼마나 될까?

(개발자 뺴고..-_-;;)

알다시피 유명하고 비싼 엔진 쓰면, 거시기한 말로 "퀄리티 쩐다."

그럼 안쓰면 안쩌나?

꼭 그렇지 않다!!

프로그래머들이란 자신의 기술력에 자부심을 갖고 있거나 갖을 만큼 실력을 키우고 싶어 하는 존재 들이다. 반대로 개발능력이 되는 사람도 상당히 있다는 소리.

실력 되면 만들 수 있다. 하지만 그래도 사 쓴다.

왤까?!?!

사장님 왈

"저도 게임 만들 때 엔진 직접 다 만들었죠. 속된 말로 ‘씩X 엔진 만들다 토나오겠네’가 입에서 튀어나오죠 그게 엔진 만들 줄 알아도 사는 이유 중 하나랍니다..."

워워 릴렉스..

엔진 무엇이 편해서 쓰는 걸까?

만들 때에는 신경 쓸 것이 별의 별게 많다. 쓰기도 편해야 한다.

엔진 하나 만드는데 얼마의 시간과 사람이 필요할까?

1. 최소 5년 이상의 경력자 1~2명 이상 필요.

2. 그 프로그래머가 전에 다니던 회사서 만든 엔진은 그 회사의 재산이다.

3. 개발은 1년은 잡아야 안전성이 높다.

4. 테스트 머신 100마리 200마리 늘려가며 테스트하다 뭔가 이상하면 다시 문제 해결하고 다시 테스트.

5. 아니면 그냥 그 연봉 값과 시간, 개발진들의 스트레스로 엔진을 산다..(잘 만들어진 엔진의 사용은 시간과 돈에 있어 상당히 큰 절약의 수단이 된다.)

그리고 나서 만약 엔진 쪽에 에러가 났다. 시급히 잡아야 한다. 근데 다른 일도 너무 많다.

1. 직접 만들고 죽자 살자 미친 듯이 고치자. 까짓 거 없는 시간은 한 달이고 일년이고 잠 안자고 개인시간 다 버리면 되지

   뭐. 그래도 안되면 사람도 더 써!!

2. 걍 사쓰고 에러 났다고 빨랑 고치라고 통보만 보내면 빠른 시일 내에 알아서 해준다. 추가 인력도 안 들고 내 일에만 집

   중하면 된다. (스트레스 감소 최대화)

안전성에 대한 증명사례가 필요하다

1.     미친 듯이 테스트 머신 돌리고 사람 붙여봐서 안 걸려도 만 단위 이상 붙으면 무슨 일이 생길지 아무도 모름..

2.     그냥 이미 다른 게임에서 성공사례가 있는 엔진을 사자..

속도가 느리다. 엔진에 대한 업그레이드가 필요하다.

1.     할게 많고 미친 듯이 바쁘다.. 시간을 쪼개고 쪼개서 계획을 세우자..

2.     엔진이나 사 쓰고 통보 한번 보내자 어디가 느리면 테스트 툴로 테스트해 보고 요청 보내면 끝.

더러는 어떤 기능을 구현하려고 한다.

1.     죽어라 개발하고 2~3명씩 붙여 유지 관리도 해주어야 할 때가 있다.

2.     그냥 엔진에 붙은 기능 쓰자.

네트워크의 경우 플레이어가 2배로 늘면 버그는 제곱으로 는다.. ㅠ_ㅜ 

      1. 내부 테스트에서 잘돌아간다고 그게 정말 버그가 없는 것일까?

      2. 내부 테스트로 모든 확인이 가능하면 '발로 만든' 꼬리표는 세상에 나오지도 않았을 것이다..

실수란 아무리 뛰어난 실력자라 할지라도 피할 수 없다. 사람이기에!!!

결국 가장 중요한 것은 개발된 후, 버그가 발견되고 수정되며 흘러온 많은 시간과, 실질 적용된 사례이다.

가만있으면 알아서 어떤 기능이 추가 되어져 올 때가 있다. 예를 들면 다른 게임회사에서 들어가는 어떤 기능 추가 요청에 대한 트렌드가 될 수도 있다. 그냥 그런 기능을 연결만하면 유저는 ‘오 많이 발전했다’ 하고 놀랜다..

삽질은 많이 해봐야 삽질일 뿐…

어떤 에러의 경우 1프로 이하의 확률로 일어나며,

데이터 베이스, 서버엔진, 서버 컨텐츠, 클라이언트 컨텐츠, 글라이언트 엔진

중에 어디가 문제인지 참 애매할 때가 있다. 이럴 때 정신적 고통을 줄이고 시간을 절약하기 위해서도 엔진은 절대적으로 견고해야만 한다.

특히 한달 두달 날수만 늘고 희박한 확률로 버그가 튀어나와서 감도 안 잡히는 경우도 꾀나 종종 생기게 되는데 이런 피마르는 상황을 줄이기 위해서도 엔진의 안정성은 절대적이지 않을 수 없다.

그리고 이중에 저 Server Engine을 개발 하는 회사가 우리 넷텐션인 것이다.

글좀 줄여바.. 너무 길자나..

온라인 게임 개발에서 로그인 과정은 만들기가 까다롭고 짜증나는 부분 중 하나입니다. 로그온 과정까지 만들기 위해 넘어야 할 산들은 많습니다. 오죽하면게임 서버 개발에서 로그인 과정까지 완성되면 서버 개발의 반은 끝났다고 하겠습니까?

완성되고 나서도 로그온 부분에서 말썽을 일으키기 십상입니다. 로그인 과정 중 오류, 데이터베이스 랙, 그리고 서비스 오픈하면 한차례 겪는 해킹, 아이템 복제 등 후폭풍이 기다립니다.

프라우드넷(ProudNet)은 로그인 과정을 쉽고 안전하게 만들 수 있는 여러가지 장치들을 제공합니다. 그중 보안 부분에 대해서 소개합니다.

프라우드넷은 강력한 보안 통신 기능을 제공하고 있습니다. 가령, 로그인 관련 메시지를 높은 암호화를 수행하게 합니다.

먼저, 암호화라는 것이 무엇인지 알아봅시다.
어떤 메시지가 다른 컴퓨터로 전달될 때 제3자가 내용을 해독하거나 변조할 수 있으면 해킹을 당하기 쉽습니다. 예를 들어 입력한 아이디,비밀번호가 제3자에 의해 해독/변조가 될 수 있으면, 어느날 게임에 접속했더니 자기 캐릭터가 알몸이 되어 있겠죠.

그래서 메시지를 암호화하려면 암호화,해독(복호화)를 하는 알고리즘(공식)이 각각 있어야 합니다. 하지만 알고리즘이 공개되면 위험할 수 있겠죠? 그래서 뻔히 아는 알고리즘이 눈 앞에 있어도 암호화된 메시지를 풀지 못하게 하는 수단, 즉 열쇠(키)가 있어야 합니다. 현대 전산학에서 암호화 알고리즘은 키 기반 암호화가 통용되고 있습니다. 암호키의 길이는 1비트에서 수백 비트까지 다양합니다.

해커가 암호화된 메시지를 캐내서 얻어냈다고 가정하겠습니다. 해커가 그 메시지의 내용을 알아내려면 메시지를 해독할 키를 알아야 합니다. 이미 알고리즘은 얻었다고 가정합시다. 어떤 키를 넣어봐야 할지 시도해볼 것입니다. 암호키를 일일히 대보는 해커가 만들었다고 가정해도 어마어마한 시간이 소요됩니다. 

키, 즉 암호키는 크게 비대칭키와 대칭키로 구별됩니다. 비대칭키는 한 쌍의 열쇠가 있어서, 한 개의 열쇠로 암호화하면 나머지 한 개의 열쇠가 없으면 해독할 수 없습니다. 대칭키는 암호화할 때 쓴 키와 해독할 수 있는 키가 서로 같음을 의미합니다. 이러한 성질을 활용해서, 컴퓨터 네트워크에서는 암호화된 메시지를 전송하기 위해 대칭키와 비대칭키를 혼용하기도 합니다.

두 호스트 A,B가 있다고 가정하죠. A가 B에게 안전하게 암호화된 메시지를 전달하고자 합니다. A는 먼저 비대칭키 한쌍을 만듭니다. 그리고 하나는 자기가 갖고 있고 나머지를 B에게 전송합니다. 자기가 갖고 있는 것을 개인키(Private Key), B에게 전송한 키를 공개키(Public Key)라고 부릅니다.

이때 해커는 가뿐하게 공개키를 얻어버렸다고 가정하겠습니다.

B는 대칭키(Session Key)를 만들고 갖고 있습니다. A로부터 공개키가 도착했습니다. 이제 그것을 갖고 있는 대칭키로 암호화합니다. 그리고 암호화한 대칭키를 A에게 보내줍니다. 해커는 역시 그것도 얻어버렸습니다.

A는 받은 대칭키를 개인키로 복호화합니다. 그리고 B가 만든 대칭키를 공유합니다. 해커는 공개키와 암호화된 대칭키를 갖고 있지만 정작 개인키가 없어서 대칭키 내용을 알 수 없습니다.

이제 A는 암호화할 메시지 본문을 B로부터 받은 대칭키로 암호화 후 B에게 전송합니다. 해커는 이것도 갈무리했습니다.

B는 암호화된 본문을 가지고 있는 대칭키로 복호화해서 잘 씁니다. 한편, 해커는 아직도 대칭키를 얻지 못했기 때문에 해킹해서 갈무리한 메시지를 얻어내지 못합니다.

에라 모르겠다, 해커는 B에게 메시지 내용을 이것저것 훼손해서 보내봅니다. B는 받아서 복호화해봤더니 복호화가 되지 않습니다. 뭐, 그냥 버립니다.

프라우드넷은 이러한 암호화 방식을 내장하고 있습니다. RSA는 매우 강력합니다. 하지만 계산량이 막대해서 모든 메시지를 암호화하기에는 벅찹니다. 그래서 대칭키 알고리즘과 혼용합니다.

프라우드넷의 이러한 기능을 쓰기 위해서 사용자(게임 프로그래머)는 딱 하나만 하면 됩니다. 프라우드넷에서 메시지 형식을 정의할 때 “이건 암호화할거임~”만 한마디 적어주면 끝입니다. 위 키 주고받기 과정은 사용자는 신경쓰지 않아도 됩니다. 

프라우드넷은 클라이언트와 서버간 통신 뿐만 아니라 P2P로 통신할 때도 지금까지 설명한 방식의 암호화 기능을 제공합니다. P2P간 통신도 제3자가 해독/변조하지 못하게요.

여기서 잠깐! 프라우드넷이 어떻게 암호화를 하는지 대놓고 공개해도 괜찮냐고요? 암호화 기법은 알고리즘을 공개해도 뚫지 못하는 데 그 가치가 있습니다. 이렇게 대놓고 공개해도 안뚫리니까 공개하는거죠. ^^;;;

프라우드넷이 제공하는 기능은 많습니다. 암호화 기능은 작은 부분에 불과합니다. 하지만 지금까지 홍보가 부족했던 것 같습니다.

프라우드넷 엔진 코어 소스 량입니다. 툴 소스, 테스트 프로그램 소스, 샘플 소스 등은 모두 제외한 분량입니다.

Classes:                        391
Files:                          303
Functions:                     3968
Lines:                        83747
Lines Blank:                  13710
Lines Code:                   53856
Lines Comment:                13472
Lines Inactive:                1083
Declarative Statements:       14379
Executable Statements:        20939
Ratio Comment/Code:            0.25

도움말이 상당히 상세합니다. 그러다보니 주석량 비율이 높습니다.
메시지 포맷 하나 하나를 클래스로 정의하지도 않았는데도 클래스가 무려 391개! 
소스도 무려 8만라인! 뭘 하길래 이렇게 양이 많지? 라고 생각하실지도 모르겠지만, 프라우드넷은40개가 넘는 고객사가 게임서버개발에 쓰면서 제안된 수많은 기능들의 집합체이니만큼 이정도 양은 충분히 나온다고 봅니다. 당연히 중복 코딩 같은건 없죠. 엔진 최적화와 유지보수가 얼마나 중요한데, 설마요 ^^

넷텐션의 배현직님의 블로그 글의 일부 발췌

Feature creep이라는 말이 있습니다. 게임 개발 뿐만 아니라 많은 소프트웨어 개발 프로젝트에서 발견할 수 있는 것들입니다.

뒷북이지만 올립니다.

Korea Game Conference (KGC)에 저도 강연을 합니다. 

KGC09 스폰싱 후기(첫날) 

http://blog.naver.com/imays/150071351767

http://blog.naver.com/imays/150071687630

KGC09 스폰싱 후기(마지막날) 

ProudNet 빌드중 찍은 샷. Incredibuild가 쓸만한지 궁금하신 분들에게 참고가 될 것입니다.

하얀 공간은 암달의 저주입니다. 

자기가 쓴 책의 한글판 왔다고 자랑질하시는 사장님

http://blog.naver.com/imays/150084802186

이런거 쓰지좀 마시고, 프라우드넷 영문판은 언제 나오시나욤? (직원이 사장한테 일 시키는 이상한 회사)

사족. 사장이 직원인 척 자작극 티 너무 난다

http://blog.naver.com/PostView.nhn?blogId=funnygo&logNo=20048803499&categoryNo=0&parentCategoryNo=1&viewDate=¤tPage=5&postListTopCurrentPage=1&from=search

퍼온글 + 지식인...

 혓바늘 하고 구내염은

인체의 방어기재가 무너짐으로 해서 면역체게 교란으로 오는 질병이라고 합니다.

주고 원인은 피로와 스트레스. + 구강내 세균

 여기 직빵은 뭐?

바로 알보칠.

'알보칠' 은 일종의 약어이며,

풀어서 작성하면 다음과 같습니다.

알 아 보 고 칠 하 세 요

그리고 이 약의 태생은 '독일' 입니다.

'일주일 아플껄 한순간에 몰아서 아픈뒤 잊는다.' 랄까요?

-----------------------------------------------------------------------------------------------------------------------------

알보칠 사용하려는데 두렵습니다.-내공 50- 

virusdogs

2007.12.30 07:11