113 lines
6.1 KiB
Plaintext
113 lines
6.1 KiB
Plaintext
# 서버 리펙토링 로드맵
|
|
|
|
1. 서버 단독 진행 내용
|
|
|
|
1.1. 패킷 수신시 패킷 식별 정보를 활용한 수신 Pakcet Handler 관리 및 호출 구조로 변경 해야 한다. (코드번호:2.1.)
|
|
- 현재 패킷을 새로 추가할 때마다 패킷을 분석 및 전달 하는 코드를 유사 코드를 매번 추가해야 하는 불편함이 있다.
|
|
(개발시 패킷 가독성도 상당히 떨어져 비효율적임 !!!)
|
|
Protobuf로 정의된 패킷용 메시지 계층 구조를 활용하여 패킷을 헤더화해서
|
|
PacketHandler가 호출되는 구조로 수정 한다.
|
|
|
|
1.2. 객체 지향 프로그래밍(OOP)과 SOLID 정책을 활용하여 설계하고 구현하자. (코드번호:1.2.)
|
|
- 서버 각 프로세스내에 네트워크 Session 객체가 여러가지 로직 처리를 담당 하고 있는데,
|
|
여러가지 역할을 단일 역할 객체로 각각 분리 하여 복잡한 로직들을 분리 한다.
|
|
|
|
=> 완료일 : 9/27
|
|
|
|
=> 이하 일정 산정 및 우선 순위 결정 필요
|
|
|
|
|
|
|
|
|
|
1.3. 각종 저장 데이터의 키 구조를 재정의 한다. (코드번호:2.20.)
|
|
- 키 구조 설계시 효율적인 형태로 되어 있는지 체크하여 되도록이면 Document 형태의 저장은 지양 하도록 한다.
|
|
|
|
=> 우선순위 최고 / 아바타 데이터 수정시 전체적인 업데이트를 해야되는 이슈
|
|
|
|
|
|
1.4. 플레이어의 이동시 속도에 대한 타당성을 체크하는 로직을 서버에 추가해야 한다. (코드번호:2.15.)
|
|
- 현재 서버측에 플레이어의 이동 요청에 대한 방어 로직이 구현 되어 있지 않다.
|
|
|
|
=> 우선순위가 중간 / 아바타에 능력치 시스템이 없는데 (스탯 기획하고 논의해야함)
|
|
|
|
|
|
** 1.5. 유저 상태에 의해 패킷 처리 가능 여부를 체크할 수 있는 기반 구조를 만든다. (코드번호:2.15.)
|
|
- 수신된 패킷을 매번 수신 패킷 핸들러내에서 유저의 상태를 체크하여 예외 처리하는 구조는 안정성있는 로직 관리가 쉽지 않다.
|
|
- 유저 상태별 패킷 처리 가능한 목록 관리 구조를 만들어 패킷 수신시 네트워크 로직 내부에서 예외 처리되도록 개선 한다.
|
|
|
|
=> 우선순위가 낮고 /
|
|
|
|
|
|
** 1.7. 현재의 GMTool을 서버 모니터링 툴로 리뉴얼 한다. (코드번호:7.1.)
|
|
- 서버 프로세스를 제어하는 ServerControl Agent 프로세스를 개발 한다.
|
|
- 서버 모니터 시스템 개발 기획서를 작성 한다.
|
|
- ServerControl Agent를 관리하는 ServerMonitorServer 를 개발 한다.
|
|
- ServerMonitorServer를 제어하는 ServerMonitorTool 을 개발 한다.
|
|
- 주요 기능은 서버 시작, 서버 종료 서버 자동재시작, 서버 시스템 및 컨텐츠 주요 정보 조회 및 서버 덤프파일 출력
|
|
- 모두 .Net C# 기반으로 개발 한다.
|
|
|
|
=> 우선순위가 중상 / 모니터링 툴 개발
|
|
|
|
|
|
1.8. 서버 검수용 봇을 리뉴얼 한다. (코드번호:7.2.)
|
|
- ClosedProject에 있는 봇 리뉴얼 프로젝트를 재개발 한다.
|
|
- 봇 시스템 개발 기획서를 작성 한다.
|
|
- 봇 프로세스를 제어하는 BotMonitorServer 를 추가로 개발 한다.
|
|
|
|
=> 우선순위가 중상 / 봇 개선
|
|
|
|
|
|
** 1.9. 서버 모니터링 툴에서 네트워크 수신 패킷 처리시 or DB 쿼리 요청시 처리를 인위적으로 지연시켜
|
|
서버의 각 공정별 응답 지연을 발생시키고 지연 시간의 범위에 따라 서버 안정성을 검수 한다. (코드번호:8.1.)
|
|
- 서버 모니터링 시스템에서 해당 서버들에 대해 패킷 수신 및 DB 요청의 처리 지연 기능을 추가 한다.
|
|
|
|
=> 우선순위가 중상 / 부하 성능 검증
|
|
|
|
|
|
1.6. 비지니스 로직 & DB 쿼리 & 비지니스 로그 들을 하나의 트랜젝션으로 묶고 Batch 화 해주는 구조를 만들어야 한다. (코드번호:2.2.)
|
|
- 여러개의 작업 단위들이 실행되어 모두 반영되던가 아니면 모두 반영되지 않도록
|
|
처리 하는 구조가 전혀 없다.
|
|
해당 관련 작업을 진행 하는 프로그래머가 어렵지 않게 구현 할 수 있도록 구조화 해서
|
|
제공해 주어야 한다.
|
|
|
|
=> 우선순위가 제일 낮고 / 재화소모, 구매 관련
|
|
|
|
|
|
|
|
1.10. 로그인시 체크할 접속 관리용 IP 대역 체크 기능 추가한다. (코드번호:9.2.)
|
|
- 로그인시 접속이 가능한 IP 인지 접속 관리용 IP 대역 데이터를 읽고 판단 하여
|
|
접속을 허용 여부를 판단 한다.
|
|
|
|
=> 우선순위가 낮음
|
|
|
|
|
|
|
|
1.11. 인벤토리 시스템 리뉴얼 <- 인테리어 프로젝트 시스템을 위한 확장 고려 (코드번호:2.16.)
|
|
|
|
|
|
1.12. 아이템 시스템 리뉴얼 <- 기획서상의 각종 아이템 효과를 위한 확장 고려 (코드번호:2.17.)
|
|
|
|
|
|
1.13. 이펙트 시스템 개발 <- 버프 효과를 위한 이펙트 베이스 시스템 구조 고려 및
|
|
추후 엑티브 & 페시브 스킬 & 다양한 충돌체도 고려할 것인가?
|
|
|
|
|
|
1.14. 능력치 효과 시스템 리뉴얼 <- 나중에 생길 수 있으니 개발해 두자...
|
|
|
|
|
|
|
|
|
|
2. 클라이언트 협의후 진행 내용
|
|
|
|
=> 예정일 : 2023년 10월경 협의후 진행
|
|
|
|
2.1. ProudNet 관련 초기화 절차에서 Nagle 알고리즘을 사용하지 않도록 설정 해야 한다. (코드번호:1.7)
|
|
- 클라이언트 & 서버 모두 비활성화 설정을 해야 한다. (ProudNet 관련 코드 한줄 추가 요함)
|
|
|
|
=> 예정일 : 2024년 1월이후 협의후 진행
|
|
|
|
2.2. 프로토콜 계층 구조와 ProudNet PIDL을 여러 개로 나누어 연결 하는 구조로 리뉴얼해 보자. (코드번호:2.14.)
|
|
- 네트워크 프로토콜 구조가 3계층으로 되어 있어서 관리시 제약사항이 많아 개선 한다.
|
|
- 프로토콜 그룹 관리 정책에 따라 복수개로 ProudNet Stub & Proxy 관리가 가능하도록 개선 한다.
|
|
|