역사적으로 볼때.. 어험 어험.. 욱, 캘록 캘록! -_-; 속도의 보틀넥,그러니까
게임이
빠르고 느리고를 결정하는 관건은 이랬던 것 같네요.
8086,80286이 있던 시절.. 얼마나 스프라이트를 조금 그리고 빨리 그리냐,게임
진행
을빠르게 처리하느냐.. 그래서 풀어셈으로 짜는건 기본이었죠.
80386,80486이 있던 시절.. 이때는 제가 고2-3 독수리 수험생이었기에 잘 모르겠군요
Pentium이 처음 나온 시절.. 얼마나 텍스처를 빨리 그리냐,그래서 텍스처
그리는
부분과 기하학 연산만큼은 어셈이 계속 등장했죠.
요새.. 얼마나 가속 보드를 잘 타냐(맞는진 모르겠군요. 요새는 3D 프로그래밍에
손
을안대니.. -_-;) 어셈은 단 한줄도 안들어가는 것 같더군요.
그런데,게임 서버에 대해서는 이런 보틀넥이 어디에 있는지에 대해서는,
사실 저도
아리송하답니다. 아직까지 커다란 서버 돌려가면서 그게 어디서 벅벅대는지
조차
알아보지 못했기 때문이죠. 다른 분들은 어떻게 생각하시는지 궁금하네요.
..제가 짐작하기에는,네트워크 선을 얼마나 빠른걸 끌어왔느냐가 결정할
것 같네요.
예전에는 CPU도 상당히 먹는걸로 기억했는데,막상 다른 분들 얘기를
보니까 꼭
그런것 같지는 않군요. 그건 저도 마찬가지이지만요. 정작 많이 먹는건 네트워크가
아니라 서버에서의 게임 진행을 위한 여러가지 숫자 계산이더군요.
제가 만드는 서버에서 보니 accept() 할때 은.근.히 많은 시간이 걸리더군요.
그래서 접속 받는 처리는 다른 스레드에서 처리했습니다.
그리고 NPC 인공지능 처리중 길찾기 부분에서도 많은 부하가 걸리구요.
흐흐..--;
네트워크 속도에 관련된 병목현상은, 한번에 보내는 패킷
데이터의 양을 작고
다발적이기 보다는 양은 크고 보내는 횟수는 적게 해서
최대한 줄이는 쪽으로
해봐야겠죠.
그리고 서버의 컴퓨터 스펙 성능에 의존한 쓰레드 형식의
프로그램 보다는,
쓰레드 본연의 장점을 최대한 활용하는 쪽으로 해야겠지요.
접속한 사용자
하나하나마다 쓰레드를 만들었다면, 동기화 하는 부분에서도
세세한 처리를
해주어야 하고, 메세지 큐 처리도 조금이라도 늦으면 안되는
형태의 게임의
경우에는 동기화 노가다가 장난이 아니겠지요. -_-; 헐헐.
클라이언트와 클라이언트 간의 통신이 번개처럼 이루어질
필요가 없다면야,
쓰레드로 몽땅 만들어서 처리하는 방식도 아주 괜찮겠지만요.
흠..
전 거의 완전히 다른 부분의 일을 하는 각각의 쓰레드로
나눕니다만,
이렇게 하면 어떤 부분이 부하가 얼마나 걸리고 이 부분은
얼마나 복잡한
짓을 해도 유연하게 돌아가겠다 하고 예상이 될 거라 봅니다.
몽챵 쓰레드(?) 서버에서는 약간만 더 고생하면 알아낼
수 있겠지요.
결국, 이도 저도 아닌 미지근한 글이 되버렸군요. 하하.
-비엽
요즘 요 게시판에 재밌는 이야기거리가 올라오고있는데,,
한참 재밌게 보고있는 한 개발자입니다...
보다가 아는건 별루 없지만,,그냥 써봅니다.
우선,,대부분의 분들이 소프트웨어적으로만 병목현상을 해결하시려하지만
좀 넓게 봤으면 좋겠네여..아는게 없어서 자세히는 말할수는 없지만..
게임의형태(동시사용자수,초당 전송량,게임 방식)에 따라서 많이 틀려지겠지만,
OS의 선택,,
프로토콜의 선택,,
전용선 회사 선택,,
그다음..프로그래밍 모델 선택(멀티쓰레드냐,,이벤트 방식이냐.
이벤트 방식이면 NT로 한정된다고봐야하겠죠??)
그리고,,,
전체적인 NMS..(이게 모의 약자였더라..네트워킹 매니지먼트 시스템의 약자
였던가 그럴꺼예여..)
암튼,효과적인 네트워킹 환경 관리 시스템 구축이 요소가 될것같습니다.
OS야 대부분..NT를 쓰시던데,,저는 개인적으로 Unix(또는 Linux..그게 그거니까.모)
쪽을 선호합니다.비록 Unix를 별루 사용하지 않았음에도 불구하구요..
Unix와 NT로 작업했던적이 있는데 여러가지면에서 저는 Unix가 좋더군요..
프로토콜이야 선의 용량이 커짐에 따라 거의 TCP로 굳혀지고 있으니...흐:)
전용선 회사...이것두차이가 클겁니다.. 저는 개인적으로 데이컴쪽을
선호합니다만...암튼 이것두 서비스대상지역이나 그런것에 차이가 있지않을까
싶어요...(이건 추측입니다...실제적인 분석자료는 없지요)
프로그래밍 모델은..지금 게시판 보면..멀티쓰레드 ,이벤트 방식
각각의 장단점에 대해 거론되고 있는데,,,이것두 게임의 형태에
맞춰줘야하겠지만,,저는 멀티쓰레드 방식을 선호합니다.
왜냐면...앞으로도 개선의 여지가 많이 남아있는부분이 멀티쓰레드
일테니까요(물론.이건 OS만드는데서 하겠죠....)
멀티스레드중에서도 여러가지 모델이 있는걸로 알고있습니다.
보스워커 방식이라던지,워크 크루라던지,,파이프라인닝..등이 있던가요..
앗,,그러고보니 이 각각에 대한 특징을 까먹었네여..
보스워커는 하나의 메인 스레드에서 다수의 스레드를 발생하는식이던가
대부분이 이 모델을 사용할거예여..아마두...
워크 크루는 각각의 할일을 정해서(배에서의 선원처럼요) 각자 하는..
방식인것 같구...파이프 라이닝은...자동차 생산 라인위의 각 일꾼내지
로보트에 비유할수있던것 같아요....아...벌써부터 기억력이 가물가물해져서야..
쩝.암튼..이런것도 염두해두고 사용하면.도움이 될것 같다고 생각됩니다...
가령 동기화 방식이라던가..영역 설정등에 크게 도움이 될것 같다고 생각되네여..
하지만,,아무리 멀티스레드라도 무식한 동기화 기법이 쓰인다면..할말없을것
같아여^^
서버 시스템만 좋다면...스레드를 남발하는게 더 좋지 않을까합니다...히히
전..전문가가 아니니까.무시하셔도 될것 같아여...나하하하..
그리고는 NMS인데,,
이게 우리나라에서는 제일 등한시되고 있는것 같아여...
NMS는 제가 알기로는 네트워크에 문제가 생겼을때 그 문제를 처리하는 방식이라던가
그런걸 관리해주는 시스템일거예여...이러한것 외에도..
서버의 분할이라던가...(보통 DB서버와 게임 서버 로비서버는 분리하죠??)
그리고,,물리적인 장치들의 세팅(라우터라던가..등등등...)
아..~ 마지막으로 생각난건데,,,
애시당초 네트워크 환경에 알맞는 게임의 기획이 제일 중요한것 같아요..
현재 네트워크 환경의 한계와 특징을 잘 파악하고서, 이러한 요소를
커버해줄수 있는 요소를 게임에 넣는것이지요...서브스페이스에서는
관성을~,,,스타크래프트같은것들은 유저의 커맨드에 의한 게임 정보변경이라던지..
이런 인터페이스.......
쓰다보니 길어졌는데,,,....
암튼,하루빨리 게임 제작의 강국 '한국'이 됐음 좋겠네여.
카카카카.
별루,내용도 없는글 끝까지 읽어주셔서 감사합니다...
네트워크를 통해 크기가 작은 패킷을 자주 보내야 할 입장입니다.
생각에 헤더를 제외하고 약 20~300 바이트 정도씩 되는 것 같습니다.
제가 알고 있기론 작은 패킷을 너무 자주 보내는 것은 효율이 떨어지는
것으로 알고 있습니다. 오버헤드가 너무 크니까요. 하지만 다른 방법은 모르겠군요.
시간에 대해 크리티컬하니까.. 어느정도는..
방법이 있을까요?
얼마나 자주 보내셔야 하시는지요?
왜 자주 보내셔야 하는지요?
헉.질문글 보다가 저두 의문사항이 생겨
질문해봅니다
작은패킷(20~300바이츠)을 자주보내면..
오버헤드가 있어서 효율이 떨어진다고 하셨는데,,
무슨 오버헤드인지 모르겠어요..
만약,,,tcp/ip프로토콜 헤더라면, tcp/ip의 경우 헤더압축이 되면
거의 2x바이트인걸로 아는데,,,아닌가?...
아니면.다른 오버헤드가 있는건가요?? 매우 궁금....
------------------------ 그리고 763에 대한 저의 생각 ------------------
그리고,,,만약 패킷이 너무 작다고 생각되면
버퍼를 하나 만들어서 버퍼에 차면 걍 보내는 방법이 있지 않을까싶은데,,,
중요한 패킷이면 걍 flush 기능을 하는 펑션만들어서 쓰면되고...
----------------------------------------------------------------
아구궁.. 두분 먼저 감사드리구여.. 읽어주셔서..
글구 써주셔서.. ^^;
제가 생각하기로 20바이트의 tcp/ip 헤더에 비해
20바이트의 데이타라면 실제 전송량의 50%가 헤더 잖아여.
그러니까 오버헤드가 큰거죠.
제가 알기로 20바이트 2번 보내는 거랑.
50바이트 한번 보내는 거..
둘중에 당연히 50바이트 한번 보내는 것이 빠르지요.
하지만, 제가 생각하는 데이터는 게임에 관한 것이라..
사실 매우 시간에 크리티컬하지는 않지만..
어느 정도는 크리티컬하다고 생각하기때문에..
어쩔수없이.. 작은 패킷을 여러번 보내는 수밖에
없을 것 같군요.
일반적으로 네트워크 회선이 상당히 빠르다고 가정하면.
일반적인 NIC 에서 초당 얼만큼의 패킷을 보낼 수 있는지.
이것이 문제이군요... 쩝.
100MBPS의 NIC 라면 좀 보낼 수 있는 양은 큰건가??
쩝.. 아직도 헤매는 군요.
글구 한가지 의문이 있어여..
공용체(유니온)에 관한건데..
공용체의 멤버로 객체를 쓸 수 없나요??
될 것도 같은 데.. 복사 생성자 어쩌구 에러가 나는군요..
아시는 분은 갈켜주세여~~
그럼 이만!
아~~ 아래 비엽님 질문에 대답을 제대루 못한 거 같아서여~
(쓰고 나니까... 이상하다... )
(왜냐! 질문에 대한 질문들이라서... ^^;)
아직 얼마나 많은 수의 패킷을 보내야 하는 지는 정확히
산출해 보지 못했습니다.. 그렇지만 어림짐작으로 무척 많을듯..
그리고 패킷의 실제 데이터 크기는 다양하지만..
보통 20~300 바이트 정도 수준입니다.
가장 큰 것은 약 1킬로바이트 정도 이구요.
젤 작은 것은..... 6바이트 정도...
큰 것을 보내는 빈도는 적은 편이고, 주로 작은 패킷을 보내게 됩니다.
이상 질문의 질문에 대한 대답이었읍니다... -__-;;
winsock의 경우에는 TCP_NODELAY옵션이 걸리지 않는 한 네트웍 사정에 따라 작은
패킷이 한꺼번에 뭉쳐서 전송되기도 한다고 알고 있습니다.
다만 이러한 사이즈를 소프트웨어적으로 계산하여 적정 수준에서 전송을 한다는
소리도 들은 적이 있는데 잘은 모르겠군요.
헬브레스의 경우에는 전송단위가 6바이트, 9바이트에서부터 3~40바이트,
100~1000바이트 등등 다양한데 별 생각 없이 그냥 전송하고 있습니다.
트래픽 검사 프로그램.
트래픽 검사 프로그램은 라우터에 직접연결해서 검사하는 방법도 있고
찾아보면 다양하게 있습니다.
저희 회사에서 쓰는건 MRTG라는 프로그램인데.
설치하면 웹으로 해당 라우터의 평균 트래픽을 얻어 오네요..
(5분에 한번씩..)
http://ee-staff.ethz.ch/~oetiker/ 에 가면 얻어 올 수 있습니다.
유닉스 NT용 다 있습니다.
몇 Kbps단위로 나오더군요..
input와 output 트래픽으로 나눠서 나옵니다.
그럼.
fROM PSYCHO
PS. 제이름은 이경만 입니다. 흑흑.