I'm FanJae.

1. 시작에 앞서- 이전 작업에서는 MySQL 개발 환경을 구성하고, LoginServer에서 Account와 Character 데이터를 DB를 통해 조회할 수 있도록 구조를 변경했다.- 이에 따라 코드 내부에 직접 작성해두었던 임시 계정과 캐릭터 데이터를 실제 Database에서 가져올 수 있는 기반은 만들어졌다.- 다만 로그인 과정 자체는 아직 단순했다.- 클라이언트가 accountId를 직접 전달하면 해당 계정이 DB에 존재하는지만 확인하는 구조였기 때문이다.Client ↓accountId 전달 ↓LoginServer ↓Account 존재 여부 확인 ↓로그인 성공- 하지만 실제 로그인에서는 클라이언트가 내부에서 사용하는 accountId를 직접 알고 있을 필요가 없다.- 일반적으로 사..

1. 시작에 앞서- 이전 작업까지 LoginServer와 GameServer를 분리하고, 로그인 이후 캐릭터를 선택한 뒤 인증 티켓을 이용해 GameServer로 이동하는 흐름을 구현했다.- 다만 아직 로그인 계정과 캐릭터 정보는 실제 데이터베이스에서 가져오는 것이 아니라 테스트를 위한 임시 데이터를 사용하고 있었다.- 예를 들어 특정 계정만 로그인에 성공하도록 처리하거나, 캐릭터 목록 역시 코드 내부에 직접 작성해두는 방식이었다.LoginServer계정 확인→ 임시 데이터 사용캐릭터 목록→ 코드 내부에 직접 작성된 데이터 사용캐릭터 선택→ 임시 캐릭터 목록을 기준으로 확인- 서버 간 인증 흐름을 확인하는 단계에서는 이 정도로도 충분했지만, 실제 서버 구조로 확장하기 위해서는 계정과 캐릭터 데이터를 별도..

1. 시작에 앞서- 이전 작업에서는 로그인 이후 캐릭터를 선택하면 LoginServer에서 인증 티켓을 생성하고, 이를 GameServer에 미리 등록한 뒤 클라이언트가 해당 인증 키를 이용해 GameServer에 접속하도록 구성했다.- 이를 통해 다음과 같은 기본적인 입장 흐름을 만들 수 있었다.로그인 ↓캐릭터 선택 ↓인증 티켓 발급 ↓GameServer에 티켓 등록 ↓클라이언트 GameServer 접속 ↓인증 티켓 확인- 기본적인 동작은 가능했지만, 인증 티켓을 실제 입장 인증 정보로 사용하려고 보면 추가로 고려해야 하는 부분이 있었다.- 우선 인증 키는 단순히 1, 2, 3 ... 형태로 증가하는 값을 사용하고 있었다.- 또한 한번 발급된 인증 티켓에는 별도의 유효 시간이 없었기 ..

1. Docker란?- Docker는 애플리케이션과 실행에 필요한 라이브러리, 설정 등을 Container라는 격리된 환경으로 패키징하고 실행할 수 있도록 해주는 플랫폼이다.- 일반적인 가상 머신(VM)이 각각의 Guest OS를 실행하는 것과 달리, Container는 호스트의 커널을 활용하여 프로세스를 격리한다. 이 때문에 일반적으로 VM보다 가볍고 빠르게 실행할 수 있다.- Docker에서 흔히 사용하는 Linux Container는 Linux 커널의 기능을 기반으로 동작한다. 따라서 Windows에서 Linux Container를 실행하려면 Linux 커널을 사용할 수 있는 별도의 환경이 필요하다.- Docker Desktop은 이를 위해 WSL 2, Hyper-V 등의 backend를 지원하며,..

1. 시작에 앞서- 이전에는 Blocking 서버의 한계와 Non-Blocking Socket에 대해 정리했다.- Blocking 방식에서는 I/O가 완료될 때까지 Thread가 대기할 수 있었고, Non-Blocking 방식에서는 I/O를 즉시 완료할 수 없다면 WSAEWOULDBLOCK을 반환받아 Thread가 계속 실행될 수 있었다.- 하지만 Non-Blocking 방식만 사용하면 I/O가 언제 가능한지를 애플리케이션에서 다시 확인해야 하는 문제가 남는다.recv() ↓데이터 없음 ↓다시 확인 ↓recv()- 즉 Thread가 Blocking되지는 않지만, 작업을 언제 다시 시도해야 하는지 직접 관리해야 한다.- 그렇다면 다음과 같은 방식으로 처리하는 것은 가능하지 않을까?I/O 요청 ..