Всем привет! В этом посте хотел бы поделиться опытом создания и развития сервиса для одной небезызвестной онлайн игры.
Жизнь в нем еще пока теплится, но, думаю, уже можно подвести окончательные итоги.
Об этой игре мне стало известно задолго до ее выхода, и я смог попасть в число первых бета-тестеров. От браузерной игры много не ждал, но интерес взял свое. Довольно быстро я нашел адекватное русскоязычное комьюнити и вступил в один из кланов.
Наверное, все уже слышали о чудесной библиотеке asyncio?
Если нет, то коротко: эта либа стала стандартом на асинхронное сетевое программирование на Python. tornado и twisted или научатся с ней работать или постепенно уйдут в маргиналы.
asyncio прекрасна, но это просто библиотека для работы с TCP, UDP, UNIX сокетами, PIPES и асинхронным запуском subprocess.
Чтобы всем было здорово нужны сторонние библиотеки, умеющие работать с asyncio. Кое-что уже есть, но мало.
Вот я с коллегами и сделал пару: одну для ZeroMQ и другую для PostgreSQL
Если вы прочно сидите на Python 2 и не интересуетесь Python 3 — не ходите под кат во избежание глупых вопросов и прочих недоразумений.
Читать полностью »
Привет!
Продолжая статьи о Центрифуге, мне хотелось бы обсудить один из способов подключения реал-тайм событий на сайт.
Суть отдельностоящих серверов рассылки сообщений в реальном времени такова, что клиенты из браузера должны подключиться к серверу, подписаться на нужные каналы и ждать сообщений из этих каналов.
Читать полностью »
Привет!
Пару месяцев назад я опубликовал на Хабре статью, посвященную описанию open-source проекта Centrifuge. Напомню, что это сервер рассылки сообщений подключенным клиентам (в основном из веб-браузера) в реальном времени. Написан на Python.
С тех пор я продолжал работать над проектом в свободное время и сейчас готов поделиться накопившимися мыслями и изменениями.
Привет!
В статье я опишу свой небольшой open-source проект — Centrifuge (далее Центрифуга). Это сервер на Python, задача которого — рассылка (broadcast) сообщений в реальном времени подключенным (в основном из браузера) клиентам.
Это будет история, наполненная как личными эмоциями, так и описанием используемых технологий, но без примеров кода. Если вам близка тема — не проходите мимо, будет любопытно.
Для начала, посмотрите, пожалуйста, скринкаст (не забудьте включить субтитры), если после просмотра интерес не пропадет, смело читайте дальше!
Не так давно, разрабатывая очередной программный продукт, наша команда разработчиков столкнулись с задачей реализации полноценной системы синхронизации пользовательских данных в реальном времени, путем рассылки (PUSH метод) изменений сервером. В самом приложении объем данных был не велик, но они могли просматриваться несколькими пользователями одновременно. Поэтому нам был необходим легковесный и достаточно производительный подход к синхронизации данных в рамках Веб-приложения. После того как были рассмотрены различные пути к решению этой задачи, мы остановили свой выбор на достаточно популярном эмуляторе WebSocket’ов – SockJS, который использует различные алгоритмы обмена данными между клиентом и сервером, в зависимости от браузера, которым пользуется клиент. В рамках данной статьи я не буду заострять внимание на том, почему был сделан именно такой выбор (по этому поводу написано немало статей, в том числе и на хабрахабре), а просто скажу, что мы ещё ни разу об этом не пожалели.
Изначально при изучении стандартных подходов к реализации подобного рода задач мы столкнулись с одной проблемой. Эта проблема заключалась в том, что взаимодействие с нашей системой производилось не только посредством веб интерфейса, но также посредством использования API сторонними продуктами, которые мы не могли контролировать. И конечный пользователь нашего продукта, безусловно, ожидает увидеть всю информацию об изменениях в данных, которые его касаются. Стандартный подход использования sockjs сервера подразумевает, что уведомления об изменении каких-либо данных в системе будут посылаться с использованием того же самого JS клиента, который используется для получения информации об этих изменениях. Именно поэтому в нашем случае такой подход был бы неприменим.
В этой статье я хотел бы рассказать о том, как мы решили эту задачу.
Читать полностью »
