Текст книги "UNIX: разработка сетевых приложений"

Автор книги: Уильям Ричард Стивенс

Соавторы: Эндрю М. Рудофф,Билл Феннер
сообщить о нарушении

Текущая страница: 8 (всего у книги 88 страниц) [доступный отрывок для чтения: 32 страниц]

Универсальная структура адреса сокета

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

Проблема в том, как объявить тип передаваемого указателя. Для ANSI С решение простое: void*является указателем на неопределенный (универсальный) тип (generic pointer type). Но функции сокетов существовали до появления ANSI С, и в 1982 году было принято решение определить универсальнуюструктуру адреса сокета (generic socket address structure) в заголовочном файле , которая показана в листинге 3.2.

Листинг 3.2. Универсальная структура адреса сокета: sockaddr

struct sockaddr {

 uint8_t sa_len;

 sa_family_t sa_family; /* семейство адресов: константа AF_xxx */

 char sa_data[14];      /* адрес, специфичный для протокола */

};

Функции сокетов определяются таким образом, что их аргументом является указатель на общую структуру адреса сокета, как показано в прототипе функции bind(ANSI С):

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

В следующей главе мы увидим, что размер структуры адреса сокета в действительности имеет тип socklen_t, а не int, но POSIX рекомендует определять socklen_t как uint32_t.

2. Четыре функции accept, recvfrom, getsocknameи getpeernameпередают структуру адреса сокета от ядра к процессу, то есть в направлении, противоположном предыдущему случаю. Этим функциям передается указатель на структуру адреса сокета и указатель на целое число, содержащее размер структуры, как показано в следующем примере:

struct sockaddr_un cli; /* домен Unix */

socklen_t len;

len = sizeof(cli);      /* len – это значение */

getpeername(unixfd, (SA*)&cli, &len);

/* значение len могло измениться */

Причина замены типа для аргумента «длина» с целочисленного на указатель состоит в том, что «длина» эта является и значениемпри вызове функции (сообщает ядру размер структуры, так что ядро при заполнении структуры знает, где нужно остановиться), и результатом, когда функция возвращает значение (сообщает процессу, какой объем информации ядро действительно сохранило в этой структуре). Такой тип аргумента называется аргументом типа «значение-результат»( value-result argument). На рис. 3.3 представлен этот сценарий.

Рис. 3.3. Структура адреса сокета, передаваемая от ядра к процессу

Пример аргументов типа «значение-результат» вы увидите в листинге 4.2.

Если при использовании аргумента типа «значение-результат» для длины структуры структура адреса сокета имеет фиксированную длину (см. рис. 3.1), то значение, возвращаемое ядром, будет всегда равно этому фиксированному размеру: 16 для sockaddr_inIPv4 и 24 для sockaddr_in6IPv6. Для структуры адреса сокета переменной длины (например, sockaddr_unдомена Unix) возвращаемое значение может быть меньше максимального размера структуры (вы увидите это в листинге 15.2).

ПРИМЕЧАНИЕ

Мы говорили о структурах адресов сокетов, передаваемых между процессом и ядром. Для такой реализации, как 4.4BSD, где все функции сокетов являются системными вызовами внутри ядра, это верно. Но в некоторых реализациях, особенно в System V, функции сокетов являются лишь библиотечными функциями, которые выполняются как часть обычного пользовательского процесса. То, как эти функции взаимодействуют со стеком протоколов в ядре, относится к деталям реализации, которые обычно нас не волнуют. Тем не менее для простоты изложения мы будем продолжать говорить об этих структурах как о передаваемых между процессом и ядром такими функциями, как bind и connect. (В разделе В.1 вы увидите, что реализации System V действительно передают пользовательские структуры адресов сокетов между процессом и ядром, но как часть сообщений потоков STREAMS.)

Существует еще две функции, передающие структуры адресов сокетов: это recvmsg и sendmsg (см. раздел 14.5). Однако при их вызове поле длины не является отдельным аргументом функции, а передается как одно из полей структуры.

В сетевом программировании наиболее общим примером аргумента типа «значение-результат» может служить длина возвращаемой структуры адреса сокета. Вы встретите и другие аргументы типа «значение-результат»:

■ Три средних аргумента функции select(раздел 6.3).

■ Аргумент «длина» для функции getsockopt(см. раздел 7.2).

■ Элементы msg_namelenи msg_controllenструктуры msghdrпри использовании с функцией recvmsg(см. раздел 14.5).

■ Элемент ifc_lenструктуры ifconf(см. листинг 17.1).

■ Первый из двух аргументов длины в функции sysctl(см. раздел 18.4).

3.4. Функции определения порядка байтов

Рассмотрим 16-разрядное целое число, состоящее из двух байтов. Возможно два способа хранения этих байтов в памяти. Такое расположение, когда первым идет младший байт, называется прямым порядком байтов( little-endian), а когда первым расположен старший байт – обратным порядком байтов( big-endian). На рис. 3.4 показаны оба варианта.

Рис. 3.4. Прямой и обратный порядок байтов для 16-разрядного целого числа

Сверху на этом рисунке изображены адреса, возрастающие справа налево, а снизу – слева направо. Старший бит( most significant bit, MSB) является в 16-разрядном числе крайним слева, а младший бит( least significant bit, LSB) – крайним справа.

ПРИМЕЧАНИЕ

Термины «прямой порядок байтов» и «обратный порядок байтов» указывают, какой конец многобайтового значения – младший байт или старший – хранится в качестве начального адреса значения.

К сожалению, не существует единого стандарта порядка байтов, и можно встретить системы, использующие оба формата. Способ упорядочивания байтов, используемый в конкретной системе, мы называем порядком байтов узла( host byte order). Программа, представленная в листинге 3.5, выдает порядок байтов узла.

Листинг 3.5. Программа для определения порядка байтов узла

//intro/byteorder.c

 1 #include "unp.h"

 2 int

 3 main(int argc, char **argv)

 4 {

 5  union {

 6   short s;

 7   char c[sizeof(short)];

 8  } un;

 9  un.s = 0x0102;

10  printf("%s: ", CPU_VENDOR_OS);

11  if (sizeof(short) == 2) {

12   if (un.c[0] == 1 && un.c[1] == 2)

13    printf("big-endiann");

14   else if (un.c[0] == 2 && un.c[1] == 1)

15    printf("little-endiann");

16   else

17    printf("unknownn");

18  } else

19   printf('sizeof(short) = %dn", sizeof(short));

20  exit(0);

21 }

Мы помещаем двухбайтовое значение 0x0102в переменную типа short(короткое целое) и проверяем значения двух байтов этой переменной: с[0](адрес А на рис. 3.4) и c[1](адрес А + 1 на рис. 3.4), чтобы определить порядок байтов.

Константа CPU_VENDOR_OSопределяется программой GNU (аббревиатура «GNU» раскрывается рекурсивно – GNU's Not Unix) autoconfв процессе конфигурации, необходимой для выполнения программ из этой книги. В этой константе хранится тип центрального процессора, а также сведения о производителе и реализации операционной системы. Ниже представлены некоторые примеры вывода этой программы при запуске ее в различных системах (см. рис. 1.7).

freebsd4 % byteorder

i386-unknown-freebsd4.8: little-endian

macosx % byteorder

powerpc-apple-darwin6.6: big-endian

freebsd5 % byteorder

sparc64-unknown-freebsd5.1: big-endian

aix % byteorder

powerpc-ibm-aix5.1.0.0: big-endian

hpux % byteorder

hppa1.1-hp-ux11 11: big-endian

linux % byteorder

i586-pc-linux-gnu: little-endian

solaris % byteorder

sparc-sun-solaris2.9: big-endian

Все, что было сказано об определении порядка байтов 16-разрядного целого числа, конечно, справедливо и в отношении 32-разрядного целого.

ПРИМЕЧАНИЕ

Существуют системы, в которых возможен переход от прямого к обратному порядку байтов либо при перезапуске системы (MIPS 2000), либо в любой момент выполнения программы (Intel i860).

Разработчикам сетевых приложений приходится обрабатывать различия в определении порядка байтов, поскольку в сетевых протоколах используется сетевой порядок байтов( network byte order). Например, в сегменте TCP есть 16– разрядный номер порта и 32-разрядный адрес IPv4. Стеки отправляющего и принимающего протоколов должны согласовывать порядок, в котором передаются байты этих многобайтовых полей. Протоколы Интернета используют обратный порядок байтов.

Теоретически реализация Unix могла бы хранить поля структуры адреса сокета в порядке байтов узла, а затем выполнять необходимые преобразования при перемещении полей в заголовки протоколов и обратно, позволяя нам не беспокоиться об этом. Но исторически и с точки зрения POSIX определяется, что для некоторых полей в структуре адреса сокета порядок байтов всегда должен быть сетевым. Поэтому наша задача – выполнить преобразование из порядка байтов узла в сетевой порядок и обратно. Для этого мы используем следующие четыре функции:

#include

uint16_t htons(uint16_t host16bitvalue);

uint32_t htonl(uint32_t host32bitvalue);

Обе функции возвращают значение, записанное в сетевом порядке байтов

uint16_t ntohs(uint16_t net16bitvalue);

uint32_t ntohl(uint32_t net32bitvalue);

Обе функции возвращают значение, записанное в порядке байтов узла

В названиях этих функций hобозначает узел, nобозначает сеть, s– тип short, l – тип long. Термины shortи longявляются наследием времен реализации 4.2BSD Digital VAX. Следует воспринимать sкак 16-разрядное значение (например, номер порта TCP или UDP), а l– как 32-разрядное значение (например, адрес IPv4). В самом деле, в 64-разрядной системе Digital Alpha длинное целое занимает 64 разряда, а функции htonlи ntohlоперируют 32-разрядными значениями (несмотря на то, что используют тип long).

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

Мы еще вернемся к проблеме определения порядка байтов, обсуждая данные, содержащиеся в сетевом пакете, и сравнивая их с полями в заголовках протокола, в разделе 5.18 и упражнении 5.8.

Мы до сих пор не определили термин байт. Его мы будем использовать для обозначения 8 бит, поскольку практически все современные компьютерные системы используют 8-битовые байты. Однако в большинстве стандартов Интернета для обозначения 8 бит используется термин октет. Началось это на заре TCP/IP, поскольку большая часть работы выполнялась в системах типа DEC-10, в которых не применялись 8-битовые байты. Еще одно важное соглашение, принятое в стандартах Интернета, связано с порядком битов. Во многих стандартах вы можете увидеть «изображения» пакетов, подобные приведенному ниже (это первые 32 разряда заголовка IPv4 из RFC 791):

0                   1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Version| IHL |Type of Service|           Total Length          |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

В этом примере приведены четыре байта в том порядке, в котором они передаются по проводам. Крайний слева бит является наиболее значимым. Однако нумерация начинается с нуля, который соответствует как раз наиболее значимому биту. Вам необходимо получше ознакомиться с этой записью, чтобы не испытывать трудностей при чтении описаний протоколов в RFC.

ПРИМЕЧАНИЕ

Типичной ошибкой среди программистов сетевых приложений начала 80-х, разрабатывающих код на рабочих станциях Sun (Motorola 68000 с обратным порядком байтов), было забыть вызвать одну из указанных четырех функций. На этих рабочих станциях программы работали нормально, но при переходе на машины с прямым порядком байтов они переставали работать.

3.5. Функции управления байтами

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

Первая группа функций, названия которых начинаются с b(от слова «byte» – «байт»), взяты из реализации 4.2BSD и все еще предоставляются практически любой системой, поддерживающей функции сокетов. Вторая группа функций, названия которых начинаются с mem(от слова «memory» – память), взяты из стандарта ANSI С и доступны в любой системе, обеспечивающей поддержку библиотеки ANSI С.

Сначала мы представим функции, которые берут начало от реализации Беркли, хотя в книге мы будем использовать только одну из них – bzero. (Дело в том, что она имеет только два аргумента и ее проще запомнить, чем функцию memsetс тремя аргументами, как объяснялось в разделе 1.2.) Две другие функции, bcopyи bcmp, могут встретиться вам в существующих приложениях.

#include

void bzero(void * dest, size_t nbytes);

void bcopy(const void * src, void * dest, size_t nbytes);

int bcmp(const void * ptr1, const void * ptr2, size_t nbytes);

Возвращает: 0 в случае равенства, ненулевое значение в случае неравенства

ПРИМЕЧАНИЕ

Мы впервые встречаемся со спецификатором const. В приведенном примере он служит признаком того, что значения, на которые указывает указатель, то есть src, ptr1 и ptr2, не изменяются функцией. Другими словами, область памяти, на которую указывает указатель со спецификатором const, считывается функцией, но не изменяется.

Функция bzeroобнуляет заданное число байтов в указанной области памяти. Мы часто используем эту функцию для инициализации структуры адреса сокета нулевым значением. Функция bcopyкопирует заданное число байтов из источника в место назначения. Функция bcmpсравнивает две произвольных последовательности байтов и возвращает нулевое значение, если две байтовых строки идентичны, и ненулевое – в противном случае.

Следующие функции являются функциями ANSI С:

#include

void *memset(void * dest, int c, size_t len);

void *memcpy(void * dest, const void * src, size_t nbytes);

int memcmp(const void * ptr1, const void * ptr2, size_t nbytes);

Возвращает: 0 в случае равенства, значение <0 или >0 в случае неравенства (см. текст)

Функция memsetприсваивает заданному числу байтов значение с. Функция memcpyаналогична функции bcopy, но имеет другой порядок двух аргументов. Функция bcopyкорректно обрабатывает перекрывающиеся поля, в то время как поведение функции memcpyне определено, если источник и место назначения перекрываются. В случае перекрывания полей должна использоваться функция ANSI С memmove(упражнение 30.3).

ПРИМЕЧАНИЕ

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

dest = src;

Последним аргументом этой функции (как и всех ANSI-функций memXXX) всегда является длина области памяти.

Функция memcmpсравнивает две произвольных последовательности байтов и возвращает нуль, если они идентичны. В противном случае знак возвращаемого значения определяется знаком разности между первыми несовпадающими байтами, на которые указывают ptr1и ptr2. Предполагается, что сравниваемые байты принадлежат к типу unsigned char.