73 n = Recvfrom(sockfd, mesg, MAXLINE, 0, pcliaddr, &len);
74 printf("child %d, datagram from %s", getpid,
75 Sock_ntop(pcliaddr, len));
76 printf(", to %s\n", Sock_ntop(myaddr, clilen));
77 Sendto(sockfd, mesg, n, 0, pcliaddr, len);
78 }
79 }
Новый
аргумент
65-66
Четвертым аргументом этой функции является IP-адрес, связанный с сокетом. Этот сокет должен получать только дейтаграммы, предназначенные для данного IP-адреса. Если IP-адрес является универсальным, сокет должен получать только те дейтаграммы, которые не подходят ни для какого другого сокета, связанного с тем же портом.
Чтение дейтаграммы и отражение ответа
71-78
Дейтаграмма читается с помощью функции
recvfrom
и отправляется клиенту обратно с помощью функции
sendto
. Эта функция также выводит IP-адрес клиента и IP-адрес, который был связан с сокетом.
Запустим эту программу на нашем узле
solaris
после установки псевдонима для интерфейса
hme0
Ethernet. Адрес псевдонима: узел 200 в сети 10.0.0/24.
solaris % udpserv03
bound 127.0.0.1:9877 интерфейс закольцовки
bound 10.0.0.200:9877 направленный адрес интерфейса hme0:1
bound 10.0.0.255:9877 широковещательный адрес интерфейса hme0:1
bound 192.168.1.20:9877 направленный адрес интерфейса hme0
bound 192.168.1.255:9877 широковещательный адрес интерфейса hme0
bound 0.0.0.0.9877 универсальный адрес
При помощи утилиты
netstat
мы можем проверить, что все сокеты связаны с указанными IP-адресами и портом:
solaris % netstat -na | grep 9877
127.0.0.1.9877 Idle
10.0.0.200.9877 Idle
*.9877 Idle
192.129.100.100.9877 Idle
*.9877 Idle
*.9877 Idle
Следует отметить, что для простоты мы создаем по одному дочернему процессу на сокет, хотя возможны другие варианты. Например, чтобы ограничить число процессов, программа может управлять всеми дескрипторами сама, используя функцию
select
и не вызывая функцию
fork
. Проблема в данном случае будет заключаться в усложнении кода. Хотя использовать функцию
select
для всех дескрипторов несложно, нам придется осуществить некоторое сопоставление каждого дескриптора связанному с ним IP-адресу (вероятно, с помощью массива структур), чтобы иметь возможность вывести IP-адрес получателя после того, как на определенном сокете получена дейтаграмма. Часто бывает проще использовать отдельный процесс или поток для каждой операции или дескриптора вместо мультиплексирования множества различных операций или дескрипторов одним процессом.
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 показаны все шаги.