해당 서비스 소개
4주차 계획
4주차 협업 진행 과정(각자의 일감을 분배하고 특정 시간에 만나서 함께 상황 공유) -> 이전 주차와 다른점은 무엇인지? (3주차에는 openvidu 등등의 고난… 이후 4주차부터 일감 나누고 본격적으로 개발 시작)
4주차에 진행한 일 설명 (게임 페이즈에 따라 게임이 어떻게 진행 되는지? + api명세서 작성) -> 일종의 진행상황
4주차 동안의 진행상황 시연 영상
FE 트러블 슈팅 및 해결 경험 & 구현 과정
- 소켓을 하나로 적용한 과정
남은 FE 기술적 도전
- 소켓 연결이 끊어 졌을 경우, socketio에서는 재연결을 시도하는데 이때 재연결 간격을 늘려 서버에 많은 요청이 계속해서 가는 것을 막는 것을 도전으로 하고 있음
- 서버 이벤트 누락 및 지연 처리
- 스켈레톤 로딩 컴포넌트, 로딩 상태 UI 등
- 클라이언트가 현재 페이즈와 서버 이벤트를 비교하여 누락된 이벤트를 검증하는 로직 추가
BE 구현과정 & 트러블 슈팅
-
Coturn 서버 설정 ⇒
- 백엔드 초보 강조…
- 로컬 윈도우에서 WSL2로 도커를 실행 중인 상황
- 설정 후 port가 열려있는 건 확인됐는데 기능이 동작하지 않음 ⇒
- 포트가 열려있는 이미지
netstat -ano | findstr :3478 netstat -ano | findstr :5349 TCP 0.0.0.0:3478 0.0.0.0:0 LISTENING 5808 TCP 0.0.0.0:5349 0.0.0.0:0 LISTENING 5808- netstat 명령어로 해당 포트를 어떤 프로그램이 점유하고 있는지 확인
tasklist /svc /FI "PID eq 5808”명령어로 PID 기준 5808이 무슨 프로그램으로 잡혀있는 지 확인 (찾아보니 IP Helper가 5808을 점유하고 있었음 따라서 도커에서 실행한 Coturn 컨테이너가 제대로 동작 안하는 문제가 있었음)
Image Name PID Services ========================= ======== ============================================ IP Helper 5808 IP Helper- 이후 IP Helper를 끄고 동작을 해보니 성공해서 서버 인스턴스에 성공적으로 배포
- 성공 이미지
남은 BE 기술적 도전
- 쉬운구현을 위해 단일 서버의 메모리에서 세션을 저장하고있는데
- 단일 서버가 아니라 여러대의 위해 세션을 redis로 분리하는것
- 이유: 수평 확장 (Scalability)
- 단일 서버에 세션을 저장하면 해당 서버가 모든 요청을 처리해야 하므로 로드밸런싱이나 수평 확장이 어렵습니다.
- Redis에 세션을 저장하면, 여러 서버가 동일한 Redis에 접근하여 세션 데이터를 공유할 수 있어 수평 확장이 가능합니다.
- webRTC - SFU 방식 도전 (미디어 서버 추가)
피드백 질문
- 게임 방에서 로비 페이지로 뒤로 가기를 통해 이동 하는 게 적합할지? 아니면 뒤로 가기를 막아주고, 나가기 버튼 시에만 로비로 나가게 하는 게 사용자 측면에서 더 자연스러울지?