Сервер rpc что это

Что такое сервер RPC и как исправить ошибку «сервер RPC недоступен»

На компьютерах достаточно часто возникают разного рода ошибки. Проблема, связанная с недоступностью RPC сервера не исключение. В основном она появляется при обновлении драйверов, но бывают случаи, когда ошибки «сервер RPC недоступен» возникает и при запуске операционной системы (ОС) Windows 7, 8, 10, а также XP или Server 2003, 2008, 2012. Также ошибка может возникать при печати или установке принтера.

Принцип работы RPC

RPC — это просто метод для передачи информации между различными процессами или клиентом (техника, что начинает связь) и сервером (устройством, которое пытается связаться с клиентом) в рамках системы или сети. Очень много компонентов ОС Виндовс использует этот способ “общения”. RPC в качестве точек связи использует разные порты чтобы связывать системы между собой.

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

Что за ошибка и почему возникает

Проблема появляется, когда связь между системами нарушается, так как сервер не может отправить адрес порта точке связи. Появиться она может по следующим причинам:

1. Работа службы PRC была приостановлена или вовсе не запущена.
2. Наименование сервера может быт по ошибке связано с не тем адресом. Получается, что клиент пытается связаться с не тем “собеседником”. Также бывает, что связь пытаются наладить через порт, который не используется или имя сервера просто не распознается системой.
3. Трафик был заблокирован брандмауэром или другим приложением для обеспечения безопасности.
4. Есть проблемы с сетью, которые мешают связи между клиентом и сервером.
5. Недавно были установлены драйвера на принтер, МФУ, звуковую карту и т.д.

Поиск причины

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

1. Открыть меню “Пуск”.
2. Перейти в панель управления.
3. Зайти на вкладку администрирования и открыть окно просмотра событий.
4. Поискать в журнале сообщение об ошибке (обычно помечено красным крестом). Как правило, если сделать все действия сразу после первого появления ошибки, то она будет в первой строке. В ней будет находится расшифровка и устройство, которое вызывает неполадки.
5. Найти описание проблемы в интернете, а также способы решения.

Общие способы решения

Есть универсальные способы, которые помогают быстро устранить проблему с сервером РПЦ. На их выполнения потребуется немного времени, но результат не заставит ждать.

Перезапуск службы RPC

Для начала рекомендуется просто перезапустить службу. Возможно, что неполадки в работе при этом будут устранены. Сделать это можно следующим образом:

1. Открыть диспетчер задач.
2. Перейти на вкладку “Службы”.
3. Найти необходимое. Для удобства рекомендуется выстроить элементы по алфавиту, что можно сделать одним кликом на столбик “Имена”.
4. Кликнуть правой кнопкой мышки по службе и выбрать пункт “Перезапустить”.

После этого процесс прекратит работу и тут же запустится.

Отключение брандмауэра

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

Сделать это можно через панель управления, в разделе системы и безопасности.

Проверка времени компьютера

Если ошибка появилась в момент запуска какой-то программы или ее остановки, то вероятно все связанно с синхронизацией времени. Решить эту проблемы можно таким образом:

1. Зайти в диспетчер задач. Перейти в последнюю вкладку. Внизу окна будет ссылка “Открыть Службы”.
2. Откроется окно, в котором требуется найти службу времени.
3. Если она была приостановлена, то ее требуется запустить. При активной службе рекомендуется выполнить перезапуск.

Устранение неполадок системы

В случае, если ошибка «сервер РПЦ недоступен» появилась при запуске ОС, необходимо сделать следующее:

1. Перезагрузить компьютер.
2. Нажать кнопку F8 при загрузке.
3. Выбрать пункт «Устранение неполадок компьютера».
4. Дождаться окончания процесса.

Проверка на вирусы

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

При обнаружении вируса, его необходимо удалить.

Ошибка с кодом 1722

Ошибка «Сервер RPC недоступен» наиболее часто встречается при проблемах с отсутствием звука. Решается следующим образом:

1. Открыть диспетчер задач.
2. Перейти на вкладку “Службы”.
3. Внизу окна будет ссылка, кликнуть на нее для открытия всех служб.
4. Найти «Средство построения точек аудио».
5. Сделать тип запуска “Вручную” и сохранить изменения.

Ошибка в FineReader

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

1. Зайти в “Службы” через диспетчер задач или панель управления.
2. Оставить службу FineReader.
3. Перезагрузить компьютер и запустить приостановленный процесс.

Проблемы с Bitlocker

Битлокер защищает информацию на носителях информации, например, флешках. И иногда работа этой технологии может вызывать ошибки с сервером RPC. Исправить это можно отключением технологии или просто обновлением. Это можно сделать через центр обновлений Виндовс или скачав необходимые файлы с интернета.

Что такое удалённые вызовы процедур?

Удалённый вызов процедур (RPC) — это подпрограмма в распределённых вычислениях. Реализация RPC напоминает реализацию локальных вызовов, но обычно они не идентичны. Как правило, RPC предполагает передачу параметра, имени объекта, имени функции на удалённые серверы, откуда затем на сторону клиента возвращаются обработанные результаты (запрос-ответ). RPC осуществляется с использованием протоколов TCP, UDP или HTTP.

В Golang существуют три типа реализаций, а именно:

• net/rpc
• net/rpc/jsonrpc
• gRPC

net/rpc

Официальная документация Golang в пакете net/rpc использует encoding/gob в качестве методов кодирования или декодирования, поддерживающих протоколы TCP или HTTP. Но gob используется только в Golang, поэтому поддерживает лишь те серверы и взаимодействия на стороне клиента, которые написаны на Golang. Вот пример net/rpc на стороне сервера:

Примечательно, что функция GetLine добавляется к Listener . Она вернёт тип error , ожидая строку с какими-то данными и ответ со стороны клиента. Кроме того, функция наверняка является указателем, поэтому объявлена структура Reply для хранения соответствующих данных Data .

В функции main мы используем сначала net.ResolveTCPAddr , а затем net.ListenTCP для установки TCP-соединения, слушая порт 12345 со всех адресов. И, наконец, используем rpc.Register для регистрации соединения, которое должно прослушиваться, принимая все запросы с указанных TCP-соединений.

Пример net/rpc на стороне клиента:

На стороне клиента для установления соединения с сервером и портами будет использован rpc.Dial , а это бесконечный цикл for с функцией ReadLine , которая принимает данные от портов получения. В случае возникновения обрывов на линии активируется client.Call и запускается функция GetLine . Благодаря этому процессу, reply будет сохраняться в базе данных, а мы сможем вызвать его с помощью reply.Data (по сути, это означает: что мы вводим, то и получаем на выходе). Попробуем запустить этот код:

net/rpc/jsonrpc

net/rpc поддерживает только Golang, поэтому библиотека Go использует net/rpc/jsonrpc для поддержки RPC в платформах на любом языке программирования. Для реализации аналогичного приведённому выше приложения надо лишь поменять rpc.Accept в функции main() .

Вот пример net/rpc/jsonrpc на стороне сервера:

Теперь пример net/rpc/jsonrpc на стороне клиента:

json-rpc основан на протоколе TCP и на настоящий момент не поддерживает метод HTTP. Результаты будут те же, что и в предыдущем примере:

Объект JSON в запросе имеет две похожие структуры: clientRequest и serverRequest .

Мы могли бы использовать такую структуру для отправки сообщения и в других языках программирования. Попробуем в командной строке:

Тот факт, что jsonRPC может поддерживать другие языки, но не поддерживает метод HTTP, ограничивает его применение. Поэтому в эксплуатационной среде обычно используют Thrift или gRPC .

gRPC — это популярная, высокопроизводительная и общедоступная RPC-платформа, созданная в Google. Она предназначена главным образом для параллельного выполнения задач современных приложений на основе стандартного протокола HTTP/2 и поддерживает такие языки, как Python, Golang и Java. Разработана в протоколе сериализации Protobuf.

Protobuf

Protobuf (сокращение от Protocol Buffers) — это всеязычный, платформенно-независимый механизм для сериализации структурированных данных в формате, похожем на XML и JSON. Легковесный и быстрый, он очень подходит для хранения данных или обмена ими в сети RPC. Первым делом устанавливаем Protobuf:

Теперь пишем образец данных на основе proto3:

Запрос и ответ имеют здесь лишь по одной строчке с данными data . Сервис Simple имеет только один метод GetLine с входным SimpleRequest и возвращает SimpleResponse .

Таким вот образом создаём файл simple.pb.go в каталоге src/simple для поддержки gRPC.

Как использовать gRPC

Сначала устанавливаем gRPC:

Затем импортируем src/simple в код:

Здесь pb "./src/simple" импортируется пакетом. Заметим, что в названии добавляется pb .

Первым параметром функции GetLine идёт context.Context . Второй параметр — *pb.Simple-Request (запрос определён в файле .proto ). Эта функция вернёт (*pb.SimpleResponse, error) , где pb.SimpleResponse соответствует определению в файле .proto . С другой стороны, SimpleRequest и SimpleResponse должны обозначаться большими буквами, несмотря на то, что в файле .proto они в верблюжьем регистре.

На стороне клиента:

Сначала устанавливаем соединение с помощью grpc.Dial("localhost:12345", rpc.WithInsecure()) . Затем используем pb.NewSimpleClient для создания экземпляра simpleClient в формате XXXClient . (XXX определено раннее в файле .proto для значения simple в service Simple ).

Для использования RPC вводится следующая команда:

GetLine определяется в файле .proto ( rpc GetLine(SimpleRequest) возвращает (SimpleResponse) ). Первый параметр — context.Background() . Вторым параметром идёт request . Так как строка имеет тип []byte , её надо перевести в string . Ответ reply представляет собой экземпляр SimpleReponse , который можно получить из reply.Data :

Заключение

Надеюсь, что после прочтения этой статьи у вас отложилось в голове какое-то представление о RPC (удалённом вызове процедур) и трёх типах реализации в Golang. В помощь будут и примеры кода для net/rpc , net/jsonrpc и grpc . Остаётся только написать собственный код!

Сервер RPC недоступен — как исправить ошибку?

При подключении к удаленному компьютеру или виртуальной машине, некоторым сетевым устройствам, а также при установке и работе прикладных программ, использующих клиент-серверную архитектуру (в том числе на единственном локальном компьютере) пользователь может получить сообщение об ошибке «Сервер RPC недоступен» (RPC server is unavailable).

В этой инструкции подробно о способах исправить ошибку «Сервер RPC недоступен» в Windows 11 и Windows 10 с фокусом прежде всего на домашнего пользователя, но многие решения универсальны и подойдут для других сценариев.

Службы RPC и связанные с ними службы

Первое что следует проверить при ошибке — работу и тип запуска служб, необходимых для правильной работы протокола удаленного вызова процедур RPC. Некоторые из представленного списка — необходимые, некоторые — опциональны, но в некоторых случаях также способны приводить к ошибке «Сервер RPC недоступен».

1. Откройте «Службы Windows», для этого можно нажать клавиши Win+R на клавиатуре (или нажать правой кнопкой мыши по кнопке «Пуск» и выбрать пункт «Выполнить», ввести services.msc и нажать Enter.
2. Найдите службы из списка, который приведен ниже после 5-го пункта, убедитесь, что они выполняются, а тип запуска задан верно.
3. Если это не так, дважды нажмите мышью по такой службе, измените тип запуска службы и примените настройки.
4. Если ошибка RPC возникает при подключении к удаленному компьютеру или виртуальной машине, убедитесь, что и на нем службы настроены правильно.
5. После изменения параметров запуска служб, перезагрузите компьютер.

Список служб в формате: Название службы на русском языке (название на английском) — тип запуска по умолчанию:

• Инструментарий управления Windows (Windows Management Instrumentation) — Автоматически
• Локатор удаленного вызова процедур RPC (Remote Procedure Call RPC Locator) — Вручную, можно попробовать поставить «Автоматически».
• Модуль запуска процессов DCOM-сервера (DCOM Server Process Launcher) — Автоматически
• Служба времени Windows (Windows Time service) — Автоматически
• Сопоставитель конечных точек RPC (RPC Endpoint Mapper) — Автоматически
• Удаленный вызов процедур RPC (Remote Procedure Call RPC) — Автоматически

Если для отдельных служб тип запуска выставлен неверно, при этом изменить его в интерфейсе управления службами невозможно, можно использовать редактор реестра.

Для этого: запустите редактор реестра (Win+R — regedit) и перейдите к разделу реестра

В этом разделе реестра измените значение параметра Start на 2 (дважды нажав по параметру и задав новое значение) в следующих подразделах:

• DcomLaunch
• RpcEptMapper
• RpcLocator
• RpcSs
• W32Time
• Winmgmt

Часть параметров могут не изменяться и в реестре, в этой ситуации может помочь изменение прав доступа к разделам реестра.

В справке на официальном сайте Майкрософт приводится ещё две службы, которые могут вызывать ошибку «Сервер RPC недоступен» при входе в Windows :

• Модуль поддержки NetBIOS через TCP/IP (TCP/IP NetBIOS Helper)
• Удаленный реестр (Remote registry)

Протокол IPv6 и общий доступ к файлам и принтерам

Отключенная поддержка IP версии 6 и «Общий доступ к файлами и принтерам для сетей Майкрософт» также могут приводить к сбоям доступа к серверу RPC. Проверьте, включены ли они и, если нет — включите:

1. Нажмите клавиши Win+R на клавиатуре, введите ncpa.cpl и нажмите Enter.
2. Нажмите правой кнопкой мыши по сетевому подключению и откройте его свойства.
3. Отметьте пункты «Общий доступ к файлами и принтерам для сетей Майкрософт» и «IP версии 6» и примените настройки.

Брандмауэр Windows

В части настроек брандмауэра Windows при ошибке доступа к серверу RPC, в зависимости от сценария проблемы возможны разные решения.

1. В Панели управления (открыть её можно, используя поиск в панели задач) откройте пункт «Брандмауэр Защитника Windows»
2. В панели слева нажмите «Разрешение взаимодействия с приложениями или компонентами брандмауэра Защитника Windows».
3. Нажмите кнопку «Изменить параметры» и разрешите взаимодействие для «Удаленный помощник».

Если предыдущий метод не помог, попробуйте:

• Открыть порт 135 на локальной и удаленной машине. Подробнее: Как открыть порты в Windows. (возможно, временно, чтобы выяснить, является ли его работа причиной ошибки)

Дополнительные методы решения проблемы

Если предыдущие варианты не помогли, при этом вы уверены, что на сервере (при удаленном подключении к собственным ресурсам или серверам, которые использует ваше ПО) проблем нет, попробуйте следующие варианты решения проблемы:

• Используйте команды в командной строке, запущенной от имени Администратора
• Если используется профиль сети «Общественная» (Общедоступная), попробуйте переключить её на «Частная» — Как изменить тип сети в Windows 11 и в Windows 10.
• Если вам известен IP-адрес сервера, к которому выполняется подключение, проверьте, доступен ли порт 135 на нем с помощью команды PowerShell (заменив IP-адрес на нужный), при успехе в пункте TcpTestSucceeded должен быть статус «True»
• При наличии сторонних антивирусов или файрволлов, попробуйте отключить их, или отключить только функции защиты в сети.
• При использовании VPN-сервисов, попробуйте отключить их.
• Попробуйте отключить протокол teredo для IPv6 с помощью командыЧтобы в дальнейшем включить его обратно используйте команду
• Учитывайте: если ошибка «Сервер RPC недоступен» возникает при запуске, установке или работе какого-либо прикладного ПО, полученного и модифицированного неофициальными методами, причина может быть в целенаправленной блокировке доступа к серверам лицензирования или иным.
• Проверьте компьютер на наличие вирусов и вредоносных программ, блокировок доступа к сайтам в файле hosts.

Remote Procedure Call

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

Содержание

Реализации

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

(бинарный протокол на базе TCP и UDP и XDR) RFC-1831 второе название ONC RPCRFC-1833 (бинарный протокол на базе TCP, UDP, HTTP)  — Simple Object Access Protocol (текстовый протокол на базе HTTP) см. спецификацию: RFC-4227 (текстовый протокол на базе HTTP) см. спецификацию: RFC-3529  — 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)  — Distributed Component Object Model известный как MSRPC Microsoft Remote Procedure Call или «Network OLE» (объектно-ориентированное расширение DCE RPC, позволяющее передавать ссылки на объекты и вызывать методы объектов через таковые ссылки)

Принцип

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

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

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

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

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

Подсистемы

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

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

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

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

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

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

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

См. также

Вызов удаленных процедур (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.