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

count=read (fd,buf,nbytes); где fd - целое число, buf - массив символов, nbytes - целое число.

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

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

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

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

Рис. 3.1.  а) Стек к выполнению вызова read;
б) Стек во время выполнения процедуры;
в) Стек по возвращении в  программу

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

RPC достигает прозрачности таким путем. Когда что вызывается процедура действительно есть отдаленной, в библиотеку помещается вместо локальной процедуры другая версия процедуры, называемая клиентским стабом (stub - заглушка). Подобно оригинальной процедуре, стаб визивається с использованием последовательности , которая вызывает , (как на рисунке 3.1), так же происходит прерывания при обращении к ядру. Только в отличие от оригинальной процедуры он не помещает параметры в регистры и не спрашивает у ядра дани, вместо этого он формирует сообщение для отправления ядру отдаленной машины.

 

Возможно стоит прочитать: