Асинхронный удар

[int02h]

>> совершает какое либо дайствие?
Опечаточка))

[int02h]

Прошу прощения, если я кого-то обидел, указав на опечатку. Топик мне понравился и ничего против него я не имею.

[obiwanus]

Такие вещи в личку автору и будет щастье, неужели не понятно

[Masterkey]

помните, ныли раньше, что непонятно как отправлять сообщения в личку?
теперь, видимо, два клика это много :)

[svetlov]

gevent использует гринлеты. Против libevent ничего не имею, красивая штука. Но гринлеты — бууу. Stack slicing, лежащий в основе технологии, глюкав по определению. Слишком хакерская процедура. Не один раз наблюдал, как гринлеты и C Extensions входили в клинч. Упадет процесс или просто повиснет — дело случая.
Т.е. оно работает, но шаг влево-вправо приводит к неожиданным последствиям.

[svetlov]

Мое предложение? Не понял вопроса.

[svetlov]

Все еще не понимаю. Если речь идет о работе с сетью — то есть разные способы. Библиотек — дюжина.
А если конкретно о гринлетах — то никак не починишь. stackless делает переключение «правильно», но для этого нужно менять ceval. Т.е. stackless — это другой питон, а не библиотека для классического cpython.

[Imbolc]

У нас на gevent-wsgi-сервере крутится крупный проект. Уже около года. Обрабатывает порядка 200 запросов / сек. Там юзается lxml. Ничего подобного не замечал. Очень доволен gevent-ом.

[svetlov]

lxml прокатит. Многие библиотеки работают — иначе бы о gevent вообще никто бы не говорил.
Беда случается, если вызывается callback. И если этот callback, скажем, работает со старым стеком, поврежденным stack slicing.
Это встречается нечасто, да и проявляться может не с первого раза. Зато уж если выползло — тушите свет. Доверие к Питону как к платформе резко падает, ломается просто непредсказуемо. Чуть-чуть подшаманив, можно восстановить работу. До следующего раза…
Очень неприятная ситуация. Корень зла — очень хакерский подход к подсовыванию стека для питоноввского фрейма. Оно работает. Время от времени.
Что касается gevent, то monkey-patching и покрытие тестами тоже доставляют.

[svetlov]

Немножко пишут здесь: bitbucket.org/ambroff/greenlet/src/9e69243295dd/greenlet.c
Самое начало файла.
Да и вообще исходники стоит почитать. Их совсем немного.

[ZZZ_Sochi]

А выбор есть?

[Masterkey]

как костыль для веб-сокетов на ИЕ — флешу замены нет, но от фразы «а js не умеет работать с сокетами» меня слегка передернуло

dev.w3.org/html5/websockets/

[giner]

А что это на картинке?

[ftp27]

«Подвеска в виде пули, на которой выгравирован католический крест и текст молитвы.»

[point212]

Вы слышали когда-нибудь про silver bullet? :)

[MpaK999]

Вы тоже увидели дилдо на цепочке? :)

[ingspree]

Как насчëт socket.io/? И тогда github.com/MrJoes/tornadio/

[lol2Fast4U]

tornadio? А не проще перейти на node.js? Оно быстрее любого питона.

[dmitriko]

LOL. Жаль не все поймут эту шутку ;)

[niksite]

объясните?

[dmitriko]

Очень не надежно в продакшине.
В то время как питоновские демоны работают годами без вмешательства.

[niksite]

Как раз сейчас выбираю в каком направлении податься к торнаде ли, к ноде ли, аль и вовсе в сторону ерланга какого…

[dmitriko]

Erlang хорош когда на нем пишет кто то другой ))
NodeJS сыроват.
Простые системные админстраторы рекомендуют Python.

[ingspree]

5 баллов, честное слово. :)

[kmike]

Перешел с socket.io-node на tornadio, т.к. такое решение проще интегрировать с не-реалтайм частью сайта, да и писать на питоне приятнее. У node.js тоже свои преимущества есть (главное — больше готовых асинхронных библиотеках), но в сумме преимущества чисто питоньего решения перевесили, ни разу не пожалел.

[b0n3Z]

Пробовал торнадио. Пока еще, увы, слишком рано для продакшена.

[kmike]

а с какими трудностями столкнулись?

[kmike]

Почему объемы кода должны быть обязательно меньше? Какой еще beaker.session, какие зависимости? И что не так с flashpolicy?

Интересно даже, в чем конкретно-то проблемы с tornadio. Мне-то просто показалось, что код там по делу, все работает, пользоваться удобно.

[kmike]

1) Мы о разных библиотеках говорим: tornadio — это совсем не SocketTornad.IO.

2) flashpolicy-сервер — это не пример использования, а встроенная штука для того, чтобы из коробки иметь работающий flash-транспорт. В продакшне я для этого nginx настраиваю. К слушанию сокетов он не имеет ну никакого отношения, и отвечать xml он должен не на каждый запрос. Почему он написан так, как написан — судить не берусь, т.к. с flash знаком слабо. Как пользователя это меня не волнует, т.к. в продакшне эта штука не используется, а локально работает и есть не просит.

Примеры можно посмотреть в папке с примерами, очевидно) Например, вот чат: github.com/MrJoes/tornadio/blob/master/examples/chatroom/chatroom.py — куда уж проще?

[fu2re]

tornadio как то упустил. Попробую, спасибо.

[dvska]

а ещё под PyPy пробуйте запускать

[VladX]

А почему Вы не попробовали напрямую работать с сокетами? Будет и быстро, и стабильно, и не слишком сложно (тут можно поспорить, но тем не менее, при грамотном подходе получится не сложнее фреймворка), и логику работы Вам легко будет подогнать под себя в случае чего.

[pluseg]

А как предлагаете организовать сокеты на клиенте?

[VladX]

У вас же они уже организованы через флеш, вам остаётся переписать серверную часть.

[pluseg]

По-моему, автор как раз решает вопрос выбора инструмента для серверной части.
П.с. Я не автор, лишь любопытствующий;)

[VlK]

А с чем он, по-вашему, работает? Автор перечислил популярнейшие инструментарии для работы с неблокирующими сокетами.

Не писать же все заново!

[VladX]

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

[ZZZ_Sochi]

Может тогда ещё и на Си писать?
«Своя реализация» и всё равно будет прослойкой, только поддерживать её придётся самому.
Не стоит изобретать пылесос.

[VladX]

Стоит, если свой пылесос лучше справляется с нужной вам задачей, чем существующие решения. Если бы не было сподвижек в изобретении пылесосов, мы бы до сих пор заводили пылесосы на бензине из 19 века.

[ZZZ_Sochi]

Угу… А если бы каждый изобретатель пылесоса начинал в высечения искры из камня и придумыванию колеса, то мы бы до технологий девятнадцатого века не добрались.
Я думаю, что в данном случае всё уже придумано. Автор показал нам три инструмента, и только если их не хватит, нужно будет начинать выдумывать что-то своё. А то правда, проект надо писать прямо сразу под конкретное железо на асме… Да и асм… Да и само железо…

[ZZZ_Sochi]

Я даже не знаю, как ответить на это. Наверное потому, что питон больше подходит для данных целей.

[bsdemon]

Gevent
— Не очень удобно.

Почему?

[fu2re]

У twisted есть обработчики событий, например connectionLost. У gevent и tornado их нет.

[b0n3Z]

Не знаю, чем вам не понравились исходники торнады, там ведь всего ~10'000 строк, все написано с кучей комментариев и само по себе весьма pythonic.

[p0is0n]

Еще бы про клиента написали.

[fu2re]

про клиент можно почитать тут.
Единственное что, используя такой способ, надо чтобы дополнительно висел сервер политик на 843 порту, либо эти самые политики раздавались на основном сервере. Например в пример сервера на twisted в dataReceived добавить:

file_policy="""<?xml version="1.0" encoding="UTF-8"?>\n
<cross-domain-policy xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:noNamespaceSchemaLocation='http://www.adobe.com/xml/schemas/PolicyFileSocket.xsd'>\n
        <allow-access-from domain="*" to-ports="*" secure="false" />\n
        <site-control permitted-cross-domain-policies="master-only" />\n
</cross-domain-policy>\0"""

if line=='<policy-file-request/>\0':
   self.transport.write(file_policy)

[seriyPS]

Сразу оговорюсь, что работал с ними очень и очень поверхностно, но впечатления такие:

Tornado — слишком тоненький, мало функций из коробки. И, насколько я знаю, нет поддержки пулов потоков (соединений с БД например)
Gevent — это очень не-мейнстрим и собрано на костылях и хаках со стеком и манкипатчингом
Twisted — весьма и весьма неплохо, но говорят что медленный

Думаю в случае возникновения необходимости держать постоянные соединения предпочту Erlang

[ZZZ_Sochi]

Выше я уже выразил свою мысль: сначала реализуем на том, что есть, а потом оптимизируем.
В случае проблем с производительностью сокетов, Erlang действительно в тему. Но не раньше.

[seriyPS]

Тоже верно)

[DmitryVolodin]

Я в свое время написал библиотечку для NOC'а. Она легковесная и умещается в одном файле: lib/nbsocket.py. Можете попробовать. Для наших задач вполне хватает.

[letoosh]

Облегчить сервер от ненужной работы, например отрисовки самой странички, используя вместо этого javascript шаблонизатор.

Практика показывает что это не всегда полезно. В вашем случае, если много одинаковых запросов с похожими данными, но разным представлением — смысл есть. У нас обычно много разносортных данных и опыт показал что для отрисовки на стороне клиента объем данных для темплейтинга растет намного быстрее чем объем уже отрисованных данных. Учитывая еще тот факт, что javascript шаблонизатор как правило медленее отрисовки на стороне сервера, я бы советал очень аккуратно подходить к такому приему.

Вообще, на своем опыте убедился что *очень* часто дешевле отрисовать HTML и вернуть клиенту, чем толкать все нужные для шаблона данные.