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

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

ского стаба сформировано из имени IDL файла (без расширения) и символов

_C.C. Если имя (без расширения ) имеет длину более шести символов, некото -

рые файловые системы могут не принимать полученное имя файла стаба. В

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

имена. Имя клиентского стаба можно изменить, воспользовавшись ключом

/cstub компилятора MIDL:

midl hello.idl -cstub mystub.c

Если в командной строке компилятора MIDL определены ваши собствен-

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

мандах компиляции и компоновки.

Программа сервера

Серверная сторона распределенного приложения сообщает системе, что

сервисы являются доступными, после чего переходит в состояние ожидания за-

просов клиента. В зависимости от размера приложения и привычек кодирова-

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

большем количестве отдельных файлов. В данном примере основная подпро-

грамма помещена в исходный файл HELLOS.C, а удаленная процедура реали-

зуется в отдельном файле, именованном HELLOP.C. Польза от такой организа-

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

ры могут быть скомпонованы с автономной программой для отладки кода,

прежде чем она будет преобразована в распределенное приложение. После то -

го , как программа заработает автономно, те же самые исходные файлы могут

компилироваться и компоноваться с серверным приложением . Подобно исход -

ному файлу клиентской прикладной программы, исходный файл программы

сервера должен включить заголовочный файл HELLO.H, чтобы получить опре-

деления данных и функций RPC, а также специфических для интерфейса дан -

ных и функций .

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

В следующем примере сервер вызывает функции

RpcServerUseProtseqEp и RpcServerRegisterIf, чтобы сделать инфор-

мацию связывания доступной клиенту . Затем сервер сообщает о своей готовно-

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

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

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

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

void main(void)

{

RpcServerUseProtseqEp(...);

RpcServerRegisterIf(...);

RpcServerListen(...);

}

RpcServerUseProtseqEp идентифицирует пункт назначения (endpoint)

сервера и последовательность сетевых протоколов. RpcServerRegisterIf ре-

гистрирует интерфейс, а RpcServerListen инструктирует сервер начать про-

слушивание запросов клиента.

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

серверными стабами, midl_user_allocate и midl_user_free. Эти функции

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

ленная процедура должна передать параметры . В следующем примере,

midl_user_allocate и midl_user_free реализованы с использованием

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

void __RPC_FAR * __RPC_API midl_user_allocate(size_t len)

{

return(malloc(len));

}

void __RPC_API midl_user_free(void __RPC_FAR * ptr)

{

free(ptr);

}

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

#include <stdlib.h>

#include <stdio.h>

#include <ctype.h>

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

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

void Usage(char * pszProgramName)

{ fprintf(stderr, "%s", PURPOSE);

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

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

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

fprintf(stderr, " -m maxcalls\n");

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

fprintf(stderr, " -f flag_wait_op\n");

exit(1);

}

void main(int argc, char * argv[])

{ RPC_STATUS status;

unsigned char * pszProtocolSequence = "ncacn_np";

unsigned char * pszSecurity = NULL;

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

unsigned int cMinCalls = 1;

unsigned int cMaxCalls = 20;

unsigned int fDontWait = FALSE;

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 'e': // endpoint

pszEndpoint = argv[++i]; break;

case 'm': // max concurrent calls

cMaxCalls = (unsigned int) atoi(argv[++i]);

break;

case 'n': // min concurrent calls

cMinCalls = (unsigned int) atoi(argv[++i]);

break;

case 'f': // flag

fDontWait = (unsigned int) atoi(argv[++i]);

break;

case 'h':

case '?':

default: Usage(argv[0]);

}

else Usage(argv[0]);

}

status = RpcServerUseProtseqEp(

pszProtocolSequence,

cMaxCalls,

pszEndpoint,

pszSecurity); // Security-дескриптор

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

if (status) exit(status);

status = RpcServerRegisterIf(

hello_ServerIfHandle,

NULL, // MgrTypeUuid

NULL); // MgrEpv; null по умолчанию

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

if (status) exit(status);

printf("Calling RpcServerListen\n");

status = RpcServerListen(

cMinCalls,

cMaxCalls,

fDontWait);

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

if (status) exit(status);

if (fDontWait) {

printf("Calling RpcMgmtWaitServerListen\n");

status = RpcMgmtWaitServerListen(); // ожидание

printf("RpcMgmtWaitServerListen returned: 0x%x\n",

status);

if (status) exit(status);

}

/* распределение памяти */

void __RPC_FAR * __RPC_API midl_user_allocate(size_t len)

{ return(malloc(len));

}

void __RPC_API midl_user_free(void __RPC_FAR * ptr)

{ free(ptr);

}

Сборка серверного приложения

Сборка серверного приложения совершенно аналогична сборке приложе-

ния клиента.

MIDL компиляция

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

вместе с файлом клиентского стаба и файлом заголовка. Компилятор MIDL

создает все эти три файла одновременно . В нашем примере нет необходимости

вызывать компилятор MIDL дважды. Командная строка компилятора MIDL вы -

глядит следующим образом :

# makefile, фрагмент

midl hello.idl

Компиляция C

Исходные файлы на C, содержащие вызовы серверных RPC-функций и

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

ванным компилятором MIDL:

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

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

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

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

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

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

NT.

Компоновка

Как только исходные файлы на C откомпилированы , они компонуются с

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

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

(у нас – именованными каналами) и модели памяти:

# makefile, фрагмент

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

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

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

server.exe : hellos.obj hellop.obj hello_s.obj

$(LINK) $(CONFLAGS) -out:server.exe hellos.obj hellop.obj \

hello_s.obj $(CONLIBS) rpcrt4.lib

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

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

Сборка сервера , резюме

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

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

вера. Исполняемая программа собирается из исходных файлов сервера и файла

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

HELLO.H:

# makefile, фрагмент

server.exe : hellos.obj hellop.obj hello_s.obj

...

hello.h hello_s.c : hello.idl hello.acf

...

hellos.obj : hellos.c hello.h

...

hellop.obj : hellop.c hello.h

...

hello_s.obj : hello_s.c hello.h

...

Остановка серверного приложения

Робастная серверная программа при завершении работы должна остано-

вить прослушивание клиентов и аннулировать регистрацию интерфейса. Для

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

функции – RpcMgmtStopServerListening и RpcServerUnregisterIf.

Серверная функция RpcServerListen не возвращает вызвавшей программе

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

зовет RpcMgmtStopServerListening. В Microsoft RPC клиент не может не-

посредственно вызывать эту функцию , останавливающую прослушивание.

Можно , однако, разработать программу сервера так , чтобы пользователь мог

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

го приложения вызвать RpcMgmtStopServerListening. Другой путь реше-

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

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

ет RpcMgmtStopServerListening. Следующий пример использует послед -

ний из подходов, для чего к HELLOP.C добавлена новая удаленная функция

Shutdown:

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

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

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

void Shutdown(void)

{

RPC_STATUS status;

status = RpcMgmtStopServerListening(NULL);

...

status = RpcServerUnregisterIf(NULL, NULL, FALSE);

...

}

Единственный параметр со значением NULL указывает

RpcMgmtStopServerListening, что локальное приложение должно остано-

вить прослушивание удаленных вызовов процедур. Два NULL-параметра для

RpcServerUnregisterIf указывают, что никакие интерфейсы не останутся

зарегистрированными. Параметр FALSE требует, чтобы регистрация интерфей -

са была аннулирована немедленно .

Процедура Shutdown, поскольку она является удаленной , должна также

быть добавлена в секцию тела интерфейса IDL файла:

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

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

version(1.0)

]

interface hello

{

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

void Shutdown(void);

}

Наконец, программа клиента должна добавить вызов функции Shutdown:

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

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

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

void main(void)

{

char * pszString = "Hello, world";

RpcStringBindingCompose(...);

RpcBindingFromStringBinding(...);

HelloProc(pszString);

Shutdown();

RpcStringFree(...);

RpcBindingFree(...);

}

Особенности сборки RPC приложений в среде визуаль-

ного программирования

Рассмотренная выше последовательность операций иллюстрирует процесс

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

средств, сопровождающих поставку компилятора Microsoft C: компилятора

MIDL, утилиты nmake, компоновщика, библиотекаря и т.д . Те же шаги можно

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

граммирования на C++: Microsoft Visual C++ или Borland C++ Builder, в состав

поставки которых входит компилятор MIDL.

Если не ставить цели интегрировать процесс компиляции IDL-файлов в

среду разработки, компилятор MIDL можно запускать просто из командной

строки, как показано в предыдущих разделах . При этом необходимо помнить,

что компилятор MIDL реализован как динамическое приложение и может по-

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

файлы для стабов и заголовочный файл затем необходимо добавить в соответ-

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

программирования.

Так рассматриваемый в данном руководстве пример реализуется в виде

двух консольных приложений : клиентского и серверного . Компиляция примера

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

чего изменяются соглашения относительно генерируемых им идентификаторов.

Например , MIDL из поставки Visual C++ 6.0 изменяет имя структуры данных

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

шем примере идентификатором hello_ServerIfHandle. Затруднения при

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

библиотечных файлов RPC-библиотек времени выполнения. Например , для по-

ставки Visual C++ 6.0, необходимо добавить в установки проекта (окно «Project

Settings» , вкладка «Link» ) имя библиотечного модуля rpcrt4.lib. Для C++

Builder, возможно , потребуется указать путь к библиотечным модулям RPC

(окно «Project Options» , вкладка «Directories/Conditionals» ). Например , при

стандартной установке C++ Builder 5.0 эти модули помещаются в каталог

\Lib\PSDK .

Заключение: основные шаги при разработке RPC при -

ложений

Распределенное приложение состоит из исполняемых программ на стороне

клиента и на стороне сервера.

Процесс разработки с использованием RPC включает, в дополнение к

стандартному процессу разработки, два шага. Вы должны определить интер -

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

лируются MIDL. Компилятор MIDL производит исходные файлы на C и файлы

стабов. Далее следует обычный для любого приложения процесс разработки:

компилируются файлы языка C и компонуются объектные модули с библиоте -

ками для создания исполняемых программ.

Для распределенного приложения «Привет, мир» , разработчик создает

следующие исходные файлы:

• HELLOC.C

• HELLOS.C

• HELLOP.C

• HELLO.IDL

• HELLO.ACF

Компилятор MIDL использует файлы HELLO.IDL и HELLO.ACF для гене-

рации исходного файла клиентского стаба HELLO_C.C, исходного файла сер -

верного стаба HELLO_S.C и файл заголовка HELLO.H, который в свою очередь

включает заголовочный файл RPC.H.

Исполняемая программа клиента строится из клиентской библиотеки вре-

мени выполнения и следующих файлов на языке C, заголовочного и исходных:

• HELLO.H

• HELLOC.C

• HELLO_C.C (клиентский стаб)

Исполняемая программа сервера строится из серверной библиотеки време-

ни выполнения и следующих файлов на языке C, заголовочного и исходных:

• HELLO.H

• HELLOS.C

• HELLOP.C

• HELLO_S.C (серверный стаб)

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

зованием Microsoft RPC:

1. Создание файла на языке определения интерфейсов, который определяет

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

для удаленных процедур.

2. Создание файла конфигурации приложения.

3. Компиляция определения интерфейса с использованием MIDL. Компилятор

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

клиента и сервера.

4. Включение (include) заголовочных файлов, сгенерированных компилятором

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

5. Написание исходного текста программы сервера, которая вызывает функции

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

зывает RpcServerListen для начала прослушивания клиентских запросов.

Обеспечение метода остановки сервера.

6. Компоновка клиента с файлом клиентского стаба и клиентской RPC-

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

7. Компоновка сервера с файлом серверного стаба, удаленными процедурами и

серверной RPC-библиотекой времени выполнения.

Практические задания

1. Средствами MS RPC реализуйте распределенное приложение, в котором

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

тов, с поддержкой процедуры их регистрации.

2. Средствами MS RPC реализуйте распределенное приложение, в котором

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

ет функции каталога файлов, а также процедуру регистрации клиентов и авто -

ризации сохраняемой информации.

3. Средствами MS RPC реализуйте распределенное приложение с серве-

ром–вычислителем , хранящим библиотеку математических функций . Сервер

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

ентов и продолжительность работы по их удовлетворению .

4. Средствами MS RPC реализуйте распределенное приложение, в котором

сервер исполняет роль архиватора, поддерживая функции сжатия клиентских

потоков данных без потери информации. Алгоритмы компрессии/ декомпрессии

выберите сами.

5. Средствами MS RPC реализуйте распределенное приложение, в котором

сервер выполняет функции шифрования клиентских потоков данных одним (а

возможно – несколькими, по запросу клиента) из известных вам алгоритмов.

Запросы на расшифровку данных должны сопровождаться процедурой регист-

рации клиентов.

6. Средствами MS RPC реализуйте распределенное приложение с безопас -

ным обменом информацией по сети: передаваемые потоки данных должны

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

7. Средствами MS RPC реализуйте распределенное приложение с интен-

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

редаваемые потоки данных сжимаются без потери информации. Алгоритмы

компрессии/декомпрессии выберите сами.

8. Средствами MS RPC реализуйте асинхронный параллельный вычисли-

тельный процесс в распределенном приложении: клиент подготавливает массив

данных и передает его серверу , запуская процедуру обработки (на ваше усмот-

рение). Далее клиент генерирует следующий массив, а также производит пе-

риодический опрос сервера на предмет завершения обработки и готовности

данных к возвращению клиенту .

9. Средствами MS RPC реализуйте распределенное приложение – модель

службы времени: клиенты периодически синхронизируют свои таймеры с вре-

менем на сервере; сервер устанавливает свой таймер , усредняя время, сообщае -

мое клиентами. Каким образом ваша система учитывает задержки на реализа-

цию удаленных вызовов?

10. Средствами MS RPC реализуйте модель «профайлера» распределенно-

го приложения – средства, позволяющего измерять время исполнения удален-

ных вызовов с различными типами параметров и при различных способах раз -

мещения клиента и сервера, а также – в зависимости от выбора транспорта.