Index's Tistory

[Network] HTTP 프로토콜 분석

index1207 — Sun, 10 Nov 2024 22:11:15 +0900

HTTP 프로토콜이란

웹에서 이루어지는 통신에 사용되는 네트워크 프로토콜. TCP기반 소켓을 기반으로 구현된다.

프로토콜 구조

HTTP 프로토콜에서 통신은 클라이언트 측이 요청(Request)을 보내면 서버가 그에 대한 응답(Response)을 보내 통신하는 방식을 사용한다. 요청과 응답은 CRLF(\r\n)를 사용해 개행을 구분한다.

Request

Request의 구조는 Startline, Header, Body로 나뉘어져 있다.

Start line
- ex.) GET / HTTP/1.1
- 메서드, 경로, HTTP 프로토콜 버전이 포함된다.
Header
- Connection, Accept, Date등의 추가 정보가 포함되어 있다.
Body: POST 메서드를 사용할 때 추가 정보를 담을 수 있다.

GET / HTTP/1.1
Accept: text/plain
Connection: close

Request Method

Request를 보낼 때 start line에서 Method를 사용해 요청을 보낸다. 종류는 다음과 같이 있지만, 주로 쓰이는 것은 GET과 POST이다.

GET: 리소스를 요청하는 기본적인 메서드. 리소스를 URL에서 query형태로 요청하므로 Body가 필요하지 않다.
POST: 리소스를 요청하는 메서드. GET과 달리 URL에 표현하지 않고, Body에서 리소스를 요청한다.

Request Header

Accept: 원하는 타입의 데이터의 우선순위
- ex.) text/html, text/plain, image/jpeg, ...
- ex.) text/*, */*
Connection: 연결 유지(keep-alive)에 대한 옵션
Date: 요청을 생성한 시간

Response

Status line
- HTTP 프로토콜 버전, 상태 코드, 상태 메세지가 포함된다.
Header
- Content type, content length 등, 응답에 대한 추가 정보가 포함되어 있다.
Body
- 요청에 대한 응답의 컨텐츠 데이터가 들어간다.

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 13

Hello, World!

Response Header

Content-Type: 응답 데이터에 대한 데이터 타입
Content-Length: 응답 데이터에 대한 길이
Date: 응답을 생성한 시간

URL 구조

URL의 구조는 기본적으로 다음과 같이 프로토콜, 호스트, 포트, 경로로 이루어져 있다.

${프로토콜(https, https)}://${호스트}:${포트(기본80)}/${경로}

브라우저에서 경로를 지정해 입력해보면 GET이나 POST를 사용해 Request를 지정된 서버로 송신하게 된다.

GET 같은 경우 경로에 ?변수=값 과 같은 형태로 query를 추가하는 것도 가능하다.

[C#] Disposable과 using문

index1207 — Mon, 14 Oct 2024 12:44:45 +0900

Disposable

C#에선 객체의 할당과 해제를 GC가 관리한다. 하지만 GC는 관리되지 않은 리소스를 인식하지 못하고, 자주 작동하게 되면 성능에 오버헤드가 발생한다.

Disposable은 이런 단점을 해결한 인터페이스이다. using 블럭을 벗어나면 자동으로 Dispose메서드를 호출하고 할당해제하여 성능을 개선시킬 수 있다.

인터페이스는 IDisposable과 await using에서 사용할 수 있는 IAsyncDisposable이 있다.

using문

다음과 같이 Disposable객체를 생성하고 using블럭 안에서 사용이 가능하다.

using (var object = new DisposableClass())
{
	...
}

예제

class DisposableClass : IDisposable
{
	public DisposableClass()
    {
    	Console.WriteLine("Constructor()");
    }
    
    public void Dispose()
    {
    	Console.WriteLine("Destroyed");
    }
}

class Program
{
	static void Main(String[] args)
    {
    	using (var disp = new DisposableClass())
        {
        }
        Console.WriteLine("End");
    }
}

/*
	결과:
    Constructor()
    Destroyed
    End
*/

using문을 사용하지 않고 사용한다면 GC에 의해 객체가 관리되므로 Dispose메서드가 호출되지 않는다.

static void Main(String[] args)
{
	var object = new DisposableClass();
    Console.WriteLine("End");
}
/*
	결과:
    Constructor()
    End
*/

[Network] 차세대 IO 모델

index1207 — Wed, 11 Sep 2024 11:55:41 +0900

이전에는 윈도우 진영에선 IOCP, 리눅스 및 UNIX진영에서는 epoll, kqueue 등을 사용하고 있었다.

하지만 2010년대에 들어 구식 모델보다 더 향상된 차세대 IO모델이 발표되었다. 윈도우에서는 Windows Server 2012에 맞춰 IOCP의 확장 격인 RIO(Registered I/O)를 발표, 리눅스에선 커널 5.1 버전부터 io-uring을 사용할 수 있게 되었다.

윈도우의 RIO는 기존 IOCP에서 잦은 시스템콜과 유저모드와 커널모드 간 컨텍스트 스위칭이 잦아 CPU의 점유율이 높은 단점아닌 단점이 있었다. RIO는 이를 해결하기 위해 CP(Completion Port)를 '완료(Completion)'와 '요청(Request)'에 대한 원형 큐로 나누고, 유저모드와 커널모드간 공유하는 메모리를 통한 IO로 컨텍스트 스위칭을 현저히 줄였다.

리눅스의 io-uring은 RIO와 같이 '완료(Completion)'와 '제출(Submission)'을 원형큐로 만들어 IO를 처리하고, 유저모드와 커널모드가 공유하는 메모리를 통한 컨텍스트 스위칭을 줄인 것은 동일하다.

RIO와의 차이점이라 한다면 RIO의 경우 쓰기/읽기 밖에 지원하지 않아 accept, connect와 같은 것은 이벤트를 사용하거나, IOCP를 이용해야 한다. 또한 IOCP와 혼합해서 사용한다면 코드가 복잡해지고, 개발 중 제한사항 등이 꽤 많이 존재한다.

io-uring은 accept, connect, read, write 등을 모두 지원하고 인터페이스와 같은 것도 매우 심플해 사용하기 매우 간단하다. 그리고 리눅스 커뮤니티, man7 등 비교적 정보가 많다.

나는 되도록이면 IOCP를 사용하는 것을 추천한다. RIO가 발표된지도 10년이 넘었지만 정보가 많이 부족하고, 또 실제로 사용하는 회사는 국내에 NC소프트밖에 없다 생각해도 될 정도로 없다. 게다가 RIO로 바꾸면서까지 얻는 효용성이 없어 추천하지 않는다.

[C++] 메모리 뷰에서의 다중 상속, 캐스팅

index1207 — Thu, 15 Aug 2024 16:21:11 +0900

만약 public을 통해 다중상속을 한다면 static_cast를 통해 쉽게 상위 클래스로 형변환이 가능하다.

하지만 부모의 멤버를 감추기 위해 private으로 상속한다면 static_cast를 사용할 수 없다.

struct A {
	unsigned int data;
};

struct B {
	unsigned short data;
};

class C : A, B {
public:
	C() {
		A::data = 0xA;
		B::data = 0xB;
		C::data = 0xC;
	}
	unsigned char data;
};

다음과 같은 상황이라고 치자. 이때 클래스 C로 변수를 만들면 메모리 뷰 관점에서는 다음과 같을 것이다. (public 상속을 해도 같은 결과가 나온다)

[A:4byte][B:2byte][C:1byte]

만약 c의 주소를 통해 B로 reinterpret_cast 한다면 A의 주소값을 기반으로 캐스팅되기 때문에 컴파일은 가능하지만, 원하는 값을 얻어오기는 불가능하다.

쉽게 해결하기 위해서는 그냥 public 상속을 하는 것이지만, 나는 어떻게는 상위 클래스를 감추고 싶다면 다음과 같은 방법이 있다.

reinterpret_cast<B*>(reinterpret_cast<A*>(&c)+1)->data = 0xD;

매-우 불편하지만 가능은 하다.

과정은 A로의 형변환을 통해 주소크기를 4로 바꾼 뒤, 주소 다음값을 B로 형변환한 것이다.

[C++] vcpkg 라이브러리 패키징

index1207 — Wed, 7 Aug 2024 18:41:49 +0900

소개

vcpkg는 microsoft에서 개발한 패키지 매니저로, 파이썬의 pip와 같이 커맨드라인을 통해 패키지를 설치할 수 있도록 하는 프로그램이다.

이 글에서는 내가 직접 Microsoft/vcpkg 레포지토리에 PR을 올려 머지된 경험을 바탕으로 작성되었다.

더 자세한 내용은 여기를 참고해보자.

순서

vcpkg에 새로운 패키지를 업로드하는 과정은 다음과 같다.

CMakeList 수정
vcpkg 포크(fork) 후 리모트 변경
port 작성 후 커밋 & push
최종적 PR 보내기

vcpkg에서 port란

vcpkg에는 우리가 작성한 라이브러리 코드가 들어있지 않고, 저장소의 이름과 버전 SHA 해시를 가지고 있다.

우리가 작성해야 하는 port는 각각의 라이브러리의 버전과 설치 방법에 대한 내용이 담겨있는 정보이다.

사용자는 개발자가 작성한 port를 통해 원격 저장소를 통해 라이브러리를 설치하게 된다.

1. CMakeList 수정

먼저 라이브러리의 CMakeList.txt를 수정해보자. 만약 Visual Studio나 Xcode를 사용하고 있다면 CMake로 전환하자. CMakeList.txt에서 수정 할 것은 vcpkg의 규격에 맞도록 네임스페이스와 export, install 명령어를 추가해야 한다.

대략적인 명령어 구문은 다음과 같다.

# definition
string(REPLACE "/${CMAKE_LIBRARY_ARCHITECTURE}" "" CMAKE_INSTALL_LIBDIR_ARCHIND "${CMAKE_INSTALL_LIBDIR}")
set(EXPORT_NAMESPACE "${PROJECT_NAME}::")
set(CMAKE_CONFIG_FILE_BASENAME "${PROJECT_NAME}Config.cmake")
set(CMAKE_EXPORT_FILE_BASENAME "${PROJECT_NAME}Export.cmake")

# install & export
install(TARGETS ${PROJECT_NAME}
        EXPORT ${PROJECT_NAME}
        INCLUDES DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}")
        
export(TARGETS "${PROJECT_NAME}"
        NAMESPACE "${EXPORT_NAMESPACE}"
        FILE "${CMAKE_EXPORT_FILE_BASENAME}"
        EXPORT_LINK_INTERFACE_LIBRARIES)

install(EXPORT "${PROJECT_NAME}"
        FILE "${CMAKE_CONFIG_FILE_BASENAME}"
        NAMESPACE "${EXPORT_NAMESPACE}"
        DESTINATION "${CMAKE_INSTALL_LIBDIR_ARCHIND}/cmake/${PROJECT_NAME}")

2. vcpkg 포크(fork) 후 리모트 변경

vcpkg가 설치되어있지 않다면 이 글을 참고해 설치하자.

먼저 vcpkg의 레포지토리에서 fork를 한 뒤, vcpkg가 설치된 디렉토리로 이동 후 다음 명령어를 통해 remote를 추가해주자.

> git remote add myfork <내가_포크한_vcpkg레포지토리_URL>

3. port 작성

port의 요소로는 portfile.cmake, usage, vcpkg.json이 있다. portfile.cmake는 라이브러리의 설치에 대한 정보를 작성하고, usage는 라이브러리의 타겟, vcpkg에는 라이브러리의 릴리즈 버전, 종속성을 작성한다.

먼저 작업할 branch를 만들고, vcpkg/ports/ 에 새로운 폴더를 만들어 작업하자.

※주의 파일의 맨 끝은 공백줄로 끝나야 한다.

vcpkg.json

{
  "name": <이름>,
  "version": <릴리즈_버전>,
  "description": <소개_및_설명>,
  "homepage": <홈페이지_URL>,
  "license": <라이선스>,
  "supports": <지원_플랫폼>
  "dependencies": [
    {
      "name": "vcpkg-cmake",
      "host": true
    },
    {
      "name": "vcpkg-cmake-config",
      "host": true
    },
    <추가_종속성>...
  ]
}

visual studio로 작성하게 되면 scheme를 자동으로 인식한다.

usage

<이름> provides CMake targets:

    find_package(<이름> CONFIG REQUIRED)
    target_link_libraries(main PRIVATE <CMAKE_네임스페이스>::<이름>)

portfile.cmake

vcpkg_from_github(
    OUT_SOURCE_PATH SOURCE_PATH
    REPO <레포지토리_URL>
    REF "${VERSION}" # VERSION은 vcpkg.json에서 작성한 version값이다. 깃허브의 릴리즈 태그와 일치해야 한다.
    SHA512 0 # 나중에 채워 넣을 예정
    HEAD_REF <메인_브렌치>
)


vcpkg_cmake_configure(
    SOURCE_PATH "${SOURCE_PATH}"
)

vcpkg_cmake_install()
vcpkg_cmake_config_fixup(CONFIG_PATH lib/cmake/<이름> PACKAGE_NAME <이름>)

file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/include")
file(INSTALL "${SOURCE_PATH}/LICENSE" DESTINATION "${CURRENT_PACKAGES_DIR}/share/${PORT}" RENAME copyright)

configure_file("${CMAKE_CURRENT_LIST_DIR}/usage" "${CURRENT_PACKAGES_DIR}/share/${PORT}/usage" COPYONLY)

추가적인 vcpkg명령어는 learn.microsoft를 참고.

작성이 완료됬다면 커맨드 라인으로 다음을 실행해 해시값을 추출해보자.

vcpkg install <이름>

그럼 애러와 함께 다음이 출력될 것이다.

Expected hash: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Actual hash: <해시값>

portfile.cmake의 SHA512에서 0으로 지정된 값을 출력된 해시로 변경하자.

다시 설치를 시도하면 설치에 성공하는것을 볼 수 있다.

설치에 성공했다면 다음 명령어를 실행해 vcpkg의 버전 데이터베이스에 추가하자.

vcpkg x-add-version <이름>

마지막으로 변경사항을 커밋 한 뒤 myfork로 push하자.

4. PR 보내기

최종적으로 패키지를 publish하기 위해 github에서 내가 fork한 vcpkg로 가서 PR를 보내보자.

PR의 형식은 다음과 같이 [<이름>] 요청사항 으로 작성하면 된다.

그리고 무수히 많은 체크박스가 있는데, 약관사항?이라 보면 된다. 하나씩 읽어본 뒤 체크하면 된다.

만약 마이크로소프트에 처음 PR을 보내면 봇의 코멘트가 올 수 있다.

마이크로소프트 기여에 대한 약관이므로 자세히 잃어본 뒤 @microsoft-github-policy-service agree 를 코멘트로 보내 약관을 수락하자.

PR을 보내거나, 새로 커밋을 한다면 깃허브에서 CI 액션이 시작될 것이다. PR 요청자는 모든 항목이 통과해야 master에 머지를 할 수 있게 된다. CI와 별개로 마이크로소프의 코드 리뷰어의 리뷰가 시작된다.

코드를 수정하게 된다면, 반드시 vcpkg x-add-version <이름> --overwrite-version를 통해 갱신시켜줘야 한다.

리뷰어의 모든 요청사항 수정을 마친다면 info:reviewed 태그가 붙게 된다. 다른 리뷰어의 approve를 받게 된다면 최종적으로 master에 머지가 된다.

이로써 vcpkg에서 내가 개발한 라이브러리를 설치할 수 있게 된다.

처음으로 마소에 PR을 보내는 정말 특별한 경험이였다. 물론 직접적인 기여는 아니지만, 대형 오픈소스의 개발 방식에 대한 경험을 쌓을 수 있는 정말 좋은 경험이 된 것 같다.

[C++] 제대로 알고 사용하자. atd::async

index1207 — Sat, 13 Jul 2024 00:28:08 +0900

서론

게임 서버 프로젝트에서 로직 스레드를 싱글로 변환했다. 로직스레드가 싱글로 돌아가기 때문에 I/O에서 블로킹이 일어나면 그만큼 처리의 레이턴시가 생기는 것이기 때문에 이를 개선하기 위해 데이터베이스 쿼리를 비동기로 실행하고, 완료 콜백을 호출할 시스템을 구현하기로 했다.

본격 비동기화 시키기

따로 데이터베이스 쿼리를 처리할 스레드를 생성할까 했지만, 스레드와 스레드가 데이터를 주고받는것 자체가 지연이 생길 수 밖에 없어 좋지 않아 보였다. 그렇다고 각 쿼리마다 스레드를 파는 것은 너무 효율이 떨어지는 방법이다.

가장 단순한 방법으로 task를 생각했다. task는 promise, future, packaged_task, async 등을 사용해 개발하는 것이다.

task의 구현 자체는 스레드의 wrapper이므로 느릴 수 밖에 없지만, 가독성 측면에서 월등히 좋다.

하지만 문제가 있다. cppreference에 따르면 std::async의 비동기적 실행은 potentially in a separate thread which might be a part of a thread pool, 즉 task에 대해 매번 새로운 스레드를 생성하지 않다고 된다는 것이다. 하지만 실제로는 GNU의 libstdc++의 경우, stackoverflow의 한 유저가 실험을 해본 후 올린 질문이 있다.

https://stackoverflow.com/questions/67034861/why-would-concurrency-using-stdasync-be-faster-than-using-stdthread

Why would concurrency using std::async be faster than using std::thread?

I was reading Chapter 8 of the "Modern C++ Programming Cookbook, 2nd edition" on concurrency and stumbled upon something that puzzles me. The author implements different versions of paral...

stackoverflow.com

이 질문에 대한 답변의 요약은 다음과 같다.

- 현재 libstdc++ 구현은 std::async는 각각의 task에 새로운 스레드가 필요하지 않다는 사실의 이점을 취하지 않습니다.
- 현재 libstdc++ 구현은 std::async는 std::thread가 수행하지 않는 일종의 잠금(lock)을 수행합니다.
- std::async와 std::launch::deferred는 설정과 파괴 비용을 절약합니다.

답변자의 말에 따르면 std::async는 매번 호출될 때마다 새로운 스레드를 생성하고, 오히려 더 많은 스레드를 생성한다는 것이다. 만약 정말 그렇다면 비동기 호출의 결과를 받아온다는 점 말고는 std::thread를 사용하는 편이 더 효율적이라는 것이다.

결론

인터넷에 널려있는 블로그를 보면 스레드를 풀링한다고 하는데 맞을 수도 있고 틀릴수도 있다. 결국 STL의 표준은 호출 인터페이스와 같은 것만 정해져 있기 때문에 내부 구현은 GNU나 Microsoft, Apple각각 모두 다를 수 있다. 그러므로 std::async이 풀링을 사용할 수도, 안할 수도 있다는 것이다.

std::async를 사용하는것은 이러한 점을 숙지하고 프로젝트에 알맞은 방향으로 사용하도록 하자.

[C++] C++에서 라이브러리를 관리해보자

index1207 — Thu, 27 Jun 2024 10:43:25 +0900

C++ 라이브러리 시스템

C++은 다른 언어들과 다르게 라이브러리가 소스파일이 아니라 라이브러리 바이너리와 헤더로 나뉘어져 있고,

컴파일 과정에 헤더의 경로를 등록시키고, 라이브러리 바이너리를 링크 시켜주어야 한다.

그로 인해 새로운 라이브러리를 사용할 때마다 따로 컴파일, include 경로, 라이브러리 링크 등을 설정해주어야 한다.

내가 사용한 기존의 방법

git에서 submodule로 라이브러리를 추가하고, 배치파일 스크립트를 통해 CMake로 각각을 빌드하고 특정 폴더에 라이브러리 바이너리를 복사했다. 그 후 비주얼 스튜디오 프로젝트 설정에서 라이브러리를 등록해 사용했다.

하지만 배치파일 스크립트를 통해 커스텀으로 라이브러리를 컴파일 하기때문에 새로운 라이브러리를 추가할 때마다 빌드 스크립트의 작성과 프로젝트 설정에서 일일이 추가해야한다는 문제가 발생했다.

패키지 매니저

비교적 최신에 개발된 언어들에는 패키지 매니저가 있어 커맨드라인이나 세팅 파일을 통해 모듈이나 라이브러리 등을 쉽게 추가할 수 있다. 예를 들어 python에서 stringcase라는 모듈을 추가하고 싶다면 pip install stringcase라는 하나의 커맨드라인으로 추가할 수 있다.

C++도 라이브러리 문제를 해결하기 위해 패키지매니저가 개발되었다. 대표적으로는 vcpkg와 conan이 있다.

이 글에선 가장 많이 쓰이고 있는 vcpkg를 중점적으로 알아볼 것이다.

vcpkg는 비주얼 스튜디오와 통합하여 사용할 수 있는 패키지 매니저로, vcpkg로 다운받은 라이브러리를 바로 비주얼 스튜디오에서 바로 사용 가능하다.

자동화된 프로젝트 구성

내가 원하는 것은 전역 로컬에서만 관리되는 것이 아니라 다른 사람들과 공유되도록 프로젝트에 설치해 사용하는 라이브러리 관리이다. 배치파일로 vcpkg를 통해 필요한 라이브러리를 전역으로 다운하도록 하는것도 좋지만, 가장 명확한 방법으로는 프로젝트에 라이브러리를 설치하는 것이다.

vcpkg는 'manifest 모드'라는 것을 지원한다. manifest모드는 vcpkg.json이라는 파일을 통해 사용할 라이브러리를 지정해 프로젝트에 설치할 수 있도록 해주는 기능이다. 이 기능을 사용한다면 다른 사람들의 환경의 차이를 어느정도 해결할 수 있고, 비주얼 스튜디오나 CMake에서도 vcpkg를 지원하기 때문에 CI 스크립트를 작성할 때도 용이하다.

끝으로

수동으로 라이브러리를 설치하다가 자동화된 툴을 사용해보니 정말 편한것 같다.

이 글을 보신다면 vcpkg로 프로젝트를 구성해보는것을 추천한다.

[C++/Unreal] 커스텀 RPC 구현 기록

index1207 — Fri, 31 May 2024 16:13:00 +0900

개발 배경

MMORPG 팀 프로젝트 기획 중 서버에서 혼자 구현하지 못할 만큼의 컨텐츠를 기획하게 되었다...

이 상황을 해결하기 위해 고민하던 중 포톤에서 사용하던 RPC방식이 떠올렸다.

RPC는 네트워크에서 복제된 객체에 대해 원격으로 함수를 호출해 서버에서 따로 로직을 구현하지 않고 클라이언트에서 구현하므로 개발 속도가 빨라지기 때문이다.

구현 이론

RPC를 구현하기 위해선 다음 정보를 직렬화해야 한다.

메서드 식별용 아이디
브로드캐스팅 타깃
RPC 호출자 아이디
메서드 인수 목록

클라이언트에서 RPC를 호출하면 데이터를 직렬화시켜 서버에게 보내고, 서버는 타깃에게 이 직렬화 데이터를 브로드캐스팅 하게 된다. 그 후 클라이언트에서 RPC 데이터를 받게 된다면 메서드 식별 아이디와 메서드 인수 목록을 역직렬화 시켜 호출하게 된다.

호출자 아이디가 자신이라면 내가 호출한 RPC이고, 아니라면 남이 호출한 RPC임을 알 수 있다.

본격 구현

첫번째로, 메서드 식별용 아이디를 만들어 보자. 나는 RPC 식별 아이디를 정수형 15자리의 비트로 만들어 줬다.

왜냐하면 RPC와 메세지 시스템을 같이 사용할 예정이기 때문에 상위 1비트를 통해 RPC인지, 메세지인지 판별하기 위함이다.

나는 매크로를 사용해 메서드에 RPC아이디를 부여해줄 것이다. 아래 매크로는 메서드 이름을 받아와

헬퍼 메서드를 만들어준다. 헬퍼 메서드는 메서드를 RpcView클래스에 등록하고 메서드 식별 아이디를 리턴한다.

#define THIS_CLASS std::remove_pointer<decltype(this)>::type /* 내 클래스 타입 얻어오기 */
#define RPC(Func) _RPC##Func() /* 헬퍼 메서드 */
#define RPC_FUNCTION(func) uint16 RPC(Func)\
						   {\
							   static auto RpcId = RpcView::Register(&THIS_CLASS::func);\
							   return RpcId;\
						   }\

RpcView클래스는 RPC 메서드를 관리하는 정적 클래스이다. Register를 호출하면 메서드가 RPC로 등록이 되고, 메서드 식별 아이디가 리턴된다.

template<class T, class... Args>
static uint16 Register(void(T::*RpcFunc)(Args...))
{
    auto RpcObject = new Rpc<T, Args...>(RpcFunc, ++RpcId); // 새로운 Rpc 객체 생성
    RpcInterface Interface // 템플릿 타입 단순화용 객체
    {
        .Owner = RpcObject, // 템플릿 객체를 담기 위한 void*
        .Execute = std::bind(&Rpc<T, Args...>::Execute, RpcObject, std::placeholders::_1)
    };

    RpcFuncTable.Add(RpcId, Interface); // Rpc 함수 등록
    return RpcId; // RPC 아이디 리턴
}

그 다음으로 메서드 아이디, 브로드캐스팅 타입, RPC 호출자, 그리고 인수 목록을 캡슐화 시킨 클래스인 Rpc클래스를 구현했다.

이 클래스는 템플릿으로 구현되어 있고, 주 역할은 인수를 직렬/역직렬화 시키고 메서드를 호출하는 역할을 한다.

Register를 호출될 때 Rpc객체가 생성되고, RpcView는 이 Rpc객체를 저장하고 있게 된다.

template<class T, class... Args> requires std::is_base_of_v<NetObject, T> // C++20's Concept
class Rpc : Packet // 직렬화 & 메세지 전송가능 클래스
{
public:
	Rpc(void(T::*RpcFunc)(Args...), uint16 Id) : Packet(Id, RPC), RpcFunc(RpcFunc)
	{
	}
public:
	void Execute(std::span<char> Buffer) // RPC 수신 후 호출
	{
    	...
	}
	void WriteParameter(Args... ArgsList)
	{
		*this << static_cast<uint8>(Target) << CallerId; // Target, CallerId 직렬화
		((*this << ArgsList), ...); // 인수 목록 직렬화
	}
	void ReadParameter(Args&... ArgsList)
	{
    	*this >> reinterpret_cast<uint8&>(Target) >> CallerId;
		((*this >> ArgsList), ...); // 인수 목록 역직렬화
		Reset();
	}
public:
    void SetTarget(RpcTarget NotifyTarget) { ... }
	void SetBuffer(std::span<char> Buffer) { ... }
	void SetCaller(uint16 Id) { CallerId = Id; }
private:
	uint64 CallerId; // 호출자 아이디
	RpcTarget Target; // 타깃
	void(T::*RpcFunc)(Args...); // 메서드 포인터
};

마지막으로 RPC를 호출하는 과정이다.

template<class T, class... Args>
static void Execute(void(T::*)(Args...), T* Owner, uint16 Id, RpcTarget Target, Args... ArgsList)
{
    auto RpcObj = static_cast<Rpc<T, Args...>*>(RpcFuncTable[Id].Owner);
    RpcObj->SetTarget(Target);
    RpcObj->SetCaller(Owner->GetId());
    RpcObj->WriteParameter(Forward<Args>(ArgsList)...);
    SendRpc(reinterpret_cast<Packet*>(RpcObj));
}

#define CallRPC(Func, Target, ...) Execute(&THIS_CLASS::Func, this, RPC(Func), Target, __VA_ARGS__);

RpcView::CallRPC(메서드, 타깃, 인수 목록...)을 통해 호출하게 된다.

먼저 Execute메서드를 보면, 첫번째 인수로 메서드를 받고, 다음으로 소유자, 메서드 아이디, 타깃, 인수 목록을 받는다.

첫번째 인수인 메서드는 꺾쇠(<,>)없이 템플릿 타입을 결정하기 위한용도이고, 3번째로 받는 아이디를 통해 RPC 데이터를 보내게 된다.

RpcView::Execute의 인수는 너무 길기 때문에 단축하기 위해 CallRPC라는 매크로를 만들었다.

위에서 이름으로 헬퍼 메서드를 추출하고 리턴을 통해 아이디를 가져와 간편화 시켰다.

마지막으로

최종적으로 구현한 RPC의 예제를 보면 다음과 같다.

// PlayerCharacter.h

...
	void CallRpcTest();
    
	RPC_FUNCTION(TestRPC)
    void TestRPC(int Data);
...

-------------------------------------------------------------------------------------

// PlayerCharacter.cpp

...
APlayerCharacter::APlayerCharacter()
{
	...
    RPC(TestRPC);
}

void APlayerCharacter::CallRpcTest()
{
	RpcView::CallRPC(TestRPC, RpcTarget::All, 100);
}

void APlayerCharacter::TestRPC(int Data)
{
	GEngine->AddOnScreenDebugMessage(-1, 5, FColor::White, FString::FromInt(Data));
}
...

BeginPlay이후에 CallRpcTest를 호출하면 TestRPC가 호출되는 것을 볼 수 있다.

[기타] 메모리 관리에 대하여

index1207 — Fri, 31 May 2024 12:28:37 +0900

프로그래밍을 할 때 메모리 관리는 필수 불가결하다.

프로그래머가 직접 메모리를 할당과 해제를 관리한다면 실수로 인해 사용 중인 메모리가 어떠한 이유로 해제되어 프로그램이 고장 날 수도 있고, 메모리 누수가 일어날 수도 있다.

이러한 문제를 해결하기 위해 직접 할당과 해제를 하지 않고 메모리를 관리하는 여러 시스템이 만들어졌다.

이 글에선 메모리를 관리하는 시스템 3가지를 소개하려 한다.

1. 참조 카운팅(Reference Counting)

이 방법은 주로 C++에서 사용되는 방법으로, 객체를 참조하는 카운팅을 통해 객체의 할당 해제 시점을 결정하는 방식이다.

C++에서 '스마트 포인터'를 사용해 카운팅 한다. 객체를 참조하면 카운트가 1이 늘어나고, 참조를 하는 객체가 소멸된다면 카운트가 1이 줄어든다. 최종적으로 카운트가 0이 된다면 메모리가 해제된다.

장점

가장 단순 명쾌한 방식으로, 사용자가 임의로 해제를 하지 않아도 알아서 해제가 되는 간편성이 있다.

단점

순환 참조: A라는 객체에선 B를 참조하고, B라는 객체에선 A를 참조하고 있을 때, 서로의 참조 카운트가 1이 되므로 영원히 해제가 되지 않는 문제가 발생한다. 물론 약한 참조라는 해결법도 있다.
성능 오버헤드: C++에서는 '복사 생성자'와 '대입 연산자'를 통해 카운트를 올린다. 하지만 불필요하게 반복되는 복사 연산은 오버헤드가 발생할 수 있다.

2. GC(Garbage Collection)

이 방법은 Java와 C#에서 사용되는 방법으로, Java로 개발한 프로그램을 작동시키면 자바 가상 머신(JVM)에서 Garbage Collector가 알아서 불필요한 메모리를 해제하는 시스템이다.

GC가 있는 언어라면 메모리의 할당과 해제는 개발자가 직접 관리하지 않아도 된다.

장점

개발자가 직접 메모리를 관리하지 않기 때문에 메모리로 인해 문제가 일어날 가능성이 거의 없고, 그로 인해 개발의 효율성이 높아진다.

단점

성능 오버헤드: Java에서 GC가 작동할 때 다른 동작이 중지됨과, 프로그램 이외로 GC가 작동해 CPU를 점유함으로 인해 성능의 오버헤드가 발생한다.
메모리 오버헤드: GC의 메모리 관리 알고리즘으로 인해 프로그래머가 의도한 메모리보다 더 많은 메모리가 과다 할당되는 메모리 오버헤드가 발생한다.

3. 소유권(Ownership)

이 방법은 Rust가 사용하는 제3의 방식이다. 컴파일 타임에 '소유권 규칙'에 따라 문법을 체크하는 방식을 사용해 메모리가 유효한지 체크하는 방식이다. (C++로 치자면 모든 객체가 unique_ptr인 셈)

소유권 규칙
- 각각의 '값'은 '오너(owner)'라고 불리는 변수를 갖고 있다.
- 하나의 '값'에 대해서는 하나의 오너만 존재할 수 있다.
- '오너'가 스코프 밖에 나갔을 때 '값'은 버려진다.

장점

컴파일 타임에 체크하므로, 런타임에 체크하는 GC방식에 비해 성능이 좋다.

단점

'소유권 규칙'으로 인해 문법 검사가 깐깐하게 진행된다.

[C++] 메모리 풀에서 new 무한 호출

index1207 — Fri, 3 May 2024 10:40:08 +0900

나는 메모리 풀을 구현할 때 다음과 같이 구현했다.

static T* Pop()
{
	T* ptr = nullptr;
    if (!m_pool.empty())
    	ptr = m_pool.pop();
    else
    	ptr = new T;
    return ptr;
}

하지만 Pop을 호출하는 순간 엄청난 new의 콜스택이 쌓여 스택 오버플로우가 발생했다.

아무리 생각해도 new가 new를 호출할 일이 뭐가 있지 싶었지만, 얼마 지나지 않아 이유를 찾았다.

바로 내가 풀링을 구현한 방식 때문이였다.

클래스에서 매크로를 사용해 new를 오버로딩하게 만들어 new를 호출할 때 오브젝트 풀에서 Pop을 호출하게 하는 식으로 구현했다.

ptr = new T;

그래서 이 코드에서 또 new를 호출하고 Pop을 하게 만드는 순환이 발생하게 된 것이였다.

이를 해결하려면 new 대신 크기로 메모리를 할당하는 전역 new나 malloc을 사용해주면 된다.