// Session.h
class SessionImpl;

class Session
{
public:
    Session() = default;
    ~Session() = default;
    
private:
    std::unique_ptr<SessionImpl> m_pImpl;
};

위와 같이 전방선언한 클래스의 객체를 삭제할 때에는 생성자와 소멸자에 default를 붙여주면 안된다.

조금 더 정확하게는 스마트 포인터 사용 또는 헤더파일에서 원시 포인터를 delete를 하는 경우이다.

class Session
{
...
    ~Session() { m_pUserManager.reset(); }
};

왜냐하면 해당 클래스의 원형을 모른채로 소멸자를 호출하는 것과 동일하기 때문이다.

그래서 불완전한 타입을 삭제할 수 없다는 오류가 발생한다.

// Session.h
class SessionImpl;

class Session
{
public:
    Session();
    ~Session();
};


// Session.cpp
#include "SessionImpl.h"

Session::Session() {}
Session::~Session() {}

해결법은 간단하다. 기본 생성자와 소멸자를 사용하더라도 default 키워드 대신 cpp에 명시적으로 정의해주면 된다.

주의할 점은 "생성자와 소멸자 둘 다" default 키워드를 사용하면 안된다.

서버 함수

int bind(
    SOCKET s, // 클라이언트 접속 수용을 목저긍로 만든 소켓
    const struct sockaddr* name, // 지역 IP 주소와 지역 포트 번호가 담긴 구조체의 주소
    int namelen // 소켓 주소 구조체 변수의 길이
);
// 반환값 : 성공(0), 실패(SOCKET_ERROR)

int listen(
    SOCKET s, // bind 함수에 의해 지역 IP 주소와 지역 포트 번호가 설정된 상태
    int backlog // 접속 가능한 클라이언트의 개수. 프로토콜의 지원 가능한 최대값은 SOMAXCONN
);
// 반환값 : 성공(0), 실패(SOCKET_ERROR)

SOCKET accept(
    SOCKET s, // 클라이언트 접속을 수용할 목적으로 만든 소켓
    struct sockaddr* addr, // 소켓 주소 구조체 변수의 주소
    int* addrlen
);
// 반환값 : 성공(new socket), 실패(INVALID_SOCKET)

클라이언트 함수

int connect(
    SOCKET s, // 서버와 통신하기 위해 만든 소켓
    const struct sockaddr* name,
    int namelen, // 구조체의 크기
);
// 반환값 : 성공(0), 실패(SOCKET_ERROR)

데이터 전송 함수

int send(
    SOCKET s, // 통신할 대상과 연결된 소켓
    const char* buf, // 보낼 데이터를 담고 있는 어플리케이션 버퍼의 주소
    int len, // 보낼 데이터의 크기
    int flags // 대부분 0 사용. MSG_DONTROUTE, MSG_OOB를 사용하는 경우도 드물게 있다
);
// 반환값 : 성공(보낸 바이트 수), 실패(SOCKET_ERROR)

int recv(
    SOCKET s, // 통신할 대상과 연결된 소켓
    char* buf, // 받은 데이터를 저장할 어플리케이션 버퍼의 주소
    int len, // 수신 버퍼로부터 복사할 최대 데이터 크기
    int flags // 대부분 0 사용. MSG_PEEK, MSG_OOB를 드물게 사용한다
              // 복사하고 나면 해당 데이터를 수신 버퍼에서 삭제하지만 MSG_PEEK 사용 시 삭제하지 않는다
);
// 반환값 : 성공(받은 바이트 수 또는 0), 실패(SOCKET_ERROR)

IOCP(Input/Output Completion Port)

IOCP는 다수의 클라이언트의 요청을 효율적으로 처리하기 위한 방법들 중 하나이다.

사용할 스레드를 미리 만들어두고 소켓에서의 IO가 완료되었을 때 잠들어있는 스레드를 깨워서 작업을 처리한다.

최적화 할 수 있는 스레드의 수는 프로세서의 2배 정도가 적당하다고 한다.

IOCP는 스레드를 관리하기 위해 1개의 스레드 큐와 2개의 스레드 리스트, 1개의 작업 큐를 사용하고 각 스레드는 3개의 큐중 하나의 큐에만 존재할 수 있다.

IOCP를 사용하려면 먼저 IOCP를 만들어야 한다.

HANDLE WINAPI CreateIoCompletionPort(
    _In_        HANDLE fileHandle, // IOCP와 연결할 핸들. 최초 생성시 INVALID_HANDLE_VALUE를 넘긴다
    _In_opt_    HANDLE ExistingCompletionPort, // IOCP 핸들. 최초 생성시 NULL
    _In_        ULONG_PTR CompletionKey, // IO 완료 시 넘어갈 값. 사용자가 넘기고 싶은 값을 넘김
    _In_        DWORD NumberOfConcurrentThreads) // 한 번에 동작할 수 있는 최대 스레드 개수. 0을 넘기면 프로세서 숫자로 자동 지정됨
    
HANDLE hPort = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 0); // CP 최초 생성
HANDLE port = CreateIoCompletionPort(socket, hPort, (ULONG_PTR)session, 0); // 디바이스-CP 연결

CreateIoCompletionPort 함수는 2가지 일을 한다.

1. CP 생성

2. 디바이스와 CP 연결

하나의 함수로 서로 다른일을 하기 때문에 명확하게 다른 이름으로 래핑하여 사용하면 좋을 것 같다.

IOCompletionQueue

입출력 완료시 말고도 유저가 직접 PostQueuedCompletionStatus 함수를 호출해서 정보를 직접 큐에 집어넣을 수도 있다.

BOOL WINAPI PostQueuedCompletionStatus(
    _In_        HANDLE CompletionPort,
    _In_        DWORD dwNumberofByteTransferred,
    _In_        ULONG_PTR dwCompletionKey,
    _in_opt_    LPOVERLAPPED lpOverlapped)

전달한 정보들은 입출력이 완료되면 CompletionQueue에 저장되어 스레드가 자신을 처리해주기를 기다리게 된다.

WatingThreadQueue

GetQueuedCompletionStatus 함수로 스레드를 대기 상태로 만든다.

ReleaseThreadList에 공간이 있고, 완료된 입출력이 있는 경우에만 대기 상태가 해제된다.

ReleaseThreadList

입출력 장치 또는 PostQueuedCompletionStatus로 보낸 정보를 GetQueuedCompletionStatus 함수를 통해서 받아온다.

BOOL WINAPI GetQueuedCompletionStatus(
    _In_    HANDLE CompletionPort,
    _Out_   LPDWORD lpNumberofBytes,
    _Out_   PULONG_PTR lpCompletionKey,
    _Out_   LPOVERLAPPED *lpOverlapped,
    _In_    DWORD dwMilliseconds)

입출력 처리를 하고 난 뒤에 재호출해야만 다시 대기 상태로 전환된다. 재호출하지 않으면 대기 상태로 전환되지 않기 때문에 주의해야 한다.

PausedThreadList

GetQueuedCompletionStatus를 호출하지 않더라도 스레드가 Blocking 상태에 빠지면 IOCP가 알아서 PauseThreadList에 집어넣는다.

Tower of Fantasy

제작 기간 : 23. 11. 01 ~ 24. 01. 04

개발 인원 : 5인

담당 파트

- 셰이더, 서브 프레임워크

주요 구현 내역

- 셰이더

- 렌더링

- 멀티스레드 로딩

- 맵툴 최적화

- 데이터 파싱

- 미니맵

- 인벤토리

- 퀘스트

- 대화

- 상호작용

- 사운드 제어

Furi

제작 기간 : 23. 07. 31 ~ 23. 10. 25

개발 인원 : 1인

주요 구현 내역

- 툴 제작 (맵, 이펙트, 애니메이션)

- fbx 바이너리 포맷 변환

- 애니메이션 제어

- 애니메이션 노티파이

- 행동트리

- 컷신

- 오브젝트 풀

- Material

- 네비게이션 메시

- 오브젝트 피킹

- 후처리 렌더링

- 그림자

- 인스턴싱