Книга: UNIX: разработка сетевых приложений

4.8. Параллельные серверы

4.8. Параллельные серверы

Сервер, представленный в листинге 4.2, является последовательным (итеративным) сервером. Для такого простого сервера, как сервер времени и даты, это допустимо. Но когда обработка запроса клиента занимает больше времени, мы не можем связывать один сервер с одним клиентом, поскольку нам хотелось бы обрабатывать множество клиентов одновременно. Простейшим способом написать параллельный сервер под Unix является вызов функции fork, порождающей дочерний процесс для каждого клиента. В листинге 4.3 представлена общая схема типичного параллельного сервера.

Листинг 4.3. Типичный параллельный сервер

pid_t pid;
int listenfd, connfd;
listenfd = Socket( ... );
/* записываем в sockaddr_in{} параметры заранее известного порта сервера */
Bind(listenfd, ... );
Listen(listenfd, LISTENQ);
for (;;) {
 connfd = Accept(listenfd, ...); /* вероятно, блокировка */
 if ((pid = Fork() == 0) {
  Close(listenfd); /* дочерний процесс закрывает
                      прослушиваемый сокет */
  doit(connfd);    /* обработка запроса */
  Close(connfd);   /* с этим клиентом закончено */
  exit(0);         /* дочерний процесс завершен */
 }
 Close(connfd);    /* родительский процесс закрывает
                      присоединенный сокет */
}

Когда соединение установлено, функция accept возвращает управление, сервер вызывает функцию fork и затем дочерний процесс занимается обслуживанием клиента (по присоединенному сокету connfd), а родительский процесс ждет другого соединения (на прослушиваемом сокете listenfd). Родительский процесс закрывает присоединенный сокет, поскольку новый клиент обрабатывается дочерним процессом.

Мы предполагаем, что функция doit в листинге 4.3 выполняет все, что требуется для обслуживания клиента. Когда эта функция возвращает управление, мы явно закрываем присоединенный сокет с помощью функции close в дочернем процессе. Делать это не обязательно, так как в следующей строке вызывается exit, а прекращение процесса подразумевает, в частности, закрытие ядром всех открытых дескрипторов. Включать явный вызов функции close или нет — дело вкуса программиста.

В разделе 2.6 мы сказали, что вызов функции close на сокете TCP вызывает отправку сегмента FIN, за которой следует обычная последовательность прекращения соединения TCP. Почему же функция close(connfd) из листинга 4.3, вызванная родительским процессом, не завершает соединение с клиентом? Чтобы понять происходящее, мы должны учитывать, что у каждого файла и сокета есть счетчик ссылок (reference count). Для счетчика ссылок поддерживается своя запись в таблице файла [110, с. 57–60]. Эта запись содержит значения счетчика дескрипторов, открытых в настоящий момент, которые соответствуют этому файлу или сокету. В листинге 4.3 после завершения функции socket запись в таблице файлов, связанная с listenfd, содержит значение счетчика ссылок, равное 1. Но после завершения функции fork дескрипторы дублируются (для совместного использования и родительским, и дочерним процессом), поэтому записи в таблице файла, ассоциированные с этими сокетами, теперь содержат значение 2. Следовательно, когда родительский процесс закрывает connfd, счетчик ссылок уменьшается с 2 до 1. Но фактического закрытия дескриптора не произойдет, пока счетчик ссылок не станет равен 0. Это случится несколько позже, когда дочерний процесс закроет connfd.

Рассмотрим пример, иллюстрирующий листинг 4.3. Прежде всего, на рис. 4.5 показано состояние клиента и сервера в тот момент, когда сервер блокируется при вызове функции accept и от клиента приходит запрос на соединение.

Рис. 4.5. Состояние соединения клиент-сервер перед завершением вызванной функции accept

Сразу же после завершения функции accept мы получаем сценарий, изображенный на рис. 4.6. Соединение принимается ядром и создается новый сокет — connfd. Это присоединенный сокет, и теперь данные могут считываться и записываться по этому соединению.

Рис. 4.6. Состояние соединения клиент-сервер после завершения функции accept

Следующим действием параллельного сервера является вызов функции fork. На рис. 4.7 показано состояние соединения после вызова функции fork.

Рис. 4.7. Состояние соединения клиент-сервер после вызова функции fork

Обратите внимание, что оба дескриптора listenfd и connfd совместно используются родительским и дочерним процессами.

Далее родительский процесс закрывает присоединенный сокет, а дочерний процесс закрывает прослушиваемый сокет. Это показано на рис. 4.8.

Рис. 4.8. Состояние соединения клиент-сервер после закрытия родительским и дочерним процессами соответствующих сокетов

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

Оглавление книги