monstrosite

이번에는 기존의 패킷에서 Session들에서 수행하던Read와 Write를 패킷에서 수행할 수 있도록 변경해보겠습니다. 공통적으로 패킷의 구조를 다음과 같이 변경하였습니다.차후에 패킷의 클래스를 따로 선언하여 클라이언트와 서버가 갖게끔 구성하도록 수정하겠습니다. 1) Server와 Client 모두가 공통적으로 갖는 패킷 // 패킷의 인자를 설정하는 경우, 최대한 용량을 줄여주는 것이 좋음public abstract class Packet{ // 패킷의 용량 public ushort _packetSize; // 패킷의 아이디 public ushort _packetID; // 패킷을 읽고, 패킷에 쓰기 위한 함수 public abstract void Read(ArraySeg..

이번 포스트에서는 네트워크 통신에서의 직렬화에 대해 알아보겠습니다.직렬화는네트워크 뿐만이 아닌 다른 상황에서도 보편적으로 사용하는 단어입니다.그리고 네트워크 통신에서의 직렬화는 다음과 같이 사용할 수 있습니다. 1) 직렬화 : Send 버퍼안에 전송할 데이터를 압축하여 집어넣는 작업을 의미대표적으로 OnConnected 에서 수행하는 로직이 해당합니다.2) 역직렬화 : Recv 버퍼에 담겨진 압축된 데이터를 다시 원상태로 늘리는 작업을 의미대표적으로 서버의 OnRecvPacket과 클라의 OnRecv에서 수행하는 로직이 해당합니다. 이 포스트에 소개해드릴 직렬화와 관련된 작업은 자동화 이전에 자동화 작업이 어떻게 이뤄질 지 간략하게 알아보도록 하겠습니다. 1) 클라이언트1 - 1) Client{ // 기..

TCP 통신환경에서는상황을 고려하여 패킷을 완전하게 보내지 않고 내용의 일부를 잘라 전송합니다.이때, 패킷이 완전히 도착하지 않고 잘려서 오는 경우에잘려진 패킷을 올바르게 결합하는 여러 방법이 존재합니다. 이번 프로젝트에서는 패킷 별로 ID를 설정하여 잘려진 패킷을 결합하는 방식을 구현해보도록 하겠습니다.ID를 설정하는 경우에 인자로 패킷의 사이즈와 패킷의 ID를 우선적으로 설정해야 합니다.그리고 이렇게 우선적으로 설정되는 패킷의 메모리를 Header라고 부릅니다. Header를 구현하는 경우에는 용량을 최대한 줄이고,Header의 메모리도 Header에 기록할지 결정해야 합니다.이번 프로젝트에서는 Header에 Header의 메모리도 기록하겠습니다.따라서 Header의 메모리 크기도 Header에 포함..

기존의 프로젝트 코드는 TCP를 사용하여 네트워크 통신을 하는 경우, 상황을 고려하여 분할되어 전송된 패킷을 온전히 받지 못하는 문제가 있으므로이를 수정하도록 하겠습니다. 이때 RecvBuffer와 SendBuffer는 설계구조에서 약간의 차이가 존재합니다.RecvBuffer의 경우, 클라이언트(=유저)별로 보내는 데이터가 다르므로 Session 별로 다르게 생성하여 갖고 있습니다.하지만 SendBuffer의 경우 다른데, 일단 크기가 일정하고 또한 SendBuffer의 경우Session이 갖는 것이 아닌 Server가 직접 갖고 있게 됩니다.이러한 이유는 외부에서 Send할 데이터를 만든 다음 해당 데이터를 내부로 넘기는 방식은성능적인 문제를 발생시키므로 외부에서 Send를 처리하도록 하겠습니다.1) ..

이번 포스트에서는 TCP와 UDP를 적용하기 이전에 간단하게 이 둘을 훌어보도록 하겠습니다.TCP와 UDP 모두 OSI 7계층 모델을 5개로 나타낸 TCP/IP 모델의 4층에 위치합니다.  전송 계층에서 사용하는 프로토콜이며 두 프로토콜의 차이점을몇 가지 기준으로 비교해보도록 하겠습니다. 1. 연결 지향성의 시각1 - 1) TCP연결 지향의 시각으로 보면 TCP는 연결형 서비스입니다.연결을 위해 할당되는 논리적인 경로가 있고 전송 순서가 보장된다 1 - 2) UDP연결 지향의 시각으로 보면 UDP는 비연결형 서비스입니다.연결이라는 개념 자체가 없기에 논리적인 경로가 없고 전송 순서가 보장되지 않습니다. 2. 속도와 신뢰성의 시각2 - 1) TCP속도와 신뢰성의 시각으로 보면 TCP는 신뢰성은 높지만 속도..

이번 포스트에서는 Listen을 수행하는 Listener 말고도Connect를 수행하는 Connector를 만들어 보겠습니다. 이렇게 사용하는 이유는 사용 목적 - 사용 도구를 짝지을 수 있고, 혹시 서버와 다른 서버를 연결하는 경우에 유동적으로 대응할 수 있기 때문입니다. Connector의 코드는 다음과 같습니다.1) Connectorpublic class Connector{ // Session을 생성하고 리턴하기 위한 Func Func _sessionFactory; // 연결을 수행하는 함수 public void Connect(IPEndPoint endPoint, Func sessionFactory) { // 서버 소켓 생성 Socket socke..

이전 포스트에 이어서 계속 만들어보겠습니다.이번에는 Session이 아닌 클라이언트의 Connect 요청에 집중하는 Server의 Listener를 수정해보겠습니다.기존의 Main 코드에서 수행하던 Accept를 이제 Listener에서 수행해보도록 하겠습니다.이를 통해, 클라이언트가 아닌 서버가 수행하는 구조를 만들 수 있습니다. 1) Listenerclass Listener{ Socket _listenSocket; // Action과 다르게 리턴값이 존재하는 Func, 제네릭 자료형이 곧 리턴형이다 Func _sessionFactory; // Server의 Client 소켓의 초기 상태를 설정 public void Init(IPEndPoint endPoint, Func s..

이번 포스트에서는 기존의 Listener 예제에 Session을 추가하는 방식으로 멀티 네트워크를 구현하겠습니다.그리고 기존의 Listener의 역할을 조금 더 확대하여Listener에서 Accept를 수행하도록 하겠습니다.이런 방식으로 수정하는 경우, 클라이언트가 아닌 서버에서 안전하게 멀티 네트워크를 개시할 수 있습니다. 1) Session일단 현재 만들어진 세션은 서버에서만 동작할 예정입니다.세션은 크게 2가지의 역할을 수행합니다. 서버에서 클라이언트로 데이터를 전송 = Send클라이언트에서 전송된 데이터를 서버에서 받음 = Recv 따라서 위의 2가지 역할을 수행하기 위한 코드를 만들어보겠습니다.abstract class Session{ Socket _socket; // 만약, 클라이언..

기존의 소켓 프로그래밍 예제에는 치명적인 문제가 남아있습니다.치명적인 문제점은 바로 블로킹 즉, 동기 방식으로 서버가 클라이언트의 Connect 요청에 Accept를 수행한다는 것입니다. 동기 방식에서는 서버가 Connect 요청이 오기전그러니까 서버가 Accept를 수행하기 전까지는 다른 작업을 하지 않고 계속 기다리게 됩니다.그리고 이는 작업을 처리하는데 있어서 낭비로 이어지게 됩니다. 따라서 기존의 코드를 수정하여 논블로킹, 즉 비동기 방식으로 변경하여클라이언트로부터 Connect 요청이 오는 경우, Accept를 수행하고그렇지 않은 경우 다른 작업을 수행하는 방식으로 변경하겠습니다. 코드 작업을 하기 전,간단하게 동기와 비동기 방식을 시각적으로 표현해보았습니다. - 동기 방식(=블로킹) 서버에서 ..

서버 - 클라이언트 프로그래밍에서 소켓 프로그래밍은서버와 클라이언트 모두 연결을 위한 대리자, 즉 소켓을 이용하여 서로 연결하는 프로그래밍입니다.이때 서버와 클라이언트의 진행 방식에 있어서 서로 차이점이 존재합니다. 1) 클라이언트 단계의 소켓 프로그래밍클라이언트는 소켓을 준비하여 서버 주소로 Connect를 요청할 수 있습니다.그리고 Connect 요청이 받아들여진 후 서버 소켓을 통해 Session 소켓과 패킷을 서로 송신/수신할 수 있습니다. 2) 서버 단계의 소켓 프로그래밍서버는 클라이언트와 다르게 소켓 프로그래밍을 위한 준비 절차가 조금 복잡합니다.그 절차를 간단하게 다음과 같이 표현할 수 있습니다. 클라이언트로부터 접속 요청(=Connect)을 받는 Listener 소켓 준비준비된 Listen..