Django/Comet (Push): Меньше всего зол?

Я прочитал все вопросы и ответы, которые я могу найти относительно Django и HTTP Push. Тем не менее, ни один из них не предлагает четкое, краткое, сквозное решение о том, как выполнить базовый "мир привет" так называемой "кометы".

Первый вопрос (1): В какой степени проблема в том, что HTTP просто не является (по крайней мере до сих пор) для этого? Все ли потенциальные решения существенно взломают?

2) Какое лучшее в настоящее время решение?

облетел?
Некоторые другие решения на основе Twisted?
Торнадо?
node.JS?
XMPP w/BOSH?

Другое решение?

3) Как работает nginx push-модуль в этом обсуждении?

4) Какое из этих решений требует замены типичной модели развертывания mod_wsgi/nginx (или apache)? Зачем им это нужно? Является ли это благоприятным переходом в любом случае?

5) Насколько важны преимущества использования решения, которое уже находится в Python?

Выступление Алекс Гайнор из PyCon 2010, которое я только что наблюдал на blip.tv, является удивительным и информативным, но не самым ужасным для текущего состояния HTTP Push в Django. Одна вещь, которая, по его словам, дала мне некоторую уверенность, такова: Orbited делает хорошую работу по абстрагированию и моделированию концепции сетевых сокетов. Таким образом, когда WebSockets на самом деле приземляются, мы будем в хорошем месте для перехода.

6) Как веб-узлы HTML5 отличаются от существующих решений? Является ли оценка Гейнором легкости перехода от Орбитальной точной?

Ответ 1

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

Async с Django (и связанный с ним сетевой трафик, например websockets) был для многих из нас в сообществе. Я взял эти последние несколько лет, среди прочего, поцарапал этот зуд.

hendrix

hendrix - это conatiner WSGI/ASGI, который работает на Twisted. Это проект, в основном ориентированный на 5 энтузиастов, с помощью и финансированием от некоторых дальновидных организаций. Он находится в производстве сегодня десятками, но не сотнями компаний.

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

он основан на Twisted, не требует знания или использования Twisted внутренних компонентов, но оставляет их доступными
Он "просто работает" в том смысле, что вам не нужна какая-либо специальная конфигурация сервера или процесса, чтобы делать асинхронный и сокет-трафик из вашего приложения Django (или Pyramid или Flask)
Скорее всего, он будет совместим с ASGI, стандартом каналов Django, и имеет несколько существенных способов первый контейнер ASGI
Он поставляется с простыми API-интерфейсами, которые поддерживают поток вашей логики просмотра и легко доступны unit test.

Пожалуйста, смотрите этот разговор, который я дал в Django-NYC (в офисах Buzzfeed) для получения дополнительной информации о том, почему я думаю, что это лучший ответ на этот вопрос.

Ответ 2

Я бы посмотрел на evserver (http://code.google.com/p/evserver/), если вам нужна комета.

Он "поддерживает малоизвестное расширение асинхронного WSGI" и строит вокруг libevent. Работает как шарм и поддерживает django. Фактический код обработчика немного уродлив, но он хорошо масштабируется, так как он действительно асинхронный.

Я использовал evserver, и сейчас я перехожу к циклону (торнадо на скрученном), потому что мне нужно немного больше, чем у evserver. Мне нужен настоящий двунаправленный io (think socket.io(http://socket.io/)), и хотя evserver мог его поддерживать, я думал, что было легче переопределить tornado socket.io в циклоне (я выбрал циклон вместо торнадо, поскольку циклон строится на скрученном, что позволяет использовать больше транспортов, которые не реализованы в скрученном (ic zeromq)). Socket.io поддерживает веб-разъемы, опрос в стиле кометы и многое другое межсетевые, основанные на flash-сетях. Я думаю, что в большинстве практических ситуаций websockets + flash-based websockets достаточно, чтобы поддерживать 99% (по данным adobe flash-проникновения около 99% (http://www.adobe.com/products/player_census/flashplayer/version_penetration.html)) посетителей веб-сайтов (только люди, не использующие флэш-память, должны откидываться на один из сокетов. Его резервное копирование (менее перфомант и ресурс))

Помните, что веб-сайты не являются транспортными средствами http, поэтому они помещают их в прокси-серверы на основе http (например, haproxy в режиме http), нарушает соединение. Лучше обслуживайте их на альтернативном ip или порту, чтобы вы могли прокси-сервер в режиме tcp (например, haproxy в режиме tcp).

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

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

(3) Это всего лишь одна другая реализация сервера. Если я прочитал его правильно, нажмите только. толкание данных клиенту выполняется путем установки http equest из вашего приложения на сервер nginx. (nginx затем заботится о том, чтобы они дошли до клиента). Если вы заинтересованы в этом, посмотрите на mongrel2 (http://mongrel2.org/home), у него есть не только обработчики для longpolling, но и для websockets. (Вместо того, чтобы делать http-запрос to mongrel, на этот раз вы используете обработчики zeromq для получать данные на ваш mongrel-сервер) (обратите внимание на отсутствие энтузиазма разработчика для веб-сайтов и флеш-сайтов. Особенно принимая во внимание, что протокол websocket имеет тенденцию развиваться, в какой-то момент вам может потребоваться перекодировать поддержку web-обоев mongrel2 с поддержкой websockets)

(4) Все решения, кроме evserver, заменяют wsgi чем-то другим. Хотя большинство серверов также имеют некоторую поддержку wsgi на этом "что-то еще". Независимо от того, какое решение вы выберете, будьте осторожны, чтобы один интенсивный процессор или другой запрос блокировки io не блокировал сервер. (вам нужно либо несколько экземпляров, либо потоки).

(5) Не очень важно. Все решения зависят от некоторых пользовательских обработчиков, чтобы нажимать (и, если применимо, получать) данные клиенту. Все упомянутые решения позволяют записывать эти обработчики на python. Если вы хотите использовать совершенно другую структуру (node.js), тогда вам нужно взвесить непринужденность node.js(она считается простой, но она также довольно экспериментальная, и я нашел очень мало библиотек на самом деле стабильный) от удобства использования вашей существующей базы кода и доступных библиотек (например, если вашему приложению нужен блог, вы найдете множество дневников django, которые вы могли бы подключить, но не для node.js) Также не смотрите на себя вслепую по характеристикам производительности. если вы не планируете делать немые предопределенные данные (что все тесты) для клиента, вы обнаружите, что фактическая обработка данных добавляет многобольше накладных расходов, чем даже худшая асинхронная реализация. (Но вы все еще хотите использовать сервер на основе асинхронного ядра, если вы планируете иметь много одновременных клиентов, потоковая передача просто не предназначена для сохранения тысяч подключений)

(6) websockets предлагают двунаправленную связь, длительный опрос/комета только толкает данные, но не принимает записи. (Socket.io имитирует эту двунаправленную поддержку, используя два HTTP-запроса, один для longpoll, один для отправки данных. Он отслеживает их взаимозависимость идентификатором (session), который является частью строки запроса обоих запросов). основанные на flash-сетях, похожи на реальные веб-порты (разница в том, что их реализация выполняется в swf, а не в вашем браузере). Также протокол websockets не соответствует протоколу http; longpolling/comet stuff (технически клиент websocket отправляет запрос на обновление на сервер websocket, обновленный протокол больше не http)

Ответ 3

Существует поддержка WebSockets с django-websocket, но, к сожалению, для ее работы есть серьезные проблемы; здесь цитата с этой страницы:

Отказ от ответственности (что вы должны знать при использовании django-websocket)

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ BIG FAT - на данный момент его технически НЕ возможно каким-либо образом использовать веб-узел с WSGI. Это известная проблема, но ее невозможно обработать чистым способом из-за какого-то дизайнерского решения, которое было сделано в то время, когда была написана стадия WSGI. В это время такие вещи, как Websockets и т.д., Не существовали и не были предсказуемыми.

...

Но не только WSGI является ограничивающим фактором. Сам Django был разработан вокруг простого запроса на сценарий ответов без использования Websockets. Это также означает, что предоставление стандартного соответствия реализации websocket сейчас невозможно для django. Однако это работает как-то не так красиво. Поэтому имейте в виду, что сокеты tcp могут подвергаться пыткам при использовании django-websocket.

Итак, на данный момент WSGI: нет; Django: вряд ли кто-нибудь пойдет, даже с django-websockets; см. комментарий автора оригинальное объявление:

Я не могу сказать, что это выглядит неплохо. Вы делаете долгоживущие соединения таким образом, чтобы требовать потоки. django-websocket требует установки потоковой передачи и не будет работать, если у вас есть процессы (потому что у вас просто слишком много процессов), но потоки не будут масштабироваться для большого количества подключений одновременно, поэтому его просто ложная безопасность. Вам нужна асинхронная платформа для долговечных вещей, и я делаю это, выполняя свое приложение в Django и моей комете и websocket в Node.js

Лично, если вы пытаетесь использовать WebSockets (который я ожидаю в следующем году), я бы попробовал комбинацию Twisted и Cyclone. Они предназначены для работы с WebSockets и хорошо масштабируются. Если вы правильно напишете свой код, чтобы удалить ненужные зависимости от Django, вы сможете использовать большую часть своего кода в системе на основе Twisted. Это очень отличное преимущество перед использованием Node.js или кометы или любой системы на другом языке. Вы также можете сделать простой push

Наконец, вы также можете просто решить это слишком сложно и использовать внешнюю службу, чтобы обеспечить поддержку push. Тогда возникает вопрос отправки простого запроса JSON на их серверы, а не беспокоиться о том, как установить соединение и как concurrency будет работать, и тому подобное. Конечно, вам нужно будет заплатить за это (хотя в настоящее время он может быть бесплатным в бета-версии), но вам не нужно беспокоиться о деталях реализации; у вас не будет полной мощности WebSockets, но просто нажмите кнопку поддержки.

Ответ 4

Re question # 2, мне недавно давали экскурсию по внутренностям приложения Django, которое сильно использует Comet, а Orbited - это решение, которое они выбрали.