Удаленный вызов процедур (remote procedure call, RPC) – это технология взаимодействия прикладных программ, выполняющихся на разных узлах, разработанная корпорацией Sun Microsystems (см. RFC 1831). RPC дает возможность программам вызывать процедуры, расположенные на других узлах, (или в других адресных пространствах) точно так же, как и локальные процедуры.
В случае локального вызова процедуры, вызывающая сторона размещает передаваемые параметры в некотором известном месте (например, в регистрах или стеке) а затем передает управление этой процедуре. После того, как процедура выполнена, вызывающая сторона вновь получает управление, извлекает возвращаемые параметры из регистров или стека и продолжает свою работу.
Удаленный вызов процедуры для вызывающей стороны выглядит очень похоже. Поток управления проходит через два процесса: вызывающий (клиентский) и обслуживающий (серверный). Клиентский процесс отправляет сообщение-запрос серверному и приостанавливает свою работу до получения сообщения-ответа. Сообщение-запрос содержит передаваемые параметры, а сообщение-ответ – возвращаемые параметры. После того, как сообщение-ответ получено, клиентский процесс извлекает из него данные и продолжает свою работу. Серверный процесс в основном ожидает поступления сообщений-запросов. Когда запрос поступил, из него извлекаются значения параметров, выполняется требуемая процедура, формируется и отправляется сообщение-ответ, и серверный процесс опять переходит в состояние ожидания.
В этой модели клиентский и серверный процессы выполняются синхронно – в каждый момент времени выполняется только один из них. Тем не менее, протокол RPC допускает и асинхронное выполнение, например, клиентский процесс может выполнять некоторую полезную работу во время ожидания ответа.
Наряду со значительным подобием, имеется ряд серьезных отличий между удаленным и локальным вызовом процедур. Во-первых, обработка ошибок: необходимо обрабатывать отказы сети и удаленного сервера. Во-вторых, глобальные переменные и побочные эффекты: поскольку сервер не имеет доступа к адресному пространству клиента, нельзя передавать в процедуру данные через глобальные переменные, а также возвращать данные путем побочных эффектов. В-третьих, производительность: удаленные вызовы процедур выполняются на несколько порядков дольше, чем локальные. В-четвертых, контроль доступа: поскольку удаленные вызовы могут производиться через небезопасные сети, серверу необходимо проверять аутентичность клиента, и наоборот.
Протокол RPC определяет только структуру сообщений и может быть реализован поверх любого транспортного протокола. Надежность RPC зависит от надежности транспортного протокола: при работе через TCP выполняется управление потоком, квитирование и повторная передача потерянных пакетов, при работе через UDP, программа, пользующаяся RPC, должна самостоятельно обеспечивать надежность. При этом возникает проблема единственного выполнения удаленной процедуры: если по тем или иным причинам от сервера не пришло сообщение-ответ, то, по истечении таймаута, клиент должен повторно передать сообщение-запрос. Возможна ситуация, при которой сервер получит и выполнит оба запроса, что является нарушением логики работы программы. Для защиты от подобных проблем может использоваться, например, механизм нумерации запросов: разные запросы несут в себе разные номера, а повторные запросы – номера исходных запросов. Сервер должен хранить список выполненных номеров запросов и не выполнять запросы повторно.
Спецификация RPC не определяет конкретную процедуру привязки (binding) клиентов к серверам. Возможным способам привязки посвящен отдельный документ – RFC 1833. Конкретная служба (service) RPC идентифицируется номером программы RPC, номером ее версии и транспортным адресом, по которому к ней можно обратиться. Транспортный адрес состоит из сетевого адреса (например, IP-адреса) и селектора транспорта (например, номера TCP-порта). Для успешного обращения к службе, клиент должен знать все перечисленные идентификаторы. При этом номер программы RPC и номер ее версии обычно жестко прописываются в программе клиента, а сетевой адрес либо передается программе при запуске, либо определяется динамически путем обращения к службе имен (например, DNS). Селектор транспорта обычно определяется динамически при запуске экземпляра сервера. Сервер динамически выделяет транспортный адрес и сообщает его некоторой известной (расположенной по заранее заданному селектору транспорта) службе поиска (lookup service). Клиенты, когда им нужно определить транспортный адрес той или иной службы, обращаются к службе поиска.
Необходимость в использовании отдельной службы поиска связана с тем, что многие транспортные протоколы не могут предоставить большое количество заранее известных селекторов, в то время, как потенциальное количество служб очень велико. Использование службы поиска позволяет занять единственный заранее известный селектор, а селекторы остальных служб назначать динамически.
RFC 1833 определяет три типа служб поиска: Port Mapper . Все они используют общий номер программы RPC (1000000) и порты TCP/111 и UDP/111.
Стандарты распределенных вычислений Open Source Foundation (OSF) Distributed Computing Environment (DCE) используют RPC как основной механизм выполнения удаленных процедур. В пользу RPC говорят его простота, прозрачность и производительность. То, что модель вызова RPC максимально приближена к модели вызова локальных процедур, позволяет сократить время обучения разработчиков.
СПИСОК ЛИТЕРАТУРЫ
1. Компьютерные сети. Принципы, технологии, протоколы. / В.Г.Олифер, Н.А.Олифер. — СПб: Издательство “Питер”, 1999. — 672 с.: ил.
2. Высокопроизводительные сети. Энциклопедия пользователя: Пер. с англ./Марк А. Спортак и др. — К.: Издательство “ДиаСофт”, 1998. – 432с.
3. Кульгин М. Технологии корпоративных сетей. Энциклопедия— СПб: Издательство “Питер”, 2000. — 704 с.: ил.
4. Гук М. Аппаратные средства локальных сетей. Энциклопедия – СПб.: Издательство “Питер”, 2000. –576с.:ил.
5. Компьютерные сети+. Учебный курс (MSCE 70-058)/Пер. с англ. — М.: “Русская редакция”, 2000. — 552с.
6. Сети Windows NT 4.0: Пер. с англ. /Джон Д. Рули и др. — К.: Издательская группа BHV, 1997. — 800с.
7. Мельников Д.А. Информационные процессы в компьютерных сетях. Протоколы, стандарты, интерфейсы, модели… – М: КУДИЦ-ОБРАЗ, 1999. – 256с., ил.
8. Якубайтис Э.А. Информационные сети и системы.Справочная книга. — М.: Финансы и статистика, 1996. — 368c.: ил.
9. Ратынский М.В. Основы сотовой связи/ Под ред. Д.Б. Зимина. – 2-е изд., перераб. и доп. – М.:Радио и связь, 2000. – 248с.:ил.
10. Семенов А.Б., Стрижаков С.К., Сунчелей И.Р. Структурированные кабельные системы, 3-е изд. – М.: “Компьютер-Пресс”, 2001. – 608с.