어려웠던 점

1. pub / sub topic 설계

• 게임 내 존재하는 수많은 topic을 어떻게 관리하는게 유리할지 고민을 했습니다.
• 리소스를 효율적으로 활용하면서 동시에 채널 관리가 용이한 방식을 구상해야 했습니다.
• 개발 비용을 줄이기 위해서는 직관적인 방식을 선정해야 했습니다.
  • 클라이언트 컴포넌트 별로 topic 지정 vs 페이지 별 topic 지정 후 message type 설정

💡 이렇게 해결했습니다.

• 페이지 별로 topic을 싱글 채널로 관리하며 이에 대한 통일된 Response를 지정했습니다.
• 상황에 따른 다양한 message type을 활용하는 방식으로, 채널의 관리 복잡성을 줄였습니다.
• 이를 통해 리소스 부담을 줄일 수 있었고 동시에 기능 별 유연한 확장이 가능하도록 하였습니다.

2. 세션 Disconnect 문제

• 회원은 로그아웃의 개념이 아닌, 소켓 세션이 끊어지는 것을 기준으로 오프라인 처리를 했습니다.
• 이 때, Redis에서 관리하는 방과 게임에 대한 세부적인 업데이트 로직이 필요했습니다.
• 뿐만 아니라, 타임아웃 메커니즘으로 인해 연결이 끊어지는 문제도 해결해야 했습니다.

💡 이렇게 해결했습니다.

• 인터셉터를 통해 STOMP의 command를 확인하여 다양한 분기 처리를 하였습니다.
• 게임 중 단일 유저가 disconnect 되면, 해당 게임과 방의 데이터를 삭제 후 업데이트 하였습니다.
  • 채널 인터셉터에서 이벤트 리스너를 활용하여 순환참조를 예방할 수 있었습니다.
• 나아가 HeartBeat를 활용하여 세션 끊김 현상을 해결할 수 있었습니다.
  • ping, pong 프레임을 일정 시간마다 주고 받으며 연결성을 보장할 수 있었습니다.