Уильям Стивенс - UNIX: разработка сетевых приложений

Заключительная часть функции mainпоказана в листинге 22.15. В этом коде при помощи функции bindпроисходит связывание с универсальным адресом для обработки любого адреса получателя, отличного от адресов направленной и широковещательной передачи, которые уже связаны. На этот сокет будут приходить только дейтаграммы, предназначенные для ограниченного широковещательного адреса (255.255.255.255).

Листинг 22.15. Заключительная часть сервера UDP, связывающегося со всеми адресами

//advio/udpserv03.c

50 /* связываем универсальный адрес */

51 sockfd = Socket(AF_INET, SOCK_DGRAM, 0);

52 Setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));

53 bzero(&wildaddr, sizeof(wildaddr));

54 wildaddr.sin_family = AF_INET;

55 wildaddr.sin_addr.s_addr = htonl(INADDR_ANY);

56 wildaddr.sin_port = htons(SERV_PORT);

57 Bind(sockfd, (SA*)&wildaddr, sizeof(wildaddr));

58 printf("bound %s\n", Sock_ntop((SA*)&wildaddr, sizeof(wildaddr)));

59 if ((pid = Fork()) == 0) { /* дочерний процесс */

60 mydg_echo(sockfd, (SA*)&cliaddr, sizeof(cliaddr), (SA*)sa);

61 exit(0); /* не выполняется */

62 }

63 exit(0);

64 }

50-62 Создается сокет UDP, устанавливается параметр сокета SO_REUSEADDRи происходит связывание с универсальным IP-адресом. Порождается дочерний процесс, вызывающий функцию mydg_echo.

63 Функция mainзавершается, и сервер продолжает выполнять работу, как и все порожденные дочерние процессы.

Функция mydg_echo, которая выполняется всеми дочерними процессами, показана в листинге 22.16.

Листинг 22.16. Функция mydg_echo

//advio/udpserv03.c

65 void

66 mydg_echo(int sockfd, SA *pcliaddr, socklen_t clilen, SA *myaddr)

67 {

68 int n;

69 char mesg[MAXLINE];

70 socklen_t len;

71 for (;;) {

72 len = clilen;

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после установки псевдонима для интерфейса hme0Ethernet. Адрес псевдонима: узел 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-адрес получателя после того, как на определенном сокете получена дейтаграмма. Часто бывает проще использовать отдельный процесс или поток для каждой операции или дескриптора вместо мультиплексирования множества различных операций или дескрипторов одним процессом.

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

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

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

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

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