TIL260529

개요

---

오늘은 챕터2 프로젝트가 모두 끝나서 그동안 한 작업을 회고하였다.

TextRPG.pdf

1.75MB

링크

---

내일배움캠프/챕터2/텍스트RPG/6조/감자가생각났어요

 

 

2026.05.27 - [ndhphysics] - TIL260527 - 챕터2 프로젝트 - 1

TIL260527 - 챕터2 프로젝트 - 1

 

2026.05.28 - [내일배움캠프/TIL] - TIL260528 - 챕터2 프로젝트 - 2

TIL260528 - 챕터2 프로젝트 - 2

 

2026.05.21 - [내일배움캠프/Works] - NBC 챕터 1주차 26.05.11 ~ 26.05.21 사이드 프로젝트 회고록

NBC 챕터 1주차 26.05.11 ~ 26.05.21 사이드 프로젝트 회고록

 

에필로그

---

튜터님 질문 시간 들어올거 같아서 예상질문 리스트업했는데 결국 못썼다...

 

- 서버는 어떻게 구축했는가? 
>> 하마치 네트워크로 다른 피시 간에 우회 터널을 뚫어서 LAN 환경과 같이 통신했다.

- 하마치 사용 이유
>> 리슨 서버를 구현할 때 포트포워딩 없이 빠르게 멀티 플레이를 구현하기 위해서

- TCP를 택한 이유는?
>> 텍스트 게임 특성상 실시간 반응 속도가 중요하지 않아서 패킷이 유실되지 않고 순서대로 도착하는 정합성을 중시하여
TCP를 택했다.

- TCP 패킷이 일관성있게 오지않은 경우 어떻게 파싱?
>> 패킷은 버퍼에 담아서 헤더에 명시된 패킷 사이즈에 도달하면 버퍼를 패킷사이즈만큼 비우고 파싱하는 식으로 처리

- 불안정한 네트워크 환경에서 예외처리는?
>> 시간이 촉박해서 고려하지 않았다. 하마치의 가상 LAN 환경에서 높은 연결 안정성을 전제로 개발해서 재접속 로직은 생략
실제 구현에서는 패킷 유실을 한 경우 재전송이나, 기존 세션을 복구하는 과정이 필요하다

- 소켓은 어떻게?
>> 블로킹 소켓에 클라이언트가 연결이 될 때마다 백그라운드 스레드를 하나 더 신설해서 돌렸다.
>> 서버가 부담할 클라이언트가 최대 6인이여서 스레드의 컨텍스트 스위치 비용이 충분히 감당가능하다고 판단해서
쉽게 구현했다.
>> clientNames 같은 공유 자원에 접근하는 경우 mutex를 사용하여 레이스 컨디션을 방지했다

- 클라이언트 접속 체크/핑퐁 체크 했는가?
>> FIN 패킷을 호출하는 정상적인 종료 상황이 아닌 경우에 대해서 방어처리를 하지 않았다.
>> 보완한다면 클라이언트에게 주기적으로 핑퐁 패킷을 보내서 lastRecvTime이 일정이상 지나면 타임아웃으로 간주하고
연결을 끊어야 한다.

- 방장이 나간 경우 클라이언트는 어떻게 처리했나요?
>> 이 부분도 시간 관계상 생략했다. 추가로 구현한다면 하마치 아이피 주소를 캐싱해서 다른 클라이언트를
서버로 승격하는 로직을 넣었을 것

- 패킷에서 오버플로가 난다면?
>> 패킷을 정의할 때 string은 고정 문자 배열로 한정시켜서 버퍼를 초과할 일이 없다

- 클라이언트 위변조
>> 솔로모드는 챕터 요구사항을 준수하는데 충실해서 멀티 플레이가 전제되지 않았다. 이 부분은 변조가 가능하다.
하지만 멀티 플레이 모드에서는 클라이언트가 진입 당시에 데이터의 스냅샷을 서버가 가지고 오직 이 스냅샷을 서버가
변경하는 식으로 서버 권위를 약식으로나마 구현했다.

- 스레드 동기화 UI 업데이트
>> 현재는 UI 출력을 담당하는 메인스레드가 바로 소켓 스레드를 참조하는 식으로 강결합이 되어있다.
스레드 안전한 큐에 결과를 담아 이를 출력하는 식으로 리팩토링 할 필요가 있다.

- 블로킹 소켓 종료
-> 방장의 소켓이 닫히면 클라이언트입장에서 isNetworkRunning flag를 false로 바꾸고 안전하게 스레드를 종료하도록 했다.

- 엔디안 포맷팅
>> 저희 조원 모두 리틀 엔디안 방식을 사용해서 별도로 빅엔디안 표준으로 맞추는 작업을 하지 않았다.
>> 패딩은 전처리로 컴파일러에게 패딩하지 말도록 명시해서 데이터 파싱할 때 패딩을 고려하지 않아도 되게 설계했다.(직렬화 포맷은 안씀)

- 동기화 문제
>> 내부적으로 각 멀티 플레이 모드 매니저에 CurrentTurnPlayer 같은 정보를 저장해서 클라이언트가 행동 패킷을 보내도 무시하도록 설계했다.

- TCP의 Nagle 알고리즘
>> 패킷을 기다리지 않고 바로 보내는 소켓옵션으로 알고 잇는데 그 부분은 배제했다. 텍스트 게임이여서 반응성이 그렇게 중요하지 않았다.