서버 공부를 하고싶은데 어디서 부터 시작해야할지 모르겠습니다.회사에서 리눅스를 공부를 하라고하네요!서버는 심오? 비밀 스러운것? -> NO!클라는 학원도있고 뭐 해서 조금 대중적인거 같은데서버는 아직 대중적이지는 않은거 같다.다른 컴퓨터에서 연결이 가능하도록 대기 상태
비쥬얼 스튜디오 Server라는 프젝 생성하자우리가 지금까지 작업을 할때는한 솔루션안에 하나의 프로젝트만 넣고 작업을 했었다.그런데 서버 작업을 할때는 솔루션안에 프로젝트를 몇개를 더 넣어서 작업을 하게 될 것이다.그래서 솔루션에 추가를 하면 아까와 마찬가지로이렇게 또
멀티 쓰레드 프로그래밍
우리가 이때까지는 c서버가 들어가게 되면은 서버는 멀티쓰레드를 활용을 해야하는데멀티쓰레드를 알기 위해서는컴퓨터 구조 원리랑운영체제에 대한 기본적인 지식이 필요하다.그래서 당장 코드부터 보기보다는 스토리를 하나 들려주고자 한다.그래서 멀티 쓰레드는 식당을 운영하는 것과
이제 프로젝트를 킨다음에 쓰레드를 생성을 해보도록 하겠다.일단 ServerCore를 시작 프로젝트로 설정을 해주고맨들어보자.쓰레드를 만드는 것은 굉장히 쉬운데이렇게 using system.Threading 해주고 하면 된다.그리고 인자에다가 쓰레드가 실행 된다음에 실행
지난시간에 쓰레드를 생성하고 간단하게 사용하는 것 까지 해보았다. 그런데 이것이 끝이 아니다. 오히려 반대로 이제 멀티쓰레드의 진짜 시작이다. 왜냐하면 우리가 지금 까지 만들었던 코드들은 싱글 쓰레드기반으로 돌고 있었었다. 사실은 아무런 문제 없이 돌아가던 것들
이전에 식당 얘기를 할때직원들이 각자의 업을 맡아서식당 운영이 어느정도 되어서어느 괘도에 잘 올라섰다고 함보자 손님들도 많아지고 잘 돈을 벌고 있었다고 해보자.그런데 손님이 많아 지다 보니까 이것들을 어떻게 처리를 할지 고민이 생기기 시작했다.이렇게 테이블을 돌아 다니
지지난 시간에 컴파일러 최적화라 해가지고우리가 짠 코드를 컴파일러가 멋대로튜닝을 해가지고다른 결과물을 만들어 내는 그런 실습을 해보았다.그것이 분명히 성능 향상을 위해서 선의로 해주었던 것인데결과적으로 "멀티 쓰레드"환경에서는 "독"이 되었고오묘한 버그들을 만들었던 것
지난 시간까지 하드웨어 최적화시 문제에대해서 알아보았다.그 문제들을 메모리 베리어를 이용해 가지고뭐 하는 그런 작업들을 해보았다.그런데 이런 "컴파일러"나 하드웨어에서 일어나는 최적화 문제들은생각보다 우리가 그렇게 크게 신경을 안써도 되는 것이나중에 가면은 이런 메모리
지난시간에 멀티 쓰레드 환경에서 일어날 수 있는Race Condition라는 "경합 조건"에 대해서 살펴 보았고InterLocked 계열의 함수를 사용해서 ref \_number를 처리를 하는 부분까지도 알아 보았다.InterLocked 계열이 성능도 빠르고 굉장히 우
지난 시간에 했던 것을 복습을 잠깐 해보자면데드락 상황이 뭔지 알아 봤었는데멀티쓰레드 환경이라 가정을 하자면직원1, 직원2 이렇게 있을 때화장실에 누가 먼저 가느냐에 따라서 먼저 사용하는 사람이 정해지는데만약 직원1이 먼저 도착하면 자물쇠를 화장실에 잠구고 혼자 계속
지난시간 까지 락에 대한 설명을 하였고데드락까지도 설명을 하였는데사실은"멀티 쓰레드"프로그래밍에서 "Lock"의 비중이 한60%~70% 정도는 될 정도로 굉장히 중요하게 사용이 된다.그렇기 때문에Lock은 도대체 어떻게 동작을 하는지대략적으로 나마 이해를 하는 것이 굉
지난 시간에 이어서 이제 Lock을 구현을 해볼 것인데그래서 먼저 SpinLock부터 알아 볼 것인데참고로 SpinLock의 경우 면접에서도 굉장히 자주 나온다.면접의 0번째 질문으로 멀티쓰레드를 구현을 할 때, SpinLock을 구현을 해보았냐?? 고 물어 보기 때문
지난 시간에 우리는 Spinlock에 대해서 알아 보았고SpinLock이라는게 결코 어려운 개념이 아니였다.InterLock.CompareExchange에서lock을 획득하려는 시도를 하고 있었고break에 왔다는 것은 굉장히 해피한 상황이라는 것이다.만약 이것이 실패
오늘은 지난 시간에 이어서 마지막 방법으로 Lock을 구현을 해볼 것인데, (마지막 방법이 직원에게 알려달라고 한다음 나는 자리로 가있고 직원이 알려주면 그제서야 가는것)이게 사실은 Event 라는 것을 사용하는 방법이다.지난번에 얘기했던 마지막 방법이 이것이다.이 방
지난 시간까지관리자 직원(Kernel Mode)를 거쳐서락을 구현하는 세가지 방법에 대해서 배웠었다.AutoResetEventMaualResetEventMutex이렇게 세가지이번에도 새로운 락에대해서 배울 것인데배우기 전에 복습을 잠깐하고 가도록 하자.그래서 보면은락을
지난 시간에 예고한대로 구현을 함 해보도록 하겠다.오늘 해볼 방식이Lock Free Programming이랑 사실 굉장히 비슷한데오늘 하는 내용이 어렵기 때문에 한번듣고 모르겠다 싶으면구경만 하고 넘어가도 상관은 없다.Servercore -> 새 항복 추가를 해서 Lo
오늘은 TLS라는 아이이다.이게 뭐 사실은 개념적으로 어려운 부분은 아니고이게 사실은 전역 변수인데Thread 마다 "고유" 하게 접근 할 수 있는 전역 변수라고 생각하면된다.그래서 이게 뭔지 알아보기전에이게 "왜"필요한지에 대해서 부터 알아보고 시작을 하도록 하자.그
네트워크 프로그래밍 19~
우리가 나중에 서버를 만들게 되면"안정성" 이 굉장히 중요한 이슈가 될 것이다.서버가 많은 동시 접속자를 버티는 능력도 되겠지만해킹공격에 대한 방어도 충분히 할 수 있어야 한다.우리가 네트워킹 지식이 없으면 어떻게 처리를 해야될지도 모를 것이고대처를 못할 것이다.그래서
이번시간은 통신 모델에 대해서 알아 볼 것인데이게 컴공에서 네트워크 시간에 배우는OSI, 7Layer 등에 대한 내용이다.일단,예제를 통해 이게 뭐하는건지 잠깐 알아보도록 하자.택배가 어떻게 보내졌었는지 다시 생각을 해보면이런식으로 경로만 있다고해서 없던 택배가 막 보
이렇게해서 네트워크 쪽을 알아보았는데사실은 네트워크 쪽은 많이 알면 알 수록 도움이 많이 된다.일반적으로 네트워크 공학은 학교에서 한학기 동안 배우는 내용이다.그래서 굉장히 학습할 내용이 많다.그래서 그 내용에 대해서 하나하나씩 다 얘기를 하면 몇십시간의 강의가 될 테
이제 네트워크 프로그래밍을 해보도록 하겠다.이상태에서 시작을 해보도록 하자.락도 딱히 사용할 일이(지금은 없기때문에) 삭제를 해주도록 하자.솔루션 > 속성 >여러개의 시작 프로그램으로 맞춰 주어라.그리고 Client 역할은 더미클라가, 서버 역할은 ServerCore가
지난번에 작업하던 코드를 조금 정리를 하고 넘어가도록 하겠다.코드가이렇게 Main안에 크게 다 때려박혀있다.코드가 커지면 관리가 어려워지기 때문에따로 빼서 관리하는 습관을 길러야 한다.지금은 문지기 부분을 빼서 관리를 먼저 하자.ServerCore > 우클릭 > 추가
이번 시간은 Session을 만들어서Receive, Send하는 부분을 비동기 방식으로 만들 것인데이전시간에 했던 부분중에서 의문이 들만한 부분을 좀 고치고 가도록 하겠다.우리가 Listener라는 클래스를 만들어서 Accept부분을 Aysnc로 만들었었다.이 두부분을
이번 시간에 이어서 session을 만들어 볼 것이다.receive까지는 Async계열로 바꾸었었다.그리고 그전에else 부분 잠깐 Disconnect넣어주자.RegisterRecv의 경우Event를 이렇게 하나만 만들어서 등록을 하고있었다.비록 비동기이기는 하지만여러
지난 시간에 이어서 세션을 만들어 볼 것이다.지난 시간에 했던거 중에 중요한게이런식으로 recvArgs, \_sendArgs를 만들어서 사용했던것인데나중에 C++에서도 서버에서 이렇게 진짜 비슷하게 만들 것이니까유심히 살펴봐라.그리고Receive의 경우 SetBuffe
지난 시간에 Send를 조금 효율적으로 고치는 방법에 대해서 알아보았다.이게 무슨 말이냐 하면은패킷을 보내고 싶을때를 통해서 보낼 수 있다.패킷을 받는 경우에이런식으로 콘솔에다만 찍고 아무것도 안하고 있었다.그래서 여기다가 콜백으로든 어떤 방식으로든 메세지를 받았다는
오늘은 Listener의 반대 역할을 하는Connector를 만들 것이다.더미클라에서 Connect하는 부분을이렇게 블로킹으로 사용을 하고 있었다.(온라인 게임에서는 이런 블로킹함수를 사용하는 것을 최대한 "지양"해야됨)이런 부분을 담당하는 애가 되겠다.일단 이렇게 만
지난시간까지 세션작업 완료를 하고,라이브러리로 ServerCore를 따로 뺀 다음에클라랑 컨텐츠(Server)에서 참조를 하도록 만들어 주었다.그런데우리가 지금은 문자열로만 통신을 하고 있었는데나중에는 당연히 문자열로만 통신을 하지 않을 것이고"패킷"이라는 개념으로 통
다시 코드로 돌아와서오늘은 ReceiveBuffer를 개선을 해보는 시간을 갖도록 하겠다.이게 "패킷"으로 넘어가기 위한 기초 작업이다.Session에서 여기서 SetBuffer해줌이녀석을 설정만 하고 안 바꿨으니까결국 이 부분에서 보내준 메세지는 무엇이냐하면은buff
SendBuffer 맨들어 주는데RecvBuffer보다 조금더 어렵다.우선 Server > Program으로 가보면여기서 Send를 하고 있었다.그런데, 외부에서 이렇게 바이트 배열을 만든 다음에Send라는 인터페이스를 통해서 sendBuff를 넣어주고 있었다.그 다음
이때까지 RecvBuffer, SendBuffer 만들어서 주고 받는 인터페이스는 어느정도 윤곽이 나왔다.오늘은 이어서 "패킷 작업"을 위해서 뭐가 필요한지 생각을 해볼 것인데ServerCore의 Session에 기능을 추가를 할 것이다.Session > OnRecv를
지난 시간까지 클라 <- 패킷 -> 서버이렇게 통신을 해보았다왼쪽 클라 Pro오른쪽 Server Pro이렇게 Packet이라는 것을 만들어서 흘려보내고 있었는데"직렬화"라는 용어를 사용하게 된다 이제부터
패킷을 직렬화를 해서 보내고받는쪽에서는 비직렬화를 해서 패킷을 꺼내는 것 까지 해보았다.오늘은 나중에 자동화를 하기위한 준비작업 &&조금 인터페이스적인 부분을 사용을 하기 쉽게 만들것인데지금패킷을 직렬화 하는 부부에서 하는게 너무 많다.이런부분들을 함수화 해서 자동화를
이제는 문자열을 직렬화를 할 것인데즉, 네트워크 패킷에다가 문자열을 밀어 넣는 작업을 이어서 할 것이다.UNICODE & ENCODING의 내용에 대해서 훑어 보고 갈 것이다.우리가 이전에 Hellow NetWorkServer! 이런 문자열을UTF-8로 보냈었는데이 U
이어서 직렬화를 계속 작업을 해볼 것인데그래서 이런 고정된 사이즈의 데이터가 아니라string같은 가변적인 사이즈의 데이터를 갖는 것에 대해서어떻게 처리를 할것인지를 알아볼 것이다.즉, 어떻게 넘기고 어떻게 추출을 할 것인지그전에 잠깐 수정을 하자면 count += 2
오늘은 리스트를 주고 받은 부분 할 것이다.이런식으로 리스트안에 기본 자료형인 int가 들어가 있다고 하면은string, byte\[]를 넘겼던 것과 마찬가지로List에 몇개짜리가 있는지 먼저 밀어 넣어 주고그 다음에 데이터를 밀어넣는 작업을 똑같이 해주면 될 것이다.
1. 준비 그래서 int, string, List 등과 같은거 직렬화 해서 보내고 받을때는 역직렬화를 통해서 Raed하는 부분까지 해보았는데 이것을 이제 "자동화"를 하는 부분을 구현읋 하도록 하자. 자동화 코드를 만들때 방법이 먼저 "하드코딩" > 재사용하
결국 우리가 하고싶은게 뭐냐하면은XML파일 읽은다음에여기서 하나하나씩 다 파싱을 한다음에이 기능을 이용해가지고여기다가 "파일"로 하나로 만들어 주는 것이다.이런 이름으로 만들어주고 "" 에다가 자동 완성한 무언가를 넣어주면된다." "안에다가 자동완성하는 것을 "genP
앞으로는 여기 GenPackets에 있는 내용들을수동으로 복붙해서 붙여 넣는게 아니라 클라든 서버든 필요한쪽에서 "참조"를 하게끄름 만들어 줘야한다.그래서 이 파일이 완전체로 제공되기 위해서뭐가 빠졌는지 유심히 살펴보면은이런식으로 enum값 필요 할테고그리고 이런 us
packet을 만들어서 어느정도 자동화 되는 것까지 확인을 하였다.그런데 그 만든 코드(파일들을)PlayerInfoReq와 같은 패킷들을 이런식으로 복붙을 하고 있었는데패킷이 계속해서 바뀔텐데그럴때마다 복붙하는것은 말이 안되니까 오늘은 복붙을 안하고 참조를 하는 방식이
1. 개선점 찾기 1) switch문 개선 클라 세션에서 이런식으로 스위치로 패킷아이디를 구분을 해주고 있었는데 사버 클라 네트웍 통신이 많을텐데 운이 안좋게 PlayerInfoReq가 199번째 switch문이라면 쓸데없는 스위치 비교를 198번동안이나
우리가 그래서 PacketFormat에다가 PacketManager내용 옮기도록 하자.이런식으로 다 긁어 온다음에자동화 할부분을 보면은의외로 많이 없는것을 알 수 있다.Register부분만 자동화 부분이 들어가야 한다는 말인데여기 {0}번은 패킷 등록패킷등록의 {0}에
패킷까지는 준비 OKsession도 어느정도 끝났기 떄문에컨텐츠를 작업할 대략적인 준비는 끝났다!그런데 이것을 그냥 딱 하고 넘겨주면 난해할것이다.그래서 이것을 어떻게 구조를 짜가지고 게임이든 MMO든 어떻게 만들어야할지아리쏭하다.다른 게임서적을 보아도 거의 여기까지인
Dummy클라를 보면은이런식으로 한번만 "접속"을 하고있었다.그래서 일단 더미 클라에SessionManager를 만들어 주자 이렇게이녀석은 서버의 세션메니저와는 하는 역할이 다르다.그리고 더미클라의 Program에서 이렇게 retrun 하는 부분이렇게 바꿔주도록 하자.
오늘은 "Command패턴 이론" 대해서 알아 볼 것이다.우리가 나중에 Job, Task와 같은 것들을 관리하는 "Queue"가전형적인 Command패턴의 예제 이다.이런식으로 식당안에 클라이언트 세션이 있었는데클라세션이 이런식으로 뭔가를 요청하면 직원이 와서 요청사항
이 잡큐는 컨텐츠 딴에서 만들어도되고ServerCore == 라이브딴에서 만들어도 노상관이다.ServerCore -> Job 생성그다음에 이 Job이라는 개념을 어떻게 만들어 줄 것인가가 고민이다.만드는 방법은 여러가지인데 오늘 보여줄 것은 크게 두가지1) C2) 수동
그래서 크래쉬가 나는거 해결했고이것을 조금더 빡세게 테스트를 해볼려면Listener에서만약 더미클라에서 동시에 500명씩 접속을 하려고 하면은그중에서 일부는 연결이 안될 것이다.why? => 지금 문지기가backlog를 10명만 인정을 하고있기 때문.그래서 원래는 문지
우리가 지금까지 Job Queue에 대해서 알아보았다.그리고 지금이 GameRoom이라는 개념이 굉장히 중요하다.던전, 마을에 이런 Room이라는 개념이 들어갈 수 있을 것이다.그게 아니라고한다면 이게 필드에 있는 하나의 "Zone"이 될 수도 있다.그래서 이런 Zon
지난시간까지 패킷모아보내기를 알아보았다.결국에는 가장 중요하고 핵심적인 부분들은 다 완료가 된 것이다.오늘은 짜잘짜잘한 작업들 말고 오늘 살펴볼 것은지난시간에 했던 0.25초마다 Flush를 하고싶었던 것이다.그런데 나중에 게임이 커져가지고Room이 하나만있는게 아니라
유니티에서이런 TryWriteBytes나 Span같은 것을 사용할 수 없을 것이니유니티 프로젝트를 만들어서 나중에 수정을 해나가야 한다.유니티 프로젝트우리 CSHARP > Server 안에다가 생생 ㄱㄱ우리가 여기 ServerCore를 빌드를 한다음에 ServerCor
그래서 우리가 클라에서 채팅만 받아서 하는게 아니라이제 플레이어를 움직이거나하는 그런 간단한 작업을 해보고싶은건데그래서정상적인 Cif or else 둘중 하나는 찾아야될 것이다.그래서 Server 구동후 유니티 실행하면아무것도 안 뜬다! ??지금 Hello Server
미니 프젝 진행하고 마칠 것이다.지금 PDL에서 C_chat이라는 이름으로 채팅을 보내서그것을 S_chat 이라는 서버쪽 답변 메세지 패킷을 이용해서 해당 채팅 내용을 뿌리는 어떻게 보면 굉장히 간단한 채팅 프로그램을 만들고있었다.그래서 플레이어 생성을 하고 움직이게
이어서 유니티 작업 ㄱㄱ유니티의clientPacketManager로 오면 PacketHandler를 만들어 주지 않아 에러가 발생한거 확인 가능그래서 더미클라 > PacketHandler 있는 내용들복사 ㄱㄱ그런데 이제 유니티쪽은 더미클라 PacketHandler보다