서버공부

using System.Threading;네임스페이스 System.Threading 을 선언하고, Main 함수 내에 Thread를 인스턴스 해준다. 다만 이렇게 할 경우 new Thread() 부분에 빨간색 밑줄이 그어질텐데 쓰레드로 활용할 부분을 지정 해주면 된다.

지난 글에서 스레드를 생성하고, 실행해보며 간단한 스레드 사용 법을 배웠다. [지난 글 보기] 하지만 스레드 사용하는 것은 회사에서 정직원을 채용하는 것 처럼 부담이 클 수 있기에 잠시 활용이 필요한 용도에서는 단기 알바를 구해 사용하는 방식을 고려해볼 수도 있다

우선 기존에 배웠던 코드들을 활용해 무한 루프를 돌고 있는 MainThread를 만들어 주고 bool 전역 변수를 통해 빠져나갈 구멍을 만들어준다.그뒤 Task를 활용해 MainThread()를 실행시켜준다. 그후 Thread.Sleep(\*1ms)으로 잠시 쉬어주고

캐시는 CPU 내에 코어 속에 존재하며 데이터나 값을 미리 복사해 놓는 임시 장소를 뜻한다.시간적으로 분석해보면, 가장 최근에 사용한 변수같은 것이 사용될 확률이 높다고 가정하는 접근법공간적으로 분석해보면, 가장 최근에 사용한 변수같은 것의 주소 근처에서 추가 요청이

지난 시간에 Release 시에 최적화를 자동으로 해주어 오류를 만들던 거를 'volatile' 키워드로 예외처리를 해주는 방법을 사용했는데 이번 메모리 배리어의 경우도 유사하다고 볼 수 있다.실습을 통해 빠르게 배우는게 이해도 잘 되고 좋은 거 같다. 얼마 후 있을

지난 시간에는 Memory Barrier를 활용하여 최적화 시에 자기 맘대로 코드의 순서를 변경하는 걸 막아주거나, 가장 최신 값을 값을 불러오거나 대입하는 가시성을 살려주는 역할을 한다고 배웠다.오늘은 비슷한 거 같지만 다른 주제로 Interlocked 라는 개념에

지난 시간에 원자성에 대한 개념을 배웠고, 원자성이 보장되지 않았을 때 생기는 문제 예시를 시작으로 Interlocked을 통해 해결하는 방법을 배웠다.예시로 배웠던 문제점과 같이 동시 다발적으로 사용(Write)하게 되면 발생하는 이슈를 피하기위해, 문제가 발생하지

Monitor에 대한 개념을 시작으로 중간에 Exit을 해주지않아 DeadLock이 발생하는 상황을 만들고, 더 간결하게 코드 작성을할 수 있는 lock 개념에 대해 배웠다.아주 간단한 DeadLock의 원인이었으니, 더 복잡한 케이스를 통해 배워볼 차례이다.Key를

DeadLock이 발생할 수 있는 두 번째 예제를 통해 어떻게 해결할 수 있을지에 대한 해결방법이었다. 하지만 아직 Lock을 정확하게 구현해본게 아니라, 감이 잘 잡히지 않았는데 이제 부터 제대로 배울 수 있을 거 같다.무한 대기하기(Spine Lock)이미 차지되어

어제는 SpinLock, Context Switching, Auto Reset Event 라는 Lock의 세가지 동작 상태에 대해 배웠고, 오늘은 그 중에서 SpinLock에 대해 조금 더 깊게 배울 것이다.이미 차지되어있는 Lock에 접근하기 위해 계속 대기중인 상태

SpinLock이란 지난번에 사용했던 구조 자체를 의미 하는 것이 아니다. interlock에서 획득을 시도하고, 실패 시 다시 도전하며 반복하는 것을 SpinLock이라 한다.지난 번 요약했던 Lock의 세가지 상태 중 2번 째인 대기 상태의 '쉬다가 다시 획득을 시

Context Switching이 발생하며 내부적으로는 발생하는 비용들에 대해 자세하게 알 수 있었다. 오늘도 역시 Auto Reset Event 시에 발생하는 구조에 대해 설명을 들을 수 있을 것 같다.Lock의 세가지 구조 중 가장 마지막으로 소개해줬었던 일명 '갑

지난 시간에 Auto, Manual, Mutex를 통한 Event 형식의 lock 구조에 대해 배웠다. Event 형식의 특징은 관리자(커널) 영역에 작업이 필요하기에Context Switching이 발생하여 구동이 느리기에 빠른 작업이 필요한 곳에는 적절하지 않다고

✅ 지난 시간 읽을(Read) 때는 자유롭지만, 쓸(Write) 때는 lock을 통해 작동할 수 있는 상황에서 사용되는 ReaderWriterLock의 개념에 대해 배웠고, 실전에 적용해볼 시간이다. 🔧 실습 우선 정책에 대한 정의가 필요하다. 재귀적 허용을 할 것

Read Write Lock을 구현하며 비트에 할당하는 부분이 잘 이해가 되지 않아 배우기 쉽지 않았다. 그래도 여러번 듣다보니 익숙해져서 결국 정리는 잘 해두었지만, 반복해서 보면서 내용을 잘 기억해야겠다.개념설명TLS 란 각 쓰레드간의 공유-개인 사이에 있는 듯한

각 쓰레드만의 고유 공간이었던 TLS를 마지막으로 쉽지 않았던 멀티쓰레드 이론 챕터가 끝났다. 이제 내가 정리한 내용을 바탕으로 다시 복습해 나아갈 예정이고,그래도 다음 챕터인 네트워크는 바로 들으면서 개념을 빨리 익혀야겠다.필요한 이유서버 프로그래밍이라면 안정성 +

네트워크에 기초를 배우며 패킷이 어떻게 목적지로 가는지 택배를 예시로 배우니 쉽게 이해가 될 수 있었다. TCP/IP 5계층이란?네트워크의 기본 구조를 5계층으로 나누어 구분한 것이다. 각 다른 역할을 하는 5가지의 층을 통해 네트워크 통신이 발생한다.물리 계층은 말

✅ 지난 시간 TCP/IP 5계층이라는 구분을 통해 네트워크가 어떻게 동작하는지 간단하게 알 수 있었다. 구조마다 각자 하는 일이 다르구나 정도만 이해한 상태라 틈틈히 찾아보고 이해해야겠다. 소켓 프로그래밍 기초 > 소켓이란? 네트워크 송수신할 수 있도록 '네트워크

소켓 프로그래밍에 대해 처음으로 구현을 했다. 순서가 정해져 있다보니 과정에 이해가 쉬웠다. 서버: 생성 -> 결합 -> 대기 -> 승인 -> 통신 -> 종료클라이언트: 생성 -> 연결 요청 -> 통신 -> 종료지난 시간에 구현한 소켓 프로그래밍의 경우 코드가 모두 메

코드를 조금 더 효율적이게 구분하고, 비동기 처리가 될 수 있게 구현을 해보았다. 과정중에서 이벤트 기안을 동작하는 SocketAsyncEventArgs 를 사용하여 아주 편하게 코드 구성을 할 수 있었다.유저들이 많이 몰릴 경우 처리 \-> 해당 부분을 여러개 생성하

Receive 하는 부분을 새로운 Session Class로 구분하여 코드를 정리하고, listener 처리와 동일하게 SocketAsyncEventArgs를 사용해 비동기 처리를 제작하였다. 오늘은 이어서 Send 부분을 처리할 것이다.지난 시간 Receive는 사용

Accept, Receive의 비동기 처리까지 완료하고, send를 비동기 처리하는 작업을 하였다. 하지만 아직 효율적이게 개선이 완료된 것이 아니기에 오늘도 이어서 개선해나아갈 예정이다.\_sendArgs는 버퍼 사이즈 설정 이슈로 receive 처럼 새로 생성하고

버퍼를 하나씩 보내는게 아닌, BufferList를 활용하여 버퍼들을 한 번에 담아 보내는 방법으로 수정을 하고, 그 과정 중에서 배열의 일부분을 받을 수 있는 ArraySegment< T >를 배워 적용하였다.Send를 할 때는 지난 번 구현한 것에서 처리를 하

클라이언트와 서버간의 통신은 당연하지만, 서버만 있는 곳에 왜 Connector가 필요할 까 의문이 들 수 있다.이유는 게임 서버를 구축하다 보면 서버가 여러개 제작 되기도 하는데, 이때도 서버끼리도 한 명은 요청을 보내고 받는 구조이다. 결국 서버 끼리도 연결 요청이

TCP/IP 프로토콜 을 학습할 당시에 간단하게 알고 넘어갔지만 패킷 통신처리를 하기 위해서는 TCP는 뭐고, UDP랑은 어떤 차이가 있는지 이해해야 처리를 할 수가 있다.TCP로 구성시에는 요청시에 100bytes를 요청해도 상황에따라 30bytes 만 처리하고, 나

TCP와 UDP가 뭔지 조금 더 자세하게 알아보고, 이번 프로젝트를 제작해보며 사용하게 될 TCP에 특성에 대해 알아봤다.TCP의 특성중 현재 처리 가능한 패킷만 받고, 나머지는 나중에 처리하는 것이 있는데 이럴때 상황을 처리하기 위해 코드 작업을 해놓아야 한다.시작시

Receive Buffer를 제작하여 하드 코딩식이 아닌, 패킷 처리가 됐을 때도 적용 가능하도록 틀을 구성하였다. 기존 Send는 Encoding 하여 byte타입으로 넘겨주고, SendQueue에 저장하며 처리하는 방식이었다. 이번에는 이 부분을 개선 해줄 것이다.

Open()을 통해 큰 사이즈를 만들고 사용한 만큼 Close()에 넣어 할당하며, 큰 사이즈의 크기에서 점점 채워가며 사용하는 방식의 SendBuffer를 제작하였고 이제 본격적으로 패킷 작업을 위해 구성을 해놓을 것이다. 패킷의 값으로 구분하기패킷을 전송하는 방식을

간략하게 Send 처리를 하던 부분을 조금 더 효율적으로 개선하는 작업을 배웠다. 오늘도 이어서 더 개선할 수 있는 부분을 찾아 개선할 것이다.string이나 list 같은 타입이 추가 될 경우 단순하게 숫자 넘겨주는 방식으로는 진행이 어려워 압축하여 보내는개념 Cla

serialization, deserialization. 직렬화와 역직렬화 작업을 간단하게 실험해보며 현재 부족한 부분의 코드를 개선하는 작업을 하였다.지난시간에 열심히 개선해준 OnConnected에서 buffer를 날려준 부분을 더 사용하기 편하게 PlayerInf

지난시간

long은 8바이트, short은 2바이트 이렇게 크기가 정해져있지만 string 타입의 경우는 정해져있지 않기에 넘기기 어렵다. array write slice로 변경 read도 slice로 변경 string을 어떻게 넘길지 고민 c#에서는 string, cha

지난 시간 int, short 같은 사이즈 크기가 정해져있는 것과 다르게 string 타입은 입력 값에 따라 변하기에 다른 방법으로 처리를 해주어여했다. 하지만 새로운 방법이 아닌 기존 처럼 string을 얼마나 사용할 건지 미리 넘겨주고, 그 만큼 메모리에 할당하는

지난시간 Packet Generator 자동화는 하드코딩으로 진행하여 구성한 뒤 자동화할 수 있는 부분으로 돌릴 수 있다. XML 추가 XML 읽어오기 기존에 하드코딩 내역 복사하여 고정영역과 변동영역을 구분하기 ![](https://velog.velcdn.c

간단하게 패킷 자동화를 어떻게 할 수 있을지에 대한 개념이해를 위해 큰 틀을 짜놓는 작업을 하였다. xml파일에 담긴 데이터를 읽어와 각 타입에 맞게 변화시키는 작업이 귀찮지만 굉장히 유용해서 추후 다른 프로젝트에서도 종종 사용할 수 있을 것 같다.기존에 using문을

PacketFormat이라는 Class를 통해 패킷 처리 코드를 자동화하는 작업을 하고, 완성된 코드를 기존 코드에 대체해보며 잘 동작하는지 테스트해보았다. 오늘도 이어서 이 자동화 코드를 개선해볼 것이다.계속 코드를 수정하면 Client, Server를 왔다갔다 하며

✅ 지난 시간 PacketId가 담긴 Enum을 포함하여 FileFormat을 새로 추가해주고, byte와 이중list 상황에서 테스트 해보며 대응코드를 작성해주며 자동화를 더 개선하였다. PDL 문서 자동화 지난 시간 PDL 생성하여 복사한 뒤에 Debug 폴더에

Interface - Protocol 상속 interface abstact 차이? PacketHandler 해당 패킷이 다 조립이 되었으면 무엇을 호출할지 도와주는 역할 PacketManager

Packet Generaotr의 마지막 작업.

클라에서 보낼 메시지 내용, 서버에서 어떤 사람이 보낸건지 확인하기 위한 id, 다시 뿌려줄 chat 내용 리스트가 아닌 딕셔너리로 관리해도 괜찮다. ClientSession을 새로 생성해서 그냥 보내주는 것이 아니라 Manager를 통해 생성해주고, 어떤 클라이

현재 클라에서는 하나의 유저만 접속하고 있는 상황이라, 이를 다수의 유저들이 접속하는 상황으로 변경해줄 것이다.서버 쪽과 동일하게 여기도 Manager를 만들어 대신 제작하여 넘겨주는 방식을 사용하자서버에서 작업했던 것과 유사하게 싱글톤 형식으로 만들어 주고, Gene

Chat 기능을 제작하며 어떤 식으로 구조가 돌아가는지 알 수 있었다. 다만 아래와 같은 악순환구조가 발생하였다. 이번에는 이를 개선하고자 한다.lock을 잡으면서 일처리를 하다보니 대기하는 쓰레드가 생김쓰레드 풀에서는 업무 처리가 느려지니 쓰레드가 부족한가 싶어 추가

지난 시간에 Action과, 람다를 이용해 함수를 담고 실행시켜주었다. 이와 다른 방법도 가능해서 테스트를 해보고자 한다.TaskQueue라는 새항목을 생성하고, interface ITask를 생성 하고 Excute() 라는 함수 틀 하나를 만들어 준다.일 처리에 필요

지난 시간 지난 시간에 foreach로 broadcast를 하는건 유저가 증가할 수록 비효율적이기에 '패킷 모아 보내기' 라는 방법을 사용하기로 하였다. 패킷을 저장해둘 위치는 그럼 이 패킷 모아보내기를 어디서 처리할 수 있을까? 크게 엔진과, 콘텐츠 쪽이 있는데 우

지난 시간에는 서버에서 Flush를 Sleep을 0.25초 마다 진행 시켜주었다. 다만 room이 많아지면 각 다른 시간이 될 수 있어 이런 방식으로 처리 할 순 없다. 그렇기에 일감마다의 시간 관리를 해주어야 한다. 첫 번째 방법