Фертиков В.В. Распределенные вычисления: технология Microsoft RPC. Часть1

Подождите немного. Документ загружается.

процедуры на сервере, а сервер печатает слова на устройстве стандартного вы -

вода.

Это распределенное приложение включает две различные исполняемые

программы: одну для клиента и одну для сервера. Подобно обычным програм -

мам , они будут получены из исходных файлов на языке C, в основном написан -

ных разработчиком . Однако некоторые из исходных файлов будут автоматиче-

ски сгенерированы RPC инструментом – компилятором MIDL.

Примерный план работы по реализации этого приложения таков. Чтобы

сделать его распределенным , Вы создадите файл, включающий функциональ-

ный прототип удаленной процедуры . Прототип связан с атрибутами, которые

описывают, каким образом данные для удаленной процедуры должны быть пе-

реданы через сеть. Атрибуты , типы данных и функциональные прототипы со-

вместно описывают интерфейс между клиентом и сервером . Интерфейс ассо-

циируется с уникальным идентификатором, позволяющим отличать этот ин-

терфейс от всех других. Вы также создадите файл, который объявляет особую

переменную – дескриптор связывания, используемую клиентом и сервером

для представления их логического соединения через этот интерфейс. Вы буде-

те, наконец, писать главные программы клиента и сервера, которые вызывают

RPC функции времени выполнения для установки интерфейса.

Программа клиента

Начнем с самого простого . Автономная программа, которая может быть

выполнена на одном компьютере, состоит из вызова одной функции, называе -

мой HelloProc:

/* файл: helloc.c (автономная программа) */

void HelloProc(unsigned char * pszString);

void main(void)

{ unsigned char * pszString = "Hello, world";

HelloProc(pszString);

}

Функция HelloProc вызывает библиотечную C функцию printf, чтобы

отобразить текст "Привет, мир":

/* файл: hellop.c */

#include <stdio.h>

void HelloProc(unsigned char * pszString)

{ printf("%s\n", pszString);

}

HelloProc мы с самого начала определили в собственном исходном фай -

ле HELLOP.C, так что она может компилироваться и компоноваться как с авто -

номной прикладной программой , так и с распределенным приложением , к реа-

лизации которого мы приступаем .

Файл на языке определения интерфейсов

Первый шаг при создании распределенного приложения должен обеспе-

чить возможность клиенту и серверу найти друг друга и связаться через сеть.

Для этого формально определяется интерфейс с использованием языка опреде-

ления интерфейсов Microsoft (MIDL). Интерфейс состоит из типов данных,

функциональных прототипов, атрибутов и информации интерфейса. Определе-

ние интерфейса сохраняется в собственном файле с расширением IDL. Для

удобства этот пример использует то же самое имя, HELLO, как для IDL файла,

так и для файла языка C. Вы можете использовать и различные имена для этих

двух файлов:

/* файл: hello.idl */

[ uuid (6B29FC40-CA47-1067-B31D-00DD010662DA),

version(1.0)

]

interface hello

{

void HelloProc([in, string] unsigned char * pszString);

}

Конструкции IDL файла отличаются от конструкций в исходных файлах

языка C, но они достаточно очевидны . IDL файл состоит из двух частей : заго -

ловка интерфейса и тела интерфейса. Заголовок интерфейса включает инфор-

мацию относительно интерфейса в целом , такую как его идентификатор и но-

мер версии. Он состоит из спецификации, заключенной в квадратные скобки и

заканчивающейся ключевым словом interface и именем интерфейса. Заголо-

вок интерфейса в этом примере включает ключевые слова uuid, version и

interface. Тело интерфейса заключено в фигурные скобки и содержит типы

данных и функциональные прототипы .

UUID – универсально уникальный идентификатор (universally unique

identifier), строка из пяти групп шестнадцатеричных цифр, разделяемых дефи-

сами. Эти пять групп соответственно содержат восемь цифр, четыре цифры , че-

тыре цифры, четыре цифры и 12 цифр. Например , "6B29FC40-CA47-1067-

B31D-00DD010662DA" – является допустимым UUID. В среде Microsoft

Windows NT UUID также известен как GUID, или глобально уникальный иден-

тификатор (globally unique identifier). UUID интерфейса можно получить при

помощи специальной утилиты uuidgen, которая генерирует уникальные иден-

тификаторы в требуемом формате .

Тело интерфейса содержит С - подобные определения типов данных и

функциональных прототипов, к которым добавлены атрибуты . Атрибуты при-

водятся в квадратных скобках и описывают способ передачи данных по сети. В

данном примере тело интерфейса содержит функциональный прототип

HelloProc. Единственный параметр pszString, обозначен как параметр in,

что означает необходимость его передачи от клиента к серверу . Параметры мо-

гут также быть обозначены как out, если они передаются от сервера клиенту ,

или in,out , если передаются в обоих направлениях. Эти атрибуты – инфор-

мация для библиотек времени выполнения , организующих передачу данных

между клиентом и сервером . Атрибут string указывает, что параметр – сим -

вольный массив.

В результате обработки IDL файла компилятором MIDL будут сгенериро-

ваны файлы на языке C для клиентского и серверного стабов и файл заголовка.

Файл заголовка, произведенный из файла определения интерфейса HELLO.IDL,

по умолчанию именуется HELLO.H и содержит включение (#include) заголо-

вочного файла RPC.H , а также функциональные прототипы из IDL файла.

Файл заголовка RPC.H определяет данные и функции, используемые сгенери-

рованным файлом заголовка:

/* файл: hello.h (фрагмент) */

#include <rpc.h>

void HelloProc(unsigned char * pszString);

Вместо того чтобы дублировать эти функциональные прототипы , исход -

ный текст клиента должен включить файл заголовка, который сгенерирован из

IDL файла:

/* файл: helloc.c (распределенная версия) */

#include <stdio.h>

#include "hello.h" // заголовок, сгенерированный

// компилятором MIDL

void main(void)

{ char * pszString = "Hello, world";

...

HelloProc(pszString);

...

}

IDL файл определяет «договор» между клиентом и сервером – твердое со-

глашение относительно последовательности, типов и размеров данных, кото -

рые должны быть переданы через сеть.

Файл конфигурации приложения

Стандарт распределенной вычислительной среды (DCE) требует также оп-

ределить файл конфигурации приложения или ACF (application configuration

file), который обрабатывается компилятором MIDL вместе с IDL файлом . ACF

содержит данные и атрибуты RPC, не имеющие отношения к передаваемым

данным . Например , объект данных, называемый дескриптором связывания,

представляет соединение между приложениями клиента и сервера. Клиент вы -

зывает функции времени выполнения, чтобы установить имеющий силу деск -

риптор связывания, который может затем использоваться функциями времени

выполнения всякий раз , когда клиент вызывает удаленную процедуру . Деск -

риптор связывания не является частью функционального прототипа и не пере-

дается через сеть, поэтому он определяется в ACF.

ACF для программы "Hello,world" имеет следующий вид :

/* файл: hello.acf */

[ implicit_handle(handle_t hello_IfHandle)

]interface hello

{

}

Формат ACF подобен формату IDL файла. Атрибуты приводятся в квад -

ратных скобках со следующим за ними ключевым словом interface и именем

интерфейса. Имя интерфейса, определенное в ACF, должно соответствовать

имени, определенному в IDL файле. ACF содержит атрибут

implicit_handle, указывающий , что дескриптор – глобальная переменная ,

т.е. доступная функциям библиотеки времени выполнения. Ключевое слово

implicit_handle связано с типом дескриптора и именем дескриптора; в этом

примере дескриптор имеет MIDL тип данных handle_t. Имя

hello_IfHandle дескриптора, специфицированное в ACF, определено в сге-

нерированном файле заголовка HELLO.H. Этот дескриптор будет использо-

ваться при вызовах функций клиентской библиотеки времени выполнения.

Функции, вызываемые из RPC

Библиотеки времени выполнения RPC часто вызывают функции, реализо-

ванные пользователем . Этот подход позволяет компилятору MIDL генериро-

вать C код автоматически, в то же время сохраняя возможность непосредствен-

ного управления выполнением операции в приложении. Такие реализованные

пользователем функции могут иметь либо фиксированные имена, либо имена,

основанные на атрибутах или типах данных IDL-файла. Например , всякий раз ,

когда библиотеки времени выполнения распределяют или освобождают память,

они вызывают реализованные пользователем функции midl_user_allocate и

midl_user_free. В примере "Привет, мир" приложение не нуждается в слож -

ном управлении памятью , так что эти функции просто реализованы в терминах

библиотечных C-функций malloc и free:

void __RPC_FAR * __RPC_USER midl_user_allocate(size_t len)

{ return(malloc(len));

}

void __RPC_USER midl_user_free(void __RPC_FAR * ptr)

{ free(ptr);

}

Вызов функций клиентского API

RPC поддерживает два типа связывания: автоматическое и программно-

управляемое. При использовании автоматического связывания, Вы не должны

определять дескриптор связывания, а также делать какие- либо вызовы клиент-

ских функций времени выполнения для объявления (регистрации) дескриптора.

Если же управляет дескриптором приложение, оно само должно делать эти оп-

ределения и вызовы . В данном примере соединением с сервером управляет

клиент. Чтобы связаться с сервером , клиент должен вызвать функции времени

выполнения перед вызовом удаленной процедуры и должен отсоединиться по

завершении всех удаленных вызовов. Структура программы клиента, которая

управляет собственным соединением с сервером , описана в следующем фраг -

менте кода. Удаленные вызовы процедуры помещаются между вызовами этих

функций клиентской библиотеки времени выполнения:

/* файл: helloc.c (фрагмент) */

#include "hello.h" // заголовок, сгенерированный

// компилятором MIDL

void main(void)

{

RpcStringBindingCompose(...);

RpcBindingFromStringBinding(...);

HelloProc(pszString); // удаленный вызов

RpcStringFree(...);

RpcBindingFree(...);

}

Первые два вызова API времени выполнения устанавливают имеющий си-

лу дескриптор для сервера. Этот дескриптор затем используется, чтобы сделать

удаленный вызов процедуры . Заключительные два вызова API времени выпол -

нения освобождают его .

Функции Microsoft RPC используют структуры данных, которые представ-

ляют связывание, интерфейс , последовательность протоколов и пункт на-

значения (endpoint). Связывание – это соединение между клиентом и сервером ;

интерфейс – совокупность типов данных и процедур, реализованных сервером ;

последовательность протоколов – спецификация базового сетевого транспорта,

который нужно использовать для передачи данных по сети; пункт назначения –

сетевое имя, которое является специфическим для последовательности прото -

колов. Данный пример использует именованные каналы (named pipe) в качестве

последовательности протоколов, и пункт назначения \pipe\hello. В приводимом

далее примере кода функция RpcStringBindingCompose комбинирует по-

следовательность протоколов, сетевой адрес (имя сервера), пункт назначения

(имя канала) и другие строковые элементы в форму, требующуюся для сле-

дующей функции, RpcBindingFromStringBinding, а также распределяет

память для размещения символьной строки. В свою очередь, RpcBinding-

FromStringBinding использует эту строку для генерации дескриптора, кото -

рый представляет связывание между сервером и клиентом . После того , как уда-

ленные вызовы процедур выполнены , RpcStringFree освобождает память,

которая была распределена RpcStringBindingCompose для структуры дан -

ных строки связывания . RpcBindingFree освобождает дескриптор.

Строка связывания (string binding), таким образом , является ключевым

понятием при реализации соединения программно- управляемого типа, по-

скольку содержит всю необходимую для этого информацию . Строка связыва-

ния состоит из нескольких подстрок , представляющих UUID интерфейса, по-

следовательность протоколов, сетевой адрес, пункт назначения и его опции.

Последовательность протоколов, в свою очередь, представляет сетевой RPC

протокол , а также определяет соглашения о соответствующем формате сетевых

адресов и об именовании пунктов назначения. Например , последовательность

протоколов ncacn_ip_tcp определяет протокол с установлением соединения,

в терминах NCA (Network Computing Architecture), над TCP/IP. При этом требу -

ется соответствующий формат представления сетевого адреса или имени серве-

ра, а пункт назначения обозначает серверный коммуникационный порт.

В общем случае последовательность протоколов содержит набор из трех

опций , которые должны быть определены для RPC-библиотеки времени вы -

полнения:

• RPC протокол , доступные опции – ncacn (NCA Connection-oriented) и

ncadg (Datagram-oriented);

• формат сетевого адреса, доступные опции – ip, dnet и osi;

• транспортный протокол , доступные опции – tcp, udp, nsp, dna, np

(named pipes) и nb (NetBIOS).

Заметим , что наиболее сложные распределенные приложения для получе-

ния дескриптора связывания должны использовать функции сервиса имен вме-

сто строк связывания. Функции сервиса имен позволяют серверу регистриро-

вать интерфейс, UUID, сетевой адрес и пункт назначения под одним логиче-

ским именем . Эти функции обеспечивают независимость расположения компо-

нентов приложения и легкость администрирования.

Полный текст программы клиента включает код для обработки ввода ко-

мандной строки и выглядит следующим образом :

#include <stdlib.h>

#include <stdio.h>

#include <ctype.h>

#include "hello.h" // заголовок, сгенерированный

// компилятором MIDL

void Usage(char * pszProgramName)

{ fprintf(stderr, "Usage: %s\n", pszProgramName);

fprintf(stderr, " -p protocol_sequence\n");

fprintf(stderr, " -n network_address\n");

fprintf(stderr, " -e endpoint\n");

fprintf(stderr, " -o options\n");

fprintf(stderr, " -s string\n");

exit(1);

}

void main(int argc, char **argv)

{ RPC_STATUS status;

unsigned char * pszUuid = NULL;

unsigned char * pszProtocolSequence = "ncacn_np";

unsigned char * pszNetworkAddress = NULL;

unsigned char * pszEndpoint = "\\pipe\\hello";

unsigned char * pszOptions = NULL;

unsigned char * pszStringBinding = NULL;

unsigned char * pszString = "Hello, world";

unsigned long ulCode;

int i;

/* Обработка ключей командной строки, позволяющих изменять

определенные выше установки параметров */

for (i = 1; i < argc; i++) {

if ((*argv[i] == '-') || (*argv[i] == '/')) {

switch (tolower(*(argv[i]+1))) {

case 'p': // protocol sequence

pszProtocolSequence = argv[++i]; break;

case 'n': // network address

pszNetworkAddress = argv[++i]; break;

case 'e': // endpoint

pszEndpoint = argv[++i]; break;

case 'o': // options

pszOptions = argv[++i]; break;

case 's': // string

pszString = argv[++i]; break;

case 'h':

case '?':

default: Usage(argv[0]);

}

else Usage(argv[0]);

}

/* Формирование строки связывания в требуемом формате */

status = RpcStringBindingCompose(

pszUuid,

pszProtocolSequence,

pszNetworkAddress,

pszEndpoint,

pszOptions,

&pszStringBinding);

printf("RpcStringBindingCompose returned 0x%x\n",status);

printf("pszStringBinding = %s\n", pszStringBinding);

if (status) exit(status);

/* Установка дескриптора связывания */

status = RpcBindingFromStringBinding(

pszStringBinding,

&hello_IfHandle);

printf("RpcBindingFromStringBinding returned 0x%x\n",

status);

if (status) exit(status);

printf("Calling the remote procedure 'HelloProc'\n");

printf("Print the string '%s' on the server\n",

pszString);

RpcTryExcept {

HelloProc(pszString); // удаленный вызов

printf("Calling the remote procedure 'Shutdown'\n");

Shutdown(); // остановка сервера (используется далее)

}

RpcExcept(1) {

ulCode = RpcExceptionCode();

printf("Runtime reported exception 0x%lx \n",ulCode);

}

RpcEndExcept

/* Удаленные вызовы сделаны. */

/* Освобождение строки и дескриптора связывания */

status = RpcStringFree(&pszStringBinding);

printf("RpcStringFree returned 0x%x\n", status);

if (status) exit(status);

status = RpcBindingFree(&hello_IfHandle);

printf("RpcBindingFree returned 0x%x\n", status);

if (status) exit(status);

exit(0);

}

void __RPC_FAR * __RPC_USER midl_user_allocate(size_t len)

{ return(malloc(len));

}

void __RPC_USER midl_user_free(void __RPC_FAR * ptr)

{ free(ptr);

}

Сборка приложения клиента

Распределенное приложение требует, чтобы перед компиляцией и компо-

новкой исходного текста на C был сделан дополнительный подготовительный

шаг : компиляция IDL и ACF файлов с использованием компилятора MIDL. При

этом необходимо с самого начала обратить внимание на то , что результаты этой

компиляции зависят:

• от версий операционной системы, которая будет строить приложение;

• от операционной системы (систем ), в которой будут выполняться про-

граммы клиента и сервера;

• от сетевой последовательности протоколов, которая будет использо-

ваться в реализации распределенного приложения.

Все эти условия определят версии используемых MIDL и C компиляторов,

версии заголовочных файлов, включаемых в приложения, и версии RPC-

библиотек времени выполнения, компонуемых с приложениями. Для простоты

мы примем , что этот первый пример использует одну и ту же операционную

систему – Microsoft Windows NT – как для построения, так и в качестве плат -

формы клиента и сервера, и что пример использует именованные каналы в ка-

честве последовательности протоколов.

MIDL компиляция

IDL файл HELLO.IDL и файл конфигурации приложения HELLO.ACF

компилируется с использованием компилятора MIDL:

# makefile, фрагмент

midl hello.idl

Компилятор MIDL генерирует файл заголовка HELLO.H и файл клиент-

ского стаба на языке C HELLO_C.C. (Компилятор MIDL также производит

файл серверного стаба HELLO_S.C, но мы пока его игнорируем .)

Компиляция C

Остальная часть процесса разработки знакома: компиляция исходных фай -

лов на языке C и компоновка их с RPC-библиотеками времени выполнения для

целевой платформы и всеми остальными библиотеками, требующимися для

приложения . Следующие команды компилируют пример клиентской програм -

мы:

# makefile, Фрагмент

# CC обращается к компилятору C

# CFLAGS задает ключи компилятора C

# CVARS управляет директивой #ifdef

$(CC) $(CFLAGS) $(CVARS) helloc.c

$(CC) $(CFLAGS) $(CVARS) hello_c.c

Обратите внимание: приведенные команды предполагают наличие опреде-

ленной конфигурации программного обеспечения, которая состоит из утилиты

nmake, компилятора Microsoft C и операционной системы Microsoft Windows

NT.

Компоновка

Исходные файлы клиента затем компонуются с клиентской библиотекой

времени выполнения, библиотекой сетевого представления данных и стандарт-

ной библиотекой C времени выполнения для данной платформы.

# makefile, фрагмент

# LINK обращается к компоновщику

# CONFLAGS задает флаги консольных приложений

# CONLIBS задает библиотеки консольных приложений

client.exe : helloc.obj hello_c.obj

$(LINK) $(CONFLAGS) -out:client.exe helloc.obj hello_c.obj \

$(CONLIBS) rpcrt4.lib

Заметьте, что команды компоновщика и параметры могут измениться в за-

висимости от конкретной компьютерной конфигурации.

Сборка клиента, резюме

Следующий фрагмент файла MAKEFILE для утилиты nmake показывает

зависимости между файлами, используемыми для построения приложения кли-

ента.

# makefile, фрагмент

client.exe : helloc.obj hello_c.obj

...

hello.h hello_c.c : hello.idl hello.acf

...

helloc.obj : helloc.c hello.h

...

hello_c.obj : hello_c.c hello.h

...

Пример использовал заданные по умолчанию имена файлов, которые про-

изведены компилятором MIDL. Заданное по умолчанию имя для файла клиент-