16.8. XDR: представление внешних данных

We use cookies. Read the Privacy and Cookie Policy

16.8. XDR: представление внешних данных

В предыдущей главе мы использовали двери для вызова процедуры одного процесса из другого процесса. При этом оба процесса выполнялись на одном узле, поэтому необходимости в преобразовании данных не возникало. Однако RPC используется для вызова процедур на разных узлах, которые могут иметь различный формат хранения данных. Прежде всего могут отличаться размеры фундаментальных типов (в некоторых системах long имеет длину 32 бита, а в других — 64). Кроме того, может отличаться порядок битов (big-endian и little-endian, о чем говорится в книге [24, с. 66-69 и 137-140]. Мы уже столкнулись с этой проблемой, когда обсуждали листинг 16.3. Сервер у нас работал на компьютере с little-endian х86, а клиент — на big-endian Sparc, но мы могли без проблем обмениваться данными (в нашем примере — одно длинное целое).

Sun RPC использует стандарт XDR (External Data Representation — представление внешних данных) для описания и кодирования данных (RFC 1832 [19]). XDR является одновременно языком описания данных и набором правил для их кодирования. В XDR используется скрытая типизация (implicit typing), то есть отправитель и получатель должны заранее знать тип и порядок данных. Например, два 32-разрядных целых, одно число с плавающей точкой и одинарной точностью и строка символов.

ПРИМЕЧАНИЕ

Приведем сравнение из мира OSI. Для описания данных обычно используется нотация ASN.1 (Abstract Syntax Notation one), а для кодирования — BER (Basic Encoding Rules). Эта схема также использует явную типизацию, то есть перед каждым значением указывается его тип. В нашем примере поток байтов содержал бы: спецификатор типа целого, целое, спецификатор типа целого, целое, спецификатор типа single, число с плавающей точкой и одинарной точностью, спецификатор типа строки символов, строку символов.

Представление всех типов согласно XDR требует количества байтов, кратного четырем. Эти байты всегда передаются в порядке big-endian. Целые числа со знаком передаются в дополнительном коде, а числа с плавающей точкой передаются в формате IEEE. Поля переменной длины могут содержать до 3 байтов дополнения в конце, так чтобы подогнать начало следующего элемента до адреса, кратного четырем. Например, 5-символьная строка АSСII будет передана как 12 байтов:

? 4-байтовое целое, содержащее значение 5;

? 5-байтовая строка;

? 3 байта со значением 0 (дополнение).

При описании XDR и поддерживаемых типов данных следует уточнить три момента.

1. Как объявляются переменные различных типов в файле спецификации RPC (файл с расширением .х)? В наших примерах пока что использовалось только длинное целое.

2. В какой тип языка С преобразуется данный тип программой rpcgen при составлении заголовочного файла?

3. Каков реальный формат передаваемых данных?

Таблица 16.2 содержит ответы на первых два вопроса. Для составления этой таблицы мы создали файл спецификации RPC со всеми поддерживаемыми стандартом XDR типами. Этот файл был обработан rpcgen, после чего мы изучили получившийся заголовочный файл.

Таблица 16.2. Типы данных, поддерживаемые xdr и rpcgen 

№ Файл спецификации RPC (.x) Заголовочный файл языка С (.h) 1 const name = value #define name value 2 typedef declaration; typedef declaration; 3 char var; short var; int var; long var; hyper var; char var; short var; int var; long var; longlong_t var; 4 unsigned char var; unsigned short var; unsigned int var; unsigned long var; unsigned hyper var; u_char var; u_short var; u_int var; u_long var; u_longlong_t var; 5 float var; double var; quadruple var; float var; double var; quadruple var; 6 bool var; bool_t var; 7 enum var {name = const, …} enum var {name = const, …}; typedef enum var var; 8 opaque var[n]; char var[n]; 9 opaque var<m>; struct { u_int var_len; char *var_val; } val; 10 string var<m> char *var; 11 datatype var[n]; datatype var[n]; 12 datatype var<m> struct { uint var_len; datatype *var_val; } var; 13 struct var {members … }; struct var {members … }; typedef struct var var; 14 union var switch (int disc) { case discvalueA: armdeclA; case discvalueB: amrdeclB; … default: defaultdecl; }; struct var { int disc; union { armdeclA; armdeclB; …  defaultdecl; } var_u; }; typedef struct var var; 15 datatype *name; datatype *name;

Опишем содержимое таблицы более подробно.

1. Декларация const преобразуется в #define.

2.  Декларация typedef преобразуется в typedef.

3. Пять целых типов со знаком. Передаются XDR как 32-разрядные значения (первые четыре типа), а последний — как 64-разрядное.

ПРИМЕЧАНИЕ

64-разрядное целое поддерживается многими компиляторами С как формат long long int или просто long long. Многие, но не все компиляторы и операционные системы поддерживают такой формат. Поскольку в созданном заголовочном файле объявляются переменные типа longlong_t, в другом заголовочном файле должно содержаться следующее определение:

typedef long long longlong_t;

Длинное целое в XDR занимает 32 бита, но длинное целое языка С в 64-разрядных системах Unix может занимать и 64 бита (например, в модели LP64, описанной в [24, с. 27]). Имена формата XDR устарели лет на десять и не слишком соответствуют современным стандартам. Лучше, если бы они назывались как-нибудь вроде int8_t, int16_t и т. д.

4. Пять целых типов без знака. Первые 4 передаются как 32-разрядные значения, а последнее — как 64-разрядное.

5. Три типа данных с плавающей точкой. Первый передается как 32-разрядное значение, второй — как 64-разрядное, а третий — как 128-разрядное.

ПРИМЕЧАНИЕ

Четверная точность для чисел с плавающей точкой (quadruple precision) поддерживается в С для типов long double. He все компиляторы и операционные системы его воспринимают. Ваш компилятор может пропустить long double, но работать с этой переменной как с double. Поскольку в созданном заголовочном файле объявляются переменные типа quadruple, нужно создать другой заголовочный файл с объявлением

typedef long double quadruple;

В Solaris 2.6, например, нам пришлось бы включить строку

%#include <floatingpoint.h>

в начало файла спецификации RPC, потому что этот заголовочный файл содержит требуемое определение. Знак процента перед #include говорит программе rpcgen о необходимости поместить остаток строки непосредственно в создаваемый заголовочный файл.

6. Тип boolean эквивалентен целому со знаком. Заголовки RPC также определяют константу TRUE равной 1, a FALSE равной 0.

7. Перечисление (enumeration) эквивалентно целому со знаком и совпадает с типом данных enum в С. rpcgen также создает определение типа для данной переменной.

8. Скрытые данные фиксированной длины передаются библиотекой как 8-разрядные значения без интерпретации.

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

10. Строка представляет собой последовательность ASCII-символов. В памяти строка хранится как обычная строка символов языка С, завершаемая нулем, но при передаче перед ней отправляется целое без знака, в которое помещается количество символов данной строки (без завершающего нуля). При отправке данных такого типа размер строки определяется библиотекой с помощью вызова strlen. При приеме данные такого типа помещаются в строку символов С, завершаемую нулем.

11. Массив фиксированной длины любого типа передается как последовательность n элементов данного типа.

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

13. Структура передается как последовательность полей. rpcgen также создает определение типа для данного имени переменной (typedef).

14. Размеченное объединение состоит из целочисленного дискриминанта и набора типов данных (ветвей), зависящих от значения дискриминанта. В табл. 16.2 мы показываем, что дискриминант должен быть типа int, но он может быть и unsigned int, и enum, и bool (все эти типы передаются как 32-разрядные целые). При передаче размеченного объединения передается 32-разрядное значение дискриминанта, за которым следует значение той ветви, которая ему соответствует. В ветви default часто объявляется тип void, что означает отсутствие передаваемой вслед за дискриминантом информации. Ниже мы продемонстрируем это на примере.

15. Дополнительные данные представляют собой специальный тип объединения, описанный в примере из листинга 16.24. Объявление XDR выглядит как объявление указателя в языке С, и именно указатель объявляется в созданном заголовочном файле.

На рис. 16.3 сведена информация о кодировании различных типов данных в XDR.

Рис. 16.3. Кодирование типов данных в XDR

Данный текст является ознакомительным фрагментом.