▶ 전송 계층이란?   OSI 7계층 중 4계층으로, 데이터 패킷이 손실이나 오류 없이 올바른 순서로 도착하는 것이 주 목적인 계층이다. 이를 위해 연결 속도가 빠른 송신자가 연결 속도가 느린 수신자를 압도하지 않도록 최적의 전송 속도를 제어하는 등, 흐름 제어 및 오류 제어 기능의 역할을 수행하기도 한다. 필요한 경우 데이터 패킷을 원활하게 복구하기도 한다. 전송 제어 프로토콜(TCP) 및 사용자 데이터그램 프로토콜(UDP)을 예로 들 수 있다. 세션 계층에서 가져온 데이터를 세그먼트라고 하는 조각으로 분할하고, 세그먼트를 다시 세션 계층에서 사용할 수 있는 데이터로 재조립하는 일도 이 계층에서 수행된다.  전송 제어 프로토콜(TCP) : 인터넷상에서 데이터를 메세지의 형태로 보내기 위해 IP와 함께 ..

🎲 한장씩, 랜덤하게 인벤토리에 넣어주기 위의 사진과 같이 normal 타입의 카드팩을 구매하면, 인벤토리에 각각 랜덤 확률로 뽑힌 플레이어 카드가 들어가야 했다. 그러나 이상하게 랜덤하게 뽑힌 카드 한장이 count 만큼 인벤토리에 반복해서 들어가고 있었다. 반복문만 test 파일에서 돌려보면 이상이 없었기 때문에, 개인과제에서 뜯어온 await userDataClient.inventory.createMany 코드를 완전히 이해하지 못하고 가공하고 있는 문제 같았다. 랜덤값과 인벤토리에 넣는 코드를 연결하는 것이 도저히 이해되지 않아, 강의도 계속 돌려보고 튜터님도 여러번 찾아가야만 했다. 튜터님의 피드백을 받아보니 문제점이 명확해졌다. 인벤토리에 아이템(플레이어 카드)을 넣어주는 코드가 애초에 지정..

🧧 플레이어를 뽑으려면, 일단 카드팩을 사야하는데기존에 배웠던 아이템 구매 API는 정해진 품목을 장바구니에 담는 것처럼 품목과 수량을 정해서 req를 보내면 인게임 머니를 차감하고 인벤토리에 아이템을 추가하는 방식이었다. 이번에는 확률형 아이템을 구매하도록 만들어야 하는데, 기존에 구성한 DB의 player 테이블은 구매한 아이템의 결과값일 뿐 정작 구매해야 할 플레이어 카드팩 관련 정보를 불러올 곳이 없었다. 풋살 게임을 진행하기 위해 사용되는 player 데이터만 고려하고, 그 player를 구매하고 inventory에 넣는 과정에 사용될 데이터를 고려하지 못한 것이다.  가챠 게임들을 보면 다양한 카드팩을 시즌별로 판매한다. 풋살 온라인 프로젝트에서도 플레이어 카드의 종류나 확률에 따라 다양한 ..

🎒 인벤토리란 무엇인가jwt 토큰 인증 이슈로 인해 이전 개인과제에서 인벤토리 구현을 해보지 못했기 때문에, 실제로 데이터베이스에 어떻게 데이터가 쌓이는지 감이 오지 않았다. 당연히 가방처럼 플레이어당 하나의 인벤토리가 생성되고, 그 안에 아이템의 id와 갯수(count)가 쌓인다고 생각했다. 그러나 팀원들과 이야기를 나누다보니, 인벤토리의 슬롯 하나로 이해하는 경우도 있었다. 그러면 DB가 너무 더러워져서 관리하기 어렵지 않은가? 로그처럼 데이터를 계속 누적하는 건데... 아이템을 사고 팔거나 장착할 때 꼬이지 않는 것인가? 라는 의문이 들었지만... 사실 해당 기능을 제대로 구현했던 적이 있는 사람은 없었기에 다같이 공부한 뒤 다시 모여야 했다. 해설 영상을 참고해보니, 하나의 아이템이 인벤토리에 ..

JWT를 헤더에서만 사용하는 것 때문에 수정과 테스트를 반복하다가 정신을 차려보니 이미 11일이 지나있었다. 조금 늦었지만, 트러블슈팅 관련 기록을 남겨두기로 했다. ▶ 쿠키 대신 헤더에 토큰 부여하기JWT로 ACCESS TOKEN을 쿠키에 부여하는 방법만 배웠는데, 헤더에서만 사용되어야 한다고 하니 난관이 예상되었다. 관련 다행히도 res.cookies였던 토큰 관련 코드를 res.setHeader나 res.header로 변경하니 헤더에 들어가기는 했다.   그러나 헤더에 부여된 이 정보가 /api/characters 같은 다른 API까지 연결되지 않아, 인증 로직 구현이 불가능했다. user_id 기반으로 ACCESS TOKEN이 생성되지 않아, 유저가 body 입력하는 account 기준으로 생성했..

🚧 회원가입 유효성 검사회원가입 관련, 과제에서 주어진 유효성 검사 기준은 2가지였다. 아이디가 '영어 소문자 + 숫자 조합' 일 것, 패스워드가 6글자 이상일 것. 해당 기능은 어제 테스트 해 본 결과, Prisma에서 구현은 불가능하며 router의 회원가입 API에서 조건을 걸어줘야 했다. 패스워드는 입력받은 값의 길이만 확인하면 간단하게 검사할 수 있었다.if (password.length  문제는 아이디였다. 'js 영문+숫자 조합' 등의 검색어로 찾아보니, 정규식이라는 것이 있었다. 회원가입 관련 로직에서 많이 사용한다고 하여, 코드에 적용해보았다.  regex로 조건을 선언해주고, 해당 조건의 테스트를 입력받은 account 값이 통과하지 못하면 error message가 반환되는 로직을 ..