2. Если локальный IP-адрес связан с символьным сокетом функцией
bind
, IP-адрес получателя в полученной дейтаграмме должен совпадать с этим адресом, иначе дейтаграмма не посылается данному сокету.
3. Если для символьного сокета был определен внешний адрес с помощью функции
connect
, IP-адрес отправителя в полученной дейтаграмме должен совпадать с этим адресом, иначе дейтаграмма не посылается данному сокету.
Следует отметить, что если символьный сокет создан с нулевым значением аргумента
protocol
и не вызывается ни функция
bind
, ни функция
connect
, то сокет получает копии всех дейтаграмм, которые ядро направляет символьным сокетам.
Дейтаграммы IPv4 всегда передаются
через символьные сокеты целиком, вместе с заголовками. В версии IPv6 символьному сокету передается все, кроме дополнительных заголовков (см., например, рис. 28.4 и 28.6).
ПРИМЕЧАНИЕ
В заголовке IPv4, передаваемом приложению, для ip_len, ip_off и ip_id установлен порядок байтов узла, а все остальные ноля имеют порядок байтов сети. В системе Linux все поля остаются в сетевом порядке байтов.
Как уже говорилось, интерфейс символьных сокетов определяется таким образом, чтобы работа со всеми протоколами, в том числе и не обрабатываемыми ядром, осуществлялась одинаково. Поэтому содержимое полей зависит от ядра операционной системы.
В предыдущем разделе мы отметили, что все ноля символьного сокета IPv6 остаются в сетевом порядке байтов.
Фильтрация по типу сообщений ICMPv6
Символьный сокет ICMPv4 получает большинство сообщений ICMPv4, полученных ядром. Но ICMPv6 является расширением ICMPv4, включающим функциональные возможности ARP и IGMP (см. раздел 2.2). Следовательно, символьный сокет ICMPv6 потенциально может принимать гораздо больше пакетов по сравнению с символьным сокетом ICMPv4. Но большинство приложений, использующих символьные сокеты, заинтересованы только в небольшом подмножестве всех ICMP-сообщений.
Для уменьшения количества пакетов, передаваемых от ядра к приложению через символьный ICMPv6-сокет, предусмотрен фильтр, связанный с приложением. Фильтр объявляется с типом данных
struct icmp6_filter
, который определяется в заголовочном файле
<netinet/icmp6.h>
. Для установки и получения текущего ICMPv6-фильтра для символьного сокета ICMPv6 используются функции
int ICMP6_FILTER_WILLPASS(int msgtype, const struct icmp6_filter * filt);
int ICMP6_FILTER_WILLBLOCK(int msgtype, const struct icmp6_filter * filt);
Все возвращают: 1, если фильтр пропускает (блокирует) сообщение данного типа, 0 в противном случае
Аргумент
filt
всех макрокоманд является указателем на переменную
icmp6_filter
, изменяемую первыми четырьмя макрокомандами и проверяемую последними двумя. Аргумент
msgtype
является значением в интервале от 0 до 255, определяющим тип ICMP-сообщения.
Макрокоманда
SETPASSALL
указывает, что все типы сообщений должны пересылаться приложению, а макрокоманда
SETBLOCKALL
— что никакие сообщения не должны посылаться приложениям. По умолчанию при создании символьного сокета ICMPv6 подразумевается, что все типы ICMP-сообщений пересылаются приложению.
Макрокоманда
SETPASS
определяет конкретный тип сообщений, который должен пересылаться приложению, а макрокоманда
SETBLOCK
блокирует один конкретный тип сообщений. Макрокоманда
WILLPASS
возвращает значение 1, если определенный тип пропускается фильтром. Макрокоманда
WILLBLOCK
возвращает значение 1, если определенный тип блокирован фильтром, и нуль в противном случае.
В качестве примера рассмотрим приложение, которое будет получать только ICMPv6-извещения маршрутизатора:
Сначала мы блокируем все типы сообщений (поскольку по умолчанию все типы сообщений пересылаются), а затем разрешаем пересылать только извещения маршрутизатора. Несмотря на то, что мы используем фильтр, приложение должно быть готово к получению всех типов пакетов ICMPv6, потому что любые пакеты ICMPv6, полученные между вызовами
socket
и
setsockopt
, будут добавлены в очередь на сокете. Параметр
ICMP6_FILTER
— лишь средство оптимизации условий функционирования приложения.
28.5. Программа ping
В данном разделе приводится версия программы
ping
, работающая как с IPv4, так и с IPv6. Вместо того чтобы представить известный доступный исходный код, мы разработали оригинальную программу, и сделано это по двум причинам. Во-первых, свободно доступная программа
ping
страдает общей болезнью программирования, известной как «ползучий улучшизм» (стремление к постоянным ненужным усложнениям программы в погоне за мелкими улучшениями): она поддерживает 12 различных параметров. Наша цель при исследовании программы
ping
в том, чтобы понять концепции и методы сетевого программирования и не быть при этом сбитыми с толку ее многочисленными параметрами. Наша версия программы
ping
поддерживает только один параметр и занимает в пять раз меньше места, чем общедоступная версия. Во-вторых, общедоступная версия работает только с IPv4, а нам хочется показать версию, поддерживающую также и IPv6.
Действие программы ping предельно просто: по некоторому IP-адресу посылается эхо-запрос ICMP, и этот узел отвечает эхо-ответом ICMP. Оба эти сообщения поддерживаются в обеих версиях — и в IPv4, и в IPv6. На рис. 28.1 приведен формат ICMP-сообщений.
Рис. 28.1. Формат сообщений эхо-запроса и эхо-ответа ICMPv4 и ICMPv6
В табл. А.5 и А.6 приведены значения поля тип( type) для этих сообщений и говорится, что значение поля код( code) равно нулю. Далее будет показано, что в поле идентификатор( identifier) указывается идентификатор процесса
ping
, а значение поля порядковый номер (sequence number) увеличивается на 1 для каждого отправляемого пакета. В поле дополнительные данные( optional data) сохраняется 8-байтовая отметка времени отправки пакета. Правила ICMP-запроса требуют, чтобы идентификатор, порядковый номери все дополнительные данные возвращались в эхо-ответе. Сохранение отметки времени отправки пакета позволяет вычислить RTT при получении ответа.