Ещё один подводный камень связан с обработкой ошибок. Если скрипт, который принимает аплоад, упадёт с ошибкой, то скрипт формы об этом не узнает. Решается перехватом всех-всех-всех исключений в обработчике аплоада на сервере, и в случае проблем возвращает 200 OK с сообщением об ошибке.
Собственно, статья совершенно правильно описывает то, как оно происходит и в старкрафте.
От игроков передаются их действия: выделил здание, нажал «строить танк», выделил группу N, кликнул правой кнопкой в такие-то координаты и т.д. По сути, даже если действие не удалось (нет денег на постройку танка), команда всё равно проходит.
Нет доверия к серверу. Если хакер контролирует сервер, он себе сможет денег дорисовать. Если сервер делать на мощностях оператора игры, это слишком дорого выйдет.
Такие программы называются мэпхаки. Патчат клиент и отключают туман войны. Есть противоядие. Когда проводят турниры, старкрафт запускают из-под монитора, который прочёсывает память игры и контрольные суммы считает. Монитор потом отчитывается, что клиент чист. Игрок без монитора не допускается до соревнований.
Как раз чтобы обойти защиту, я отреверсил протокол старкрафта и с соседнего компьютера сниффил трафик. По сути, как раз и убирал туман войны.
В старкрафте задержка между действием пользователя и тиком, в котором его планируется обработать, называется Latency и настраивается в опциях. Все машинки во время сетевой игры связаны каждая с каждой, и каждая каждой отправляет действия игрока за текущий тик. Если действий не было, всё равно отправляется пустой кадр. И пока каждая машина не получит от всех остальных кадры действий, к обсчёту тика она не приступает.
> Время проходит со скоростью одну секунду за секунду для всех наблюдателей.
По-моему, должно быть как раз наоборот — время НЕ проходит со скоростью 1 секунда в секунду для всех наблюдателей. Время идёт по-разному в разных системах отсчёта.
Мы тоже так тестируем браузерку. Игрокам вообще ничего платить не приходится — для них узнать о будущих нововведениях раньше остальных, получить возможность нахаляву потестировать разные комбинации шмоток — это само по себе вознаграждение.
Я не юрист, но имею некоторый судебный опыт, правда гражданско-правовых дел, не уголовных. Практика такова, что к судьям никто не подкатывает с мздой. В любом случае, есть апелляции, и судья верхнего уровня легко отменит несправедливое решение нижнего судьи.
Взятки начинаются в тот момент, когда к делу привлекается специалист или эксперт, получающий взятку от одной из сторон. Исследование или заключение эксперта подшивается к материалам дела, и потом вымарать глупости, которые эксперт под присягой расскажет суду, это убийственно сложное дело.
Обычно с инициативой о назначении экспертизы ходатайствует взяткодатель. И тут же в ходатайстве пишут, что указанную экспертизу может произвести ООО «Рога и копыта», лицензия № бла-бла, имеющее опыт проведения таких экспертиз. Судья спрашивает жертву, нет ли у неё возражений против выбора организации. Жертва никаких доказательств афиллированности взяткодателя и эксперта предъявить не может, поэтому не возражает. Эксперт пишет то, за что ему заплатили, и бинго — судья принимает единственно возможное решение.
Вообще да, перемудрили однозначно. Я поэтому и предостерегаю читателей, чтобы по нашим граблям не пошли. Ничего тяжёлого, никакого доступа к нагруженной БД там быть не должно.
У нас вся передача предметов, расчёт характеристик персонажей перед боем (а это тоже загрузка инвентаря, характеристик предметов), появление на локации растений, их удаление, перемещение персонажей, включая рассылку остальным клиентам информации о перемещениях — всё это легло на sync. По поводу «не тянет» я неправильно выразился. Тянуть оно тянет и 1000 — и наверное и выше сможет. Проблема в том, что задержка в 2-3 секунды у одного игрока автоматически блокирует всех остальных игроков на 2-3 секунды. А чем больше игроков, тем чаще эти провисания случаются. И это системный недостаток архитектуры. Железо нормальное — Xeon 3.2 ГГц.
Мы в нашей игре используем точно такой же подход. Все операции, для которых строго важна очерёдность, выполняем на едином однопоточном сервере, который назвали sync (сервер для синхронных действий). Надо понимать, что, построив такую архитектуру, мы навсегда гарантированно избавились от гонок, но, с другой стороны, ввели в систему узкое место — теперь если какой-то запрос выполняется с задержкой, то эту задержку испытывают ВСЕ игроки, которые в то же время что-то хотят от игры. Субъективное ощущение у игроков — что игра тормозит.
Теперь о том, как это получилось. После того, как был сделан прототип архитектуры, синтетические тесты показывали отличные результаты — десяток тысяч пользователей на одном шарде — как нечего делать. Но дело в том, что в онлайн-игре синхронизации потребовало огромное количество самых различных действий. Например, один персонаж нападает на другого, а последний успел в последний момент слинять в соседнюю локацию. Система должна обеспечить жёсткую синхронизацию этих действий — либо успел уйти, либо начался бой. И никак иначе. Другая ситуация — игрок A видит, что игрок B ходит голый и решает его побить. В момент нападения A внезапно одевается. И должна быть чёткая последовательность — либо A успел одеться, либо в бою у него низкие характеристики, и никак иначе. Потом ситуация с ограблением — если один персонаж нападает на другого с целью ограбить, а последний прямо перед боем покупал что-то в магазине. Должна быть соблюдена чёткая очерёдность — либо деньги успели списаться со счёта, товары попасть в инвентарь, и ограбление удалось, либо торговля не успела пройти и грабитель остался без добычи. Ну и т.д.
Количество различных действий, которые требуют синхронизации, росло в таких немыслимых количествах, что наш sync начал захлёбываться под нагрузкой. И в реальности на онлайне 300 сервер начинает адски тормозить. Точнее работает, но на любой затормозившей операции (транзакции по передаче большого количества предметов, например) сервер блокирует игру на несколько секунд.
Сейчас приходится разбирать этого монстра обратно — отпиливать все тяжёлые операции, выносить их на фронтенды. Фронтенды синхронизируем мьютексами на memcached. И хотя в систему вносится потенциальная возможность гонок (в редких случаях), успешному оперированию игры это не мешает.
В общем, архитектура жизнеспособная, но очень важно, чтобы синхронные операции были крайне лёгкими, а при расширении мира можно было этот сервер горизонтально отмасштабировать, перебросив на него часть нагрузки. Возможно, для этого придётся мир разделить на условные зоны, между которыми персонажи взаимодействовать не могут.
От игроков передаются их действия: выделил здание, нажал «строить танк», выделил группу N, кликнул правой кнопкой в такие-то координаты и т.д. По сути, даже если действие не удалось (нет денег на постройку танка), команда всё равно проходит.
Как раз чтобы обойти защиту, я отреверсил протокол старкрафта и с соседнего компьютера сниффил трафик. По сути, как раз и убирал туман войны.
По-моему, должно быть как раз наоборот — время НЕ проходит со скоростью 1 секунда в секунду для всех наблюдателей. Время идёт по-разному в разных системах отсчёта.
Взятки начинаются в тот момент, когда к делу привлекается специалист или эксперт, получающий взятку от одной из сторон. Исследование или заключение эксперта подшивается к материалам дела, и потом вымарать глупости, которые эксперт под присягой расскажет суду, это убийственно сложное дело.
Обычно с инициативой о назначении экспертизы ходатайствует взяткодатель. И тут же в ходатайстве пишут, что указанную экспертизу может произвести ООО «Рога и копыта», лицензия № бла-бла, имеющее опыт проведения таких экспертиз. Судья спрашивает жертву, нет ли у неё возражений против выбора организации. Жертва никаких доказательств афиллированности взяткодателя и эксперта предъявить не может, поэтому не возражает. Эксперт пишет то, за что ему заплатили, и бинго — судья принимает единственно возможное решение.
Теперь о том, как это получилось. После того, как был сделан прототип архитектуры, синтетические тесты показывали отличные результаты — десяток тысяч пользователей на одном шарде — как нечего делать. Но дело в том, что в онлайн-игре синхронизации потребовало огромное количество самых различных действий. Например, один персонаж нападает на другого, а последний успел в последний момент слинять в соседнюю локацию. Система должна обеспечить жёсткую синхронизацию этих действий — либо успел уйти, либо начался бой. И никак иначе. Другая ситуация — игрок A видит, что игрок B ходит голый и решает его побить. В момент нападения A внезапно одевается. И должна быть чёткая последовательность — либо A успел одеться, либо в бою у него низкие характеристики, и никак иначе. Потом ситуация с ограблением — если один персонаж нападает на другого с целью ограбить, а последний прямо перед боем покупал что-то в магазине. Должна быть соблюдена чёткая очерёдность — либо деньги успели списаться со счёта, товары попасть в инвентарь, и ограбление удалось, либо торговля не успела пройти и грабитель остался без добычи. Ну и т.д.
Количество различных действий, которые требуют синхронизации, росло в таких немыслимых количествах, что наш sync начал захлёбываться под нагрузкой. И в реальности на онлайне 300 сервер начинает адски тормозить. Точнее работает, но на любой затормозившей операции (транзакции по передаче большого количества предметов, например) сервер блокирует игру на несколько секунд.
Сейчас приходится разбирать этого монстра обратно — отпиливать все тяжёлые операции, выносить их на фронтенды. Фронтенды синхронизируем мьютексами на memcached. И хотя в систему вносится потенциальная возможность гонок (в редких случаях), успешному оперированию игры это не мешает.
В общем, архитектура жизнеспособная, но очень важно, чтобы синхронные операции были крайне лёгкими, а при расширении мира можно было этот сервер горизонтально отмасштабировать, перебросив на него часть нагрузки. Возможно, для этого придётся мир разделить на условные зоны, между которыми персонажи взаимодействовать не могут.