Запрос клиента RPC идентифицирует запускаемую программу и процедуру по ее номеру. Например, чтобы прочитать файл, запрос RPC обратится к программе 100003 (NFS) и процедуре 6 (чтение). На рис. 15.3 показано клиентское приложение, обращающееся к удаленной процедуре программы 100003.

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

Рис. 15.3. Доступ к удаленной процедуре из клиентского приложения

Удаленный запрос к процедуре (RPC) послан от клиента серверу в форматированном сообщении. RPC не заботится о том, какой транспортный протокол используется для пересылки сообщения. В мире TCP/IP RPC может работать поверх UDP или TCP, но можно использовать и другой транспорт.

Хотя обычно предполагается взаимодействие клиента с уникальным сервером, запросы RPC могут передаваться в многоадресных или широковещательных рассылках.

Наиболее известной программой RPC является NFS. Соответствующая команда mount (монтировать) позволяет клиенту подключить к своей локальной файловой системе удаленный каталог. Эта команда также является программой RPC. Существуют lock manager (диспетчер блокировки) и программа status, которые обеспечивают основу для изменения пользователем разделяемых файлов на сервере NFS.

Spray (распыление) — пример очень простой программы RPC. Клиент spray посылает серию сообщений к удаленной системе и получает ответ. Представленная ниже команда посылает 100 датаграмм хосту plum (эта программа позволяет получить статистику пересылки группы сообщений. — Прим. пер.):

> spray -с 100 plum

sending 100 packets of lnth 86 to plum …

in 10.1 seconds elapsed time,

29 packets (29.00%) dropped by plum

Sent: 9 packets/sec, 851 bytes/sec

Rcvd: 7 packets/sec, 604 bytes/sec

Программа rusers выясняет, кто зарегистрирован на хостах из указанного списка или на всех хостах локальной сети. Клиент rusers отправляет запрос RPC через широковещательные рассылки локальной сети. Ответы содержат имена хостов и список пользователей, зарегистрированных на каждом из них.

> rusers

Zonker.num.cs.yale.edu leonard jones harris

Mark.num.cs.yale.edu   davis   sherman

Duke.num.cs.yale.edu   burry   victor

. . .

Если служба основана на протоколе TCP, запросы и ответы будут доставляться надежно. TCP берет на себя обеспечение целостности доставляемых данных.

Если RPC базируется на UDP, то, в зависимости от требований конкретного приложения, клиент и сервер должны обеспечить собственный тайм-аут, повторную пересылку и стратегию выделения дублированных сообщений. Разработчик приложения может выбрать для клиента любую из следующих стратегий:

■ Если в пределах тайм-аута не будет получен ответ, послать сообщение об ошибке конечному пользователю, который и должен снова инициировать запрос к службе.

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

Если клиент повторно посылает запрос, разработчик должен реализовать на сервере стратегию обработки дубликатов сообщений. Сервер может:

■ Не фиксировать ранее выполненные операции. При поступлении запроса выполнить процедуру, даже если это был дубликат запроса. Отметим, что для некоторых процедур (например, чтение набора байт из файла) в этом нет ничего страшного. Конечно, клиент может и дальше получать двойные ответы, но может и блокировать их, отслеживая ранее выполненные транзакции.

■ Хранить копии ответов, которые были отправлены в течение нескольких последних минут. При поступлении запроса с тем же операционным идентификатором сервер уже знает, что процедура выполнена и на нее уже был послан ответ, следовательно, он мог бы отослать назад копию исходного ответа. Если сервер выполняет затребованную процедуру в момент поступления дубликата запроса — он должен отбросить повторный запрос.

Каждое приложение клиент/сервер может выбрать стратегию соединения, наиболее подходящую своим конкретным требованиям.