UNIX: разработка сетевых приложений — страница 23 из 42

Многоадресная передача

21.1. Введение

Как показано в табл. 20.1, адрес направленной передачи идентифицирует одиночный интерфейс, широковещательный адрес идентифицирует все интерфейсы в подсети, а адрес многоадресной передачи — набор (множество) интерфейсов. Направленная и широковещательная передача — это конечные точки спектра адресации (один интерфейс или все), а цель многоадресной передачи — обеспечить возможность адресации на участок спектра между этими конечными точками. Дейтаграмму многоадресной передачи должны получать только заинтересованные в ней интерфейсы, то есть интерфейсы на тех узлах, на которых запущены приложения, желающие принять участие в сеансе многоадресной передачи. Кроме того, широковещательная передача обычно ограничена локальными сетями, в то время как многоадресная передача может использоваться как в локальной, так и в глобальной сети. Существуют приложения, которые ежедневно участвуют в многоадресной передаче через всю сеть Интернет.

Дополнения к API сокетов, необходимые для поддержки многоадресной передачи, — это девять параметров сокетов. Три из них влияют на отправку дейтаграмм UDP на адрес, а шесть — на получение узлом дейтаграмм многоадресной передачи.

21.2. Адрес многоадресной передачи

При описании адресов многоадресной передачи необходимо провести различия между IPv4 и IPv6.

Адреса IPv4 класса D

Адреса класса D, лежащие в диапазоне от 224.0.0.0 до 239.255.255.255, в IPv4 являются адресами многоадресной передачи (см. табл. А.1). Младшие 28 бит адреса класса D образуют идентификатор группы многоадресной передачи (multicast group ID), а 32-разрядный адрес называется адресом группы (group address).

На рис. 21.1 показано, как адреса многоадресной передачи сопоставляются адресам Ethernet. Сопоставление адресов групп IPv4 для сетей Ethernet описывается в RFC 1112 [26], для сетей FDDI — в RFC 1390 [59], а для сетей типа Token Ring — в RFC 1469 [97]. Чтобы обеспечить возможность сравнения полученных в результате адресов Ethernet, мы также показываем сопоставление для адресов групп Ipv6.

Рис. 21.1. Сопоставление адресам Ethernet адресов многоадресной передачи IPv4 и IPv6

Если рассматривать лишь сопоставление адресов IPv4, то в 24 старших битах адреса Ethernet всегда будет 01:00:5е. Следующий бит всегда нулевой, а 23 младших бита копируются из 23 младших битов группового адреса. Старшие 5 бит группового адреса при сопоставлении игнорируются. Это значит, что 32 групповых адреса сопоставляются одиночному адресу Ethernet, то есть соответствие не является взаимнооднозначным.

Младшие 2 бита первого байта адреса Ethernet идентифицируют адрес как универсально управляемый групповой адрес. «Универсально управляемый» означает то, что 24 старших бита были присвоены IEEE (Institute of Electrical and Electronics Engineers — Институт инженеров по электротехнике и электронике), а групповые адреса многоадресной передачи распознаются и обрабатываются получающими интерфейсами специальным образом.

Существует несколько специальных адресов многоадресной передачи IPv4:

■ 224.0.0.1 — это группа всех узлов (all-hosts group). Все узлы в подсети, имеющие возможность многоадресной передачи, должны присоединиться к этой группе интерфейсами, поддерживающими многоадресную передачу. (Мы поговорим о том, что значит присоединиться к группе, несколько позже.)

■ 224.0.0.2 — это группа всех маршрутизаторов (all-routers group). Все маршрутизаторы многоадресной передачи в подсети должны присоединиться к этой группе интерфейсами, поддерживающими многоадресную передачу.

Диапазон адресов от 224.0.0.0 до 224.0.0.255 (который мы можем также записать в виде 224.0.0.0/24), называется локальным на канальном уровне (link local). Эти адреса предназначены для низкоуровневого определения топологии и служебных протоколов, и дейтаграммы, предназначенные для любого из этих адресов, никогда не передаются маршрутизатором многоадресной передачи дальше. Более подробно об области действия различных групповых адресов IPv4 мы поговорим после того, как рассмотрим адреса многоадресной передачи IPv6.

Адреса многоадресной передачи IPv6

Старший байт адреса многоадресной передачи IPv6 имеет значение ff. На рис. 21.1 показано сопоставление 16-байтового адреса многоадресной передачи IPv6 6-байтовому адресу Ethernet. Младшие 32 бита группового адреса копируются в младшие 32 бита адреса Ethernet. Старшие 2 байта адреса Ethernet имеют значение 33:33. Это сопоставление для сетей Ethernet описано в RFC 2464 [23], то же сопоставление для FDDI — в RFC 2467 [24], а сопоставление для сетей типа Token Ring — в RFC 2470 [25].

Младшие два бита первого байта адреса Ethernet определяют адрес как локально администрируемый групповой адрес. «Локально администрируемый» — это значит, что нет гарантий, что адрес уникален по отношению к IPv6. В этой сети кроме IPv6 могут быть и другие наборы протоколов, использующие те же два старших байта адреса Ethernet. Как мы отмечали ранее, групповые адреса распознаются и обрабатываются получающими интерфейсами специальным образом.

Имеется два формата адресов многоадресной передачи IPv6 (рис. 21.2). Когда флаг P имеет значение 0, флаг T интерпретируется как обозначение принадлежности адреса к группе заранее известных (well-known — значение 0) или к группе временных (transient — значение 1). Если флаг P равен 1, адрес считается назначенным на основе одноадресного префикса (см. RFC 3306 [40]). При этом флаг T также должен иметь значение 1 (многоадресные адреса на основе одноадресных всегда являются временными), а поля plen и prefix устанавливаются равными длине и значению префикса соответственно. Верхние два бита этого поля зарезервированы. Адреса многоадресной передачи IPv6 имеют также 4-разрядное поле области действия (scope), которое будет описано ниже. Документ RFC 3307 [39] описывает механизм выделения младших 32 разрядов группового адреса IPv6 (идентификатора группы) в зависимости от значения флага P.

Рис. 21.2. Формат адресов многоадресной передачи IPv6

Существует несколько специальных адресов многоадресной передачи Ipv6:

■ff02:1 — это группа всех узлов (all-nodes group). Все узлы подсети (компьютеры, маршрутизаторы, принтеры и т.д.), имеющие возможность многоадресной передачи, должны присоединиться к этой группе всеми своими интерфейсами, поддерживающими многоадресную передачу. Этот адрес аналогичен адресу многоадресной передачи IPv4 224.0.0.1. Однако поскольку многоадресная передача является неотъемлемой частью IPv6, присоединение к группе является обязательным (в отличие от IPv4).

ПРИМЕЧАНИЕ

Хотя группа IPv4 называется all-hosts, а группа IPv6 — all-nodes, назначение у них одно и то же. Группа IPv6 была переименована, чтобы подчеркнуть, что в нее должны входить маршрутизаторы, принтеры и любые другие IP-устройства подсети, а не только компьютеры (hosts).

■ff02:2 — группа всех маршрутизаторов (all-routers group). Все маршрутизаторы многоадресной передачи в подсети должны присоединиться к этой группе интерфейсами, поддерживающими многоадресную передачу. Он аналогичен адресу многоадресной передачи IPv4 224.0.0.2.

Область действия адресов многоадресной передачи

Адреса многоадресной передачи IPv6 имеют собственное 4-разрядное поле области действия (scope), определяющее, насколько «далеко» будет передаваться пакет многоадресной передачи. Пакеты IPv6 вообще имеют поле предела количества транзитных узлов, которое ограничивает количество передач через маршрутизаторы (hop limit field). Поле области действия может принимать следующие значения:

■ 1: локальная в пределах узла (node-local);

■ 2: локальная в пределах физической сети (подсети) (link-local);

■ 4: локальная в пределах области администрирования (admin-local);

■ 5: локальная в пределах сайта (site-local);

■ 8: локальная в пределах организации (organization-local);

■ 14: глобальная (global).

Оставшиеся значения — это еще не присвоенные либо зарезервированные значения. Дейтаграмма, локальная в пределах узла, не должна выводиться интерфейсом, а дейтаграмма, локальная в пределах сети, никогда не должна передаваться в другую сеть маршрутизатором. Что понимается под областью администрирования, сайтом или организацией, зависит от администраторов маршрутизаторов многоадресной передачи. Адреса многоадресной передачи IPv6, различающиеся только областью действия, считаются относящимися к разным группам.

В IPv4 нет отдельного поля области действия для многоадресных пакетов. Исторически поле TTL IPv4 в заголовке IP выполняло также роль поля области действия многоадресной передачи: TTL, равное нулю, означает адрес, локальный в пределах узла, 1 — локальный в пределах сети, значения до 32 — локальный в пределах сайта, до 64 — локальный в пределах региона, до 128 — локальный в пределах континента (это означает, что пакеты не передаются по низкоскоростным и загруженным каналам, даже если они проложены в пределах одного континента) и до 255 — неограниченная область действия (глобальный). Двойное использование поля TTL привело к ряду сложностей, подробно описанных в документе RFC 2365 [75].

Хотя использование поля TTL IPv4 для области действия является принятой и рекомендуемой практикой, предпочтительнее административное управление областями действия, если оно возможно. При этом диапазон адресов от 239.0.0.0 до 239.255.255.255 определяется как пространство многоадресной передачи IPv4 с административным ограничением области действия (administratively scoped IPv4 multicast space) [75]. Это верхняя граница пространства адресов многоадресной передачи. Адреса в этом диапазоне задаются организацией локально, но их уникальность за пределами организации не гарантируется. Организация должна настроить свои пограничные маршрутизаторы многоадресной передачи таким образом, чтобы пакеты многоадресной передачи, предназначенные для любого из этих адресов, не передавались вовне.

Административно управляемые адреса многоадресной передачи IPv4 затем делятся на локальную область действия и локальную в пределах организации область действия, первая из которых аналогична (но не является семантическим эквивалентом) области действия IPv6, локальной в пределах сайта. Различные правила определения области действия мы приводим в табл. 21.1.

Таблица 21.1. Область действия адресов многоадресной передачи IPv4 и IPv6

Область действия	Значение поля области действия в IPv6	Значение поля TTL в IPv4	Административное управление областью действия в IPv4
Локальная в пределах узла	1	0
Локальная в пределах сети	2	1	от 224.0.0.0 до 224.0.0.255
Локальная в пределах сайта	5	<32	от 239.255.0.0 до 239.255.255.255
Локальная в пределах организации	8	от 239.192.0.0 до 239.195.255.255
Глобальная	14	<255	от 224.0.1.0 до 238.255.255.255

Сеансы многоадресной передачи

Сочетание адреса многоадресной передачи IPv4 или IPv6 и порта транспортного уровня часто называется сеансом (session), особенно если речь идет о передаче потокового мультимедиа. Например, телеконференция может объединять два сеанса: один аудио- и один видео-. Практически во всех случаях сеансы используют разные порты, а иногда и разные группы, что обеспечивает определенную гибкость для получателей. Например, один клиент может получать только аудиопоток, тогда как другой — аудио- и видео-. Если бы сеансы использовали один и тот же групповой адрес, это было бы невозможно.

21.3. Сравнение многоадресной и широковещательной передачи в локальной сети

Вернемся к примерам, представленным на рис. 20.2 и 20.3, чтобы показать, что происходит в случае многоадресной передачи. В примере, показанном на рис. 21.3, мы будем использовать IPv4, хотя для IPv6 последовательность операций будет такой же.

Рис. 21.3. Пример многоадресной передачи дейтаграммы UDP

Принимающее приложение на узле, изображенном справа, запускается и создает сокет UDP, связывает порт 123 с сокетом и затем присоединяется к группе 224.0.1.1. Мы вскоре увидим, что операция «присоединения» выполняется при помощи вызова функции setsockopt. Когда это происходит, уровень IPv4 сохраняет внутри себя информацию и затем сообщает соответствующему канальному уровню, что нужно получить кадры Ethernet, предназначенные адресу 01:00:5e:00:01:01 (см. раздел 12.11 [128]). Это соответствующий IP-адресу многоадресной передачи адрес Ethernet, к которому приложение только что присоединилось (с учетом сопоставления адресов, показанного на рис. 21.1).

Следующий шаг для отправляющего приложения на узле, изображенном слева, — создание сокета UDP и отправка дейтаграммы на адрес 224.0.1.1, порт 123. Для отправки дейтаграммы многоадресной передачи не требуется никаких специальных действий — приложению не нужно присоединяться к группе. Отправляющий узел преобразует IP-адрес в соответствующий адрес получателя Ethernet, и кадр отправляется. Обратите внимание, что кадр содержит и адрес получателя Ethernet (проверяемый интерфейсами), и IP-адрес получателя (проверяемый уровнями IP).

Мы предполагаем, что узел, изображенный в центре рисунка, не поддерживает многоадресную передачу IPv4 (поскольку поддержка многоадресной передачи IPv4 не обязательна). Узел полностью игнорирует кадр, поскольку, во-первых, адрес получателя Ethernet не совпадает с адресом интерфейса; во-вторых, адрес получателя Ethernet не является широковещательным адресом Ethernet, и в-третьих, интерфейс не получал указания принимать сообщения с адресами многоадресной передачи (то есть адресами, у которых младший бит старшего байта равен 1, как на рис. 21.1).

ПРИМЕЧАНИЕ

Когда интерфейс получает указание принимать кадры, предназначенные для определенного группового адреса Ethernet, многие современные сетевые адаптеры Ethernet применяют к адресу хэш-функцию, вычисляя значение от 0 до 511. Затем один из 512 бит массива устанавливается равным 1. Когда кадр проходит по кабелю, предназначенному для группового адреса, та же хэш-функция применяется интерфейсом к адресу получателя (первое поле в кадре), и снова вычисляется значение от 0 до 511. Если соответствующий бит в массиве установлен, кадр будет получен интерфейсом; иначе он игнорируется. Старые сетевые адаптеры использовали массив размером 64 бита, поэтому вероятность получения ненужных кадров была выше. С течением времени, поскольку все больше и больше приложений используют многоадресную передачу, этот размер, возможно, еще возрастет. Некоторые сетевые карты уже сейчас осуществляют совершенную фильтрацию (perfect filtering). У других карт возможность фильтрации многоадресной передачи отсутствует вовсе, и получая указание принять определенный групповой адрес, они должны принимать все кадры многоадресных передач (иногда это называется режимом смешанной многоадресной передачи). Одна популярная сетевая карта выполняет совершенную фильтрацию для 16 групповых адресов, а также имеет 512-битовую хэш-таблицу. Другая выполняет совершенную фильтрацию для 80 адресов, а остальные обрабатывает в смешанном режиме. Даже если интерфейс выполняет совершенную фильтрацию, все равно требуется совершенная программная фильтрация в пределах IP, поскольку сопоставление групповых адресов IP с аппаратными адресами не является взаимнооднозначным.

Канальный уровень, изображенный справа, получает кадр на основе так называемой несовершенной фильтрации (imperfect filtering), которая выполняется интерфейсом с использованием адреса получателя Ethernet. Мы говорим, что эта фильтрация несовершенна, потому что если интерфейс получает указание принимать кадры, предназначенные для одного определенного группового адреса Ethernet, может случиться так, что он будет получать кадры, предназначенные также для других групповых адресов Ethernet.

Если предположить, что канальный уровень, изображенный справа, получает кадр, то поскольку тип кадра Ethernet — IPv4, пакет передается уровню IP. Поскольку полученный пакет был предназначен IP-адресу многоадресной передачи, уровень IP сравнивает этот адрес со всеми адресами многоадресной передачи, к которым присоединились приложения на узле. Мы называем это совершенной фильтрацией, так как она основана на полном 32-разрядном адресе класса D в заголовке IPv4. В этом примере пакет принимается уровнем IP и передается уровню UDP, который, в свою очередь, передает дейтаграмму сокету, связанному с портом 123.

Существует еще три сценария, не показанных нами на рис. 21.3.

1. На узле запущено приложение, присоединившееся к адресу многоадресной передачи 225.0.1.1. Поскольку 5 верхних битов группового адреса игнорируются при сопоставлении с адресом Ethernet, этот интерфейс узла будет также получать кадры с адресом получателя Ethernet 01:00:5e:00:01:01. В этом случае пакет будет проигнорирован при осуществлении совершенной фильтрации на уровне IP.

2. На узле запущено приложение, присоединившееся к некоторой группе. Соответствующий адрес Ethernet этой группы является одним из тех, которые интерфейс может получить случайно, поскольку он запрограммирован на получение сообщений на адрес 01:00:5e:00:01:01 (то есть сетевая карта выполняет несовершенную фильтрацию). Этот кадр будет проигнорирован либо канальным уровнем, либо уровнем IP.

3. Пакет предназначен для той же группы 224.0.1.1, но для другого порта, скажем 4000. Узел, изображенный справа на рис. 21.3, получает пакет, далее этот пакет принимается уровнем IP, но если не существует сокета, связанного с портом 4000, пакет будет проигнорирован уровнем UDP.

ВНИМАНИЕ

Эти сценарии показывают нам, что для того чтобы процесс мог получать дейтаграммы многоадресной передачи, он должен присоединиться к группе и связаться с портом.

21.4. Многоадресная передача в глобальной сети

Многоадресная передача внутри локальной сети, описанная нами в предыдущем разделе, проста. Один узел посылает пакет многоадресной передачи, и любой заинтересованный узел получает этот пакет. Преимущество многоадресной передачи перед широковещательной состоит в сокращении нагрузки на все узлы, не заинтересованные в получении пакетов многоадресной передачи.

Многоадресная передача имеет преимущества и при работе в глобальных сетях. Рассмотрим глобальную сеть, изображенную на рис. 21.4.

Рис. 21.4. Пять локальных сетей с пятью маршрутизаторами многоадресной передачи

Здесь изображены пять локальных сетей, соединенных пятью маршрутизаторами многоадресной передачи.

Будем считать, что некая программа запущена на пяти из показанных узлов (скажем, программа прослушивания группового аудиосеанса), и эти пять программ присоединяются к данной группе. Тогда каждый из пяти узлов присоединяется к группе. Мы также считаем, что каждый маршрутизатор многоадресной передачи общается с соседними маршрутизаторами многоадресной передачи при помощи протокола маршрутизации многоадресной передачи (multicast routing protocol), который мы обозначим просто MRP. Это показано на рис. 21.5.

Рис. 21.5. Присоединение пяти узлов к группе многоадресной передачи в глобальной сети

Когда процесс на узле присоединяется к группе, этот узел отправляет всем присоединенным к той же сети маршрутизаторам многоадресной передачи сообщение IGMP, информирующее их о том, что узел только что присоединился к группе. Затем маршрутизаторы обмениваются этой информацией по MRP, так что каждый маршрутизатор знает, что делать, если он получит пакет, предназначенный для конкретного адреса многоадресной передачи.

ПРИМЕЧАНИЕ

Адресация многоадресной передачи — не до конца исследованная тема, и ее описание может легко составить отдельную книгу.

Теперь будем считать, что процесс на узле, изображенном слева вверху, начинает отправлять пакеты на адрес многоадресной передачи. Допустим, этот процесс отправляет аудиопакеты, ожидаемые получателями многоадресной передачи. Эти пакеты показаны на рис. 21.6.

Рис. 21.6. Отправка пакетов на адрес многоадресной передачи в глобальной сети

Проследим шаги, которые проходит пакет от отправителя до получателей.

■ Пакеты многоадресной передачи рассылаются отправителем в левой верхней локальной сети. Получатель H1 получает их (так как он присоединился к группе), как и MR1 (поскольку маршрутизатор многоадресной передачи должен получать все пакеты многоадресного вещания).

■ MR1 передает пакет многоадресной передачи дальше маршрутизатору MR2, поскольку протокол маршрутизации многоадресной передачи сообщил MR1, что MR2 должен получить пакеты, предназначенные для этой группы.

■ MR2 передает этот пакет присоединенной локальной сети, поскольку узлы H2 и H3 входят в группу. Он также создает копию пакета и отправляет ее MR3.

Создание копии пакета маршрутизатором свойственно только многоадресной передаче. Пакет направленной передачи никогда не дублируется при передаче маршрутизаторами.

■ MR3 с отправляет пакет многоадресной передачи маршрутизатору MR4, но не передает копию в свою локальную сеть, потому что ни один из узлов в этой сети не присоединился к группе.

■ MR4 передает пакет на присоединенную локальную сеть, поскольку узлы H4 и H5 входят в группу. Он не создает копии пакета и не отправляет пакет маршрутизатору MR, поскольку ни один из узлов присоединенной к MR локальной сети не входит в группу, и MR4 знает об этом из информации о маршрутизации многоадресной передачи, которой он обменялся с MR.

Две менее желательные альтернативы многоадресной передаче в глобальной сети — лавинная адресация (broadcast flooding) и отправка индивидуальных копий каждому получателю. В первом случае отправитель будет передавать широковещательные пакеты, а каждый маршрутизатор будет передавать пакет с каждого из своих интерфейсов, кроме принимающего. Ясно, что это увеличит число незаинтересованных узлов и маршрутизаторов, которым придется получать этот пакет.

Во втором случае отправитель должен знать IP-адреса всех получателей и отослать каждому по копии пакета. В случае с пятью пакетами, который представлен на рис. 21.6, это потребует пяти пакетов в локальной сети отправителя, четырех пакетов, идущих от MR1 к MR2, и двух пакетов, идущих от MR2 к MR3 и к MR4. А если получателей будет миллион?!

21.5. Многоадресная передача от отправителя

Внедрение многоадресной передачи в глобальные сети было затруднено несколькими обстоятельствами. Главная проблема заключается в том, что протокол маршрутизации MRP, описанный в разделе 21.4, должен обеспечивать доставку данных от всех отправителей (которые могут располагаться в сети совершенно произвольным образом) всем получателям (которые также могут быть размещены произвольно). Еще одна проблема связана с выделением адресов: адресов многоадресной передачи IPv4 недостаточно для того, чтобы можно было статически назначать их всем, кому они нужны, как это делается с адресами направленной передачи. Чтобы передавать многоадресные сообщения в глобальной сети, не конфликтуя с другими отправителями, нужно иметь уникальный адрес, однако механизма глобального выделения адресов еще не существует.

Многоадресная передача от отправителя (source-specific multicast, SSM) [47] представляет собой эффективное решение этих проблем. Она состоит в соединении адреса группы с адресом отправителя.

■ При подключении к группе получатели предоставляют маршрутизаторам не только адрес группы, но и адрес отправителя. Это устраняет проблему поиска, потому что теперь маршрутизатор точно знает, где находится отправитель. Однако при этом сохраняется удобство масштабирования приложений, потому что отправителю все так же не нужно знать адреса всех своих получателей. Такое решение очень сильно упрощает протоколы маршрутизации многоадресной передачи.

■ Идентификатор группы перестает быть групповым адресом и становится комбинацией адреса отправителя (адреса направленной передачи) и адреса группы (адреса многоадресной передачи). Такая комбинация называется в SSM каналом (channel). Благодаря этому отправитель может выбрать любой адрес многоадресной передачи, так как уникальность канала обеспечивается уже уникальностью адреса отправителя. Сеанс SSM представляет собой комбинацию адреса отправителя, адреса группы и порта.

SSM обеспечивает некоторую защиту от подмены адреса, потому что отправителю 2 становится значительно труднее передавать сообщения по каналу отправителя 1, так как идентификатор этого канала включает в себя адрес отправителя 1. Подмена все еще остается возможной, однако серьезно усложняется.

21.6. Параметры сокетов многоадресной передачи

Для поддержки многоадресной передачи программным интерфейсом приложений (API) требуется только пять новых параметров сокетов. Поддержка фильтрации отправителей, необходимая для SSM, требует еще четырех параметров. В табл. 21.2 показаны три параметра, не имеющих отношения к членству в группах, а также тип данных аргумента, который предполагается использовать в вызове функций getsockopt или setsockopt для IPv4 и IPv6. В табл. 21.3 представлены оставшиеся шесть параметров сокетов для IPv4, IPv6 и не зависящего от IP-версии API. Во втором столбце показан тип данных переменной, указатель на которую является четвертым аргументом функций getsockopt и setsockopt. Все девять параметров действительны с функцией setsockopt, но шесть предназначенных для входа и выхода из группы не могут быть использованы в вызове функции getsockopt.

Таблица 21.2. Параметры сокетов многоадресной передачи

Параметр	Тип данных	Описание
IP_MULTICAST_IF	struct in_addr	Интерфейс по умолчанию для исходящих многоадресных пакетов
IP_MULTICAST_TTL	u_char	TTL для исходящих многоадресных пакетов
IP_MULTICAST_LOOP	u_char	Включение и отключение закольцовки для исходящих многоадресных пакетов
IPV6_MULTICAST_IF	u_int	Интерфейс по умолчанию для исходящих многоадресных пакетов
IPV6_MULTICAST_HOPS	int	Предел количества прыжков для и сходящих многоадресных пакетов
IPV6_MULTICAST_LOOP	u_int	Включение и отключение закольцовки для исходящих многоадресных пакетов

Таблица 21.3. Параметры сокета, определяющие членство в группах многоадресной передачи

Параметр	Тип данных	Описание
IP_ADD_MEMBERSHIP	struct ip_mreq	Присоединение к группе многоадресной передачи
IP_DROP_MEMBERSHIP	struct ip_mreq	Отсоединение от группы многоадресной передачи
IP_BLOCK_SOURCE	struct ip_mreq_source	Блокирование источника из группы, к которой выполнено присоединение
IP_UNBLOCK_SOURCE	struct ip_mreq_source	Разблокирование ранее заблокированного источника
IP_ADD_SOURCE_MEMBERSHIP	struct ip_mreq_source	Присоединение к группе источника
IP_DROP_SOURCE_MEMBERSHIP	struct ip_mreq_source	Отсоединение от группы источника
IPV6_JOIN_GROUP	struct ipv6_mreq	Присоединение к группе многоадресной передачи
IPV6_LEAVE_GROUP	struct ipv6_mreq	Отсоединение от группы многоадресной передачи
MCAST_JOIN_GROUP	struct group_req	Присоединение к группе многоадресной передачи
MCAST_LEAVE_GROUP	struct group_req	Отсоединение от группы многоадресной передачи
MCAST_BLOCK_SOURCE	struct group_source_req	Блокирование источника из группы, к которой выполнено присоединение
MCAST_UNBLOCK_SOURCE	struct group_source_req	Разблокирование ранее заблокированного источника
MCAST_JOIN_SOURCE_GROUP	struct group_source_req	Присоединение к группе источника
MCAST_LEAVE_SOURCE_GROUP	struct group_source_req	Отсоединение от группы источника

ПРИМЕЧАНИЕ

Параметры IPv4 TTL и закольцовки получают аргумент типа u_char, в то время как IPv6-параметры предела транзитных узлов и закольцовки получают аргументы соответственно типа int и u_int. Распространенная ошибка программирования с параметрами многоадресной передачи IPv4 — вызов функции setsockopt с аргументом типа int для задания TTL или закольцовки (что не разрешается [128, с. 354–355]), поскольку большинство других параметров сокетов, представленных в табл. 7.1, имеют целочисленные аргументы. Изменения, внесенные в IPv6, должны уменьшить вероятность ошибок.

Теперь мы опишем каждый из девяти параметров сокетов более подробно. Обратите внимание, что эти девять параметров концептуально идентичны в IPv4 и IPv6 — различаются только их названия и типы аргументов.

■IP_ADD_MEMBERSHIP, IPV6_JOIN_GROUP, MCAST_JOIN_GROUP. Назначение этих параметров — присоединение к группе на заданном локальном интерфейсе. Мы задаем локальный интерфейс одним из его направленных адресов для IPv4 или индексом интерфейса для IPv6. Следующие три структуры используются при присоединении к группе или при отсоединении от нее:

struct ip_mreq {
 struct in_addr imr_multiaddr; /* IPv4-адрес многоадресной
                                  передачи класса D */
 struct in_addr imr_interface; /* IPv4-адрес локального
                                  интерфейса */
};

struct ipv6_mreq {
 struct in6_addr ipv6mr_multiaddr; /* IPv6-адрес многоадресной
                                      передачи */
 unsigned int ipv6mr_interface;    /* индекс интерфейса или 0 */
};

struct group_req {
 unsigned int gr_interface;        /* индекс интерфейса или 0 */
 struct sockaddr_storage gr_group; /* адрес многоадресной передачи
                                      IPv4 или IPv6 */
};

Если локальный интерфейс задается как универсальный адрес (INADDR_ANY для IPv4) или как нулевой индекс IPv6, то конкретный локальный интерфейс выбирается ядром.

Мы говорим, что узел принадлежит к данной группе на данном интерфейсе, если один или более процессов в настоящий момент принадлежат к этой группе на этом интерфейсе.

Сокет может быть присоединен к нескольким группам, но к каждой группе должен быть присоединен уникальный адрес или уникальный интерфейс. Это свойство можно использовать на узле с несколькими сетевыми интерфейсами: создается один сокет, которому присваивается один адрес многоадресной передачи, но благодаря наличию разных интерфейсов этот сокет может быть присоединен к разным группам.

Вспомните из табл. 21.1, что частью адреса многоадресной передачи IPv6 является поле области действия. Как мы отмечали, адреса многоадресной передачи IPv6, отличающиеся только областью действия, являются различными. Следовательно, если реализация протокола синхронизации времени (network time protocol, NTP) хочет получать все пакеты NTP независимо от их области действия, она должна будет присоединиться к адресу ff01:101 (локальный в пределах узла), ff02:101 (локальный в пределах физической сети), ff05:101 (локальный в пределах сайта), ff08:101 (локальный в пределах организации) и ff0e:101 (глобальный). Все присоединения могут выполняться на одном сокете. Можно установить параметр сокета IPV6_PKTINFO (см. раздел 22.8), чтобы функция recvmsg возвращала адрес получателя каждой дейтаграммы.

Независимый от версии IP параметр сокета (MCAST_JOIN_GROUP) аналогичен соответствующему параметру IPv6 за тем исключением, что он использует структуру sockaddr_storage вместо in6_addr для передачи адреса ядру. Структура sockaddr_storage (см. листинг 3.4) достаточно велика для хранения адреса любой версии, поддерживаемой системой.

ПРИМЕЧАНИЕ

В большинстве реализаций число присоединений, допустимых для одного сокета, ограничено. Предел определяется константой IP_MAX_MEMBERSHIPS (для Беркли-реализаций ее значение равно 20). В некоторых реализациях это ограничение снято, в других оно значительно превышает значение для Беркли-реализаций.

Когда интерфейс, на котором будет происходить присоединение, не задан, Беркли-ядра ищут адрес многоадресной передачи в обычной таблице маршрутизации IP и используют полученный в результате интерфейс [128, с. 357]. Некоторые системы для обработки этой ситуации устанавливают маршрут для всех адресов многоадресной передачи (то есть маршрут с адресом получателя 224.0.0.0/8 для IPv4) в процессе инициализации.

Для IPv6 сделано изменение — при задании интерфейса используется индекс, а не локальный адрес направленной передачи, как было в IPv4. Это позволяет выполнять присоединение на ненумерованных интерфейсах и конечных точках туннелей.

Изначально в API многоадресной передачи IPv6 использовалась константа IPV6_ADD_MEMBERSHIP, а не IPV6_JOIN_GROUP. Во всех остальных отношениях интерфейс программирования не изменился. Описанная далее функция mcast_join скрывает это отличие.

■IP_DROP_MEMBERSHIP, IPV6_LEAVE_GROUP и MCAST_LEAVE_GROUP. Назначение этих параметров — выход из группы на заданном локальном интерфейсе. С этими параметрами сокета применяются те же структуры, которые мы только что показали для присоединения к группе. Если локальный интерфейс не задан (то есть его значение равно INADDR_ANY для IPv4 или индекс интерфейса равен нулю для IPv6), удаляется первое совпадающее с искомым вхождение в группу.

Если процесс присоединился к группе, но не выходил из группы явно, то при закрытии сокета (либо явном, либо по завершении процесса) вхождение в группу прекращается автоматически. Возможна ситуация, когда несколько процессов на узле присоединились к одной и той же группе, и в этом случае узел остается членом группы, пока последний процесс не выйдет из группы.

ПРИМЕЧАНИЕ

Изначально в API многоадресной передачи IPv6 использовалась константа IPV6_DROP_MEMBERSHIP, а не IPV6_LEAVE_GROUP. Во всех остальных отношениях интерфейс программирования не изменился. Описанная далее функция mcast_leave скрывает это отличие.

■IP_BLOCK_SOURCE, MCAST_BLOCK_SOURCE. Блокируют получение трафика через данный сокет от конкретного источника для конкретной группы и интерфейса. Если все сокеты, присоединенные к группе, заблокировали один и тот же источник, система может проинформировать маршрутизаторы о нежелательности трафика, что может повлиять на маршрутизацию многоадресного трафика в сети. Локальный интерфейс задается одним из его направленных адресов для IPv4 или индексом для независимого от версии API. Для блокирования и разблокирования источника используются две приведенные ниже структуры:

struct ip_mreq_source {
 struct in_addr imr_multiaddr;  /* IPv4-адрес многоадресной
                                   передачи класса D */
 struct in_addr imr_sourceaddr; /* IPv4-адрес источника */
 struct in_addr imr_interface;  /* IPv4-адрес локального
                                   интерфейса */
};

struct group_source_req {
 unsigned int gsr_interface;         /* индекс интерфейса или 0 */
 struct sockaddr_storage gsr_group;  /* адрес многоадресной
                                        передачи IPv4 или IPv6 */
 struct sockaddr_storage gsr_source; /* адрес источника IPv4
                                        или IPv6 */
};

Если локальный интерфейс задается как универсальный адрес (INADDR_ANY для IPv4) или как нулевой индекс IPv6, то конкретный локальный интерфейс выбирается ядром.

Запрос на блокирование источника действует только для присоединенных групп, то есть таких, которые уже были присоединены к указанному интерфейсу параметром IP_ADD_MEMBERSHIP, IPV6_JOIN_GROUP или MCAST_JOIN_GROUP.

■IP_UNBLOCK_SOURCE, MCAST_UNBLOCK_SOURCE. Разблокирование заблокированного ранее источника. Аргументы должны быть в точности те же, что и у предшествовавшего запроса IP_BLOCK_SOURCE или MCAST_BLOCK_SOURCE.

Если локальный интерфейс задается как универсальный адрес (INADDR_ANY для IPv4) или как нулевой индекс IPv6, то конкретный локальный интерфейс выбирается ядром.

■IP_ADD_SOURCE_MEMBERSHIР, MCAST_JOIN_SOURCE_GROUP. Присоединение к группе конкретного источника на заданном локальном интерфейсе. С этим параметром используются те же структуры, что и с параметрами блокирования и разблокирования источника. Сокет не должен быть присоединен к той же группе без указания источника (параметры IP_ADD_MEMBERSHIP, IPV6_JOIN_GROUP, MCAST_JOIN_GROUP).

Если локальный интерфейс задается как универсальный адрес (INADDR_ANY для IPv4) или как нулевой индекс IPv6, то конкретный локальный интерфейс выбирается ядром.

■IP_DROP_SOURCE_MEMBERSHIP, MCAST_LEAVE_SOURCE_GROUP. Отключение от группы источника конкретного локального интерфейса. Используются те же структуры, что и с предыдущими параметрами сокетов. Если локальный интерфейс не указан (значение INADDR_ANY для IPv4 или 0 для независимого от версии API), отключается первая группа, удовлетворяющая заданным значениям.

Если процесс присоединяется к группе источника, но не отключается от нее явно, отсоединение производится автоматически при закрытии сокета (явном или также автоматическом, при завершении процесса). Несколько процессов узла могут присоединиться к одной и той же группе источника, в случае чего узел остается в группе до тех пор, пока из нее не выйдет последний процесс.

■IP_MULTICAST_IF и IPV6_MULTICAST_IF. Назначение этих параметров - задание интерфейса для исходящих дейтаграмм многоадресной передачи, отправленных на этом сокете. Этот интерфейс задается либо структурой in_addr для IPv4, либо индексом интерфейса для IPv6. Если задано значение INADDR_ANY для IPv4 или нулевой индекс интерфейса для IPv6, то удаляется любой интерфейс, ранее заданный этим параметром сокета, и система будет выбирать интерфейс каждый раз при отправке дейтаграммы.

Будьте внимательны, четко различая локальный интерфейс, заданный (или выбранный), когда процесс присоединяется к группе (интерфейс для получения приходящих дейтаграмм многоадресной передачи), и локальный интерфейс, заданный (или выбранный) для исходящих дейтаграмм.

ПРИМЕЧАНИЕ

Беркли-ядра выбирают интерфейс для исходящих дейтаграмм многоадресной передачи по умолчанию при помощи обычной таблицы маршрутизации IP. В ней выполняется поиск маршрута к групповому адресу получателя, после чего используется соответствующий интерфейс. Это та же технология, что используется для выбора принимающего интерфейса, если процесс не задает его в процессе присоединения к группе. При этом считается, что если для данного адреса многоадресной передачи существует маршрут (возможно, маршрут, заданный по умолчанию в таблице маршрутизации), то соответствующий интерфейс должен использоваться для ввода и вывода.

■IP_MULTICAST_TTL и IPV6_MULTICAST_HOPS. Назначение этих параметров - установка значения поля TTL в случае IPv4 или предельного количества транзитных узлов в случае IPv6 для исходящих дейтаграмм многоадресной передачи. По умолчанию значение обоих параметров равно 1, что ограничивает дейтаграмму локальной подсетью.

■IP_MULTICAST_LOOP и IPV6_MULTICAST_LOOP. Назначение этих параметров - включение или отключение локальной закольцовки для дейтаграмм многоадресной передачи. По умолчанию закольцовка включена: копия каждой дейтаграммы многоадресной передачи, посылаемой процессом на узле, будет отправлена обратно на этот узел и обработана им, как любая другая полученная дейтаграмма, если узел принадлежит данной группе на исходящем интерфейсе.

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

ПРИМЕЧАНИЕ

Описываемая здесь закольцовка является внутренней и выполняется на уровне IP или выше. Если интерфейс получает копии своих передач, RFC 1112 [26] требует, чтобы драйвер игнорировал эти копии. В этом документе также утверждается, что параметр закольцовки по умолчанию включен «в целях оптимизации производительности для протоколов верхнего уровня, которые ограничивают членство в группе до одного процесса на узел (например, маршрутизирующих протоколов)».

Первые шесть пар параметров сокетов (ADD_MEMBERSHIP/JOIN_GROUP, DROP_MEMBERSHIP/LEAVE_GROUP, BLOCK_SOURCE, UNBLOCK_SOURCE, ADD_SOURCE_MEMBERSHIP/JOIN_SOURCE_GROUP, DROP_SOURCE_MEMBERSHIP/LEAVE_SOURCE_GROUP) влияют на получение дейтаграмм многоадресной передачи, в то время как последние три пары параметров влияют на отправку дейтаграмм многоадресной передачи (интерфейс для исходящих сообщений, TTL или предел количества транзитных узлов, закольцовка). Ранее мы отмечали, что для отправки дейтаграммы многоадресной передачи ничего особенного не требуется. Если ни один параметр сокетов многоадресной передачи не задан перед отправкой дейтаграммы, интерфейс для исходящей дейтаграммы будет выбран ядром, TTL или предел количества транзитных узлов будут равны 1, а копия отправленной дейтаграммы будет посылаться обратно (то есть будет включена закольцовка).

Чтобы получить дейтаграмму многоадресной передачи, процесс должен присоединиться к группе, а также связать при помощи функции bind сокет UDP с номером порта, который будет использоваться как номер порта получателя для дейтаграмм, отсылаемых данной группе. Это две отдельные операции, и обе они являются обязательными. Присоединение к группе указывает уровню IP узла и канальному уровню, что необходимо получать дейтаграммы многоадресной передачи, отправленные этой группе. Связывая порт, приложение указывает UDP, что требуется получать отправляемые на этот порт дейтаграммы. Некоторые приложения в дополнение к связыванию порта также связывают при помощи функции bind адрес многоадресной передачи с сокетом. Это предотвращает доставку сокету любых других дейтаграмм, которые могли быть получены для этого порта.

ПРИМЕЧАНИЕ

Исторически Беркли-реализации требуют только, чтобы некоторый сокет на узле присоединился к группе — это не обязательно тот сокет, который связывается с портом и затем получает дейтаграммы многоадресной передачи. Однако есть вероятность, что эти реализации могут доставлять дейтаграммы многоадресной передачи приложениям, не знающим о многоадресной передаче. Более новые ядра требуют, чтобы процесс связывался с портом и устанавливал какой-нибудь параметр сокета многоадресной передачи для сокета как указатель того, что приложение знает о многоадресной передаче. Самый обычный параметр сокета многоадресной передачи — признак присоединения к группе. Для Solaris 2.5 характерны некоторые отличия: дейтаграммы многоадресной передачи доставляются только на те сокеты, которые присоединились к группе и связались с портом. В целях переносимости все приложения многоадресной передачи должны присоединиться к группе и связаться с портом.

Более новый интерфейс многоадресного сервиса требует, чтобы уровень IP доставлял многоадресные пакеты сокету только в том случае, если этот сокет присоединился к группе или источнику. Такое требование было введено с IGMPv3 (RFC 3376 [16]), чтобы разрешить фильтрацию источников и многоадресную передачу от источника. Таким образом ужесточается требование на присоединение к группе, но зато ослабляется требование на связывание группового адреса. Однако для наибольшей переносимости со старыми и новыми интерфейсами приложения должны присоединяться к группам и связывать сокеты с групповыми адресами.

Некоторые более старые узлы, имеющие возможность многоадресной передачи, не позволяют связывать адрес многоадресной передачи с сокетом при помощи функции bind. В целях переносимости приложение может игнорировать ошибку функции bind при связывании адреса многоадресной передачи с сокетом и делать повторную попытку с адресом INADDR_ANY или in6addr_any.

21.7. Функция mcast_join и родственные функции

Несмотря на то что параметры сокетов многоадресной передачи для IPv4 аналогичны параметрам сокетов многоадресной передачи для IPv6, есть достаточно много различий, из-за которых не зависящий от протокола код, использующий многоадресную передачу, усложняется и содержит множество директив #ifdef. Наилучшим решением будет использование приведенных ниже восьми функций, позволяющих скрыть различия реализаций:

#include "unp.h"

int mcast_join(int sockfd, const struct sockaddr *grp,
 socklen_t grplen, const char *ifname, u_int ifindex);
int mcast_leave(int sockfd, const struct sockaddr *grp,
 socklen_t grplen);
int mcast_block_source(int sockfd,
 const struct sockaddr *src, socklen_t srclen,
 const struct sockaddr *grp, socklen_t grplen);
int mcast_unblock_source(int sockfd,
 const struct sockaddr *src, socklen_t srclen,
 const struct sockaddr *grp, socklen_t grplen);
int mcast_join_source_group(int sockfd,
 const struct sockaddr *src, socklen_t srclen,
 const struct sockaddr *grp, socklen_t grplen,
 const char *ifname, u_int ifindex);
int mcast_leave_source_group(int sockfd,
 const struct sockaddr *src, socklen_t srclen,
 const struct sockaddr *grp, socklen_t grplen);
int mcast_set_if(int sockfd, const char *ifname, u_int ifindex);
 int mcast_set_loop(int sockfd, int flag);
int mcast_set_ttl(int sockfd, int ttl);
Все перечисленные выше функции возвращают: 0 в случае успешного выполнения, -1 в случае ошибки

int mcast_get_if(int sockfd);
Возвращает: неотрицательный индекс интерфейса в случае успешного выполнения, -1 в случае ошибки

int mcast_get_loop(int sockfd);
Возвращает: текущий флаг закольцовки в случае успешного выполнения, -1 в случае ошибки

int mcast_get_ttl(int sockfd);
Возвращает: текущее значение TTL или предельное количество транзитных узлов в случае успешного выполнения, -1 в случае ошибки

Функция mcast_join присоединяет узел к группе. IP-адрес этой группы содержится в структуре адреса сокета, на которую указывает аргумент grp, а длина этой структуры задается аргументом grplen. Мы можем задать интерфейс, на котором должно происходить присоединение к группе, либо через имя интерфейса (непустой аргумент ifname), либо через ненулевой индекс интерфейса (непустой аргумент ifindex). Если ни одно из этих значений не задано, ядро самостоятельно выбирает интерфейс, на котором происходит присоединение к группе. Вспомните, что в случае IPv6 для работы с параметрами сокета интерфейс задается по его индексу. Если для сокета IPv6 известно имя интерфейса, нужно вызвать функцию if_nametoindex, чтобы получить индекс интерфейса. В случае параметра сокета IPv4 мы задаем интерфейс по его IP-адресу направленной передачи. Если для сокета IPv4 интерфейс задан по имени, нужно вызвать функцию ioctl с запросом SIOCGIFADDR для получения IP-адреса направленной передачи для этого интерфейса. Если для сокета IPv4 задан индекс интерфейса, мы сначала вызываем функцию if_indextoname, чтобы получить имя интерфейса, а затем обрабатываем имя так, как только что было сказано.

ПРИМЕЧАНИЕ

Пользователи обычно задают имя интерфейса le0 или ether0, а IP-адрес и индекс интерфейса не используются. Например, tcpdump является одной из немногих программ, позволяющих пользователю задавать интерфейс, а ее параметр -i принимает имя интерфейса в качестве аргумента.

Функция mcast_leave выводит узел из группы с IP-адресом, содержащимся в структуре адреса сокета, на которую указывает аргумент grp.

Функция mcast_block_source блокирует получение через конкретный сокет пакетов, относящихся к определенной группе и исходящих от определенного источника. IP-адреса группы и источника хранятся в структурах адреса сокета, на которые указывают аргументы grp и src соответственно. Длины структур задаются параметрами srclen и grplen. Для успешного завершения функции необходимо, чтобы до ее вызова уже была вызвана функция mcast_join для того же сокета и той же группы.

Функция mcast_unblock_source разблокирует получение трафика от источника из заданной группы. Аргументы src, srclen, grp и grplen имеют тот же смысл, что и аргументы предыдущей функции, и должны совпадать с ними по значениям.

Функция mcast_join_source_group выполняет присоединение к группе источника. Адрес источника и адрес группы содержатся в структурах адреса сокета, на которые указывают аргументы src и grp. Длины структур задаются параметрами srclen и grplen. Интерфейс, присоединяемый к группе, может быть задан именем (ненулевой аргумент ifname) или индексом (ifindex). Если интерфейс не задан явно, ядро выбирает его самостоятельно.

Функция mcast_leave_source_group выполняет отсоединение от группы источника. Адреса источника и группы содержатся в структурах адреса сокета, на которые указывают аргументы src и grp. Длины структур задаются параметрами srclen и grplen. Подобно mcast_leave, mcast_leave_source_group не требует указания интерфейса: она всегда отсоединяет от группы первый интерфейс, удовлетворяющий условиям.

Функция mcast_set_if устанавливает индекс интерфейса по умолчанию для исходящих дейтаграмм многоадресной передачи. Если аргумент ifname непустой, он задает имя интерфейса. Иначе положительное значение аргумента ifindex будет задавать индекс интерфейса. В случае IPv6 имя сопоставляется индексу с использованием функции if_nametoindex. В случае IPv4 сопоставление имени или индекса IP-адресу направленной передачи интерфейса происходит так же, как для функции mcast_join.

Функция mcast_set_loop устанавливает параметр закольцовки либо в 0, либо в 1, а функция mcast_set_ttl TTL в случае IPv4 или предел количества транзитных узлов в случае IPv6. Функции mcast_get_XXX возвращают соответствующие значения.

Пример: функция mcast_join

В листинге 21.1[1] показана первая часть функции mcast_join. Эта часть демонстрирует простоту интерфейса программирования, не зависящего от протокола.

Листинг 21.1. Присоединение к группе: сокет IPv4

//lib/mcast_join.c
 1 #include "unp.h"
 2 #include 

 3 int
 4 mcast_join(int sockfd, const SA *grp, socklen_t grplen,
 5 const char *ifname, u_int ifindex)
 6 {
 7 #ifdef MCAST_JOIN_GROUP
 8  struct group_req req;
 9  if (ifindex > 0) {
10   req.gr_interface = ifindex;
11  } else if (ifname != NULL) {
12   if ((req.gr_interface = if_nametoindex(ifname)) == 0) {
13    errno = ENXIO; /* интерфейс не найден */
14    return(-1);
15   }
16  } else
17  req.gr_interface = 0;
18  if (grplen > sizeof(req.gr_group)) {
19   errno = EINVAL;
20   return -1;
21  }
22  memcpy(&req.gr_group, grp, grplen);
23  return (setsockopt(sockfd, family_to_level(grp->sa_family),
24  MCAST_JOIN_GROUP, &req, sizeof(req)));
25 #else

Обработка индекса

9-17 Если при вызове был указан индекс интерфейса, функция использует его непосредственно. В противном случае (при указании имени интерфейса), имя преобразуется в индекс вызовом if_nametoindex. Если ни имя, ни индекс не заданы, интерфейс выбирается ядром.

Копирование адреса и вызов setsockopt

18-22 Адрес сокета копируется непосредственно в поле группы. Вспомните, что поле это имеет тип sockaddr_storage, а потому достаточно велико для хранения адреса любого типа, поддерживаемого системой. Для предотвращения переполнения буфера (при ошибках в программе) мы проверяем размер sockaddr и возвращаем EINVAL, если он слишком велик.23-24 Присоединение к группе выполняется вызовом setsockopt. Аргумент level определяется на основании семейства группового адреса вызовом нашей собственной функции family_to_level. Некоторые системы допускают несоответствие аргумента level семейству адреса сокета, например использование IPPROTO_IP с MCAST_JOIN_GROUP, даже если сокет относится к семейству AF_INET6, но это верно не для всех систем, поэтому мы и должны выполнить преобразование семейства к нужному значению level. Листинг этой тривиальной функции в книге мы не приводим, но исходный код этой функции вы можете скачать вместе со всеми остальными программами.

В листинге 21.2 представлена вторая часть функции mcast_join, обрабатывающая сокеты IPv4.

Листинг 21.2. Присоединение к группе: обработка сокета IPv4

26  switch (grp->sa_family) {
27  case AF_INET: {
28   struct ip_mreq mreq;
29   struct ifreq ifreq;

30   memcpy(&mreq.imr_multiaddr,
31    &((const struct sockaddr_in*)grp)->sin_addr,
32    sizeof(struct in_addr));

33    if (ifindex > 0) {
34     if (if_indextoname(ifindex, ifreq.ifr_name) == NULL) {
35      errno = ENXIO; /* i/f index not found */
36      return(-1);
37     }
38     goto doioctl;
39    } else if (ifname != NULL) {
40     strncpy(ifreq.ifr_name, ifname, IFNAMSIZ);
41 doioctl:
42     if (ioctl(sockfd, SIOCGIFADDR, &ifreq) < 0)
43      return(-1);
44     memcpy(&mreq.imr_interface,
45      &((struct sockaddr_in*)&ifreq.ifr_addr)->sin_addr,
46      sizeof(struct in_addr));
47    } else
48     mreq.imr_interface.s_addr = htonl(INADDR_ANY);

49    return(setsockopt(sockfd, IPPROTO_IP, IP_ADD_MEMBERSHIP,
50     &mreq, sizeof(mreq)));
51   }

Обработка индекса

33-38 Адрес многоадресной передачи IPv4 в структуре адреса сокета копируется в структуру ip_mreq. Если индекс был задан, вызывается функция if_indextoname, сохраняющая имя в нашей структуре ip_mreq. Если это выполняется успешно, мы переходим на точку вызова ioctl.

Обработка имени

39-46 Имя вызывающего процесса копируется в структуру ip_mreq, а вызов SIOCGIFADDR функции ioctl возвращает адрес многоадресной передачи, связанный с этим именем. При успешном выполнении адрес IPv4 копируется в элемент imr_interface структуры ip_mreq.

Значения по умолчанию

47-48 Если ни индекс, ни имя не заданы, используется универсальный адрес, что указывает ядру на необходимость выбрать интерфейс.49-50 Функция setsockopt выполняет присоединение к группе.

Третья, и последняя, часть функции, обрабатывающая сокеты IPv6, приведена в листинге 21.3.

Листинг 21.3. Присоединение к группе: обработка сокета IPv6

52 #ifdef IPV6
53  case AF_INET6: {
54   struct ipv6_mreq mreq6;

55   memcpy(&mreq6.ipv6mr_multiaddr,
56    &((const struct sockaddr_in6*) grp)->sin6_addr,
57    sizeof(struct in6_addr));

58    if (ifindex > 0) {
59     mreq6.ipv6mr_interface = ifindex;
60    } else if (ifname != NULL) {
61     if ((mreq6.ipv6mr_interface = if_nametoindex(ifname)) == 0) {
62      errno = ENXIO; /* интерфейс не найден */
63      return(-1);
64     }
65    } else
66     mreq6.ipv6mr_interface = 0;

67    return(setsockopt(sockfd, IPPROTO_IPV6, IPV6_JOIN_GROUP,
68     &mreq6, sizeof(mreq6)));
69   }
70 #endif

71  default:
72   errno = EAFNOSUPPORT;
73   return(-1);
74  }
75 #endif
76 }

Копирование адреса

55-57 Сначала адрес IPv6 копируется из структуры адреса сокета в структуру ipv6_mreq.

Обработка индекса или имени интерфейса или выбор интерфейса по умолчанию

58-66 Если был задан индекс, он записывается в элемент ipv6mr_interface. Если индекс не задан, но задано имя, то для получения индекса вызывается функция if_nametoindex. В противном случае для функции setsockopt индекс устанавливается в 0, что указывает ядру на необходимость выбрать интерфейс.67-68 Выполняется присоединение к группе.

Пример: функция mcast_set_loop

В листинге 21.4 показана наша функция mcast_set_loop.

Поскольку аргументом является дескриптор сокета, а не структура адреса сокета, мы вызываем нашу функцию sockfd_to_family, чтобы получить семейство адресов сокета. Устанавливается соответствующий параметр сокета.

Мы не показываем исходный код для всех остальных функций mcast_XXX, так как он свободно доступен в Интернете (см. предисловие).

Листинг 21.4. Установка параметра закольцовки для многоадресной передачи

//lib/mcast_set_loop.c
 1 #include "unp.h"

 2 int
 3 mcast_set_loop(int sockfd, int onoff)
 4 {
 5  switch (sockfd_to_family(sockfd)) {
 6  case AF_INET:{
 7   u_char flag;

 8   flag = onoff;
 9   return (setsockopt(sockfd, IPPROTO_IP, IP_MULTICAST_LOOP,
10    &flag, sizeof(flag)));
11  }

12 #ifdef IPV6
13  case AF_INET6:{
14   u_int flag;

15   flag = onoff;
16   return (setsockopt(sockfd, IPPROTO_IPV6, IPV6_MULTICAST_LOOP,
17    &flag, sizeof(flag)));
18  }
19 #endif

20  default:
21   errno = EPROTONOSUPPORT;
22   return (-1);
23  }
24 }

21.8 Функция dg_cli, использующая многоадресную передачу

Мы изменяем нашу функцию dg_cli, показанную в листинге 20.1, просто удаляя вызов функции setsockopt. Как мы сказали ранее, для отправки дейтаграмм многоадресной передачи не нужно устанавливать ни одного параметра сокета многоадресной передачи, если нас устраивают заданные по умолчанию настройки интерфейса исходящих пакетов, значения TTL и параметра закольцовки. Мы запускаем нашу программу, задавая в качестве адреса получателя группу всех узлов (all-hosts group):

macosx % udpcli01 224.0.1.1
hi there
from 172.24.37.78: hi there MacOS X
from 172.24.37.94: hi there FreeBSD

Отвечают оба узла, находящиеся в подсети. На обоих работают многоадресные эхо-серверы. Каждый ответ является направленным, поскольку адрес отправителя запроса, используемый сервером в качестве адреса получателя ответа, является адресом направленной передачи.

Фрагментация IP и многоадресная передача

В конце раздела 20.4 мы отмечали, что в большинстве систем фрагментация широковещательной дейтаграммы не допускается по стратегическим соображениям. Фрагментация допускается при многоадресной передаче, что мы можем легко проверить, используя тот же файл с 2000-байтовой строкой:

macosx % udpcli01 224.0.1.1 < 2000line
from 172.24.37.78: xxxxxxx[...]
from 172.24.37.94: xxxxxxx[...]

21.9. Получение анонсов сеансов многоадресной передачи

Многоадресная инфраструктура представляет собой часть Интернета, в которой разрешена многоадресная передача между доменами. Во всем Интернете многоадресная передача не разрешена. Многоадресная инфраструктура Интернета начала свое существование в 1992 году. Тогда она называлась MBone и была оверлейной сетью. В 1998 году MBone была признана частью инфраструктуры Интернета. Внутри предприятий многоадресная передача используется достаточно широко, но междоменная передача поддерживается гораздо меньшим числом серверов.

Для участия в мультимедиа-конференции по сети многоадресной передачи достаточно того, чтобы сайту был известен групповой адрес конференции и порты UDP для потоков данных (например, аудио и видео). Протокол анонсирования сеансов (Session Announcement Protocol, SAP) определяет эту процедуру, описывая заголовки пакетов и частоту, с которой эти анонсы при помощи многоадресной передачи передаются по инфраструктуре многоадресной передачи. Этот протокол описан в RFC 2974 [42]. Протокол описания сеанса (Session Description Protocol, SDP) [41] описывает технические параметры сеанса связи (в частности, он определяет, как задаются адреса многоадресной передачи и номера портов UDP). Сайт, желающий анонсировать сеанс, периодически посылает пакет многоадресной передачи, содержащий описание сеанса, для известной группы на известный порт UDP. Для получения этих анонсов сайты запускают программу под названием sdr. Эта программа не только получает объявления сеансов, но и предоставляет интерактивный интерфейс пользователя, позволяющий пользователю отправлять свои собственные анонсы.

В этом разделе мы продемонстрируем прием пакетов многоадресной передачи, создав пример простой программы, лишь получающей анонсы сеансов. В данном случае мы стремимся показать простоту устройства получателя пакетов при многоадресной передаче, а не исследовать подробности конкретного приложения.

В листинге 21.5 показана наша программа main, получающая периодические анонсы SAP/SDP.

Листинг 21.5. Программа main, получающая периодические анонсы SAP/SDP

//mysdr/main.c
 1 #include "unp.h"

 2 #define SAP_NAME "sap.mcast.net" /* имя группы и порт по умолчанию */
 3 #define SAP_PORT "9875"

 4 void loop(int, socklen_t);

 5 int
 6 main(int argc, char **argv)
 7 {
 8  int sockfd;
 9  const int on = 1;
10  socklen_t salen;
11  struct sockaddr *sa;

12  if (argc == 1)
13   sockfd = Udp_client(SAP_NAME, SAP_PORT, (void**)&sa, &salen);
14  else if (argc == 4)
15   sockfd = Udp_client(argv[1], argv[2], (void**)&sa, &salen);
16  else
17   err_quit("usage: mysdr ");

18  Setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));
19  Bind(sockfd, sa, salen);

20  Mcast_join(sockfd, sa, salen, (argc == 4) ? argv[3], NULL, 0);

21  loop(sockfd, salen); /* получение и вывод */

22  exit(0);
23 }

Заранее известные имя и порт

2-3 Адрес многоадресной передачи, заданный для анонсов SAP — 224.2.127.254, а его имя — sap.mcast.net. Все заранее известные адреса многоадресной передачи (см. http://www.iana.org/assignments/multicast-addresses) появляются в DNS в иерархии mcast.net. Заранее известный порт UDP — это порт 9875.

Создание сокета UDP

12-17 Мы вызываем нашу функцию udp_client, чтобы просмотреть имя и порт, и она заполняет соответствующую структуру адреса сокета. Если не заданы аргументы командной строки, мы используем значения по умолчанию. В противном случае мы получаем адрес многоадресной передачи, порт и имя интерфейса из аргументов командной строки.

Связывание порта с помощью функции bind

18-19 Мы устанавливаем параметр сокета SO_REUSEADDR, чтобы позволить множеству экземпляров этой программы запуститься на узле, и с помощью функции bind связываем порт с сокетом. Связывая адрес многоадресной передачи с сокетом, мы запрещаем сокету получать какие-либо другие дейтаграммы UDP, которые могут быть получены для этого порта. Связывание этого адреса многоадресной передачи не является обязательным, но оно обеспечивает возможность фильтрации, благодаря чему ядро может не принимать пакеты, которые его не интересуют.

Присоединение к группе

20 Мы вызываем нашу функцию mcast_join, чтобы присоединиться к группе. Если имя интерфейса было задано в качестве аргумента командной строки, оно передается нашей функции, иначе мы позволяем ядру выбрать интерфейс, на котором будет происходить присоединение к группе.21 Мы вызываем нашу функцию loop, показанную в листинге 21.6, чтобы прочитать и вывести все анонсы.

Листинг 21.6. Цикл, получающий и выводящий анонсы SAP/SDP

//mysdr/loop.c
 1 #include "mysdr.h"

 2 void
 3 loop(int sockfd, socklen_t salen)
 4 {
 5  socklen_t len;
 6  ssize_t   n;
 7  char      *p;
 8  struct sockaddr *sa;
 9  struct sap_packet {
10   uint32_t sap_header;
11   uint32_t sap_src;
12   char     sap_data[BUFFSIZE];
13  } buf;

14  sa = Malloc(salen);

15  for (;;) {
15   len = salen;
17   n = Recvfrom(sockfd, &buf, sizeof(buf) - 1, 0, sa, &len);
18   ((char *)&buf)[n] = 0; /* завершающий нуль */
19   buf.sap_header = ntohl(buf.sap_header);
20   printf("From %s hash 0х%0х\n" Sock_ntop(sa, len),
21    buf.sap_header & SAP_HASH_MASK);
22   if (((buf.sap_header & SAP_VERSION_MASK) >> SAP_VERSION_SHIFT) > 1) {
23    err_msg("... version field not 1 (0x%08x)", buf.sap_header);
24    continue;
25   }
26   if (buf.sap_header & SAP_IPV6) {
27    err_msg("... IPv6");
28    continue;
29   }
30   if (buf.sap_header & (SAP_DELETE|SAP_ENCRYPTED|SAP_COMPRESSED)) {
31    err_msg("... can't parse this packet type (0x%80x)",
32    buf.sap_header);
33    continue;
34   }
35   p = buf.sap_data + ((buf.sap_header & SAP AUTHLEN_MASK)
36    >> SAP_AUTHLEN_SHIFT);
37   if (strcmp(p.,"application/sdp") == 0)
38    p += 16;
39   printf(%s\n", p);
40  }
41 }

Формат пакета

9-13 Структура sap_packet описывает пакет SDP: 32-разрядный заголовок SAP, за которым следует 32-разрядный адрес отправителя и сам анонс. Анонс представляет собой строки текста в стандарте ISO 8859-1 и не может превышать 1024 байта. В каждой дейтаграмме UDP допускается только один анонс сеанса.

Чтение дейтаграммы UDP, вывод параметров отправителя и содержимого

15-21 Функция recvfrom ждет следующую дейтаграмму UDP, предназначенную нашему сокету. Когда она приходит, мы помещаем в конец буфера пустой байт, исправляем порядок байтов заголовка и выводим адрес отправителя пакета и хэш SAP.

Проверка заголовка SAP

22-34 Мы проверяем заголовок SAP, чтобы убедиться, что он относится к одному из тех типов, с которыми мы умеем работать. Пакеты SAP с адресами IPv6 в заголовках, а также сжатые и зашифрованные пакеты мы не обрабатываем.

Поиск начала и вывод анонса

35-39 Мы пропускаем аутентифицирующие данные и тип пакета, после чего выводим содержимое оставшейся части.

В листинге 21.7 показано несколько типичных примеров результата выполнения нашей программы.

Листинг 21.7. Типичный анонс SAP/SDP

freebsd % mysdr
From 128.223.83.33:1028 hash 0x0000 v=0
o=- 60345 0 IN IP4 128.223.214.198
s=UO Broadcast - NASA Videos - 25 Years of Progress
i=25 Years of Progress, parts 1-13. Broadcast with Cisco System's
IP/TV using MPEG1 codec (6 hours 5 Minutes; repeats) More information
about IP/TV and the client needed to view this program is available
from http://videolab.uoregon.edu/download.html
u=http://videolab.uoregon.edu/
e=Hans Kuhn 
p=Hans Kuhn <541/346-1758>
b=AS:1000
t=0 0
a=type:broadcast
a=tool:IP/TV Content Manager 3.2.24
a=x-iptv-file:1 name y:25yop1234567890123.mpg
m=video 63096 RTP/AVP 32 31 96
c=IN IP4 224.2.245.25/127
a=framerate:30
a=rtpmap:96 WBIH/90000
a=x-iptv-svr:video blaster2.uoregon.edu file 1 loop
m=audio 31954 RTP/AVP 14 96 0 3 5 97 98 99 100 101 102 10 11 103 104 105 106
c=IN IP4 224.2.216.85/127
a=rtpmap:96 X-WAVE/8000
a=rtpmap:97 L8/8000/2
a=rtpmap:98 L8/8000
a=rtpmap:99 L8/22050/2
a=rtpmap:100 L8/22050
a=rtpmap:101 L8/11025/2
a=rtpmap:102 L8/11025
a=rtpmap:103 L16/22050/2
a=rtpmap:104 L16/22050
a=rtpmap:105 L16/11025/2
a=rtpmap:106 L16/11025
a=x-iptv-svr:audio blaster2.uoregon.edu file 1 loop

Этот анонс описывает рассылки, посвященные истории NASA (National Aeronautics and Space Administration — НАСА, государственная организация США, занимающаяся исследованием космоса). Описание сеанса SDP состоит из множества строк следующего формата:

type=value

где type всегда является одним символом, значение которого зависит от регистра, a value — это структурированная текстовая строка, зависящая от значения type. Пробелы справа и слева от знака равенства недопустимы. v=0 (в нашем случае) обозначает версию (version).

■o= обозначает источник (origin). В данном случае имя пользователя не указано, 60345 — идентификатор сеанса, 0 — номер версии этого сеанса, IN — тип сети, IР4 — тип адреса, 128.223.214.198 — адрес. В результате объединения этих пяти элементов — имя пользователя, идентификатор сеанса, тип сети, тип адреса и адрес — образуется глобально уникальный идентификатор сеанса.

■s= задает имя сеанса (session name), а i= — это информация о сеансе (information). u= указывает URI (Uniform Resource Identifier — уникальный идентификатор ресурса), по которому можно найти более подробную информацию по тематике данного сеанса, а р= и e= задают номер телефона (phone number) и адрес электронной почты (e-mail) ответственного за данную конференцию.

■b= позволяет оценить пропускную способность, необходимую для приема данного сеанса.

■t= задает время начала и время окончания сеанса в единицах NTP (Network Time Protocol — синхронизирующий сетевой протокол), то есть число секунд, прошедшее с 1 января 1900 года, измеренное в соответствии с UTC (Universal Time Coordinated — универсальное скоординированное время). Данный сеанс является постоянным и не имеет конкретных моментов начала и окончания, поэтому соответствующие времена полагаются нулевыми.

■ Строки a= представляют собой атрибуты, либо сеанса, если они помещены до первой строки m=, либо мультимедиа, если они помещены после первой строки m=.

■ Строки m= — это анонсы мультимедиа. Первая строка говорит нам о том, что видео передается на порт 63 096 в формате RTP с использованием профиля аудио и видео (Audio/Video Profile, AVP) с возможными типами данных 32, 31 и 96 (то есть MPEG, H.261 и WBIH соответственно). Строка c= сообщает о соединении. В данном случае используется протокол IPv4 с групповым адресом 224.2.245.25 и TTL = 127. Хотя между этими числами стоит символ «косая черта», как в формате CIDR, они ни в коем случае не должны трактоваться как префикс и маска.

Следующая строка m= говорит, что аудиопоток передается на порт 31 954 и может иметь один из типов RTP/AVP, некоторые из которых являются стандартными, в то время как другие указаны ниже в виде атрибутов a=rtpmap:. Строка с= сообщает нам сведения об аудиосоединении: IPv4 с групповым адресом 224.2.216.85 и TTL = 127.

21.10. Отправка и получение

Программа для получения анонсов сеанса многоадресной передачи, показанная в предыдущем разделе, могла только получать дейтаграммы многоадресной передачи. Теперь мы создадим простую программу, способную и отправлять, и получать дейтаграммы многоадресной передачи. Наша программа состоит из двух частей. Первая часть отправляет дейтаграмму многоадресной передачи определённой группе каждые 5 с. Эта дейтаграмма содержит имя узла отправителя и идентификатор процесса. Вторая часть программы — это бесконечный цикл, присоединяющийся к той группе, которой первая часть программы отправляет данные. В этом цикле выводится каждая полученная дейтаграмма (содержащая имя узла и идентификатор процесса отправителя). Это позволяет нам запустить программу на множестве узлов в локальной сети и посмотреть, какой узел получает дейтаграммы от каких отправителей.

В листинге 21.8 показана функция main нашей программы.

Листинг 21.8. Создание сокетов, вызов функции fork и запуск отправителя и получателя

//mcast/main.c
 1 #include "unp.h"

 2 void recv_all(int, socklen_t);
 3 void send_all(int. SA *, socklen_t);

 4 int
 5 main(int argc, char **argv)
 6 {
 7  int sendfd, recvfd;
 8  const int on = 1;
 9  socklen_t salen;
10  struct sockaddr *sasend, *sarecv;

11  if (argc != 3)
12   err_quit("usage: sendrecv ");

13  sendfd = Udp_client(argv[1], argv[2], (void**)&sasend, &salen);

14  recvfd = Socket(sasend->sa_family, SOCK_DGRAM, 0);

15  Setsockopt(recvfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));

16  sarecv = Malloc(salen);
17  memcpy(sarecv, sasend, salen);
18  Bind(recvfd, sarecv, salen);

19  Mcast_join(recvfd, sasend, salen, NULL, 0);
20  Mcast_set_loop(sendfd, 0);

21  if (Fork() == 0)
22   recv_all(recvfd, salen); /* дочерний процесс -> получение */

23  send_all(sendfd, sasend, salen); /* родитель -> отправка */
24 }

Мы создаем два сокета, один для отправки и один для получения. Нам нужно, чтобы принимающий сокет связался при помощи функции 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, и длину этой структуры.

Создание принимающего сокета и связывание (при помощи функции bind) с адресом многоадресной передачи и портом

14-18 Мы создаем принимающий сокет, используя то же семейство адресов, что и при создании отправляющего сокета, и устанавливаем параметр сокета SO_REUSEADDR, чтобы разрешить множеству экземпляров этой программы одновременно запускаться на узле. Затем мы выделяем в памяти пространство для структуры адреса этого сокета, копируем ее содержимое из структуры адреса отправляющего сокета (адрес и порт которого взяты из аргументов командной строки) и при помощи функции bind связываем адрес многоадресной передачи и порт с принимающим сокетом.

Присоединение к группе и выключение закольцовки

19-20 Мы вызываем нашу функцию mcast_join, чтобы присоединиться к группе на получающем сокете, а также нашу функцию mcast_set_loop, чтобы отключить закольцовку на отправляющем сокете. Для присоединения задаем имя интерфейса в виде пустого указателя и нулевой индекс интерфейса, что указывает ядру на необходимость выбрать интерфейс самостоятельно.

Функция fork и вызов соответствующих функций

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;

 9  safrom = Malloc(salen);

10  for (;;) {
11   len = salen;
12   n = Recvfrom(recvfd, line, MAXLINE, 0, safrom, &len);

13   line[n] = 0; /* завершающий нуль */
14   printf("from %s: %s", Sock_ntop(safrom, len), line);
15  }
16 }

Размещение в памяти структуры адреса сокета

9 При каждом вызове функции recvfrom в памяти выделяется пространство для структуры адреса сокета, в которую записывается адрес отправителя.

Чтение и вывод дейтаграмм

10-15 Каждая дейтаграмма считывается функцией recvfrom, дополняется символом конца строки (то есть нулем) и выводится.

Пример

Мы запускаем программу в двух системах: freebsd4 и macosx. Каждая система видит пакеты, отправляемые другой.

freebsd4 % sendrecv 239.255.1.2 8888
from 172.24.37.78:51297: macosx, 21891
from 172.24.37.78:51297: macosx, 21891
from 172.24.37.78:51297: macosx, 21891
from 172.24.37.78:51297: macosx, 21891

macosx % sendrecv 239.255.1.2 8888
from 172.24.37.94.1215: freebsd4, 55372
from 172.24.37.94.1215: freebsd4, 55372
from 172.24.37.94.1215: freebsd4, 55372
from 172.24.37.94.1215: freebsd4, 55372

21.11. SNTP: простой синхронизирующий сетевой протокол

Синхронизирующий сетевой протокол (Network Time Protocol, NTP) — это сложный протокол синхронизации часов в глобальной или локальной сети. Его точность часто может достигать миллисекунд. В RFC 1305 [76] этот протокол подробно описан, а в RFC 2030 [77] рассматривается протокол SNTP — упрощенная версия NTP, предназначенная для узлов, которым не требуется функциональность полной реализации NTP. Типичной является ситуация, когда несколько узлов в локальной сети синхронизируют свои часы через Интернет с другими узлами NTP, а затем распространяют полученное значение времени в локальной сети с использованием либо широковещательной, либо многоадресной передачи.

В этом разделе мы создадим клиент SNTP, который прослушивает широковещательные или групповые сообщения NTP на всех присоединенных сетях, а затем выводит разницу во времени между пакетом NTP и текущим истинным временем узла. Мы не пытаемся изменить это время, поскольку для этого необходимы права привилегированного пользователя.

Файл ntp.h, показанный в листинге 21.11, содержит некоторые из основных определений формата пакета NTP.

Листинг 21.11. Заголовок ntp.h: формат пакета NTP и определения

//ssntp/ntp.h
 1 #define JAN_1970 2208988800UL /* 1970 - 1900 в секундах */

 2 struct l_fixedpt { /* 64-разрядное число с фиксированной точкой */
 3  uint32_t int_part;
 4  uint32_t fraction;
 5 };

 6 struct s_fixedpt { /* 32-разрядное число с фиксированной точкой */
 7  u_short int_part;
 8  u_short fraction;
 9 };

10 struct ntpdata { /* заголовок NTP */
11  u_char status;
12  u_char stratum;
13  u_char ppoll;
14  int    precision:8;
15  struct s_fixedpt distance;
16  struct s_fixedpt dispersion;
17  uint32_t refid;
18  struct l_fixedpt reftime;
19  struct l_fixedpt org;
20  struct 1_fixedpt rec;
21  struct l_fixedpt xmt;
22 };

23 #define VERSION_MASK 0x38
24 #define MODE_MASK 0x07

25 #define MODE CLIENT 3
26 #define MODE_SERVER 4
27 #define MODE_BROADCAST 5

2-22 l_fixedpt задает 64-разрядные числа с фиксированной точкой, используемые NTP для отметок времени, a s_fixedpt — 32-разрядные значения с фиксированной точкой, также используемые NTP. Структура ntpdata представляет 48-байтовый формат пакета NTP.

В листинге 21.12 пpeдcтaвлeнa функция main.

Листинг 21.12. Функция main

//ssntp/main.c
 1 #include "sntp.h"

 2 int
 3 main(int argc, char **argv)
 4 {
 5  int sockfd;
 6  char buf[MAXLINE];
 7  ssize_t n;
 8  socklen_t salen, len;
 9  struct ifi_info *ifi;
10  struct sockaddr *mcastsa, *wild, *from;
11  struct timeval now;

12  if (argc != 2)
13   err_quit("usage: ssntp ");

14  sockfd = Udp_client(argv[1], "ntp", (void**)&mcastsa, &salen);

15  wild = Malloc(salen);
16  memcpy(wild, mcastsa. salen); /* копируем семейство и порт */
17  sock_set_wild(wild, salen);

18  Bind(sockfd, wild, salen); /* связываем сокет с универсальным[3]

                                  адресом */

19 #ifdef MCAST
20  /* получаем список интерфейсов и обрабатываем каждый интерфейс */
21  for (ifi = Get_ifi_info(mcastsa->sa_family, 1); ifi != NULL;
22   ifi = ifi->ifi_next) {
23   if (ifi->ifi_flags & IFF_MULTICAST) {
24    Mcast_join(sockfd, mcastsa, salen, ifi->ififname, 0);
25    printf("joined %s on %s\n",
26     Sock_ntop(mcastsa, salen), ifi->ifi_name);
27   }
28  }
29 #endif

30  from = Malloc(salen);
31  for (;;) {
32   len = salen;
33   n = Recvfrom(sockfd, buf, sizeof(buf), 0, from, &len);
34   Gettimeofday(&now, NULL);
35   sntp_proc(buf, n, &now);
36  }
37 }

Получение IP-адреса многоадресной передачи

12-14 При выполнении программы пользователь должен задать в качестве аргумента командной строки адрес многоадресной передачи, к которому он будет присоединяться. В случае IPv4 это будет 224.0.1.1 или имя ntp.mcast.net. В случае IPv6 это будет ff05::101 для области действия NTP, локальной в пределах сайта. Наша функция udp_client выделяет в памяти пространство для структуры адреса сокета корректного типа (либо IPv4, либо IPv6) и записывает адрес многоадресной передачи и порт в эту структуру. Если эта программа выполняется на узле, не поддерживающем многоадресную передачу, может быть задан любой IP-адрес, так как в этой структуре задействуются только семейство адресов и порт. Обратите внимание, что наша функция udp_client не связывает адрес с сокетом (то есть не вызывает функцию bind) — она лишь создает сокет и заполняет структуру адреса сокета.

Связывание универсального адреса с сокетом

15-18 Мы выделяем в памяти пространство для другой структуры адреса сокета и заполняем ее, копируя структуру, заполненную функцией udp_client. При этом задаются семейство адреса и порт. Мы вызываем нашу функцию sock_set_wild, чтобы присвоить IP-адресу универсальный адрес, а затем вызываем функцию bind.

Получение списка интерфейсов

20-22 Наша функция get_ifi_info возвращает информацию обо всех интерфейсах и адресах. Запрашиваемое нами семейство адреса берется из структуры адреса сокета, заполненной функцией udp_client на основе аргумента командной строки.

Присоединение к группе

23-27 Мы вызываем нашу функцию mcast_join, чтобы присоединиться к группе, заданной аргументом командной строки для каждого интерфейса, поддерживающего многоадресную передачу. Все эти присоединения происходят на одном сокете, который использует эта программа. Как отмечалось ранее, количество присоединений на одном сокете ограничено константой IP_MAX_MEMBERSHIPS (которая обычно имеет значение 20), но лишь немногие многоинтерфейсные узлы используют столько интерфейсов.

Чтение и обработка всех пакетов NTP

30-36 В памяти размещается другая структура адреса сокета для хранения адреса, возвращаемого функцией recvfrom, и программа входит в бесконечный цикл, считывая все пакеты NTP, которые получает узел, и вызывая нашу функцию sntp_proc (описывается далее) для обработки пакета. Поскольку сокет был связан с универсальным адресом и присоединение к группе произошло на всех интерфейсах, поддерживающих многоадресную передачу, сокет должен получить любой пакет NTP направленной, широковещательной или многоадресной передачи, получаемый узлом. Перед вызовом функции sntp_proc мы вызываем функцию gettimeofday, чтобы получить текущее время, потому что функция sntp_proc вычисляет разницу между временем пакета и текущим временем.

Наша функция sntp_proc, показанная в листинге 21.13, обрабатывает пакет NTP.

Листинг 21.13. Функция sntp_proc: обработка пакета NTР

//ssntp/sntp_proc.c
 1 #include "sntp.h"

 2 void
 3 sntp proc(char *buf, ssize_t n, struct timeval *nowptr)
 4 {
 5  int version, mode;
 6  uint32_t nsec, useci;
 7  double usecf;
 8  struct timeval diff;
 9  struct ntpdata *ntp;

10  if (n < (ssize_t)sizeof(struct ntpdata)) {
11   printf("\npacket too small: %d bytes\n", n);
12   return;
13  }

14  ntp = (struct ntpdata*)buf;
15  version = (ntp->status & VERSION_MASK) >> 3;
16  mode = ntp->status & MODE_MASK;
17  printf("\nv%d, mode %d, strat %d, ", version, mode, ntp->stratum);
18  if (mode == MODE_CLIENT) {
19   printf("client\n");
20   return;
21  }

22  nsec = ntohl(ntp->xmt.int_part) - JAN_1970;
23  useci = ntohl(ntp->xmt.fraction); /* 32-разрядная дробь */
24  usecf = useci; /* дробь в double */
25  usecf /= 4294967296.0; /* деление на 2**32 -> [0, 1.0) */
26  useci = usecf * 1000000.0; /* дробь в миллионную часть */

27  diff.tv_sec = nowptr->tv_sec - nsec;
28  if ((diff.tv_usec = nowptr->tv_usec - useci) < 0) {
29   diff.tv_usec += 1000000;
30   diff.tv_sec--;
31  }
32  useci = (diff.tv_sec * 1000000) + diff.tv_usec; /* diff в мс */
33  printf("clock difference = %d usec\n", useci);
34 }

Ратификация пакета

10-21 Сначала мы проверяем размер пакета, затем выводим его версию, режим и слой (stratum) сервера. Если режимом является MODE_CLIENT, пакет является запросом клиента, а не ответом сервера, и мы игнорируем его.

Получение времени передачи из пакета NTP

22-34 В пакете NTP нас интересует поле xmt — отметка времени. Это 64-разрядное значение с фиксированной точкой, определяющее момент отправки пакета сервером. Поскольку отметки времени NTP отсчитывают секунды начиная с 1 января 1900 года, а отметки времени Unix — с 1 января 1970 года, сначала мы вычитаем JAN_1970 (число секунд в 70 годах) из целой части.

Дробная часть — это 32-разрядное целое без знака, которое может принимать значение от 0 до 4 294 967 295 включительно. Оно копируется из 32-разрядного целого (usecf) в переменную с плавающей точкой двойной точности (usecf) и делится на 4 294 967 296 (2³²). Результат больше либо равен 0.0 и меньше 1.0. Мы умножаем это число на 1 000 000 — число микросекунд в секунде, записывая результат в переменную useci как 32-разрядное целое без знака.

Число микросекунд лежит в интервале от 0 до 999 999 (см. упражнение 21.5). Мы преобразуем значение в микросекунды, поскольку отметка времени Unix, возвращаемая функцией gettimeofday, возвращается как два целых числа: число секунд и число микросекунд, прошедшее с 1 января 1970 года (UTC). Затем мы вычисляем и выводим разницу между истинным временем узла и истинным временем сервера NTP в микросекундах.

Один из факторов, не учитываемых нашей программой, — это задержка в сети между клиентом и сервером. Но мы считаем, что пакеты NTP обычно приходят как широковещательные или многоадресные пакеты в локальной сети, а в этом случае задержка в сети составит всего несколько миллисекунд.

Если мы запустим эту программу на узле macosx с сервером NTP на узле freebsd4, который с помощью многоадресной передачи отправляет пакеты NTP в сеть Ethernet каждые 64 с, то получим следующий результат:

macosx # ssntp 224.0.1.1
joined 224.0.1.1.123 on lo0
joined 224.0.1.1.123 on en1
v4, mode 5, strat 3, clock difference = 661 usec
v4, mode 5, strat 3, clock difference = -1789 usec
v4, mode 5, strat 3, clock difference = -2945 usec
v4, mode 5, strat 3, clock difference = -3689 usec
v4, mode 5, strat 3, clock difference = -5425 usec
v4, mode 5, strat 3, clock difference = -6700 usec
v4, mode 5, strat 3, clock difference = -8520 usec

Перед запуском нашей программы мы завершили на узле работу NTP-сервера, поэтому когда наша программа запускается, время очень близко к времени сервера. Мы видим, что этот узел отстал на 9181 мс за 384 с работы программы, то есть за 24 ч он отстанет на 2 с.

21.12. Резюме

Для запуска приложения многоадресной передачи в первую очередь требуется присоединиться к группе, заданной для этого приложения. Тем самым уровень IP получает указание присоединиться к группе, что, в свою очередь, указывает канальному уровню на необходимость получать кадры многоадресной передачи, отправляемые на соответствующий адрес многоадресной передачи аппаратного уровня. Многоадресная передача использует преимущество аппаратной фильтрации, имеющееся у большинства интерфейсных карт, и чем качественнее фильтрация, тем меньше число нежелательных получаемых пакетов. Использование аппаратной фильтрации сокращает нагрузку на все узлы, не задействованные в приложении.

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

API для многоадресной передачи обеспечивают девять параметров сокетов:

■ присоединение к группе на интерфейсе;

■ выход из группы;

■ блокирование передачи от источника;

■ разблокирование заблокированного источника;

■ присоединение интерфейса к группе многоадресной передачи от источника;

■ выход из группы многоадресной передачи от источника;

■ установка интерфейса по умолчанию для исходящих пакетов многоадресной передачи;

■ установка значения TTL или предельного количества транзитных узлов для исходящих пакетов многоадресной передачи;

■ включение или отключение закольцовки для пакетов многоадресной передачи.

Первые шесть параметров предназначены для получения пакетов многоадресной передачи, последние три — для отправки. Существует достаточно большая разница между указанными параметрами сокетов IPv4 и IPv6. Вследствие этого код многоадресной передачи, зависящий от протокола, очень быстро становится «замусорен» директивами #ifdef. Мы разработали 12 наших собственных функций с именами, начинающимися с mcast_, для упрощения написания приложений многоадресной передачи, работающих как с IPv4, так и с IPv6.

Упражнения

1. Скомпилируйте программу, показанную в листинге 20.5, и запустите ее, задав в командной строке IP-адрес 224.0.0.1. Что произойдет?

2. Измените программу из предыдущего примера, чтобы связать IP-адрес 224.0.0.1 и порт 0 с сокетом. Запустите ее. Разрешается ли вам связывать адрес многоадресной передачи с сокетом при помощи функции bind? Если у вас есть такая программа, как tcpdump, понаблюдайте за пакетами в сети. Каков IP-адрес отправителя посылаемой вами дейтаграммы?

3. Один из способов определить, какие узлы в вашей подсети имеют возможность многоадресной передачи, заключается в запуске утилиты ping для группы всех узлов, то есть для адреса 224.0.0.1. Попробуйте это сделать.

4. Одним из способов обнаружения маршрутизаторов многоадресной передачи в вашей подсети является запуск утилиты ping для группы всех маршрутизаторов — 224.0.0.2. Попробуйте это сделать.

5. Один из способов узнать, соединен ли ваш узел с многоадресной IP-инфраструктурой — запустить нашу программу из раздела 21.9, подождать несколько минут и посмотреть, появляются ли анонсы сеанса. Попробуйте сделать это и посмотрите, получите ли вы какие-нибудь анонсы.

6. Выполните вычисления в листинге 21.12 при условии, что дробная часть отметки времени NTP равна 1 073 741 824 (одна четвертая от 2³²).

Выполните еще раз эти же вычисления для максимально возможной дробной части (2³² - 1).

Измените реализацию функции mcast_set_if для IPv4 так, чтобы запоминать имя каждого интерфейса, для которого она получает IP-адрес. Это позволит избежать нового вызова функции ioctl для данного интерфейса.

Глава 22