소켓 연결 관련 질문

• 현재는 클라이언트가 게임 도중 브라우저 닫기 등을 통해 나가는 경우, 플레이어의 정보(제출 내역, 맞춘 항목 등등)을 삭제시키지 않고 보유하고 있으며, 방에 다시 들어온다면 새로운 소켓에 기존의 정보를 복원시켜 주고 있습니다. 그렇다보니 모든 플레이어가 퀴즈 풀이를 종료하면 타임 아웃 전에도 다음 퀴즈로 넘어가는 방향으로 구현했지만, 한 플레이어라도 중간에 나갔다면 모든 플레이어는 반드시 타임아웃 전까지는 대기 상태로 남아있어야 합니다.

• 웹소켓이 생각보다 네트워크 불안정 이슈 등으로 자주 연결이 끊어지는 것을 확인했는데, 짧은 끊김은 클라이언트에서 끊어졌다는 사실을 모르도록 퀴즈 진행이 매끄럽게 이어지는 것이 UX 측면에서 좋을까요?

  • 현재는 연결 재수립 과정이 아래와 같습니다.
    1. 클라이언트에서 소켓 연결 끊김을 감지 (헤더 정보 등을 통해)
    2. 서버로 REST GET 요청 ⇒ 서버에서 응답 및 화면 렌더링을 위해 필요한 데이터 반환
       1. 200 OK라면, 웹소켓 재연결, 서버의 응답 값을 바탕으로 화면 리렌더링
       2. 서버에서 거부한다면 사용자에게 서버의 메세지 노출
  • 그렇다보니 아주 매끄럽지는 않을 것 같습니다. (혹시 매끄럽게 처리하는 다른 방법이 있는 지는 잘 모르겠습니다.)

• 아니면 끊김-재연결 사이에 관련 ui등을 넣는게 더 좋을까요?

  

현재의 흐름 (소켓 연결 끊김)

sequenceDiagram
    participant Client
    participant Server
    
    Note over Client: 소켓 연결 끊김 감지
    
    Client->>Server: REST GET 요청
    
    alt 200 OK
        Server-->>Client: 데이터 반환
        Note over Client: 웹소켓 재연결
        Note over Client: 화면 리렌더링
    else 거부
        Server-->>Client: 에러 메시지
        Note over Client: 사용자에게 에러 메시지 노출
    end

MSA 관련 질문

• 현재는 NEST 서버에서 연결 상태 관리를 관리하고 있고, 뿐만 아니라 서버의 메모리에서 퀴즈방과 플레이어 상태 저장 등을 모두 하고 있는 상황인데 이를 여러 서버(혹은 컨테이너)로 분리하는 것이 아키텍처 측면에서 더 좋을까요?
• 분리한다면 시그널링 서버(연결 상태 관리, 하트비트 관리) 및 레디스 서버 생각하고 있습니다.

Github Action

• 액션 ⇒ 액션 호출 가능