-이것 저것 네떡 게임들을 했다. 디아블로를 즐겨 했고, 우연히 듀플링 등 네떡겜의
 고질 등을 하나하나 알아내었다.
 -무엇을 만들까 고민하다가 '다방구'라는 통탄할 소재가 튀어나왔다. (내가 그런
 소리 안했어도 지금쯤, 개인적으로 좋아하는, 피튀기는 잔인겜 하나 만들고
 있었을텐데..)
 -다이렉트플레이를 선택하여 프로그래밍을 시작했다. 자료는 없었으므로,
 duel이라는 소스에 의존하는 수밖에 없었다.
 -처음으로 다이렉트플레이로 돌아가는 간이 네떡 프로그램을 만들고 나서, 나는
 기쁜 나머지 뱃속에서 나오는 웃음소리를 냈다. 한동안 나의 웃음소리는 사내의
 이슈가 되었다. 마귀할아범의 웃음소리가 어쩌구 저쩌구..
 -만들어 보는 중에 랙이 '거지 망토'가 아닌 '지연시간'이란 뜻임을 알았다.
 -액션 게임이 더 만들기 쉬울 줄 알았는데, 랙이란 놈 때문에 되레 어려운 놈임을
 알았다. 하지만, 이제와서 빠꾸할 수는 없다!
 -TCP/IP와 UDP/IP라는게 따로 있다는 사실을 알았다. 그러면서 winsock이 뭔지 알게
 되었다.       

 -패킷 노가다는 하늘을 찔렀다. 그거 때문에 작년 설날에도 회사에 나와 일했다.
 -혼자서 네떡 서버와 클라이언트를 모두 만드니까 애인 하나 사귈 시간이 안생겼다.
 (나중에 괜찮은 프로그래머 하나 더 붙었을때 나는 만세를 불렀다. 그런데, 하필 그
 프로그래머에게는 예쁜 애인이 하나 있다니! 그 프로그래머에게 일 다 밀어버리고
 애인 뺏어버릴까 흑심을 품기도 했다. ..하지만, 지금도 애인이 없는거 보니까,
 아무래도 재고해봐야겠다..)
 -네떡 엔진 만드는 것보다 네떡에 맞는 게임 디자인을 하는게 더 중요하고 어렵다는
 사실을 알아냈다. 왜 네떡 게임이 버벅댈 수밖에 없는지 알아내었다. 네떡 게임은
 프로그램의 특성상 웬만해선 자주 고치면 안된다. 차라리 추가하면 했지 빼거나
 고치는건 몇 배의 노가다를 요구한다. 그렇지만, 어느 누구도 네떡 게임을 기획해
 본 자가 사내에 없는지라, 결국 해보고 고치는 방법을 취하지 않으면 안되었다.
 "짭밥으로 딸리는 내가 참지.. 대신 애인 대신 찾아 붙여주쇼!"
 -다이렉트플레이의 한계에 대해서 주워듣고 난 후에 몽땅 갈아치웠다. 결국
 winsock과 멀티스레딩으로 떡칠했다.
 -어줍잖은 공부만 하고 멀티스레딩 프로그램 만들었다가 데드락 잡느라 몇 주간

 밤샘을 밥먹듯 했다. (머리가 길면 장발장, 밤을 자주 새면 밤샘밤인가?)
 -서버 프로그래머는 한명이면 안되겠다는 생각이 들었다. 게임이 꽤 큰 경우, 엔진
 프로그래머, 서버 게임 처리 담당 프로그래머, 웹 프로그래머, 디비 프로그래머
 이렇게 안나누면 노총각 되겠다는 공포가 찾아오기 시작했다. (그래서 애인이
 없는걸까..)
 -TCP는 금방 됐지만, UDP에서 엄청난 뺑이를 쳤다. 랜에서 돌릴때, 하이텔에서
 돌릴때, 천리안에서 돌릴때 등 각각에 대한 경우가 모두 다르다는 사실을 알아낸
 다음, 이번 게임은 주거도 느리게 안가면 버벅 그 자체가 될거라는 엄포로 사내
 분위기를 냉랭하게 만들기도 했다. 어쨌건 지금은 UDP를 쓰긴 하지만, 그래도 어떤
 예외가 생길까봐 항상 살얼음이다.
 -울티마 온라인은, 처음 봤을때 버그 투성이 개판이라 결론지었다. 하지만, 지금은
 울티마 온라인만한 탄탄한 네떡 게임은 거의 없을것이라고 생각한다. 울온은
 얽혀있는 게임 기획을 모두 프로그램으로 탄탄하게 옮겨놓은 대작이다.
 -다른 회사에서는, 하도 서버가 잘 다운돼서, 그 회사 간부가 서버 프로그래머에게
 "서버 다운 안되는 시간만큼 너한테 휴가 주겠다"라는 말까지 했다고 한다. 무리가

아니다. 한사람씩 늘어가면서 나의 걱정은 비례해서 늘어났으니까.
 -4500만원짜리 서버 컴퓨터를 보자마자, 서버 프로그램 디자인과 전자파 장해에
 대해 재고했다. 저런 하드웨어 사양이라도 사용자가 300명 들어오면 스레드가
 900개가 될텐데 버텨낼까..? 900개의 스레드가 돌아가는 서버에서 나오는 전자파
 때문에 내가 나중에 딸부자집 아빠가 되면 어떻하지? 내 성은 흔한것도 아닌데..
 -게임 업그레이드 하면서 아이템 데이터베이스 그냥 넘어갔다가 베타 사용자들한테
 욕을 엄청 먹었다. 네떡 노가다에 디비 변화까지 겹친 상황..가뜩이나 어려운 게임
 기획 바꾸기가 더 어려워졌다.
 -괜찮은 여자 하나 조만간 생길 것 같다.. 고진감래란 말야!
                                                           

효과적인 동기화

네트워크 게임에서 동기화를 해결하기 위한 방법은 여러가지가 있을 수 있다고
생각합니다.
우선 플레이어의 움직임에 관성을 줌으로서 해결할 수 있는데, 이것은 디아블로
에서 볼때 쉽게 알수 있는 일이지요.. 즉, 플레이어가 어느 방향으로 움직이는데
갑자기 생각이 바뀌어서 다른 방향으로 움직임을 수정하려고 한다면 네트워크에
많은 부하가 발생하게 됩니다. 이를 방지하기 위해서 즉각적인 수정이 되지
않도록 하면 어느정도는 해결할 수 있다고 생각합니다.
또 한가지의 방법은 캐릭터의 움직임에 대한 것입니다. 예를 들어서 네트워크
지연시간에 따라서 애니매이션의 프레임을 조절하는 것인데, 이것은
네트워크 지연시간 스케쥴링 기법으로 해결하는 것으로 알고 있습니다.
이 밖에도 다양한 방법이 있지만, 우선적으로 해결해야 할 문제는
네트워크 프로토콜을 어떠한 것을 사용할 것인가에 달린게 아닌가 합니다.
물론 TCP/IP를 기반으로 하겠지만, 기존의 HTTP나 FTP등의 프로토콜과는
약간의 구별되는 형태의 게임에 적합한 프토토콜을 개발하는 것이 좋을 듯    
합니다.
한가지 동기화를 아예 무시하는 형태의 게임을 생각할 수도 있습니다.
동기화의 가장 커다란 문제점은 사용자간에 지속적인 네트워크 상황을 체크해야
한다는 것입니다. 그렇기 때문에 사용자가 느린 네트워크 상황을 가지고 있건
상관 말고 일정한 속도에 모든 사용자를 맞추어버리는 것이지요...
만약에 일정한 속도 이상의 네트워크 전송속도를 가진 사용자가 있다면 그것은
다른 사람보다

 빠른 게임을 가능하게 할수도 있으리라 생각합니다.
하지만, 그건 올바른 게임을 가능하게 하리라고 생각되지 않습니다.
바람의 나라의 경우에는 느린 전송속도의 플레이어와 빠른 전송속도의 플레이어
간에 서로 동기화가 되지 않는것 같습니다.
이상에 제가 생각하는 동기화에 대한 참고발언이었습니다.
의문이 생기시면 멜 주셔요....  양정녕  (althus  )

이상적인 방법이라면 매 프레임마다 모든 클라이언트들의 자료를 서로 주고
받는 것이겠지만, 속도 문제로 효용성이 떨어집니다.
대안은 두개의 프로그램 (혹은 더 많은 프로그램 = 클라이언트) 이 동시에
시작해서 각자의 메모리에 같은 내용을 가지도록 하게끔 할 꼭 필요한 정보
만 공유를 하는 것입니다. 간단하게 말하자면 마우스만 사용을 하는 프로그램이라면
마우스의 필요한 정보, 또는 걸러진 정보만을 주고 받는 것이고, 키보드를 사용
하는 프로그램이라면 필요한 키코드 (커맨드) 들만 공유를 하는 것입니다.
이렇게 처리할때에 예를 들어서 3 대의 컴퓨터가 네트웍상에서 연결된 상태에서
같이 게임을 진행한다고 봅시다.
편의상 3 대의 컴퓨터가 모두 동시에 게임을 시작했다고 가정해보죠
컴퓨터 A, B, C 가 있다고 할때, 컴퓨터 A 에는 로컬 플레이어 A 와 리모트
플레이어 B, C 가 있고, 컴퓨터 B 에는 로컬 플레이어 B 와 리모트 A, C
컴퓨터 C 에는 로컬 C 와 리모트 A, B 가 있겠죠
예를 들어서 조이패드를 사용하는 게임이라고 치면, 컴퓨터 A 에서 볼때에는
조이패드가 플레이어 A 를 조작하고, 플레이어 B, C 는 네트워크를 통해서
연결된 가상적인 장치 (NetPad 라고 부르겠습니다) 가 조작을 하게 됩니다.
컴퓨터 A 에서의 네트패드 B 는 실제 컴퓨터 B 에서의 조이패드 1 번이 되고
컴퓨터 A 에서의 네트패드 C 는 실제 컴퓨터 C 에서의 조이패드 1 번이 되고
그런겁니다.
이렇게 처리를 한다고 하면, 매 프레임마다

각각의 컴퓨터는 자신의 실제
디바이스 (조이패드 1, 키보드 등) 의 정보를 입력받아서 로컬 플레이어
에게 정보를 전해주는 동시에 다른 클라이언트의 네트패드에게 똑같은
정보를 전달합니다 (버튼 눌린 상태, 스틱의 방향등), 한편 자신의 네트패드
는 각각 자신의 앞으로 전달된 메시지를 체크해서 똑같이 상태를 만들어놓는
것입니다.
이렇게 하면 최소한의 데이타 전달만으로 대부분의 게임을 진행할 수 있습니다
대신 모든 컴퓨터는 데이타를 똑같이 맞춰줘야 하므로 난수발생이라던가 하는
요소의 사용에는 제약이 따릅니다.
하지만 실제로 이렇게 게임을 만들고 나면, 아무리 빠른 10MBps 급의 IPX/SPX
네트워크를 사용하더라도, 조금씩 진행에 차이가 생기기 마련입니다.
이것을 해결하기 위해서는 직접 게임 내의 개체마다 동기화를 시켜줘야만 합니다
물론 동기화를 할때에는 실제 메모리에 저장된 모든 속성값 (좌표, 속도, 에너지등)
을 전해주어야만 하겠죠. 이러한 동기화는 매프레임마다 할 수가 없으므로
100 프레임마다 한번씩 동기화를 모든 오브젝트마다 한다던가 하는 식의 분산을
해야하지만, 이럴 경우에는 일정 간격마다 속도가 느려지므로 좋은 대안이 아니고
꾸준히 네트웍의 전체적인 속도를 저하시키지 않을 범위 내에서 점진적으로
동기화를 시켜줘야겠죠.
예를 들어서 현재 게임상에 존재하는 오브젝트가 200 개이고, 한꺼번에 동기화
시켜도 무리가없는 오브젝트의 갯수는 5 개까지이다. 라고 하면
첫번째 프레임에는 네트패드의 데이타 +

 동기화 데이타 0 번부터 4 번까지,
두번째 프레임에는 네트패드의 데이타 + 동기화 데이타 5 번부터 9 번까지
이런 식으로 점진적으로 맞춰주면 안정적인 효율을 얻을 수 있을 것입니다.
하지만 이렇게 하기 위해서는 각각의 오브젝트마다 네트웍상에서 고유한
ID 를 지녀야 하므로 좀 더 치밀한 객체지향적 설계가 필요할 것입니다.
이상의 글이 네트웍 게임을 설계하시는 분들께 도움이 되었기를 바랍니다
학규
neolith

우선,게임의 성질을 분석해보세요. 속도가 중요한가 정확성이 중요한가를 말입니다.
 그리고,2명 정도라면.. 한쪽이 호스트가 되어서 게임을 진행시키고, 나머지는 그냥
  터미널 역할을 하기만 해도 충분히 떡을 칠수 있겠네요.
 제가 그냥 짐작하기에는,테트리스같은 비교적 '느린'게임은 속도보다 정확한게 우선
 일 것 같습니다. 그러니까, confirm되면 다음 프레임으로 넘어가는 형식이 더 나을
 듯 싶네요.
                                        막걸리

멀티 쓰레드의 특징
멀티 유저용 게임을 제작할시에 서버 프로그래밍시에 시스템의 사양이
딸린다고 생각이 들때 멀티 스레드를 NT용 환경에서 돌리게 되면 매우
높은 퍼포먼스를 얻을수 있을 겁니다.
듀얼 CPU를 쓴 시스템에 NT를 깔아서 쓴다고 가정했을때 그냥 싱글스레드로
프로그래밍을 한 서버의 경우 두개의 CPU를 쓰지 않습니다.
멀티 스레드로 프로그래밍된 서버를 돌릴경우는 CPU를 많이 꼽을수록
훨신 안정되게 돌아 갈것입니다.
그리고 유저 한명당 한개의 스레드를 가지게 해서 한사람의 벅이 날경우라도
시스템이 다운되지도 않을 것이고요.
문제는 멀티 스레드 방식으로 프로그래밍을 할경우 많은 주의 사항이 필요로
하며 싱글로 짜던 방식에서 탈피할려면 좀 고생을 해야 겠지요.

팁
인터넷에서 인기리에 운영중인 게임인 서브스페이스의 경우 입니다.
보통 이런 리얼타임 액션용 통신 게임에서는 서버가 죽는게 거의
밥먹듯이 이뤄집니다.
이유야 여러가지 겠지만 암튼 무진장 잘 죽습니다.
그런데 이게임을 해보신 분들도 아시겠지만 게임이 중단이 되도
체팅은 돌아가는 것을 볼수가 있습니다.
한시스템에 체팅서버와 게임서버가 분리 되어 있거나 아니면 IP어드레스를 따로두어
포트를 두개 이상 관리한다는 예기가 되겠지요.
보통 체팅용 스트링을 길이 만큼 그대로 보내기 때문에 어떤 게임에서는
게임의 진행이 잠깐 느려질수도 있지만 게임서버가 다운시에 여러사람이
바로 통신을 할 수 있다는 장점이 있고요..
인터넷 상에서만 가능한 예기가 될겁니다. 손서호  (mouse   )

서버를 설계할시에 분할로 잘만 설계를 한다면 얼마든지 많은 인원이 접속할
수있는 온라인 게임을 만들수 있다고 봅니다.
물론 퀘이크 와 같은 게임을 여러 서버로 돌린다는 것은 논리상 어렵다고
생각이 드네요.
그래도 울티마 온라인 같은 서버를 만드는것은 시스템 설계만 잘 할 수
있다면 충분히 가능한 예기라고 생각이 듭니다.
음..
전에 울티마 온라인을 국내에 수입을 생각한 분이 계신다고 예기를 들었는데요  
제생각으로는 좀 어렵다라는 결론이 나오는데요.
문제는 한두대가 아닌 시스템을 가져 오는 것이고 그것을 관리 할수 있는
필요 인원이한둘이 아닐텐데..
아니면 오리진에서 국내 울티마 온라인 유져가 무척많다면 국내에 서버를 두고
자체내에서 미국에서 원격 컨트롤로 운영이 강능할지도 모르겠네요.
음.. 아니면 미국과 한국과의 통신 선로도 요즘은 T3(45Mbps)로 높아지고
있으니 별로 필요가 없을수도 있겠고요.  
음.. 한글화 작업이 필요 할 수도 있겠지만 현실적으로는 좀 문제가 많은듯
하고요..
이상 잡담입니다. 손서호  (mouse   )

저도 아직은 확실한 멀티 유저용 게임을 만들어 본적이 없는 상황이지만
이곳회사에 있으면서 여러 멀티유저용 게임을 만드는 회사들의 경우를
예기하는 것입니다.
음.. 우선 사용자의수(동시접속자의 사용자를 말함)가 1000명이든 100명이든
그문제를 떠나서 시스템과 서비스를 목적으로하는 전용선의 속도를 고려
하는 것이 좋습니다.
보통은 동시사용자수 100명미만이고 속도를 그리 많이 요구하지 않는
멀티유저 그래픽 머드의 경우는 1개의 시스템(팬티엄 프로정도)에서도
무리 없이 동작을 하는 경우를 봤습니다.
물론 이것은 서비스를 들어가는 피시통신 업체나 아니면 인터넷상의
서비스를 제공하는 ISP에 연결된 전용선의 속도를 감안해 봐야 하는
문제입니다.
그리고 보통 이런 게임에서는 사용자의 케릭터 뿐만 아니라 시스템이
움직여주는 케릭터도 포함 되어 있기 때문에 이숫자 역시 고려 해 봐야
할 사항입니다.
제가 말씀드리고 싶은것은 바로 멀티 서버를 만들어서 서비스를 들어
가는 것보다는 멀티 서버를 구축 할 수 있게 서버프로그래밍을 한후에
상황을 고려해서 늘려 나가는 것이 좋을 듯합니다.
아니면 아주 히트를 칠 경우를 대비해서 멀티서버를 구형하고 시스템을
늘려두는 것도 하나의 방편이 되겠지만 나중에 손해보면 안되니까요.
음.. 그리고 시스템이 움직여주는 케릭터가 많다면 케릭터를 움직여주는
서버를 따로 구축하는 방법도 있습니다.
그리고 많은 데이타베이스를 요구하는 게임(전략류)의

게임의 경우 는
DB를 처리해준느 서버를 따로 구축을 하는 편이 좋겠죠.
뭐.. 뻔한 말인지도 모르지만 게임이 어떤 형식이냐가 멀티서버로
구축을 할것인지 아닐지를 결정하는 요인이 될것입니다.
음.. 멀티 서버로 모든 프로그램을 구현한뒤에 나중에 사용자 수가
많아지고 하나의 시스템에서 여러개의 서버가 돌아가지 못할 경우
이때가서 시스템을 늘려주는 방법도 있습니다.
한개의 시스템에서 여러종류의 서버를 띄울수도 있으니까요. 손서호  (mouse   )

네트웍게임 제작시 고려사항
 제가 얼마전 자바로 네트웍 게임을 만들었습니다.
 아케이드형 슈팅게임을 네트워크로 만들었는데,
 생각보다 느리게 동작했습니다.
 어째거나 네트워크 게임을 제작시 고려할 것중 하나는
 네트워크 트래픽을 가능하면 줄이는 것입니다.
 일반LAN속도는 10Mbps입니다. 엄청난 속도지만, 실제로 여러컴퓨터가
 하나의 자원을 공유하므로 10대라면 1Mbps정도 됩니다.. 슈팅게임 같은
 경우 총알 하나 하나가 이벤트로 여기저기에 데이터를 쏟아 내야 합니다.
 동일네트워크가 아닌 인터넷상에서 이러한 각종 데이터를 보내려면 속도
 문제가 생각보다 심각하게 됩니다. 동일 네트워크에서는 브로드캐스팅을
 해서 받는 방법을 쓰면 됩니다(하지만 자바에서는 이를 어떻게 하는 건지
 몰라 일일이 각 플레이어의 주소를 대입해서 여러번 전송했죠)
 그래서, 결론적으로 자기가 원하는 데이터를 교환하고, 충분히 속도를
 내려면, 데이터의 축소와 플레이어 및 아이템등의 제한이 필요하게 됩
 니다. 오가는 데이터 량을 잘 계산하시기 바랍니다.   
 참고로 LAN에서 UDP로 한번 보낼때
 Ethernet헤더 및 테일러가 18바이트,
 IP헤더가 20바이트,
 UDP헤더가 8바이트입니다.
 즉 기본적으로 46바이트, 즉 366비트가 소요되죠.
 참고하시길...고석갑  (sukgab  )

 멀티 쓰레드가 아닌 단일 쓰레드에서는 주의해야 할 점이 한 클라이언트가 벅나면
 서버작동 자체가 모두 중단되버린다는 겁니다... 때문에 이중삼중 방어책을 세워
 놔야 합니다.. 배열에 접근할때도 맞는 인덱스값인지 일일이 확인해서 Access
 Violation을 막아야 하죠... 또한 엉뚱한 데이터라면 칼같이 무시해 버려야
 하구요... 소켓은 당연히 항상 논블록킹상태로 접근해야 하죠... 한
 클라이언트로부터 데이터가 안왔다고 블록킹 상태로 기다리다간 스톱해 버리는
 거죠... 아무튼 아바돈 서버는 아직 테스트 중이라서... 아직까진 문제 없는데
 사용자가 한 5~60명 이상되면 어찌될지 모르겠어요...
 
 그러나 단일 쓰레드는 멀티쓰레드에 비해 장점도 있습니다. 즉 멀티쓰레드의 경우  
소켓의 공유문제가 엄청난 골치거리중에 하나같은데 단일쓰레드에서는 이런 문제가
 없죠. 또한 임계영역이나 뮤택스니 뭐니 하는 것들 처리하느라 처리속도가 느려지는
 일이 없죠. 또 아무리 멀티 CPU의 시스템이라 해도 쓰레드 많이 띄우면 버벅대는
 것은 어쩔수 없더군요.
  때문에 클라이언트로부터 메시지가 도착하면 그에 해당하는 처리를 되도록
 빠른시간동안에 오동작 없이 할 수 있다면 단일 쓰레드라고 해도 문제될 것은 별로
 없어 보입니다.(아직까지는...)
 
 그리고 아바돈 서버/클라이언트의 메시지 통신 구조는 대강 이런데요...
 
 클라이언트에서 한칸 옆으로 움직이겠다고 마우스 명령 입력을 받으면 캐릭터가

 옆칸으로 이동하기 시작하며 동시에 서버에 이동명령을 날립니다. 그러면 서버가
 그 메시지를 받고 이 클라이언트가 옆으로 이동할 수 있는지의 여부를 판단해서
 가능하면 OK, 다른 플레이어가 이미 그 자리에 있거나 못가는 곳이면 Reject
 메시지를 응답해 줍니다. 그 동안 클라이언트는 이동하는 애니매이션을 보여주는
거죠. 그리고 서버로부터 응답이 와야만 다음 메시지를 또 보낼 수 있습니다. 즉
 이동 애니메이션이 이루어지는 동안 서버로부터 응답이 오면 연속적인 동작이
 가능한 것이고, 네트웍 속도가 느려서 응답이 느려지면 랙이 걸리는 듯 멈추는
 거죠. 이렇게 서버로부터 응답이 와야 다음 명령을 내릴수 있게 한 것은 당연히
 동기화를 맞추기 위함이죠. 그리고 몹들의 움직임은 타이머 메시지를 주기적으로
 받아 그때 활성화 되어 있는 몹들을 처리하면서 인접한 클라이언트들에게 몹의 동작
 메시지를 발송해 줍니다.
 
 이상 참고가 되었으면 좋겠네...   고광현  (Soph    )

Winsock.dll에서 몇개까지의 소캣을 제공하는지 혹시 아시나요?
NT에서는 100개 이상의 소켓 가볍게 열리는 군요. 역시 95의 자원관련 문제
였던것 같습니다. 다만 winsock.h에는 디폴트로 64개의 소켓만 가능하게 정의 되어
있으니 #define FD_SETSIZE 250 이런식으로 winsock.h를 인클루드 하기 전에 미리
정의를 해야 겠죠. 이런 문제로 또 고생하는 사람이 없었으면 좋겠군요.
고광현  (Soph    )  


MFC 소켓 성능 경험담
음... 저도 초보라서 잘은 모르지만요...  MFC의 CAsyncSocket 클래스가 아마
윈속 함수의 WSAAsyncSelect()라는 걸 쓰는데요, 이게 윈속 DLL로부터 메시지를 받아
아 해당 메시지에 따른 처리(On Receive 같은)를 해 주는 것 같더군요.
즉 윈속 DLL으로부터 떠있는 각 소켓마다의 멀티쓰레드(비블록킹 모드니깐요)에서
이벤트 발생시 첫번째로 윈도우즈 메시지를 날리고 그걸 받아서 두번째로 해당
함수를 콜하고, 거기서 보통 예제들 보면 mDoc->OnReceiveSocket()뭐 이런식으로
처리를 하거나 아니면 또다시 OnReceive에서 메인 윈도우로 사용자 정의 메시지를  
날려서 처리하죠. 이러한 메시지 패싱의 프로세스가 상당히 시간의 지연현상을
발생시키는 듯한 느낌입니다!!!(어디까지나 개인적 추측)
게다가 도큐먼트-뷰구조, 클래스라는 특성이 속도저하를 또 가져올테고...
CSocket을 사용한 MFC예제 Chatsvr라고 있쟎아요? 그걸 한번 Auto-Chat모드로
돌려봤더니 전 느리다고 느껴지더군요.
그래서 SDK를 사용해서 소켓마다 블로킹 모드로 각가 쓰레드를 띄우고 Recv()하면
데이터가 날라올때까지 그냥 멈춘상태에서 기다리게 만들었습니다. 제 생각에 이러
한 멀티쓰레드 구조는 데이타를 받았을때 MFC의 경우처럼 윈도우즈 메시지를 발생
시킬 필요가 없기 때문에 조금은 효율적이라 생각되고 또 실행결과 좀 빠르더군요.
그러나 이경우도 문제는 있씁니다! 윈도우 소켓이 96개정도 이상은 생성

이 안되는
것입니다! 지금 이것땜에 골머리를 앓고 있는데요... 혹시 윈속에서 100개 이상의
소켓을 만드는 법 아시는 분 안계십니까?
아마 MFC로 해도 소켓을 100개 이상 만들기는 어려운 것으로 알고 있씁니다만...
리눅스로 하면 좋을지...  
어쨌거나 SDK로 소켓함수를 쓰는것이 MFC 소켓클래스 보다는 빠릅니다.
MFC로 프로그램을 만드시더라도 소켓관련 함수는 SDK용 API를 쓰시는 것이 나을
거라고 생각합니다.고광현  (Soph    )  
www.codeguru.com왈. 'api socket보다 1000배 느리다.'
inside visual c++5왈. 'win32비동기 소켓가지고 완전히 win16동기 소켓+윈도메시지
처리기다'
그러므로 느리다..이거더군요. 쓰기 편하다는 장점외에는 기능적으로
단점뿐이라는데.
1000배정도라니 말 다했죠.
그냥 참고하세요.        막걸리     

[참고] 머그겜 제작에 대해서

머그겜은 이런식으로 짜야한다는 기본 형식이 공개된 것이 거의 없기 때문에
 누구한명 섣불리 어떤 방법론을 제시한다는 것은 매우 조심스러운 일이죠.
 또한 네트웍이라는 근본적인 불안정성을 끼고 들어가는(네트웍은 어떤 식으로든
 벼라 별 상황이 다생기죠) 부분이라 프로그램 로직만으로도 다 설명이 안되고...
 
 아무튼 아는데까지만 설명하자면요...
 
 클라이언트마다 하나씩 쓰레드를 띄우는 방법은 쓰레드의 달인이라면 몰라도 저같은
 평범한 프로그래머에게는 매우 구현하기 힘들더군요. 일단 쓰레드로 돌면
 클라이언트간의 동시에 행동할 경우 이리저리 엉킬 가능성이 높죠. 한 클라이언트의
 쓰레드가 벅나도 걔만 죽여버리면 될지도 모르지만, 어찌어찌했든 로직상의 버그로
 쓰레드가 벅나는 상황이 있다면 서버작동후 얼마지나지 않아 모든 쓰레드가 벅날 수
 도 있다는 말이므로 별 의미가 없는 것 같더군요.
 즉 쓰레드로 돌리든 단일 루프로 돌든 서버쪽은 절대로 시스템 장애로 이어지는 벅
에 대한 만반의 대비를 해야 한다는 말이죠.
 전 메시지 루프를 돌면서 클라이언트로부터 요청이 있을때 그때그때 응답해주는
 방식을 씁니다. 제 예상으로는 이 방식으로 한 서버에서 한 1~200명정도는 처리
 가 가능할 것 같습니다(순전히 생각). 대신에 멀티서버를 구현해서 맵별로 사용자
 를 분산시킵니다.
 클라이언트는 서버로의 응답이 없더라도 어느정도 수준까지는 랙이 없는 것처럼
 사용자를 속여(?)야 합니다. 이런 기법의 극치는 '리니지'가 아닐까 하는데요, T1급
 라인 3개로 1000명이 넘는 사용자가 그럭저럭 잘 움직이는 것처럼 보이는 것을 보면
 참 대단하다는 생각밖에는 안들더군요. 그렇기에 동기화가 안맞지만...
이거 너무 뻔한 말만 쓰고... 그럼 이만

제 경험에 의하면 논블럭킹으로 만드는 것이 안정적입니다. 블록킹은 연결이 빨리
 된다면야 좋겠지만 만약 부하상황이 발생하여 Connect시간이 오래걸린다거나, 아예
 서버가 작동안된 상태라면 블록킹은 장시간을 프로그램 진행이 멈춘채로 대기하기
 때문에 사용자 입장에서는 매우 짜증나게 됩니다.
 
 이게 제가 첨에 만들었던 아바돈이 블록킹으로 서버접속을 하는 바람에 엄청 욕을
 먹었었죠. 어지간하면 논블럭킹으로 만드세요. 블록킹보다는 좀 복잡하지만 나중을
 생각하면 많이 도움이 될 겁니다.  

 

  유닉스 서버 프로그래밍시 공부해야 할것들.
 
 1. Socket : 유닉스에서도 소켓 기반으로 해야하구요. TCP/UDP 모두
             지원 합니다.
 2. IPC : Inter Process Communication의 약자로 유닉스 프로세스간에
          메시지를 전달할때 사용 됩니다. 사용법이 쉽고 강력하져.
 3. Signal : 윈도의 이벤트를 연상하시면 되고요. 이벤트 보다
             쓰기가 까다롭습니다.
 4. RPC : Remote Procedure Call 의 약자로 원격지의 프로세스에
          접근하기 위한 프로토콜(라이브러리)죠.
 5. 공유메모리 : 유닉스에서 프로세스간에 같이  쓸 수 있는 공유 메모리죠.
          뭐 윈도도 비슷한 개념이 있지만.
 6. Thread : 말그대로 쓰레드 입니다. 프로세스 내부의 독립적인 시퀀스.
 
 유닉스상에서 서버는 유저하나당 하나의 프로세스를 가지게 하는   

것이 가장 안정적입니다. 리눅스는 커널 컴파일시 최대 프로세스 갯수를
 정해 줄 수 있는데 4096개 까지 만들 수 있습니다.(커널 버전 2.1부터)
 전통적인 방법에 따르면 Socket으로 클라이언트 받고 프로세스 열어서
 IPC랑 시그널로 통신을 하는 거죠.
 이렇게 프로세스 단위로 쪼개주면 나중에 분산 시킬때도 편하게 됩니다.
 프로세스 단위로 분산해주면 되기 때문에.
 저도 지금 공부하고 있고요. 서버 설계 단계라서 자세한건 설계가 나오면
 게시판에 올려 보지요. 요즘은 테스트프로그램 짜서 테스트만 하고 있습니다.
 프로세스는 몇개까지 띄울 수 있나? IPC서버는 몇개 까지 버틸까?
 프로세스 단위로 띄워서 서버가 얼마까지 버티는가?
 그런것 들이죠.. 쓰레드는 유닉스 상에서 한개의 프로세스가 띄울 수 있는
 한계가 존재 합니다. 따라서 요즘 나오는 유닉스용 서버들을 보면 쓰레드와
 프로세스를 같이 쓰고 있지요.
 흑~