1. Eugene

    13.06.2011

    0 ↑
    0 ↓
    Стоит задача - чат в реальном времени. Скорее всего без торнадо не обойтись, но в том числе не хочется терять админку и ОРМ джанго, поэтому возникли вопросы:
    1. Можно ли в торнадо-проекте написать import models и использовать джанговские модели?
    2. Как быть с авторизацией? Можно ли прикрутить авторизацию из джанги? (django-registration, auth модели...)
    3. Лучше вешать джанго админку на другом порту как отдельный проект, но обращаться к той же БД? Или есть более гибкие способы?
    4. Может есть смысл использовать SQLAlchemy + Tornado?
  2. foothold.ru

    13.06.2011

    0 ↑
    0 ↓
  3. nwalker.mp

    13.06.2011

    3 ↑
    0 ↓
    в моем текущем проекте как раз джанго+торнадо и чатики.
    сделано примерное так:
    - торнадо о джанго не знает вообще.
    - вся работа с бд в джанго-части, она же принимает сообщения от пользователей.
    - весь push работает через socket.io и tornadio. tornadio имеет в себе пинг и обработку коннектов-дисконнектов, минус одна проблема.
    - коммуникация между частями через redis pub/sub. на стороне джанго только publish, который быстрый и синхронный. на стороне торнадо, ожидаемо, subscribe, по которому отрабатывает push. единственный асинхронный редис-клиент для торнадо - brukva.
    - в редисе лежат все общие данные, помимо всего прочего.

    идею с редисом я упер у convore, где-то была статья про их архитектуру, правда там для асинхронного push голые wsgi-обработчики на uwsgi, кажется.
  4. nwalker.mp пишет все по делу, немного еще добавлю.

    единственный асинхронный редис-клиент для торнадо - brukva

    Асинхронных клиентов для redis под торнадо немало (есть еще как минимум https://github.com/d3vz3r0/tornado-redis и https://bitbucket.org/reiddraper/tornadis), но brukva (от evilkost) лучше.

    Использовать джанговские модели и т.д. из торнады можно, но осторожно, т.к. там все блокирующее и нужно смотреть, достаточно ли все быстро и выносить работу куда-то (тред, api, zeromq, rabbitmq), если недостаточно.

    Вместо другого порта лучше поддомен, чтоб с проксями проблем не было.

    Авторизацию прикрутить можно: слать куку сессии в торнадо-часть при установке соединения и проверять еще раз там. Вот еще немного слайдов.

  5. nwalker.mp

    13.06.2011

    0 ↑
    0 ↓

    ох-ох. где же была эта презентация, когда я рвал себе мозг, как связать сессии джанго и торнадо и получить хоть какой-то доступ к джанговским пользователям. что ж, лучше поздно, чем никогда, спасибо. =)

  6. Denis

    14.06.2011

    0 ↑
    0 ↓
    Очень интересна тема web сокетов и django, есть у кого интересные ссылки по практической реализации.
    Например репа на гитхабе :)
  7. Denis

    14.06.2011

    0 ↑
    0 ↓
  8. в django-websocket все неправильно, автор сам этим пользоваться не рекомендует) Лучше делать как nwalker.mp описал и запускать какую-то штуку, которая с вебсокетами работать будет, рядом.

  9. Denis

    14.06.2011

    0 ↑
    0 ↓
    Да я чуток углубился в суть вопроса, и тоже понял что django-websocket не подходит.
    Для подхода описанного nwalker.mp придется в очень многое вникать с 0.
    А можно ли сделать так: На основном хосте сидят джанги, а в поддомене сидит tornado который тоже подключен к django, но берёт на себя реализацию websocket'ов?
  10. так об этом и речь

  11. Вот еще немного слайдов.

    Offtop: а видео с DevConf'а случаем нет?

  12. nwalker.mp

    14.06.2011

    0 ↑
    0 ↓
    с вебсокетами есть одно "но".

    вебсокеты предоставляют 2way соединение, и его хочется использовать в полной мере. НО, коммуникация джанго-торнадо через редис 1way, джанго->торнадо, торнадо не может что-то сказать джанго.
    точнее может, но это сопряжено с дополнительными трудностями. варианты борьбы с этими трудностями упомянуты в замечательной презентации Михаила.

    еще один минус вебсокетов - их не поддерживает nginx, соответственно, нужна примерно такая последовательность:
    клиент -> haproxy -> nginx -> wsgi -> django
    | |-> статика
    |-> tornado #1
    |-> tornado #2
    |-> ...
    придется в очень многое вникать с 0
    я бы не сказал. самое сложное - удержать в голове, кто что куда шлет, и где что обрабатывается. а чисто технически там мало сложного, и redis, и tornadio достаточно просты в обращении.
    Вместо другого порта лучше поддомен, чтоб с проксями проблем не было.
    а можно чуть подробнее?
  13. Eugene

    14.06.2011

    0 ↑
    0 ↓
    Всем спасибо за ответы! Узнал много интересного.
    Спасибо, Михаил, за слайды. Интересно будет на досуге копнуть node.js.
    В текущей ситуации решил все не усложнять и сделать через html5 Server Side Events + обычная джанга.
  14. nwalker.mp

    14.06.2011

    0 ↑
    0 ↓
    о, занятная штука. а как их браузеры поддерживают?
  15. Denis

    14.06.2011

    0 ↑
    0 ↓
    а можно чуть подробнее?
    Можно ли сделать так чтобы на example.com - сидела джанга, а на chat.example.com - сидел торнадо?
  16. nwalker.mp

    14.06.2011

    0 ↑
    0 ↓
    можно. но вопрос в том, какой профит мы от этого получим.
    именно это я хотел услышать от Михаила. =)
  17. Профит - что это будет надежнее работать с глупыми проксями, которые могут, к примеру, пускать только 80 и 443 (бывают админы, которые в фирмах так проксю настраивают для сотрудников).

  18. Denis

    14.06.2011

    0 ↑
    0 ↓
    Но как это сделать? Ведь через web сервер это делать нельзя - они не поддерживают сокеты.
    Или через haproxy?
  19. это - это что?

    Надежно - все равно никак не сделать imho, даже с socket.io, который сваливается в flash или long polling, если вебсокеты не работают. Лучше стараться делать так, чтобы если фича отвалилась, сайт не особо страдал, все остальное работало как и раньше и основной функционал был все равно в каком-то виде доступен.

  20. Eugene

    15.06.2011

    0 ↑
    0 ↓
    о, занятная штука. а как их браузеры поддерживают?
    Хром, Файрфокс поддерживают, Опера вроде тоже. Но меня больше волнуют первые 2 - примерно 55% всего интернета в сумме. ИЕ-шных юзеров прийдется посылать на Chrome Frame...

    Попробовал я WebSockets, Server Side Events, пришел к выводу, что в любом случае и сокеты и SSE периодически дергают сервер, чтобы поддерживать постоянное соединение. Поэтому SSE в данном случае более простое решение - не требует ничего стороннего - браузер + джанга.

Внимание! Это довольно старый топик, посты в него не попадут в новые, и их никто не увидит. Пишите пост, если хотите просто дополнить топик, а чтобы задать новый вопрос — начните новый.