verf <

unsigned int xid enum msg type enum reply stat enum autli flavor

opaque body<400> <

enum accept stat

заголовок IP

заголовок UDP

идентификатор транзакции (XID)

тип сообщения (1 = ответ)

статус ответа (О = принят)

тип аутентификации

длина проверочных данных

проверочные данные

запрос принят (О = успешно)

результаты процедуры

20 байт

4 4 4 4 4

до 400 байт

Рис. 16.7. Ответ на успешно обработанный вызов в дейтаграмме UDP

/* ошибки на сервере */

AUTH BADCRED = 1. /* ошибка в личных данных пользователя (нарушена контрольная сумма) */ AUTH REJECTEDCRED = 2. /* клиент должен начать сеанс заново */

AUTH BADVERF = 3. /* ошибка в проверочных данных (нарушена контрольная сумма) */ AUTH REJECTEDVERF = 4. /* проверочные данные устарели или были повторы */ AUTH TOOWEAK = 5. /* запрос отклонен системой безопасности */ /* ошибки клиента */

AUTH INVALIDRESP = 6. /* фальшивые проверочные данные в ответе */

AUTH FAILED =7 /* причина неизвестна */

union rejected reply switch (reject stat stat) { case RPC MISMATCH: struct {

unsigned int low: /* наименьший номер версии RPC */ unsigned int high: /* наибольший номер версии RPC */ } mismatchjnfo: case AUTHJRROR: auth stat stat:

16.10. Резюме

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

Программа rpcgen является краеугольным камнем приложения, использующего RPC. Она считывает файл спецификации и создает заглущку клиента и заглушку сервера, а также функции, вызывающие требуемые подпрограммы XDR, которые осуществляют все необходимые преобразования данных. Библиотека XDR также является важной частью процесса. XDR определяет стандарт обмена данными различного формата между разными системами, у которых может быть по-разному определен, например, размер целого, порядок байтов и т. п. Как мы показали, XDR можно использовать и отдельно от RPC для обмена данными в мащинно-независимом стандартном формате. Для передачи данных можно использовать любой механизм (сокеты, XTI, дискеты, компакт-диски или что угодно).

В Sun RPC используется свой стандарт именования программ. Каждой программе присваивается 32-разрядный номер программы, 32-разрядный номер версии и 32-разрядный номер процедуры. Каждый узел с сервером RPC должен выполнять программу отображения портов в фоновом режиме (RPCBIND). Серверы RPC привязывают временные порты TCP и UDP к своим процедурам, а затем регистрируют эти порты в программе отображения портов, указывая номера программ и версий. При запуске клиент RPC связывается с программой отображения портов узла, где запущен сервер RPC, и выясняет номер нужного ему порта, а затем связывается с самим сервером по протоколам TCP или UDP.

По умолчанию клиенты RPC не предоставляют аутентификационной информации и серверы RPC обрабатывают все приходящие запросы. Это аналогично написанию собственного приложения клиент-сервер с использованием сокетов или XTI. В Sun RPC предоставляются три дополнительные формы аутентификации: аутентификация Unix (предоставляется имя узла клиента, идентификатор пользователя и группы), аутентификация DES (основанная на криптографии с секретным и открытым 1слючом) и аутентификация Kerberos.

Понимание стратегии тайм-аутов и повторных передач пакета RPC важно при использовании RPC (как и любой формы сетевого программирования). При использовании надежного транспортного протокола, такого, как TCP, клиенту RPC нужно использовать только общий тайм-аут, поскольку потеря пакетов или прием лишних копий целиком обрабатываются на транспортном уровне. Когда используется ненадежный транспортный протокол, такой как UDP, пакет RPC использует тайм-аут повтора в дополнение к общему тайм-ауту. Идентификатор транзакций используется клиентом RPC для проверки ответа на соответствие отправленному запросу.

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

Sun RPC - это большой пакет, и мы лишь вкратце обсудили особенности его использования. Тем не менее сведений, приведенных в этой главе, должно быть достаточно для написания приложений целиком. Использование rpcgen скрывает многие детали и упрошает кодирование. Документация Sun описывает различные уровни кодирования RPC - упрошенный интерфейс, верхний уровень, средний уровень, уровень экспертов и низкий уровень, но эти категории достаточно бессмысленны. Количество функций в библиотеке RPC - 164, они могут быть разделены следующим образом: ш 11 auth (аутентификация); Ш 26 с1 nt (клиентские);

5 ртар (доступ к программе отображения портов);

24 грс (общего назначения);

Ш АА svc (серверные);

ш 54 xdr (преобразования XDR).

Для сравнения отметим, что интерфейсы сокетов и XTI содержат по 25 функций, а интерфейсы дверей, очередей сообщений Posix и Systeffl V, семафоров и разделяемой памяти содержат по 10 функций. 15 функций используются для работы с потоками в стандарте Posix, 10 - для работы с условными переменными. 11 функций используются для работы с блокировками чтения-записи Posix и одна при работе с блокировкой записей fcntl.

Упражнения

1. При запуске сервер регистрируется в программе отображения портов. Что происходит при заверщении сервера, например, клавишей заверщения программы с терминала? Что произойдет, если на этот сервер впоследствии придет запрос от клиента?

2. Клиент взаимодействует с сервером RPC по протоколу UDP, и кэш не включен. Клиент посылает запрос на сервер, но серверу требуется 20 секунд до отправки ответа. Клиент посылает запрос повторно через 15 секунд, что приводит к повторному запуску процедуры сервера. Что произойдет со вторым ответом сервера?

3. Тип XDR string всегда кодируется в значение длины и последовательность символов. Что произойдет, если мы напишем char сСЮ] вместо string s<tt)>?

4. Измените максимальный размер string в листинге 16.11 со 128 на 10 и запустите программу write. Что произойдет? Уберите ограничение длины и сравните файл data xdr. с с тем, который был создан, когда длина была ограничена. Что изменилось?