Remote Procedure Call

Remote Procedure Call

Удалённый вызов процедур (или Вызов удалённых процедур) (от англ. Remote Procedure Call (RPC)) — класс технологий, позволяющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве (как правило, на удалённых компьютерах). Обычно, реализация RPC технологии включает в себя два компонента: сетевой протокол для обмена в режиме клиент-сервер и язык сериализации объектов (или структур, для необъектных RPC). Различные реализации RPC имеют очень отличающуюся друг от друга архитектуру и разнятся в своих возможностях: одни реализуют архитектуру SOA, другие CORBA или DCOM. На транспортном уровне RPC используют в основном протоколы TCP и UDP, однако, некоторые построены на основе HTTP (что нарушает архитектуру ISO/OSI, так как HTTP изначально не транспортный протокол).

Реализации

Существуют множество технологий, обеспечивающих RPC:

• Sun RPC (бинарный протокол на базе TCP и UDP и XDR) RFC-1831 второе название ONC RPC RFC-1833
• .Net Remoting (бинарный протокол на базе TCP, UDP, HTTP)
• SOAP — Simple Object Access Protocol (текстовый протокол на базе HTTP) см. спецификацию: RFC-4227
• XML RPC (текстовый протокол на базе HTTP) см. спецификацию: RFC-3529
• Java RMI — Java Remote Method Invocation — см. спецификацию: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
• JSON-RPC JavaScript Object Notation Remote Procedure Calls (текстовый протокол на базе HTTP) см. спецификацию: RFC-4627
• DCE/RPC — Distributed Computing Environment / Remote Procedure Calls (бинарный протокол на базе различных транспортных протоколов, в том числе TCP/IP и Named Pipes из протокола SMB/CIFS)
• DCOM — Distributed Component Object Model известный как MSRPC Microsoft Remote Procedure Call или «Network OLE» (объектно-ориентированное расширение DCE RPC, позволяющее передавать ссылки на объекты и вызывать методы объектов через таковые ссылки)
• Routix.RPC
• ZeroC ICE

Принцип

Идея вызова удалённых процедур (Remote Procedure Call — RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удалённого вызова процедур предназначены для облегчения организации распределённых вычислений и создания распределенных клиент-серверных информационных систем. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удалёнными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.

Характерными чертами вызова локальных процедур являются:

• Асимметричность, то есть одна из взаимодействующих сторон является инициатором;
• Синхронность, то есть выполнение вызывающей процедуры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры.

Реализация удалённых вызовов существенно сложнее реализации вызовов локальных процедур. Можно обозначить следующие проблемы и задачи, которые необходимо решить при реализации RPC:

• Так как вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины находятся под управлением различных операционных систем или имеют различную архитектуру (например, используется прямой или обратный порядок байтов). Так как RPC не может рассчитывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Для копирования параметров процедуры и результата выполнения через сеть выполняется их сериализация.
• В отличие от локального вызова удалённый вызов процедур обязательно использует транспортный уровень сетевой архитектуры (например TCP), однако это остается скрытым от разработчика.
• Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса. Но в реализации RPC участвуют как минимум два процесса — по одному в каждой машине. В случае, если один из них аварийно завершится, могут возникнуть следующие ситуации: при аварии вызывающей процедуры удалённо вызванные процедуры станут «осиротевшими», а при аварийном завершении удалённых процедур станут «обездоленными родителями» вызывающие процедуры, которые будут безрезультатно ожидать ответа от удалённых процедур.
• Существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках. Таким образом имеется проблема совместимости, до сих пор не решённая ни с помощью введения одного общепринятого стандарта, ни с помощью реализации нескольких конкурирующих стандартов на всех архитектурах и во всех языках.

Подсистемы

• Транспортная подсистема

— управление исходящими и входящими соединениями. — поддержка понятия «граница сообщения» для транспортных протоколов, не поддерживающих его непосредственно (TCP). — поддержка гарантированной доставки для транспортных протоколов, не поддерживающих ее непосредственно (UDP).

• Пул потоков (только для вызываемой стороны). Предоставляет контекст выполнения для вызванного по сети кода.

• Маршалинг (также называется «сериализация»). Упаковка параметров вызовов в поток байт стандартным образом, не зависящим от архитектуры (в частности, от порядка байт в слове). В частности, ему могут подвергаться массивы, строки и структуры, на которые указывают параметры-указатели.

• Шифрование пакетов и наложение на них цифровой подписи.

• Аутентификация и авторизация. Передача по сети информации, идентифицирующей субъект, осуществляющий вызов.

В некоторых реализациях RPC (.NET Remoting) границы подсистем являются открытыми полиморфными интерфейсами, и возможно написать свою реализацию почти всех перечисленных подсистем. В других реализациях (DCE RPC в Windows) это не так.

См. также

• Network File System

Вызов удаленных процедур (RPC) Концепция удаленного вызова процедур

Идея вызова удаленных процедур (Remote Procedure Call — RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удаленного вызова процедур предназначены для облегчения организации распределенных вычислений. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удаленными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.

Характерными чертами вызова локальных процедур являются:

• Асимметричность, то есть одна из взаимодействующих сторон является инициатором;
• Синхронность, то есть выполнение вызывающей процедуры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры.

Реализация удаленных вызовов существенно сложнее реализации вызовов локальных процедур. Начнем с того, что поскольку вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины не идентичны. Так как RPC не может рассчитывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Следующим отличием RPC от локального вызова является то, что он обязательно использует нижележащую систему связи, однако это не должно быть явно видно ни в определении процедур, ни в самих процедурах. Удаленность вносит дополнительные проблемы. Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса. Но в реализации RPC участвуют как минимум два процесса — по одному в каждой машине. В случае, если один из них аварийно завершится, могут возникнуть следующие ситуации: при аварии вызывающей процедуры удаленно вызванные процедуры станут «осиротевшими», а при аварийном завершении удаленных процедур станут «обездоленными родителями» вызывающие процедуры, которые будут безрезультатно ожидать ответа от удаленных процедур.

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

Эти и некоторые другие проблемы решает широко распространенная технология RPC, лежащая в основе многих распределенных операционных систем. Базовые операции RPC

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

count=read (fd, buf, nbytes);

где fd — целое число, buf — массив символов, nbytes — целое число.

Чтобы осуществить вызов, вызывающая процедура заталкивает параметры в стек в обратном порядке (рисунок 3.1). После того, как вызов read выполнен, он помещает возвращаемое значение в регистр, перемещает адрес возврата и возвращает управление вызывающей процедуре, которая выбирает параметры из стека, возвращая его в исходное состояние. Заметим, что в языке С параметры могут вызываться или по ссылке (by name), или по значению (by value). По отношению к вызываемой процедуре параметры-значения являются инициализируемыми локальными переменными. Вызываемая процедура может изменить их, и это не повлияет на значение оригиналов этих переменных в вызывающей процедуре.

Если в вызываемую процедуру передается указатель на переменную, то изменение значения этой переменной вызываемой процедурой влечет изменение значения этой переменной и для вызывающей процедуры. Этот факт весьма существенен для RPC.

Существует также другой механизм передачи параметров, который не используется в языке С. Он называется call-by-copy/restore и состоит в необходимости копирования вызывающей программой переменных в стек в виде значений, а затем копирования назад после выполнения вызова поверх оригинальных значений вызывающей процедуры.

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

Применение

Значительная часть инструментов удаленного управления операционной системой Windows (Event Viewer, Server Manager, управление печатью, списками пользователей) использует DCE RPC как средство общения по сети между управляемой службой и управляющим приложением пользовательского интерфейса. Поддержка DCE RPC присутствовала в Windows NT с самой первой версии 3.1. Клиенты DCE RPC поддерживались и в облегченной линии операционных системы Windows 3.x/95/98/Me.

Системные библиотеки Windows, предоставляющие возможности такого управления и служашие базовым уровнем для управляюших приложений пользовательского интерфейса (netapi32.dll и отчасти advapi32.dll), на деле содержат в себе клиентский код интерфейсов DCE RPC, осуществляющих это управление.

Это архитектурное решение было предметом активной критики в адрес Microsoft. Универсальные процедуры маршаллинга, присутствующие в DCE RPC, очень сложны и имеют огромный потенциал наличия дефектов, эксплуатируемых в сети путем посылки умышленно искаженного пакета DCE RPC. Значительная часть дефектов безопасности Windows, обнаруженных с конца 90-х до середины 2000-х годов, представляла собой именно ошибки в коде маршаллинга DCE RPC.

Помимо DCE RPC, в Windows активно применяется технология DCOM. Так, например, она используется как средство общения между инструментами управления веб-сервером IIS и собственно управляемым сервером. Полнофункциональный интерфейс общения с почтовой системой MS Exchange Server — MAPI — также основан на DCOM.

Ссылки

Более полно на unix.org.ua