Уильям Стивенс - UNIX: разработка сетевых приложений
int bind(int, struct sockaddr*, socklen_t);
При этом требуется, чтобы для любых вызовов этих функций указатель на структуру адреса сокета, специфичную для протокола, был преобразован в указатель на универсальную структуру адреса сокета. Например:
struct sockaddr_in serv; /* структура адреса сокета IPv4 */
/* заполняем serv{} */
bind(sockfd, (struct sockaddr*)&serv, sizeof(serv));
Если мы не выполним преобразование (struct sockaddr*), компилятор С сгенерирует предупреждение в форме "Warning: passing arg 2 of 'bind' from incompatible pointer type" (Передается указатель несовместимого типа). Здесь мы предполагаем, что в системных заголовочных файлах имеется прототип ANSI С для функции bind.
С точки зрения разработчика приложений, универсальная структура адреса сокета используется только для преобразования указателей на структуры адресов конкретных протоколов.
ПРИМЕЧАНИЕВспомните, что в нашем заголовочном файле unp.h (см. раздел 1.2) мы определили SA как строку "struct sockaddr", чтобы сократить код, который мы написали для преобразования этих указателей.
С точки зрения ядра основанием использовать в качестве аргументов указатели на универсальные структуры адреса сокетов является то, что ядро должно получать указатель вызывающей функции, преобразовывать его в struct sockaddr, а затем по значению элемента sa_family определять тип структуры. Но разработчику приложений было бы проще работать с указателем void*, поскольку это избавило бы его от необходимости выполнять явное преобразование указателя.
Структура адреса сокета IPv6
Структура адреса сокета IPv6 задается при помощи включения заголовочного файла <netinet/in.h>, как показано в листинге 3.3.
Листинг 3.3. Структура адреса сокета IPv6: sockaddr_in6
struct in6_addr {
uint8_t s6_addr[16]; /* 128-разрядный адрес IPv6 */
/* сетевой порядок байтов */
};
#define SIN6_LEN /* требуется для проверки во время компиляции */
struct sockaddr_in6 {
uint8_t sin_len; /* длина этой структуры (24) */
sa_family_t sin6_family; /* AF_INET6 */
in_port_t sin6_port; /* номер порта транспортного уровня */
/* сетевой порядок байтов */
uint32_t sin6_flowinfo; /* приоритет и метка потока */
/* сетевой порядок байтов */
struct in6_addr sin6_addr; /* IPv6-адрес */
/* сетевой порядок байтов */
uint32_t sin6_scope_id; /* набор интерфейсов */
};
ПРИМЕЧАНИЕРасширения API сокетов для IPv6 описаны в RFC 3493 [36].
Отметим следующие моменты относительно листинга 3.3:
■ Константа SIN6_LEN должна быть задана, если система поддерживает поле длины для структур адреса сокета.
■ Семейством IPv6 является AF_INET6, в то время как семейство IPv4 — AF_INET.
■ Элементы в структуре упорядочены таким образом, что если структура sockaddr_in6 выровнена по 64 битам, то так же выровнен и 128-разрядный элемент sin6_addr. На некоторых 64-разрядных процессорах доступ к данным с 64-разрядными значениями оптимизирован, если данные выровнены так, что их адрес кратен 64.
■ Элемент sin6_flowinfo разделен на три поля:
□ 20 бит младшего порядка — это метка потока;
□ следующие 12 бит зарезервированы.
Поле метки потока и поле приоритета рассматриваются в описании рис. А.2. Отметим, что использование поля приоритета еще не определено.
■ Элемент sin6_scope_id определяет контекст, в котором действует контекстный адрес (scoped address). Чаще всего это бывает индекс интерфейса для локальных адресов (см. раздел А.5).
Новая универсальная структура адреса сокета
Новая универсальная структура адреса сокета была определена как часть API сокетов IPv6 с целью преодолеть некоторые недостатки существующей структуры sockaddr. В отличие от структуры sockaddr, новая структура sockaddr_storage достаточно велика для хранения адреса сокета любого типа, поддерживаемого системой. Новая структура задается подключением заголовочного файла <netinet/in.h>, часть которого показана в листинге 3.4.
Листинг 3.4. Структура хранения адреса сокета sockaddr_storage
struct sockaddr_storage {
uint8_t ss_len; /* длина этой структуры (зависит от реализации) */
sa_family_t ss_family; /* семейство адреса. AF_xxx */
/* зависящие от реализации элементы, обеспечивающие:
а) выравнивание, достаточное для выполнения требований по выравниванию всех
типов адресов сокетов, поддерживаемых системой;
б) достаточный объем для хранения адреса сокета любого типа,
поддерживаемого системой. */
};
Тип sockaddr_storage — это универсальная структура адреса сокета, отличающаяся от struct sockaddr по следующим параметрам:
1. Если к структурам адресов сокетов, поддерживаемым системой, предъявляются требования по выравниванию, структура sockaddr_storage выполняет самое жесткое из них.
2. Структура sockaddr_storage достаточно велика для размещения любой структуры адреса сокета, поддерживаемой системой.
Заметьте, что поля структуры sockaddr_storage непрозрачны для пользователя, за исключением ss_family и ss_len (если таковые заданы). Структура sockaddr_storage должна преобразовываться в структуру адреса соответствующего типа для обращения к содержимому остальных полей.
Сравнение структур адреса сокетов
На рис. 3.1 показано сравнение пяти структур адресов сокетов, с которыми мы встретимся в тексте, предназначенных для IPv4, IPv6, доменного сокета Unix (см. листинг 15.1), канального уровня (см. листинг 18.1) и хранения. Подразумевается, что все структуры адреса сокета содержат 1-байтовое поле длины, поле семейства также занимает 1 байт и длина любого поля, размер которого ограничен снизу, в точности равна этому ограничению.
Рис. 3.1. Сравнение различных структур адресов сокетов
Две структуры адреса сокета имеют фиксированную длину, а структура доменного сокета Unix и структура канального уровня — переменную. При обработке структур переменной длины мы передаем функциям сокетов указатель на структуру адреса сокета, а в другом аргументе передаем длину этой структуры. Под каждой структурой фиксированной длины мы показываем ее размер в байтах (для реализации 4.4BSD).
ПРИМЕЧАНИЕСама структура sockaddr_un имеет фиксированную длину, но объем информации в ней — длина полного имени (pathname) — может быть переменным. Передавая указатели на эти структуры, следует соблюдать аккуратность при обработке поля длины — как длины в структуре адреса сокета (если поле длины поддерживается данной реализацией), так и длины данных, передаваемых ядру и принимаемых от него.
Этот рисунок служит также иллюстрацией стиля, которого мы придерживаемся в этой книге: названия структур на рисунках всегда выделяются полужирным шрифтом, а за ними следуют фигурные скобки.
Ранее отмечалось, что в реализации 4.3BSD Reno ко всем структурам адресов сокетов было добавлено поле длины. Если бы поле длины присутствовало в оригинальной реализации сокетов, то не возникло бы необходимости передавать аргумент длины функциям сокетов (третий аргумент функций bind и connect). Вместо этого размер структуры мог бы храниться в поле длины структуры.
3.3. Аргументы типа «значение-результат»
Мы отмечали, что когда структура адреса сокета передается какой-либо из функций сокетов, она всегда передается по ссылке, то есть в качестве аргумента передается указатель на структуру. Длина структуры также передается в качестве аргумента. Но способ, которым передается длина, зависит от того, в каком направлении передается структура: от процесса к ядру или наоборот.
1. Три функции bind, connect и sendto передают структуру адреса сокета от процесса к ядру. Один из аргументов этих функций — указатель на структуру адреса сокета, другой аргумент — это целочисленный размер структуры, как показано в следующем примере:
struct sockaddr_in serv;
/* заполняем serv{} */
connect(sockfd, (SA*)&serv, sizeof(serv));
Поскольку ядру передается и указатель, и размер структуры, на которую он указывает, становится точно известно, какое количество данных нужно скопировать из процесса в ядро. На рис. 3.2 показан этот сценарий.
Рис. 3.2. Структура адреса сокета, передаваемая от процесса к ядру
