첫 주차에 간략히 배웠던 TCP를 본격적으로 시작한다.

오늘 학습한 내용은 위와 같으며,

강의 하나 하나의 난이도가 상당하다. 

하나에 20분 내외로 끝날 강의가 맞을까 의심이 되는데, 

그럴것도 없이, 추가적인 학습을 유도하는 강의로 보인다.

시작은 디렉토리 구조 부터 !

지난 과제의 디렉토리보다 세분화되어 복잡해 보인다.

아니, 익숙하지 않다고 하는게 더 맞는 말 같다.

server.js 를 시작으로

무려 Node 의 기본 모듈

net 을 이용하여 TCP 서버를 생성하고

initServer 를 통해 본격적으로 서버가 구동된다.

기본적인 구조는 socket 서버의 형태와 크게 다르지 않지만,

데이터를 주고 받을때는 반드시 buffer 의 형태 여야 한다는 것 !!

때문에, onData => 데이터를 받았을 때

당연히 buffer 형태로 왔을 것이므로, 해당 buffer를 다시 해석하는 과정이 필요하다.

에서 끝나면 사실 그렇게 복잡할 일은 아니다...

버퍼가 늘 출발한 순서대로,

예상한 시간에 도착하여 딱 딱 완성된다는 보장이없다.

따라서, while 반복문으로 헤더에 담긴, 오기로 한 길이만큼 올 때 까지 기다려 주는 상황을 만드는 

코드가 필요하다.

버퍼들이 도착하여 이미 약속된 패킷의 길이가 될 때 까지 기다리는 것이다.

에서 끝나면 사실 그렇게 복잡할 일은 아니다...

해당 버퍼를 처리하려고 할 때, 추가적인 다른 버퍼들이 이미 도착해 있을 수 있다.

따라서, header 에 담긴 length 만큼만 buffer 에서 잘라서 처리하고, 

나머지 부분은 다시 buffer 에 넣어버리는 코드를 작성한다.

여기가 3-3에 해당하는 내용인데,

이번 과제는 시작조차 쉽지가 않을것 같다.

갑자기 클라이언트 등장?! 

하지만, 백엔드 과정이기 때문에 간단한 지식만 배운다.

강의 내용은 위와 같으며, 

유니티로 제작된 클라이언트를 서버와 연결하는 법 정도는 알아햐 하기 때문에 편성된 강의이다.

유니티란 뭘까? 

게임 개발을 돕기 위한 소프트웨어 플랫폼으로,

개발자들이 게임을 디자인, 개발, 배포하기 위한 기능과 도구를 제공하여

클라이언트 개발에 필요한 시간을 획기적으로 단축시켜주는게임 개발 엔진이다 !

유니티는 Object 단위로 작업이 진행되며, 

Object 의 다양한 설정을 손 쉽게 적용할 수 있어서 편리하다.

모든 기능 하나하나마다 코딩 필요가 사라진 것이다.

특히, 게임 개발 엔진인 만큼

위에서 보는 것 처럼 충돌에 관련된 기능이나 움직임 (운동) 에 관련된 내용들이

많이 내장이 되어있다.

강의에서는 대단한 코딩 없이 이러한 기능들을 활용하여 핑퐁 게임을 만드는것을 알려주었다.

...처음해보면 다 신기하다 !!

그리고 가장 중요한 내용인 

클라이언트 <> 서버 간의 TCP 통신을 연결하는 부분인데, 

이 과정은 비교적 간략하게 알려주었기 때문에, 아직 이해가 덜 되었다.

서버 파일도 통째로 주고, 후딱 끝나버린 강의

다음 3주차의 강의에서 해당 부분이 본격적으로 진행 될 듯 하다.

CH.5 에서... 드디어 올 것이 왔다.  TCP 

악명이 높은 TCP 통신에 관한 챕터이다.

구현하기에 앞서, TCP 에서 사용하는 패킷과 

패킷의 데이터 단위인  Buffer 에 대해 알아야 한다.

TCP 는 바이트 배열을 주고받으며 통신한다.

1바이트 = 8비트 단위의 데이터 배열이며, 

8 비트는 16진수 2자리에 해당하고, 0~255의 값을 표현 할 수 있다. ( 00 ~ FF )

16진수를 단위를 쓰는 색상코드는 한번 쯤은 봤을 것인데, 

이는 00 00 00   8비트 x3 의 코드이다.

게이머라면 알만한 프로그램인  치트 엔진에서도 

데이터를 16진수 2자리 = 8비트 로 표현하는 것을 볼 수 있다.

다음은..

아무튼 Node 의 기본 문자열 처리방식인  UTF-16 (16비트) 인코딩보다 빠르다는게 중요

백문불여일견 !!

Hello 문자열을 아스키 코드 16진수로 표현하면 48 65 6c 6c 6f 가 되고,

Buffer.from('Hello') 를 실행해 보면, 버퍼 객체인

<Buffer 48 65 6c 6c 6f> 가 출력되는것을 확인 할 수 있다.

왜 'H ' 가 48이 되었는가 하면,  

'H' 는 아스키 코드로 72 에 해당하고,  72 (10진) 을 16진수로 바꾸면 48이 되는것이다.

살짝 머리아픈 부분은, 막상 해당 인덱스를 찍어서 보면 72 즉, 10진수로 표시해준다는것

헷갈리지 말자 !

마무리

강의에서 설명해준 내용대로,

문자열 -> 버퍼 -> 전송  -> 문자열 의 과정을 수행해 보았다.

서버가 받는 문자열은 뒤집는 것 까지 !

프로그래머스의  2레벨이 시작되었다...

2레벨 초입이라 그런지, 풀이가 어느정도 가능할 것으로 보이는 문제이다.

n은 2 이상으로 주어지기 때문에 시작을 2로 잡아보았다.

이렇게 배열을 하나 만들어서  Fn-2 Fn-1 Fn 을 표현해 주었다.

first[2] 를 반환하여 정답을 만드는것

문제 그대로를 집어넣은듯한 반복문을 작성해주었다.

1회 반복될 때 마다,

first[1],first[2] =>  first[0] first[1] 이 되고

first[2] = first[0] +first[1] 로 갱신되는 형태

shift를 사용해서 배열의 값을 한칸 씩 땡기고 first[2] 를 다시 만들어 주는것도 같은 결과일 것이다.

shift() 의 시간복잡도는  O(n) 인데,  이 경우 항상 length =3 에서 진행되기 때문에 3의 시간 복잡도가 된다.

하지만 first[0]  과  firtst[1] 을 각각 수정하면  복잡도가 1+1 이기 때문에  n당 n회 이득이다..ㅋㅋ...

조건이 더 있었다.

Int 한계 때문에 생긴 조건일까?

마찬가지로 조건도 그대로 넣어버린다

오늘은 Socket 을 다루며 생겼던 의문에 대해 생각해보는 시간을 가졌다.

🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 

Chapter.4 의 Dino -run 과   Tower Defence 를 진행하고 들었던 의문이 있다.

🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔 🤔

위는 dino run 에서, 서버가 클라이언트의 데이터를 검증하는 과정이다.

유저가 일정 점수를 만족하여 스테이지를 넘어갈 때, 

당시의 점수가 정상적인 값인지 서버에서 확인하는 과정이다.

클라이언트는 클라이언트 나름대로의 계산을 통해서 

스코어를 계산해서 반영하고 있다.

여기서 생긴 의문은

어차피, 각자 점수 계산을 할꺼면 그냥 서버가 점수를 관리하여 결과만 보내주는게 낫지 않을까? 

하는 의문이었다.

쉽게 말해,

서버도 10의 일을 하고

클라이언트도 10의 일을 할 바에는

서버만 10의 일을 해서 클라이언트는 그 결과를 받아서 표기만 하게 하는것이 낫지 않겠나 하는 것이었다.

이렇게 하면 클라이언트에서 점수를 조작하는것도 어려워지고, 

서버에서는 검증을 하던지 데이터 자체를 관리하던지 로직 복잡도는 크게 다르지 않을것이고,

패킷은 검증만 해도 오가야 하니 패킷의 양 또한 비슷할 것이다.

쉽게 말해, 검증을 위해 서버가 예상한 점수를 그냥 클라이언트로 보내버리는 것이다. 

그걸 받아서 현재 점수를 갱신하게 만들면, 일종의 동기화가 진행된 것이기 때문에

유저는 보다 정확한 값을 확인할 수 있고, 클라이언트는 딱히 계산할 것도 없어지게 된다.

얼핏 보면 크게 오류가 없어보이는 논리이다.

그렇기 때문에,

왜 그렇게 하고 있지 않은지를 찾아보기로 했다.

지금 생각해보면 대단히 고민 할 필요도 없는 문제...

자잘한 문제를 다 치워 두고 위에 저 두 상황을 봤을 때,

아래의 케이스는 결국,

클라이언트가 서버의 패킷을 받을 때 까지 데이터 변화를 적용 할 수 없다는 것 !!!!

이 부분이 가장 큰 차이점이다.

만약 서버의 응답이 느려지거나, 적당히 빠르다 할지라도 빈도가 너무 많은 과정이라면

그 때마다, 클라이언트는 서버가 데이터를 보내줄 때 까지 손가락만 빨고 있어야 한다.

아무리 짧다고 하더라도 클라이언트가 직접 수정하는 것보다는 느릴 수 밖에 없다는 것이다.

결과적으로, 유저 경험적인 측면에서

순간이지만, 일단 클라이언트 마음대로 하게 두고,

선을 넘으면 그 때  =검거= 하러 가는 검증 방식을 사용하는 것이다.

결론은 케바케 !!

결론 

총 세 가지 케이스로 요약할 수 있다.

1. 서버가 데이터를 관리하고 계산하여 클라이언트로 쏴줌

게임의 재화같은 경우, 중요하게 관리되어야 하는 만큼 서버에서 데이터를 관리하는 경우가 많다.

서버가 계산한 내용으로 클라이언트에 반영하려면 위에서 말한것 처럼,

서버가 보내는 명세서를 클라이언트가 받을 때 까지 갱신이 지연되는 문제가 생길 수 있다.

2. Dino run 의 점수 계산

위에서 본 Dino run 의 스코어 계산의 경우, 

프레임 단위로 이루어지도록 설계가 되어있다.

만약 서버가 해당 스코어를 관리하려면 프레임 단위로 데이터 갱신하고,

프레임 단위로 패킷으로 보내줘야 하는 상황이다.

스코어의 경우 최종 스코어만 정확하게 계산이 가능하다면

굳이 매 순간 엄격하게 정확 할 필요까진 없는 데이터이기 때문에, 

결과적으로 클라이언트에서 관리하되, 적절한 타이밍마다 서버가 검증하는 방식이 되었다.

3. 그 외 ...?

여기까지 써야 하나 싶긴하지만, 마무리를 위해 작성해 보았다.

클라이언트에 그려지는 '점수' 라는 텍스트가 'white' 색상이 맞는지, '점수' 라는 텍스트가 맞는지는 

전혀 검증 할 필요성이 없다.

따라서 해당 부분은 따로 검증이 진행되지 않고 클라이언트 독단으로 실행되게 되어 있다.

결국, 개발자가 데이터를 어떻게 설계 하는지에 달려있다고 볼 수 있다 !

오늘 발표를 끝으로 또 하나의 프로젝트가 종료되었다.

담당 업무 부분을 정리해보았다.

• 상점의 구매 버튼을 통해 이벤트 시작

클라이언트에서 생성될 타워의 좌표와 버튼 번호를 #30 towerBuy (handler Id) 로 요청

서버에서는 버튼 번호 === 타워 종류 로 구분하여 해당하는 타워 정보를 redis에 저장된 metaData 에서 가져온다. 

그 후 서버에서 관리하는 user의 소지금을 가져와서 간단한 검증을 진행한다.

검증에 문제가 없다면, 타워의 data를 redis 에 push 한다.

저장되는 내용은 타워의 종류 = towerType, 타워 좌표 = position , 그리고 강화 횟수 (구매 시 0 ) 이다.

그 후 return 되는 정보는 아래와 같으며,

해당 데이터는 다시 클라이언트에게 동일한 handler Id = #30 towerBuy 로 'response' 이름으로 전송된다.

클라이언트는 받은 패킷의 내용으로 메세지 출력, 타워 구매, 표시 골드 갱신하는 함수를 실행하게 된다.

타워를 찾아서 실행된다.

• 타워를 클릭 할 때, 해당 마우스 좌표에 타워가 있다면 실행된다.

클릭 시, 해당 타워의 사거리를 원으로 표시하고 타워의 능력치 정보와 타워 강화, 타워 판매 버튼을 생성한다.

• 타워 메뉴에 있는 타워 판매 버튼을 통해 실행

로직 자체는 타워 구매와 유사하며, #31 towerSell 핸들러로 클릭한 타워의 좌표를 payload로 보낸다.

서버에서는 받은 타워의 좌표와 동일한 좌표를 갖는 데이터를 redis 에서 찾는것으로 검증을 진행하며,

같은 좌표의 데이터가 있을 시, 해당 데이터를 삭제하고 해당 타워 가격의 절반에 해당하는 금액을 소지금에 더한다.

이 후 정상적으로 return 이 반환되면 클라이언트는 해당 타워를 제거한다.

• 타워 메뉴에 있는 타워 강화 버튼을 통해 실행

타워 판매와 동일하게 좌표를 받아서 진행하며, 동일한 좌표의 데이터를 redis 에서 찾은 뒤 enhanceLevel 을 +1 한다.

클라이언트는 서버에서 받은 데이터로, 강화를 실행한다.

하루에 한번 회의 시간을 정해서 각자의 진행 상황과 그날 구현 목표에 대해 공유하는 것이 좋았습니다.

A 의 작업이 완료되어야 B의 코드를 테스트할 수 있는 환경일 때,

A의 작업이 완료될 때 까지 시간이 더 필요하다는 사실을 공유받으면,

B는 임시 더미 데이터(하드 코딩)으로 코드 테스트를 한다거나, 일단 다른 작업을 진행하는 등의 판단이 보다 수월했습니다.

추가로, 회의 시간이 아니더라도 초기에 합의된 방향으로의 구현이 어렵거나, 다른 아이디어가 생길 경우,

그때 그때 의견을 나눠서 방향을 정한것도 좋았습니다.

의견을 나눌 때, 코드 작성 전에 계획에 대한 이야기를 하면

듣는 입장에서는 어떤 내용의 코드인지 잘 이해하기가 힘들어지고,

코드를 작성하고 해당 코드에 대한 의견을 물으면,

불필요한 코드로 결론 날 경우, 작성했던 코드를 다시 롤백 해야하는 상황이 생겼습니다.

앞으로는,

자신의 코딩 계획을 좀 더 논리적으로 설명 한다던가 , 간단한 예시 코드 정도까지만 작성하여 의견을 교환하면

위와 같은 일을 방지할 수 있을 거라고 생각합니다.

코드 PR 을 올리면 PR 코멘트 외에도, 코드 작성자가 직접 해당 코드를 리뷰하는 시간을 가졌습니다.

위 방법으로 어떤 코드가 PR 된 것인지 좀 더 명확하게 팀에 공유가 될 수 있었는데요,

아쉬운 점이 있다면 리뷰 자체의 규칙을 정한것은 아니었기 때문에

팀원 모두가 PR한 내용의 코드를 설명하고, 테스트 과정을 보여주고 , 결과까지 보여주는 것에 시간 소요가 꽤 있었습니다.

불필요한 시간이었다는 것은 절대 아니지만, 목표는 어디까지나 merge 결과 이상이 없어야하는 것이었기 때문에,

코드의 목적, 테스트 과정이 명확했다는 부분과, 그 결과 확인된 이상이 없다는 점 정도만 리뷰하고

자세한 코드 해석은 주석과 코멘트를 활용했다면 리뷰 시간을 좀 더 단축 할 수 있을 것 같다고 생각합니다.

과제 진행상황 ...  물론 맡은 부분만 !

기능적인 부분은 전부 구현되었다. 어느정도 UI 의 변화도 있었다.

index.js 에 만들었던 상점 부분의 코드가 전부 빠지고

div 뼈대만 남게 되었다.

해당 부분은 game.js에서 채워지도록 작성했다.

초 하드 코딩 상점이 아니게 되었다는 말씀 !

강화 기능을 추가함에 따라, ★ / ☆ 로 강화 단계를 표기하게 했다.

강화 정보를 MetaData 를 담고 있는 towerEnhance 테이블이 추가되었고, 

강화 데이터를 포함한 모든 데이터들은 redis에서 관리하고 있다.

레디스에 쌓인 데이터를 조회하여 검증 및 데이터 갱신이 이루어진다. 

추가적으로, 타워 클릭 시 메뉴창을 띄워서 

클릭한 타워의 정보를 확인 가능하게 만들고, 

해당 타워의 강화와 판매가 이루어 지도록 했다.

또, 해당 타워의 사거리를 원으로 그리면서, 

사거리를 확인함과 동시에 어떤 타워가 클릭된건지 좀 더 명확하게 알 수 있게 만들었다.

강화버튼을 클릭 하면, 서버로 보내지는 payload 는 해당 타워의 x y 좌표 뿐이며, 

해당 타워는 redis 에 저장해놨던 tower 데이터를 긁어와서 해당 좌표의 타워가 있는지 확인하고, 

저장되어있는 towerType (타워 유형), 좌표, 강화횟수 ( 구매 시 0으로 기록) 를 기반으로 검증이 진행되고, 

유저의 보유 소지금 또한 서버에서 관리가 되고 있기 때문에 , 

강화 시 소모되는 골드 또한 반영이 되도록 했다.

그 결과 리턴하는 패킷

클라이언트에서는  socket.on , 'response'  로 통해  서버의 패킷을 받는다.

위와 같은 형태로 구매, 판매, 강화가 실행된다.

도전기능 - 타워 판매 

타워 담당 포지션인 만큼, 해당 기능을 구현해 보기로 했다. 

가장 먼저 필요한 것은 캔버스에 그려진 그림을 특정하는 방법을 알아야한다.

많은 사람이 찾는 기능이라서 그런지, 검색 결과가 많았다. (다행)

우선 클릭 이벤트를 만들어줬다.

굉장히 보편적으로 사용태는 형태인 듯 하다.

이 부분을 잘 활용하면 ,

타워 뿐만 아니라 몬스터나 메인기지 등등을 선택했을 때에도 특정 이벤트가 실행되도록 하는것이

가능할 것 같다.

클릭 시, 해당 타워 오른쪽에 버튼 두개를 생성하도록 하고,

해당 버튼 클릭 시, findClick 으로 찾은 타워를 그대로 인자로 사용해서 함수를 실행하여 써먹으면 된다.

31번 핸들러를 통해 서버로 타워 판매에 대한 요청을 하게되고,

위 핸들러 함수를 통해 이벤트가 처리된다. 

해당 핸들러 내에서는 payload를 통해 해당 타워의 type (어떤종류의 타워인지) 을 받게되고 

서버가 가진 meta data에서 일치하는 type을 찾아서 가격을 정보를 구해온다.

돈 계산을 적용하고 , ( 현재 하드 코딩으로 타워 구매 가격의 절반을 획득 )

그 후엔 Redis 에서 판매한 타워에 대한 데이터를 지우는 작업을 한다.

updateTower 를 통해 redis 데이터를 수정한다.

추가적으로 totalGold (서버에서 계산한 user의 소지금 을 보내서, 클라이언트에 적용 (갱신) 한다.

팀 프로젝트가 시작 !

사실 과제 발제는 10.08일 이었지만, TIL을 쓸 시간이 나지 않아서 이제서야 

해당 과제의 첫 TIL을 작성하게 되었다.

어디까지나 백엔드 트랙이기 때문에, 클라이언트에 해당하는 코드는 발제와 동시에 지급받았다.

지급받은 클라이언트는...

진짜.. 최고의 클라이언트.. 호우 

내가 담당한 부분은, 타워 구매에 관한 부분이고,

이미 발제일로부터 시간이 꽤 흐른 뒤이기 때문에 많은 부분이 진행되었다.

임무 중, 가장 핵심인 game.js 의 타워 구매 함수이다. 

이번 과제 중 가장 어려웠던 부분이 포함되어있는데,

towerData ... 어디서 얻어온 것인가 !

그것은, 클라이언트 내 socket.js 에 있는 response 의 .on  부분에서 

handlerId 2  를 포함하는 패킷을 받는다면, 해당 response 가 가진 데이터를 각각 파싱하는 부분이다.

( 위 코드는 리팩토링 예정에 있다. )

그럼, handlerId2 를 어디서 보내는가!

서버측에서, 게임이 실행과 같이 실행되는 gameStart 함수에서, 

데이터 베이스 (RDS) 에 있는 데이터를 전부 find 해와서 handler id 2로 보내주게 된다. 

해당 데이터들은 전부 메타데이터 형태이기 때문에, 게임 진행에 필요하므로 ,

서버에서 게임 시작 시 , 클라이언트에게 보내주게 되는 것이다 ! ★ ★ ★

결과적으로, 서버에서 데이터베이스를 조회하고 보낸 메타 데이터를 가지고,

클라이언트에서 타워 정보를 셋팅한다고 볼 수 있다.

타워 구매 후, sendEvent 를 통해 handlerId :30 으로 요청을 날리는데, 

현재는 towerType (구매 한 타워의 종류) 와 position (구매한 타워의 좌표) 를 payload 로 보내고

서버에서는 해당 데이터를 받아,  쌓아둘 데이터는 쌓아두고 (배열에 push) , 

검증이 필요한 부분은 검증을 하게 구현 해두었다.

현재는 setGold (서버가 기록하는 해당 유저의 gold 변화) 을 전부 합산한

 getTotalGold  가 0 미만 이 될 경우, 해당 유저를 치터로 간주하는 검증을 하고 있는 상태이다.

해당 Gold 검증 로직은 회의를 통해 변경 될 예정에 있다.

현재는 작업이 꽤 진행된 상태로, 이미지를 추가하고, 상점 UI 를 만들어 놓은 상태이다.

그러나, 아직 도전기능에는 손을 못대고 있기 때문에, 힘을 더 내야한다.

CPU , Central Processing Unit   란?

컴퓨터에 관심이 있다면,

전공자가 아니어도 CPU 가 컴퓨터 부품 중 하나라는것은 알 것이다. 

CS 에서 말하는 CPU 가 바로 그 CPU가 맞다 !

CPU 는 말 그대로, 컴퓨터의 시스템의 중앙 처리 장치를 말한다.

컴퓨터의 모든 연산 ( 산술 연산 / 논리 연산 ) 이 일어나는 곳이다.

CPU 는 크게 제어 장치, 연산 장치, 레지스터 와 각 구성 요소를 연결하는

내부 버스 로 구성되어 있다.

가산기 (Adder) = 2진수 덧셈을 수행

보수기 (Complementor) = 뺄셈을 덧셈으로 변환하는 역할

누산기 (ACCumulator) = 가산기의 연산 결과를 누적하는 역할

데이터 레지스터 (Data Register) = 연산에 필요한 데이터를 임시로 저장