Пример

Пример

В качестве примера использования RPC перепишем листинги 15.1 и 15.2 для использования Sun RPC вместо дверей. Клиент вызывает процедуру сервера с аргументом типа long, а возвращаемое значение представляет собой квадрат аргумента. В листинге 16.1[1] приведен текст первого файла, square.х.

Листинг 16.1. Файл спецификации RPC

//sunrpc/square1/square.x

1 struct square_in { /* входные данные (аргумент) */

2  long arg1;

3 };

4 struct square_out { /* возвращаемые данные (результат) */

5  long res1;

6 };

7 program SQUARE_PROG {

8  version SQUARE_VERS {

9   square_out SQUAREPROC(square_in) = 1; /* номер процедуры = 1 */

10  } = 1; /* номер версии */

11 } = 0x31230000; /* номер программы */

Файлы с расширением .х называются файлами спецификации RPC. Они определяют процедуры сервера, их аргументы и возвращаемые значения.

Определение аргумента и возвращаемого значения

1-6 Мы определяем две структуры — одну для аргументов (одно поле типа long) и одну для результатов (тоже одно поле типа long).

Определение программы, версии и процедуры

7-11 Мы определяем программу RPC с именем SQUARE_PROG, состоящую из одной версии (SQUARE_VERS), а эта версия представляет собой единственную процедуру сервера с именем SQUAREPROC. Аргументом этой процедуры является структура square_in, а возвращаемым значением — структура square_out. Мы также присваиваем этой процедуре номер 1, как и версии, а программе мы присваиваем 32-разрядный шестнадцатеричный номер. (О номерах программ более подробно говорится в табл. 16.1.)

Компилировать спецификацию нужно программой rpcgen, входящей в пакет Sun RPC.

Теперь напишем функцию main клиента, который будет осуществлять удаленный вызов процедуры. Текст программы приведен в листинге 16.2.

Листинг 16.2. Функция main клиента, делающего удаленный вызов процедуры

//sunrpc/square1/client.c

1  #include "unpipc.h" /* наш заголовочный файл */

2  #include "square.h" /* создается rpcgen */

3  int

4  main(int argc, char **argv)

5  {

6   CLIENT *cl;

7   square_in in;

8   square_out *outp;

9   if (argc != 3)

10   err_quit("usage: client <hostname> <integer-value>");

11  cl = Clnt_create(argv[1], SQUARE_PROG, SQUARE_VERS, "tcp");

12  in.arg1 = atol(argv[2]);

13  if ((outp = squareproc_1(&in, cl)) == NULL)

14   err_quit("ls", clnt_sperror(cl, argv[1]));

15  printf("result: %ld ", outp->res1);

16  exit(0);

17 }

Подключение заголовочного файла, создаваемого rpcgen

2 Мы подключаем заголовочный файл square.h, создаваемый функцией rpcgen.

Объявление дескриптора клиента

6 Мы объявляем дескриптор клиента (client handle) с именем cl. Дескрипторы клиентов выглядят как обычные указатели на тип FILE (поэтому слово CLIENT пишется заглавными буквами).

Получение дескриптора клиента

11 Мы вызываем функцию clnt_create, создающую клиент RPC:

#include <rpc/rpc.h>

CLIENT *clnt_create(const char *host, unsigned long prognum, unsigned long versnum, const char *protocol);

/* Возвращает ненулевой дескриптор клиента в случае успешного завершения. NULL – в случае ошибки */

Как и с обычными указателями на тип FILE, нам безразлично, на что указывает дескриптор клиента. Скорее всего, это некоторая информационная структура, хранящаяся в ядре. Функция clnt_create создает такую структуру и возвращает нам указатель на нее, а мы передаем его библиотеке RPC времени выполнения каждый раз при удаленном вызове процедуры.

Первым аргументом clnt_create должно быть имя или IP-адрес узла, на котором выполняется сервер. Вторым аргументом будет имя программы, третьим — номер версии. Оба эти значения берутся из спецификации (square.х, листинг 16.1). Последний аргумент позволяет указать протокол, обычно TCP или UDP.

Вызов удаленной процедуры и вывод результата

12-15 Мы вызываем процедуру, причем первый аргумент указывает на входную структуру (&in), а второй содержит дескриптор клиента. В большинстве стандартных функций ввода-вывода дескриптор файла является последним аргументом. Точно так же и в вызовах RPC дескриптор клиента передается последним. Возвращаемое значение представляет собой указатель на структуру, в которой хранится результат работы сервера. Место под входную структуру выделяет программист, а под возвращаемую — пакет RPC.

В файле спецификации square.x мы назвали процедуру SQUAREPROC, но из клиента мы вызываем squareproc_1. Существует соглашение о преобразовании имени из файла спецификации к нижнему регистру и добавлении номера версии через символ подчеркивания.

Со стороны сервера от нас требуется только написать процедуру. Функция main автоматически создается программой rpcgen. Текст процедуры приведен в листинге 16.3.

Листинг 16.3. Процедура сервера, вызываемая с помощью Sun RPC

//sunrpc/square1/server.c

1 #include "unpipc.h"

2 #include "square.h"

3 square_out *

4 squareproc_l_svc(square_in *inp, struct svc_req *rqstp)

5 {

6  static square_out out;

7  out.res1 = inp->arg1 * inp->arg1;

8  return(&out);

9 }

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

3-4 Прежде всего мы замечаем, что к имени процедуры добавился суффикс _svc. Это дает возможность использовать два прототипа функций ANSI С в файле square.x, один из которых определяет функцию, вызываемую клиентом в листинге 16.2 (она принимает дескриптор клиента), а второй — реальную функцию сервера (которая принимает другие аргументы).

При вызове процедуры сервера первый аргумент является указателем на входную структуру, а второй — на структуру, передаваемую библиотекой RPC времени выполнения, которая содержит информацию о данном вызове (в этом примере игнорируется для простоты).

Выполнение и возврат

6-8 Программа считывает входной аргумент и возводит его в квадрат. Результат сохраняется в структуре, адрес которой возвращается процедурой сервера. Поскольку мы возвращаем адрес переменной, эта переменная не может быть автоматической. Мы объявляем ее как статическую (static).

ПРИМЕЧАНИЕ

Внимательные читатели заметят, что это лишает нашу функцию возможности использования в защищенном поточном программировании. Мы обсудим это в разделе 16.2, где приведем пример защищенной функции. 

Откомпилируем клиент в системе Solaris, а сервер — в BSD/OS, запустим сервер, а затем клиент:

solaris % client bsdi 11

result: 121

solaris % client 209.75.135.35 22

result: 484

В первом случае мы указываем имя узла сервера, а во втором — его IP-адрес. Этим мы демонстрируем возможность использования как имен, так и IP-адресов для задания узла в функции clnt_create.

Теперь продемонстрируем некоторые ошибки, возникающие при работе clnt_create, если, например, не существует узел или на нем не запущена программа-сервер:

solaris % client nosuchhost 11

nosuchhost: RPC: Unknown host возвращается библиотекой RPC времени выполнения

clnt_create error             возвращается нашей функцией-оберткой

solaris % client localhost 11

localhost: rpc: program not registered

clnt_create error

Мы написали клиентскую и серверную части программы и продемонстрировали их использование вообще без явного сетевого программирования. Клиент просто вызывает две функции, а сервер вообще состоит из одной функции. Все тонкости использования XTI в Solaris, сокетов в BSD/OS и сетевого ввода-вывода обрабатываются библиотекой RPC времени выполнения. В этом и состоит предназначение RPC — предоставлять возможность создания распределенных приложений без знания сетевого программирования.

Другая немаловажная деталь данного примера заключается в том, что в системах Sparc под Solaris и Intel x86 под управлением BSD/OS используется разный порядок байтов. В Sparc используется порядок big endian («тупоконечный»[2]), а в Intel — little endian («остроконечный») (что мы показали в разделе 3.4 [24]). Отличия в порядке байтов также обрабатываются библиотекой RPC времени выполнения автоматически с использованием стандарта XDR (внешнее представление данных), который мы обсудим в разделе 16.8.

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

solaris % rpcgen-Сsquare.x

solaris % cc-сclient.с-оclient.о

solaris % cc-сsquare_clnt.c-оsquare_clnt.o

solaris % cc-сsquare_xdr.с-оsquare_xdr.o

solaris % cc-оclient client.оsquare_clnt.o square_xdr.o libunpipc.a –lnsl

Параметр –С говорит rpcgen о необходимости создания прототипов функций ANSI С в заголовочном файле square.h. Программа rpcgen также создает заглушку клиента (client stub) в файле с именем square_clnt.с и файл с именем square_xdr.с, который осуществляет преобразование данных в соответствии со стандартом XDR. Наша библиотека (содержащая функции, используемые в этой книге) называется libunpipc.a, а параметр –lnsl подключает системную библиотеку сетевых функций в Solaris (включая библиотеки RPC и XDR времени выполнения).

Аналогичные команды используются для создания сервера, хотя rpcgen уже не нужно запускать снова. Файл square_svc.c содержит функцию main сервера, и файл square_xdr.о, обсуждавшийся выше, также требуется для работы сервера:

solaris % cc –с server.с –о server.о

solaris % сc –с square_svc.c –о square_svc.o

solaris % cc –о server server.о square_svc.o libunpipc.a –lnsl

При этом создаются клиент и сервер, выполняемые в системе Solaris.

Если клиент и сервер должны быть построены для разных систем (как в предыдущем примере, где клиент выполнялся в Solaris, а сервер — в BSD/OS), могут потребоваться дополнительные действия. Например, некоторые файлы должны быть либо общими (через NFS), либо находиться в обеих системах, а файлы, используемые клиентом и сервером (например, square_xdr.o), должны компилироваться в каждой системе в отдельности. 

Рис. 16.1. Этапы создания приложения клиент-сервер с использованием RPC

На рис. 16.1 приведена схема создания приложения типа клиент-сервер. Три затемненных прямоугольника соответствуют файлам, которые мы должны написать. Штриховые линии показывают файлы, подключаемые через заголовочный файл square.h.

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

1. Запускается сервер, который регистрируется в программе, управляющей портами на узле-сервере. Затем запускается клиент и вызывает clnt_create. Эта функция связывается с управляющей портами программой сервера и находит нужный порт. Функция clnt_create также устанавливает соединение с сервером по протоколу TCP (поскольку мы указали TCP в качестве используемого протокола в листинге 16.2). Мы не показываем эти шаги на рисунке и откладываем детальное обсуждение до раздела 16.3.

2. Клиент вызывает локальную процедуру, называемую заглушкой клиента. В листинге 16.2 эта процедура называлась squareproc_1, а файл, содержащий ее, создавался rpcgen автоматически и получал название square_clnt.c. С точки зрения клиента именно эта функция является сервером, к которому он обращается. Целью создания заглушки является упаковка аргументов для удаленного вызова процедуры, помещение их в стандартный формат и создание одного или нескольких сетевых сообщений. Упаковка аргументов клиента в сетевое сообщение называется сортировкой (marshaling). Клиент и заглушка обычно вызывают библиотеки функций RPC (clnt_create в нашем примере). При использовании редактора связей в Solaris эти функции загружаются из библиотеки –lnsl, тогда как в BSD/OS они входят в стандартную библиотеку языка С.

3. Сетевые сообщения отсылаются на удаленную систему заглушкой клиента. Обычно это требует локального системного вызова (например, write или sendto).

4. Сетевые сообщения передаются на удаленную систему. Для этого обычно используются сетевые протоколы TCP и UDP.

5. Заглушка сервера ожидает запросов от клиента на стороне сервера. Она рассортировывает аргументы из сетевых сообщений.

6. Заглушка сервера осуществляет локальный вызов процедуры для запуска настоящей функции сервера (процедуры squareproc_l_svc в листинге 16.3), передавая ей аргументы, полученные в сетевых сообщениях от клиента.

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

8. Заглушка сервера преобразовывает возвращаемые значения к нужному формату и рассортировывает их в сетевые сообщения для отправки обратно клиенту.

9. Сообщения передаются по сети обратно клиенту. 

10. Заглушка клиента считывает сообщения из локального ядра (вызовом read или recvfrom).

11. После возможного преобразования возвращаемых значений заглушка клиента передает их функции клиента. Этот этап воспринимается клиентом как завершение работы процедуры.

Рис. 16.2. Действия, происходящие при удаленном вызове процедуры

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

Пример

Из книги Обработка событий в С++ автора Клюев Александр

Пример В примере создаются два класса обработчик и инициатор события, устанавливается связь между ними и иллюстрируется обработка события в нескольких объектах одновременно:#include "stdafx.h" #include "sigslot.h"struct EventRaiser { // источник события signal<const char*> event; // const char* – тип аргумента.


25.5. Пример

Из книги Разработка приложений в среде Linux. Второе издание автора Джонсон Майкл К.

25.5. Пример Для закрепления материала этой главы ниже приводится пример приложения, в котором задействовано большинство функциональных возможностей qdbm. Подразумевается, что в результате выполнения этого приложения будет создана простая база данных телефонных номеров,


27.1.1. Пример

Из книги Искусство программирования на языке сценариев командной оболочки автора Купер Мендель

27.1.1. Пример В главе 8 был представлен пример использования обычной разделяемой библиотеки. Библиотеку libhello.so, которую нам удалось создать, можно загружать во время выполнения. Программа loadhello загружает libhello.so динамически и вызывает функцию print_hello, которая находится в


Пример 10-27. Простой пример сравнения строк

Из книги Программирование для Linux. Профессиональный подход автора Митчелл Марк

Пример 10-27. Простой пример сравнения строк #!/bin/bash# match-string.sh: простое сравнение строкmatch_string (){ MATCH=0 NOMATCH=90 PARAMS=2 # Функция требует два входных аргумента. BAD_PARAMS=91 [ $# -eq $PARAMS ] || return $BAD_PARAMS case "$1" in "$2") return $MATCH;; * ) return $NOMATCH;; esac}a=oneb=twoc=threed=twomatch_string $a # неверное число


Пример 12-20. Пример форматирования списка файлов в каталоге

Из книги UNIX: разработка сетевых приложений автора Стивенс Уильям Ричард

Пример 12-20. Пример форматирования списка файлов в каталоге #!/bin/bash# За основу сценария взят пример "man column".(printf "PERMISSIONS LINKS OWNER GROUP SIZE DATE TIME PROG-NAME " ; ls -l | sed 1d) | column -t# Команда "sed 1d" удаляет первую строку, выводимую командой ls,#+ (для локали "С" это строка: "total N",#+ где "N" -- общее


Пример 12-45. Пример работы с m4

Из книги UNIX — универсальная среда программирования автора Пайк Роб

Пример 12-45. Пример работы с m4 #!/bin/bash# m4.sh: Демонстрация некоторых возможносией макропроцессора m4# Строкиstring=abcdA01echo "len($string)" | m4 # 7echo "substr($string,4)" | m4 # A01echo "regexp($string,[0-1][0-1],&Z)" | m4 # 01Z# Арифметикаecho "incr(22)" | m4 # 23echo "eval(99 / 3)" | m4 #


Пример 24-2. Еще один пример проверки аргументов с помощью "И-списков"

Из книги автора

Пример 24-2. Еще один пример проверки аргументов с помощью "И-списков" #!/bin/bashARGS=1 # Ожидаемое число аргументов.E_BADARGS=65 # Код завершения, если число аргументов меньше ожидаемого.test $# -ne $ARGS && echo "Порядок использования: `basename $0` $ARGS аргумент(а)(ов)" && exit $E_BADARGS# Если


Пример 25-8. Пример реализации алгоритма Решето Эратосфена

Из книги автора

Пример 25-8. Пример реализации алгоритма Решето Эратосфена #!/bin/bash# sieve.sh# Решето Эратосфена# Очень старый алгоритм поиска простых чисел.# Этот сценарий выполняется во много раз медленнее# чем аналогичная программа на C.LOWER_LIMIT=1 # Начиная с 1.UPPER_LIMIT=1000 # До 1000.# (Вы можете


9.4. Пример

Из книги автора

9.4. Пример В архитектуре x86 есть инструкции, определяющие позицию старшего и младшего значащих битов в слове. Процессор выполняет эти инструкции очень быстро. С другой стороны, чтобы сделать то же самое на языке С, потребуется написать цикл с операциями побитового


Пример

Из книги автора

Пример В листинге 11.1[1] показана простая программа, вызывающая функцию gethostbyname для любого числа аргументов командной строки и выводящая всю возвращаемую информацию.Листинг 11.1. Вызов функции и вывод возвращаемой информации//names/hostent.c 1 #include "unp.h" 2 int 3 main(int argc, char **argv) 4 { 5  char


Пример

Из книги автора

Пример Сначала приведем пример с Ipv4:freebsd % traceroute www.unpbook.comtraceroute to www.unpbook.com (206.168.112.219): 30 hops max. 24 data bytes1 12.106.32.1 (12.106.32.1) 0.799 ms 0.719 ms 0.540 ms2 12.124.47.113 (12.124.47.113) 1.758 ms 1.760 ms 1.839 ms3 gbr2-p27.sffca.ip.att.net (12.123.195.38) 2.744 ms 2.575 ms 2.648 ms4 tbr2-p012701.sffca.ip.att.net (12.122.11.85) 3.770 ms 3.689 ms 3.848 ms5 gbr3-p50.dvmco.ip.att.net (12.122.2.66) 26.202 ms 26.242 ms


Пример

Из книги автора

Пример Сначала мы запустим нашу программу с аргументом командной строки -0 и убедимся, что сервер имен отвечает на приходящие дейтаграммы, не содержащие контрольной суммы. Мы также задаем флаг -v.macosx # udpcksum -i en1 -0 -v bridget.rudoff.com domaindevice = en1local net = 172.24.37.64. netmask = 255.255.255.224cmd = udp and src host