페이저 퀘스트의 지연 시간 추정

이 기사에서는 Phaser Quest의 서버가 게임 내내 연결된 모든 플레이어의 대기 시간을 추적하는 방법을 설명합니다.

대기 시간이란 무엇이며 왜 측정해야합니까?

대기 시간은 게임 서버와 클라이언트간에 데이터 패킷이 이동하는 데 걸리는 시간입니다. 서버에 연결된 각 클라이언트는 여러 가지 요인에 따라 다른 대기 시간을 가질 수 있습니다. 서버 컴퓨터에서 클라이언트 컴퓨터로 또는 그 반대로 이동하려면 물리적 와이어를 통해 정보를 이동해야합니다. 인터넷상의 정보가 빛의 속도에 가까운 속도로 여행 할 수 있지만, 여전히 시간이 걸립니다. 너무 지리적으로 멀지 않은 기계와 상호 작용할 때 일반적이고 일반적인 대기 시간은 약 20ms입니다. 하지만 플레이어 중 하나가 연결 상태가 좋지 않거나 혼잡하면 대기 시간이 크게 늘어나 익숙한 지연 현상이 발생할 수 있습니다.

플레이어의 대기 시간을 잘 예측하면 여러 가지 이유로 (Phaser Quest에서 설명한 것처럼) 보상을 시도하고 게임 통계의 일부로 기록하고 문제를 발견하는 등 여러 가지 이유로 유용 할 수 있습니다.

대기 시간을 계산하는 방법

Phaser Quest에서 서버가 클라이언트에 업데이트를 보낼 때마다 수행되는 탁구 방식을 사용하여 지연 시간을 예측합니다. 다음은 프로세스입니다.
- 서버가 모든 클라이언트에 업데이트 패킷을 보냅니다. stamp라는 추가 필드가 패킷에 추가됩니다. 이 값은 업데이트를 전송할 당시 서버의 타임 스탬프입니다. 이것은 "ping"단계입니다.
- 각 클라이언트는 각 클라이언트의 대기 시간에 따라 다른 클라이언트보다 빨리 업데이트를받습니다. 업데이트를 처리하기 전에 각 클라이언트는 작은 패킷 인 "pong"을 되돌려 보냅니다. 수정되지 않은 서버가 보낸 스탬프 필드를 포함합니다.
- 서버가 클라이언트의 pong 패킷을 수신 할 때마다 패킷의 스탬프 (갱신이 전송 된 순간의 서버 시간 소인)와 현재 서버 시간 소인을 비교합니다. 차이점은 업데이트가 클라이언트에 도달하고 클라이언트의 응답이 서버에 도달하는 데 걸리는 시간 (밀리 초)입니다. 이 값을 2로 나누면 클라이언트의 대기 시간을 예측할 수 있습니다.
-이 상호 작용은 서버가 클라이언트에 업데이트를 보낼 때마다 반복되므로 전체 게임에서 지연 시간을 샘플링합니다. 서버는 각 클라이언트에 대해 마지막 20 개의 대기 시간 예상치 목록을 보관합니다. 클라이언트의 대기 시간에 대한 실행 예상치는이 20 개의 마지막 추정치의 중간 값에 해당합니다 (중간 값은 평균과는 달리 특이 치에 강하기 때문에 선호됩니다).

다음은 pong 응답 처리를위한 코드입니다. server.js

ocket.on('ponq',function(sentStamp){ // sentStamp is the stamp sent back by the client
        // Compute a running estimate of the latency of a client each time an interaction takes place between client and server
        // The running estimate is the median of the last 20 sampled values
        var ss = server.getStamp();
        var delta = (ss - sentStamp)/2;
        if(delta < 0) delta = 0;
        socket.pings.push(delta); // socket.pings is the list of the 20 last latencies
        if(socket.pings.length > 20) socket.pings.shift(); // keep the size down to 20
        socket.latency = server.quickMedian(socket.pings.slice(0)); // quickMedian used the quickselect algorithm to compute the median of a list of values
    });

이 구성표를 사용하면 서버가 언제든지 게임의 각 클라이언트의 대기 시간을 대략적이지만 견고하게 추정 할 수 있습니다. 탁구 상호 작용과 업데이트를 결합하는 것은 의도적 인 일임에 유의하십시오. 이러한 상호 작용은 대개 트래픽이 적을수록 여분의 데이터없이 이루어집니다. 그러나 데이터가 클라이언트와 적극적으로 교환 될 때 "실제"대기 시간이 무엇인지 평가하는 것이 더 흥미로운 것 같습니다. 조금 더 높을 수도 있지만 클라이언트가 경험하는 업데이트 지연을보다 잘 나타냅니다. 또한 업데이트와 함께 번들링하면 대기 시간을 샘플링하기 위해 별도의 패킷을 별도로 전송하는 오버 헤드가 발생하지 않습니다.

결론

이 기사에서는 고객의 대기 시간을 예측하는 매우 간단하면서도 강력한 방법에 대해 설명했습니다. 모든 의견은 환영합니다. 과거 프로젝트에서 다른 접근법을 구현했거나 사용했는지 여부를 알려 주시면 언제든지 알려 주시기 바랍니다.