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

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

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

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

В данном примере для каждого дочернего процесса нам нужна некая структура, содержащая информацию о нем. Заголовочный файл child.h, в котором определяется структура Child, показан в листинге 30.16.

Листинг 30.16. Структура Child

//server/child.h

1 typedef struct {

2  pid_t child_pid;  /* ID процесса */

3  int child_pipefd; /* программный (неименованный) канал между

                        родительским и дочерним процессами */

4  int child_status; /* 0 = готово */

5  long child_count; /* количество обрабатываемых соединений */

6 } Child;

7 Child *cptr; /* массив структур Child */

Мы записываем идентификатор дочернего процесса, дескриптор программного канала (pipe) родительского процесса, связанного с дочерним, статус дочернего процесса и количество обрабатываемых дочерним процессом клиентских соединений. Это количество выводится обработчиком сигнала SIGINT и позволяет нам отслеживать распределение клиентских запросов между дочерними процессами.

Рассмотрим сначала функцию child_make, которая приведена в листинге 30.17. Мы создаем канал и доменный сокет Unix (см. главу 14) перед вызовом функции fork. После того, как создан дочерний процесс, родительский процесс закрывает один дескриптор (sockfd[1]), а дочерний процесс закрывает другой дескриптор (sockfd[0]). Более того, дочерний процесс подключает свой дескриптор канала (sockfd[1]) к стандартному потоку сообщений об ошибках, так что каждый дочерний процесс просто использует это устройство для связи с родительским процессом. Этот механизм проиллюстрирован схемой, приведенной на рис. 30.3.

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

//server/child05.c

 1 #include "unp.h"

 2 #include "child.h"

 3 pid_t

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

 5 {

 6  int sockfd[2];

 7  pid_t pid;

 8  void child_main(int, int, int);

 9  Socketpair(AF_LOCAL, SOCK_STREAM, 0, sockfd);

10  if ((pid = Fork()) > 0) {

11   Close(sockfd[1]);

12   cptr[i].child_pid = pid;

13   cptr[i].child_pipefd = sockfd[0];

14   cptr[i].child_status = 0;

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

16  }

17  Dup2(sockfd[1], STDERR_FILENO); /* канал от дочернего процесса к

                                       родительскому */

18  Close(sockfd[0]);

19  Close(sockfd[1]);

20  Close(listenfd); /* дочернему процессу не требуется, чтобы

                        он был открыт */

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

22 }

Рис. 30.3. Канал после того, как дочерний и родительский процесс закрыли один конец

После создания всех дочерних процессов мы получаем схему, показанную на рис. 30.4. Мы закрываем прослушиваемый сокет в каждом дочернем процессе, поскольку только родительский процесс вызывает функцию accept. Мы показываем на рисунке, что родительский процесс должен обрабатывать прослушиваемый сокет, а также все доменные сокеты. Как можно догадаться, родительский процесс использует функцию select для мультиплексирования всех дескрипторов.

Рис. 30.4. Каналы после создания всех дочерних процессов

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

Листинг 30.18. Функция main, использующая передачу дескриптора

//server/serv05.c

 1 #include "unp.h"

 2 #include "child.h"

 3 static int nchildren;

 4 int

 5 main(int argc, char **argv)

 6 {

 7  int listenfd, i, navail, maxfd, nsel, connfd, rc;

 8  void sig_int(int);

 9  pid_t child_make(int, int, int);

10  ssize_t n;

11  fd_set rset, masterset;

12  socklen_t addrlen, clilen;

13  struct sockaddr *cliaddr;

14  if (argc == 3)

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

16  else if (argc == 4)

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

18  else

19   err_quit("usage; serv05 [ <host> ] <port#> <#children>");

20  FD_ZERO(&masterset);

21  FD_SET(listenfd, &masterset);

22  maxfd = listenfd;

23  cliaddr = Malloc(addrlen);

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

25  navail = nchildren;

26  cptr = Calloc(nchildren, sizeof(Child));

27  /* предварительное создание дочерних процессов */

28  for (i = 0; i < nchildren; i++) {

29   child_make(i, listenfd, addrlen); /* родительский процесс

                                          завершается */

30   FD_SET(cptr[i].child_pipefd, &masterset);

31   maxfd = max(maxfd, cptr[i].child_pipefd);

32  }

33  Signal(SIGINT, sig_int);

34  for (;;) {

35   rset = masterset;

36   if (navail <= 0)

37    FD_CLR(listenfd, &rset); /* выключаем, если нет свободных

                                  дочерних процессов */

38   nsel = Select(maxfd + 1, &rset, NULL, NULL, NULL);

39   /* проверка новых соединений */

40   if (FD_ISSET(listenfd, &rset)) {

41    clilen = addrlen;

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

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

44     if (cptr[i].child_status == 0)

45      break; /* свободный */

46    if (i == nchildren)

47     err_quit("no available children");

48    cptr[i].child_status = 1; /* отмечаем этот дочерний процесс как

                                   занятый */

49    cptr[i].child_count++;

50    navail--;

51    n = Write_fd(cptr[i].child_pipefd, 1, connfd);

52    Close(connfd);

53    if (--nsel == 0)

54     continue; /* с результатами select() закончено */

55   }

56   /* поиск освободившихся дочерних процессов */

57   for (i = 0; i < nchildren; i++) {

58    if (FD_ISSET(cptr[i].child_pipefd, &rset)) {

59     if ((n = Read(cptr[i].child_pipefd, &rc, 1)) == 0)

60      err_quit("child %d terminated unexpectedly", i);

61     cptr[i].child_status = 0;

62     navail++;

63     if (--nsel == 0)

64      break; /* с результатами select() закончено */

65    }

66   }

67  }

68 }

Отключение прослушиваемого сокета в случае отсутствия свободных дочерних процессов

36-37 Счетчик navail отслеживает количество свободных дочерних процессов. Если его значение становится равным нулю, прослушиваемый сокет в наборе дескрипторов функции select выключается. Это предотвращает прием нового соединения в тот момент, когда нет ни одного свободного дочернего процесса. Ядро по- прежнему устанавливает эти соединения в очередь, пока их количество не превысит значения аргумента backlog функции listen, заданного для прослушиваемого сокета, но мы не хотим их принимать, пока у нас не появится свободный дочерний процесс, готовый обрабатывать клиентский запрос.

Прием нового соединения

39-55 Если прослушиваемый сокет готов для считывания, можно принимать (accept) новое соединение. Мы находим первый свободный дочерний процесс и передаем ему присоединенный сокет с помощью функции write_fd, приведенной в листинге 15.11. Вместе с дескриптором мы передаем 1 байт, но получатель не интересуется содержимым этого байта. Родитель закрывает присоединенный сокет.

Мы всегда начинаем поиск свободного дочернего процесса с первого элемента массива структур Child. Это означает, что новое соединение для обработки поступившего клиентского запроса всегда получает первый элемент этого массива. Этот факт мы проверим при рассмотрении табл. 30.2 и значения счетчика child_count после завершения работы сервера. Если мы не хотим оказывать такое предпочтение первому элементу массива, мы можем запомнить, какой дочерний процесс получил последнее клиентское соединение, и каждый раз начинать поиск свободного дочернего процесса со следующего за ним, а по достижении конца массива переходить снова к первому элементу. В этом нет особого смысла (на самом деле все равно, какой дочерний процесс обрабатывает очередное соединение, если имеется несколько свободных дочерних процессов), если только планировочный алгоритм операционной системы не накладывает санкций на процессы, которые требуют относительно больших временных затрат центрального процессора. Более равномерное распределение загрузки между всеми дочерними процессами приведет к выравниванию времен, затраченных на их выполнение.

Обработка вновь освободившихся дочерних процессов

56-66 Когда дочерний процесс заканчивает обработку клиентского запроса, наша функция child_main записывает один байт в канал для родительского процесса. Тем самым родительский конец канала становится доступным для чтения. Упомянутый байт считывается (но его значение при этом игнорируется), а дочерний процесс помечается как свободный. Если же дочерний процесс завершит свое выполнение неожиданно, его конец канала будет закрыт, а операция чтения (read) возвратит нулевое значение. Это значение перехватывается и дочерний процесс завершается, но более удачным решением было бы записать ошибку и создать новый дочерний процесс для замены завершенного.

Функция child_main показана в листинге 30.19.

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

//server/child05.c

23 void

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

25 {

26  char c;

27  int connfd;

28  ssize_t n;

29  void web_child(int);

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

31  for (;;) {

32   if ((n = Read_fd(STDERR_FILENO, &c, 1, &connfd)) == 0)

33    err_quit("read_fd returned 0");

34   if (connfd < 0)

35    err_quit("no descriptor from read_fd");

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

37   Close(connfd);

38   Write(STDERR_FILENO, "", 1); /* сообщаем родительскому процессу

                                     о том, что дочерний освободился */

39  }

40 }

Ожидание дескриптора от родительского процесса

32-33 Эта функция отличается от аналогичных функций из двух предыдущих разделов, так как дочерний процесс не вызывает более функцию accept. Вместо этого дочерний процесс блокируется в вызове функции read_fd, ожидая, когда родительский процесс передаст ему дескриптор присоединенного сокета.

Сообщение родительскому процессу о готовности дочернего к приему новых запросов

38 Закончив обработку очередного клиентского запроса, мы записываем (write) 1 байт в канал, чтобы сообщить, что данный дочерний процесс освободился.

В табл. 30.1 при сравнении строк 4 и 5 мы видим, что данный сервер медленнее, чем версия, рассмотренная нами в предыдущем разделе, которая использовала блокировку потоками взаимного исключения. Передача дескриптора по каналу от родительского процесса к дочернему и запись одного байта в канал для сообщения родительскому процессу о завершении обработки клиентского запроса занимает больше времени, чем блокирование и разблокирование взаимного исключения или файла.

В табл. 30.2 показаны значения счетчиков child_count из структуры Child, которые выводятся обработчиком сигнала SIGINT по завершении работы сервера. Дочерние процессы, расположенные ближе к началу массива, обрабатывают большее количество клиентских запросов, как было указано при обсуждении листинга 30.18.

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

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

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

Инициализация дескриптора безопасности

Из книги Системное программирование в среде Windows автора Харт Джонсон М

Инициализация дескриптора безопасности Сначала необходимо инициализировать дескриптор безопасности с помощью функции InitializeSecurityDescriptor. Параметр pSecurityDescriptor должен указывать адрес действительной структуры SECURITY_DESCRIPTOR. Эти структуры являются непрозрачными для


25.2.3. Получение файлового дескриптора

Из книги Разработка приложений в среде Linux. Второе издание автора Джонсон Майкл К.

25.2.3. Получение файлового дескриптора Помимо возможности использования автоматической блокировки, которую предлагает qdbm, в некоторых программах потребуется изменять их собственную схему блокировки. Для этой цели qdbm обеспечивает доступ к файловому дескриптору, который


Урок № 67. Передача собственных материалов в переработку на сторону и передача продукции из давальческого сырья

Из книги 1С: Бухгалтерия 8 с нуля. 100 уроков для начинающих автора Гладкий Алексей Анатольевич

Урок № 67. Передача собственных материалов в переработку на сторону и передача продукции из давальческого сырья В процессе производственной деятельности предприятия часто приходится осуществлять передачу собственных материалов стороннему переработчику для выпуска


Пример A-5. encryptedpw: Передача файла на ftp-сервер, с использованием пароля

Из книги Искусство программирования на языке сценариев командной оболочки автора Купер Мендель

Пример A-5. encryptedpw: Передача файла на ftp-сервер, с использованием пароля #!/bin/bash# Модификация примера "ex72.sh", добавлено шифрование пароля.# Обратите внимание: этот вариант все еще нельзя считать безопасным,#+ поскольку в сеть пароль уходит в незашифрованном виде.# Используйте


Счетчик ссылок дескриптора

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

Счетчик ссылок дескриптора В конце раздела 4.8 мы отметили, что когда родительский процесс на нашем параллельном сервере закрывает присоединенный сокет с помощью функции close, счетчик ссылок дескриптора уменьшается лишь на единицу. Поскольку счетчик ссылок при этом все


Пример передачи дескриптора

Из книги Разработка ядра Linux автора Лав Роберт

Пример передачи дескриптора Теперь мы представим пример передачи дескриптора. Мы напишем программу под названием mycat, которой в качестве аргумента командной строки передается полное имя файла. Эта программа открывает файл и копирует его в стандартный поток вывода. Но


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


Хранение дескриптора процесса

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

Хранение дескриптора процесса Система идентифицирует процессы с помощью уникального значения, которое называется идентификатором процесса (process identification, PID). Идентификатор PID — это целое число, представленное с помощью скрытого типа pid_t[12] , который обычно соответствует


Удаление дескриптора процесса

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

Удаление дескриптора процесса После возврата из функции do_exit() дескриптор завершенного процесса все еще существует в системе, но процесс находится в состоянии TASK_ZOMBIE и не может выполняться. Как уже рассказывалось выше, это позволяет системе получить информацию о


Выделение дескриптора памяти

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

Выделение дескриптора памяти Указатель на дескриптор памяти, выделенный для какой-либо задачи, хранится в поле mm дескриптора процесса этой задачи. Следовательно, выражение current->mm позволяет получить дескриптор памяти текущего процесса. Функция copy_mm() используется для


Удаление дескриптора памяти

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

Удаление дескриптора памяти Когда процесс, связанный с определенным адресным пространством, завершается, то вызывается функция exit_mm(). Эта функция выполняет некоторые служебные действия и обновляет некоторую статистическую информацию. Далее вызывается функция mput(),