서버를 만들어서 돌리다 보면 클라이언트 측은 이미 끊어졌는데
서버에서는 연결 해제를 인식 못하는 경우가 종종 있습니다.
예를 들면 네트워크 선을 네트워크 카드에서 뺐을 경우와 같은
현상이죠.
해결책으로 서버와 클라이언트간에 일정 시간 간격마다 통신을
해서 응답이 없으면 연결을 강제적으로 끊는 방식을 취하고 있는데
소켓 레벨에서 이를 인식할 수 있는 방법이 없을까요?
고수님들의 조언 부탁합니다.
안녕하세요..
아버지아뒤를 빌려쓰는 중1 장용석이라구 하는데요..
CSocket를 사용해서, 채팅서버를 제작해보는데,,
다중으로 만들기전, CSocket사용에 능숙해지기 위해서, 간단히 1:1 로 통신을하는
프로그램을 만드는데요,,
음..
우선, 서버소캣을 Server_Socket로 하구요, 클라이언트를 Client_Socket,
첫접속자 소캣을 User_Socket로 이름을 주었죠.
암튼, 이 것들을.. 코딩하면 다음과 같겠죠..
CSocket Server_Socket;
CSocket Client_Socket;
CSocket User_Socket;
이것들을 제가 CChatView(한마디로 뷰에다가)에다가
함수선언하는데다가 선언을 해놓았죠.
그리고, 스레드 이름은..
우선, 서버스레드의 이름은
UINT Server_Thread(LPVOID iParam)
입니다.
서버스레드 시작버튼을 누르면 다음과같은 루틴이 실행되죠..
AfxBeginThread(Server_Thread,this);
Server_Thread의 첫줄입니다.
CChatView *Views=(CChatView *)iParam;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
암튼,, CSocket변수들을 뷰에다가 선언시켰을때,
스래드 내에서 CSocket변수를 사용하려면,
위에 밋줄친 Views에서 사용을 해야겟죠..
그러니까,,
Views->Server_Socket.Create(채널번호);
Views->Server_Socket.Listen();
Views->Server_Socket.Accept(다른소캣)
이런식으로 항상 앞에다가 Views를 붙여서 사용하겟죠..
근데, 정말문제는 이렇게해서 스레드를 기냥 강제로 종료시키면,
종료되고, 윈도우가 사라진 뒤, 런타임에러가 난다는 점입니다.
그래서, 한동안 이문제에 대해서, 생각을 했죠.
그러다가 결국, 스래드내에서, 이 소캣들을 생성하고
종료해봤더느 괜찮더라구요..
런타임 에러가 안나고..
그런데 문제는 스래드내부에서 CSocket변수들을 사용가능할지 몰라도,
다른스레드나 메인 에서는 그 변수를 사용못하더라구요..
그래서, 이 두가지문제를 다 가르쳐주셨으면.. 합니다.
다시정리하자면, 뷰에다가 CSocket선언, 스레드에서 접속, 대기, 크레이트 들을
처리할경우 윈도우종료시 발생하는 런타임오류 해결법.
두번째는 스레드내에서 CSocket선언, 외부나 다른스레드에서 그소캣을 사용하는
방법을... 꼭좀 가르쳐주셨으면 합니다..
그럼..
전 이만..
꼭좀 부탁드립니다.
안녕하세여
병국님께서 오류가 나신다고 하셨는데.. 당연한 겁니다.
다만 쓰레드를 종료시킨다면 문제가 생길 소지가 높지요.
즉, 동기화 문제를 생각해야 합니다.
메인 어플리케이션 쓰레드와 작업 쓰레드가 별도로 독립적인 작업을 한다면야
동기화에 다르는 문제가 적겠지만.
소켓에 관한 일을 쓰레드로 나눠서 하는 것은 안정적이지 못합니다.
(ms에서는 쓰지 말라고 합니다..^^)
결국 한 쓰레드 내에서 소켓 작업을 처리하는 방법을 써야 합니다.
(다른 방법으로도 안정적인지 모르겠군여)
그러니, 멀티 쓰레드 작업은 힘듭니다..ㅜㅜ
저같은 경우테스트로 만들어본 채팅 클라이언트를 멀티 쓰레드를 썼는데.
잘 돌더군요.
그러나, 이 예제를 기능확장을 하려고 하니까 무지 어렵더군요..ㅜㅜ
음.. 저의 경우는 소켓 클래스를 api로 만들었기 때문에..
mfc의 소켓 클래스가 멀티 스레드에 안전한지 장담할 수 없습니다.
결국 스레드 사용을 피하시고요..
만약 쓰시겠다면.. api로 작성하셔서 thread_safe한 클래스를 제작하시기 바랍니다.
안녕하세요? 이홍기입니다.
쩝.. 유닉스에서 소켓프로그래밍을 하고 있습니다만..
쓰레드를 쓰면서 성능을 높이는 방법은 쓰레드풀을 사용하는 방법이라고
생각합니다.
송수신측에 패킷처리하는 입출력 큐를 각각 두고,
입력시에는 read이벤트를 받아서 소켓을 입력측소켓큐에 넣고, 쓰레드풀에서
경쟁하듯가져가서 read를 하는 방법을 쓰고,
출력시에는 출력큐에 처리한 패킷을 집어넣으면 write를 해주는 출력 쓰레드풀
에서 경쟁하듯 가져가면서 처리해주는 방법이 좋은 방법일듯합니다.
튜닝은 물론 쓰레드풀의 쓰레드 개수로 하면 되겠지요.
다만 쓰레드 관리나 메모리침범에 대해서는 처리하기가 만만찮다는 것이
프로그래밍시의 난제라 볼수있겠습니다.
한국과 미국에 서버를 두고,
두 서버에 ISP로부터 온 선을 하나씩 물려서
회선을 모두 서버가 사용하게 된다면..
서버간 평균 전송속도는 얼마정도가 나올까요..?
전송 핑타임 700ms 에 초당 15kb를 예상하고 있습니다만..
혹시 테스트 해보셨거나 관련된것들 아시는분 도움 부탁 드립니다.
- Testors
저기요 제가 서버를 다 만들었거든요.
그런데 키보드 채크 함수가 없어서 ㅠ_ㅠ
개피를 보긴했지만. (도스로 만들었거든요)
윈도로 만들면서 실력이 부쩍 는듯 싶군요 후히히히
그런데요.
제가 알기로.. 서버에 접속하는건.. 자기 서버에 접속이
가능하다고 하더군요 물론 그걸 쓰고 있지만요.
하지만 그걸로는 태스트 할수가 없죠.
그러니까 말인데요.
자신에 서버를 남이 들어오게(저희 집이아닌)하는 방법은
없나요?
저는 두루넷입니다.
빨리 만들어 보고 싶은데.. 걸리는게 좀 많군요..
누가 알았겠습니까 ㅠ_ㅠ 다 만들어 놓고 컴파일 시키는데
kbhit()가 없다니... 그래서 부랴부랴 bioskey(1)로 대치했더니.
어랍셔? 이거 함수가 없군^^
저같은 lcc유저가 별로 없어선가요? 질문란에 질문했더니.
묵살하네요 ㅠ_ㅠ
서버 운영방법과.. 딴곳에서 우리집에 접속하는 방법을 좀
가르쳐 주세요.
그리고 저에게 답변주신분요. 정말 고맙습니다. 정말
gma가 좋아 집니다.^^
그럼 빠이루~~
안녕하세요?
일단 서버는 컴퓨터에서 실행을 시켜야 합니다..
그러고 나서
자신의 IP주소를 알아야 합니다
아는 법은 winipcfg하면 자신의 ip를 알죠
그럼 클라이언트에서 접속하면 됩니다
하지만 컴 한대 갖구도 할수 있습니다
자신의 컴을 가리키는 ip는
127.0.0.1입니다
그럼~
안녕하세요..
항상 이곳 게시판에서 많은 도움을 받는 개제동 회원입니다.
개인적으로 온라인 머그 게임에 많은 관심이 있고 좋아하다
보니 이곳에 자주 들리게 되었습니다.
이번에 컴퓨터가 2대가 생기게 되어서 하나에다는 linux 를
깔고 조그마한 네트웍을 구성하였습니다.
그리고 ADSL을 신청하였더니 고정 IP 도 하나 주더군요.
항상 아주 간단하게라도 온라인 머그를 한번 구현해보고 싶
다는 생각이 간절했기때문에 시스템이 구축됨과 동시에 해보
려고 했는데 너무나도 떨어지는 실력 때문에 이렇게 도움을
외칩니다...많이 도와주세요...
1. fork() 인가 쓰레드인가...
서버에서 클라이언트를 다중으로 받기위해서는 당연히
fork() 를 사용해야 되는것으로 알고 있었는데 게시판을
읽다보니 멀티 쓰레드를 사용하는 방법도 있다고 보았습니다.
어떤분은 fork 를 사용하면 시스템 부화가 크다고도 말씀하
시는데 이 두가지 방법밖에는 없습니까?
그리고 차이점은 뭐가 있는지 알고 싶습니다.
2. PC 와 NPC의 움직임 처리는 쓰레드로? ..설마 Timer?
머그겜을 하다보면 자신의 캐릭터 말구 다른유저의 캐릭터들이
자연스럽게 움직입니다...이것을 구현하려면 쓰레드를 사용해
야 되는것입니까? .. 아니면 현재 접속해 있는 모든 유저만큼
Timer 로 뺑뺑이(?)를 돌려야 하는것입니까?(Client에서)
아니면 패킷에 오는정보대로 그냥 스프라이트 처리만 하는겁니까?
이렇게 두 부분이 무척 궁굼합니다..
fork() 콜이 부하가 걸리는 이유는 간단합니다.
여러 책에 나와있듯이 fork() 는 부모의 거의 모든 정보를 무식하게
복사해서 프로세스를 하나 더 만듭니다.
또한 fork() 콜은 프로세스 간의 통신을 처리하기에 용이하지 못하므로
게임서버와 같이 클라이언트와 클라이언트간의 통신이 매우 잦은 구조에는
적합하지 않다고 할 수 있겠습니다.
만약 부모가 640kb 짜리였다면 그리고 자식을 접속하나하나마다 쑴풍쑴풍
낳는 대단한 부모라면 640kb * 접속자수 = 메모리사용량 이 되겠지요.
그래서 시스템 부하가 심합니다.
안녕하세요...
오랫만에 왔더니 반가운(?) 글이 있군요...
(지금은 아니지만 한 때는 MUD 전공(?) 이었기 땜시~ ^_^)
우선, 1번...
결론부터 말씀 드리면 요즘은 쓰레드를 사용하는 추세입니다.
물론, OS가 무엇인지, 전체 시스템 구조를
어떤 형태로 가지고 갈 것인지에 따라서 다르긴 합니다.
보통 fork()는 권하지 않습니다.
밑에 다른 분도 답변하셨지만 overhead가 너무 큽니다.
쓰레드를 쓰기 어려운 구조거나 시스템에서 뒷받침이 잘 안되면...
clone()을 사용해도 됩니다.
clone()는 메모리 영역은 그대로 사용하면서 텍스트 영역만 하나 더 복사해서
프로세스 단위를 생성시켜 줍니다.
새로 생긴 것인데... 아직 저도 큰 시스템에는 적용해보지 않아서
안정성이나 성능에 대해서는 확신하지 못하겠습니다.
2번...
이 부분은 앞의 1번 구조를 어떻게 하느냐에 따라서 달라집니다.
전체를 one process 구조로 할 경우에는 뺑뺑이를 돌리죠...
이러한 형태는 circle mud에서 찾아 보실 수 있습니다.
(ftp.circlemud.org 에 가시면 source가 있습니다.)
쓰레드로 하면... 아무래도 독립 쓰레드로 돌리는 것이 유리하겠죠...
물론 독립적인 process를 띄울 수도 있습니다.
이 두가지 방법을 사용할 때에는 다른 쓰레드, 또는 process와
동기화를 잘 해야겠죠...
머드는 만드는 사람마다 그 구조가 다릅니다.
어떤 것이 정석이라는 것도 없습니다.
기존에 나와 있는 소스를 참조하시는 것도 좋으리라 생각합니다.
리눅스 동호회나 머드 동호회 가시면 몇 가지 소스가 있고,
인터넷에서 여러가지 소스를 구하실 수 있을 것입니다.
답변이 되었길 바라네요... ^_^
안녕하세요.
Client가 들어왔을 때마다 User thread를 생성해주면서 User가 방을 만들기를
선택하면 서버 내에서 Room thread를 생성한 후 인자로 User들의 정보(리스트)
를 넘겨주려 합니다.
그런데 문제는...Room thread의 기능이 Client들의 메시지를 주고 받고
귓속말, 초대등의 기능인데..이 메시지를 처리하기 위해서 현재 무한루프를
돌고 있다는겁니다. 그래서 중간에 Sleep(500)쯤 주니 부하는 많이 없어졌는데
대신 반응이 느리구요. -.-;;
흠..그래서 다른 해결책으로 아예 room thread를 만들지 않고 무식하게
user마다 room의 기능을 가지고 있는 것으로 짜긴 했는데..역시 찝찝하네요.
그럼 이걸 어떻게 해결할 수 있는지 고수님들의 답변 부탁드립니다.
지금 쓰시고있는 방법은 어떻게 보면 멀티테스킹을 이용한 폴링이라고 보이는
군뇨..
저도 이런 방법을 처음에 써봤는데.. 나중에 바꾸었습니다.
저는 winsock 2.0을 사용해서 해결하는데..
상대방으로부터 메세시가오거나 접속이오면 이벤트를 발생시킬수있습니다
이때 까지 각각의 스레드는 wait하다가 (거의 부하를 안먹는군뇨..)
처리할내용이 오면 그때마다 쓰레드를 가동시킵니다..
그러면 실제 필요할때만 스레드가 움직이므로 부하를 덜먹을수있죠..
사실 지금 제가 쓰는 방법은 체팅에는 안맞을지 모르지만..
(저는 이방법을 액션 게임에서 사용합니다)
TX,RX,ACCEPT 의 세가지의 스레드를 만들고 각각의 유저에게 소켓을
생성합니다..
그리고 각각의 소켓에서 어떤일이 일어날때만 관심을 둔다는 거죠.
그전까지는 wait입니다..
이런 방법으로 한프로그램에서 쓰레드를 10개이상 (소켓,기타 쓰레드)
사용하는데도 그런데로 만족합니다.
다른분들도 이런 방법으로 사용하지 않나 싶습니다..
다른의견있으시면 조언부탁합니다..(초보라..--;)
그럼
일단 윈도우즈 플랫폼을 이용하는 경우로 말씀드립니다.
윈속의 비동기 소켓을 쓰면 간단하게 해결할 수 있습니다.
우선 접속을 받는 부분입니다.
WSAAsyncSelect(m_socketBase,g_hServerMessageWindow,WM_SOCKET_EVENT,FD_ACCEPT);
첫번째 인자는 리슨하고 있는 소켓입니다.두번째는 메시지를 받을 윈도우고
그 다음은 소켓에서 이벤트가 발생했을 경우 발생시킬 메시지, 그 다음 FD_ACCEPT
는 억셉트 메시지가 생긴 경우입니다.
즉 위 라인에선 접속 요청이 있을 경우(FD_ACCEPT) WM_SOCKET_EVENT메시지(이건
제가 임의로 정의한 것입니다.)를 g_hServerMessageWindow를 핸들로 하는 윈도우
로 보냅니다.
그럼 그 윈도우의 프로시져에 WM_SOCKET_EVENT가 날아오고 wparam에는 메시지
가 발생한 소켓 번호가 들어옵니다.
lparam에는 어떤 메시지인지..fd_accept나 fd_read등이 들어오죠.
이 경우 fd_accept가 들어오면 accept를 해주면 됩니다.
억셉트할때도
csock = accept(m_socketBase, (struct sockaddr *)&caddr, &caddr_len);
WSAAsyncSelect(csock,g_hServerMessageWindow,WM_SOCKET_EVENT,FD_ACCEPT
| FD_CONNECT | FD_READ | FD_WRITE | FD_CLOSE);
이렇게 해주면 접속이 이루어진 소켓을 비동기로 돌립니다.
현재 접속을 요청한 클라이언트로부터 발생한 메시지는 g_hServerMessageWindow
로 날아가고 fd_aceept, fd_connect , fd_read, fd_write, fd_close가 발생했
을 경우만 wm_socket_event를 발생시킵니다.
일일히 소켓마다 메시지를 체크할 필요가 없으니 편하고 또 pc에 부하를
거의 주지 않습니다.
제 경우는 모든 소켓은 비동기 소켓으로 쓰고 있고 자체 리시브,샌드 큐때문
에 루프를 사용하고 있는데 루프안에 sleep(10)을 넣어서 10밀리세컨드씩
쉬게 하고 있습니다.일단은 놓치는 메시지 없이 잘 돌아가고 클라이언트,
서버 모두 같은 소스를 쓰는데 98에서 클라이언트,서버 동시에 뛰워놓고
메시지를 매 루프마다 보내는 테스트를 할때 cpu점유율은 10%정도입니다.
도움이 되셨길
일단.. 98에서는 thread띄우면.. 거의 cpu 100%까지 기본으로 올라가더군요..
같은 코드로 NT에서 하면 부드럽게 돌아가죠..
acesaga라는 전략시뮬의 네트웍을 맡고 있는데..
그냥 별생각없이 polling thread 뒀다가.. 98에서 어이없게 느려지는 현상이
일어나서.. 한참을 뒤져보고 알았습니다.
뭐.. 밑에분들이 말씀하신거처럼 select로 폴링하는것도 괜찮은 방법이고요..
thread에 Event를 줘서 Thread를 돌리는것도 좋은 방법입니다.
WaitForSingleObject 나 WaitForMultipleObjects 등으로 이벤트가 없을때는
쓰래드가 자고있다가.. 이벤트 발생시만 움직이면.. 오히려 select보다
부하는 덜 먹죠..
구조가 여의치 않다면.. Thread Priority를 조정하는것도 한 방법입니다.
SetThreadPriority 라는 API를 쓰시면.. 그럭저럭 느슨한 polling을
할수 있을겁니다.. 근데.. 역시 98같은데서는.. 약간 반응이 불규칙적이더군요..
역시.. OS는 NT나 Unix가 깔끔한거 같습니다..
그럼 참고가 되었기를..
안녕하셔요 ..
스타같은 배틀넷 구성을 어떻게 하는것인지 궁금합니다.
다이렉트 플레이를 보믄 로비라는게 있눈데 그러로도 되는지
아님 소켓프로그램이용해서 서버구축해야하는지
그리고 어떤방법이 조은지 조언좀 부탁드려요..
그럼 즐거운 하루되십셔요 꾸벅..
우선, 머그 게임 서버는
말그대로 게임 서버가 되는겁니다.
채팅서버,메일서버같은것들도 특별히 어떤 표준 형식이
있는것은 아니지요. 물론, 그들이 이용하는
프로토콜(프로그램간의 통신 규약이라 생각하시면 됩니다^^)
은 표준인것도 있지만,(POP3, SMTP따위가 그렇죠)
머그 게임 서버를 만들려한다면 해당 게임만의 프로토콜을
정의하신다음 게임 클라이언트와 통신하는 서버를 만들어 주시면
그것이 게임 서버입니다.
그리고,Windows계열이라면 모두 winSock 을 이용하기때문에
네트워크 관련 프로그래밍 방식은 크게 틀려지지 않습니다.
하지만,98이랑 NT랑은 커널이 틀리니까 세부적으로는 틀리게
만들수 있겠죠!
만약,, 채팅 클라이언트와 서버를 만드실 줄 안다면
게임 서버를 만들준비는 다 된것이나 마찬가지입니다.(준비가
다된겁니다^^;)
참고가 되셨음....
안녕하세요.. 이번에 어쩌다가 이쪽으로 공부를 시작하게 되어서리.. 이 게시판에
오게 되었습니다. 서버 프로그래밍 쌩초보라서 처음부터 쭉 보다보니 처음에 3d
프로그래밍 시작했을때만큼이나 막막하더군요. 비동기화 IO 라던가 멀티쓰레딩이
라던가 분산처리라던가 등등등...
처음에는 유닉스로 서버프로그래밍을 짜려고 생각했었는데 불행히도 리눅스 환경
에 적응하기가 쉽지 않을 듯 해서 NT 쪽으로 방향을 선회하였습니다. 요즘 이것
저것 책을 보고 있는데 Jeff Richter 의 윈도우 책과 스티븐스의 유닉스 네트워킹책
을 보고 있습니다.
어쨌건 지상과제는 많은 클라이언트가 접속해서 최대한 스무스하게 볼일 보고 나가
는 환경을 만드는 것인데.. 멀티쓰레딩문제와 IO 문제가 일단 걸림돌이 되더군요
1thread per 1client 방식은 확장성이 다소 결여된다는 느낌이 들어서
Thread-pooling
을 사용해야겠다는 생각을 했었는데, 마침 W2k 에서는 QueueUserWorkItem 이라는
함수를 통해서 자동적으로 쓰레드의 갯수를 증감시켜가면서 밸런싱을 하는 기능을
제공하더군요. 또한 네트워크 관련 IO 에 있어서도 IoCompletionPort 라는 개념을
통해서 해당 IO 가 완료되는 시점마다 자동적으로 기다리는 Worker Thread 와 연결
시켜주는 기능이 있는 것 같고.. 어쨌든 이 2 가지 개념 + Winsock2 의 기능들이
연결되면 나름대로 운영체제에 맞게 잘 구성된 시스템이 나올것 같다는 느낌이 들
었습니다....... 만!
VS 6.0 에 있는 Platform SDK 에는 QueueUserWorkItem 같은 함수는 등장하지도
않더군요 --;...
그래서 지금 모뎀으로 ms 의 ftp 에 접속해서 w2k Jan2000 SDK 를 받고 있습니다
어느 철년에나 다 받을련지 --;..
제가 생각하는 방향이 잘 생각하는 방향인지 아직 확신도 좀 부족하고, 쓸만한
예제도 아쉬운 상황이라 몇자 끄적거려봅니다..
여러분 모두 앞으로 이 게시판에서 자주 뵙게 될 듯..
그럼
학규
neolith
헬브레스 서버가 단일 루프 노 쓰레드 방식이에여. 프로그래밍 기법적인 측면에서
보면 단순무식하지만 사실 가장 안정적이라는 생각이 듭니다. 무엇보다도 단일 루프
구조아래서는 아이템 복사가 불가능하다는 장점이 있죠. 어차피 한순간에 하나만
처리 하니깐요.
루프방식의 서버 1개가 펜3 500 CPU에서 적정 사용자 600~700명(최대 900)까지
처리가 가능하더군요. 0.4초 동안 소켓 메시지를 받아 큐에 넣고 일괄적으로
처리하는데 0.4초간에 클라이언트로 부터 수신되는 메시지가 1000~1500개
사이입니다. 펜3 500급의 CPU로는 이정도 처리하는데는 별 무리가 없더군요.
단 단일 쓰레드이기 때문에 멀티 CPU 환경의 서버에서 자원낭비가 있을 수 있는데
이경우에는 서버를 여러개 띄우면 되더군요. 어차피 맵 분할 방식으로 각각의 맵을
처리하는 서버가 나누어져 있으니깐요. CPU 갯수에 맞게끔 서버 프로그램을
할당하면 CPU 자원이 낭비되지는 않는 것 같더군요.
이상 단일 쓰레드 방식도 쓸만하다는 의견이었네요.
안녕하세요.
메틴 게임 서버의 경우 Soph 님과 같이 무식한 루프를 썼습니다.
리눅스에서 select() 폴링을 해서 만들었는데, 1200명 까지는 한
프로세스에서 어느정도 버티더군요. 음.. 디스크 억세싱 부분은
쓰레드를 썼습니다만.. 사용자가 느낄 필요가 없는 부분이니 흠.
쓰레드는 멀티태스킹이 안되는 제 두뇌에는 너무나도 고통을 주기
때문에, 그리고 예외처리가 많이 필요한 게임에서 (이건 제 프로그램
디자인 자체가 잘못되서 그런지 몰라도요 크하하) 쓰레드는 짜증일
꺼라는 괴변을 펼치며, 또한 제가 프로그래밍 철학을 선호하는 사람이
아니라서 무식한 루프를 고수하고 있습니다.
음.. 그래서 Soph 님 말씀대로 프로세스를 많이 띄우는 방식으로
처리하고 있습니다.
한 프로세스에서 avg 150ms/sec 도 걸리니 할만하죠. 프로세스 세개
까지는 Xeon 550mhz two way 에서 할만 하던데요.
그리고 현재 메틴 게임은 위와 같이 돌아가고 있습니다. DB 서버는
SQL + 자체제작 형식으로 돌아가고 있습니다.
-비엽
ps. 메틴 게임이라고 홍보도 안하고 잡지에도 안나온 괴상한 온라인
게임이 있습니다. -_-;
아래 글을 보니 저랑 거의 생각이 같으신거 같군요.
저도 별로 쓰래드나 그런걸 잘 모르기 때문에--_--;;
첨에는 서버 한개로 하려고 했으나.
포트리스 서버를 보고.. 이래도 될거 같다라는 생각을
했죠.
그리고 생각해보니.. 한컴에서도 여러개에 서버를 띄울
수 있더군요. 포트만 바꾸면.^^
그래서 저는 서버를 한 5개 정도 만들까 생각하고 있었
답니다.
우선 게임에 장르로 봐서는 그리 렉이 없을듯 싶고요.
나중에는 스타처럼. 사용자 서버도 생각해 볼거구요.
만들고 나면... 더 고치고 방법을 설명해 드리고 싶은데.
아직 시작이 않돼 있으니...-_-;;
오늘 부터 할 예정이랍니다^^
안녕하세요? 아래 광현님 한주님 춘기님 글 잘 보았습니다. 루프방식을 사용한다면
일정시간동안은 프로세스 처리를 하지 않고 IO 입력만 받아 모았다가 다시
일정시간동안은 IO 입력을 받는 처리는 하지 않고 처리를 해두고, 다시
일정시간동안에는 출력을 보내는 식이 되는 것인가요? 그런 경우의 입출력
방식은 윈삭의 비동기화 소켓을 사용하는 것인가요? select 등을 이용한
폴링을 사용하게 되는 것인가요? 멀티쓰레딩을 사용하는 것이 아니니까
아마 블럭킹은 아닐 것 같고요..
학규
뭐 특별한 공식이 따로 정해져 있는건 아니지만
아래 학규님 말처럼 1인당 쓰레드 하나는 너무 비효율적이고요.
그럴 필요가 없다고 생각 합니다. OS에 따라 쓰레드 갯수에 한계도 있고요.
작업에 대해 많이 걸리는 작업에 Thread수를 조절해주는 것이죠.
PC,NPC,Monster등에 Thread를 하나씩 두고 처리하는데 Monster 1000마리의
움직임을 처리할때 100분의 1초정도 걸리더군요. 물론 여러가지 루틴이 아직 많이
구현안된 상태이고 구현방식에 따라 차이가 있겠지만요 , 가장 시간이 많이
걸리는 쪽은 네트웍처리인데 이부분은 input의 경우 큐를 두고 쓰레드 하나는
계속해서 유저로부터 패킷을 받아서 쌓아둡니다. 그리고 그걸 처리하는
쓰레드(parseThread라는 이름을 붙여봤습니다^^;) 는 계속 대기하며 큐에 패킷이
들어오길 기다리고 들어오면 경쟁적으로 빼가서 처리하는 구조입니다.
output의 경우 outputQueue에 입력하는 루틴이 여러군데 라는 점을
빼면 inputQueue와 동일하죠.
멀티쓰레드 서버의 일반적인 구조라고 생각 합니다.
여기서 처리하는 쓰레드 갯수는 config 화일에서 조절할 수 있게 했습니다.
관리자가 상황을 보고 튜닝이 가능하도록 말이죠.
서버콘솔에는 큐의 상태를 확인해 볼수 있는 명령을 두어서 input큐가
쌓이면 parseThread갯수를 늘려주고 , outputQueue가 쌓이면 유저에게
날리는 Thread갯수를 늘려주게 (수동으로 ^^;)해서 성능에 대한 튜닝을
할 수 있게 말이죠. (물론 멀티 서버라서 이부분은 구조가 좀 더 복잡합니다.)
물론 이부분도 내부적인 구현으로 Queue의 상태를 체크해서 Thread의 갯수를 조절할
수 있게 할 수 있겠지요.. (그부분만 구현 하면 학규님이 말한 라이브러리와 비슷한
구조네요 ^^;)
좋은 점은 유동성이네요. 이번에 베타도중 Queue의 멀티쓰레드 처리시 문제가
발견되었을때 parseThread갯수를 1개로 줄여서 위기를 모면 했다는.. ^^:
물론 프로그램짤때 골머리썩습니다. 이 네트웍 엔진쪽 구현도 구현이지만
멀티 Thread 사용시 실질적인 게임 구현에서 구조를 잘잡지 않으면 흰머리가 더
늘어날 거라는 전설이~~~..
__
이경만
PS.
철아. 너의 아버지는 예전의 나나 에메랄더스와 같이 싸웠던 멋진 전사였다.
불행히 도중에 다른 길을 가게 되었지만...
너는 너의 아버지를 많이 닮았다.
철아! 비록 아버지와 뜻은 달라도 그것을 뛰어넘어 젊은이가 미래를 만드는 것이다.
부모에게서 자식으로, 자식에게서 또 그 자식에게 피는 그렇게 흘러 영원히
이어진다.
그것이 진정한 영원한 생명이라고 나는 믿는다.
__
은하철도999 극장판중에서
http://show.thrunet.com/entercp/aniline/bb004a01.asf
헬브레스 서버는 NT로 되어 있구요, Win32의 비동기 소켓으로 논블록킹 메시지 구동
방식으로 되어 있습니다. 0.4 초 간격의 멀티미디어 타이머를 걸어 놓고 그 동안은
아무런 작업을 하지 않고 대기하며 오직 소켓 이벤트가 오면 처리하기를 기다리고
있습니다. 0.4초인 이유는 클라이언트 프로그램의 캐릭터의 동작처리를 위해 보내는
메시지의 최소 간격이기 때문이구요, 그동안 수신되는 클라이언트로부터의 소켓
메시지는 모두 큐에 저장되죠. 그런다음 한번에 일괄 처리하면서 NPC, 몬스터들의
동작 역시 같이 처리합니다. 처리하면서 각각의 클라이언트들에게 변경된 메시지를
보내 줍니다.
이런 헬브레스 서버의 구조가 어느정도의 퍼포먼스를 보여주는 것인지는 잘
모르겠습니다만 지금까지 서비스 해 오면서 보아 온 것으로는 단일 쓰레드 치고는
상당한 수준이 아닐까 합니다. 또다른 장점이라면 디버깅이 쉽고, 아이템 복사등과
같은 문제가 발생할 가능성이 매우 적으며, 시스템적으로도 안정적이어서 자원누출
등의 문제나 NT자체의 불안정으로 인해 시스템이 멈추지 않는한 잘 다운되는 일이
없습니다.
물론 이건 헬브레스 처럼 각각의 맵이 독립적으로 운용되는 구조의 시스템 아래서
해당되는 말이구요, 울온처럼 서버간의 이동을 알아챌 수 없는 시스템이라면 문제가
다를겁니다.
쓰다보니 단일 루프가 좋다는 말처럼 들리는데 이건 제가 쓰레드 프로그램을 해보지
않은것에서 비롯되는 개인적인 의견이죠^^
어쨌든 NT서버, 비동기 논블록킹 Win32 소켓 메시지 처리 방식, 단일 루프, 맵분할
독립 처리 방식으로 헬브레스 정도의 시스템 구축이 가능하다는 점은 참고가 되겠
네요.
현재 헬브레스는 동시접속자 1400~1500명 정도를 수용하고 있고 서버 시스템은
펜2 300 DUAL 1대, 펜3 500 DUAL 2대의 시스템에서 로그인 서버를 제외한
게임서버 7개가 작동하고 있습니다.
참고가 되었으면 좋겠네요
경만님의 아타나시아와 비슷한 방법으로 서버 프로그래밍
계획이 잡혀서.. 상당 부분 진척이 되고 있긴 한데..
경만님과 약간 다른 점은.. pharsing thread가 하나라는 점..
유동성을 주면 좋긴 하겠지만.. 부하가 커지면 유리하겠지만..
일단.. 한 가지 일을 하는ㄴ 여러개의 쓰레드를 두자니..
각각의 쓰레드가 공히 정보 교환이 필요할 지 모른다는 것과.
하나라도 충분할 거야~~ 라는 막연한 기대와 배짱...으로다가... ^^;;
다만 걱정되는 것이 타이머 주기를 0.1초로 잡고 있다는 것..
0.1초 동안 적게는 수백에서 많게는 수천, 수만의 클라이언트
메시지를 처리해 줄 수 있을까.. 하는 점임다.
0.1초 동안 클라이언트 리스트(혹은 맵)에서 수신된 메시지가
있는 가 검사해서ㅗ 있음 처리하는 방식인데..
파싱 쓰레드라기보다.. 메인 게임 엔진 쓰레드이죠.
경만님의 말씀하신 플랜 엔진은 따로...
몹 엔진 하나 따로.. 환경 엔진 하나 따로..
젤 할일없는 환경엔진.. 흐흐..
하나 더 문제가 되는 것이 캐릭터의 이동 속도가 저마다
다르다는 것인데.. 따라서, 플랜 엔진에서 잡아주는
타이머의 주기가 작을 수 밖에 없다는 것이죠.. ㅠㅜ
과연 서버가 얼마나 빨리 많은 일을 할 수 있는지
알수가 없으니... 죽겠군요.
대략 되겠지... 하는 마음으로... 타조가 되고 있습니다..
이렇게 플밍하다가 나중에 안되면 어떻게 감당하죠? 흘..
그럼..
parseThread를 설계할때 각각의 쓰레드은 독립적으로
설계를 했고 나머지 쓰레드와는 따로 locking Manager를 두어 같이 쓰는
자료들은 보호해주는 거죠.
parsethread를 하나두면 처리방식에 따라 차이가 있겠지만
처리못하고 Queue에 남아 있는 경우도 생길겁니다.
한번 스트레스 테스트를 해보십시요. 그게 가장 확실합니다.
실지로 돌리기 전에 미리 시뮬레이션 하는 프로그램으로 테스트를 해보는게
중요합니다. 서버는 사실 돌려 보기 전엔 모르거든요.
충분히 테스트 되지 않아서 초기에 몇십분에 한번씩 죽은 적도 있고요.
디버깅에 확실히 도움이 됩니다.
불안에 떨지 마시고 ^^;
스트레스 테스트 프로그램을 짜십시요.
__
이경만
안녕하세요? 레이옷입니다.
아래 글을 보면서 서버 콘솔이 필요하다는 걸 느꼈습니다.
그것도, 단순히 표준 출력에 줄줄줄 찍는 게 아니라....
ncurses 같은 걸 써서 잘 정렬해서 보여줘야 할 거 같네요.
흠. 거기다가 각 분산 서버들의 상태 및 처리 인원,
몬스터 개수, 아이템 개수 같은 것들도 출력해주면 더더욱
좋겠네요. 캬캬.. 에러 발생, 크래킹 시도 체크(invalid
protocol) , DB 상태 같은 것도 보여주고.. 냐하하..
결국 또 서버 모니터 프로그램과 게임서버간의 프로토콜을
만들어야 한다는 이야기인가??? 우웃..
흠. 시간이 날지 모르겠습니다. 이제 겨우 DB 스키마가 나온
상태인데.. - -; 언제 이동시키고 게임 코드 넣고 하징...
==
the Dark Eden : the Bible of the Blood
<다크 에덴>은 아름다운 동유럽을 배경으로, 날카로운 검과
막강한 총/폭탄, 그리고 성령의 가호로 무장한 인간들과
고대로부터 전해지는 강력한 공격마법을 사용하는 불멸의
뱀파이어들간의 마지막 전쟁을 다루는 온라인 게임입니다.
^_^; 기대해 주세요....
요새는 게임 서버구축할경우
ISP 에서 회선을 싼가격에 대 주고,
서버는 데이터 센터에 두는 경우가 많은데요,
NT기반의 서버라면 리모트 컨트롤하기가 굉장히 곤란해 집니다.
하지만, Unix 라면 리모트 디버깅도 되는 강점이 있지요.
퍼포먼스 면에서는 NT나 Unix나 비슷하다는 느낌이지만,
수십년간 쌓여온 Unix 의 관리에 있어서의 충실함은
NT가 따라갈게 못된다고 생각합니다.
간단하게 생각해보면.. 퇴근은 했고.. 서버가 다운되었다면..?
혹은 해외 서버가 이상이 생겼다면..?
네트웍 게임은 대부분 자동 패치를 지원하는데요..
이의 구현방법과 주의사항을 듣고싶어요..
일단 제생각에는 최초 접속시 자신의 버젼정보를 서버에게 알려주고...
버전이 틀리면 서버가 틀린 버전임을 통지하면 클라이언트는...
자신의 프로세스를 종료하면서 자동패치 프로그램을 실행한다???
그리구...
패치용 서버에게 접속하여 필요한 파일을 다운로드 받는다...
다 받으면 설치하고 클라이언트를 재실행 한다...
대충 이런식으로 구상해봤는데.. 문제는요.
1. 패치파일 전송만 전담하는 서버가 필요한가요?
2. 파일 전송은 어떤식으로 행해야하나요?
직접 파일 전송을 해야하는지 아니면 파일 전송을 해주는 다른 방법이 있는지..
만일 직접 해야한다면 어떤 방법이 가장 효율적인지 듣고 싶습니다.
웅.. 네떡겜은 골치아픈 요소들이 많은거 같군요.
꼭 답변 부탁드려요.. ㅠ.ㅠ일단 사용자가 많으면 파일전송 서버를 따로 두는것이 좋겠지요?
사용자가 엄청 많다면.. 메인 서버가 패치서버의 IP를 알려줘서
Replicated 분산서버로의 확장도 가능할테구요..
파일전송은 전통적인 Kermit방식이나 Windowing 방식 같은거를 쓰면 되겠군요.
Kermit방식은 말그대로 한패킷 보내고 받았다는 응답이 오면 다음패킷 보내는
방식인데.. 보내는 delay 랑 응답 delay때문에 대역폭이 아무리 좋은 네트웍
이라고 해도 그리 빠른속도는 나오기 힘들죠.. 뭐.. 뒤집어 말하면..
사용자가 많이 붙는다고 느려지는 것이 아니니깐.. 그럭저럭 쓸만하겠죠?
문제는 사용자가 한명이어도 수백명이 받을때랑 똑같이 느리다는것.. ^^;
여튼 .. delay 차이를 좀 줄여보고자.. 응답을 받기 전에 미리 패킷을 보내고..
응답이 한 7개쯤 안왔다(예를들어)면 응답오기까지 기다리고..
또 응답 몇개 오면 보내고.. 이런 방식이 Windowing방식인데..
대부분의 파일전송 알고리즘이 이런방식이라고 할 수 있겠지요..
위에서 7개를 예를 들었으니.. WindowSize == 7 이 되겠지요?
여튼 보내고 확인받는 갯수가 동시에 7개정도니깐.. 전체적으로 봤을때
딜레이가 상당히 적겠지요? 음. Window sliding 그림을 그려가며
설명을 하면 좀더 이해하기 쉬울텐데.. 뭐.. tcp책같은거 보면 다
나와있으니.. 참고하세요..
음.. 설명이 엄청 난잡하군요.. ^^;
여튼 도움이 되었음 좋겠네요
네떡 초보자 호 입니다.
제가 질문할 내용은 서버에 접속된 유저 관리에 관한 내용입니다.
우선 생각한 방법이 CUser라는 클래스를 만들어 접속된 유저마다
CUser를 할당합니다. CUser는 유저의 ID와 소켓을 관리하는데
이 CUser를 단순히 링크드 리스트를 만들어 관리를 할려니 유저의
ID에서 문제가 생기더군요. 링크드 리스트의 중간에 있던 유저가
나가면 유저의 ID를 수정해야 할것 같습니다. 프로그램 세계 12월에
나온 기사를 읽으니 유저 ID를 InterlockedIncrement()를 이용하여
만들더군요. 그런데 위의 것을 쓰면 유저가 계속 들어오면 ID가 무한정
커지는 경우가 생길것 같은데요?
고수님들은 유저관리 및 ID생성을 어떻게 하시나요? 그리고 한명의
유저에게 자신의 일정영역까지의 다른 유저정보를 보낼때 다른 유저
정보를 어떤 식으로 검색하시나요?
효과적인 유저관리의 조언을 바랍니다.
디비를 쓰면 간단하게 해결됩니다.
물론 프로그램적으로 구현해도 상관없지만.
좀 어느정도 중규모 이상의 디비에선 자동으로 증가하는
필드를 만들 수 있습니다.
이렇게 해서 중복하지 않는 ID값을 얻을 수 있습니다.
그러다가 유저 아이디를 지우거나 해서 계속해서
한계값이상으로 증가 한다면 내부적으로 정리해주는
프로그램을 짜서 해결해 주는거죠.
중간에 빈값을 찾아서 넣어주는 것은 좀 신경 쓸 부분이 있죠.
차라리 서비스 정검 시간에 정리하는 프로그램을 돌려주는
것이 좋은 방법이라고 생각 하고 그렇게 구현하고 있습니다.
__
이경만
PS.
Effort without results is just self-satisfying bunk.
리눅스나 BSD 환경에 sendfile() 이란 call 이 있더군요. FTP 데몬에서
직접 적으로 파일 전송할 때 사용되는 콜인데, 노가다로 만들었던 코드
보다 효율이 잘 나와서 화가 나네요. (-_- 아무래도 로우 레벨에서 넘
어가는 코드니..)
다음은 sendfile manpage 입니다.
NAME
sendfile - transfer data between file descriptors
SYNOPSIS
#include <unistd.h>
intsendfile(intout_fd,intin_fd,off_t*offset,size_tcount)
DESCRIPTION
This call copies data between file descriptor and another file descri
p
tor or socket. in_fd should be a file
descriptor opened for reading. out_fd should be a descriptor opened for
writing or a connected socket. offset
is a pointer to variable holding the input file pointer position fr
o
m which sendfile(2) will start reading
data. After sendfile finished this variable will be set to the offset of
the byte following the last byte that
was read. count is the number of bytes to copy between file descriptors
──────────────────────────────────────
.
NOTES
Sendfile does not modify the current file pointer of in_fd, but does for
out_fd.
If you plan to use sendfile for sending files to a TCP socket, but ne
e
d to send some header data in front of
the file contents, please refer to the TCP_CORK option in tcp(4) to tune
performance.
RETURN VALUE
If the transfer was succeeded, the number of bytes written to out_fd is
r
eturned. On error, -1 is returned, and
errno is set appropriately.
ERRORS
EBADF Input file was not opened for reading or output file was not ope
n
ed for writing.
EINVAL Descriptor is not valid or locked.
ENOMEM Insufficient memory for reading from in_fd.
EIO Unspecified error while reading from in_fd.
VERSIONS
sendfile is a new feature in Linux 2.2.
Other Unixes often implement sendfile with different semantics a
n
d prototypes. It should not be used in
portable programs.
특정 서버 프로그램의 포트를 구할수 있나요?
예를 들어 간단한 채팅 서버가 있을때 이 프로그램의
포트번호를 알수 있는 방법이 있나요?
답변 부탁드리며..
돌구지..
hithere@hitel.net