Мы создаем два сокета, один для отправки и один для получения. Нам нужно, чтобы принимающий сокет связался при помощи функции bind
с группой и портом, допустим 239.255.1.2, порт 8888. (Вспомните, что мы могли просто связать универсальный IP-адрес и порт 8888, но связывание с определенным адресом многоадресной передачи предотвращает получение сокетом других дейтаграмм, которые могут прийти на порт получателя 8888.) Далее, нам нужно, чтобы принимающий сокет присоединился к группе. Отправляющий сокет будет отправлять дейтаграммы на этот же адрес многоадресной передачи и этот же порт, то есть на 239.255.1.2, порт 8888. Но если мы попытаемся использовать один сокет и для отправки, и для получения, то адресом отправителя для функции bind
будет 239.255.1.2.8888 (здесь используется нотация netstat
), а адресом получателя для функции sendto
— также 239.255.1.2.8888. Но адрес отправителя, связанный с сокетом, становится IP-адресом отправителя дейтаграммы UDP, a RFC 1122 [10] запрещает дейтаграмме IP иметь IP-адрес отправителя, являющийся адресом многоадресной или широковещательной передачи. (См. также упражнение 21.2.) Следовательно, мы создаем два сокета: один для отправки, другой для получения.
13
Наша функция udp_client
создает отправляющий сокет, обрабатывая два аргумента командной строки, которые задают адрес многоадресной передачи и номер порта. Эта функция также возвращает структуру адреса сокета, готовую к вызовам функции sendto
, и длину этой структуры.
14-18
Мы создаем принимающий сокет, используя то же семейство адресов, что и при создании отправляющего сокета, и устанавливаем параметр сокета SO_REUSEADDR
, чтобы разрешить множеству экземпляров этой программы одновременно запускаться на узле. Затем мы выделяем в памяти пространство для структуры адреса этого сокета, копируем ее содержимое из структуры адреса отправляющего сокета (адрес и порт которого взяты из аргументов командной строки) и при помощи функции bind
связываем адрес многоадресной передачи и порт с принимающим сокетом.
19-20
Мы вызываем нашу функцию mcast_join
, чтобы присоединиться к группе на получающем сокете, а также нашу функцию mcast_set_loop
, чтобы отключить закольцовку на отправляющем сокете. Для присоединения задаем имя интерфейса в виде пустого указателя и нулевой индекс интерфейса, что указывает ядру на необходимость выбрать интерфейс самостоятельно.
21-23
Мы вызываем функцию fork
, после чего дочерним процессом становится получающий цикл, а родительским — отправляющий.
Наша функция sendmail
, отправляющая по одной дейтаграмме многоадресной передачи каждые 5 с, показана в листинге 21.9. Функция main
передает в качестве аргументов дескриптор сокета, указатель на структуру адреса сокета, содержащую адрес получателя многоадресной передачи и порт, и длину структуры.
Листинг 21.9. Отправка дейтаграммы многоадресной передачи каждые 5 с
//mcast/send.c
1 #include "unp.h"
2 #include
3 #define SENDRATE 5 /* отправка дейтаграмм каждые 5 с */
4 void
5 send_all(int sendfd, SA *sadest, socklen_t salen)
6 {
7 static char line[MAXLINE]; /* имя узла и идентификатор процесса */
8 struct utsname myname;
9 if (uname(&myname) < 0)
10 err_sys("uname error");
11 snprintf(line, sizeof(line), "%s, %d\n", myname, nodename, getpid());
12 for (;;) {
13 Sendto(sendfd, line, strlen(line), 0, sadest, salen);
14 sleep(SENDRATE);
15 }
16 }
9-11
Мы получаем имя узла из функции uname
и создаем строку вывода, содержащую это имя и идентификатор процесса.
12-15
Мы отправляем дейтаграмму и с помощью функции sleep
переходим в состояние ожидания на 5 с.
Функция recv_all
, содержащая бесконечный цикл получения, показана в листинге 21.10.
Листинг 21.10. Получение всех дейтаграмм многоадресной передачи для группы, к которой мы присоединились
//mcast/recv.c
1 #include "unp.h"
2 void
3 recv_all(int recvfd, socklen_t salen)
4 {
5 int n;
6 char line[MAXLINE + 1];
7 socklen_t len;
8 struct sockaddr *safrom;