Linux API. Исчерпывающее руководство

/* Обрабатываем клиентский запрос: передаем сокету копию полученного от него ввода */

static void

handleRequest(int cfd)

{

char buf[BUF_SIZE];

ssize_t numRead;

while ((numRead = read(cfd, buf, BUF_SIZE)) > 0) {

if (write(cfd, buf, numRead)!= numRead) {

syslog(LOG_ERR, "write() failed: %s", strerror(errno));

exit(EXIT_FAILURE);

}

}

if (numRead == -1) {

syslog(LOG_ERR, "Error from read(): %s", strerror(errno));

exit(EXIT_FAILURE);

}

}

int

main(int argc, char *argv[])

{

int lfd, cfd; /* Слушающий и подключенный сокеты */

struct sigaction sa;

if (becomeDaemon(0) == -1)

errExit("becomeDaemon");

sigemptyset(&sa.sa_mask);

sa.sa_flags = SA_RESTART;

sa.sa_handler = grimReaper;

if (sigaction(SIGCHLD, &sa, NULL) == -1) {

syslog(LOG_ERR, "Error from sigaction(): %s", strerror(errno));

exit(EXIT_FAILURE);

}

lfd = inetListen(SERVICE, 10, NULL);

if (lfd == -1) {

syslog(LOG_ERR, "Could not create server socket (%s)",

strerror(errno));

exit(EXIT_FAILURE);

}

for (;;) {

cfd = accept(lfd, NULL, NULL); /* Ожидаем соединения */

if (cfd == -1) {

syslog(LOG_ERR, "Failure in accept(): %s", strerror(errno));

exit(EXIT_FAILURE);

}

/* Обрабатываем каждый клиентский запрос в новом дочернем процессе */

switch (fork()) {

case -1:

syslog(LOG_ERR, "Can't create child (%s)", strerror(errno));

close(cfd); /* Отклоняем запрос данного клиента */

break; /* Возможно, это временная проблема;

пробуем следующий запрос */

case 0: /* Потомок */

close(lfd); /* Ненужная копия слушающего сокета */

handleRequest(cfd);

_exit(EXIT_SUCCESS);

default: /* Родитель */

close(cfd); /* Ненужная копия подключенного сокета */

break; /* Повторяем цикл, чтобы принять следующее соединение */

}

}

}

sockets/is_echo_sv.c

56.4. Другие разновидности архитектуры параллельного сервера

Традиционная модель параллелизма, описанная в предыдущем разделе, подходит для многих приложений, которым нужно одновременно обрабатывать несколько клиентов, подключенных по TCP. Однако в высоконагруженных серверах (например, в веб-серверах, обрабатывающих тысячи запросов в минуту) создание нового дочернего процесса (или даже потока) для каждого клиента является довольно затратным (см. раздел 28.3). В этом случае требуются альтернативные подходы, и часть из них мы кратко рассмотрим ниже.

Серверы с пулом готовых процессов или потоков

Серверы с пулом готовых процессов или потоков подробно описываются в главе 30 книги [Stevens et al., 2004]. Их ключевая идея состоит в следующем.

• Вместо создания нового потомка (или потока) для каждого клиента сервер заранее, во время запуска (то есть до того, как начать прием клиентских запросов), создает определенное количество дочерних процессов (или потоков). Эти потомки формируют так называемый серверный пул (от англ. pool — «резервуар»).

• Каждый потомок в данном пуле обслуживает по одному клиенту за раз. Когда обслуживание окончено, потомок не завершается, а переходит к следующему клиенту и повторяет процедуру.

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

Кроме того, потомки в пуле должны соблюдать некий протокол, позволяющий им полностью брать на себя обслуживание отдельных клиентских соединений. В большинстве UNIX-систем (включая Linux) для этого достаточно сделать так, чтобы потомок блокировался на время вызова accept() для слушающего дескриптора. Иными словами, родительский процесс сервера создает слушающий сокет до создания любого потомка; притом в результате вызова fork() каждый из участников серверного пула наследует файловый дескриптор сокета. Когда появится новое клиентское соединение, только один из потомков завершит выполнение операции accept(). Но, поскольку в некоторых старых реализациях системный вызов accept() не является атомарным, к нему, возможно, придется применить механизм взаимного исключения (например, файловую блокировку). Это послужит гарантией того, что данная операция будет выполняться последовательно каждым дочерним процессом ([Stevens et al., 2004]).