RTT, Latency и другие

[Crenth]

Есть реалтайм игра. Я не знаю деталей. Моя задача - серверная часть.

На клиенте и на сервере есть часто выполняемые участки кода, ответственные за обмен данными и актуализацию.
Каждый участок кода может выполняться в течение различного времени. Время выполнения зависит от возможностей и загрузки клиентского компа и загрузки сервера.
(Latency)

Кроме того пакеты летают от сервера к клиенту и обратно также всегда с различной скоростью. Которая также зависит от загрузки канала у клиента и у сервера Round-trip-time RTT)

Задача состоит в том, чтобы в определенные моменты времени приблизительно точно знать:
- время доставки пакета от сервера к клиенту
- время доставки пакета от клиента к серверу
- время, затрачиваемое обоими на обработку пакета
( Latency обеих сторон, RTT down и up)
Задача простая вроде бы. Но решение осложняется тем, что решить задачу нужно на серверной стороне.

На сервере есть доступ ко всей инфе, которую способно дать ядро Linux.
На клиенте - как обычно (netstream.info и иже с ним)

Третий день туплю - не знаю, с какой стороны подойти.

С газелями как то проще

[maxlapshin]

А что мешает написать код, который будет слать на клиента сообщение с текущим временем, после чего получать его обратно и сравнивать?

[Crenth]

Решение оказалось до безобразия простым!
Самое замечательное в том, что синхронизация таймеров сервера и клиента происходит за один шаг, без лишнего обмена данными и самое главное - с точностью до 1 мсек.
Я доволен

[Котяра]

и? где решение то?))
Колись уж давай.

[Crenth]

var stream:Object = new Object();
var LocalTime:Date = new Date();
stream.LOCALTIME = LocalTime.time.toString();
myStream.play(stream);

Задержки на сервере или на клиенте, связанные с выполнением фрагментов кода, исчисляются микросекундами. Поэтому ими пренебрегаем.
FP при отсчете timestamp чанков принимает за НОЛЬ момент вызова метода NetConnection.Connect.
Далее в каждом чанке timestamp равен разнице во времени между НОЛЕМ и моментом формирования чанка.
Network Latency измеряем в самом начале коннекта, когда в обе стороны идет обмен пакетами, превышающими TCP MSS.
Вызов myStream.play(stream) передает локальное время клиента. На сервере сравниваем chunk timestamp и значение LOCALTIME.VALUE, по которому можно вычислить момент начала сеанса.
Далее зная NetLatency вычисляем расхождение Tdelta между часами сервера и клиента.
Если прибавить Tdelta к timestamp чанка, получаем точное время отправки чанка от клиента на сервер.
Дальше не имеет значения как будет меняться NetLatency, поскольку каждый прибывший на сервер пакет имеет timestamp - время отправки.

Таким образом мы будем знать время отправки каждого чанка по серверным часам. А если засечь время прибытия чанка, можно в каждый момент времени знать BDP

[IMG]http://img44.**************/img44/5671/timelineb.jpg[/IMG]

[Crenth]

Сообщение от Котяра

и? где решение то?))
Колись уж давай.

не впечатлило ?
или нужны пояснения ?

[maxlapshin]

Сообщение от Crenth

FP при отсчете timestamp чанков принимает за НОЛЬ момент вызова метода NetConnection.Connect.
Далее в каждом чанке timestamp равен разнице во времени между НОЛЕМ и моментом формирования чанка.

Вообще, уже это неверно. Таймстемпы в RTMP не обязаны быть монотонно возрастающими по всем потокам, начиная с нуля.

[Crenth]

не обязаны.
но когда мы говорим о синхронизации для целей реалтайм игры, то будут

[maxlapshin]

А, я тебя кажется понял. Ты хочешь ориентироваться по NetStream.time?
Если так, то проверь хорошенько. Не знаю как у тебя будет, но использовать его для того, что бы узнать, что именно сейчас играет на видео, невозможно. audioBytes гораздо точнее.

[Crenth]

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


Проблема русскоязычных форумов: не с кем обсудить фундаментальные вопросы. Либо потому, что знающие предпочитают держать при себе добытые потом знания, либо потому, что никто глубоко не копает.
В любом случае не гут.