Кушаем у мистера Джо

Realtime Web №3 - TornadIO2

Thu, 24 Nov 2011 18:28:51 -0500

Написал мини-статью для Хабра о новой TornadIO2 с поддержкой самых новых с свежих версий socket.io.

Смотреть тут.

Почему питон кушает много памяти

Sun, 20 Feb 2011 05:44:00 -0500

Короткая заметка о том, почему python любит память. Я, возможно, покажусь Капитаном Очевидностью, но все же.

Вот возьмем такой рафинированый пример:

class A(object):
    def __init__(self, i):
        self.j = i

x = [A(i) for i in xrange(1000000)]

input()

Запустим его на 32 битной системе (с 32 битным питоном) и увидим что он кушает, примерно, 190 МБ памяти.

Как-то много для массива из миллиона указателей на объекты размером в 4 байта.

Теперь берем 64 битную систему и проверяем сколько скушает данный пример. У piranha получилось 384 МБ - в примерно два раза больше чем у меня.

Упс.

А теперь попытаемся разобраться чем же это все может быть вызвано.

Мне было совсем лениво заниматься тестами памяти, тем более что кто-то это уже сделал - http://www.valuedlessons.com/2008/10/blog-post.html

Посмотрим на табличку. new-style class = 336, int = 24. (336+24)*1000000 = 360,000,000 или ~351 МБ. Из количества используемой памяти можно сделать вывод, что тесты проводились на 64-битной системе. Остальное можно списать на стандартные либы, системные либы в процессе питона и так далее.

Откуда столько памяти на один int? Вспоминаем что питон работает с объектами. Имена переменных это просто ссылки на объекты. Кроме того, сборщик мусора работает на подсчете ссылок, так что каждый объект должен хранить количество ссылок на себя.

Вот и получается - поскольку все на указателях, то при переходе на архитектуру с вдвое большим размером оных, использование памяти в питоне увеличивается почти в два раза. Да и без перехода получается ерунда - 24 байта на значение в 4 байта это тоже overkill.

Так что, если у вас памяти не очень много (VPS, etc) - однозначно использовать 32 битный питон. Если памяти много (больше 3 ГБ), то тогда прийдется использовать 64 битный, так как PAE еще и притормаживает.

Такие вот пироги с котятами.

greenlet/gevent

Wed, 09 Feb 2011 05:45:00 -0500

Тут будет немного сумбурных мыслей по поводу greenlet’ов в контексте gevent.

Гринлеты это хак

Немного пояснений о том как же работают гринлеты и к чему это все может привести.

В питоне весь стек - unmanaged. Это означает, что используется “обычный” стек, который предоставляет операционная система вместе со своим менеджментом стековой памяти (дополнительное выделение страниц под стек если нужно еще и так далее). В этом самом unmanaged стеке хранятся всякие локальные переменные питоновского интерпретатора, локальные переменные сишных модулей и тому подобное. Такая вот солянка из всего сразу.

Поскольку питон - интерпретируемый язык и если бы у него был управляемый стек (стек програмы на питоне был бы реализован сам интерпретатором), то greenlet’ы делаются элементарно - заводим два стека и все.

А поскольку стек как раз не управляется питоном, то greenlet начинает шаманить с системным стеком. А именно:

1. При переключении гринлетов (из А в Б) вычисляет размер использованого стека относительно вышестоящего стек-фрейма
2. Копирует данную область из стека в кучу (делая malloc/realloc)
3. Переписывает данные из кучи в стек для гринлета Б
4. Патчит регистры процессора, что бы указатель стека был на правильном месте
5. Освобождает память в куче для гринлета Б (free)
6. Патчит PyThreadState (переменные recursion_depth, top_frame) что бы питон не сломался
7. Возвращает управление в интерпретатор питона

И того, на одно переключение гринлета происходит 2 memcpy, возможно один realloc и один free. Зачем free? Потому что при алгоритмах с рекурсией размер стека может быть большим. Например - 50 КБ. Соответственно если после переключения оставлять копию стека в куче - получим 2х кратное увеличение использования памяти.

Какие общие проблемы у такого подхода:

1. Проблемы со сборкой мусора

Из официальных док: Greenlets do not participate in garbage collection; cycles involving data that is present in a greenlet’s frames will not be detected. Storing references to other greenlets cyclically may lead to leaks.

Что означает - любые переменные которые были выгружены гринлетами в кучу из стека не будут принимать участия в сборке. А поскольку у питона обычный reference count, то и все объекты на которые они ссылаются тоже подчищены не будут.

Так что прийдется очень внимательно писать код, а то потом прийдется ловить ошибки на продакшене.

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

3. Магия для интерпретатора

PyThreadState это как бы внутренняя структура питона, которая используется для определения текущего состояния интерпретатора в текущем потоке. В ней хранится текущий уровень рекурсии, ссылка на текущий фрейм, текущее исключение (если есть) и т.д.

Гринлеты занимаются магией и влезают в стек. Если произойдет исключение будет очень трудно посмотреть реальный стек-трейс.

Если произойдет исключение в гринлете, оно передается на вышестоящий гринлет. Если произошло еще одно исключение в вышестоящем гринлете, то исходное исключение потеряется. А все потому, что питон работает категориями потоков (PyThreadState на поток), а у нас кучка виртуальных потоков в одном реальном. К слову, из одного гринлета можно читать исключение которое произошло в другом гринлете.

Реальный размер используемого системного стека может быть значительно больше чем значение PyThreadState.recursion_depth - при слоеном пироге из фреймов разных гринлетов. Чем грозит - не знаю, памяти сейчас много, но может себя вести странно на “нестандартных” (не х86) архитектурах.

К слову, текущая интеграция для x64 нарушает конвенции вызовов функций (ABI) - не сохраняет все нужные регистры при переключении гринлетов. Так что я бы не советовал их использовать на х64 - можно словить кучу ошибок.

Вот тут еще есть немного: http://code.google.com/p/coev/wiki/GreenletProblems

Ну а теперь о хорошем.

Мне нравится концепция асинхронного программирования без callback’ов. Код становится сильно проще и красивее.

gevent, в целом - симпатичный. Ну да, нужно патчить все что можно, что бы библиотека питона стала асинхронной. Некрасиво, но других вариантов нет.

Например взять ту же SQLAlchemy - ее заставили работать асинхронно под gevent. Ага, monkey patching, но какие есть альтернативы, учитывая что это самая вменяемая ORM и она, к сожалению, не умеет работать асинхронно из коробки?

Что плохо - основа на которой написан gevent меня пугает, поскольку мне страшно ставить ее на высоконагруженный продакшн. Слишком много магии - очень плохо. Хотя вроде spotify что-то там писал на gevent, может библиотека уже production ready.

Ну а какие есть альтернативы?

Торнадо, да. Но появляется требование работы с базой данных и привет. Без баз данных - магии нет, код проще, но callback’и.

Такие вот дела.

Realtime Web №2 - TornadIO

Thu, 27 Jan 2011 15:48:00 -0500

В продолжение предыдущего поста про Web реального времени: socket.io oказался хорошим, а вот существующая серверная поддержка для питона под названием SocketTornad.IO - не очень. Кроме кучки существующих багов, похоже что проект умер. Да и внутри там еще та каша.

И в результате - приветствуем TornadIO. TornadIO - Comet библиотека для организации постоянной связи между браузером и сервером для быстрой передачи сообщений туда и обратно.

По сути, переписал заново SocketTornad.IO, исправил ошибки, добавил всяких вкусностей и так далее. Вот сегодня его добавили на главную страницу socket.io, чему я рад.

Под катом - немного информации что это такое и с чем это едят.

Socket.io - это клиентская библиотка, которая предоставляет единый интерфейс для связи с comet сервером используя один из поддерживаемых протоколов.

Протоколы поддерживаются такие:

1. Websocket
2. Flashsocket
3. XHR multipart
4. XHR polling
5. JSONp
6. HTMLFile (IE only)

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

Немного о каждом протоколе:

1. Websocket

- Обычные websocket’ы из коробки.
- Открывается одно соединение на прием и отправку данных.
- Proxy поддерживаются

2. Flashsocket

- Эмуляция websocket’ов через специальный флешовый скрипт. Используется https://github.com/gimite/web-socket-js
- Одно соединение на прием и отправку данных
- Proxy не поддерживается

К слову - web-socket-js еще та петрушка, которую можно очень хорошо соптимизировать, чем обещают заняться разработчики socket.io.

3. XHR multipart

- Один долгоиграющий GET запрос на прием данных с сервера
- По POST запросу на отправку данных на сервер с клиента
- Proxy поддерживается

4. XHR polling

- Куча GET запросов, которые висят до 20 секунд если нет данных, для чтения данных с сервера
- По POST запросу на отправку данных на сервер с клиента

5. JSONp

- Аналогично XHR polling, но данные приходят с сервера как JS скрипт.

6. HTMLFile

- Хитрая штука, которая нечто среднее между XHR multipart и XHR polling и только для IE
- Одно соединение для приема данных
- По POST запросу на отправку данных

Теперь о TornadIO.

TornadIO - это библиотека для поддержки транспортов socket.io поверх торнадо. По сути, мимикрирует внешнее API websocket’ов (их поддержка в торнадо появилась достаточно давно), при этом поддерживает все транспортные протоколы socket.io.

По сути, пишем код 1 раз и пускай socket.io + TornadIO заботятся о транспортном уровне.

Как это выглядит с точки зрения кода. Напишем простой realtime чат.

Вот это наша серверная часть (инициализация опущена, только сама логика чата):

class ChatConnection(tornadio.SocketConnection):
    participants = set()

    def on_open(self, *args, **kwargs):
        # Register incoming connection
        self.participants.add(self)
        self.send("Welcome!")

    def on_message(self, message):
        # Broadcast incoming message
        for p in self.participants:
            p.send(message)

    def on_close(self):
        # Remove client
        self.participants.remove(self)

        # Broadcast that client left
        for p in self.participants:
            p.send("A user has left.")

Каждый клиент - это отдельный экземпляр класса ChatConnection. Появился новый клиент - мы его добавили в set, ушел - убрали. Прислал сообщение - разослали всем в чате.

Клиентская часть выглядит так: https://github.com/MrJoes/tornadio/blob/master/examples/chatroom/index.html

Все достаточно просто.

Взять библиотеку можно тут или на pypi.

Примеры можно посмотреть тут: https://github.com/MrJoes/tornadio/tree/master/examples

Надеюсь еще кому-то пригодится.

Realtime Web

Tue, 04 Jan 2011 16:56:00 -0500

Решил разобраться что и как у нас с realtime в современном Вебе.

Для примера возьмем какую-нибудь онлайн игру, для которой важны (в порядке важности):
1. Streaming данных с сервера в реальном времени (с минимальной задержкой)
2. Время отклика на действия игрока
3. Возможность работы через прокси

Пункт 3й желателен, но не обязателен.

Из средств будем использовать HTML, js, python, при этом не очень хочется использовать twisted. Желательно хотя бы tornado.

Какие есть варианты:

1. Long running AJAX

Что такое: делаем запрос на сервер, который ждет ответа неограниченно долго. После получения ответа делаем запрос еще раз. И так до бесконечности.

Существует в нескольких вариациях: с использованием XHR, с использованием скрытого фрейма и так далее.

Проблемы:
- Бьет по производительности, т.к. мы сами разрешили клиентам долбить наш веб сервер
- Время отклика сильно зависит от нагруженности веб морды
- Синхронные фреймворки использовать нельзя, а юзать асинхронные не сильно удобно. Вариант решения - nginx который будет распределять запросы по маске между 2 бекендами, один на той же Сварге, а второй на торнадо.
- Нельзя напрямую обращаться к серверу на другом порту/тазике из за ограничений AJAX на тему cross domain scripting.

Достоинства:
- Работает везде
- Поддержка проксей

2. Cometd, он же Bayeux Protocol

По сути, попытка “стандартизации” long polling request’ов. Может работать как в обычном long polling режиме, так и с извратом - открывается 2 соединения, где одно соединение используется для отсылки данных к серверу, а другое - для отсылки данных от сервера.

Описывать буду именно режим с двумя соединениями.

Проблемы:
- Для питона поддерживается только Cometd, который написан поверх Twisted
- Twisted :-)
- Протокол относительно сложный, да и синхронизировать 2 соединения в одно логическое не очень удобно

Достоинства:
- Время отклика сильно лучше

3. WebSockets

Попытка добавить сокеты к клиентскому JS. Открываем соединение с помощью HTTP протокола, сервер видит что это именно WebSocket и дальше его как-то обрабатывает.

Проблемы:
- Почти никто из браузеров не поддерживает
- Те кто поддерживают - отключили из за найденной дыры в протоколе
- Финальных спеков нет, 76 ревизий настораживают.
- Всякие там кеширующие прокси не умеют и не понимают (nginx, например). Есть HAProxy, но делать цепочку Client -> HAProxy -> nginx -> wsgi не очень хочется.

Достоинства:
- Сокеты в JS, ура!

Кстати, я так и не понял зачем было городить это все. Со времен появления SSL был такой HTTP метод как CONNECT. Его отлично понимали proxy, его легко можно прикрутить к веб серверу. Если нужно различать куда стучимся - используем custom header, делов то. Даже если будет срабатывать same origin policy для JS, то на всех существующих проксях (nginx например) легко можно будет заворачивать трафик куда надо по хидеру.

4. socketjs & co

Идея тоже весьма простая - делаем мелкий флешовый скрипт, который средствами флеша имитирует работу обычного tcp сокета. Работает везде где есть флеш.

Достоинства:
- Легко использовать
- Чистый tcp
- Быстрый
- Работает почти везде (найти юзера у которого нет флеша нынче тяжело)

Недостатки:
- Завязка на флеш
- Надо писать свой сетевой протокол, т.к. ничего готового нет.

5. js-amqp

Есть такая штука как AMQP (Advanved Messaging Queue Protocol) который позволяет создавать очереди сообщений. К сожалению, протокол overdesigned, т.е. его использовать не очень удобно, но production-ready решения есть, например RabbitMQ, ActiveMQ и т.д.

По сути, браузер коннектится к AMQP серверу и получает/отправляет собщения. Все круто, но использовать AMQP для передачи сообщений между клиентом и сервером это как палить из пушки по воробьям.

Недостатки:
- Сложный и неэффективный протокол (первоначальный автор спецификаций AMQP от него отказался и решил делать ZeroMQ)
- Большая половина функциональности использоваться не будет
- Интеграция js-amqp представляет собой флешовый скрипт с неким JS API.

Достоинства:
- Не заморачиваемся со своим сетевым протоколом
- Быстрее long polling ajax, медленнее сырых сокетов

6. Использовать Mongrel2 как фронтенд

Mongrel2 это такая штука, которая ловит входящие запросы (HTTP, TCP, etc) и конвертирует их в сообщения ZeroMQ. Подписчики на эти сообщения их обрабатывают и отправляют ответ обратно к Mongrel2, который уже отправляет их на клиент.

Достоинства:
- Получаем ZeroMQ из коробки (т.е. заодно и хорошую расширяемость на будущее)

Недостатки:
- Не решает вопроса с транспортом от браузера к серверу
- Слишком новая технология
- Нет никаких тестов
- Никто не писал об опыте использования

Это как бы все что я смог накопать.

Какие еще есть идеи:

- ZeroMQ

Отличная штука - сокеты на стероидах, с гарантированной доставкой в случае потери tcp соединения и так далее. Есть интеграции почти со всеми языками, включая node.js.

Но. Интеграция всегда завязана на Сишную либу, которая уже и занимается протоколом. Т.е. даже интеграция на Java тянет за собой сишную либу.

Нативных клиентов (например как для redis) нет вообще.

Подумываю написать клиент на жаваскрипте поверх socketjs, благо протокол там ну очень простой. Но это когда-нить потом.

Итог

Я вот даже не знаю на чем остановиться. Использовать Cometd не очень хочется, там страшный Twisted. Делать все на AMQP - overkill. Писать свой wire протокол поверх WebSockets/socketjs - не хочется, но чую прийдется.

P.S. Я нашел его! Смотреть тут: https://github.com/SocketTornadIO/SocketTornad.IO

Секреты рендеринга Starcraft 2: Ролики

Thu, 11 Nov 2010 03:40:23 -0500

Секреты рендеринга Starcraft 2: Ролики

Секреты рендеринга Starcraft 2

Wed, 03 Nov 2010 04:13:30 -0400

Секреты рендеринга Starcraft 2

Производительность .NET

Thu, 28 Oct 2010 15:59:00 -0400

Сейчас занимаюсь прототипированием MMO сервера на C#. Как будет что-то готовое, будет серия постов на тему его архитектуры.

А сейчас хочу рассказать насколько быстрое создание объектов в шарпе через new().

В свое время кодируя на С/С++ всегда считал (и продолжаю считать), что лишние создания объектов это зло. Точнее - и операция медленная и вообще плохо. Потому, ради производительности, делались такие штуки, как всякие там кеширующие фабрики: если объект уничтожается, он не прибивается, а добавляется в очередь фабрики. Если нам понадобился новый экземпляр такого объекта - мы смотрим чего там у нас закешировано и если ничего - то создаем новый.

Понятное дело, что был контроль длины очереди и тому подобное.

И решил я, значит, сделать похожий велосипед для шарпа - у меня создается куча мелких объектов в рантайме.

Написал и ужаснулся: мой вариант с очередью в 6 (!) раз медленнее обычного new(). При том, что мой был однопоточный, а new() работает и в многопоточном окружении. Если что, за основу брался код отсюда: http://www.codeproject.com/KB/recipes/ObjectPooling.aspx который я сильно почистил и оптимизировал.

Если что, объекты были действительно мелкие - по 12 байт каждый.

Вторая часть истории - у C# есть такой класс BitConverter. У него есть кучка статических методов, которые позволяют конвертировать базовые типы данных (int, etc) в/из массив байт. Проблема состоит в том, что прототип функций конвертации в массив примерно такой:

byte[] ToShort(int value)

Внутри оно делает new byte[4] и сериализирует в него value.

Явная проблема с производительностью? Да, я тоже подумал. И написал свой очередной велосипед.

И что вы думаете? Вот мои результаты в ms, для int, 10000000 итераций:

MyFromArray: 121.0107
BitConverterFromArray: 65.0044
MyToArray: 115.01
BitConverterToArray: 194.0111

Грубо говоря, мои функции вида:

short ReadShort(byte[] buf, int offset);

оказались примерно в 2 раза медленней аналогов из BitConverter из за дополнительных проверок “а не надо ли менять byte order” и из за того, что мои методы не статические.

А функции записи вида:

void Write(short value, byte[] buf, int offset);

оказались всего лишь на ~80% быстрее чем вариант в BitConverter с созданием нового объекта… Я ожидал разницы где-то в порядок, на самом деле.

Вот что получается - запись в массив 4х байт одной операцией (*(int*)&buf = value) всего лишь на 80% быстрее чем создание массива из 4х байт в куче и записью туда этих самых 4х байт той же операцией.

Так что будем считать что new() в .NET почти бесплатен.

Небольшой реверс инжиниринг Minecraft

Wed, 06 Oct 2010 01:26:00 -0400

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

Дальше немного о том, как Minecraft написан, как функционирует и соображения почему-же оно смогло так хорошо продаться.

Если кто не в курсе, Minecraft это такая себе игра, которая представляет собой Dwarf Fortress от лица рядового гнома. Можно крафтить вещи, копать ямы и отбиваться от монстров. Мир бесконечен - создается на лету. Физические ограничения - 65 тыс. квадратных километров.

Minecraft написан на Java с использованием http://lwjgl.org/ - некой платформо-зависимой прослойки, которая представляет собой что-то типа SDL, но для Java. Игра может работать как апплет в браузере или как standalone приложение. Разница только в точке входа.

Код игры обфусцирован, что бы усложнить жизнь читерам и им сочувствующим. Но это не сильно помогает - даже в мультиплеере сервер весьма мало чего контролирует. Т.е. игроки летают, прыгают, как хотят и тому подобное. Кроме того, есть известные баги, например в мультиплеере можно создавать дубликаты вещей.

Кода мало. Ну, реально, там несколько десятков классов, простой рендер, простая сетевая подсистема. Это в клиенте. В сервере итого меньше.

Взять тот же рендер - там все на кубиках построено. Земля рендерится через VBO, куда накидываются видимые грани кубиков. Никакого occlusion culling нет, да и не нужен он - там все квадратиками и в одном VBO до 15 тысяч полигонов. Никаких шейдеров, все на FFP.

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

Собственно я решил сделать себе радар с минералами для мультиплеера. Вариантов несколько:

1. Сделать injection своего Java класса и работать с игровыми данными
2. Сделать прослойку между opengl.dll и игрой и выключать z-test для нужной мне геометрии

С первым вариантом мне не хотелось возиться - копать обфусцированный Java код то еще удовольствие.

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

Ну заодно зафиксировал цвета в VBO, чем получил равномерное освещение везде.

Как бы пруф:

Ну и напоследок…

Посмотрев внутренности игры, однозначно прихожу к выводу, что идея решает. Главное совсем уж не подкачать с реализацией. Человек не сильно заморачивался с картинкой, кодом и просто взял интересную идею и начал обвешивать ее фичами. Я не могу сказать, что Minecraft хорошо написан, не могу сказать что Notch (собственно автор) мега-супер-программер. Просто человеку пришла в голову хорошая идея и он, как умел, ее реализовал. Я совершенно не могу сравнить количество труда затраченного на Minecraft с любой другой более крупной игрой. Народ тратит уйму денег, уйму усилий и совершенно не добивается того, что смог сделать один программист с хорошей идеей.

Так что congratulations Notch.

О том, как подкрадывается песец...

Tue, 29 Jun 2010 10:23:00 -0400

Есть у нас приложение, которое мы пишем на основе DotNetNuke (DNN). Причина почему выбрали DNN - настоял заказчик. Мол, DNN самый “взрослый”, “стабильный”, “корпоративный” и тому подобное.

Вот, на днях у нас упал продакшен. Хорошо так упал.

Начал исследовать причину, поковырялся - оказалось что падает вся ферма из веб серверов (их 3 штуки), если запускается операция создания сайта. DNN поддерживает несколько сайтов работающих в одной инсталляции DNN.

После исследования, получилась весьма интересная картина, которая касается внутренностей ASP.NET, а так же архитектурных решений DNN.

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

Кроме того, в ASP.NET есть кеш. Кеш это key/value storage, который локален для процесса ASP.NET. Операции стандартные - добавить, получить, удалить и т.д. Есть expiration settings.

Есть стандартные рекомендации по deployment’у DNN - выкладываем файлы в расшаренной директории (SMB share), все физические сервера работают с проектом с этой расшареной директории, т.к. изменения файлов тоже надо синхронизировать и все сервера должны об этом знать.

Так вот, есть веб ферма с 3 физическими серверами. Работает с одной папкой на шаре. У всех серверов - свой локальный кеш, который как-бы надо синхронизировать.

Вместо использования централизированного кеша (memcached/redis/etc), разработчики DNN делают велосипед - синхронизационный провайдер. Это такая штука, которая каким-то образом дает другим серверам в ферме знать, что такой вот ключ уже не действителен и его надо удалить.

В бесплатной версии ДНН таких провайдеров есть два: один через базу данных, другой через файлы.

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

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

И тут подкрался песец…

Создание сайта (стандартная операция) работает с обычным API DNN а-ля “создать страницу”, “положить модуль на страницу” и т.д. Каждая из таких операций инвалидирует кеш по нужным им ключам (“удалить ключ Page_1234”, “Создать ключ Module_1234” и т.д). И таких операций _очень_ много. Около 40 тысяч для полноценного портала.

В результате, происходит 40 тысяч добавлений/удалений файлов с шары за очень короткий промежуток времени. ASP.NET на каждом из серверов обрабатывает file change notifications, что жрет процессор (их много, пускай даже они и ерундовые), потом еще происходит удаление ключей, а в результате - полный армагеддон на всех серверах.

Клиенты отписались в саппорт DNN - они ответили, что у них в платной версии есть специальный синхронизационный провайдер, который дает супер производительность в ферме. Купили. Ничего не изменилось - сервера все равно падают.

Оказалось что новый провайдер работает через HTTP: каждый web сервер говорит соседям что у них удалился ключ. В результате, при создании портала, эти 40 тысяч запросов идут на все соседние сервера в течении небольшого промежутка времени и они успешно захлебываются. Что в лоб, что по лбу.

В результате, как quick fix, пока выключили апдейты кеша при создании сайтов и руками удаляем ключики после таких операций. Теперь думаем как фиксить правильно - то ли переехать на какой-нить memcached, то ли писать свой синхронизатор на сокетах.

О собеседованиях

Thu, 20 May 2010 10:04:00 -0400

У нас иногда появляются вакансии. И мне приходится проводить интервью.

В принципе, мы требования к кандидатам не завышаем, в требованиях пишем стандартную ASP.NET солянку: .NET, ASP.NET, SQL, JavaScript. Набирали и во время кризиса, но кандидатов было много, а вакансий мало.

Ну и значит, приходили эти кандидаты на собеседования и пытались его с блеском (или не очень) провести.

Как-то так получалось, что люди делились на две категории: толковые и не очень.

Толковые отвечали на вопросы (если знали ответ). Если не знали - пытались догадаться или сделать выводы из наводящих вопросов. В целом - было приятно общаться. Если человек не подходил, то не по техническим вопросам.

А вот другие… Скажем вот один из стандартных вопросиков.

Что напишет следующий код:

public class Test
{
    private static void Main(string[] args)
    {
        try
        {
            int[] a = null;
            int i = a[m1(true)];
        }
        catch (Exception e)
        {
            Console.WriteLine(e.GetType());
        }
    }

    public static int m1(bool b)
    {
        if (b)
            throw new Exception("Some Exception");
        return 0;
    }
}

Варианты ответов:

a) Some Exception
b) System.NullReferenceException
c) System.Exception
d) Throws a runtime exception
e) None of the above

Как ни странно, на такой, в принципе простой задаче, которая просто показывает умеет ли человек читать код резалось почти 2/3 соискателей.

Варианты ответов, из тех что запомнились:

- Будет System.NullReferenceException, потому что компилятор знает что там null
- Не знаю
- Эксепшена не будет

Мне вот интересно - это нам так везло или это такая ситуация с C#/ASP.NET вообще?

Private, protected, internal, etc...

Tue, 18 May 2010 03:22:25 -0400

Вот, на работе, столкнулись с простой задачей: кусочек стороннего кода надо запускать асинхронно. Кусочек может работать минут 10 и запускать его синхронно (в результате web запроса) как-то совсем неправильно. На всякий случай уточню, что исходники этого кусочка есть.

Вроде бы - чего тут сложного? А оказалось…

1. Кусок зависел от инициализированного окружения ASP.NET. Использовал аж одну функцию из всего API ASP.NET - меппинг виртуальных URL в физический путь. Без инициализации ASP.NET, меппинг кидал исключение.
2. Кусок нельзя было выдрать минимальными усилями (и дописать/переписать), так как он завязан на функционал, который помечен как internal (в шарпе internal означает что объект/метод доступен только из своей сборки и снаружи не виден), так что выдирание кусочка привело бы не только к размножению идентичного кода, а так же к выдиранию всех зависимостей
3. Инициализацию ASP.NET нельзя сфабриковать - все методы, которые инициализируют ASP.NET являются или internal или private.
4. У ASP.NET есть официальное API инициализации, которое “поднимает” новый application domain (весьма тяжелая операция) и с помощью remoting устанавливает связь с произвольным классом внутри этого application domain.
5. Кроме самой инициализации ASP.NET, кусочку потребовалась инициализация через его собственный фильтр запросов, который проверяет не был ли его фреймворк инициализирован и инициализирует, если надо. Что бы вызвать фильтр, надо повозиться с созданием HttpApplication, который хочет полноценной инициализации, типа той, которая приходит из ISAPI фильтра ASP.NET (а-ля http module в apache).

В сухом остатке:
1. Обдурить маленький кусок кода без полной инициализации ASP.NET оказалось нельзя
2. Инициализация ASP.NET очень тяжелая, так как ведет к полной компиляции ASP.NET приложения. Кроме того все приложение грузится в память, в нашем случае это примерно 100 мегов в памяти, несмотря на то, что оно совсем не надо.
3. Необходимо следить что бы application domain не умер во время работы. Если умер - прибить и создать заново (что накладно)

К чему я это все веду:
1. В питоне я бы просто вызвал функцию инициализации фреймворка напрямую. Работоспособность при переезде на новую версию фреймворка контролировал бы с помощью юнит-теста.
2. Ограничение доступа на уровне “ты сюда не ходи, ты сюда ходи” в таких ситуациях очень сильно мешает.

ASP.NET и "спецсимволы" в URL

Sun, 18 Apr 2010 08:28:00 -0400

Вообще, если будет настроение, надо бы написать пост, почему же ASP.NET (который не MVC) плох. В целом, как технология.

Ну а пока просто расскажу как непонятная хрень осложняет жизнь.

На днях у нас нашелся странный баг: если в URL, в пути, содержится символ ‘&’ то ничего не работает и возвращается 400 Bad Request.

Т.е. вот такая вот ссылка не работает: http://foo.com/candy/m&ms/ , хотя ‘&’ не является запрещенным символом.

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

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

Предсказывая возможный вопрос, параметр этот может принимать значения из [a-zA-Z&: ], так что раньше необходимости деления параметров по категориям не было.

Ах да, самое главное забыл - мы получаем 400 Bad Request, даже если используются URL Rewrite, т.е. разобранная ссылка уже не содержит амперсанд в пути.

Т.е. если исходная ссылка была: http://foo.com/candy/m&ms/ , разобраная: http://foo.com/Default.aspx?candy=m&ms , то ошибка все равно останется.

О перегрузке объектов лишними сущностями

Tue, 13 Apr 2010 06:00:00 -0400

Очень часто я сталкиваюсь с подходом в программировании, который я мог бы описать как “все включено”.

Рассмотрим простой пример: некий разработчик игр, который пишет на С++, решил что STL это тормоз и вообще ужасная вещь, надо писать свой велосипед. Он сделал свои контейнеры, свои строки, все свое. Но рассказ будет не о NIH синдроме, а о том, как эти классы были спроектированы.

Возьмем его класс строки, как пример. Он умел все. Кроме базовых операций по работе со строками (сравнений и т.д.), строка умела читать себя из файла, писать себя в файл, конвертироваться во все базовые типы С++ и тому подобное. Все это помещалось в одном исходной файле размером этак под 160+ килобайт.

Это была присказка.

Так вот, на днях, один из разработчиков на нашем проекте (ASP.NET) решил сделать extension для списка строк, который бы умел сохранять и грузить его из CSV файла. В C# extension это что-то типа синтаксического сахара над существующим классом, который представляет собой функцию которую можно вызвать через объект данного класса. Для примера выше это было бы что-то типа такого:

List csv = List.LoadCSV("hello.csv");
csv.SaveCSV("hello2.csv");

Загрязнять объекты методами, которые не являются их неотъемлемой частью - это зло. Такой код потом тяжело поддерживать, классы раздуваются, теряется “идеологическая стройность” существующего кода, а так же теряется расширяемость - логика поведения таких вот утилитарных функций становится зашита в класс.

Думаете эти примеры придуманы и в реальном мире не встречаются?

Вот взять web2py, зачем делать экспорт и импорт данных в CSV частью объекта базы данных? Разве такой код сложнее написать:

export_to_csv(db, open('somefile.csv',  'wb'))

чем такой:

db.export_to_csv(open('somefile.csv',  'wb'))

Но во втором случае, идет жесткая привязка к типу объекта (база данных) и теряется reuse кода - duck typing в питоне никто не отменял.

Другой пример из того же web2py: сохранение результатов запроса как HTML! Это вообще нонсенс, включать в ORM логику представления:

rows = db(db.person.id > 0).select()
print rows.xml()

Или вот взять Руби (за пример спасибо Александру Соловьеву):

piranha@gto ~> irb
>> String.methods.length
=> 98
>> Fixnum.methods.length
=> 97
>> require 'active_support'
=> true
>> String.methods.length
=> 190
>> Fixnum.methods.length
=> 188

Зачем?

Может кто-то знает почему такое делают и почему это может быть, даже теоретически, хорошо?

Svarga - еще один web фреймворк

Fri, 09 Apr 2010 12:36:00 -0400

Примерно год назад решил сделать небольшой сайтик для себя. Думал на чем же делать (первоначально хотел на ASP.NET, но оный уже на работе набил оскомину), так что решил писать на питоне с использованием Django. Предупреждаю сразу, пост сугубо технический и предполагает значение Django в какой-либо степени.

Django, конечно, классная штука, но через пару недель разработки столкнулся с тем, что я не могу сделать множество вещей или “просто” или “эффективно”.

Пример таких вещей:

Странная система настроек доступа в contrib.auth - права доступа прописываются на уровне моделей
Убогие возможности по разграничению доступа к различным частям админки
Админка ориентирована на управление данными (читай - моделями) и не представляет собой некий фреймворк для построения админок
Тормоза в contrib.auth при использовании профилей (надо патчить модель пользователя)
Убогие возможности ORM’ки (те же агрегации появились уже после того, как я решил делать сайт) и т.д.
Тормоза в шаблонах, особенно при наследовании
Ужасные forms
Смесь логики представления с моделями данных (см. Meta в моделях)
И так далее.

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

В результате, было принято решение делать фреймворк который внешне похож на Django, но без определенных его недостатков. За основу взяли:

Werkzeug как основу WSGI приложения
Jinja2 как шаблонизатор
SQLAlchemy как ORM по умолчанию (если что - ее можно заменить)
WTForms для управления формами

Svarga представляет собой относительно тонкую прослойку между этими библиотеками. Кроме того, реализует некоторые вещи из django.contrib, например django.contrib.auth.

Разработка ведется в фоновом режиме, так что фреймворк скорее хобби, чем основная работа. Первые строчки кода попали в репозиторий примерно год назад.

Теперь немного о том, как это все выглядит.

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

Environment

В Svarga введено понятие окружения. Окружение это “глобальный” объект, который содержит всякие разные настройки, необходимые для обслуживания запроса от клиента. Каждый запрос получает свое личное окружение.

Глобальность окружения условная - окружение это что-то типа threadlocals объекта с поддержкой greenlet’ов, и состоит в том, что оно доступно отовсюду.

Делается это как-то так:

from svarga import env

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

Кроме того, в тех приложениях что я видел в Django, почти всегда кто-то пишет свой велосипед для доступа к request через threadlocals. В Svarga вы можете хранить переменные в окружении.

Что хранится в environment? Куча всего, например:

env.request - текущий запрос, если есть
env.sqla - сессия алхимии, если включена
env.jinja - контекст Jinja2
env.user - если подключен contrib.auth
и т.д.

Следует заметить, что окружение доступно из шаблонов:

{{ env.user.last_name }}, {{ env.user.first_name }}

Что у нас получилось с таким подходом? Примерно следующее:

Окружение доступно отовсюду, что само по себе большой плюс
Решение вопроса с загрязнением объекта запроса. Лично я считаю, что кормить дополнительные поля в request в Django это неправильно
Унификация хранения различных данных, которые необходимы для работы программы

Какие последствия использования окружения? Самое главное - во view не передается request, так как он и так доступен через окружение. Вот именно тут теряются функциональные принципы: функция которая, возможно, работает с запросом, не принимает его как параметр. Однако, благодаря Werkzeug этот самый запрос не всегда и нужен, так как следующий код это вполне себе полноценный view:

@as_html('hello.html')
def hello(a,b,c,d):
    return dict(m=a*b*c*d)

Дело в том, что Werkzeug умеет проверять, конвертировать и передавать параметры во view. Правило для примера выше выглядеть как-то так:

Rule('/mul/////', view='test.views.hello', endpoint='test.hello')

Routing

Routing у нас от Werkzeug. Отличается он от Django тем, что вместо сырых regexp в правилах, используется более-менее читабельный синтаксис.

Кроме того, он поддерживает фильтры, которые проверяют и конвертируют значения. В примере выше, “” проверяет что на этом месте будет число и если это число, конвертирует значение в тип int и передает его во view.

Фильтров разных много, и если надо - можно писать свои.

Кроме того, Svarga реализует несколько полезных штук, например так называемые bundle. Bundle (хм, наверное правильно будет его перевести как упаковка) это класс, который содержит view как методы, и является чем-то типа Include() правила.

Т.е. такая вот штука это и есть bundle:

class MyBundle(Bundle):
     @expose('/')
     @as_html('entry.html')
     def entry(self):
         return dict(a=10)

И потом его можно использовать так:

url_map = Map(
    MyBundle('b1', '/1/'),
    MyBundle('b2', '/2/'),
    MyBundle('b3', '/3/'),
)

Обратившись по адресу /1/ получим вызов в первом объекте, /2/ - во втором и так далее.

Обработка запросов

Мы поддерживаем только WSGI интерфейс. На текущий момент, для отладочного режима используется Werkzeug. Но, к сожалению, он медленнее чем CherryPy, так что для production лучше его не использовать. Кроме того, у нас в contrib есть поддержка tornado, который работает быстрее первых двух.

Если кто не знает что такое Werkzeug - советую почитать его документацию. Самое удобное и полезное что в нем есть, это онлайновый отладчик. Упало приложение? Не вопрос, можно на месте посмотреть stack trace, а заодно и получить доступ к консоли и посмотреть какие были переменные, потрейсить и т.д. По сути, это полноценный pdb, но через браузер.

Как и в джанго, у нас есть request middleware, причем подход ничем не отличается - можно получить управление до выполнения запроса, можно после, можно при исключении и т.д.

Приложения

Система приложений работает полностью аналогично оной в Django. Т.е. функционал всего проекта разбивается на отдельные части, которые можно подключать. Основные отличия:

Возможность инициализации приложения при старте процесса
Поддержка локальных директорий с шаблонами
Поддержка локальных директорий со статическими файлами. Причем есть команда генерации конфигурации для apache/nginx

Про первое хотелось бы рассказать немного больше. Каждое приложение может представить такую вот функцию в своем __init__.py:

def init(settings, env_class):
    settings.add_template_path('blog', 'templates')
    settings.add_static_dir('blog', 'static')

Эта функция вызовется один раз и позволит выполнить некий код инициализации приложения.

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

Чем это удобно?

Возможность конфигурировать приложения так, как ему надо
Общий подход для всех приложений - никто не будет делать какие-то там синглтоны и флажки, что приложение уже инициализировано
Возможность расширить класс-окружения, вместо постоянного добавления свойств уже во время жизни приложения. Например, в Django, request.auth добавляется в request middleware, на каждый запрос. У нас - один раз, при инициализации contrib.auth. Удобно и быстро.

Модели

Изначально, мы поддерживали только SQLAlchemy, но потом решили что можно поддержать GAE, а может и вообще nosql базы данных. В результате чего, код был немного отрефакторен. Сейчас имеется следующее:

Возможность добавления бекендов для разных библиотек
Возможность использования нескольких разных бекендов параллельно
Определен некий общий знаменатель для декларативного синтаксиса описания моделей. Если модель описать с помощью этого синтаксиса, бекенд БД конвертирует такую модель в понятное его библиотеки представление. Дает возможность писать один код для разных баз данных, например общий код contrib.auth отлично работает и под SQLAlchemy и под GAE.
Общий формат метаданных, который создает конкретный бекенд. Т.е. можно работать с описанием модели через общий интерфейс. Сейчас ModelForm и ModelFormSet используют метаданные для создания форм.
Определен общий интерфейс ModelManager, по аналогии с Django.

По умолчанию, используется SQLAlchemy. Основа моделей - sqlalchemy.ext.declarative, с кучкой всяких полезностей и красивостей.

Несколько примеров красивостей:

Автоматическая генерация primary key с названием id, если его нет
Автоматическая генерация имени таблицы, если ее нет
Всякие хелперы для создания ManyToMany связей без ручного создания промежуточной таблицы

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

Шаблоны

Для шаблонизации мы используем Jinja 2. Сама по себе Jinja крута:

Очень-очень быстрая (шаблоны компилируются в код питона)
Поддерживает sandboxing, особенно для случаев, когда шаблоны могут храниться в базе
Умеет сильно больше чем шаблоны Django. Писать свои теги на каждый чих больше не надо
Синтаксис от Django

Единственная вещь, которую ставят в недостаток Jinja - возможность писать логику в шаблонах. Тут я категорически не согласен. Следует разделять логику приложения и логику представления. Генерация меню по определенным правилам - это точно логика представления, но в Django придется писать своей тег, если там не просто цикл по массиву. В Jinja это решается встроенными средствами.

Команды

Писать свои команды в джанго было сущим наказанием. Для добавления команды приходилось писать страницу кода. Данная секция является больше рекламой Opster‘a (тоже от Пираньи), который занимается менеджментом команд и генерацией документации для них.

Вот пример вполне полноценной команды:

@command(name='lock-users', usage='-l LOCK users')
def lock_users(users, lock=('l', True, 'true or false')):
    'Lock or unlock users'
    q = User.objects.filter(User.name.contains(name))
    q = q.update(dict(locked=lock))
    print 'Done'

Кстати, благодаря алхимии, в коде выше, sql injection не произойдет. Запрос будет вида: UPDATE users SET locked=? WHERE users.name LIKE ? и все литералы и параметры будут переданы отдельно.

Админка

Django не была бы такой без своей знаменитой админки. Тут мы абсолютно согласны с большинством. Но… Лично я считаю что админка в Django сделана плохо - она нерасширяемая. Точнее, количество телодвижений, необходимых для изменения ее функционала, слишком велико даже для простых вещей.

В результате, было принято решение пойти по другому пути. Админка в Svarga это некий микро-фреймворк для создания административного интерфейса. Она легко расширяется - можно легко добавить нестандартные вьюшки или изменить поведение дефолтных. По сути, админка основана на bundle, которые просто монтируются под /admin/.

Пример “полноценной” админки модели:

class SampleAdmin(ModelAdmin):
    class Meta:
        menu = ('Sample Admin', 'Test')
        model = Sample

Определяем ее в приложении в admin.py и получаем админку модели Sample. Если очень хочется, можно свои вьюшки добавить, если унаследовать класс от AdminView и реализовать свои view методы.

К слову, рабочей и стабильной админки еще нет, она все еще в стадии разработки.

Приложеньица

Фреймворк постоянно развивается. Сейчас в contrib обитает следующее:

admin - микро-фреймворк для построения админки. Все еще в разработке, но посмотреть уже можно.
appengine - базовая поддержка Google AppEngine. К сожалению не развивается и не умеет метаданных (ModelForm не взлетит), но работает. Patches are welcome, as usual.
auth - аналог django.contrib.auth. Умеет много всего, например возможность переопределения модели User, более чистое API - данные отделены от логики, поддержка нескольких backend’ов и т.д.
cache - аналог django.contrib.cache
cherrypy - HTTP сервер с использованием CherryPy
dberrorlog - простенький logger всяких эксепшенов в базу
jslib - всякие полезности и удобности при работе с JavaScript
migrate - обертка над SQLAlchemy-migrate, с удобностями
sessions - аналог django.contrib.session
tableview - позволяет строить HTML таблички, который умеет сортировку, paging из набора исходных данных
tornado - HTTP сервер с использованием Tornado

Что дальше?

Следует учесть, что на текущий момент, это хобби. И поскольку это хобби, проектом занимаемся когда есть свободное время.

У проекта серьезно хромает документация - ее почти нет и очень сильно не хватает unit test’ов.

На текущий момент, занимаемся:

Чисткой и украшательством API
Доделываем админку
Доделываем миграции (улучшение интеграции с sqlalchemy-migrate)
Поддержкой интернационализации

Напоследок хочется сказать - patches and contributions are welcome :-)

P.S. Забыл самое главное, проект живет тут: http://bitbucket.org/piranha/svarga/wiki/Home

Немного о странных архитектурных решениях

Fri, 09 Apr 2010 06:42:00 -0400

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

Описание задачи: в .NET framework есть клиент SMTP. Письма он умеет посылать синхронно и асинхронно. Во втором случае можно подкинуть callback, который вызовется со статусом операции. Нужно посылать письма асинхронно, причем хотелось минимальными усилиями. Ну чего нам стоит вызвать SendAsync() вместо Send()? А оказалось, что не все так просто.

Начиная с ASP.NET 2.0 (сейчас на дворе 3.5), разработчики ввели поддержку асинхронных операций в базовый функционал. Но при этом сделали достаточно странное предположение - программе всегда нужен будет результат асинхронной операции до отдачи ответа клиенту. В результате, они сделали такой вот велосипед - программист может запустить несколько асинхронных задач, используя стандартные средства .NET, а страница будет ждать, пока они не завершатся. Кроме того, они запретили (кидается исключение) использование асинхронных задач, если для страницы не поставить флажок Async=”True”.

В целом, подход достаточно странный - у нас бизнес логика лежит в отдельных assembly, и посылка писем оттуда же. Получается, что для отсылки писем асинхронно, через стандартное API, мне прийдется менять уровень представления (хотя бы флажок Async=”true” повесить на все нужные страницы). Что как бы эээ.

Вот такие вот дела.

P.S. Если использовать асинхронную посылку писем вне контекста запроса ASP.NET, то все работает нормально.

Как взломали защиту Assassins Creed 2

Fri, 09 Apr 2010 05:30:00 -0400

Расскажу интересную историю о том, как взломали DRM Assassins Creed 2, а заодно и другие игры, которые ее используют.

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

Вкратце как работает защита, на примере Assassins Creed 2:

1. Защита требует постоянного подключения к серверу защиты
2. Защита интегрирована в игру
3. Защита передает некие запросы на сервер защиты, тот отдает назад некие данные, которые необходимы для игры. Без этих данных игра падает.

Все замечательно, кроме того что offline игра требует online подключения.

Теперь о том, как ломали:

1. Было выяснено, что общение с сервером идет по HTTPS
2. Сертификат SSL оказался самоподписанным (!)
3. Кто-то написал MITM сервер, который выдавал игре свой сертификат и логировал ответы и запросы в файл.
4. После того, как кто-то прошел всю игру и вытащил все возможные ответы и вопросы, раздал файл всем желающим.

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

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