Re: Re[2]: HTTP Streaming. Возможно?

[public-mail at alekciy.ru]

> Здравствуйте, public-mail.
>
> Вы писали 8 февраля 2008 г., 2:20:03:
>
>>> Нет, ngx_http_fastcgi_module буферизует всегда и это пока не
>>> отключаемо.
>> Т.е. можно надеяться, что когда либо появиться опция output_buffering =
>> off ?
>
>
> Позвольте поинтересоваться, зачем нужна такая функция (HTTP Streaming)
> именно в FastCGI варианте ?
>
> Если вы пишете что-то свое, то можно попробовать сделать из этого
> HTTP-Daemon ... Не подойдет ли такой вариант?

Нужна она именно в таком варианте по одной простой причине: малое (по
сравнению с mod_apache даже с worker) потребление ОЗУ.

Насчет демона мысли были, только преимущества его я не вижу. Точнее даже
так, я считаю что пока не смогу реализовать нормальный варинат демона.
Ведь при отсутствии веб сервера логику работы по HTTP протоколу придется 
реализовывать самому. А зачем писать то, что уже кем то реализованно? Хотя
конечно может уже есть готовые библиотеки, но я таковых пока не встречал.

Еще какой варинат возникал это  Jabber сервер как демон. Поскольку ответы
от него идут в виде XML, то можно будет использовать AJAX.
Преимущества/недостатки это вариата еще не проверял.

В любом случае у меня сомнению по поводу демона. С демоном клиент сделал
запрос, получил ответ, соединение закрылось. В варианте того же чата
придется пинать сервер через короткие промежутки времени, открывать
соеденине по новой, а новых данных может и нет. Поэтому, имхо, лучше
держать соединение открытым минуту или две, а новые данные досылать по
мере поступления. Ведь на сколько я знаю открыть один коннект в течении
минуты по накладным расходам выгоднее, чем отрыть/закрыть 60 таких
конектов.

Поэтому HTTP Streaming.
> --
> С уважением,
>  Pavel                          mailto:pavel2000 at ngs.ru