powerpc-apple-darwin6.6: big-endian
freebsd5 % <b>byteorder</b>
sparc64-unknown-freebsd5.1: big-endian
aix % <b>byteorder</b>
powerpc-ibm-aix5.1.0.0: big-endian
hpux % <b>byteorder</b>
hppa1.1-hp-ux11 11: big-endian
linux % <b>byteorder</b>
i586-pc-linux-gnu: little-endian
solaris % <b>byteorder</b>
sparc-sun-solaris2.9: big-endian
Все, что было сказано об определении порядка байтов 16-разрядного целого числа, конечно, справедливо и в отношении 32-разрядного целого.
ПРИМЕЧАНИЕ
Существуют системы, в которых возможен переход от прямого к обратному порядку байтов либо при перезапуске системы (MIPS 2000), либо в любой момент выполнения программы (Intel i860).
Разработчикам сетевых приложений приходится обрабатывать различия в определении порядка байтов, поскольку в сетевых протоколах используется сетевой порядок байтов (network byte order). Например, в сегменте TCP есть 16- разрядный номер порта и 32-разрядный адрес IPv4. Стеки отправляющего и принимающего протоколов должны согласовывать порядок, в котором передаются байты этих многобайтовых полей. Протоколы Интернета используют обратный порядок байтов.
Теоретически реализация Unix могла бы хранить поля структуры адреса сокета в порядке байтов узла, а затем выполнять необходимые преобразования при перемещении полей в заголовки протоколов и обратно, позволяя нам не беспокоиться об этом. Но исторически и с точки зрения POSIX определяется, что для некоторых полей в структуре адреса сокета порядок байтов всегда должен быть сетевым. Поэтому наша задача — выполнить преобразование из порядка байтов узла в сетевой порядок и обратно. Для этого мы используем следующие четыре функции:
#include <netinet/in.h>
uint16_t htons(uint16_t <i>host16bitvalue</i>);
uint32_t htonl(uint32_t <i>host32bitvalue</i>);
<i>Обе функции возвращают значение, записанное в сетевом порядке байтов</i>
uint16_t ntohs(uint16_t <i>net16bitvalue</i>);
uint32_t ntohl(uint32_t <i>net32bitvalue</i>);
<i>Обе функции возвращают значение, записанное в порядке байтов узла</i>
В названиях этих функций
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
. Эти функции подключаются с помощью файла
<string.h>
.
Первая группа функций, названия которых начинаются с
b
(от слова «byte» — «байт»), взяты из реализации 4.2BSD и все еще предоставляются практически любой системой, поддерживающей функции сокетов. Вторая группа функций, названия которых начинаются с
mem
(от слова «memory» — память), взяты из стандарта ANSI С и доступны в любой системе, обеспечивающей поддержку библиотеки ANSI С.
Сначала мы представим функции, которые берут начало от реализации Беркли, хотя в книге мы будем использовать только одну из них —
bzero
. (Дело в том, что она имеет только два аргумента и ее проще запомнить, чем функцию
memset
с тремя аргументами, как объяснялось в разделе 1.2.) Две другие функции,
bcopy
и
bcmp
, могут встретиться вам в существующих приложениях.