/ cred <

unsigned int xid enum msg type unsigned Int tpcvers unsigned Int prog unsigned int vers unsigned Int proc enum auth flavor

opaque body<400> <

verf <

enum auth flavor

opaque body<400> {

заголовок IP

заголовок TCP

флаг и длина

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

тип сообщения (О = вызов)

версия RPC (2)

номер программы

номер версии

номер процедуры

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

длина данных о пользователе

данные о пользователе

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

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

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

аргументы процедуры

20 байт

4 4 4 4 4 4 4 4 4

до 400 байт

до 400 байт

Рис. 16.5. Запрос RPC в пакете TCP

Приведем спецификацию XDR для запроса RPC, взятую из RFC 1831. Имена на рис. 16.5 взяты из этой спецификации;

enum auth flavor { AUTH NONE = 0. AUTH SYS = 1. AUTHJHORT = 2 /* and more to be defined */

struct opaque auth { auth flavor flavor; opaque body<400>;

enum msg type { CALL = 0. REPLY = 1

struct call body {

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

unsigned int prog: /* номер программы */

unsigned int vers: /* номер версии */

unsigned int proc: /* номер процедуры */

opaque auth cred: /* данные вызывающего */

opaque auth verf: /* проверочная информация вызывающего */ /* параметры, относящиеся к процедуре */ }:

struct rpc msg { unsigned int xid: union switch (msg type mtype) { case CALL:

call body cbody: case REPLY:

reply body rbody: } body:

Содержимое скрытых данных переменной длины, содержащих сведения о пользователе и проверочную информацию, зависит от типа аутентификации. Для нулевой аутентификации, используемой по умолчанию, длина этих данных должна быть установлена в 0. Для аутентификации Unix эти данные содержат следующую структуру:

struct authsys parms { unsigned int stamp: string machinename<255>: unsigned int uid: unsigned int gid: unsigned int glds<16>:

Если тип аутентификации AUTH SYS, тип проверки должен быть AUTH NONE.

Формат ответа RFC сложнее, чем формат запроса, поскольку в нем могут передаваться сообщения об ощибках. На рис. 16.6 показаны возможные варианты.

На рис. 16.7 показан формат ответа RFC в случае успешного выполнения процедуры. Ответ передается по протоколу UDF.

Ниже приводится текст спецификации XDR ответа RPC, взятый из RFC 1831.

enum reply stat { MSG ACCEPTED = 0. MSG DENIED = 1

enum accept stat {

SUCCESS = 0, /* успешное завершение вызова RPC */ PROG UNAVAIL = 1. /* требуемый номер программы недоступен */ PROG MISMATCH = 2 1* требуемый номер версии недоступен */ PROC UNAVAIL = 3 /* номер процедуры недоступен */ GARBAGE ARGS = 4 /* не могу декодировать аргументы */ SYSTEM ERR = 5 /* ошибка выделения памяти и т. п. */

struct accepted reply { opaque auth verf: union switch (accept stat stat) { case SUCCESS:

opaque results[0]: /* результаты, возвращаемые процедурой */ case PROG MISMATCH: struct {

unsigned int low: /* наименьший поддерживаемый номер программы */ unsigned int high: /* наибольший поддерживаемый номер программы */ } mismatchjnfo:

default: /* PROGJNAVAIL. PROC UNAVAIL. GARBAGE ARGS. SYSTEMJRR */

void: } reply data:

union reply body switch (reply stat stat) { case MSG ACCEPTED:

accepted reply areply: case MSGJENIED:

rejected reply rreply: } reply:

Ответ

SUCCESS PROG UNAVAIL

PROG MISMATCH PROC UNAVAIL GARBAGE ARGS SYSTEM ERR

Рис. 16.6. Возможные варианты ответов RPC

RPC MISMATCH

AUTH ERROR

Вызов может быть отклонен сервером, если номер версии RPC не тот или возникает ошибка аутентификации:

enum reject stat {

RPC MISMATCH = 0. /* номер версии RPC отличен от 2 */ AUTHJRROR = 1 /* ошибка аутентификации */

enum auth stat { AUTH OK = 0.

/* успешное завершение */