IOCP 실습 9 채팅 서버 Redis를 사용한 로그인 처리

IOCP 실습 9 채팅 서버 Redis를 사용한 로그인 처리

위에서 적었던 대로 현재 프로젝트에 설치한 버전은 새로 바뀐 부분이 많고, 이전 버전대에 비해서 여러 가지 오류들이 많이 보고가 되어서 바로 직전 버전으로 새로 재 설치 할 예정입니다. 플러그인을 제거하는 방법은 단순하게 아래 경로에 있는 GooglePlayGames 폴더를 제거하면 됩니다. 프로젝트의 Asset 폴더 GooglePlayGames 폴더 제거 이전 버전 GPGS 플러그인 v0.10.14 임포트 해당 플러그인 깃헙의 릴리스 페이지를 보시면 위에서 두 번째에 v.0.10.14 버전 플러그인을 찾을 수 있습니다.

FirebaseManager 구조 수정

현재 FirebaseManager는 Firestore를 거의 담당하고 있습니다. 이 상태에서 Firebase Auth나 다른 Firebase의 기능들을 추가한다면, 추후 유지 보수가 어려워질 것으로 판단하여 하나하나씩 기능 별로 핸들러를 구연하여 FirebaseManager에서는 해당 핸들러에 접근하는 구조로 수정할 예정입니다. 과거 Firestore 기능을 FirestoreHandler로 분리 FirestoreHandler 클래스를 추가한 후 초기화 코드 및 과거 메서드들을 모두 옮기고, 주석 정리를 추가했습니다.

FirebaseAuthHandler 추가 FirebaseAuthHandler를 추가하여 FIrebaseAuth와 연관된 기능들을 추가해 두겠습니다.

첫째 이번 실습에서 가장 중요한 패킷에 대하여 분석하자면 pragma packpush,1struct PACKETHEADERUINT16 PacketLengthUINT16 PacketIdUINT8 Type 압축여부 암호화여부 등 속성을 알아내는 값pragma packpop

패킷은 다음과 같이 정의되어 있었어요. 위의 해야할 것 분석 내용과 같이 정의되어 있지만 이곳에서 중요한 것은 바이트 정렬입니다.

바이트 정렬을 설명하자면 바이트 정렬을 활용하는 원인을 단순하게 설명해보자면. 바이트 정렬을 하지않고 위의 구조체를 선언하게 되면 해당 구조체의 크기는 2바이트 2바이트 1바이트가 아닌 2바이트 2바이트 2바이트인 총 6바이트의 범위가 잡히게 됩니다.

Firebase Distribution을 통한 테스터 배포

전 까지는 구글 플레이 콘솔을 통하여 내부 테스트를 트랙을 통하여 테스트를 진행하였었는데 이 경우, 처음 내부 테스트 트랙 발매 시 검토나 테스터가 다운로드를 하기까지 엄청 오랜 시간이 걸리는 문제가 있습니다. 이런 사안을 해결할 수 있는 방안으로 Firebase Distribution을 추천합니다. 해당 기능을 이용하면 오래 기다리지 않고, 바로 테스터에게 앱을 전달 및 테스트 진행이 가능합니다.

아래부터는 Firebase Distribution을 사용하는 방법에 대한 설명입니다. 빌드를 마친 후에는 Firebase Console로 이동하여 Firebase Distribusion을 찾습니다.

설계와 구현

먼저 RedisTask를 정의하고 시작하겠습니다. RedisTask 또한 어떤 작업인지 구분할 RedisTaskID가 필요합니다. enum class RedisTaskID UINT16INVALID 0,REQUESTLOGIN 1001,RESPONSELOGIN 1002,

이곳에서 중요한 것은 ID의 값이 PacketID와 중복하지 않도록 하는 것입니다. PacketID 값은 3자리 수, RedisTaskID의 값은 4자리 수로 지정하여 서로 충돌하지 않도록 만들어주었다.

중복되지 않도록 만들어 주는 것은 Packet 스레드에서 결과를 처리하게 될 때 ID 값을 서치하여 함수 포인터를 사용하여 적절한 함수를 사용하도록 해야하는데 이것을 같은 map 자료구조 안에 담겨있도록 만들었기 때문입니다.

최흥배님 유튜브 설명 핵심

이번 코드를 분석하고 만든 결과 해당 코드에는 방어코드가 전부 빠져있었어요. 패킷 처리 스레드에서 IO와 네트워크 통신을 하면 안 됩니다. 이유없이 분리해야 한다 워커 스레드를 제작해서 처리하거나 분포 스레드 형식으로 나누어야 합니다. 중복 요청인지? 응답 처리를 해도 되는지? 접속이 끊어졌는지? 등을 예외처리해야 합니다. 회사에서 만든 코드와 개인 프로젝트로 만든 코드의 차이는 방어코드입니다. 게임 서버의 해킹은 거의 비동기 함수의 취약점에서 발생합니다.

방어코드 필수 방어코드가 중요한 이유는 게임 서버는 해킹에 민감하고 위험한 상황이 발생할 수 있기 때문입니다. 그 중 하나가 비동기 함수의 취약점을 사용하는 것인데 그것은 바로 비동기 함수가 바로 완료가 안된다는 점을 악용하는 것입니다.

자주 묻는 질문