Как можно исправить транспортный путь пакета, чтобы задержка была статической?

Question

Как я понимаю, когда пакет отправляется на компьютер по протоколу IP, он следует по пути от SENDER -> ROUTER-a -> ROUTER-b -> ROUTER- x -> DESTINATION,Маршрутизация определяет, по какому пути пойдет пакет, чтобы добраться до хоста.

В настоящее время я разрабатываю игру для многопользовательских сетей с использованием UDP.Поскольку игра в реальном времени, мне нужно эффективно откатывать мир физики при каждом получении пакета, чтобы определить, что сделал клиент, когда он увидел, что это происходит.Чтобы сделать это, я должен откатить мир физики, n-секунд , где n - время, затраченное на прохождение пакета от клиента к серверу.Задержка динамическая (думаю, поправьте меня, если я ошибаюсь).

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

Answer 1

Нет, это невозможно.Интернет, по сути, не работает таким образом.Каждая сеть может маршрутизировать пакеты, как это должно основываться на информации, которая может меняться от минуты к минуте.

Answer 2

Я думаю, что фундаментальное предположение, заложенное в этот вопрос, неверно.Задержка пакетов не изменяется, потому что маршрутизируемый путь изменяется (предоставленный, это действительно имеет эффект , когда это происходит , но это не частое явление в сети), а скорее из-за других факторов, таких как перегрузка и слияние данных.

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

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

---

Cheat Proof Algorithms

Этот тип вопроса намекает на создание алгоритма "cheat proof" путемустановить базовую задержку и сказать, что любое значительное колебание - это обман.Это не плохой алгоритм в теории, но он не очень хорошо работает в реальном мире, поскольку задержка изменяется ШИРОКО из-за факторов, которые мы не можем контролировать программистами.

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

---

Потоковые приложения

Причина, по которой мы используем потоковые буферы, заключается в том, чтонепредсказуемости латентности.Если ваш поток задержек большой, ваш буфер потока также должен быть.И наоборот, если ваш поток задержки очень мал, буфер потока также может быть небольшим.Для таких приложений, как VOIP, мы хотели бы, чтобы буферы были как можно короче, но всегда есть компромисс между размером буфера относительно потока и вероятностью искажения, вызванного переполнением буфера.

---

Ваша конкретная потребность может отличаться от любой из этих двух, поэтому ваше решение может оказаться другим.Просто помните, что вы никогда не сможете контролировать задержку на 100%, если не будете контролировать сеть от начала до конца.(IE: вы не используете Интернет для передачи данных)

Answer 3

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

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

Возможно, для вашей основной проблемы лучше периодически проверять синхронизацию часов - запрос ваших клиентов на запуск NTP - это хороший способ получить все системы за одну или две секунды. (Вы должны быть в состоянии сделать все хосты намного ближе, чем это, но страница Википедии предупреждает о том, что реализация Windows может работать лучше, чем 1-2 секунды. Это прискорбно.)