описание XDR - и поддерживаемых типов данных, и формата их передачи по проводам . Стандарт RFC 1833 [20] описывает протоколы привязки: RPCBIND и его предшественника, программу отображения портов (port mapper).

Одним из наиболее распространенных приложений, использующих Sun RPC, является сетевая файловая система Sun (NFS). Обычно она не создается стандартными средствами RPC, описанными в этой главе (rpcgen и библиотека времени выполнения). Вместо этого большинство подпрограмм библиотеки оптимизируются вручную и добавляются в ядро с целью ускорить их работу. Тем не менее большинство систем, поддерживающих NFS, также поддерживают и Sun RPC.

В середине 80-х Apollo соперничала с Sun за рынок рабочих станций и создала свой собственный пакет RPC, призванный вытеснить Sun RPC. Этот новый пакет назывался NCA (Network Computing Architecture - архитектура сетевых вычислений). Протоколом RPC являлся протокол NCA/RPC, а аналогом XDR была схема NDR (Network Data Representation - сетевое представление данных). Интерфейсы между клиентами и серверами определялись с помощью языка NIDL (Network Interface Definition Language - язык определений сетевого интерфейса) аналогично нашему файлу .х из листинга 16.1. Библиотека времени выполнения называлась NCK (Network Computing Kernel).

Фирма Apollo была куплена Hewlett-Packard в 1989, и NCA переросла в OSFs DCE (Distributed Computing Environment - среда распределенных вычислений), основной частью которой является RPC. Более подробно о DCE можно узнать по адресу http: www.camp.opengroup.org/tech/dce. Реализация пакета DCE RPC свободно доступна на ftp: gatekeeper.dec.com/pub/DEC/DCE. Этот каталог также содержит описание внутреннего устройства пакета DCE RPC на 171 странице. Существует много версий DCE для разных платформ.

ПРИМЕЧАНИЕ-

Sun RPC распространен шире, чем DCE RPC, возможно, благодаря свободно доступной реализации и включению в основную поставку большинства систем Unix. DCE RPC обычно поставляется в качестве дополнения (за дополнительную сумму). Переписывание свободно доступного кода под другие платформы пока еще не пошло полным ходом, хотя уже готовится версия для Linux. В этой главе мы опишем только средства Sun RPC. Все три пакета RPC - Courier, Sun и DCE - похожи друг на друга, поскольку основные концепции RPC остались неизменны.

Большинство поставщиков Unix предоставляют отдельную подробную документацию средств RPC. Например, документация Sun доступна по адресу http: docs.sun.com, и в первом томе Developer Collection можно найти 280-страничное руководство разработчика ONC-i- Developers Guides. Документация Digital Unix по адресу http: www.unix.digital.com/faqs/publications/pub page/V40D DOCS.HTM включает 116-стра-ничный документ под заголовком Programming with ONC RPC . Сам по себе RPC вызывает противоречивые мнения. Восемь статей на эту тему можно найти по адресу http: www.kohala.com/~rstevens/papers.others/rpc.comments.txt.

В этой главе мы предполагаем наличие TI-RPC (независимая от протокола версия RPC) для большинства примеров и говорим только о протоколах TCP и UDP, хотя TI-RPC поддерживает все протоколы, какие только могут быть на данном узле.

16.2. Многопоточность

Вспомните листинг 15.6, где мы продемонстрировали автоматическое управление потоками, осуществляемое библиотекой дверей. При этом сервер по умолчанию являлся параллельным. Покажем теперь, что средства Sun RPC по умолчанию делают сервер последовательным. Начнем с примера из предыдущего раздела и изменим только процедуру сервера. В листинге 16.4 приведен текст новой функции, выводящей идентификатор потока, делающей 5-секундную паузу, выводящей идентификатор еще раз и заверщающей работу.

Листинг 16.4. Процедура сервера с 5-секундной паузой

sunrpc/square2/server .с

1 #lnclude 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 printfC thread Xd started, arg = ld\n .

8 pr thread id(NULL). inp->argl);

9 sleep(5):

10 out.resl = inp->argl * inp->argl:

11 printf( thread ld done\n . pr thread id(NULL));

12 return(&out);

13 }

Запустим сервер, a после этого запустим три экземпляра программы-клиента:

Solaris % client localhost 22 & client localhost 33 & client localhost 44 &

[3] 25179 [4] 25180 [5] 25181

Solaris % result: 48примерно через 5 секунд после появления подсказки result: 1936 еще через 5 секунд result: 1089 еще через 5 секунд

Хотя этого нельзя сказать по выводимому тексту, перед появлением очередного результата проходит примерно 5 секунд. Если мы посмотрим на текст, выводимый сервером, то увидим, что клиенты обрабатываются последовательно: сначала полностью обрабатывается запрос первого клиента, затем второго и третьего:

Solaris % server

thread 1 started, arg = 22

thread 1 done

thread 1 started, arg = 44

thread 1 done

thread 1 started, arg = 33 thread 1 done

Один и тот же поток обслуживает все запросы клиентов. Сервер не является многопоточным по умолчанию.

ПРИМЕЧАНИЕ-

Серверы дверей в главе 15 работали не в фоновом режиме, а запускались из интерпретатора. Это давало нам возможность добавлять отладочные вызовы printf в процедуры сервера. Однако серверы Sun RPC по умолчанию являются демонами и выполняют действия так, как это описано в разделе 12.4 [24]. Это требует вызова syslog из процедуры сервера для вывода диагностической информации. Однако мы указали флаг -DDEBUG при компиляции нашего сервера, что эквивалентно определению

#define DEBUG

в заглушке сервера (файле square svc.c, создаваемом rpcgen). Это запрещает функции main становиться демоном и оставляет ее подключенной к терминалу, в котором она была запущена. Поэтому мы можем спокойно вызывать printf из процедуры сервера.

Возможность создания многопоточного сервера появилась в Solaris 2.4 и реализуется добавлением параметра -М в строку вызова rpcgen. Это делает код, создаваемый rpcgen, защищенным. Другой параметр, -А, позволяет автоматически создавать потоки по мере необходимости для обслуживания запросов клиентов. Мы включаем оба параметра при вызове rpcgen.

Однако для реализации многопоточности требуется внести изменения в текст клиента и сервера, чего мы могли ожидать, поскольку использовали тип static в листинге 16.3. Единственное изменение, которое нужно внести в файл square. х, - сменить номер версии с 1 на 2. В объявлениях аргументов процедуры и результатов ничего не изменится.

В листинге 16.5 приведен текст новой программы-клиента.

Листинг 16.5. Функция main клиента многопоточного сервера

sunrpc/square3/client.c

1 #include unpipc.h

2 #include square.h

3 int

4 mainCint argc. char **argv)

6 CLIENT *cl:

7 square in in:

8 square out out:

9 if (argc != 3)

10 err quit( usage: client <hostname> <integer-value> ):

11 cl = Clnt create(argv[l]. SQUARE PROG. SQUAREJERS. tcp ):

12 in.argl = atol(argv[2]):

13 if (squareproc 2(&in. &out. cl) != RPC SUCCESS)

14 err quit( *s . clnt sperror(cl. argv[l]));

15 printf( result: *ld\n , out.resl):

16 exitCO):

17 }

Объявление переменной для помещения результата

Мы объявляем переменную типа square out, а не указатель на нее.