Ю. Вахалия - UNIX изнутри (2003) (1114670), страница 103
Текст из файла (страница 103)
Стандарт ХРК [341 определяет машинно-независимое представление данных, передаваемых по сети. В стандарте описаны несколько основных типов данных, а также правил, по которым осуществляется построение более сложных типов данных. Методика ХРК была разработана корпорацией бцп М(сгозузгешэ и реализована для архитектуры Могого!а 680хО (рабочие станции Бцп-2 и Яцп-3 имели процессор 680хО) в отношении таких проблем, как порядок следования байтов.
Ниже перечислены некоторые базовые определения стандарта ХРК. + Целые числа (шге8ег) являются 32-разрядными, где байт 0 является старшим значащим байтом (нумерация байтов осуществляется слева направо). Целые числа со знаком представлены двумя дополнительными определениями. 438 Глава 10. Распределенные файловые системы + Закрытые данные переменной длины (чаг!аЫе-!епй(Ь ораг(це г(ага) описываются полем !епд!)( (четырехбайтовым целым числом) и следующими за ним данными. Данные заполняются нулями до достижения четырехбайтовой границы.
Поле !епд((з не добавляется для закрытых данных фиксированного размера. + Строки (зтг!пд) представлены полем !епд((1 и следующими за ним АсС!!- кодами строки, заполненной нулями до достижения четырехбайтовой границы. Если длина строки кратна четырем„она не заканчивается байтом (4(((.(.
(как это принято в У(х(1Х). + Массивы (аггау) однородных элементов описаны полем 3!2е, после чего следуют элементы в их обычном порядке. Поле размера является чегырехбайтовым целым числом и не используется для массивов фиксированных размеров. Размер каждого элемента должен быть кратен четырем. Хотя элементы массива обязаны быть одного типа, они могут иметь неодинаковую длину, например в массиве строк.
+ Структуры !3(гас(иге), для которых кодирование их компонентов производится в обычном порядке. Каждый компонент должен дополняться до четырехбайтовой границы. Нескорые примеры кодирования методом ХРК представлены на рис, !02. Кроме указанного набора определений стандарт предлагает спецификацию формального языка, применяемого для описания данных. Спецификации КРС, описываемые в следующем разделе, являются простыми дополнениями языка ХРК. Компилятор грсдеп понимает спецификации ХРК и умеет создавать процедуры, которые шифруют и расшифровывают данные, представленные в форме ХРК.
Представление Х(ЗЙ Значение Ох203040 00 20 30 40 Массив из 3-х целых (Охзо, Ох40, Ох50! Массив строк переменного размера ( "молод,у" "тиезоау" ) Рис. 10.2. Пример ХР~-преобразования Стандарт ХРК формирует универсальный язык, применяемый для осуществления коммуникаций между самыми различными компьютерами. Его 10.4.
Набор протоколов 439 основным недостатком является снижение производительности при использовании на машинах, семантика представления данных которых отличается от принятой в ХРК. Таким компьютерам приходится выполнять операции преобразования для каждого передаваемого элемента данных. Если две взаимодействующие стороны поддерживают одинаковое внутреннее представление данных и не требуют их преобразования для передачи друг другу, избыточность таких операций становится очевидной.
В качестве примера можно привести две машины Ъ'АХ-11, работающие с протоколом, основанным на кодировании ХРК. Так как Ъ"АХ использует обратный порядок байтов (нулевой байт является старшим), отправителю необходимо произвести преобразование данных в формат с прямым порядком байтов (принятый в ХРК), после передачи которых получатель снова перекодирует их в форму с обратным порядком следования байтов. Эти избыточные действия можно предотвратить, если представление данных будет зависеть от аппаратных характеристик, тогда преобразование нужно выполнять только в случае несовместимых архитектур. Реализация РСЕ КРС [211 использует эту схему вместо оригинальной методики, принятой в ХРК.
10.4.2. Вызов удаленных процедур (ЯРС) 11ротокол вызова удаленнык процедур (Кеша(е Ргосег)цге Са)), КРС) определяет формат взаимодействий между клиентом и сервером. Клиент отправляет запрос ЯРС серверу, который, в свою очередь, обрабатывает его и возвращает результат в ответном сооби(ении РтРС. Протокол устанавливает формат сообщений, передачу и аутентификацию и т. д., то есть решает вопросы, не зависящие от определенной спецификации или сервиса. На основе КРС построено несколько служб, таких как )ч)ГЯ, Моцпг, )чП.М, )ч)ЗМ, роггшаррег и )чПЕ (информационная сетевая служба).
ПРИМЕЧАНИЕ Существуют несколько различных реализаций протокола ВРС. Файловая система )ЧРЗ использует версию протокола ВРС, представленную Зцп М!сгозуз!егпз 135), известную под названиями Зцп ВРС и О)ЧС-ВРС (О)ЧЗ является аббревиатурой Орел )Чеввогн Согпрцбпр). В этой книге термин ВРС означает реализацию Зцп ВРС (если это не оговорено иначе). Единственным альтернативным вариантом ВРС, упоминаемым на страницах книги, является ОСЕ ВРС вЂ” версия протокола О)з)г)бц)еа Согпрц1)пц Епу)гопгпел1, созданная для ОЗЕ. В отличие от РСЕ КРС, поддерживающего как асинхронные, так и синхронные операции, протокол Яцп КРС прибегает только к синхронным запросам.
После того как клиент производит запрос КРС, вызывающий процесс блокируется до тех пор, пока не будет получен ответ. Такой подход делает КРС похожим на технологию работы локальных процедурных вызовов. 440 Глава 10. Распределенные файловые системы Протокол КРС отвечает за надежность передачи запросов. Это означает, что он должен удостовериться в достижении запросом адресата и отправке ответа на нега Хотя протокол НРС фундаментально независим от используемого транспорта, он часто применяется поверх протоколов 1)0Р/1Р (Пьет Васаягагл Ргососо!/1пгегпес Ргогосо!), по природе ненадежных.
На уровне КРС реализуется надежная служба дейтаграмм путем отслеживания запросов, не получивших ответа, и периодической повторной посылки их, осушествляемой до тех пор, пока ответ не будет получен. На рис. 10.3 показан типичный формат запроса и обратного (удачного) сообшения тьРС. Переменная хЫ вЂ” идентификатор передачи, являющийся меткой запроса.
Клиент генерирует для каждого запроса уникальный номер х!б, сервер в ответном сообщении возврашает то же значение переменной. Это позволяет клиенту идентифицировать, на какой из запросов пришел ответ, а серверу обнаруживать дубликаты запросов (появляюшиеся после повторов запросов клиентов). Поле б!гесйоп указывает, является ли сообшение запросом или ответом. Поле грс чегь содержит номер версии используемого протокола НРС (текушая версия — 2). Переменные рго9 и четь указывают на номер программы, обеспечиваюшей определенную службу НРС, а также ее версию.
Служба КРС может поддерживать многопротокольные версии. Например, протокол НРБ имеет программный номер 100 003 и различается версиями 2 и 3. Поле ртос конкретизирует процедуру, которую необходимо вызвать служебной программой. В ответном сообщении поля )ер!у ьга1 и ассерс ьта! содержат информацию о статусе. Ответное сообщение ЬГРС Запрос йРС !вызов) Рис. 10.3. Формат ЯРС-сообщений Протокол КРС применяет пять механизмов опознания обращающегося к серверу — АОТН МОЕЕ, АОТН ОМ1Х, АОТН 5НОРТ, АОТН 0Е5, АОТН КЕРВ.
При задании АОТН МОЫЕ какая-либо проверка отсутствует, метод АОТН ОЙ1Х основан на привилегиях, принятых в Т)Н1Х, и включает в себя имя клиентской машины, идентификатор пользователя и один или несколько групповых идентификаторов. Сервер может сгенерировать АОТН 5НОРТ после получения привилегий АОТН ОМ1Х и возвратить их клиенту для использования в после- 10.5. Реализация МРВ 441 дующих запросах. Такой подход применяется потому, что сервер способен очень быстро идентифицировать клиентов по привилегиям АОТН 5НОЙТ, тем самым ускоряя процесс аутентификации. Описанное средство является дополнительным и поддерживается далеко не всеми службами. Средство проверки АОТН 0Е5 использует механизм закрытьп ключей 136), АОТН КЕВВ основано иа методике Кег1зегоз 132).
Выбор инструмента контроля осуществляется каждой службой самостоятельно. Файловая система ХГВ поддерживает все пять перечисленных механизмов, ограничивая применение АОТН МОЕЕ для процедуры МОЮ. Большинство реализаций ХГВ, тем не менее, используют преимущественно АОТН ОМ1Х. Корпорация Вцп представила также язык программирования КРС и компилятор языка, называемый грсдеп. Служба, основанная на КРС, может быть полностью описана при помощи этого языка. При переработке описания программа грсдеп создает набор исходных файлов на С, которые содержат процедуры преобразования ХВК и фиктивные версии клиентских и серверных процедур, а также заголовочный файл, включающий в себя определения, используемые совместно сервером и клиентом.
10.5. Реализация МРЗ В этом разделе будут рассмотрены реализации протокола ХГЯ в стандартных системах 11Х1Х. Протокол ХГВ был перенесен и на не-ПХ1Х-системы, такие как МБ-005 и ЧМВ. Некоторые решения являются чисто клиентскими или серверными, в то время как другие версии предлагают оба варианта. Более того, существуют серверные реализации под конкретные системы, созданные компаниями Ацзрех, Хегтчог)с А111апсе СогрогаОоп и Хоче!), не работающие под управлением систем, предназначенных для общих целей. Созданы и реализации ХГВ на прикладном уровне для различных операционных систем, многие из которых доступны бесплатно или условно-бесплатно. Конечно, эти варианты системы в деталях устроены по разному.
Некоторые интересные варианты будут описаны в разделе 10.8. В этом разделе мы расскажем только о реализации ХГ5 на уровне ядра для традиционных систем НХ1Х, поддерживающих интерфейс чпог)е/чЬ. 10.5.1. Управление потоком На рис. 10.4 сервер экспортировал файловую систему цЬ, монтированную клиентом. Если процесс на клиентской машине производит системный вызов, относящийся к файлу ХГВ, независимая от файловой системы часть кода ' Процедура ЬГО1.1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
