TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

Фейт Сидни М.

■ Имеются дополнительные атрибуты файла, например его размер, время последнего обращения и обновления. Можно ожидать, что эти атрибуты поддерживаются в любой файловой системе.

15.11 XDR

Как будут взаимодействовать разнородные (гетерогенные) машины в окружении клиент/сервер, чтобы понимать посылаемые друг другу данные? Например, клиент NFS может захотеть, чтобы сервер прочитал в файле 1000 байтов данных от некоторой позиции. Как должны кодироваться параметры такого запроса? Типичными параметрами являются имя файла или имя каталога, равно как и атрибуты

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

Все параметры в сообщениях Sun RPC определены и кодируются по протоколу представления внешних данных (external Data Representation — XDR). Этот протокол специфицирует:

■ Язык описания данных XDR, определяющий тип данных в запросах и ответах

■ Правила кодирования XDR по форматированию данных при пересылке

Большая часть библиотеки программирования RPC состоит из запросов, которые преобразуют типы данных в/из сетевого формата XDR.

15.11.1 Язык описания данных XDR

Описания данных XDR похожи на описания данных в языках программирования и не являются слишком сложными. Существует несколько основных типов данных XDR: целые числа со знаком и без знака, последовательные (или порядковые) целые числа, строки ASCII, логические значения и числа с плавающей точкой. Для пересылки строк октетов общего вида применяется тип данных opaque (непрозрачный, без преобразования). В полях с этим типом данных может пересылаться зашифрованная информация. К более сложным типам данных относятся массивы, структуры и объединенные типы данных (union datatypes), построенные на основе базовых типов.

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

enum msg_type {

 CALL = 0,

 REPLY = 1

};

В данном поле может появляться только одно из целых чисел: 0 или 1. Ввод любого другого целого числа приведет к ошибке.

Структура определения тела сообщения запроса RPC:

struct call_body {

 unsigned int rpcvers; /* Версия должна быть равна 2 */

 unsigned int prog; /* Это номер программы */

 unsigned int vers; /* Это версия программы */

 unsigned int proc; /* Определение процедуры */

 opaque_auth cred; /* Мандат, например userid */

 opaque_auth verf; /* Verifier для мандата */

 /* Здесь может быть зашифрованное поле */

 /* начало описания специфичных для процедуры параметров */

15.11.2 Кодирование в XDR

Сообщения запросов и ответов для данной версии программы или процедуры имеют фиксированный формат.

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

00 00 00 05

Строки ASCII кодируются как 4-октетное целое число, содержащее длину строки со следующими далее символами ASCII, дополненными до полей, кратных 4 байт. Например, строка README будет выглядеть как:

(длина строки = 6) R E A D M E (заполнитель)

00 00 00 06 52 45 41 44 4D 45 00 00

Альтернативный метод определения и кодирования специфицирует стандарт описания данных в первой абстрактной синтаксической нотации OSI (OSI Abstract Syntax Notation 1 — ASN.1) и стандарт базовых правил кодирования (Basic Encoding Rules — BER,). ASN.1 и BER используются некоторыми приложениями TCP/IP. Наиболее значимым из них является Simple Network Management Protocol (SNMP).

Стандарт кодирования BER предполагает размещение перед каждой порцией данных специального поля, идентифицирующего эти данные и определяющего их длину (ASN.1 и BER обсуждаются в главе 20). Преимущество XDR состоит в том, что данные кодируются существенно меньшим количеством байт, а недостаток — в том, что каждое поле должно быть в предопределенном месте сообщения.

15.12 Программные интерфейсы RPC и XDR

Приложения клиент/сервер для RPC строятся на основе библиотеки подпрограмм для создания, отправки и получения сообщений RPC. Другие программы библиотеки служат для преобразования между локальным представлением данных для параметров сообщения и форматом XDR. Типичная подпрограмма RPC:

int callrpc (хост, номер_программы, номер_версии, номер_процедуры, входная_программа, входные_параметры, выходная_программа, выходные_параметры)

Параметр "хост" идентифицирует компьютер сервера, номер_программы определяет программу, а номер_процедуры — выполняемую процедуру. Передаваемые в сообщении запроса входные параметры описываются структурой входные параметры, а входная_программа преобразует эти параметры в формат XDR. Когда прибывает ответ, программа выходная программа преобразует параметры ответа XDR в локальный формат и сохраняет их в структуре выходные параметры.

Компании NetWise и Sun разработали комплект программных инструментов, который упрощает создание приложений клиент/сервер для RPC и скрывает от разработчика запросы RPC нижнего уровня.

15.13 Введение в NFS

Сетевая файловая система (Network File System — NFS) — это архитектура файлового сервера для различного оборудования, операционных систем, транспортных протоколов или сетевых топологий. Однако первоначально она была разработана для Unix.