셩잇님의 잡동사니

패킷 직렬화 지난 시간에는 ushort, int 자료형과 같이 크기가 정해져 있는 자료형과는 다른 string 자료형의 패킷 Write, Read에 대해서 알아보았다. 이는 크게 2가지의 방법으로 나뉘어져 있는데, 먼저 String Packet의 사이즈를 확인하고 그 다음 내부 데이터 값을 전송하는 방법이었다. 그렇다면 오늘은 String에서 더 나아가 List 자료구조를 보낼 때에는 어떻게 처리해야 하는지에 대해서 학습해본다. 💷 List Packet 그렇다면 List Packet은 어떻게 넘겨줄 수 있을까? 예시를 들어 설명하기 위해 기존에 작업하던 PlayerInfoReq 클래스에 새로운 List를 추가하자. public List skills = new List(); { } public struct..

패킷 직렬화 지난 시간에는 유니코드와 인코딩의 기본적인 개념과 UTF-8, 16의 개념 및 차이점에 대해서 알아보았다. 이러한 지식을 바탕으로 오늘 배울 문자열 처리를 잘 학습해보자. 🧐 🚩 코드개선 Session Write 기존 코드는 아래 이미지와 같이 new Span을 사용하여 packetId, playerId 값을 세그먼트에 넘겨주었다. 이 부분을 보다 가독성 좋고 효율적으로 변경할 수 있다. 바로 매번 Span 변수를 사용하는 것이 아닌 Span 변수를 한번만 호출하고 선언하여 세그먼트의 값을 받아와 Span의 Offset 값만 변경하며 필요한 값들을 byte 타입으로 변경시켜 줄것이다. 변경된 코드를 보면 Span span을 선언하여 사용한다. 또한 기존 코드에서는 각 패킷의 사이즈를 하드코딩..

패킷 직렬화 지난 시간에는 Send(=Write)와 Recv(=Read) 두 메서드를 Packet이라는 최상위 부모 객체에 abstract로 선언하여 이를 각자의 패킷(PlayerInfoReq)에서 override 하는 작업을 통해 또 한번의 개선을 진행했다. 이번 시간에는 Serialization에 더 자세하게 알아보기 전에 인코딩과 UTF-8, 16에 대해서 알아보자. 🍦 유니코드 유니코드(Unicode)란? 유니코드는 글자들의 특별한 번호표 같은 것이다. 예를 들어, "A"는 유니코드에서 특정한 번호를 가지고 있고, "가"라는 한글도 또 다른 번호를 가지고 있다. 🧐 왜 이런 번호를 가지게 되었을까? 1. 글자를 쉽게 구분하기 위해 * 유니코드는 전 세계의 거의 모든 글자들을 포함하고 있습니다. 각..

패킷 직렬화 지난 시간에는 직렬화, 역직렬화의 개념과 이를 예시를 통해 이해하고 학습하였다. 물론 아직 개선이 필요한 부분은 많이 있지만.. 🤔 📌 직렬화 #2 Send 개선 지난 시간에 열심히 뜯어고친 OnConneccted 메서드 내부에서 buffer를 Send 하는 부분을 더욱 편리하게 사용하기 위해 이를 PlayerInfoReq 클래스 내부에 함수로 만들어 줄 것이다. 위 스크립트에서 빨간 줄로 그어진 부분을 개선할 것이다. 😋 먼저 사용하지 않는 PlayerInfoOk 클래스는 지워주고, Server 쪽에서 패킷을 읽는 부분(=역직렬화)도 매번 재사용 하기 위한 Read 메서드와, 패킷을 보내기 전 직렬화 하는 과정인 Write 메서드를 작성한다. public abstract class Pack..

패킷 직렬화 지난 시간까지 Session, Connector, RecvBuffer, SendBuffer, PacketSession 등 다양한 클래스를 만들어 패킷 통신에 대해서 진행해보았다. 또한 통신하는 과정에서의 개선, 최적화 등 다양한 방식의 작업 또한 추가적으로 진행해보았다. 이번 세션에서는 패킷 직렬화를 통해 String, List 등 다양한 타입을 가지는 자료형들에 대해서 어떻게 전송이 필요하고, 어떤 방식으로 압축해야 하는지 등 보다 자세하게 알아보자. 📌 직렬화 마이크로소프트 공식 홈페이지에 따르면 C#(.NET)에서의 직렬화란 '지속시키거나 전송할 수 있는 형태로 개체 상태를 변환하는 프로세스'를 뜻한다. 그렇다면 왜? 직렬화를 사용해야 하고 이용해야할까? 이는 간단하다. String, ..

네트워크 프로그래밍 지난 시간에는 SendBuff 클래스를 만들었다. 클래스 내부에는 버퍼로 활용해 줄 recvBuffer, 사용한 영역을 표기하는 usedSize, 남은 공간의 크기를 나타내는 FreeSize를 선언해준다. 또한 메서드로는 Receive와 같이 Open, Close 함수를 만들어었지만, Receive와는 다르게 Clean 함수는 만들어주지 않았다. 🤔 이 후, TreadLocal을 이용한 SendBufferHelper를 만들어 SendBuff 클래스 내부를 건드리지 않고 사용하였다. 패킷 전송하기 📤 패킷을 전송하는 방법까지 알아보았지만, 정작 패킷만 보았을 때 패킷의 사이즈가 어느정도인지 아직은 알 수 없다. 따라서 보통 패킷의 첫 번째 인자로는 사이즈를 넣어주고, 두 번째 인자로는 ..

네트워크 프로그래밍 지난 시간에는 ReceiveBuff를 만들어서 Read, Write Pos(=Segment)를 생성하였다. 이러한 과정에서 byte를 받아오고, 또 받아온 byte를 처리하는 로직을 작성하였다. 또한 중간중간 R/W Pos를 초기화해주는 Clear 함수, 작업이 완료 된 이후 OnRead, OnWrite 처리를 하는 메서드 또한 만들었다. 기존 Send의 문제점 기존 Send는 Encoding을 진행한 후, byte 타입으로 전환하여 이를 넘겨주고, 넘겨준 Send Queue에 저장하여 처리하는 방식으로 진행하였다. 이번 시간에는 기존에 Encoding으로 처리하던 방법을 이번에는 실질적인 패킷 데이터로 가정하고 넘겨 받기 위해 Send Buffer를 만들어 줄 것이다. 😎 Recei..

네트워크 프로그래밍 지난 시간에는 TCP와 UDP 각각의 개념들에 대해서 알아보고, 또 '차이점은 무엇이 있는가?'에 대해서 학습하였다. 오늘은 이전 시간에 학습한 것과 마찬가지로 TCP 특성 중 현재 처리 가능한 패킷만 받고, 나머지는 나중에 처리하는 흐름제어 및 혼잡제어 기능을 구현하여 어떻게 처리하는지 알아보며 구현한다. 기존 코드의 문제점 기존 코드는 시작 시 SetBuffer의 위치를 0으로 설정해놓았기 때문에 TCP 특성상 100byte를 보내어도, 80byte만 받았을 경우 문제가 발생한다. 왜냐하면 80byte의 위치부터 나머지 20byte을 다 받은 후에 처리를 해야하기 때문이다. 따라서 현재 얼마나 받았고, 받아왔는지를 처리하며 표시할 방법이 필요하다. RecvBuffer 클래스 제작 ..

네트워크 프로그래밍 지난 시간에는 Connector를 이용하여 ServerCore 프로젝트를 라이브러리화 하는 작업을 진행했다. 이번 시간에는 실질 적으로 패킷을 전송하고, 수신하는 부분을 만들 것이다. 그렇지만 우리 프로젝트는 현재 string으로만 데이터를 전송하고 있는데, 현업에서는 string 형태로 패킷을 전송하지 않기 때문에 이를 수정해야한다. 하지만 어떻게? 무슨 방법으로? 등 패킷 통신처리에 대한 다양한 대한 궁금증이 생기게 되는데 이 때 사용할 수 있는 방법이 TCP/UDP가 있다. 따라서 오늘은 TCP와 UDP에 대해서 다시금 알아보는 시간을 가진다. 예제 😎 간단하게 예를 들어보자. 우리가 아무것도 모르지만 TCP를 이용해 서버를 구성한다고 하면, TCP의 특징 떄문에 우리가 클라이언..

네트워크 프로그래밍 지난 시간에는 Session을 상속하는 과정과 총 4가지의 Event Handler(OnConnected, OnRecv, OnSend, OnDisconnected )를 이용하여 구현하는 시간을 가졌다. 이번 시간에는 Connector를 만드는 시간을 가진다. 👍 Connector를 만들기 전에, 왜 만들어야 할까? 클라이언트와 서버간의 통신은 당연히 필요하기 때문에 구현하는 것이 맞지만, 서버만 이용하고 있는 곳에 왜 Connecotr가 필요할까? 그 이유는 다음과 같다. 1. 현재 서버 코어 같은 경우에는 서버를 메인 용도로 만들고 있지만 커넥트, 샌드, 리시브 하는 부분은 사실 공용으로 사용하면 좋다. 2. 서버 또한 분산처리를 할 수 있기 때문에 서버끼리의 연결과 통신이 필요하다..

네트워크 프로그래밍 지난 시간에서 우리는 Session을 만들어 소켓 프로그래밍의 Receive 부분과 Send 부분을 분리하여 작업이 진행되도록 처리 했다. 오늘은 Recv 부분의 코드 로직을 서버 단과 컨텐츠 단을 나누어서 작업이 진행될 수 있도록 개선할 것이다. 이 작업은 이벤트 핸들러를 이용하는 방법과, 상속을 이용하는 방법이 있지만 루키스님은 상속이 보다 구현하기 쉽기 때문에 상속 방법을 통해 이를 구현한다. 😎 Session 클래스 내 상속 메서드 추가 먼저 우리가 무엇을 사용해야 되는지 다시 한번 생각해보아야 한다. 이를 곰곰이 생각해 나누어 보면 크게 4가지로 나뉘어 질 수 있는 것을 알 수 있다. 1. 어떤 클라이언트에서 접속을 했는지 알 수 있는 OnConnected 2. 클라이언트가 ..

네트워크 프로그래밍 지난 시간에서 우리는 새로운 클래스인 Session을 만들어 소켓 프로그래밍의 Receive 부분과 Send 부분을 분리하여 작업을 진행했다. 오늘은 이어서 Send 부분의 코드 로직을 조금 더 우아하게 사용하기 위해 개선할 것이다. Send 개선 class Session { Socket _socket; int _disconnected = 0; object _lock = new object(); Queue _sendQueue = new Queue(); List _pendinglist = new List(); SocketAsyncEventArgs _recvArgs = new SocketAsyncEventArgs(); SocketAsyncEventArgs _sendArgs = new So..

네트워크 프로그래밍 지난 시간에서 우리는 새로운 클래스인 Session을 만들어 소켓 프로그래밍의 Receive 부분을 분리하여 작업을 진행했다. 오늘은 이어서 Send 부분을 분리하여 비동기로 처리할 것이다. Send 비동기 처리 구현 Send는 Receive 와는 다르게 언제, 어디서, 얼마의 버퍼(Buffer)의 크기를 사용하여 보낼지 모르기 때문에 기존 구조와는 다르게 비동기 처리 구현이 필요하다. Send의 동작 구조는 기존의 Receive의 동작 구조와 유사하다. 하지만 Start 메서드에서 SocketAsyncEventArgs 클래스를 이용해 소켓을 생성했던 기존의 Receive와는 달리 Send에서는 이벤트만을 연결해 줄 것이다. 왜 이렇게 처리해야 할까? 기존의 Receive 동작 구조는..

네트워크 프로그래밍 우리는 이전 시간에 Accept를 비동기 함수로 변경했다. 그래서 해당 로직이 AcceptAsync 👉 RegisterAccept 👉 OnAcceptCompleted를 왔다갔다 하면서 호출이 되게끔 했다. 그러나 이 함수를 자세히 보면 '혹시 RegisterAccept 메서드 내 pending의 값이 false 처리가 되어 재귀적으로 뺑뺑이를 돌다 스택 오버플로우가 일어나지 않을까?'라는 의문이 들 수 있다. 그리고 이는 이론상으로는 가능하다. 하지만 이는 현실적으로는 일어날 수 없다. 왜냐하면 우리는 Init() 메서드 내부에서 Listen의 값을 10으로 설정해주었기 때문이다. 따라서 동시 다발적으로 pending의 값이 false로 뜨는 것은 현실적으로 일어날 수 없다. 또 현재..

네트워크 프로그래밍 현재 모든 코드가 Main 함수 내부에서 동작하므로 서버 코어 프로젝트 내에 리스너 클래스를 새로 생상하여 기존 코드들을 정리해주자. 리스너 클래스가 하는 일은 서버-클라이언트가 연결할 때에 사용할 소켓의 생성, 결합, 대기, 승인들의 작업을 리스너에서 처리한다. 즉 Block 함수로 사용되던 부분을 Non-Block 함수 형태로 변경하는 것이다. 왜 Non-Block 함수 형태로 수정해야 할까? 이는 지난 시간에 짤막하게 언급한바와 같다. Listener의 Accept() 메서드와 같은 함수들은 서버에서 실행하게 될 경우 클라이언트의 입장 요청이 들어오기 전 까지 값을 영영 리턴하지 않고 기다리게 된다. 따라서 우리가 기껏 만들어놓은 메인 쓰레드는 계속 일을 해야 하는데, Accep..

네트워크 프로그래밍 이론 오늘은 소켓 프로그래밍에 대해서 알아보는 시간을 가져보도록 하자. 그렇지만 다짜고자 바로 코딩을 시작하면 어렵기 떄문에 프로그램의 어떻게 동작하는지 전체적인 흐름을 알아보자. 😋 손님 가게 가게에 방문하고 싶은 손님 입구 만들기, 문지기 고용 - 문지기 교육 입장 문의 영업 시작 소통 (직원) 안내 (소통) 손님은 본인이 가게에 방문하는 것이 아닌 대리자를 통해 가게를 방문한다. 핸드폰을 통해 식당 번호로 입장 문의를 하고, 가게는 문지기를 통해 손님의 요청을 받을지 말지 결정하고, 만약 받게 되다면 가게 내부로 안내하게 되며 서로 소통이 가능한 상태가 된다. 이러한 상황을 소켓 프로그래밍에 대입하면 아래와 같은 구조가 된다. 즉 클라이언트가 손님의 역할을 맡고, 가게가 서버의 ..

네트워크 프로그래밍 통신 모델에 대해서 알아보자. 컴퓨터 공학을 배웠다면 이는 OSI 7 계층에 해당하는 개념이다. 다시 예제를 살펴보자. 우리는 지난 시간에 택배 예제를 학습하며 같은 단지, 다른 단지 내에서 전송할 때에 어떻게 해야 하는지 학습했다. 그러나 사실 택배를 어떻게 보낼 지에 대한 방법이나, 무엇을 보낼지, 어덯게 보낼지에 대한 방법은 하나도 생각하지 않은 것이다. 따라서 택배를 보낸다면 아래와 같은 추가적인 정책이 필요하다. 이를 네트워크 단계로 다시 표현하자면 상품은 어플리케이션 단계와 같다. 이는 유저 인테페이스를 정의하는 것이다. 웹 통신을 사용하면 HTTP, 파일 다운로드를 한다면 FTP 등을 사용하는 것이다. 배송 정책은 트랜스포트 단계와 같다. 전송을 어떻게 확인하고 오류를 처..

네트워크 프로그래밍 멀티쓰레드 프로그래밍이 모두 마치고 네트워크 프로그래밍으로 파트로 넘어왔다! 😎 사실 클라이언트 개발자는 네트워크 분야까지 알아야 할 필요성은 없지만 우리는 서버를 사용해야하기 때문에 네트워크까지 학습한다. 따라서 서버의 안전성 및 보안 등을 관리해야 하기 떄문에 네트워크가 어떤 구조로 어떻게 이루어져 있는지 알 필요가 있다. 고로 기초적인 네트워크 지식이 필요하다. 네트워크 패킷을 보내는 방식은 택배를 보내는 방식과 매우 유사하다. 우리가 택배를 보내려고 하는데, 받는 사람이 같은 아파트 단지 내에 있는 사람이라면 받는 사람의 집까지 찾아가서 택배를 놓고 오면 된다. 그러나 이 방법은 아파트 단지 내에 호수가 많아지면 문제가 생긴다. 같은 아파트 단지여도 여러 호수가 있어 받는 사람..

멀티 쓰레드 TLS(Thread Local Storage) 쓰레드마다 고유하게 접근할 수 있는 전역 변수. TLS는 왜 필요할까? PPT와 예제를 통해 알아보잣! 🤠 우리는 락을 이용해 화장실처럼 동시 다발적으로 사용해야 하는 공간을 자물쇠를 이용해 사용하는 방법에 대해서 알아보았다. 여기까지만 보면 아름답지만, 현실은 녹록치 않다. 왜냐하면 주방에서 일어나는 일, 결제, 손님 테이블에서 일어나는 일 모두 각각의 직원이 대략적으로 현재 상황이 어떻게 이뤄지고 있는지 알아야 되기 때문이다. 즉 위의 이미지의 화살표처럼 일이 일사천리로 수월하게 처리되는 것이 아니라는 것이다. 그렇다면 락을 이용해 경합이 일어날 만한 곳에 락을 잡으면 되지 않을까? 생각할 수 있다. 하지만 이도 녹록치 않다. 왜냐하면 직원들..

멀티 쓰레드 ReaderWriterLock을 구현해보자! 먼저 소스코드가 길어질 수 있으므로 ServerCore의 새로운 스크립트를 Lock.cs로 만들어주자. namespace ServerCore { class Lock { int _flag; } } 새로운 플래그를 위와 같이 설정하자. 플래그는 int형 변수를 사용하기 때문에 32비트를 가지게 된다. 우리는 32비트의 구조를 이용하여 Write의 영역과 Read의 영역을 구분할 것이다. 맨 앞의 1번 비트는 사용하지 않는다. 왜냐하면 해당 값을 사용하게 되면 음수의 값을 사용하기 때문이다. 따라서 우리는 2번 비트부터 16번 비트까지는 WriteThreadID의 영역을 이용해 쓰레드 아이디를 저장하고, 17번 비트부터 32번 비트까지는 ReadCoun..