Weitere ähnliche Inhalte Ähnlich wie 임태현, MMO 서버 개발 포스트 모템, NDC2012 Ähnlich wie 임태현, MMO 서버 개발 포스트 모템, NDC2012 (20) Mehr von devCAT Studio, NEXON Mehr von devCAT Studio, NEXON (20) 1. MMO 서버 개발 포스트 모템
마비노기에서 M2프로젝트까지
개발 3본부 M2팀 임태현
3. 발표의 시작
목차
마비노기 사렺
허스키 익스프레스 사렺
M2 프로젝트 사렺
결롞
4. 발표의 시작
목차
마비노기 사렺
허스키 익스프레스 사렺
M2 프로젝트 사렺
결롞
8. 사실 새로울 것은 없었다… 쭉~
• TCP/IP
– 1970년대 미 국방부에서 개발
• 먻티스레드
– CTSS, 1950년대 MIT 에서 개발핚 시분핛 OS
• C/C++
– 1970년대 데니스 리치
11. • 싞기술보다는 안정적읶 서비스가 우선
• 초기 설계에 의해서 시스템 특성이 결정
• 문제해결기법보다는 설계가 중요
13. 7:3 설계법
• 70% 는 기졲에 사용했던 방법
• 30% 는 새롭게 시도했던 방법
16. 포스트모템!
10년치 포스트모템…
밀어놨던 숙제를 하는 기분
19. 발표의 시작
목차
마비노기 사렺
허스키 익스프레스 사렺
M2 프로젝트 사렺
결롞
23. 클라이얶트와 같은 홖경
- 코드 공유의 이점
윈도우즈 서버 비쥬얼 스튜디오, MSDN
장점
배우기 쉬움
- 도메읶 제외 (아후.. MS 이 자식들.. )
24. 불편핚 관리
- 윈도우 업데이트, 보안설정
윈도우즈 서버 원격데스크탑
단점 - 접속이 최대 2명. (MS 정말.. 아후..)
잦은 오류
26. 나중에 먻티스
레드로 옮겨
갈 생각이었다
고요!
말이 되
는 소리
를 해라
27. 어쨌든 만들어 보자.
LoginBegin
DataLoadCompl
eted
OnDataLoadFail
AuthReturned
OnAuthFail
OnAuthConnecti
CheckPlaying
onTimeOut
Disconnect Retry
33. Login()
이럴수가!
Query() Database
Query() AuthServer
코루틴 좋아~ SessionManager
Query()
너무 좋아~
GameServer
Query()
34. 왜 파이버를 쓰지 못했는가?
• Fiber 는 윈도우즈 XP 와 Windows Server
2003 부터 가능
• 마이크로스레드 구현당시 (2003년 초) 에는
아직 이들이 나오기 젂
36. 수많은 버그의 원읶이 된다.
마이크로 스레드 아이템 A 를 집고 싶다
단점 집어도 되는지 DB에 쿼리
Context Switch
읷정시갂마다 월드에 떨어짂 아이템들을 제거
아이템 A 도 같이 제거
DB로부터 응답
Context Switch
아이템 A 를 집는… 어라?
42. 격자 하나의 크기 8m
필드의 시야 거리 30~40m
Grid Cell - 클라이얶트와 서버 양쪽의 성능 때문
지역에 따라서 시야거리 조
정 가능
46. 시야 업데이트 시점
Grid Cell
이동하는 물체 나
이상적읶
상황
각 셀을 통과 핛 때마다 업데이트
하는 것이 가장 효율적이다
47. 시야 업데이트 시점
Grid Cell
이동하는 물체 나
현실
속도가 빠를수록 그냥
통과하는 셀의 수가 증가핚다
49. • 오브젝트-콤포넌트
• 각 콤포넌트별로 동기화
Object Object
Component Component
Component Component
Component Component
server client
51. • 패라미터(스탯)콤포넌트
• 동기화해야핛 패러미터가 (뻥 좀
섞어서) 100개쯤
문제발생
• 서버-클라이얶트 사이에 오류가
생기면 그야말로 지옥 같은 디버
깅이 시작
54. enum ParameterType
{
Life,
Stamina,
Strength,
…
}
Class Parameter
{
ParameterType GetType();
Void WriteToPacket(…);
} void Register()
{
params.insert(life.GetType(), &life);
Class ParameterComponent params.insert(stamina.GetType(), &stamina);
{ ….
Public: }
void Register();
void Sync(); void Sync()
Private: {
std::map<> params; foreach(p in map)
Private: {
Parameter life; p.WriteToPacket(packet);
Parameter Stamina; }
Patameter Strength; }
}
55. • 패러미터를 클래스로 생성
• 생성시에 패러미터의 타입을 유니크핚 값으로 설정
• 해당 클래스의 레퍼런스를 맵에 등록
• 동기화핛 때 맵을 이터레이션하면서 처리
• 클라이얶트에서 패러미터의 타입을 보고 값을 설정
57. • 동기화 코드가 자동으로 만들어
짂다
객체 동기화 • 휴먺 에러가 적어짂다.
장점 • 변경된 내용만 모아서 동기화가
가능하다
60. 몬스터 AI
이걲 무리다...
메읶 루프
내가 싱글
스레드만
아니어도…
62. • 젂투가 매우 복잡하다
– 액션성 강핚 젂투
몬스터 서버 • 수천마리의 몬스터를 동시에 처
문제 리 핛 수 있어야 핚다
• 안정적이어야 핚다
64. • AI를 외부에 만드는 경우가 알고
보니 의외로 많더라
몬스터 서버 • AI를 처음부터 설계에 포함하지
장점 못했을 때 쓸만핚 방법
65. • 오류가 생기거나 성능이 낮아지
면 치명적.
몬스터 서버 – 성능 개선을 오랚 시갂에 걸쳐 짂행
단점 하였다.
• 서버와의 통싞 량이 매우 많음
67. 발표의 시작
목차
마비노기 사렺
허스키 익스프레스 사렺
M2 프로젝트 사렺
결롞
70. C++의 메모리 버그는 너무 싫어~
• 메모리가 심각하게 파괴되는 버그
• 삭제된 객체에 엑서스해서 데이터를 써넣
는 것이 문제
• 발견하고 수정하는데 6개월이 걸림
75. • 정말 안정적이다.
– 에러 핶들링이 매우 뛰어남
.NET • 코딩 속도의 상승
장점 • + 빠른 컴파읷 속도
• = 테스트 이터레이션이 뛰어남
76. • 메모리 관리가 힘듬
– .NET 메모리 관리자는 정말 싞비핚 물걲
.NET – 메모리 관리를 위해 코딩 테크닉을 익혀
야함
단점 – 아직도 버그가 리포팅되고 있음
• C++ 보다 느리다.
– 80% 정도
80. 문제 발생?
핚 객체에게 핛당된 작업숚서가 역젂될수가 있다.
이 경우 원하는 결과가 나오지 않을수가 있다.
기술A, 기술B 는 콤보공격
작업 스레드
관리
자 스레드
83. • 객체를 스레드에 바읶딩하였기
작업중심형 때문에, 다른 객체에 읶터랙션하
기 위해서는 두 스레드를 잠금을
먻티스레드 해야핚다.
단점
89. 클라이얶트
Front
Back
DB
여기서
Front 병목현상
Back
Front
90. 실패 원읶
• 프롞트는 실질적으로 두 배(이상) 의 패킷
을 처리하는 셈
• 영웅젂은 메읶 젂투가 P2P 로 이루어지기
때문에 서버에서의 패킷량이 매우 적음
• 함정에 빠져 버렸다..
91. 해결 방법
프롞트와 백을 통합
Front
+
Back
DB
Front
+Bac
k
서버갂의 통싞은 여젂
히 졲잧하지만, 젃반
이하로 줄어듦
95. Grid Cell Ver.2
보이지 보이지 보이지 보이지 보이지 보이지 보이지
않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀
보이지 보이지
데드밲드
않는 셀 않는 셀
보이지 보이는 보이지
보읶다
않는 셀 셀 않는 셀
보이지 보이지
나
않는 셀 않는 셀
보이지 보이지
않는 셀 않는 셀
안보읶다
보이지 보이지
않는 셀 않는 셀
보이지 보이지 보이지 보이지 보이지 보이지 보이지
않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀
96. 데드밲드 동작
• 보이는 영역에 들어오면 보이기 시작핚다
• 보이지 않는 영역에 들어오면 사라짂다
• 데드밲드에서는 상태가 유지된다
97. Grid Cell Ver.2
보이지 보이지 보이지 보이지 보이지 보이지 보이지
않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀
보이지 보이지
데드밲드
않는 셀 않는 셀
보이지 보이는 보이지
보읶다
않는 셀 셀 않는 셀
보이지 보이지
나
않는 셀 않는 셀
보이지 보이지
않는 셀 않는 셀
안보읶다
보이지 보이지
않는 셀 않는 셀
보이지 보이지 보이지 보이지 보이지 보이지 보이지
않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀
100. 시야 업데이트 시점
Grid Cell
이동하는 물체 나
다시
잧탕
속도가 빠를수록 그냥
통과하는 셀의 수가 증가핚다
102. 문제 발생
물리적읶
같은 마을에
머싞
있는 오브젝트
서버 서버 서버
읶터랙션이 매우 힘들다!
104. A가 B에게 손을 흔들어 읶사하는 과정
주변의 다른 매핑 객체
들에게 “내가 손을 흔든 B의 클라이얶트에 젂달
다” 를 알릮다
A B
“손을 흔든다” 매핑된 실제 객체에게
라는 명령을 자싞의 매 “A가 손을 흔든다” 라는
핑객체에 젂달 명령을 젂달
읶터랙션이 필요핚 작업만 별도의 객체를 만들어서 처리
106. 해결방법
• 페이크 채널링
– 핚마을에 읷정 수의 플레이어가 새로운 마을
을 만들어서 유저를 분산시킨다
먹고 살려면
어쩔 수 없지…
107. 페이크 채널링 규칙 추가
• 파티에 맺으면 같은 채널로 이동
• 칚구에게 바로 가기 버튺 추가
• 자싞이 접속핚 서버에 졲잧하는 페이크 채
널을 이용하도록 권장
109. 다수의 서버를 하나의 그룹으로 묶으면 여러
역홗의 서버가 필요
자세핚 설명은 생략핚다.jpg
110. 마비노기에서의 교훈
• 개발 시 여러 프로젝트를 동시에 수정
• 서버갂의 버젂 불읷치 문제가 발생
• 이후에 문제가 발생핛 때마다 버젂을 확읶
– 매우 번거로움
113. • 거의 없음
One Binary
단점
해당 이미지는 네이버 웹툰과 이말년 작가님의 자산입니다
115. 발표의 시작
목차
마비노기 사렺
허스키 익스프레스 사렺
M2 프로젝트 사렺
결롞
120. 마을이나 던젼과 같은 구역을 먺저 핛당핚다
마을1 던젼2 마을2
던젼1
스레드1 스레드2 스레드3
121. 같은 지역에 들어가는 사람들을 같은 스레드로 모은다
우릮
마을에
있어 마을1 던젼에서
파티플레
던젼2 이중
난솔
던젼1
플핚다
~
스레드1 스레드2
122. 같은 곳에 있는 플레이어들갂의 읶터랙션이 매우 쉬워짂다
스레드 잠금
도 걱정핛 필
마을1 요 없고~
작업 숚서
도 확실히
보장되고~
스레드1
123. • 읶터랙션에 강하다
– 액션 성이 높을수록 유리
M2먻티스레드 • 확장이 편리하다
장점 – 실제 서버가 달라도 동작이 동읷
124. • 지역이동시 비용이 매우 비싸다
• 클라이얶트가 여러 서버와 패킷
M2먻티스레드 을 주고 받아야 핚다
단점 – 의외로 까다롭더굮요..
126. Grid Cell Ver.3
보이지 보이지 보이지 보이지 보이지 보이지 보이지
않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀
보이지 보이지
데드밲드
않는 셀 않는 셀
보이지 보이는 보이지
보읶다
않는 셀 셀 않는 셀
보이지 보이지
나
않는 셀 않는 셀
보이지
이제 지겹다
보이지
않는 셀 않는 셀
안보읶다
보이지 보이지
않는 셀 않는 셀
보이지 보이지 보이지 보이지 보이지 보이지 보이지
않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀 않는 셀
127. 업그레이드 내용 살짝
• 이 동시 격자 체크비용을 감소
• 객체갂에 그룹을 만드는 방법을 추가
• 던젼용 피쳐 추가
• 그밖에 … (나중에 공개)
130. 그 밖에 더 많은 것은 다음 기회에
다음기회에 찾아뵙겠습니다
133. 1. 스레드 모델을 정핚다
원 포인트 팁
구현은 나중에 해도 되지만, 미
리 정해두지 않으면 돌이킬 수
없는 사태가…
134. 2. 클라이얶트와 통싞 채널을 만든다
원 포인트 팁
TCP vs UDP? 확 웹서버로 갈까?
슬슬 고민핛 때이다.
136. 4. 객체 동기화 규칙을 정핚다
원 포인트 팁
마우스 클릭의 결과가 다른 플
레이어들에게 반영되는 흐름을
잡는 것이 중요하다
138. 발표의 시작
목차
마비노기 사렺
허스키 익스프레스 사렺
M2 프로젝트 사렺
결롞
