ПРОЕКТЫ 


  АРХИВ 


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: Где лучше всего хранить состояние модуля?



Hello!

On Mon, Mar 04, 2013 at 08:29:00AM +0400, Sergey Zhemzhitsky wrote:

> Привет, Nginx Гуру
> 
> Модули к nginx никогда не разрабатывал, поэтому не пинайте сильно.
> 
> Я пытаюсь написать nginx http-модуль к сторонней системе у которой есть С API.
> Под этим API лежит в том чесле и установка TCP/IP соединения.
> 
> Насколько я понял, правильным способом подключения к сторонней системе была 
> бы разработка unstream http модуля.
> Проблема в том, что протокол довольно сложный и в условиях ограниченного 
> времени разбираться с ним некогда,
> поэтому хотелось бы попользовать API, которое предоставляет система.
> 
> Посоветуйте, плиз, по следующим вопросам
> 
> 1. Где лучше всего хранить объекты, которые должны быть созданы и 
> инициализированы только один раз для куска конфигурации
> server или http?
> 2. Где лучше всего создавать объекты, которые должны присутствовать единожды 
> для конфигурации server или http (например,
> устанавливать соединение со сторонней системой)?
> 3. Насколько я понял под upstream-ами *всегда* лежит асинхронное сокетное 
> api. Верно?
> 4. Насколько плохо работать напрямую со своими TPC/IP соединениями прямо из 
> request handler-ов?

In no particular order:

1. Конфигурацию модуля, а также глобальные сущности с ней связанные - 
правильнее всего хранить в, как это ни странно, конфиге модуля.

Надо, однако, иметь ввиду, что конфиг создаётся в master-процессе, 
а потом при fork()'е наследуется в worker'ов.  Так что если вы 
там, e.g., хотите создавать постоянные соединения с бекендом - то 
делать это надо уже после старта рабочих процессов в них самих, а 
не при чтении конфига.

2. Таки да, nginx - event-based сервер, и для работы со всем чем 
можно - используются event-based API.

3. Upstream - это точно такой же модуль, как и все остальные.  
Если вы хотите написать свой модуль, аналогичный upstream'у, я бы 
рекомендовал для начала посмотреть на upstream.

4. Работать с сокетами из request handler'ов - не плохо.  Работать 
с ними в блокирующемся режиме - плохая идея.

-- 
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.