Подписчики в nginx

Question

[Ockonal]

Всем привет. Есть хороший модуль: nginx http push module. Он позволяет реализовать long-poll.

Суть работы проста: есть адрес для отправки событий на какой-то канал, есть адрес для чтения события из указанного канала.

Чтобы опубликовать канал я делаю POST-запрос вида:

> POST /pub?channel=1 HTTP/1.1
> User-Agent: test
> Host: localhost
> Accept: */*
> Content-Length: 4
> Content-Type: application/x-www-form-urlencoded
>
TEST * upload completely sent off: 4 out of 4 bytes

Ответ:

< HTTP/1.1 202 Accepted
< Server: nginx
< Date: Fri, 20 Apr 2012 10:29:44 GMT
< Content-Type: text/plain
< Content-Length: 81
< Connection: keep-alive
Тут текст о том, что сообщение добавлено

Все нормально, а теперь я хочу, чтобы клиент читал этот канал. Проблема в том, что сервер обрывает GET запрос. То есть я делаю:

> GET /sub?channel=1 HTTP/1.1
> User-Agent: test
> Host: localhost
> Accept: */*

Получаю ответ:

< HTTP/1.1 200 OK
< Server: nginx
< Date: Fri, 20 Apr 2012 10:29:34 GMT
< Content-Type: application/x-www-form-urlencoded
< Content-Length: 4
< Last-Modified: Fri, 20 Apr 2012 10:29:34 GMT
< Connection: keep-alive
< Etag: 0
< Vary: If-None-Match, If-Modified-Since
<
* Connection #0 to host localhost left intact
TEST* Closing connection #0

Так вот, мне не нравится «Closing connection». Неужели это правильно, что клиент/подписчик посылает GET-запрос, получает последнее сообщение и отключается? Я до этого использовал модуль nginx push stream, там подключение висело и клиент раз посылал GET-запрос а потом только читал из сокета поступающие соединения из канала. Может я чего-то не так делаю?

В документации написано, типа можно этим управлять через заголовки Etag, If-None-Match, If-Modifief-Since, но смысл в них, если для их использования каждый раз нужно составлять GET-запрос. Запросы шлются очень часто, поэтому я не могу постоянно пересоздавать подключение между клиентом и сервером.

Answer 1

[ertaquo]

Вроде бы все правильно. Вы в своем POST-запросе передаете заголовок:

> Content-Length: 4

Соответственно nginx берет только первые четыре буквы — «TEST».

Comments

[Ockonal]

Так это я публикую сообщения. Потом я отправляю еще пост, с новым сообщением и еще и т.д. Или это неверно в плане логики?

[ertaquo]

Ой, пардон, не понял вопроса. Да, правильно. После получения клиентом данных он отключается и надо устанавливать соединение заново. Вот пример из некой документации:

var channelId = 12345;
function check_messages() {
	$.get('/listen?cid=' + channelId, {}, function(r) {
		// Считаем, что у нас есть div c id=messages,
		// куда мы дописываем сообщения
		$('#messages').append(r);
		setTimeout(check_messages, 500);
	}, 'json');
}

check_messages();

[Ockonal]

А можно ли оставлять соединение. Просто в другом модуле github.com/wandenberg/nginx-push-stream-module сервер не отключается.

[Виталий Перетятько]

Я использовал nginx http push module для одной задачи, у меня тоже соединение равлось несмотря на keep-alive. Это небыло проблемой, так как команды приходят редко, переустановить соединение не жалко. Насколько я помню у вас это все не в браузере работает, так что может попробуете использовать другой модуль (например тот что вы привели в ответе в пример, что не рвет), или вообще другое решение — например Redis, в нем есть замечательная поддержка pub/sub ( смысл тот же что и в nginx_http_push но соединение не рвется), там простой текстовый протокол и АПИ для разных языков.

Answer 2

[Анатолий]

javascript.ru/ajax/comet/long-poll Все правильно, при длинных запросах связь обрывается при прочтении ответа, и запрос шлется еще раз. Разница между обычными запросами лишь в длительности ожидания ответа.
В отличии от потока, где открывается сокет и данные гоняют туда сюда не отключаясьи (websocket).

Comments

[Алексей Сундуков]

Если сервер сам не закроет соединение и и не пришлет Content-Length, то не разорвется. Но может сдохнуть по таймаутам.