현업에서 현재 쓰이는 게임서버의 OS와 DB좀 알려주실수 있으신

mastercho의 이미지

현업에서 현재 쓰이는 게임서버의 OS와 DB좀 알려주실수 있으신지...

아시는분좀 답변 부탁드립니다

버려진의 이미지

kgda에 올려진 질문을 참고하시라고 링크 하려고 했더니 동일인이시군요 ^^;

mastercho의 이미지

^^ 넵

일단 현재 게임업체에서 사용하는 OS와 DB에 관해

분석좀 하려고 :)

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

지리즈의 이미지

아는 분이 온라이겜업체에서 근무해서 물어 보았는데...
자신의 회사는 NT를 , 다른 업체에서는 리눅스를 쓴다고 하더군요...
리눅스 업체는 별도로 커널을 패치해서 사용하다고 하고...
NT계열을 쓰는 업체는 쓰레드가 아무래도 좀 낳아서 쓴다고 하더군요...

There is no spoon. Neo from the Matrix 1999.

whizzm의 이미지

엔씨소프트의 리니지를 보면

윈도 nt 기반이며

DB 역시 MS-SQL를 사용하고 있습니다.

국내에서 개발되는 다수의 온라인 게임이 윈도기반으로

제작된다고 합니다.

windy96의 이미지

MMORPG의 경우에는 대개 NT 기반으로 합니다. (정확히 말하자면 Win2K 기반이라고 해야겠군요. 차이가 있으니..)
이유는 IOCP를 이용하기 위함입니다. 쓰레드 관리가 효율적으로 일어나지요.

리눅스를 쓸 수도 있겠습니다만.. 지원되는 쓰레드 라이브러리의 문제 등으로 인해서 아무래도 상용 유닉스보다 불편합니다. 유닉스 기반의 게임 서버도 많은 것으로 알고 있습니다.

kornet의 이미지

제가 처음에 다녔던 W모 회사는 FREEBSD와 MySQL을 사용했습니다.

패치 서버에는 NT를 사용했고, 나중에는 시험적으로 IOCP 도 사용해봤는데, 그건 별로 중요한 것이 아니었고,

게임 서버에는 안정성을 이유로 FREEBSD와 MySQL을 사용했습니다.

지금 다니고 있는 N모 회사에서는 NT 서버.. 2000이라고 해야하나. 그리고 MS-SQL을 사용합니다.

이 경우에는 지난번 회사와 달리 개발팀 외에도 많은 팀에서 많은 서비스들이 DB를 공유하기 때문에 MySQL로는 벅차겠더군요.

예전에 어느 분의 글에서 본 게 생각나는군요. FreeBSD는 게임 서버 만들기에 정말 좋은 환경인데, 거기에 들어가는 DB가 MySQL 정도밖에 없다는..

jolasen의 이미지

정확하지는 않지만 사용과 관리상의 이유로 NT,2000과 MS-SQL을 많이 사용하더군요. 재미 있는것은 2-3년전만 해도 주로 유닉스,리눅스,freebsd기반에서도 개발하는 곳이 많았는데 점차 윈도우기반으로 옮겨 가더군요. 지금은 아마 10개중에 한군데 정도 업체가 유닉스/리눅스기반 일듯 싶습니다.나머지 9는 윈도우 기반일거구요.
제생각으론 아마도 선발 업체의 문제가 아닐까 합니다.
초창기 리니지란 게임으로 대박을 터트린 NC에서 사용한 것이 NT/MS-SQL
이었습니다. 당시 게임 서버에 대한 자료는 별로 없었고, 잘나가는 회사에선
NT와 MS-SQL을 사용한다 하니, 너도나도 별 준비 없이 온라인겜에 달려 들기
시작하면서 게임서버는 NT와 MS-SQL을 사용해야만 하는걸로 알았지 않을까 싶습니다. 하하하...결국 그런것이 지금의 상황을 만들지 않았을까요?
어디까지나 제 생각입니다..

그리고 처음 질문 올리신님.. 실제 업체에서 사용하는 os와 db 가 궁금하시면
gamejob(http://www.gamejob.co.kr)에 가서 서버/네트워크 파트 구인
글을 모두 보면 어느업체가 뭘 쓰는지 자세하게 나옵니다.

mastercho의 이미지

꼭 그런것 같진 않은거 같네요

윈도우 리눅스 에서 소켓을 둘다 써봤는데

리눅스 유닉스에선 윈도우의 IOCP 방식을 따라갈수 있는게 없더라고요

kqueue 와 epoll이 있다고 하지만 쓰기엔 불편하죠

프리비에서 써야하거나 나 epoll이 되는 최신 커널 패치를 깔아야하고

2.6은 아직 테스트 버전인걸로 알고 있습니다

그렇다고 그것들이 성능이 IOCP보다 훨 낫냐? 그것도 아니거든요...

비슷하거나 성능차인 5%미만인수준인거 같거든요

그래서 그런게 아닌가 싶네요

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

mushim의 이미지

윈도우의 IOCP 라는 놀라운게 있었군요. 그런 것을 여태 모르고 있었다니...

구체적으로 어떤 방식으로 동작하고, 리눅스나 유닉스의 방식에 비해서 왜 우수한지 설명 부탁드리겟습니다.

단정적으로 말씀하시는 것을 보면, 확실한 근거가 있는것 같군요.

skjk의 이미지

IOCP는 Asynchronous(Windows에선 Overlapped라고 함) I/O + Thread Pooling을 아주 간단하게 할 수 있게 해줍니다.

Asynchronous I/O의 수행이 완료될 시 자동적으로 Thread Pool의 Thread중 하나가 해당 I/O와 연계되어서 깨어나서 필요한 로직을 수행하게 됩니다.

Thread Pool은 Stack구조로 되어있어서 가장 최근에 사용되었던 Thread순으로 가져와서 쓰게되므로 Context Switching이나 Paging부분이 최소화 될 수 있습니다.

Windows가 다른부분은 Unix보다 안정성이라덩지 기타 문제점이 많을 지 모르겠지만.. IOCP하나는 기똥찬 거 같습니다.

기타 Windows계열을 게임서버로 쓰는 이유로는.. 클라이언트가 거의 대부분 Windows기반으로 개발하니 같은 조건이라면 서버도 Windows로 하는 게 일관성도 있고 편하겠지요.

jolasen의 이미지

IOCP를 잘 몰라서 그러는데 좀 궁금한게 있습니다.
보통 얼핏얼핏 보다보면 IOCP+쓰레드풀 구조로 서버를 구성한다면
쓰레드 풀의 쓰레드들은 모두 같은 작업을 수행할수 있는 쓰레드들로 구성
되는거가 맞는건가요? 아니면 수신+송신 쓰레드는 따로 있고 job처리하는
쓰레드만 쓰레드 풀을 이용하는건가요?
같은 작업을 하는 쓰레드 들을생성하여 IOCP에서 구성하는 방식이라면
CPU*2+1 개 정도의 쓰레드를 생성하여 IOCP로 처리하는 방식과
작업별로 수신+송신+job처리 등의 쓰레드를 처리하는 방식을
비교 한다면 어떤 방식이 더 나을지가 궁금하네요.. 전 후자쪽이 더 나을거
같은데..
어차피 같은 작업을 수행하는 쓰레드들이라면 메모리 같으걸 공유해야 할것이고
공유해서 쓰려면 뮤텍스같은걸 걸고 써야 할것인데..
특히 게임서버라면 쓰레드 별로 독립된 데이터를 가지고 처리 하는것이 아니라
모두 같은 데이타 기반에서 작업을 처리 해야 하는데 같은 job을 처리하는 쓰레드
들을 여러개 생성하는것이 과연 성능향상에 어느정도 도움이 될지가
제일 궁금합니다.

jj의 이미지

테크니컬한것도 원인중에 하나겠지만, 대부분의 게임프로그래머들이 Windows people이라는것을 무시할 수 없을것 같습니다.

또한, 대부분의 게임 업체는 영세한경우가 많죠. (적어도 처음에는...), 서버프로그래밍만을 위해서 고급 유닉스 프로그래머를 따로 고용하는건 쉽지 않겠죠. 그렇게 한들, 특별한 메리트가 있는것도 아니구요.

"초기엔 걍 C/S다 윈도우로 가다가, 여유가 생기고 안정성에 문제가 생기면 유닉스 서버로 가지." 이렇게 시작했지만, 어느정도 코드가 안정화된다음에 마이그레이션 하는건 엄두도 안날테구요. 윈도우 기반 서버라서 특별히 문제될것도 없으니 그냥 가는거죠...

제가 결정권자라도, C/S다 윈도우 기반으로 갈것 같다는 생각이 드는군요...

--
Life is short. damn short...

byung82의 이미지

IOCP메커니즘은 아주 좋습니다 ^^:
일단 쓰레드 풀이라고 하지만 동시의 IO발생수가 대기중인 쓰레드 보다 적으면 1개의 쓰레드만 사용합니다.
^^: IO처리가 아주 많아지더라도 몇개의 쓰레드만으로 그 많은 IO를 처리하가 되죠.
그래서 Context Switch가 최소화 하게 만들어줍니다.

그런문제 때문에 직접 IO Pooling을 만드는것보다 Window IOCP로 구성해서 하는경우가 많죠.
Kqueue도 어느정도 될듯은한데 그 어느정도가 어느정도일지는 ^^:
그럼 ~

likejazz의 이미지

예전 MUG 중에 행복동이라는것이 있었는데 (98년경에 나왔던 게임으로 기억) http://happy.corea.to/rttechinfo.html 이렇게 사용했다는군요 :o

지금의 미르의 전설, A3 등의 모체가 아닐까하는 ..

--
Sang-Kil Park

sangheon의 이미지

skjk wrote:
기타 Windows계열을 게임서버로 쓰는 이유로는.. 클라이언트가 거의 대부분 Windows기반으로 개발하니 같은 조건이라면 서버도 Windows로 하는 게 일관성도 있고 편하겠지요.

저는 이게 정답이라고 생각합니다.

우리나라에서 MMORPG 개발 붐이 일어나던 시기, 프로그래머로 일하는 사람 중에 온라인 게임을 구경도 못해본 사람들이 태반이었습니다. 주로 VC로 패키지 게임을 개발하시던 분들이시죠.

거기에 더해 게임에 대해서 잘 알고 있는 유닉스 서버 프로그래머를 구하기 힘들었던 것도 한 몫했다고 봅니다.

--

Minimalist Programmer

crimsoncream의 이미지

저도 인력의 문제일 꺼라고 생각합니다.
유닉스에서 시스템 프로그래밍이 가능한 c 프로그래머를 구하는게 조금씩 더 어려워지고 있습니다. 우리회사가 해보니까 특례아니면 외국인(인도,러시아) 정도 빼놓고는 초임 수준에 기대할 수 있는 인력의 수준이 고용해서 당장 써먹어야 하는 작은회사가 감당하기 힘들 정도입니다. 또 운좋게 핵심인력으로 이런 사람 한두명 구했거나 이미 있는 회사라고 해도 이를 서포트 해줄 이른바 부사수급을 구하는건 아예 불가능에 가깝습니다.

아마 게임업체도 처음부터 자금과 기간이 넉넉해서 트레이닝 시켜가면서 하는건 불가능할테니까. 인력수급에 탄력이 있는 윈도우즈를 선택하는 거 같습니다. 얼른 만들어서 데모라도 보여줘야 투자를 끌어들이고 그 돈으로 장비마련해서 서비스 하자나요 :(

오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.

sweetcorn의 이미지

좀 엉뚱한 질문입니다만....

그럼 유닉스에서 시스템 프로그래밍 쪽을 공부하는 것은 전망이 없는건가요?

대학 학부생입니다만, 요즘 개인적으로 이분야가 재밌어서 꾸준히 공부를 하고 있었는데 위의 글들을 보니까 좀 혼란스럽군요....

crimsoncream의 이미지

yy20716 wrote:
좀 엉뚱한 질문입니다만....

그럼 유닉스에서 시스템 프로그래밍 쪽을 공부하는 것은 전망이 없는건가요?

대학 학부생입니다만, 요즘 개인적으로 이분야가 재밌어서 꾸준히 공부를 하고 있었는데 위의 글들을 보니까 좀 혼란스럽군요....

제 경험으로는 unix 시스템 프로그래머에 대한 수요는 항상 존재합니다. 예전에 헤드헌터에서 얼토당토 않은 자리에 소개하는 글이 와서 봤더니 이유는 오로지 유닉스 프로그래밍이 가능하다는 거였습니다. 공부하시면 아마도 트렌드가 바뀌어도 꾸준히 먹히는 경력 하나를 가지 실 수 있지 않을까 생각합니다. 위에 제 글은 구직이 아닌 구인쪽에서 어려움을 겪고 있다는 뜻으로 쓴 글이었습니다.

오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.

mastercho의 이미지

사실 프로그래밍을 해보면 환경 자체는 윈도우가 좋아서 그렇지 , 프로그래밍은 윈도우가 훨씬 어려운쪽에 속하는거 같더군요

단지 유닉스 리눅스 프로그래밍 환경 자체에 다들 겁먹고 공부를 안하는게 아닌가 싶습니다

그래서 인력부족이 생기는듯

프로라면 OS를 가리지 말아야 한다는 -_- 옛 성인?의 말씀이 떠오르네요

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

ihavnoid의 이미지

mastercho wrote:

프로라면 OS를 가리지 말아야 한다는 -_- 옛 성인?의 말씀이 떠오르네요

매우 강하게 동감합니다. 프로라면 OS뿐만 아니라 언어도 가리지 말아야겠죠.

Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24

jika의 이미지

그렇다면 플렛폼도 가리지 말아야겠군요...

허 험난한 앞날이 눈에....

zelon의 이미지

여튼 Win2000 Server + MS-SQL 쓰고 있습니다. 윗분들이 말씀하신 것처럼... 한 명의 프로그래머가 클라이언트 코드, 서버 코드 등을 봐야하는 이유도 분명있습니다. 어느 정도급의 인력이 수급되지 않는 한 어쩔 수 없는 것 같습니다.

그리고 컨택이 되는 다른 회사를 봐도 사정은 비슷한 듯...

글고 방금 혹시나 해서 찾아봤는데.. 역시나... 제가 서버쪽을 짜다 보니까 MS-SQL 이 정말 좋다고 느끼는게, 물론 개인적인 입장일 수도 있지만, 아직 MySQL 에서는 Stored Procedure 를 지원 못하는 것 같더군요. 5.0 에서는 아마 되는 듯한 데(개발 중이라네요). MySQL 이 아직은 조금 무리가 있지 않나싶습니다.

ps : 데이터베이스 쪽은 제발 타입이 좀 통일되면 좋겠다는... ㅠ.ㅜ 필요할 때마다 컨버트해서 쓸려니... 쩝

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

espereto의 이미지

jika wrote:
그렇다면 플렛폼도 가리지 말아야겠군요...

허 험난한 앞날이 눈에....

당근입니다. :)

프로그래머의 길은 참으로 험난하죠. :D

ㅡ,.ㅡ;;의 이미지

espereto wrote:
jika wrote:
그렇다면 플렛폼도 가리지 말아야겠군요...

허 험난한 앞날이 눈에....

당근입니다. :)

프로그래머의 길은 참으로 험난하죠. :D

그러면." 누울자리를 보고 다리를 뻗어라.." 는 말도 있던데 반대되는말아닌가요?? ........ 쿵..ㅡ,.ㅡ;;


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

romantic74의 이미지

Windows플랫폼에서 IOCP, Oracle 을 쓰는 곳은 없나요 ?

bleu의 이미지

mastercho님 글은 GPG에서 가끔 봤는데 여기서도 뵙네요..^^;;

지금 개발하는 게임 서버는 IOCP 기반에 MSSQL을 사용해서 구현중입니다.

위에 UNIX(LINUX)기반 서버하고 IOCP기반을 비교해서 이야기 하시는데...

제가 경험한 바로는...그냥...-_-;;

있으닌까 쓴다...정도 인거 같습니다.

정작 중요한건 그거보다..다른쪽이...

문제에 봉착하는 경우가 많아서...

imays의 이미지

리눅스에서 서버 스트레스 테스트를 아직 안해봤습니다만, IOCP기반 저희 서버에서 이정도 성능이 측정됐습니다.

- 클라가 서버로부터 다운로드 10~20KB 트래픽 발생하는 MMORPG 게임 케이스로, 동접 12,000 정도. (이 상태에서도 서버 전체 성능 중 20% 정도만이 사용되고 있었습니다. 실제로 두배 정도는 충분히 더 붙일 수 있다는 얘기겠죠. 10기가비트 스위치허브로 교환 후 더 많은 동접 2~3만 정도 붙여봐야 자세한걸 알 수 있을 듯)
- 단순 핑만 일정시간 교환하는 경우 동접 6만 5천 정도. 랜카드 두개 붙이면 13만 정도는 충분히 들어갈 수 있더군요.

랙이나 과부하는 없었습니다.
더 접속을 받을 수 있었지만 더 붙일 수 있는 클라 컴이 부족해서 더 이상은 못붙여봤습니다.

<사용 환경> - 윈도2008서버 - 제온2.6 듀얼 - 프라우드넷(윈도IOCP기반)

리눅스에서의 성능은, 서버를 리눅스로 포팅을 한 후 측정해봐야 알 것 같습니다. 올해나 내년즈음에 할 것 같아요.
지레짐작으로, 주변에서 리눅스 관련 성능을 들은 바로는, 윈도와 비슷하게 나올 것 같습니다.

서버 프로그래밍에서는, 리눅스냐 윈도냐 부분보다도, 어떻게 스레딩과 I/O 처리, 메모리 FOOTPRINT를 최적화해서 코딩하냐에 따라 성능이 결정되는 것 같습니다.

----------

게임 서버 엔진 개발자입니다.

https://blog.naver.com/imays

ddoman의 이미지

리눅스 쪽에서도

synchronous I/O 기반인 select()/poll()/epoll() 을 이용한 서버 프로그램들이 많았지만,
커널 2.6부터 Asynchronous I/O 지원이 기본으로 포함되고

sendfile()이나 vmsplice(), splice() 같은 zero-copy를 위한 API들이 도입됨에 따라
여러가지 디자인들이 이용되고 있습니다.

대표적인 예로, lighttpd 의 블로그를 보면 ASIO를 이용한 성능비교 벤치마크가 있습니다.
IOCP는 단지, Asynchronous I/O의 일종일 뿐이고, 윈도우 뿐 아니라, 솔라리스에서도 IOCP가 있으며
리눅스에도 2.6부터는 AIO가 자주 쓰인다고 할수도 있겠네요.

lighttpd의 블로그에는, 재미있는 결과들이 나와있는데
zero-copy가 좋은 경우도 있지만, zero-copy의 특성상, O_DIRECT flag가 이용되고
raw buffer가 직접 사용되기 때문에, unbuffered I/O로 취급되어, Disk I/O의 경우, 오히려 buffered I/O보다
더 느립니다.(물론, process자체에서 user-space caching 을 구현하여 성능개선을 할수 있습니다.)

그 외 여러 (디자인 상)이슈들이 있지만, 설명하자면 너무 길고,
모든 경우에 IOCP같은 Asynchronous I/O가 Synchronous I/O보다 더 나은 성능(여기선 throughput을 의미) 을 보여주는건 아닌것 같습니다.
확실한건, 최소한, 복사 작업을 커널에게 맡겨버리기 때문에, 유저 process의 I/O idle상태를 훨신 줄여줘서
latency를 줄이는데는 효율적으로 이용될수도 있을것 같습니다.

하지만, synchronous I/O 기반의 디자인들도 latency를 줄이기 위한 여러 테크닉을 쓸수도 있기에,
리눅스에서는 SIO, ASIO 모두 구미에 맡게 골라 쓰는게 맞는것 같습니다.

반면, 윈도우는 ASIO( IOCP ) 말고는 SIO 지원이 취약한것 같습니다.

Quote:

서버 프로그래밍에서는, 리눅스냐 윈도냐 부분보다도, 어떻게 스레딩과 I/O 처리, 메모리 FOOTPRINT를 최적화해서 코딩하냐에 따라 성능이 결정되는 것 같습니다.

전적으로 동감합니다. 하지만, 윈도우 NT의 SMP kernel성능과 리눅스의 SMP kernel 성능에 차이가 있을수도 있지않을까... 한번 생각은 해봅니다.(근거없음)
그냥..NT는 항상 x86기반의 PC에서나 쓰는 OS라는 인식이 저한테 너무 박혀있는지라...

혹시라도 CPU가 16개로 인식되는( 쿼드코어 * 4 ) 그런 환경에서 리눅스만큼 스케줄링을 잘 할까 의심이 되는...;;;( 다시 말하지만 아무 근거없음 )

imays의 이미지

윈도도 zero copy를 쓸 때 주의해야 할 것들이 있습니다. 예를 들어 페이지 아웃 되어버릴 수 있는 곳에 asio가 접근하는 buffer가 있으면 연결 디스 사태 등이 발생하기 때문입니다. 그러다보니 그러한 메모리 페이지를 최대한 절약해 써야 하고(비페이징 페이지 갯수 자체가 제한되므로) external frag가 발생하지 않도록 노력해야 하죠. 그만큼 코딩도 까다로와지고요.

물론, 극복하면 대폭 오르는 성능의 희열을 느낍니다.

윈도의 경우, OS와 하드웨어, 심지어 네트웍 드라이버의 성능에도 영향을 받습니다. 그리고 생각보다 성능이 나쁘고요. 따라서 OS에 의존 안할 수 있는 방법이 있다면 최대한 의존 안하는 것도 요령이 됩니다. (근거: 저는 프라우드넷에 패킷 coalesce 기능을 넣었는데요, 그 댓가로 서버 내부 퍼버 관련 연산량이 많아지기 때문에 성능 저하를 우려했지만, 의외로, 서버 최대 동접 수용량이 증가하는걸 봤습니다. coalesce 알고리즘이 커널 접근 횟수가 줄기 때문이었죠)

제가 해본 테스트에서 쓰인 환경은 CPU 코어 16개를 썼습니다. 2NUMA였고요. x64이고요. 서버 프로세스당 1 NUMA(8개 코어)를 골고루 사용하고요(서버 엔진 자체가 concurrency를 활용하도록 만들어져 있다능 ^^v), 서버 프로세스 2개를 띄워야 16개 코어를 모두 쓰더군요. 스위치 허브 한계 때문에 2NUMA test는 아직 안해봤지만, 별 탈 없다면 MMORPG 기준 동접 3만 정도는 들어갈 것 같네요. (물론 서버컴 한대에서)

----------

게임 서버 엔진 개발자입니다.

https://blog.naver.com/imays

ddoman의 이미지

프라우드넷이 무엇인지 몰라서, 검색을 해보았는데
imays님이 게임업계에서는 유명하신분이군요. 제가 게임업계종사자는 아닌지라, 몰랐습니다. :D

블로그 들어가봤는데, 재미있는 글들이 많더군요. 가끔 kldp.org에도 좋은글 남겨주세요~

imays의 이미지

아닌게아니라 윈도 SIO는 거시기합니다. 일단 64개 이상의 select()가 되지 못하는거부터 안습

----------

게임 서버 엔진 개발자입니다.

https://blog.naver.com/imays

emptynote의 이미지

OS를 떠나 IOCP 정말 물건이군요.

동접 1만 2천이라니....

MMORPG 라고 해서 그런데 NC 아이온 섭당 동접 5-6천 이라는데 이벤트나 공성때에는 랙 쩔던데요.

NC가 무엇을 쓰는지는 모르겠지만, 설마 IOCP 에 대해서도 검토 안했겠습니까?

적어도 그 이상 성능을 내는것을 가지고 있다고 본다면,

서버는 놀구있고 단지 클라이언트만 버벅되는거 아닌가 라는 생각을 해 봅니다.

비록 본문글이 2003년 글이지만

올해 리눅스로 포팅하시면

그 결과에 대한 소식을 전해주시면 감사하겠습니다.

imays의 이미지

공성전에서 버벅대는건 동접 2~3천 문제가 아니라 좁은 지역에 많은 플레이어들이 모여있어서 생긴 문제일 수도 있습니다.
한국이야 회선이 빵빵하니까 상관없지만 외국 나가서 ADSL2+ 쓰는 환경만 가도 한 화면에 수백 플레이어 보이면 클라쪽 트래픽 부하가 한계를 칠지도 몰라요.
클라 렌더링 프레임율 저하도 한 몫 할거고요.

제가 알기로는 리니지는 처음에는 솔라리스 기반으로 개발됐는데, 윈도 서버로 포팅되었다고 합니다. 리니지가 IOCP를 썼는지는 모르겠지만, 아마 쓰지 않았을까요? IOCP는 거의 17년전에 나온 기능이고, 저도 14년전에 IOCP를 써서 게임서버를 만들 정도로 나름 알려진 방법론이었으니까요.

----------

게임 서버 엔진 개발자입니다.

https://blog.naver.com/imays