Редактировать ОК. У меня длинный опрос из javascript, который обращается к представлению django.Вид выглядит следующим образом.Он теряет некоторые сообщения, которые я публикую от клиента Redis в канале.Кроме того, мне не следует подключаться к redis для каждого запроса (возможно, переменные redis можно сохранить в сеансе?) Если кто-то может указать на изменения, которые мне нужны, чтобы это представление работало при длительном опросе, это было бы здорово!Спасибо!
def listen (request):
if request.session:
logger.info( 'request session: %s' %(request.session))
channel = request.GET.get('channel', None)
if channel:
logger.info('not in cache - first time - constructing redis object')
r = redis.Redis(host='localhost', port=6379, db=0)
p = r.pubsub()
logger.info('subscribing to channel: %s' %(channel))
p.psubscribe(channel)
logger.info('subscribed to channel: %s' %(channel))
message = p.listen().next()
logger.info('got msg %s' %(message))
return HttpResponse(json.dumps(message));
return HttpResponse('')
---- Оригинальный вопрос --- Я пытаюсь создать приложение чата (с использованием django, python) и пытаюсь избежать механизма опроса.Я боролся с этим сейчас - так что любые указатели будут по достоинству оценены!
Поскольку веб-сокеты не поддерживаются в большинстве браузеров, я считаю, что длительный опрос - это правильный выбор.Сейчас я ищу что-то, что масштабируется лучше, чем обычный опрос, и его легко интегрировать со стеком Python Django.Как только я закончу с этой разработкой, я планирую оценить другие фреймворки Python (Tornado Twister, Gevent и т. Д.), Которые приходят на ум.
Я провел некоторые исследования и мне понравился механизм redis pubsub.Сообщение чата публикуется на канале, на который уже подписаны оба пользователя.Вот мои вопросы:
Из того, что я понимаю, apache будет плохо масштабироваться, так как длинный опрос скоро столкнется с ограничениями процесса / потока.Поэтому я решил перейти на nginx.Это обоснование правильно?Также есть ли какие-то проблемы, связанные с nginx, о которых я беспокоюсь?В частности, меня беспокоит, что последняя версия не поддерживает http 1.1 для передачи прокси, как упоминалось в сообщении в блоге по адресу http://www.letseehere.com/reverse-proxy-web-sockets?
Как создать клиентскую часть подписки на сообщения насторона браузера?На мой взгляд, это будет URL, по которому код javascript будет "долго опрашиваться".Поэтому на уровне javascript клиент будет опрашивать URL-адрес, который «блокируется» «неблокирующим образом» на стороне сервера.Когда появляется результат (в данном случае новое сообщение чата), сервер возвращает результат.Javascript делает то, что ему нужно, а затем снова опрашивает тот же URL.Правильно ли это мышление?Что происходит между интервалами, когда цикл javascript приостанавливается - теряем ли мы какие-либо сообщения со стороны сервера.
По сути, я хочу создать следующее:
Из redis я публикую сообщение на канал "foo" (также можно использовать redis-cli - его легко включить позже в python / django)
Я хочу, чтобы одно и то же сообщение появлялось в двух окнах браузера, использующих один и тот же код js для опроса.Предположим, что код браузера знает название канала для целей тестирования
Я публикую второе сообщение, которое снова появляется в двух окнах браузера.
IЯ новичок в приложениях реального времени, поэтому извиняюсь за любой вопрос, который может не иметь смысла.
Спасибо!