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

В листинге 30.2 показана функция main для нашего параллельного сервера TCP.

Листинг 30.2. Функция main для параллельного сервера TCP

//server/serv01.c

 1 include "unp.h"

 2 int

 3 main(int argc, char **argv)

 4 {

 5  int listenfd, connfd;

 6  pid_t childpid;

 7  void sig_chld(int), sig_int(int), web_child(int);

 8  socklen_t clilen, addrlen;

 9  struct sockaddr *cliaddr;

10  if (argc == 2)

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

12  else if (argc == 3)

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

14  else

15   err_quit("usage: serv01 [ <host> ] <port#>");

16  cliaddr = Malloc(addrlen);

17  Signal(SIGCHLD, sig_chld);

18  Signal(SIGINT, sig_int);

19  for (;;) {

20   clilen = addrlen;

21   if ((connfd = accept(listenfd, cliaddr, &clilen)) < 0) {

22    if (errno == EINTR)

23     continue; /* назад к for() */

24    else

25     err_sys("accept error");

26   }

27   if ((childpid = Fork()) == 0) { /* дочерний процесс */

28    Close(listenfd); /* закрываем прослушиваемый сокет */

29    web_child(connfd); /* обрабатываем запрос */

30    exit(0);

31   }

32   Close(connfd); /* родительский процесс закрывает

                       присоединенный сокет */

33  }

34 }

Эта функция аналогична функции, показанной в листинге 5.9: она вызывает функцию fork для каждого клиентского соединения и обрабатывает сигналы SIGCHLD, приходящие от закончивших свое выполнение дочерних процессов. Тем не менее мы сделали эту функцию не зависящей от протокола за счет вызова функции tcp_listen. Мы не показываем обработчик сигнала sig_chld: он совпадает с показанным в листинге 5.8, но только без функции printf.

Мы также перехватываем сигнал SIGINT, который генерируется при вводе символа прерывания. Мы вводим этот символ после завершения работы клиента, чтобы было выведено время, потраченное центральным процессором на выполнение данной программы. В листинге 30.3 показан обработчик сигнала. Это пример обработчика сигнала, который никогда не возвращает управление.

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

//server/serv01.c

35 void

36 sig_int(int signo)

37 {

38  void pr_cpu_time(void);

39  pr_cpu_time();

40  exit(0);

41 }

В листинге 30.4 показана функция pr_cpu_time, вызываемая из обработчика сигнала.

Листинг 30.4. Функция pr_cpu_time: вывод полного времени центрального процессора

//server/pr_cpu_time.c

 1 #include "unp.h"

 2 #include <sys/resource.h>

 3 #ifndef HAVE_GETRUSAGE_PROTO

 4 int getrusage(int, struct rusage*);

 5 #endif

 6 void

 7 pr_cpu_time(void)

 8 {

 9  double user, sys;

10  struct rusage myusage, childusage;

11  if (getrusage(RUSAGE_SELF, &myusage) < 0)

12   err_sys("getrusage error");

13  if (getrusage(RUSAGE_CHILDREN, &childusage) < 0)

14   err_sys("getrusage error");

15  user = (double)myusage.ru_utime.tv_sec +

16   myusage.ru_utime.tv_usec / 1000000.0;

17  user += (double)childusage.ru_utime.tv_sec +

18   childusage.ru_utime.tv_usec / 1000000.0;

19  sys = (double)myusage.ru_stime.tv_sec +

20   myusage.ru_stime.tv_usec / 1000000.0;

21  sys += (double)childusage.ru_stime.tv_sec +

22   childusage.ru_stime.tv_usec / 1000000.0;

21  printf("nuser time = %g, sys time = %gn", user, sys);

22 }

Функция getrusage вызывается дважды: она позволяет получить данные об использовании ресурсов вызывающим процессом (RUSAGE_SELF) и всеми его дочерними процессами, которые завершили свое выполнение (RUSAGE_CHILDREN). Выводится время, затраченное центральным процессором на выполнение пользовательского процесса (общее пользовательское время, total user time), и время, которое центральный процессор затратил внутри ядра на выполнение задач, заданных вызывающим процессом (общее системное время, total system time).

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

Листинг 30.5. Функция web_child: обработка каждого клиентского запроса

//server/web_child.c

 1 #include "unp.h"

 2 #define MAXN 16384 /* максимальное количество байтов, которое клиент

может запросить */

 3 void

 4 web_child(int sockfd)

 5 {

 6  int ntowrite;

 7  ssize_t nread;

 8  char line[MAXLINE], result[MAXN];

 9  for (;;) {

10   if ((nread = Readline(sockfd, line, MAXLINE)) == 0)

11    return; /* соединение закрыто другим концом */

12   /* line задает, сколько байтов следует отправлять обратно */

13   ntowrite = atol(line);

14   if ((ntowrite <= 0) || (ntowrite > MAXN))

15    err_quit("client request for bytes", ntowrite);

16   Writen(sockfd, result, ntowrite);

17  }

18 }

Установив соединение с сервером, клиент записывает одну строку, задающую количество байтов, которое сервер должен вернуть. Это отчасти похоже на HTTP: клиент отправляет небольшой запрос, а сервер в ответ отправляет требуемую информацию (часто это файл HTML или изображение GIF). В случае HTTP сервер обычно закрывает соединение после отправки клиенту затребованных данных, хотя более новые версии используют постоянные соединения (persistent connection), оставляя соединения TCP открытыми для дополнительных клиентских запросов. В нашей функции web_child сервер допускает дополнительные запросы от клиента, но, как мы видели в листинге 24.1, клиент посылает серверу только по одному запросу на каждое соединение, а по получении ответа от сервера это соединение закрывается.

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

Один из способов устройства сервера, который мы не рассматриваем в этой главе, — это сервер, инициируемый демоном inetd (см. раздел 13.5). С точки зрения управления процессами такой сервер подразумевает использование функций fork и exec, так что затраты времени центрального процессора будут еще больше, чем показанные в строке 1 для параллельного сервера.

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

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

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

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

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