OrionXL

Оценка смещения времени в сетевых приложениях

Роман Иванов @ 10:52 07.12.2009

Для чего это необходимо? В сетевых приложениях, особенно в играх, обычно возникает необходимость придерживаться определенного ритма времени, точнее синхронизации событий во времени между группой компьютеров – использование единой концепции логического времени (logical time). Физическое время, часы на компьютере, клиента и сервера имеют различный ход, т.е. они не синхронизированы. В связи с этим появляется проблема в сопоставлении событий между машинами, проблема перехода к логическому времени от физического.

Иными словами клиент и сервер должны работать в одном синхронном игровом времени (логическое время). Оно определяется тем, как далеко симуляция игрового процесса отдалилась от начала игры.

Как это работает? Для реализации этой идеи, клиент должен добавить свое физическое время (реальное значение часов) к каждому исходящему пакету, а сервер, когда примет этот пакет, должен запомнить это значение, и также запомнить момент приема посылки в своем физическом времени. Далее сервер в следующей своей посылке этому клиенту должен передать оба значения этого времени и дополнительно время посылки сообщения, для учета задержки ушедшей на рабочий, игровой процесс. Далее клиент должен использовать эти данные для расчета RTT (ping, real time to transmit – времени на передачу сообщения) и определения смещения от своего физического времени к логическому времени. Иными словами все игроки должны синхронизироваться с сервером, логично согласитесь?

Вот кусок мнемокода для пояснения выше изложенных умозаключений.

Client Logical Time = Client Physical Time + Client Offset to Logical Time.
.
Client->Server:.
CP1=clock (); // client physical time – физическое время клиента.
send(CP1);.
.
Server:.
receive(CP1);.
SL1=clock (); // server logical clock – время на сервере, мы приняли его за базовое.… game time (обработка игрового процесса) ….
.
Server->Client:.
SL2=clock (); // server logical clock.
Send(CP1,SL1,SL2);.
.
Client:.
receive(CP1,SL1,SL2);.
CP2=clock (); // client physical time.
ServerProcessingTime=SL2-SL1;.
RTT=CP2-CP1;.
Ping=(RTT- ServerProcessingTime)/2;.
ClientOffsetToLogicalTime=((SL2+ping-CP2)+(SL1-ping-CP1))/2;.

А вот и рисунок визуально изображающий идею метода.

time-offest-estimation

Рис. 1 Алгоритм работы метода

Из приведенного примера видно, что для расчета временной задержки передачи пакета сообщения от клиента к серверу и наоборот берется общее среднее. Это вполне оправдано, т.к. изменение задержки обычно происходит плавно и без резких скачков особенно в локальной сети; вычисления точной задержи при каждой пересылке-получении пакета данных в принципе возможно, но это будет не оправдано. Если забежать немного вперед, в игровой процесс, то, к примеру, положение объекта изменилось за время путешествия данных о положении от машины к машине, и здесь придется предсказывать (position prediction) новое возможное положение игрока в виртуальном пространстве, а здесь эти неточности окупаются J. Данная тематика будет обсуждаться в другой статье о предсказании положения игрока в сетевых приложениях (играх).

Если остались вопросы, то в интернете есть много других источников по обсуждению этой тематики.

Комментариев нет

Комментариев нет.

RSS-лента комментариев к этой записи.

Извините, обсуждение на данный момент закрыто.

алгоритмы, методы, программы - OrionXL