30.6. Сервер TCP с предварительным порождением процессов без блокировки для вызова accept

30.6. Сервер TCP с предварительным порождением процессов без блокировки для вызова accept

В первом из рассматриваемых нами «усовершенствованных» серверов используется технология, называемая предварительным созданием процессов (preforking). Вместо того чтобы вызывать функцию fork каждый раз при поступлении очередного запроса от клиента, сервер создает при запуске некоторое количество дочерних процессов, и впоследствии они обслуживают клиентские запросы по мере установления соединений с клиентами. На рис. 30.1 показан сценарий, при котором родитель предварительно создал N дочерних процессов, и в настоящий момент имеется два соединения с клиентами.

Рис. 30.1. Предварительное создание дочерних процессов сервером

Преимущество этой технологии заключается в том, что обслуживание нового клиента не требует вызова функции fork родительским процессом, тем самым стоимость этого обслуживания понижается. Недостатком же является необходимость угадать, сколько дочерних процессов нужно создать при запуске. Если в некоторый момент времени количество имеющихся дочерних процессов будет равно количеству обслуживаемых клиентов, то дополнительные клиентские запросы будут игнорироваться до того момента, когда освободится какой-либо дочерний процесс. Но, как сказано в разделе 4.5, клиентские запросы в такой ситуации игнорируются не полностью. Для каждого из этих дополнительных клиентов ядро выполнит трехэтапное рукопожатие (при этом общее количество соединений не может превышать значения аргумента backlog функции listen), и при вызове функции accept установленные соединения будут переданы серверу. При этом, однако, приложение-клиент может заметить некоторое ухудшение в скорости получения ответа, так как, хотя функция connect может быть выполнена сразу же, запрос может не поступать на обработку еще некоторое время.

За счет некоторого дополнительного усложнения кода всегда можно добиться того, что сервер справится со всеми клиентскими запросами. От родительского процесса требуется постоянно отслеживать количество свободных дочерних процессов, и если это количество падает ниже некоторого минимального предела, родитель должен вызвать функцию fork и создать недостающее количество дочерних процессов. Аналогично, если количество свободных дочерних процессов превосходит некоторую максимальную величину, некоторые из этих процессов могут быть завершены родителем, так как излишнее количество свободных дочерних процессов тоже отрицательно влияет на производительность (об этом мы поговорим чуть позже).

Но прежде чем углубляться в детали, исследуем основную структуру этого типа сервера. В листинге 30.6 показана функция main для первой версии нашего сервера с предварительным порождением дочерних процессов.

Листинг 30.6. Функция main сервера с предварительным порождением дочерних процессов

//server/serv02.c

 1 #include "unp.h"

 2 static int nchildren;

 3 static pid_t *pids;

 4 int

 5 main(int argc, char **argv)

 6 {

 7  int listenfd, i;

 8  socklen_t addrlen;

 9  void sig_int(int);

10  pid_t child_make(int, int, int);

11  if (argc == 3)

12   listenfd = Tcp_listen(NULL, argv[1], &addrlen);

13  else if (argc == 4)

14   listenfd = Tcp_listen(argv[1], argv[2], &addrlen);

15  else

16   err_quit("usage: serv02 [ <host> ] <port#> <#children>");

17  nchildren = atoi(argv[argc - 1]);

18  pids = Calloc(nchildren, sizeof(pid_t));

19  for (i = 0; i < nchildren; i++)

20   pids[i] = child_make(i, listenfd, addrlen); /* возвращение родительского процесса */

21  Signal (SIGINT, sig_int);

22  for (;;)

23   pause(); /* дочерние процессы завершились */

24 }

11-18 Дополнительный аргумент командной строки указывает, сколько требуется создать дочерних процессов. В памяти выделяется место для размещения массива, в который записываются идентификаторы дочерних процессов, используемые функцией main при окончании работы программы для завершения этих процессов.

19-20 Каждый дочерний процесс создается функцией child_make, которую мы показываем в листинге 30.8.

Код обработчика сигнала SIGINT, представленный в листинге 30.7, отличается от кода, приведенного в листинге 30.3.

Листинг 30.7. Обработчик сигнала SIGINT

//server/serv02.c

25 void

26 sig_int(int signo)

27 {

28  int i;

29  void pr_cpu_time(void);

30  /* завершаем все дочерние процессы */

31  for (i = 0; i < nchildren; i++)

32   kill(pids[i], SIGTERM);

33  while (wait(NULL) > 0) /* ждем завершения всех дочерних процессов */

34   ;

35  if (errno != ECHILD)

36   err_sys("wait error");

37  pr_cpu_time();

38  exit(0);

39 }

30-34 Функция getrusage сообщает об использовании ресурсов всеми дочерними процессами, завершившими свое выполнение, поэтому мы должны завершить все дочерние процессы к моменту вызова функции pr_cpu_time. Для этого дочерним процессам посылается сигнал SIGTERM, после чего мы вызываем функцию wait и ждем завершения выполнения дочерних процессов.

В листинге 30.8 показана функция child_make, вызываемая из функции main для порождения очередного дочернего процесса.

Листинг 30.8. Функция child_make: создание очередного дочернего процесса

//server/child02.c

 1 #include "unp.h"

 2 pid_t

 3 child_make(int i, int listenfd, int addrlen)

 4 {

 5 pid_t pid;

 6 void child_main(int, int, int);

 7 if ( (pid = Fork()) > 0)

 8 return (pid); /* родительский процесс */

 9 child_main(i, listenfd, addrlen); /* никогда не завершается */

10 }

7-9 Функция fork создает очередной дочерний процесс и возвращает родителю идентификатор дочернего процесса. Дочерний процесс вызывает функцию child_main, показанную в листинге 30.9, которая представляет собой бесконечный цикл.

Листинг 30.9. Функция child_main: бесконечный цикл, выполняемый каждым дочерним процессом

//server/child02.c

11 void

12 child_main(int i, int listenfd, int addrlen)

13 {

14  int connfd;

15  void web_child(int);

16  socklen_t clilen;

17  struct sockaddr *cliaddr;

18  cliaddr = Malloc(addrlen);

19  printf("child %ld starting ", (long)getpid());

20  for (;;) {

21   clilen = addrlen;

22   connfd = Accept(listenfd, cliaddr, &clilen);

23   web_child(connfd); /* обработка запроса */

24   Close(connfd);

25  }

26 }

20-25 Каждый дочерний процесс вызывает функцию accept, и когда она завершается, функция web_child (см. листинг 30.5) обрабатывает клиентский запрос. Дочерний процесс продолжает выполнение цикла, пока родительский процесс не завершит его.

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

6.5.1. Действие ACCEPT

Из книги Iptables Tutorial 1.1.19 автора Andreasson Oskar

6.5.1. Действие ACCEPT Данная операция не имеет дополнительных ключей. Если над пакетом выполняется действие ACCEPT, то пакет прекращает движение по цепочке (и всем вызвавшим цепочкам, если текущая цепочка была вложенной) и считается ПРИНЯТЫМ (то бишь пропускается), тем не менее,


Поддержка синхронного вызова

Из книги Язык программирования С# 2005 и платформа .NET 2.0. [3-е издание] автора Троелсен Эндрю

Поддержка синхронного вызова Генерируемый агент определяет также поддержку синхронного вызова Web-методов. Например, синхронный вариант метода Subtract() реализуется так.public int Subtract(int x, int y) { object[] results = this.invoke("Subtract", new object[] {x, y}); return ((int)(results[0]));}Обратите внимание на то, что


Поддержка асинхронного вызова

Из книги Практика и проблематика моделирования бизнес-процессов автора Всяких Е И

Поддержка асинхронного вызова Поддержка асинхронного вызова Web-методов в .NET 2.0 сильно изменилась по сравнению с .NET 1.x. По своему предыдущему опыту вы можете знать, что агенты .NET 1.1 использовали методы BeginXXX()/EndXXX() для вызова Web-методов во вторичном потоке выполнения.


1.1.5. Функции обратного вызова

Из книги Linux: Полное руководство автора Колисниченко Денис Николаевич

1.1.5. Функции обратного вызова Прежде чем двигаться дальше, необходимо разобраться с тем, что такое функции обратного вызова (callback functions: этот термин иногда также переводят "функции косвенного вызова"). Эти функции в программе описываются, но обычно не вызываются напрямую,


16.14. Сервер kHTTPd — веб-сервер уровня ядра

Из книги Операционная система UNIX автора Робачевский Андрей М.

16.14. Сервер kHTTPd — веб-сервер уровня ядра В операционной системе все процессы можно разделить на два типа: процессы уровня ядра и пользовательские процессы. Процесс уровня ядра запускается и работает очень быстро по сравнению с относительно неповоротливым


Семантика вызова

Из книги C++ для начинающих автора Липпман Стенли

Семантика вызова Вызов локальной процедуры однозначно приводит к ее выполнению, после чего управление возвращается в головную программу. Иначе дело обстоит при вызове удаленной процедуры. Невозможно установить, когда конкретно будет выполняться процедура, будет ли она


15.5. Оператор вызова функции

Из книги UNIX: разработка сетевых приложений автора Стивенс Уильям Ричард

15.5. Оператор вызова функции Оператор вызова функции может быть перегружен для объектов типа класса. (Мы уже видели, как он используется, при рассмотрении объектов-функций в разделе 12.3.) Если определен класс, представляющий некоторую операцию, то для ее вызова


4.6. Функция accept

Из книги автора

4.6. Функция accept Функция accept вызывается сервером TCP для возвращения следующего установленного соединения из начала очереди полностью установленных соединений (см. рис. 4.2). Если очередь полностью установленных соединений пуста, процесс переходит в состояние ожидания (по


5.11. Прерывание соединения перед завершением функции accept

Из книги автора

5.11. Прерывание соединения перед завершением функции accept Существует другое условие, аналогичное прерванному системному вызову, пример которого был описан в предыдущем разделе. Оно может привести к возвращению функцией accept нефатальной ошибки, в случае чего следует


16.6. Неблокируемая функция accept

Из книги автора

16.6. Неблокируемая функция accept Как было сказано в главе 6, функция select сообщает, что прослушиваемый сокет готов для чтения, когда установленное соединение готово к обработке функцией accept. Следовательно, если мы используем функцию select для определения готовности входящих


30.7. Сервер TCP с предварительным порождением процессов и защитой вызова accept блокировкой файла

Из книги автора

30.7. Сервер TCP с предварительным порождением процессов и защитой вызова accept блокировкой файла Описанная выше реализация, позволяющая нескольким процессам вызывать функцию accept на одном и том же прослушиваемом дескрипторе, возможна только для систем 4.4BSD, в которых функция


30.8. Сервер TCP с предварительным порождением процессов и защитой вызова accept при помощи взаимного исключения

Из книги автора

30.8. Сервер TCP с предварительным порождением процессов и защитой вызова accept при помощи взаимного исключения Как мы уже говорили, существует несколько способов синхронизации процессов путем блокирования. Блокировка файла по стандарту POSIX, рассмотренная в предыдущем


30.9. Сервер TCP с предварительным порождением процессов: передача дескриптора

Из книги автора

30.9. Сервер TCP с предварительным порождением процессов: передача дескриптора Последней модификацией нашего сервера с предварительным порождением процессов является версия, в которой только родительский процесс вызывает функцию accept, а затем «передает» присоединенный


30.11. Сервер TCP с предварительным порождением потоков, каждый из которых вызывает accept

Из книги автора

30.11. Сервер TCP с предварительным порождением потоков, каждый из которых вызывает accept Ранее в этой главе мы обнаружили, что версии, в которых заранее создается пул дочерних процессов, работают быстрее, чем те, в которых для каждого клиентского запроса приходится вызывать


30.12. Сервер с предварительным порождением потоков: основной поток вызывает функцию accept

Из книги автора

30.12. Сервер с предварительным порождением потоков: основной поток вызывает функцию accept Последняя рассматриваемая нами версия сервера устроена следующим образом: главный поток создает пул потоков при запуске сервера, после чего он же вызывает функцию accept и передает