뼈대잡기
내가 모르는 A - B - C의 구조 정리하기
- 지금 Notification을 만들어 보려는데 createResponse가 없다
- createResponse 만들어보려니까 createHeader가 없다
- createHeader 만드는 구조 살펴보는 중 -> serializer.js가 이 역할을 하고 있었다
마샬링과 직렬화의 차이
참고 블로그
마샬링이나 직렬화나~ 라는 느낌으로 사용되고 있지만, 마샬링이 직렬화보다 더 큰 개념으로 사용된다고.
패킷파서가 없다면 우리가 패킷을 디코딩 해줘야지 - 프로토콜 버퍼의 늪에서 끝없이 헤매이는 중
주말에 동혁팀장님과 함께 모르겠어요! 하는 것들을 톺아보기 하여 조금은 구조 이해에 성공했다.
import를 해오는데 .js가 자꾸 빠진다면 - import module specifier ending 설정을 바꾸자
- ctrl + , 눌러서 설정 진입
- 검색어에 import module specifier ending 입력
- JavaScript > Preferences: import module specifier ending에서 .js/.ts 선택
플리마켓에 대한 고찰 - 6조의 기획에 플리마켓이 과연 필요한가
플리마켓 기능이 뭔지 잘 모르겠어 유정 튜터님을 찾아뵙고 답변을 받았다.
플리마켓도 카드의 일종이라 useCardRequest로 시작한다 -> 카드타입이 fleaMarket이면 플리마켓 시작
플리마켓 카드 사용한 유저부터 시작해서 입장순서대로 턴이 돌아간다
사용유저 인덱스가 5라면 5 6 7 1 2 3 이런 식
노티는 전체 유저가 플리마켓 상황을 알아야 하기 때문에 보내주는 것 -> 이거 플리마켓 시작한다! 용 노티임
픽 리퀘스트 - 나 이 카드 선택할거야! 하는 요청
선택하고 나면 다시 노티가 가야 할것 - 다른 유저들도 알아야 하므로
그래서 플리마켓은 useCardRequest의 일부? 한 결? 같은 느낌.
6조의 기획대로라면 플리마켓이 아니라 교환이 들어가야 하지 않나?
교환은 useCardRequest의 일부가 아닐 것.
그러면 여기서부터 다시 짜야 할 것.
리스트나 배열을 나타내는 것이 repeated.
이세카이 마트의 핵심
카드의 구매와 골드의 소모와 카드의 제거...
덱에 접근, 골드에 접근, 검증,
상태 동기화가 뭔지 모르겠어요 - 진수님과 함께 머리 들이박기
- 실시간 동기화
- 주기적 동기화
- 이벤트 기반 동기화
- 비동기 동기화
- 점진적 동기화 -> 레디스가 이 방식을 사용함
보간 & 외삽
보간은 이미 알려진 데이터 지점 사이의 값을 추측함 -> 시작점과 끝점은 알고있음
외삽은 이미 알려진 데이터 지점 바깥의 값을 추측함 -> 얘가 진짜 미래예지임
현재 우리 프로젝트에서 상태 동기화가 필요한 곳
상시 : 유저 데이터
상시 : 유저 위치 변경
이벤트 : 페이즈 업데이트
이벤트 : 카드의 사용
이벤트 : 플리마켓
타워디펜스는 이벤트보다는 실시간이 맞겠다 싶어서 실시간 동기화를 때렸음. 단점으로 리소스 소비가 많았다.
우리는 주기적 동기화 느낌으로 갈 것이다. 그러면서 부족한 점은 이벤트 동기화로 채워줄 것.
- 우리가 실시간 동기화로 간다면 어차피 노티 필요없다 - 어차피 매순간 동기화 될텐데 노티 뭐하러 하겠음.
-> 그런데 이러면 부하가 너무 심해서 주기적 동기화를 하되, 이벤트가 발생하면 그때도 동기화 해준다. - 이거 인터벌 매니저 얘기 맞나요? -> 맞다. 나 이거 몰라서 강의 다시 들어야함.
코드에서도 무결성은 깨질 수 있다 - 하나의 데이터에 여러개의 핸들러가 동시에 접근할 때
우리는 난입이라는 시스템이 있어서 하나의 카드에 여러 명의 핸들러가 엮일 수 있다.
-> 우리가 주기적 동기화로 가기로 했기 때문에 이 부분은 어쩔 수가 없다. 이거 해결하려면 메시지 큐 써야함.
일단 진수님 말씀대로 정리해보자면 이렇다
- 일단 인터벌 매니저부터 - 상시 동기화 핸들러를 먼저 만들어야 함
- 인터벌 주기를 늘려 게으르게 만든다 -> 1초 말고 한 3초, 5초로
- 이벤트 기반 동기화 핸들러를 만들어보자 - 플리마켓이나 카드 사용 시 socket.write() 해주지 않는가? 이 시점에 동기화를 한번 더 해주면 그게 이벤트 기반 동기화.
- 이게 제일 중요 -> 버그를 고친다!!
창민 튜터님의 황금같은 과외! 필요한 것을 적어보자
userCardRequest에 대한 핸들러부터 작성해야 한다.
targetUserId에 대한 걸 플리마켓으로 특정할 수 있어야 한다. 7777 이든 뭐든 -> 이건 카드타입으로 특정될 것
같은 방에서 게임을 하는데 세션이 없다면 만들어줘야 한다. 우리 게임의 세션으로 구획 나눌것 -> 우리 방에서 플리마켓 쓰면 우리방에만 적용되어야 한다
우리 방에서 플리마켓 썼다는게 서버에 기록되어야 함 -> 플리마켓 발동되면 상점(?) 오픈!
플리마켓은 소환자가 가장먼저 뽑을수 있다 -> 주인공이 먼저 뽑았는지 데이터도 알아야 할것!
저 pickIndex는 처음에는 비어있을 것임 -> 픽할때마다 찰거임. 그래야 이미 픽한 카드를 클라에서 체크
지금 구조로는 누가 플리마켓에서 트롤링하면 무한정 대기해야 하는 구조
-> 일단은 지금은 신경쓰지 말고 나중에 타임아웃 주던가 할것
유저의 덱은 서버에서 관리 -> 이건 세션마다 관리되고 있을 것! (존재 검증, 수량 검증)
플리마켓 비활성화 하면 메모리는 없애주면 된다
S2C플리마켓 노티를 쏘면서 플리마켓이 열린다!
순서 검증같은거 하고 아니면 응 니순서 아님~ 하고
repeated는 n개의 똑같은 타입이라고 보면 된다
창민 튜터님의 과외를 받는 영광을 입었으니 기록해두고 두고두고 보자. 이해할 때까지 봐야겠다😚
인터벌 매니저가 뭐였더라? 🤔 상태 동기화에 대한 복습
각각의 유저는 일정 주기를 가지고 핑을 보내게 될 것이다. 이때 같은 게임 세션에 들어와 있다면 이 유저들의 핑 송신 주기를 한 곳에서 관리해주면 더 좋을 것 -> 이 핑 송신 스케줄을 관리하는게 인터벌 매니저.
봉준님의 인터벌 특강
참고
상태동기화를 하려면 상태동기화를 하는 함수나 메소드를 하나 만들고, 그 함수 내에서 특정 정보를 클라이언트한테 Send 하겠지? 그 함수를 인터벌 매니저에 Add 해주면 끝.
setInterval어려워 할거 없다!setTimeout처럼 노드의 전역함수. 전에 봤었던 그거 맞다.
setInterval과 setTimeout의 차이 비교 등에 자주 나오던 그 setInterval을 이용해서호출 스케줄링을 하는 데에 쓰인다.
반드시 상태동기화가 아니어도 주기적으로 돌릴만한 무언가가 있으면 여기에 태워서 돌리는 것!
