Untitled

안녕하세요 이경만 입니다.
휴우.. 넘 바쁘네요.
간단히 저희 게임엔진의 구성에 대해 예기를 해드리면
우선 유저나 NPC가 하는 일중에 그냥 일회성인것은
Action이라고 했고 여러과정을 거치거나 시간이 오래걸리는 일
아니면 다른 플레이어와 연관성을 가지는 일은
Plan이라고 했습니다.
그리고 Action은 Character Class의 멤버함수로 만들어 두었구
Plan은 PlanManager를 따로 두었습니다.
Plan자체는 기본형을 두어서 PlanManager에 넣었다 뺐다 할수 있는
형태로 만들었습니다.
PlanManager의 Thread는 유저의 수가 늘어나면 늘릴 수 있게 늘어날 수 있는
구조로 짜 두었고 ParseThread에서는 프로토콜 메시지를 처리하게 되죠.
물론 ParseThread도 여러개를 동시에 띄우고 있습니다.
ParseThread에서 Action을 수행하던가 아니면 Plan을 추가해주던가 하는
역할을 하죠.
현재는 맵별로 나누진 않았지만 맵별로 따로 나눠서 분산 서버 구조로 처리할 수
있도록 하는 부분을 구현할 예정입니다.
잘되어야 할텐데..
그럼..
__
이경만

서버의 프로토콜을 설계할때 하나의 아이디어중 하나가
캐싱이었습니다.
웹서버의 Last Modify time 과 같은 계념으로
클라이언트에서 어떤 자료를 가지고 해당자료의 정보를 줄때
자료의 flag값을 같이 주는 겁니다. 그리고 서버내에서 자료가 변경되었다면
해당 flag를 ++시켜주던가해서 flag값을 바꾸는것이죠.
그리고 클라이언트에선 해당하는 값을 요청하기전에 클라이언트에서
이전에 받았던 해당 자료의 flag값을 가지고 이게 바뀌었는지 한번 먼저
쿼리를 해보는것이죠. 그래서 flag가 바뀌었으면 그때 다시 해당 값을
쿼리하는 겁니다. 바뀐 flag값과 함께 말이죠.
이런식으로 많은 싸이즈를 가진 그리고 변경 주기가 짧거나 무작위적인 데이터
예를 들면 캐릭터의 외형정보같은데 쓸려고 생각을 했는데.
캐릭터의 외형정보가 50바이트를 넘지 않는다면 안쓰는것이 더 나을것이라는
결론이 나왔습니다. TCP헤더싸이즈가 28바이트라면 배보다 배꼽이 더커진 결과가
나올 수도 있다는 거죠.. -_-;
아무튼 좀 큰데이터를 받는경우 고려해볼만한 문제라고 생각 합니다.
__
이경만
데드락이란 놈을 첨으로 경험했습니다.
서버가 자꾸 엄한데서 멈추길래.
하루종일 소스를 들어다보구 프린트해서 보구
줄쳐가면서 보구 그랬습니다.
원인이 멀까..
흑흑..
결국 데드락으로 판명되었습니다.
죽음의 버그 데드락..
두개의 쓰레드를 같이 봐야지
하나씩만 따루봤더니..
당연히 이상이 없죠.
쓰레드를 쓸려면 머리도 병렬로 돌아야 한다는..
허걱..
내 시간 돌리도!!!!
그래도 가장 확실한 디버깅 방법은 printf라는.. 허걱..
하지만 좋은 경험을 했다는 걸로 위안을 .. 흑흑..
__
이경만.
데드락이었다니... 안됐습니다.
쓰레드를 많이 쓰면 항상 데드락을 신경써야겠지요.. ㅜㅜ
지금 저도 쓰레드를 한 다섯개 정도 돌릴려구 하는데..
데드락에 대한 무지막지한 두려움이... 헐..
일단 순환 기다림은 대충 없는 거 같아서 한시름
놨지만.. 어디서 걸릴지 확신할 수가 없죠.. ㅜㅜ

그럼 데드락을 어찌 해결하셨는지 기다리겠습니다..
(저 나쁜놈같죠? 네.. 맞습니다. 나쁜놈입니다... 흘..)
그럼..
버그만든게 자랑은 아니지만.-_-;
나중에 이런실수 하는 분이 없길 바라며 씁니다.
알고 나면 간단함 문제니까요.
저도 데드락을 교과서에서만 보고 첨 당해 봅니다.
우선 캐릭터가 누군가를 클릭하면 전투가 시작되고 캐릭터의 전투 쓰레드가
돌게 됩니다.
그리고 몬스터는 타겟팅 당하면 해당하는 애를 공격하겠죠? 이것도 몬스터
처리하는 쓰레드에서 처리를 해줍니다.
근데 몬스터는 자신이 타겟팅 당하면 타겟한 놈을 쫏아가서 때립니다.
이 두 쓰레드간의 문제였는데.
우선 캐릭터쪽의 쓰레드는 캐릭터 정보를 보기위해 락을 걸고
중간에 타겟 정보를 보기 위해 또 락을 겁니다.
몬스터는 자신의 위치정보등을 수정하기 위해 락을 걸고
타겟한 캐릭의 위치정보등을 보기 위해 캐릭터를 락 합니다.
이제 두마리만 있다고 가정했을때.
보져..
편의상 캐릭터를 A 몬스터를 B라고 한다면
전투 쓰레드 : A를 락 -> 처리 -> 타겟정보를 참고하기위해 B를 락
몬스터 쓰레드 : B를 락 -> 처리 -> 위치정보를 보기위해 A를 락
이렇게 되면 전투 쓰레드에선 A를 락 건 상태에서 B를 락킹하기 위해
기다리고 있고 몬스터 쓰레드에선 B를 락건상태에서 A를 락킹하기 위해
기다리고 있는 것이죠.. 이게 바로 데드락입니다. -_-;
이게 동시에 처리되면 어느순간에 두 쓰레드가 멈춰 버리고 해당 오브젝트를
참조하는 모든 쓰레드들은 서버립니다.
해결 방법은 락을 건 상태에서 또다시 락을 거는 일이 없으면 됩니다.
즉 전투쓰레드를 A를 락 -> 처리 -> A를 언락-> B를 락 -> 필요 정보를 봄->B를
언락 -> A를 다시 락
몬스터 쓰레드도 마찬가지입니다. -_-;
흑흑..
__
음냐.. 경만님 해결하셨나보군요.

일단 데드락의 필요조건은 4가지입니다..

첫번째루, 상호배제... 즉, 라킹이 되는것이고..
두번째가 비선점.. 선점을 허락하지 않는다..
세번째가 잡고 기다림... 리소스를 잡고 놓지 않는거죠.
네번째가 순환기다림입니다.. 두개 이상의 쓰레드가
서로 하나씩 잡고 다른 리소스를 원하는 것이죠.

제가 보기엔 이 중에서ㅗ 순환기다림을 막는 것이 가장 쉬운
방법이라고 생각됩니다.
다들 그렇게 아시겠죠?

따라서, 라킹을 한 후 가능하면 바로 락을 풀어주고..
또 필요하다ㄱ면 다시 락을 걸어주는 것이죠.

일단.. 이렇게 하곤 있는데..
어디서 걸릴지는 테스르를 해봐야... 쩝..

서버 프로그래머의 비애라고나 할까여? 흘.
밑에 글내용중 해당정보를 볼때
락을 건다고 하는데/
그건 어플리케이션 수준에서 락을 건다는 의미인가요.
아님 시스템자체에서 락을 거는건가요..
다시말해 프로그래머가 락을 건애기를 하는건가요
아님 시스템이 리소스를 걸면 스스로 락을 거는건지...
저 락이 제가 아는 락인지 몰라도 아마 쓰레드에서 쓰는거면 mutex 로 락거는거
같은데 음.

서로 다른 쓰레드에서 데이터를 보호해야 할 필요가 있을 때 씁니다.

음 프로그램은 전체적으로 볼 때 읽기/쓰기로 이루어져 있다고 볼 수 있는데,
(제 생각 입니다. -_-) 쓰기에 영향을 받는 곳이고 또한 여러 쓰레드에서 공
유될 부분이라면 mutex 가 필요합니다.

예를 들어 전역변수가 하나 있다하고 이 전역변수는 읽기/쓰기 둘다 하는
변수일때, 쓰레드 세개를 돌려 두개는 쓰기를 담당하고 하나는 읽기를 한다
가정하면, 쓰는 도중 읽는 쓰레드가 읽어도 웃길 것이고, 두 쓰레드가 함께
쓰려해도 웃길 겁니다. 그래서 우리의 호프이자 괴수 mutex 가 있습니다.

mutex 를 하나 두고 이 mutex 를 lock 하면 이미 lock 이 되지 않았다면,
다음 코드로 넘어가고 이미 락이 되어 있다면 락이 풀릴 때까지 프로세스가
멈추어 있게 됩니다. 이경만님이 경험하신 데드락은 추측하건데,
thread1 이 blah_mutex 에 락을 건다음 thread1 에서 blah_mutex 를 언락하기
전에 다시 blah_mutex 에 락을 거신듯 합니다. 이게 데드락입니다.

말씀드린대로 mutex 가 락이 되어 있다면, 다시 lock 을 할때는 해당 mutex가
unlock 이 되기 전까지는 프로세스가 멈추어 있기 땜시롱 동일 쓰레드에서 락을
두번하면 데드락이 되는 것이지요. 아니면 아얘 mutex 를 언락 하는 루틴을
건너 뛴다거나 (저의 경우 언락 안하고 return 해서 실수하는 경우가 많습니다.
그래서 goto 를 즐겨쓰기도.. -_-), 아얘 업다거나 하면 데드락이 되겠지요.

구본향님이 질문하신 시스템 락이냐, 어플리캐이션 락이냐 하는 것에는 흐음.
posix thread(pthread)의 경우 user level mutex 를 구현한 것으로 알고 있습
니다. 윈도우의 경우에는 잘 모르겠습니다. T_T, 하지만 마치 시스템 락인
것 처럼 돌아간다고 느끼긴 합니다. 어쨋든 모든 프로그래머가 자체 mutex
를 구현 하는 것은 이래저래 정력낭비라서, 있는 mutex 를 쓰는게 낫겠죠.

// 아래는 posix thread 용 예제 소스 입니다. thread-safe 한 global_buffer
// 만들기 인데.. -_- 목적이 없는 코드군요..
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_t thread1, thread2;

char global_buffer[5];

void *write(void *arg)
{
while (1)
{
// 락을 건다
pthread_mutex_lock(&mutex);

// global_buffer 를 맘 놓고 괴롭혀준다. -_-;
global_buffer[0] = 'h';
global_buffer[1] = 'a';
global_buffer[2] = 'h';
global_buffer[3] = 'a';
global_buffer[4] = '\0';

// 락을 푼다
pthread_mutex_unlock(&mutex);
}
}

int main(int argc, char **argv)
{
// 두개의 쓰기 쓰레드 생성
pthread_create(&thread1, NULL, write, NULL);
pthread_create(&thread2, NULL, write, NULL);

// 두개 쓰레드가 terminate 할 때 까정 기둘린다.
pthread_join(thread1, NULL);
pthread_join(thread2, NULL);

return 1;
}

음.. 쓰레드만 공유하는 것이라면 크리티컬섹션을 쓰는 것이
가장 효율적입니다. 제일 간단한 놈이거든요.

이 쓰레드니 락이니 데드락이니 모두 os 에서 나온것인데..
쓰레드를 돌리다보니.. 이런 저런 문제가 많이 생기네요.
테스터님이 쓰레드를 안쓰신다구 하셨는데.. ^^;
어떤 면에서는 쓰레드가 더 직관적이고 편하더군요.
그래서 쓰레드를 많이 쓰는 편입니다... 휴~
하여간 쓰레드 사용시 데드락하고 몇가지만 생각하면..
상당히 유용합니다...

혹시... reader-writer 구현해 놓으신분 있으신가요?
이 놈은 쓰면 쓰레드의 성능을 최대화할 수 있는데..
구현하자니.. 좀 시간이 걸리고 신경써야하니..
혹시 구현하신분이 공개하신다면 감사히 사용할
용의가 있는데... ^^
후훗.. 그럼~
pthread 에서는 pthread_mutex_lock() 콜과 pthread_mutex_unlock() 콜로
뮤텍스를 다루는데, 다음과 같은 부분이 있군요. (얼마나 신뢰성 있는가는
모르겠지만)

The pthread_mutex_lock function returns the following error code on erro
r
:

EINVAL the mutex has not been properly initialized.

EDEADLK
the mutex is already locked by the calling thread (``error

checking'' mutexes only).
rror:

EBUSY the mutex could not be acquired because it was currently l
o
cked.

EINVAL the mutex has not been properly initialized.

The pthread_mutex_unlock function returns the following error code on er
r
or:

EINVAL the mutex has not been properly initialized.

EPERM the calling thread does not own the mutex (``error checkin
───────────────────────────────────────
The pthread_mutex_destroy function returns the following error code on e
r
ror:

EBUSY the mutex is currently locked.

바로 pthread_mutx_lock 의 리턴 값인데요, EDEADLK 이라는 리턴 값이
있군요.

-비엽
이건 제가 군대 다녀오니 만들어져 있더군요. (4주훈련)
하이텔 모동호회 시삽이자 제 후배이고 아타나시아 네트웍 엔진 담당 홍기군이
만들어 놓은건데.. (쫌있음 시삽의 굴레에서 해방될지도 모를..^^;)
Lock을 할 자료들을 Locking해주고 Unlock해주는 Manager입니다.
뭐 옜말에 이런말이 있지 않습니까?
프로그램에서 입구와 출구는 좁게 만들라는.. ^^;
한군데서 관리하는 것이죠.
사실은 Lock쪽에 버그가 많았는데 Lock해야하는데 안해준 부분도 있고
해서리 Mutex을 관리하는 Class를 만든거죠.
여기에 디버그시 로그를 남기게 해서 대략 어디에서 죽었는지도 체크 가능합니다.
Lock unlock은 거의 대부분의 소스에서 다 쓰기 때문에
디버그시 유용하죠.
물론 하룻밤만 돌리면 로그파일이 기가 단위로 남지만요 흑..
그냥 내부에 mutex를 Laping하고 또 몇개씩 묵어서 관리하는 기능을 가진
Class입니다.
경만님 답변 감사드립니다.

모 동호회 시삽이신 홍기님은 아마도...
네트워크 동호회의 이홍기(청아사랑)님인거 같군요..
무섭다... 하이텔의 좁음이... ㅠㅜ
그런데 홍기님은 게제동 활동은 안하시나 보군요..^^;;

하여간, 잡담은 그만하고...
무려 기가 단위의 로그라.. 장난이 아니군요..
저의 경우는 뮤텍스를 안쓰고 크리티컬섹션을 주로 이용하는데..
천성이 게으른 저한테는 따로 locking manager를 구현할
생각이 안들듯 합니다.. 푸힛..
하부 구조부터 안전하게 크리티컬섹션을 랩핑하는 방법으로
그냥 하고 있는데.. 별 문제가 없을 것 같은데요..
물론, 하면야 좋겠지만.... 상황이 안되고.. 쯔업..
좋은 거는 많이 듣고 배우는데.. 실제로 할 수 있는 것은
많지 않은가 봅니다.. 여러가지로 어려움이 많군요.

그럼...

- DeepDark
로그는 유저로그가 아니라..
그냥 디버깅 코드가 나열된 부분입니다.
그래서 디버깅 버전으로 돌릴때만 남게되지요 -_-;
혹시나 오해가 있으신분이 있을까봐..
유저로그는 디비에 남겨서 백업하죠.
그럼.
__
이경만
헉,,저의 무지였군요..(아직까지 디버깅로그가

기가까지 갈정도의 게임은 못만들어봐서용 ^^;)

근데, 다들 만드시면서 디버깅 정보를 어떤식으로 담는지 궁금해졌네요??

저는 가장 기본적인 방법인 텍스트로다가 줄줄줄줄 쓰곤했는데,
동시사용자가 좀 많아지면,, 별로 효율적이지 않더군요...

다른분들은 어찌 하시는지 궁금합니다.
특별히 형식은 없지만 __FILE__하고 __LINE__로 파일명과 라인수를
넣고 필요한 인자를 프린트 하는 정도 입니다.
특별한 형식을 집어 넣고 분석하는 툴을 짜볼려고도 생각 했지만
너무 경우의 수가 많아지는것 같아서리..
이렇게 해도 기가단위의 파일이 나오지만.. 마지막 천라인 정도만 짤라서
분석해 보고 있습니다.
파일의 싸이즈를 분석해서 짤라 넣는 프로그램을 돌린다면 그만큼 로그를 남기는
시간이 길어져서 프로그램의 실행에 영향을 줄 수도 있고 내부적으로 버퍼를
구현한다면 프로그램이 무작위로 죽었을때 버퍼에 남을 부분이 사라져 버리니까
디버깅용으로 적합하지 않더군요.
__
이경만
안녕하세요? 레이옷입니다.

흑.. 저희 서버에서는 내부 버퍼링하는 로그 매니저를 두고 있습니다.

아래 글처럼 갑자기 서버가 죽을 경우 원인을 알 수 없다.. 라는 큰

단점을 갖고 있지요. 근데, 원래의 목적은 디버깅용이 아니라 실제

게임 서비스에서 사용할 거였기 때문에, 쓰레드들이 파일 출력할려고

경쟁하고, 또 파일 출력할려고 기다리는 시간을 덜기 위해서(당연히

그동안에는 플레이어 서비스를 할 수 없으니깐요.. 저희 구조에서는)

전용 로그 쓰레드를 두고, 내부에 큰 버퍼를 만들어놓고, 5초마다 한
번 정도 로깅을 하고 있지요.. ^_^;

각 게임 쓰레드에서는 로그 매니저의 메쏘드를 호출해서 현재의 로그

레벨에 따라서 적절히 버퍼에 추가하면, 로그 쓰레드는 5초마다 혹은

버퍼가 몇 % 찰 때마다 파일에 쓰곤 하지요. 어차피 얘는 게임과는

무관하기 때문에..

암튼 conditional variable 을 사용하니까 쉽게 구현이 되더라고용.

==
물론 실제 디버깅은 cout & gdb 를 애용하고 있찌요. 크크.

Assert 가 난무하는 멋진 코드 - -;

아.. 웬지 시대에 뒤떨어지는 느낌이......... T_T

안녕하세요? 레이옷입니다.

현재 저희는 exception 을 많이 사용하고 있는데요..

예외 처리를 함으로써 발생하는 장점은,

코드가 무척 깔끔해진다는 겁니다.

예전같으면 어떤 메쏘드의 결과값을 체크해서 에러나 특수 상황일

경우 그에 적합한 처리 방법을 바로 명시해줬어야 하는데..

예외처리를 사용하면 대충 예외를 던지고, 상위에서 적절하게

처리하면 되니깐 꽤 편하더라고요.
제가 아주 검증된 사실을 가지고 있는건 아니지만,
예전 벤치마킹이나 서버 프로그래밍 관련 최적화 기법을 다루는
글에서 봤던 것입니다.

제가 알기로는 싼 프로세싱에 해당합니다.
(물론 사람에 따라서는 매우 다른 양상을 나타내겠지만요)

물론, 초당 꽤나 많은 횟수가 실행되는 루프에 들어가있다면

문제가 될 수 있겠지만, 암튼 쌉니다.
(보통 이럴때에는 루프를 예외처리 블록으로 묶으라고 하지만,
실제로는 그렇지 못한 경우가 많지요~..maybe)

반면에 비싼것들로는 메모리 할당과 해제가 있습니다.
(대부분 인지하시는지 모르겠지만)

특히,서버쪽 프로그램의 특성과 적절한 자료구조와 억세싱 방법을

취하기만해도 많은 퍼포먼스 향상을 가져올수 있다 들었습니다.

(물론,이런것들은 컴파일러가 아주 중요한 역할을 하겠지만요)

기본적인 메모리 풀링 알고리즘을 사용해서 메모리 할당과 해제를

처리한다면 적은 시간을 소요하고도 프로그램의 퍼포먼스를 향상시킬수

있다는 군요.