Изучил устройство сетевых подсистем в некоторых движках. Для начала - в околоклонах того же квейка. Что хочу сказать - там абсолютно везде использовано допущение, что сеть должна посылать пакеты намного реже, чем сервер выполняет кадров. Мало этого - в большинстве случаев там ещё нет и явной связи между кол-вом кадром выполненных сервром и временем для передачи очередного пакета. Сеть живёт по каким-то своим асинхронным правилам. Из-за этого обстоятельства нам приходится накапливать на клиенте кадры, пытаться всё это дело проинтерполировать или предсказывать. Структуры, нужные для интерполяции или предсказания занимают очень много места на самом деле. Да и само выполнение сетевого кода далеко не бесплатное.
Пока что навскидку наметил вот какую схему сетевой интеракции:
1. Сервер и Клиент хранят в себе состояние предидущего кадра, для каждого объекта отдельно. Хранят в виде bitstrem в raw-массиве и только для тех объектов, которым вообще требуется синхронизация. Критерии известны с незапамятных времён - у объекта должна быть модель. Разумеется можно завести какой-то флажок для форсирования отправки на клиент, ну руководствоваться одним только флажком неудобно.
2. Клиент и Сервер тикают синхронно 60 кадров в секунду. Никакого удушения и пропуска пакетов не предусмотрено. Это в свою очередь избавляет нас от необходимости заведения каких-то промежуточных структур для интерполяции значений, которые ещё надо куда-то сохранять, менять местами и выполнять кучу дополнительных действий. В норме интерполяция не нужна вообще. Я допускаю необходимость локальной интерполяции, скажем в рамках того же сервера, когда монстры делают шаг всего 10 раз в секунду, а в промежутках их позиция плавно двигается к заданной точке. Как минимум потому что между этими действиями нет реальных факторов в виде лага сетевого пакета, значит такая интерполяция будет всегда работать надёжно.
3. Несмотря на отсутствие пропуска пакетов, в дело вмешивается фактор их задержки. Если задержка менее времени кадра - менее 16 милисекунд, то всё хорошо. Нам даже не потребуется ничего предиктить.
Если же задержка выше, то клиент продолжает выполнять локальную симуляцию мира в ожидании очередного пакета. И при получении данных - просто обновляет их для клиентских объектов.
4. При таком подходе размер пакета может вырастать до приличных значений, однако не всё так плохо.
- Посылаются только переменные, отличные от ноля
- Посылаются только переменные, которые изменились с преведущего кадра
- Посылаются в виде небольшого кол-ва бит
- Если пакет достаточно большой, его можно дополнительно сжать LZSS
- Если даже такой пакет превысил MTU, его можно слать фрагментами. Фрагментация отправляет пачку пакетов за один кадр, но с этим я пока ещё толком не разобрался. UDP совершенно точно может отправлять и принимать пакеты размером до 65к чего бы мне хватило за глаза, но к сожалению в целях совместимости в большинстве случаев размер пакета ограничен прямо в настройках роутера.
Любопытно, что вышеприведённой схеме в наибольшей мере соответствует Normal Quake, который пакеты не душит, правда и предиктинга там тоже нет. Собственно уже в QuakeWorld ввели удушение пакетов и на тот момент (97-й года, диалап) это было неплохим решением. Ну а потом это удушение унаследовали все форки квейка, включая сорс и вероятно даже сорс2.
Надо будет ещё исследовать унреалы, край-энджины, сталкер.
Дядя Миша писал: - Если даже такой пакет превысил MTU, его можно слать фрагментами. Фрагментация отправляет пачку пакетов за один кадр, но с этим я пока ещё толком не разобрался. UDP совершенно точно может отправлять и принимать пакеты размером до 65к чего бы мне хватило за глаза, но к сожалению в целях совместимости в большинстве случаев размер пакета ограничен прямо в настройках роутера.
Кстати да, я тоже сталкивался с этим на Юнити, на разных провайдерах и роутерах размер пакета может отличаться. Где то он пропускает, а где то нет. Неужели нет какого то стандарта?
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Стандарт есть, и он как раз и равен 1400 байт.
Проблема сразу с двух сторон. Этот стандарт был принят во времена диалап подключения и давно уже устарел. Но его по прежнему придерживаются по принципу "как бы чего не вышло". UDP позволяет отправлять до 65 килобайт за раз, чего достаточно для всех случаев. Умные роутеры сами фргаментируют такие пакеты на мелкие. Но даже сейчас далеко не все этим занимаются. Потому что стандарта на фрагментацию - нет.
А вторая сторона - то что 1400 байт для одного пакета никогда не хватает.
Скажем во время игры можно удерживаться в рамках такого пакета без проблем, а во время подключения - нет. Кстати в том же QuakeWorld фрагментация как раз и была во время подключения, а потом она уже была не нужна.
Цитата:
FiEctro писал: могут ещё использовать различные веб протоколы
UDP это протокол с минимальной латентностью, в этом его смысл.
Дядя Миша писал: Любопытно, что вышеприведённой схеме в наибольшей мере соответствует Normal Quake, который пакеты не душит, правда и предиктинга там тоже нет. Собственно уже в QuakeWorld ввели удушение пакетов и на тот момент (97-й года, диалап) это было неплохим решением.
Там чета в мемуарах же они писали что сначала они сильно недооценили убожество телефонных линий, по факту средний пинг был выше раза в два, и т.д.
Crystallize писал: сначала они сильно недооценили убожество телефонных линий
Ну да, понадеялись на лучшее, ведь Америка - это великая страна, там же всё идеально и по другому быть просто не может
Ну а мне собственно осталось выполнить две глобальных, масштабных задачи:
1. Имплементация сетевой подсистемы в движке
2. Написание собственного редактора
Когда это будет сделано, можно считать что основной цикл разработки завершён и наступает время техподдержки. Буду спокойно дописывать некоторые недостающие мелочи, добавлять фичереквесты по просьбам фичекриперов, исправлять ошибки, итд.
На всё-про-всё понадобится ещё примерно год. Может быстрее управлюсь, но пока не буду загадывать.
Дядя Миша
А чем мультиплеер первой и второй кваки отличается от мультиплеера первохалфы? И что с ним сделали в сорсе?
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
В первой кваке не было предиктинга. Она вообще не была рассчитана на игру по интернету в тогдашних условиях. Чтобы исправить это недоразумение, Кармак сделал QuakeWorld, который был заточен исключительно под мультиплеер. Халфа первоначально базировалась на исходниках кваки, не заточенной под мультиплеер - это самые первые версии. Потом появилась CS и встал вопрос о комфортной игре по интернету.
Тогда вальвовцы конкретно прокачали сетевой движок, используя наработки от QuakeWorld, Quake 2 и собственные. В результате получилась мощная сетевая подсистема. Она же изначально была использована в Сорсе, но что там потом с ней делали я уже не знаю.
Дядя Миша писал: 3. Несмотря на отсутствие пропуска пакетов, в дело вмешивается фактор их задержки. Если задержка менее времени кадра - менее 16 милисекунд, то всё хорошо. Нам даже не потребуется ничего предиктить.
Предиктинг и задержки между кадрами -- вещи ортогональные. Хороший предиктинг должен "ощущаться" как локальная игра. Отличный предиктинг ещё и освобождает сервер от пересылки части данных.
Можно конечно сделать иначе и на клиенте крутить основную логику, а сервер занять только пересылкой данных между клиентами. В некоторых играх это сделано (и теперь они борются с читами).
Твоя схема синхронно отправлять 60 кадров отличается от удушения в кваке только тем, что лимит просто чуть выше. 60 кадров может не хватить клиенту, а серверу и явно сильно больше можно.
Цитата:
Дядя Миша писал: UDP совершенно точно может отправлять и принимать пакеты размером до 65к чего бы мне хватило за глаза, но к сожалению в целях совместимости в большинстве случаев размер пакета ограничен прямо в настройках роутера.
Физически, да, 65к. Но это редкость.
Оно, в том числе ограничено не только роутером который у вас стоит дома, но и всем сетевым оборудованием, которое находится на пути. Есть такая штуковина, которая называется Path MTU Discovery, работает просто -- если пакет не пролазит, то в ответ присылается ICMP пакет с MTU. Посылать до тех пор, пока не пролезет. Работает не везде, потому что ICMP можно игнорировать.
Цитата:
FiEctro писал: Кстати да, я тоже сталкивался с этим на Юнити, на разных провайдерах и роутерах размер пакета может отличаться. Где то он пропускает, а где то нет. Неужели нет какого то стандарта?
В том-то и дело, что он как бы есть. В RFC 791 у IPv4 минимальный размер датаграммы что-то в районе 570 байт, на практике что-то в районе 1400-1500, в какой-нибудь локалке может быть и 65к. У IPv6 таки подняли лимит до 1280, с той же оговоркой, что может быть и больше. Надо ещё не забывать что Ethernet MTU -- это 1500 байт, поэтому я мало понимаю, где Дядя Миша находит 65к.
Добавлено 29-09-2023 в 01:11:
Алсо, 2 Дядя Миша, testpacket для определения MTU был не очень хорошей идеей. Учитывая что это пакет который отправляется до поднятия нетчана, его может отправлить кто угодно. В том числе отправлять по кругу, высаживая FPS сервера в 0. В том числе отправлять с левых IP адресов. (да, это возможно, просто отправляешь сырой IP пакет с левым адресом в поле source. Некоторые провайдеры это не чинят, несмотря на то, что противодействовать этому очень легко)
a1batross писал: Предиктинг и задержки между кадрами -- вещи ортогональные
Когда у тебя асинхронная петля и клиент-сервер тикают с одинаковым зазором предиктингу просто некуда вмешиваться. Такое может возникнуть при условии, что в один из кадров пакет не пришёл.
Цитата:
a1batross писал: Отличный предиктинг ещё и освобождает сервер от пересылки части данных.
Одновременно усложняя сетевой механизм и раздувая память для хранения дельты.
Цитата:
a1batross писал: 60 кадров может не хватить клиенту, а серверу и явно сильно больше можно.
Сейчас всё работает на 60 кадров. Правда совсем без сети.
Цитата:
a1batross писал: testpacket для определения MTU был не очень хорошей идеей
Учитывая открытые сорцы и нелюбовь к своевременному апдейту на исправленные версии, наличие сети само по себе - не очень хорошая идея.
Возможно ли какое-то упрощение работы с клиент-сервером? Например я залажу в условный func_car который горит в лесу и в зависимости от того, от 3-го лица у меня камера или от 1-го, мне может понадобиться анимация всего персонажа или по крайней мере камеры и вьюмодели. Значит нужно снова тянуться в hud.cpp чтобы сделать мессагу и проиграть анимацию на клиенте.
Crystallize писал: Возможно ли какое-то упрощение работы с клиент-сервером?
Сейчас всё устроено таким образом, что на клиенте - только отрисовка худа и обработка кнопок. Ну и небольшой сетап экрана - его размер и fov.
Больше там ничего нет и не планируется. Т.е. постоянно лазить туда-сюда не придётся.
Добавлено 29-09-2023 в 13:08:
Вью-модели теперь - это самые обычные энтити, которые приаттачены к игроку. Я там в дальнейшем им добавлю фильтры, чтобы моделька от первого лица рисовалась только от первого лица и у локального клиента.
Дядя Миша писал: Когда у тебя асинхронная петля и клиент-сервер тикают с одинаковым зазором предиктингу просто некуда вмешиваться. Такое может возникнуть при условии, что в один из кадров пакет не пришёл.
Предиктинг исправляет проблему в основном с задержками. Нет смысла ждать пока сервер обработает +forward, если на клиенте мы можем рассчитать то же самое с минимальной погрешностью.
Без предиктинга для игрока это базовая задержка в 33 мс (отправка + получение), а она достаточно заметна, уже не говоря о задержке отображения кадра на мониторе.
Клиент так же может выставить лимит в 144 FPS, учитывая что играет он на 144 Гц мониторе. В данном случае задержка ~7мс и привязка к 60 здесь не нужна.
Цитата:
Дядя Миша писал: Учитывая открытые сорцы и нелюбовь к своевременному апдейту на исправленные версии, наличие сети само по себе - не очень хорошая идея.
Это само собой. Я сделал механизм, который сохранял чексуммы от тестового пакета. И он у меня даже заработал, по крайней мере стало невозможно положить сервер просто отправляя по кругу запросы на тестовый пакет, но в итоге мне просто не понравилось то как я сделал.
a1batross писал: Клиент так же может выставить лимит в 144 FPS, учитывая что играет он на 144 Гц мониторе. В данном случае задержка ~7мс и привязка к 60 здесь не нужна.
Кстати а не будет ли дергания если фпс не кратный 60? Может предусмотреть вариант 72?
Добавлено 29-09-2023 в 23:49:
Цитата:
Дядя Миша писал: Сейчас всё устроено таким образом, что на клиенте - только отрисовка худа и обработка кнопок. Ну и небольшой сетап экрана - его размер и fov.
Больше там ничего нет и не планируется. Т.е. постоянно лазить туда-сюда не придётся.
Кажется что-то такое было в клиенте ХЛ1 на релизе, а потом Вальв туда целого слона запихнули.
Добавлено 29-09-2023 в 23:50:
Так получается что концепция мессаг вообще уходит в прошлое, ну для моддера по крайней мере?
27-09-2023 22:42
