멀티게임 websocket API구현

[david-parkk]

✏️ 작업 개요

• 멀티게임 websocket API구현

⛳ 작업 분류

• 멀티게임 websocket API 구현
• global websocket request, handler 변경
• 테스트 작성

🔨 작업 상세 내용

1. 멀티 게임 websokcet API를 구현하였습니다
2. 하나의 path안에 실행되도록 구현하였고, notion에 엔드포인트를 확인하시면 크게(?) 문제없이 이해할 수 있습니다.
3. 전에 제시했던 global websocket request를 변경하였습니다. websocket global request 제안 #42
4. 3으로 모든 handler 처리를 구현했습니다.
5. 클라에서의 요구대로 30프레임으로 스케줄링 시간을 변경하였습니다 (맵이동, 멀티게임 이동)

💡 생각해볼 문제

• 현재 회의가 필요하다고 생각하여, 유저 객체 번호 배정은 일단 정적 값을 배정하게 했습니다. (일단 해당 부분은 넘어가 주세요)
• websocket에 대한 비즈니스 로직처리를 service에서 처리해야 한다고 생각합니다. 현재는 유틸클래스에서 과도하게 처리되고 있습니다.
• 디버깅에 어렵다고 생각하여 매칭되는 순간 이동처리가 아니라 3~5초 뒤부터 시작됩니다.

[github-actions]

Test Results

20 tests   20 ✅  11s ⏱️
 8 suites   0 💤
 8 files     0 ❌

Results for commit 4b5f1f7.

♻️ This comment has been updated with latest results.

[kamothi]

쭉 코드를 보는데 사실 전체적으로 구조 자체를 이해를 못한거 같습니다. 즉, 어떤 구조로 상속 받아서 핸들러들이 동작하는지 이해하기 어려운데 간단한 다이어그램으로 보여주실 수 있을까요?

[kamothi]

이렇게 해주어야하는 이유가 무엇인가요?

[david-parkk]

이렇게 해주어야하는 이유가 무엇인가요?

• 기존에는 스프링 컨텍스트 없이 static 영역에 있는 handler 객체를 사용했다면 스프링 컨텍스트에 있는 빈을 가져오기 위해서 입니다.
• 다만 모든 handler는 customhandler타입으로 사용해야한다는 점과 스프링 컨텍스트에서는 해당 구현타입을 빈으로 등록하기 위해 제네릭 ? 와일드 카드를 사용했습니다.
• 정리하면 CustomHandlerMapping에서는 CustomHandler으로 존재하고 실제로 등록된 빈은 구현타입으로 존재해야 해야해서 그렇습니다

[kamothi]

그럼 static이 아닌 스프링 컨텍스트에서 관리해야하는 이유는 무엇인가요?

handlerMapping 시 의존성 주입 문제가 있었습니다.

이슈에는 위와 같이 나와있는데 어떤 상황에서 의존성 주입이 필요했었나요?

[david-parkk]

• matchQueue와 같이 내부 자료구조를 사용하는 경우 무방하지만, repository, service와 같이 빈 객체를 사용해야하는 경우 static으로 접근 불가합니다.
• 지금 코드로 반영되어 있지않지만 handler들은 service layer를 거쳐야한다고 생각해서 나중을 생각해보면 의존성주입이 필요하다고 생각합니다

[kamothi]

결국 service layer를 위해 모든 것들을 component로 등록한 것이군요. 이해하였습니다.

[kamothi]

이건 어떤건가요?

[david-parkk]

• 스프링컨텍스트의 빈을 가져오기 위함입니다.

[kamothi]

추가로 궁금한게 술래를 정하는 기준은 무엇일까요? 코드를 보는데 그 부분은 찾지 못했습니다....

[kamothi]

위의 그림의 형태를 가지고

public class TagGameRequest<T> {

    private TagGameStatus tagGameStatus;

    private T request;
}

각 request 등록된 status마다 request의 class가 달라진다. 라고 이해하면 될까요?
만약 이 흐름이 맞다면 좋은 방식인거 같습니다. 그러면 지금의 경우 custom handler가 taggame 디렉토리에 있고 taggame에 대한 처리만 하고 있는데 이걸 전역으로 옮기고 다른 로직들도 위와 같은 방식으로 채택하여 통합하는 것을 생각하시는건가요?

[david-parkk]

추가로 궁금한게 술래를 정하는 기준은 무엇일까요? 코드를 보는데 그 부분은 찾지 못했습니다....

이전 매칭 PR에 포함되어 있습니다 #41

    /**
     * 술래를 정한다
     * @param players
     * @return
     */
    private Map.Entry<String, WebSocketSession> selectTagger(List<Map.Entry<String, WebSocketSession>> players) {

        int randomIndex = random.nextInt(players.size()); // 4는 상한값으로, 0~3 사이의 값이 생성됩니다.

        return players.get(randomIndex);
    }

[david-parkk]

위의 그림의 형태를 가지고

public class TagGameRequest<T> {

    private TagGameStatus tagGameStatus;

    private T request;
}

각 request 등록된 status마다 request의 class가 달라진다. 라고 이해하면 될까요? 만약 이 흐름이 맞다면 좋은 방식인거 같습니다. 그러면 지금의 경우 custom handler가 taggame 디렉토리에 있고 taggame에 대한 처리만 하고 있는데 이걸 전역으로 옮기고 다른 로직들도 위와 같은 방식으로 채택하여 통합하는 것을 생각하시는건가요?

네 맞습니다.

1. TagGameStatus 에 enum 값 등록
2. 해당 로직 request에 대한 parsing 처리를 위해 TagGameRequestUtil 에 TagGameStatus 와 함께 등록
3. CustomHandler 구현체 작성
4. 해당 로직에 대한 handler 처리를 위해 CustomHandlerMapping에 TagGameStatus 와 구현체 등록

만약 global하게 사용될 것을 고려하여 "게임 or 로직 이름 " + "세부기능" 으로 네이밍 하였습니다
ex) 술래잡기 매칭 -> TAG_GAME_WAITING_FOR_PLAYERS

[kamothi]

전체적인 로직들은 다 이해가 된거 같습니다. 괜찮은 방법이라 생각해서 한 번 다른 로직들과 통합해보면 좋을거 같은데 현재 taggame에 있는 custom을 전역으로 옮겨주실 수 있나요? 머지 후 저도 제꺼에 한 번 반영해보고 싶습니다.

[david-parkk]

전체적인 로직들은 다 이해가 된거 같습니다. 괜찮은 방법이라 생각해서 한 번 다른 로직들과 통합해보면 좋을거 같은데 현재 taggame에 있는 custom을 전역으로 옮겨주실 수 있나요? 머지 후 저도 제꺼에 한 번 반영해보고 싶습니다.

API 명세내용이 달라질텐데 클라이언트에게 허락을 구해야하지 않을까요?

[david-parkk]

5. 클라에서의 요구대로 30프레임으로 스케줄링 시간을 변경하였습니다 (맵이동, 멀티게임 이동)

전체적인 로직들은 다 이해가 된거 같습니다. 괜찮은 방법이라 생각해서 한 번 다른 로직들과 통합해보면 좋을거 같은데 현재 taggame에 있는 custom을 전역으로 옮겨주실 수 있나요? 머지 후 저도 제꺼에 한 번 반영해보고 싶습니다.

전역으로 옮긴다면 이번 PR이 아닌 다른 PR로 분리하겠습니다

[kamothi]

API 명세내용이 달라질텐데 클라이언트에게 허락을 구해야하지 않을까요?

클라에서의 반영은 진짜 몇분 걸리지 않는다라고 판단하여 전역으로 옮겨놓고 확장성을 열어둘려고 했는데 그러면 다음 회의에 한 번 논의를 해봅시다.

[david-parkk]

/쿠타버스 배포

[github-actions]

🌎 배포하였습니다.