Добавить простенькую PKI, чтобы сервер подписывал сертификаты клиентов, и MITM более не получится. Бороться с инжектами научились достаточно эффективно, хотя это как раз самое слабое звено, которое, в конце концов, по-любому получится обойти.
Есть режим кооперативной игры, где пунктиром видно, каких юнитов выделил твой союзник (чтобы вы не мешали друг другу). Учитывая особенности протокола (см. коммент выше), все клиенты должны получать идентичную информацию. Поэтому просто всё это транслируется всем.
Сервер участвует только во время создания игры и присоединения к ней. Он доставляет карту клиентам, у которых её нет, проверяет совпадение версий у всех и т.д. Когда начинается игра, сервер уже не нужен. Все клиенты соединяются каждый с каждым.
В игре есть единое игровое время. Оно условное, считается в тиках. У каждого тика есть свой номер. Логика игры обсчитывается на каждом клиенте индивидуально и полностью детерминированно. Единица обмена информации — действия игрока за 1 тик. Каждый клиент принимает команды игрока, формирует из них пакет и раз в тик отправляет всем остальным компьютерам. Если действий не было, то всё равно посылается пустой пакет с номером тика. Пока все клиенты не передадут свои действия за тик, обсчёт тика не начинается. Как только клиент получил от всех других клиентов данные по тику, он его обсчитывает. Поскольку всем передаются идентичные данные, и логика обсчёта детерминированная, рассинхронизации не происходит.
По этой причине, если например потюнить себе редактором памяти деньги, то другие клиенты об этом не узнают, и при попытке построить какое-то здание, у вас оно построится, а на других клиентах будет отказ. Состояние мира рассинхронизируется, и игра через небольшое время вылетит.
Пакет действий игрока состоит из элементарных команд: выделен юнит, записана группа, выделена группа, нажата правая кнопка мыши для перемещения, выбрано здание, выбрано место для здания и т.д. Команды очень короткие, из-за чего у игры очень скромные требования к интернет-каналу.
Сниффер мониторит сеть, ловит пакеты старкрафта, выкидывает действия самого хакера (чтобы не засорять экран лишней информацией) и выводит текстовый лог со всеми действиями других игроков. Элементарно выяснить, по какому пути развития идёт враг, понять, с какой стороны в какой момент ждать атаку и адекватно отреагировать.
Есть ещё Tk-версия сниффера. Там визуально на карте отмечаются действия разных противников разными цветами. И ещё была идея сделать голосовое оповещение о действиях противника, чтобы не отвлекаться на соседний монитор.
Вот именно. Какой-нибудь асимметричный протокол шифрования, чтобы перехватом не ломали, и мониторинг клиента на предмет внедрения. Близзард ничего такого не сделал.
Я в своё время исследовал протоколы Starcraft и Broodwar. Пассивным сниффингом сети видно всё, что делают противники. Они только выбирают место для постройки здания, а я уже вижу, что за здание они выбрали. Естественно, никакими античитерскими программами такой хак выявить невозможно. Одним глазом глянул на Warcraft3 — на вид там аналогичный протокол. Если интересно, могу рассказать.
Вы зря так категорично. Нужно понимать уместность каждого подхода в программировании. Отделение имеет смысл, когда предполагается взаимозаменяемость компонентов. Излишняя универсальность — неоправданное усложнение программы со всеми вытекающими.
Я чем больше живу, тем больше поражаюсь, сколько невостребованных возможностей есть у граждан. Это и использование механизма связей, и интерфейсы гражданско-государственного взаимодействия, и возможности общественных движений. А чем больше появляется высокопоставленных знакомых, тем больше убеждаюсь, что они отнюдь не всемогущи. Реальная сила — это народ. Чиновникам не пофиг на недовольство граждан — они точно так же получат по шапке от своих начальников. Видеоролики, статьи, митинги — это всё работает. И чем больше их будет, тем лучше для страны.
Кстати. в учительской среде нытья тоже хватает. Раньше ныли, что программу безбожно сжимают по времени. Теперь, что гадкий ЕГЭ убивает остатки советского образования. Там весьма негативно настроенное коммьюнити.
Зарабатываете вы, видимо, не этим. Если бы вы тратили на разработку этих программ все рабочее время, откуда бы вы брали деньги? Напомню, что ни SaaS, ни консалтинг в музыке невозможны.
В этом случае у производителя (автора) модели брюк будет простой выбор — или менять бизнес-модель (на какую?), или всеми силами запрещать копировать то, на разработку чего они потратили время и деньги.
Всё проще. «От каждого по способностям» не работает. Когда есть возможность схалявить, люди халявят. Аналогично, когда можно не заплатить, они не платят.
Делая онлайн-игры (фактически, оказывая такие же культурно-развлекательные услуги), который раз убеждаюсь, что сколь бы лояльна ни была аудитория, чтобы она начала платить, нужно её заставлять. На добровольности денег не заработаешь — медицинский факт.
Ну заплатят 100 фанатов по 200 рублей. Это что — деньги?
По своему опыту скажу. Самые типичные проблемы в протоколах:
1. некорректно описанное поведение при нештатных ситуациях (ошибки при отправке данных платежа на сервер продавца) — как должен повторяться сбойный платёж, как на него должен отвечать магазин, что делать при повторном получении ошибочного запроса.
2. проблемы со спецификацией информации об ошибках обработки — иногда дают фиксированный список «кодов ошибок», который неприменим для конкретной задачи, иногда вообще не предоставляют нормальной возможности для того, чтобы сообщить о какой-то нестандартной ситуации типа «персонаж ABC в тюрьме».
3. неоправданное переусложнение протокола — где можно просто передать параметры к запросу через RESTful-интерфейс или просто параметрами в POST, устраивают SOAP поверх HTTP, а в параметры методов SOAP ещё вкручивают маленькие XML-документики.
Сервер участвует только во время создания игры и присоединения к ней. Он доставляет карту клиентам, у которых её нет, проверяет совпадение версий у всех и т.д. Когда начинается игра, сервер уже не нужен. Все клиенты соединяются каждый с каждым.
В игре есть единое игровое время. Оно условное, считается в тиках. У каждого тика есть свой номер. Логика игры обсчитывается на каждом клиенте индивидуально и полностью детерминированно. Единица обмена информации — действия игрока за 1 тик. Каждый клиент принимает команды игрока, формирует из них пакет и раз в тик отправляет всем остальным компьютерам. Если действий не было, то всё равно посылается пустой пакет с номером тика. Пока все клиенты не передадут свои действия за тик, обсчёт тика не начинается. Как только клиент получил от всех других клиентов данные по тику, он его обсчитывает. Поскольку всем передаются идентичные данные, и логика обсчёта детерминированная, рассинхронизации не происходит.
По этой причине, если например потюнить себе редактором памяти деньги, то другие клиенты об этом не узнают, и при попытке построить какое-то здание, у вас оно построится, а на других клиентах будет отказ. Состояние мира рассинхронизируется, и игра через небольшое время вылетит.
Пакет действий игрока состоит из элементарных команд: выделен юнит, записана группа, выделена группа, нажата правая кнопка мыши для перемещения, выбрано здание, выбрано место для здания и т.д. Команды очень короткие, из-за чего у игры очень скромные требования к интернет-каналу.
Сниффер мониторит сеть, ловит пакеты старкрафта, выкидывает действия самого хакера (чтобы не засорять экран лишней информацией) и выводит текстовый лог со всеми действиями других игроков. Элементарно выяснить, по какому пути развития идёт враг, понять, с какой стороны в какой момент ждать атаку и адекватно отреагировать.
Есть ещё Tk-версия сниффера. Там визуально на карте отмечаются действия разных противников разными цветами. И ещё была идея сделать голосовое оповещение о действиях противника, чтобы не отвлекаться на соседний монитор.
Делая онлайн-игры (фактически, оказывая такие же культурно-развлекательные услуги), который раз убеждаюсь, что сколь бы лояльна ни была аудитория, чтобы она начала платить, нужно её заставлять. На добровольности денег не заработаешь — медицинский факт.
Ну заплатят 100 фанатов по 200 рублей. Это что — деньги?
1. некорректно описанное поведение при нештатных ситуациях (ошибки при отправке данных платежа на сервер продавца) — как должен повторяться сбойный платёж, как на него должен отвечать магазин, что делать при повторном получении ошибочного запроса.
2. проблемы со спецификацией информации об ошибках обработки — иногда дают фиксированный список «кодов ошибок», который неприменим для конкретной задачи, иногда вообще не предоставляют нормальной возможности для того, чтобы сообщить о какой-то нестандартной ситуации типа «персонаж ABC в тюрьме».
3. неоправданное переусложнение протокола — где можно просто передать параметры к запросу через RESTful-интерфейс или просто параметрами в POST, устраивают SOAP поверх HTTP, а в параметры методов SOAP ещё вкручивают маленькие XML-документики.