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 на прослушиваемом сокете, чтобы обрабатывать следующее клиентское соединение.

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

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

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

Параллельные подсостояния

Из книги Самоучитель UML автора Леоненков Александр

Параллельные подсостояния Параллельные подсостояния (concurrent substates) позволяют специфицировать два и более подавтомата, которые могут выполняться параллельно внутри составного события. Каждый из подавтоматов занимает некоторую область (регион) внутри составного


ТЕХНОЛОГИИ: Параллельные вычисления: кластеры

Из книги Журнал «Компьютерра» №46 от 15 декабря 2005 года автора Журнал «Компьютерра»

ТЕХНОЛОГИИ: Параллельные вычисления: кластеры Авторы: Сергей Озеров, Алексей КалиниченкоВершина современной инженерной мысли - сервер Hewlett-Packard Integrity Model SD64A. Огромная SMP-система, объединяющая в себе 64 процессора Intel Itanium 2 с частотой 1,6 ГГц и 256 Гбайт оперативной памяти,


Параллельные миры пересекаются

Из книги Журнал «Компьютерра» № 11 от 20 марта 2007 года автора Журнал «Компьютерра»

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


Глава 5. Параллельные соединения

Из книги Разгони свой сайт автора Мациевский Николай

Глава 5. Параллельные соединения 5.1. Обходим ограничения браузера на число соединений Активное (англ. keep-alive) соединение стало настоящим прорывом в спецификации HTTP 1.1: оно позволяло использовать уже установленный канал для повторной передачи информации от клиента к


Моделируем параллельные запросы

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

Моделируем параллельные запросы На основе заявленных предпосылок можно смоделировать эффективную ширину канала для пользователей, учитывая некоторые сетевые особенности при загрузке объектов различных размеров. Предположим, что каждый HTTP-запрос занимает 500 байтов и


7.3.3. Опасны ли параллельные процессы?

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

7.3.3. Опасны ли параллельные процессы? Хотя Unix-разработчики давно привыкли к вычислениям с помощью взаимодействующих процессов, среди них нет собственной традиции использования параллельных процессов (процессов, которые совместно используют все выделенное им адресное


7.3.3. Опасны ли параллельные процессы?

Из книги Основы объектно-ориентированного программирования автора Мейер Бертран

7.3.3. Опасны ли параллельные процессы? Хотя Unix-разработчики давно привыкли к вычислениям с помощью взаимодействующих процессов, среди них нет собственной традиции использования параллельных процессов (процессов, которые совместно используют все выделенное им адресное


Параллельные иерархии

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

Параллельные иерархии Чтобы не оставить камня на камне, рассмотрим вариант примера SKIER с двумя параллельными иерархиями. Это позволит нам смоделировать ситуацию, уже встречавшуюся на практике: TWO_ WAY_LIST > LINKED_LIST и BI_LINKABLE > LINKABLE; или иерархию с телефонной службой


4.9. Последовательные и параллельные серверы

Из книги OrCAD PSpice. Анализ электрических цепей автора Кеоун Дж.

4.9. Последовательные и параллельные серверы Сервер в нашем простом примере из предыдущего раздела являлся последовательным сервером (iterative server). Он последовательно обрабатывал запросы клиентов, переходя к следующему только после полного завершения работы с предыдущим.


Параллельные ветви на переменном токе

Из книги Инфобизнес на полную мощность [Удвоение продаж] автора Парабеллум Андрей Алексеевич

Параллельные ветви на переменном токе Рассмотрим теперь процессы в параллельной RL-цепи при питании ее от источника переменного тока (рис. 2.5). Рис. 2.5. Схема с параллельной RL-цепьюПараметры компонентов: I=100?0° мА; R=8,33333 Ом; L=6,36 мГн. Для этой цепи необходимо найти напряжение


Параллельные резонансные цепи

Из книги Новый ум короля [О компьютерах, мышлении и законах физики] автора Пенроуз Роджер

Параллельные резонансные цепи Уравнения для анализа параллельной резонансной цепи значительно сложнее уравнений для последовательного колебательного контура. Можно найти полное описание этих уравнений в учебниках. Однако моделирование на PSpice позволяет легко


2.10. Номера портов TCP и параллельные серверы

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

2.10. Номера портов TCP и параллельные серверы Представим себе параллельный сервер, основной цикл которого порождает дочерний процесс для обработки каждого нового соединения. Что случится, если дочерний процесс будет продолжать использовать заранее известный номер порта


22.7. Параллельные серверы UDP

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

22.7. Параллельные серверы UDP Большинство серверов UDP являются последовательными (iterative): сервер ждет запрос клиента, считывает запрос, обрабатывает его, отправляет обратно ответ и затем ждет следующий клиентский запрос. Но когда обработка запроса клиента занимает


Параллельные секции и директива parallel sections

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

Параллельные секции и директива parallel sections Директива parallel sections обеспечивает параллельное выполнение нескольких операторов, простых или составных. {$omp parallel sections} begin секция 1; секция 2; ...; end; Каждый оператор в блоке begin ... end, следующем за директивой является отдельной