Приведем спецификацию XDR для запроса RPC, взятую из RFC 1831. Имена на рис. 16.5 взяты из этой спецификации:
enum autn_flavor {
AUTH_NONE = 0,
AUTH_SYS = 1,
AUTH_SHORT = 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 gids<16>;
};
Если тип аутентификации AUTH_SYS, тип проверки должен быть AUTH_NONE. Формат ответа RPC сложнее, чем формат запроса, поскольку в нем могут передаваться сообщения об ошибках. На рис. 16.6 показаны возможные варианты. На рис. 16.7 показан формат ответа RPC в случае успешного выполнения процедуры. Ответ передается по протоколу UDP.
Ниже приводится текст спецификации 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, /* требуемый номер версии недоступен */
PROC_UNAVAIL = 3, /* номер процедуры недоступен */
GARBAGE_ARGS = 4, /* не могу декодировать аргументы */
SYSTEM_ERR = 5 /* ошибка выделения памяти и т. п. */
Вызов может быть отклонен сервером, если номер версии RPC не тот или возникает ошибка аутентификации:
enum reject_stat {
RPC_MISMATCH = 0, /* номер версии RPC отличен от 2 */
AUTH_ERROR =1 /* ошибка аутентификации */
};
enum auth_stat {
AUTH_OK = 0, /* успешное завершение */
/* ошибки на сервере */
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 */
} mismatch_info;
case AUTH_ERROR:
auth_stat stat;
};
Рис. 16.7. Ответ на успешно обработанный вызов в дейтаграмме UDP
16.10. Резюме
Средства Sun RPC дают возможность создавать распределенные приложения, в которых клиентская часть может выполняться на одном узле, а серверная — на другом. Сначала следует определить процедуры сервера, которые могут быть вызваны клиентом, и написать файл спецификации RPC, описывающий аргументы и возвращаемые значения этих процедур. Затем пишется функция main клиента, вызывающая процедуры сервера, а потом сами эти процедуры. Программа клиента выглядит так, как будто она просто вызывает процедуры сервера, но на самом деле их скрытое взаимодействие по сети обеспечивается библиотекой RPC.