ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Здравствуйте, public-mail.

Вы писали 8 февраля 2008 г., 12:30:50:

>> Если вы пишете что-то свое, то можно попробовать сделать из этого
>> HTTP-Daemon ... Не подойдет ли такой вариант?
> Нужна она именно в таком варианте по одной простой причине: малое (по
> сравнению с mod_apache даже с worker) потребление ОЗУ.

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

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

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

  Как раз таки демон и позволяет держать пуш-соединения, и не
  переоткрывать их ни раз в секунду, ни раз в минуту.  ПОзволяет
  держать их долго, десятки минут.

Допустим что все-таки есть поддержка HTTP-Streaming via FastCGI. Тогда
у вас для каждого, допустим, клиента чата нужно держать по
персональному рабочему процессу, плюс налаживать коммуникации между этими
процессами.

 Для реализации на нескольких сайтах сервиса чата я использовал
 однопоточный даймон с неблокирующимися сокетами, написанный на перл.
 Большую нагрузку оно конечно не потянет, да и сделано (у меня) "не
 очень". Как тот же самый чат сделать в другом варианте (в пределах
 того же языка) с использованием FastCGI/mod_perl, множества процессов
 - я не представляю, мне кажется что это значительно сложнее.

 Для реализации чата с использованием nginx я где-то видел  модуль
 mod_voc для nginx.
 Пример смотреть в районе  
http://forum.vochat.com/viewtopic.php?t=4288&highlight=nginx
 Чего оно там делает - не знаю, но оно есть, смотрите :)
 

-- 
С уважением,
 Pavel                          mailto:pavel2000@xxxxxx




 




Copyright © Lexa Software, 1996-2009.