Project

General

Profile

Actions

호스트 집중형 구조

호스트 처리 구조

메인 서버

P2P 호스트 기반에서도 Main Server 의 역할은 중요합니다. Player 1 , Player 2 , Player 3 , Player 4 , Player 5 , Player 6 , Player 7 , Player 8 모두 Main Server 연결이 필수이며 User List , Room List 등의 정보 중계를 받아 멀티플레이를 시작할수 있게합니다.

릴레이 서버

P2P 호스트, P2P 멤버들에게 패킷을 전달하는 역할입니다.

본래는 UDP 기반의 Client Listener로 직접붙지 못하는 클라이언트를 위한 보조장치 정도로 구현됩니다.

P2P 호스트

룸에 참여중인 멤버들은 누구나 Peer to Peer Host + Relay Server 가 될수 있습니다. 플레이중에 발생할수 있는 Attack , Move , Spawn , Swap , Use 등의 모든 패킷들이 이곳을 거쳐 검사/처리가 진행됩니다.

길찾기 부하등을 줄여야 한다거나 명중 판정등이 매우 정확해야 한다면 Peer to Peer Host 구현을 생각해보세요. 정밀한 충돌검사, 로딩된 리소스 활용, 적은수의 멤버처리 등으로 빠른 연산 및 반응 속도가 보장됩니다.

이제 Peer to Peer Host 를 만들어 볼까요?

많은 개발자들이 Reliable UDP, Client Listener등을 구현하여 공유기 Hole Punching 을 하게됩니다. 하지만 대기시간도 너무길고, Symmetric 도 너무 끔찍하고 괴롭습니다. 결국 TCP 기반으로 Relay Server 를 개발하게 되는데 UDP 기반 설계와 혼용하게 될 경우 명중 판정 시간 문제가 발생합니다.

Full Cone (공유기) 안에 Player 1 (방장), Player 2 가 같이 있으며 TCP 기반의 Relay Server 를 통해 Player 3 가 연결중입니다. 이 경우 Player 2Player 3 가 서로 공격한다면 응답 속도가 좀더 빠른 Player 2 가 항상 유리한 상황입니다.

앞으로 TCP 기반의 Relay Server 만 사용하세요. 그러면 모든 명중 판정등의 동기화 문제는 자연스럽게 정확히 맞춰집니다.

근거리에서는 분명 UDP를 사용해 Peer to Peer Host 로 직접 붙는것이 Relay Server 를 통한 패킷 전송보다 확실히 빠르게 작동합니다. 문제는 원거리 플레이어의 고려입니다.

Peer to Peer Host 는 다음과 같은 흐름으로 처리됩니다.

Player 2Player 3 에게 공격을 했을경우 Player 2 는 연결된 Relay Server 로 패킷을 전달합니다. Relay Server 는 다시 Peer to Peer Host ( Player 1)에게 해당 패킷을 전달하게 되며 Peer to Peer Host 는 다시 해당 패킷이 문제가 없다면 생명력을 깎은뒤 이를 Relay Server 를 통하여 Player 1 , Player 2 , Player 3 , Player 4 에게 중계합니다.

Player 1 , Peer to Peer Host 는 논리적인 구분이 필요합니다. 전달되는 프로토콜 키워드 역시 USER_ATTACK , HOST_ATTACK , OTHER_ATTACK , HOST_ATTACK_OTHER 처럼 선언하여 각자 처리할수 있도록 분리하세요.

조금 복잡하지만 어쩔수 없습니다. 순서도를 그리면서 개발하세요.

Updated by Master Chief 12 days ago · 3 revisions