Sun RPC

Система Sun RPC позволяет автоматически генерировать клиентский и серверный стабы в том случае, если интерфейс RPC описан на языке IDL, называемом RPC Language (RPCL). Язык RPCL является расширением языка Sun XDR (external Data Representation), который был разработан для системно-независимого представления внешних данных в гетерогенной среде. XDR-представление данных по умолчанию используется в Sun RPC при передаче аргументов и результатов между клиентом и сервером RPC.

Механизм Sun RPC обладает некоторыми достаточно жесткими ограничениями. Одним из них является ограничение на аргументы и результаты удаленных процедур — процедура может иметь только один аргумент и вырабатывать только один результат. Для преодоления этого ограничения в качестве аргумента и результата обычно используется структура данных.

Следующий пример описания интерфейса файловой службы иллюстрирует эту особенность:

/* Определение интерфейса для файловой службы с именем FILE_SERVICE_2. включающей процедуры чтения READ и записи WRITE */

const FILEJAMEJIZE =16

const BUFFER.SIZE = 1024

typedef string FileName<FILE_NAME_SIZE>

typedef long Position:

typedef long Mbytes:

struct Data {

long n;

char buffer[BUFFER SIZE]:

}:

struct readargs {

FileName filename;

Position position:

Nbytes n:

}:

struct writeargs {

FileNarae filename;

Position position:

Data data;

}:

program FILE_SERVICE_2 {

version FILE_SERVICE_VERS {

Data READ (readargs) = 1;

Nbytes WRITE (writeargs) = 2;

}=l:

} = 0x20000000:

Интерфейс однозначно идентифицируется номером программы (FILE_SERVICE_2 -- 0x20000000) и номером версии (FILE_SERVICE_VERS = 1), а процедуры внутри интерфейса — номерами процедур, READ — номером 1 и WRITE — номером 2.

Структура readargs позволяет передать процедуре READ три аргумента — имя файла, позицию (смещение) в файле, с которой нужно начать чтение данных, и количество считываемых байт. Структура Data позволяет вызывающей процедуре получить результат чтения в массиве buffer и узнать количество реально считанных байт с помощью переменной п. Аналогично используются структуры writeargs и Data в процедуре записи WRITE.

Результатом обработки описания интерфейса FILE_SERVICE_2 RPCL-компилято-ром являются несколько файлов, в том числе файл, описывающий клиентские стабы, а также файл, описывающий серверные стабы. По умолчанию имена стабов процедур образуются путем преобразования имен процедур, указанных в описании интерфейса, в нижний регистр, а также добавлением после нижнего подчеркивания номера версии интерфейса, то есть стабы в нашем примере будут иметь имена read_l и write_l.

Механизм Sun RPC не поддерживает динамического связывания с сервером с помощью агента связывания. Клиент должен явно указывать сетевой адрес сервера, а для получения номера порта он должен обратиться к модулю отображения портов, работающему на узле сервера. Для взаимодействия с этим модулем система Sun RPC предоставляет в распоряжение клиента системный вызов сlnt_create, имеющий следующий синтаксис:

client_handle = clnt_create(server_host_name. interfacejiame, interface_version, protocol)

Аргумент server_host_name представляет собой имя (символьное DNS-имя или IP-адрес узла, на котором работает сервер RPC), аргументы interface_name и interface_version задают номер и версию интерфейса, а аргумент protocol указывает на один из двух транспортных протоколов стека TCP/IP — TCP или UDP. Жесткая ориентация только на один стек коммуникационных протоколов, а именно стек TCP/IP, — еще одно ограничение Sun RPC. У компании Sun существует также и протокольно-независимая версия системы удаленного вызова процедур — TI-RPC (Transport-Independent RPC), но она менее распространена.

Вызов clnt_create возвращает указатель, который необходимо далее использовать вместо адреса RFC-сервера при последовательных обращениях к удаленным процедурам, обслуживаемым данным сервером. В процессе своего выполнения cl nt_create создает сокет, который связывает с адресом сервера, включающим и неявно полученный от модуля отображения портов (службы portmapper) номер порта. В конце сеанса работы с сервером необходимо выполнить системный вызов clnt_destroy, который закрывает созданный сокет.

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

Дата добавления: 2014-01-05