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

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

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

Определение «длительное время» означает, что другой клиент вынужден ждать в течение некоторого заметного для него промежутка времени, пока обслуживается текущий клиент. Например, если два клиентских запроса приходят в течение 10 мс и предоставление сервиса каждому клиенту занимает в среднем 5 с, то второй клиент будет вынужден ждать ответа около 10 с вместо 5 с (если бы запрос был принят в обработку сразу же по прибытии).

В случае TCP проблема решается просто — требуется лишь породить дочерний процесс с помощью функции fork (или создать новый поток, что мы увидим в главе 23) и дать возможность дочернему процессу выполнять обработку нового клиента. При использовании TCP ситуация существенно упрощается за счет того, что каждое клиентское соединение уникально: пара сокетов TCP уникальна для каждого соединения. Но в случае с UDP мы вынуждены рассматривать два различных типа серверов.

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

2. Второй тип — сервер UDP, обменивающийся множеством дейтаграмм с клиентом. Проблема здесь в том, что единственный номер порта сервера, известный клиенту, — это номер заранее известного порта. Клиент посылает первую дейтаграмму своего запроса на этот порт, но как сервер сможет отличить последующие дейтаграммы этого клиента от запросов новых клиентов? Типичным решением этой проблемы для сервера будет создание нового сокета для каждого клиента, связывание при помощи функции bind динамически назначаемого порта с этим сокетом и использование этого сокета для всех своих ответов. При этом требуется, чтобы клиент запомнил номер порта, с которого был отправлен первый ответ сервера, и отправлял последующие дейтаграммы уже на этот порт.

Примером второго типа сервера UDP является сервер TFTP (Trivial File Transfer Protocol — упрощенный протокол передачи файлов). Передача файла с помощью TFTP обычно требует большого числа дейтаграмм (сотен или тысяч, в зависимости от размера файла), поскольку этот протокол отправляет в одной дейтаграмме только 512 байт. Клиент отправляет дейтаграмму на известный порт сервера (69), указывая, какой файл нужно отправить или получить. Сервер читает запрос, но отправляет ответ с другого сокета, который он создает и связывает с динамически назначаемым портом. Все последующие дейтаграммы между клиентом и сервером используют для передачи этого файла новый сокет. Это позволяет главному серверу TFTP продолжать обработку других клиентских запросов, приходящих на порт 69, в то время как происходит передача файла (возможно, в течение нескольких секунд или даже минут).

Если мы рассмотрим автономный сервер TFTP (то есть случай, когда не используется демон inetd), то получим сценарий, показанный на рис. 22.3. Мы считаем, что динамически назначаемый порт, связанный дочерним процессом с его новым сокетом, — это порт 2134.

Рис. 22.3. Процессы, происходящие на автономном параллельном UDP-сервере

Если используется демон inetd, сценарий включает еще один шаг. Вспомните из табл. 13.4, что большинство серверов UDP задают аргумент wait-flag как wait. В описании, которое следовало за рис. 13.4, мы сказали, что при указанном значении этого флага демон inetd приостанавливает выполнение функции select на сокете до завершения дочернего процесса, давая возможность этому дочернему процессу считать дейтаграмму, доставленную на сокет. На рис. 22.4 показаны все шаги.

Рис. 22.4. Параллельный сервер UDP, запущенный демоном inetd

Сервер TFTP, являясь дочерним процессом функции inetd, вызывает функцию recvfrom и считывает клиентский запрос. Затем он с помощью функции fork порождает собственный дочерний процесс, и этот дочерний процесс будет обрабатывать клиентский запрос. Затем сервер TFTP вызывает функцию exit, отправляя демону inetd сигнал SIGCHLD, который, как мы сказали, указывает демону inetd снова вызвать функцию select на сокете, связанном с портом UDP 69.

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

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

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

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

Из книги Самоучитель 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, следующем за директивой является отдельной