광란의 공부 일지

우리가 지금까지 사용해왔던 소켓은 블로킹(Blocking) 방식 소켓이다. 우리가 통신을 하면서 사용했던 함수들이 언제 완료되는지 한 번 보자. accept -> 접속한 클라이언트가 있을 때 connect -> 서버에 접속 성공했을 때  send, sendto -> 요청한 데이터를 송신 버퍼에 복사했을 때 recv, recvfrom -> 수신 버퍼에 도착한 데이터가 있고, 이를 유저레벨 버퍼에 복사했을 때 이렇게 어떠한 행위가 끝날 때 비로소 함수가 종료된다. 함수가 실행되는 동안에는 대기를 해야한다는 뜻이다. 말그대로 블로킹(Blocking) 당하는 것이다. 게임을 한 번 생각해보자. 몇 천 명이 동시에 서버에 접속을 한다고 할 때 저렇게 대기를 하면 당연히 문제가 생길 수 밖에 없다. 그렇다고 접속을..

이번에는 간단하게 소켓 옵션을 설정하는 방법에 대해 알아보자. 소켓을 만들 때 기본적으로 커널에서 샌드, 리시브 버퍼(송수신 버퍼)가 만들어진다. 이 버퍼도 크기를 변경하는 등 프로그래머가 옵션을 설정할 수 있다. ::setsockopt();::getsockopt();이 두 함수를 통해 옵션을 설정하고 가져올 수 있다. 자세한 내용은 마이크로소프트 공식문서에 잘 나와있다. https://learn.microsoft.com/ko-kr/windows/win32/api/winsock2/nf-winsock2-setsockopt setsockopt 함수(winsock2.h) - Win32 appssetsockopt 함수(winsock2.h)는 모든 형식의 소켓과 연결된 소켓 옵션의 현재 값을 모든 상태로 설정합니..

TCP 서버를 알아보았으니 이제 코드를 수정해보면서 UDP 서버에 대해 알아보자. 일반적으로 TCP는 안정성이 높고 패킷의 도착순서를 보장하는 반면 UDP는 그렇지 못하지만 속도가 빠르고 바운더리(패킷과 패킷 사이의 경계)가 존재한다는 특징이 있다. 두 가지 전부 장단점이 있으므로 필요에 따라 적절한 프로토콜을 사용하면 된다. 채팅이나 아이템 거래 등과 같이 데이터가 유실되면 문제가 생기거나 패킷 수신의 순서가 중요한 경우 TCP를 사용하면 될 것이고, FPS와 같은 실시간 통신 게임이나 스트리밍 서비스와 같이 빠른 반응이 필요할 경우 UDP를 사용하면 될 것이다. DummyClient.cpp#include "pch.h"#include #include #include #include #pragma com..

간단한 서버의 구조를 만들어보았으니 이제 데이터를 보내고 받는 작업을 해보자. Dummyclient.cpp#include "pch.h"#include #include #include #include #pragma comment(lib, "ws2_32.lib")int main(){ // 윈속 라이브러리 초기화 (ws2_32 라이브러리 초기화) // 관련 정보가 wsaData에 채워짐 WSAData wsaData; if (::WSAStartup(MAKEWORD(2, 2), &wsaData) != 0) return 0; // af : Address Family (AF_INET = IPv4, AF_INET6 = IPv6) // type : TCP(SOCK_STREAM) vs UDP(SOCK_DGRAM) // ..

드디어 뭔가 통신같아 보이는 파트로 넘어왔다. 바로 코드부터 살펴보자. DummyClient.cpp#include "pch.h"#include #include #include #include #pragma comment(lib, "ws2_32.lib")int main(){ // 윈속 라이브러리 초기화 (ws2_32 라이브러리 초기화) // 관련 정보가 wsaData에 채워짐 WSAData wsaData; if (::WSAStartup(MAKEWORD(2, 2), &wsaData) != 0) return 0; // af : Address Family (AF_INET = IPv4, AF_INET6 = IPv6) // type : TCP(SOCK_STREAM) vs UDP(SOCK_DGRAM) // prot..

저번의 메모리 풀에는 뭔가가 아쉬운 부분이 있다. 직접 구현한 메모리 풀에서는 사이즈가 비슷한 객체들을 하나의 풀에 넣어서 관리를 했다. 사이즈가 조금이라도 다른 객체들이 같은 풀에 있다보니 해당 풀에서 메모리 오염이 발생할 가능성이 있다. 만약 어떤 한 클래스에서 오류가 났다면 그 클래스의 코드만 살펴보면 되지만 이런 경우 어디서 오류가 발생했는지 탐지하기도 굉장히 힘들다. 그래서 이번에 알아볼 것이 오브젝트 풀이다. 생각해보면 알겠지만 메모리 풀이 오브젝트 풀의 상위 개념이다. 오브젝트 풀을 포함하고 있다는 것이다.  ObjectPool.h#pragma once#include "Types.h"#include "MemoryPool.h"templateclass ObjectPool{public: templ..

ABA Problem이라는 것이 있다. CAS(Compare And Swap)에서 오류를 감지하지 못하는 것인데 쉽게 예시를 설명하자면 이렇다. 10 -> 20 -> 30 과 같이 리스트로 연결된 데이터가 있다고 하자.A 스레드가 CAS를 이용하여 제일 앞의 10을 40으로 바꾼다고 해보자. 그렇다면 10 -> 20 -> 30이라는 리스트를 저장 후 '만약 제일 앞의 데이터가 10이면 40으로 바꾸어라' 이렇게 작동할 것이다. 하지만 멀티스레드 환경에서 CAS를 실행하기 전 다른 여러 스레드에서 pop 2번이 일어나 10과 20의 메모리가 반환 되고, push 1번 일어나서 10이라는 메모리를 재활용해 다시 할당 받았다고 가정하여 10 -> 30이 되었다고 생각해보자. 그렇게 되면 제일 앞의 데이터는 1..

지금까지는 필요할 때 메모리를 할당하고 사용이 끝나면 해제하였다. 하지만 매번 할당하고 해제하는 것이 비효율적이라고 느낄 수도 있고 메모리 단편화에 대한 문제도 있다.(요즘은 할당기가 잘 되어 있어 단편화에 대한 문제는 크게 신경쓸 필요는 없다고 한다.) 풀이라는 것은 직역하면 수영장 뭐 이런 뜻인데 수영장에 물을 담아놓는 것처럼 메모리를 담아놓았다가 필요할 때 꺼내 쓰는 것이다. 메모리를 사용하고 해제하는 것이 아니라 그냥 풀에 스윽 던져놓는 것이다. 그래서 매번 할당하고 해제할 필요성이 없다. 객체단위로 풀링을 하는 오브젝트 풀링이라는 것을 들어보았을 것이다. 하지만 우리가 동적할당할 것들은 객체뿐만 아니라 벡터, 맵 등 다양한 자료구조에 대해서도 동적할당을 해야한다. 이런 상황(크기가 일정하지 않음..

일반적인 클래스나 자료형은 지금까지 했던 Allocator를 이용하여 메모리를 할당하고 해제할 수 있었다. 메모리 오염 또한 방지할 수 있었는데 벡터나 맵 등 다른 자료구조에 대해서는 아직 내부적으로 new, delete를 사용하고 있을 것이다. 이번에는 이를 한 번 수정해보자.벡터 클래스의 선언부를 보면 타입과 Allocator를 지정할 수 있다.vector> v;이런식으로 사용할 수 있다는 뜻이다!!! 하지만 매번 위와 같이 지정할 수는 없으므로 헤더파일을 하나 만들어보자. Container.h#pragma once#include "Types.h"#include "Allocator.h"#include #include #include #include #include #include #include #i..

메모리가 이미 해제되었는데 사용하거나 사용할 수 있는 범위를 넘어서 사용하는 등 유효하지 않은 메모리 영역에 접근하는 것을 메모리 오염이라고 한다. 메모리 오염의 경우 크래시가 나지 않을 때도 있어 프로그램에 치명적일 수 있다. 예를 들어 허용된 범위를 넘어 메모리에 접근을 했는데 이미 다른 객체가 사용중인 메모리라던가 아니면 게임같은 경우 골드와 같이 유료재화를 담당하는 메모리라고 생각해보자. 이러한 상황을 예방하기 위한 것이 바로 Stomp Allocator이다. Allocator.h//-------------------// StompAllocator//-------------------class StompAllocator{ enum { PAGE_SIZE = 0x1000 }; // 4kbpublic..