Dragon armor

Утверждать не буду, но похоже, что так. Или почти так. Может там кешируется как-то или что-то подобное делается. Ведь изначально сетевой движок рассчитан на разбивку игрового мира и разделение его по разным процессам (ещё и динамически, в зависимости от текущей нагрузки на один cell). А процесс не обязательно будет на том же компьютере. В общем, на БД у них очень сильно изначально было завязано. Да. Что логично, один процесс обрабатывает один бой. Тут ещё и кто-то должен быть выбран сервером. Пока рано об этом писать, концепция не ясна до конца. @DrWeb7_1 db_interface.hpp Серверных исходников почти нет. А в том, что есть можно посмотреть интерфейс взаимодействия между БД и *app. Один cell должен в памяти что-то держать, свои энтити, например, ещё он содержит сохранённое состояние соседних cell'ов. Картинку в доках находил, как клиент запрашивает что-то типа списка пользователей, а где находил - не помню. Там взаимодействие с БД было показано. А ещё у них внутри по сети не хило такой трафик должен гулять. Наружу видны только loginapp и baseapp, адрес которого сообщает loginapp после успешного логина. А адреса внутренних серверов скрыты и baseapp выступает в роли прокси, передавая всё необходимое на cellapp, когда начинается бой.

Кстати, до меня потихоньку стал доходить дзен движка бигворлд. В своём докладе (Максим Барышников — Миллион пользователей онлайн в World of Tanks с инженерной точки зрения) Максим говорит, что база данных в бигворлде - это очень нагруженная вещь. Мне долго не было понято, что же именно так её нагружает. Как оказалось (для меня, так вообще сюрприз) - всё, что идёт от клиента на сервер, а также всё между серверами сначала попадает в базу данных. Все обновления энтитей, создание и удаление их, взаимодействие и прочее - это всё через базу данных. Всё состояние клиента хранится в базе данных, куда едет, сколько снарядов, здоровье. Мне, естественно, такого не надо, буду всё в памяти держать, один процесс - одна арена. Типа того. Только физика уже есть, танк может уже падать и переворачиваться, это всё даёт физический движок. Да, по-другому никак не выходит. loginapp тоже можно сделать отдельным процессом, он с baseapp взаимодействует (будет) через базу данных, не зря же её делал. Сейчас вообще ужас там с передачей от loginapp к baseapp, накодил когда-то и даже соваться не хочу. Как бы да. Поэтому и написал, что если оглядываться назад, его назначение понятно. На тот момент этого флага не было, а для счётчика пакетов использовался общий счётчик пакетов. Теперь это отдельный. Меня это смущало долго, ведь все счётчики увеличивались строго на единицу, а этот как хотел, начаться мог и с 200000, а не с нуля. Теперь ясно стало, достаточно отбрасывать пакеты с счётчиком меньше, чем текущий, а сколько он - не важно, хоть на единицу больше предыдущего, хоть на 20.

Кстати, раз уж тему подняли. Долго не обновлял, хотел закончить в проекте то, что начал. Полностью переписал сетевой код. Это просто ужас какой-то, насколько сложно у бигворлда всё сделано. Учитывая, что у меня около половины возможностей не будет (просто не нужно, только разве что клиенту, а для сервера, соответственно, не надо этого реализовывать), ещё кучу надо добавить, но это уже рутина. Наконец-то, более-менее разобрался со структурой сетевых пакетов. Как оказалось, очень неправильно у меня было сделано, теперь белых пятен стало меньше. Разобрался, что означает флаг 12 в заголовке пакета. Оглядываясь назад, его назначение было очевидно, но кто же знал (нужен для ненадёжных пакетов, то есть тех, потеря которых ничем не грозит). Так же добавил отдельно loginapp и сейчас делаю реализацию baseapp (это ангар). Теперь не нужен отдельный прокси-клиент, можно напрямую подключаться к эмулятору. Хотя, в дальнейшем, прокси-клиент всё-таки будет нужен, потому что cellapp (бой, арена) будет отдельным процессом, а клиенту не отправляется новый ip (разве что штатный механизм задействовать перехода от одного сервера к другому, но хз как это для арены будет выглядеть при переходе из ангара). И в одном процессе не запустить, потому что нужен другой интерпретатор для питона, отдельный от baseapp. Но это будет наипростейший прокси-клиент, который просто перенаправляет трафик и получает от baseapp новый ip. Ну и добавил базу данных, а то у меня всё на лету генерировалось, что не есть хорошо. Осталось самое малое - отладить всё это. А то код писал, писал, а отладкой даже не занимался. И разобраться надо будет до конца с логином. Там интересная вещь картохой была добавлена. В оригинале, клиент отправлял запрос с передачей логина, пароля и получал ответ. Картоха добавила майнер своеобразную защиту от брутфорса, а именно алгоритм Cuckoo Cycle. Это, если правильно понял, такой тип алгоритма, который достаточно ресурсоёмкий для нахождения ответа, но очень простой для проверки найденного решения. И пока что не понятно, как именно происходит проверка, сервер отправляет строку, похожую на 16ричную, клиент долго её мутузит внутри себя, а отладчик у меня работать перестал по непонятным причинам и до конца разобраться не могу, хотя для успешного логина этого не нужно. @DrWeb7_1 Вращение добавлял, чтобы не реализовывать управление. Типа танк едет и уже можно добавлять/убирать физическую модель. Надо будет очень упрощенно сделать, когда до физики дойдут руки, а дальше уже усложнять по ходу дела.

@DrWeb7_1 В Create_Wheels смотри. Там функция EnableMotor задаёт скорость вращения (только не знаю, какую, об/мин или м/сек). Там ещё проблема такая с вылетами не известно из-за чего. Возьми танк и потряси его, получишь ассерт из недр ньютона.

@mixailwot Чего-то тут подумал, это мне надо делать что-то будет в итоге. А так могу месяц другим заниматься, а потом вернуться к незавершённому. Всё-равно сейчас физика не в приоритете. И да, у меня не клиент, а сервер. Чтобы тестировать физику, это надо каждый раз запускать сервер, перелогиниваться в клиенте (потому что будет дисконнект). Сам как раз использую demosSandbox, чтобы сразу видеть результат. Для тестирования загрузки карт так же сервер не подходит, пришлось Irrlicht использовать в качестве вьювера и отдельно выносить всё, чтобы результат видеть сразу же. То есть, чтобы даже картошкин клиент не запускать.

@mixailwot А так чем не нравится?

@mixailwot Так физики-то нет совсем. Вообще нет. Что оценивать? Для начала надо скачать тут. Потом сделать, чтобы условная модель танка ездила как танк. Версия 4.0 появилась. У меня 3.14, её надо использовать.

У меня был даже пример скинут в Newton Dynamics System, как сам пытался делать, да не получается ничего просто. Скачиваешь движок, открываешь примеры, там есть вьювер, добавляешь новый или стираешь один из существующих и делаешь. @mixailwot Вот файл могу скинуть, если лень по теме искать мой пост. Даже комментарии удалять там не буду. В закомментированном видно, что и движение делать пытался, флаги как в клиенте (MOVEMENT_FLAGS_ROTATE_LEFT, MOVEMENT_FLAGS_ROTATE_RIGHT и другие). В незакомментированном ещё раз пробовал уже не рейкастом, а физическими объектами моделировать. Там даже координаты для колёс есть. 1.7z

Делаю для версии 0.9.22. Это последняя версия перед 1.0. Если ты потроллить так хочешь, то очень не удачно. Никак. Да это и не нужно. Нужен готовый алгоритм, апи какое-то, которому закинул массив байт, а ответом будет либо ОК, либо какое-то сообщение, например, ждать следующего пакета. С наскока ничего не выйдет. Разобраться надо сначала. Вот ты файл открыл. А функцию, которая начинает обработку сообщения нашёл? С неё и надо начинать. Не, серьёзно. Если хочешь помочь - ОК. Но если можешь. А если мне надо всё объяснять перед этим, то в таком случае такая помощь не уместна. PacketReceiver::processFilteredPacket - отсюда начинается разбор пришедшего и дешифрованного массива байт. В начале всё просто и понятно. Что-то можно пропустить, например, сбор статистики. А вот ниже уже не так всё однозначно. Сразу попадается флаг, а флаги - одно из неоднозначностей. Packet::FLAG_CREATE_CHANNEL как бы и не приходит ни от сервера, ни от клиента. Это вроде бы, для внутреннего использования между серверами внутри кластера. Вот если таким образом опишешь сетевой протокол, даже на тот момент (2012 год) существующий, уже будет норм. Подтвеждение доставки, обработка пакета с номером больше, чем ожидается, запрос не пришедшего пакета и так далее. Если нет - ну, жди, когда мне будет не лень. Мне вот, наконец-то, удалось найти нормальную библиотеку для работы с таймерами. Эта штука называется "Wheel Timer" оказывается. На первый взгляд подходит. И производительность норм, сделал тест на 10к таймеров, не захлёбывается, мне с лихвой такого количества хватит. Теперь дальше сетевым протоколом заняться.

Пссс, пссс, слышите меня? Только шопотом отвечайте. В общем, качаете бигворлд 2 (например, тут). Открываете файл bw2\src\lib\network\packet_receiver.cpp. Переписываете его, чтобы от бигворлда не осталось ничего. В качестве входных данных будет дешифрованный пакет. Выход должен быть какой-то массив отдельных пакетов. Если надо в качестве примера входных данных, отсыплю сколько надо. Нужно: 1. Парсер пакетов. 2. Сборка пакетов, если размер пакета больше mtu, или ожидание, если вдруг приходят не по порядку. 3. Таймауты. Повторная отправка или повторный запрос в случае отсутствия пакета либо отсутствия подтверждения доставки. 4. Сборка пакетов из отдельных сообщений. Это то, что сейчас вспомнил. Можно на сишке, можно на c++17 или 19, или что там новомодное, плевать, соберу в dll отдельную, как с физикой. Всё, теперь можно не шопотом. Кхм. Ну блин, ну делаю, как могу. Энтузиазм уходит, когда долго нет прогресса. Самому хочется запустить уже нормальный локальный сервер и просто аутировать на старых картах, втыкая в дерево или камень. Ну вот так вот выходит пока что. Кстати, физику может кто-то запилить, если есть желание. Да и xmpp сервер сделать и плагин для него написать для картошкиного протокола. Есть для желающих, чем заняться. Уж очень хреновый клиент этих версий. Ради графики запускать его? Всё-равно поведение танков зависить будет от сервера.

А ещё есть отличия, что не удивительно, исходники года 12 что-ли. Некий флаг появился в пакете, 1 << 12. И никак не пойму, что он делает и для чего нужен. И это шлёт клиент. Нужен - не нужен, а кто его знает?

Ты просто посмотри, что надо сделать. Загляни в исходники бигворлда 2.01, файл bw2\src\lib\network\packet_receiver.cpp. Сетевая часть, которую надо хоть частично повторить. Как только вижу эту простыню кода, в которой надо разобраться, меня охватывает уныние и отчаяние.

Если адаптировать под старые версии. Игра-то полностью серверная. Изменяются, добавляются или удаляются энтити, функции, их параметры. Даже базовые методы могут измениться. Поэтому, нужно будет смотреть отличия и, при необходимости, адаптировать к нужной версии. Но нужно ли это? Зачем? Чем эта версия не устроит? Из-за пары-тройки выведеных в прошлых версиях танков? Или из-за выведенных карт? Да будет. Надеюсь. Только когда - не знаю. Ибо мне опять лень.

@Plotnik5252ru Добровольцев в чём? В программировании? Уже писал об этом, что нет тут тех, кто может сделать то, что мне нужно, а кто может - тут не сидит. Когда с картами разбирался, мне Скептический_Лис помог очень сильно. В остальном, просто нет никого знающего. Если вдруг столкнусь с чем-то, кто знает, как решить, подозреваю, что подскажут. Остальное приходится самому делать.

https://ru.wikipedia.org/wiki/Эмулятор_сервера Тут небольшая путаница в терминологии. Одно слово, но в другом значении. Так-то именно это и делаю.

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

Да. Сейчас пытаюсь с сетевой частью что-то сделать, чтобы можно было запускать без промежуточного звена (сейчас клиент игры - прокси для клиента - эмулятор). Попытаюсь сделать, чтобы более-менее нормально работало. Всякие прослойки в виде libevent хороши для TCP, но для UDP не годятся, являясь лишним звеном, которое можно заменить банальным вызовом recvfrom. А вот дальше как, уже не знаю. Наверное, надо делать по принципу "лишь бы работало". Нужен уже нормальный сервер авторизации, который хочу совместить с эмулятором (сейчас его роль выполняет прокси-клиент). Сразу же всплывает проблема сохранения состояния между loginapp и baseapp в терминах бигворлда, сейчас-то всё напрямую прописано, а тут надо базу данных делать. Тут же всплывает проблема синхронизации, потому что один поток должен принимать трафик, а другие потоки уже обрабатывать его. Ну и так далее. Именно так. Запустить ангар и покрутить вафлю? Просто внешне-то почти и нет ничего, всё скрыто внутри, а это мало кому интересно, что да как там работает, главное - конечный результат, картинка или что-то иное, которого на данный момент нет.

Но зачем передавать эту информацию? Что синхронизировать? Странно как-то. Синхронизируются координаты, но ни как не полигоны физической модели. Даже больше. На клиенте и сервере разные физические модели. Хотя внешне похожи, чтобы рассинхрона не было.

Нет, мне опять лень делать. @anomal3 У меня даже подобная картинка прикреплена была. Только речь была об статике, а не динамике. Это где? Почему такое ограничение? Этот тип коллизии называется convex hull или выпуклая оболочка. Для динамических физических объектов. Для статичных объектов это не так, можно использовать все полигоны видимой модели в физической. И речь в моём посте шла именно об этом. А при переходе к 1.0, видимо, сделано было упрощение в автоматическом режиме, а не ручное с реальной 3d модели, иначе такой вещи не было бы вовсе. Сэкономить решили, видимо.

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

@Plotnik5252ru Нет, это не моё. @DrWeb7_1 Там и 192.168.99.136, и localhost. Может из-за этого?

Пакет 61 вроде клиент отправляет. А после него ошибка. Посмотри повыше ошибочного пакета, из-за чего возникает такое. Заканчивать на сегодня надо. Сейчас итоги подведу. Итак, первое. Для чата в ангаре xmpp не нужен. Всё прекрасно работает и без него. Упс, называется. Бывает. Второе. Но всё общение завязано на xmpp, только через сервер это идёт (частично). Явно не сервер следит за отправкой и приёмом сообщений, а связан через xmpp. И третье. Где-то надо включить чат.

@DrWeb7_1 Предпоследний пакет - unknown packet

@DrWeb7_1 Не надо. Просто посмотри, что там. Если ты шифрование отключил, то там будет текст. А если не отключил, то надо будет найти, где это сделать.

Кто-нибудь подскажет, как из cPickle, в котором закодирован utf8, вывести читаемый текст? @DrWeb7_1 Возможно, клиент отправляет своё сообщение с неймспейсом 'http://wargaming.net/xmpp#filter-roster' например и ждёт ответ, а сервер не знает, что это такое и отправляет ошибку. Запусти сниффер.