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@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
