Протокол rpc что это
Как работает RPC
Средства удаленного вызова процедур делают его пользователям, как будто клиент напрямую вызывает процедуру, расположенную в удаленной серверной программе. У каждого клиента и сервера есть свои адресные пространства; то есть каждый из них имеет свой собственный ресурс памяти, выделенный для данных, используемых процедурой. На следующем рисунке показана архитектура RPC.
Как показано на рисунке, клиентское приложение вызывает локальную процедуру-заглушку вместо фактического кода, реализующего процедуру. Заглушки компилируются и связываются с клиентским приложением. Вместо того, чтобы содержать фактический код, реализующий удаленную процедуру, код заглушки клиента:
Для вызова удаленной процедуры сервер выполняет следующие действия.
Затем выполняется удаленная процедура, которая, возможно, создает выходные параметры и возвращаемое значение. После завершения удаленной процедуры аналогичная последовательность действий возвращает клиенту данные.
Клиент завершает процесс, принимая данные по сети и возвращая их вызывающей функции.
Библиотеки времени выполнения предоставляются в двух частях: библиотеку импорта, которая связана с приложением и библиотекой времени выполнения RPC, которая реализована как библиотека динамической компоновки (DLL).
Серверное приложение содержит вызовы функций библиотеки времени выполнения сервера, которые регистрируют интерфейс сервера и позволяют серверу принимать удаленные вызовы процедур. Серверное приложение также содержит удаленные процедуры, связанные с конкретным приложением, которые вызываются клиентскими приложениями.
RPC, Messaging, REST: Терминология
Цель данной статьи — обсудить терминологию. Статья — не о том, как и для чего, а только исключительно об использовании терминологии. Статья отражает мнение автора и не претендует на научность.
Вступление
Если вы работаете в области программирования распределенных систем или в интеграции систем, то большая часть изложенного здесь вам не в новинку.
Проблема возникает, когда встречаются люди, использующие разные технологии, и когда эти люди начинают технические разговоры. При этом часто возникает взаимное недопонимание, обусловленное терминологией. Я здесь попытаюсь свести воедино терминологии, используемые в разных контекстах.
Терминология
Четкой терминологии и классификации в этой области нет. Используемая ниже терминология является отражением модели, сложившейся у автора, то есть она строго субъективна. Любая критика и любые обсуждения приветствуются.
Я разделил терминологию на три области: RPC (Remote Procedure Call), Messaging и REST. Эти области имеют под собою исторические корни.
RPC технологии — наиболее старые технологии. Наиболее яркие представители RPC, это — CORBA и DCOM.
В те времена в основном приходилось связывать системы в быстрых и относительно надежных локальных сетях. Главная идея RPC была в том, чтобы сделать вызов удаленных систем очень похожим на вызов функций внутри программы. Вся механика удаленных вызовов пряталась от программиста. По крайней мере её пытались спрятать. Программисты во многих случаях вынуждены были работать на более глубоком уровне, где появлялись термины маршалинг (marshalling) и unmarshalling (как это по-русски?), что по сути означало сериализацию. Обычные вызовы функций внутри процессов обрабатывались на вызывающей стороне в Proxy, а на стороне системы, выполняющей функцию, в Dispatcher. В идеале ни вызывающая система, ни обрабатывающая система не занимались тонкостями передачи данных между системами. Все эти тонкости сосредотачивались в связке Proxy — Dispatcher, код которых генерировался автоматически.
Поэтому вы не заметите, не должны заметить, никакой разницы между вызовом локальной функции и вызовом удаленной функции.
Сейчас наблюдается своеобразный ренесанс RPC, наиболее яркие представители которого: Google ProtoBuf, Thrift, Avro.
Messaging
С течением времени выяснилось, что попытка оградить программиста от того, что вызываемая функция все же отличается от локальной, не привела к желаемому результату. Детали реализации и принципиальные отличия распределенных систем были слишком велики, чтобы решаться с помощью автоматически генерируемого кода Proxy. Постепенно пришло понимание, что факт того, что системы связывает ненадежная, медленная, низкоскоростная среда, должен быть явно отражен в коде программы.
Появились технологии веб-сервисов. Мы стали говорить ABC: Address, Binding, Contract. Не совсем понятно, почему появились контракты, которые по сути являются Envelope (конвертами) для входных аргументов. Контракты чаще усложняют всю модель, чем упрощают ее. Но… неважно.
Теперь программист явным образом создавал сервис (Service) или клиента (Client), вызывающего сервис. Сервис представлял из себя набор операций (Operation), каждая из которых на входе принимала запрос (Request) и выдавала ответ (Response). Клиент явным образом посылал (Sent) запрос, сервис явным образом получал (Receive) его и отвечал (Sent), высылая ответ. Клиент получал (Receive) ответ и на этом вызов завершался.
Так же, как и в RPC, где-то здесь работали Proxy и Dispatcher. И как прежде их код генерировался автоматически и программисту не надо было в нем разбираться. Разве только что, клиент явным образом использовал классы из Proxy.
Запросы и ответы явным образом преобразуются к формату, предназначенному для передачи по проводам. Чаще всего это массив байт. Преобразование называется Serialization и Deserialization и иногда прячется в коде Proxy.
Кульминация messaging проявилась в появлении парадигмы ESB (Enterprise Service Bus). Никто толком не может сформулировать, что это такое, но все сходятся на том, что данные по ESB движутся в виде сообщений.
В постоянной борьбе со сложностью кода, программисты сделали очередной шаг и создали REST.
Основной принцип REST в том, что операции-функции резко ограничили и оставили только набор операций CRUD: Create — Read — Update — Delete. В этой модели все операции всегда применяются к некоторым данным. Имеющихся в CRUD операций достаточно для большей части приложений. Так как REST технологии в большинстве случаев подразумевают использование протокола HTTP, то команды CRUD отразились на команды HTTP (Post — Get — Put — Delete). Постоянно утверждается, что REST не обязательно привязан к HTTP. Но на практике повсеместно используется отражение сигнатур операций на синтаксис HTTP команд. К примеру, вызов функции
EntityAddress ReadEntityAddress(string param1, string param2)
выразится в таком виде:
Заключение
Прежде, чем начинать дискуссию по распределенным системам или по интеграции, определитесь с терминологией. Если Proxy всегда будет означать одно и то же в разных контекстах, то, к примеру, request мало что будет значить в терминах RPC, а marshalling вызовет недоумение при обсуждении REST технологий.
Русские Блоги
Введение в основы RPC: введение в принципы и простые примеры
1. RPC
1. Что такое RPC
2. Зачем использовать RPC?
Фактически это обусловлено высоким спросом на разработку приложений до определенной стадии.
1. Если мы разрабатываем простое одиночное приложение, логика проста, пользователей не так много, а трафик не велик, тогда нам это не нужно;
2. Когда число посещений нашей системы увеличивается, бизнес растет, и мы обнаружим, что один компьютер с этой системой больше не может себе позволить. В настоящее время мы можем разделить бизнес на несколькоНесвязанные приложенияОтдельно развернуты на своих соответствующих машинах для уточнения логики и снижения давления. В это время нам также может не понадобиться RPC, поскольку приложения не связаны друг с другом.
3. Естественно, когда у нас будет все больше и больше приложений и все больше и больше приложений, мы обнаружим, что некоторые функцииНельзя легко разделить или нет, В это время общедоступная бизнес-логика может быть извлечена и объединена в независимое сервисное приложение службы. Как исходные, так и вновь добавленные приложения могут взаимодействовать с этими независимыми приложениями-службами для выполнения полных бизнес-функций. Так что в это время нам срочно нужноЭффективное средство связи между приложениямиКак видите, для того, чтобы удовлетворить эту потребность, пришло время RPC показать свою силу!
На самом деле сценарий, описанный в 3, также Сервис, микросервис сАрхитектура распределенной системы Основная сцена. Таким образом, структура RPC является мощным способом достижения вышеуказанной структуры.
Во-вторых, принцип и рамки RPC
В документе Нельсона указывалось, что процедура внедрения СРП состоит из пяти частей:
Соотношение между этими пятью частями показано на рисунке ниже
Здесь пользователь является клиентской стороной, когда пользователь хочет инициировать удаленный вызов, он фактически вызывается локальноuser-stub, Пользовательская заглушка отвечает за кодирование вызываемых интерфейсов, методов и параметров через согласованные спецификации протокола и передачу их удаленному экземпляру через локальный экземпляр RPCRuntime. После получения запроса удаленный экземпляр RPCRuntime передает его заглушке на сервер для декодирования и инициирует локальный вызов, и результат вызова возвращается пользователю.
Крупнозернистый RPC реализует концептуальную структуру, здесь мы дополнительно уточним, из каких компонентов он должен состоять, как показано на следующем рисунке.
Сервер RPC использует RpcServer для экспорта метода удаленного интерфейса, а клиент использует RpcClient для импорта метода удаленного интерфейса. Клиент вызывает метод удаленного интерфейса, как локальный метод. Структура RPC обеспечивает реализацию интерфейса через прокси. Фактический вызов будет делегирован прокси RpcProxy. Агент инкапсулирует информацию о вызове и перенаправляет вызов в RpcInvoker для фактического выполнения. RpcInvoker на клиенте поддерживает канал RpcChannel с сервером через соединитель RpcConnector и использует RpcProtocol для выполнения кодирования (кодирования) протокола и отправляет закодированное сообщение запроса на сервер через канал.
Приемник RpcAcceptor сервера RPC получает запрос вызова клиента, а также использует RpcProtocol для выполнения декодирования (декодирования) протокола. Декодированная информация о вызове передается в RpcProcessor для управления процессом вызова, и, наконец, вызов делегируется в RpcInvoker для фактического выполнения и возврата результата вызова. Ниже приведены подробные обязанности каждой части:
1. RpcServer
Ответственный за экспорт (экспорт) удаленного интерфейса
2. RpcClient
Реализация прокси, отвечающая за импорт удаленных интерфейсов
3. RpcProxy
Прокси-реализация удаленного интерфейса
4. RpcInvoker
Реализация клиента: отвечает за кодирование информации о вызове и отправку запроса вызова на сервер и ожидание возврата результата вызова
Реализация сервера: отвечает за вызов конкретной реализации интерфейса сервера и возврат результата вызова
5. RpcProtocol
Ответственный за протокол кодирования / декодирования
6. RpcConnector
Отвечает за поддержание канала связи между клиентом и стороной обслуживания и отправку данных стороне обслуживания
7. RpcAcceptor
Отвечает за получение клиентских запросов и возврат результатов запроса.
8. RpcProcessor
Он отвечает за управление вызывающим процессом на стороне службы, включая управление пулом вызывающих потоков, временем ожидания и т. Д.
9. RpcChannel
Канал передачи данных
В-третьих, обычно используемая среда RPC в Java
Текущая обычно используемая среда RPC выглядит следующим образом:
3. Spring Cloud Spring Cloud состоит из множества подпроектов, таких как Spring Cloud Config, Spring Cloud Netflix, Spring Cloud Consul и т. Д., Которые предоставляют инструменты, обычно используемые для создания распределенных систем и микросервисов, такие как управление конфигурацией, обнаружение служб, прерыватели цепи, интеллектуальная маршрутизация, Прокси, шина управления, одноразовый токен, глобальная блокировка, выбор мастера, распределенный сеанс и состояние кластера и т. Д. Соответствуют всем решениям, необходимым для построения микросервисов. Spring Cloud основан на Spring Boot, что делает разработку и развертывание чрезвычайно простыми.
В-четвертых, разница между RPC и очередью сообщений
1. Функциональные различия
В архитектуре разница между RPC и Message заключается в том, что Message имеет очередь сообщений промежуточного узла, которая может хранить сообщения.
Особенности сообщения
1. Очередь сообщений сохраняет давление запроса и постепенно освобождает его, позволяя процессору обрабатывать его в своем темпе.
2. Очередь сообщений вводит новый узел. Надежность системы будет зависеть от узла очереди сообщений.
3. Очередь сообщений Асинхронный односторонний Новости. Отправка сообщений разработана таким образом, что нет необходимости ждать завершения обработки сообщения.
Так что для Синхронный возврат Использование очереди сообщений становится проблематичным.
Особенности RPC
Синхронный вызов. Для сценариев, в которых вы хотите дождаться возвращаемого результата / результата обработки, RPC является очень естественным и интуитивно понятным способом (RPC также может быть асинхронным вызовом).
В результате ожидания Consumer (клиент) будет потреблять потоки. При использовании в асинхронном RPC потребление потоков клиента (клиента) может быть устранено. Тем не менее, невозможно временно хранить сообщения / запросы, такие как сообщения, и давление будет напрямую передано поставщику услуг.
2. Различия в применимых случаях
1. RPC подходит, если вы хотите получить результат синхронно.
2. Если вы хотите использовать простой, то RPC; операция RPC основана на простом в использовании интерфейсе, используйте режим для имитации локальных вызовов. Программирование в асинхронном режиме является более сложным.
3. Не хочу отправителя (получатель RPC, отправитель сообщения) Ограничено стороной обработки (RPC Provider, Message Receiver), используйте очередь сообщений.
По мере роста бизнеса некоторые вычислительные мощности станут узким местом и будут продолжаться Синхронный вызов асинхронного сообщения Ремонт. Такая трансформация фактически меняет способ использования бизнеса. Например, после отправки исходной страницы операции на следующей странице будет показан результат обработки, а после преобразования асинхронного сообщения следующая страница станет «операция отправлена, и вы получите уведомление о ее завершении».
3. Описание неподходящих случаев
1. Синхронный вызов RPC использует очередь сообщений для передачи информации о вызове. Приведенный выше анализ показывает, что таким образом отправитель ожидает, занимая промежуточную точку ресурсов. Это становится сложным, но нет эквивалентного усиления.
2. Для вызова, возвращаемое значение которого равно void, вы можете сделать это, потому что фактически этому бизнесу вызовов часто не нужно получать результат обработки синхронно, если он может быть обработан. (Метод RPC может гарантировать, что вызов возвращается и обработка завершена. Это невозможно гарантировать после использования метода сообщения.)
3. Возвращаемое значение является вызовом void и используется сообщение. По сути, метод использования сообщения Wrap становится вызовом службы (метод использования вызова службы прост, основан на бизнес-интерфейсе).
V. Основные технические аспекты структуры RPC
Несколько основных технических моментов, реализованных в рамках RPC:
(1) Сервисное воздействие:
Удаленный поставщик должен предоставить в некоторой формеИнформация о сервисном звонке,в том числе, но не ограничиваетсяОпределение интерфейса сервиса、структура данныхИли промежуточныйФайл определения сервиса, Например, Facebook ThriftФайл IDL, Веб-сервисФайл WSDLВызывающий службу должен получать информацию, связанную с удаленным вызовом службы, определенным образом.
Существует также специальный звонок в JavaПолиморфизмТо есть, может быть несколько реализаций интерфейса, так что из них вызывается при удаленном вызове? Семантика этого локального вызова неявно реализуется посредством ссылочного полиморфизма, предоставляемого jvm, поэтому для RPC межпроцессные вызовы не могут быть реализованы неявно. Если есть две реализации интерфейса DemoService выше, вам необходимо экспортировать интерфейсСпециальные теги для разных нужд реализации, Затем вам нужно передать тег при удаленном вызове, чтобы вызвать правильный класс реализации, который решаетПолиморфный звонокСемантическая проблема.
(2) Удаленный прокси-объект:
Служба, используемая вызывающей стороной службы, фактически является локальным агентом удаленной службы. Говоря прямо, значит пройтиДинамический проксивыполнить.
(3) Связь:
Структура RPC не имеет ничего общего с конкретным протоколом. RPC может быть основан наПротокол HTTP или TCPВеб-служба представляет собой RPC на основе протокола HTTP, имеет хорошую кроссплатформенность, но ее производительность не так хороша, как RPC на основе протокола TCP.
3. Режим ввода-вывода: Для поддержки высокого параллелизма традиционная блокировка ввода-вывода явно не подходит, поэтому нам нужноАсинхронный ввод-выводКоторый является НИО. Java предоставляет решение NIO, а Java 7 также обеспечивает лучшую поддержку NIO.2.
(4) Сериализация:
1. СериализацияВ конце концов, это связь на большие расстояния, и объект должен быть преобразован в двоичный поток для передачи. Различные среды RPC имеют разные сценарии применения и будут использовать разные технологии в сериализации. Что касается сериализации, Java предоставляет метод сериализации по умолчанию, но в случае высокого параллелизма этот метод принесет некоторые узкие места производительности, поэтому на рынке появилась серия отличных платформ сериализации, таких как : Protobuf, Kryo, Hessian, Jackson и т. Д., Которые могут заменить сериализацию по умолчанию в Java, тем самым обеспечивая более эффективную производительность.
2. Закодированный контентПо соображениям эффективности, чем меньше закодированная информация, тем лучше (меньше передаваемых данных) и чем проще правила кодирования, тем лучше (высокая эффективность выполнения). Ниже приведена информация, необходимая для кодирования:
6. Простая реализация фреймворка RPC и анализ его примеров
Сервер предоставляет услуги, ожидаемые клиентом, которые обычно включают в себя три части: интерфейс службы, внедрение службы и возможность регистрации службы, а именно: интерфейс службы
Предоставление сервиса: только когда сервис открыт, клиент может сделать вызов. Это одна из функций инфраструктуры RPC.
Служба, предоставляемая клиентским сервером-потребителем, обычно включает две части: интерфейс службы и ссылку на службу, две части, а именно: интерфейс службы: совместно использовать один и тот же интерфейс службы с сервером
Ссылка на сервис: потребитель делает удаленные вызовы через инфраструктуру RPC, которая также является одной из функций инфраструктуры RPC
(3). Реализация прототипа фреймворка RPC
Инфраструктура RPC в основном включает две основные функции: одну для служб предоставления информации на стороне сервера и одну для справочных служб на стороне клиента. Сервер выставлен сервис
Из простой реализации инфраструктуры RPC логика сервера RPC заключается в следующем: сначала создайте ServerSocket, отвечающий за прослушивание определенного порта и получение запросов на подключение клиента, а затем используйте собственный механизм сериализации / десериализации Java для анализа запроса, включая вызываемый метод. Имя, список параметров и фактические параметры, и, наконец, отражают конкретную реализацию интерфейса службы, вызывая сервер и возвращая результат клиенту. На этом процесс сервера простого вызова PRC завершен. Клиентская справочная служба
Выше приведен простой и полный код, реализованный простой структурой RPC.
VII. Объяснение некоторых вопросов о структуре СРП
(1). Как инфраструктура RPC обеспечивает прозрачный вызов удаленного сервиса?
(2). Как опубликовать свой сервис?
Как позволить другим использовать наш сервис? Можно ли напрямую написать сервисный IP и порт, как в коде выше? На самом деле, в реальной производственной реализации способ использования уведомлений о человеческой плоти нереален, потому что в реальном производстве служебные машины слишком часто подключены к сети или отключены. Если вы обнаружите, что один компьютер не предоставляет достаточно услуг, вам нужно добавить еще один. В это время вы должны сообщить вызывающему абоненту, что у меня теперь есть два IP-адреса. Вы должны опросить вызов для достижения балансировки нагрузки; Когда машина зависает, вызывающая сторона обнаруживает, что половина службы недоступна, и он может только вручную изменить код, чтобы удалить ip, который зависает на этой машине. Это должно быть довольно больно!
(3). Сериализация и десериализация
Мы знаем, что объекты Java не могут быть переданы напрямую по сети. Итак, как можно отправить наш RPC-запрос на сервер и как клиент может получить ответ от сервера? Ответ заключается в том, что при передаче объектов Java сначала сериализуйте их, а затем десериализуйте и восстановите объекты на соответствующем терминале для обработки. Фактически, существует много видов технологий сериализации / десериализации, таких как собственный метод сериализации Java, JSON, сериализация Али Hessian и ProtoBuff и т. Д. Они имеют различия в эффективности, но имеют свои собственные характеристики.
Протокол rpc что это
Кроме того, существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках.
Эти и некоторые другие проблемы решает широко распространенная технология RPC, лежащая в основе многих распределенных операционных систем.
Базовые операции RPC
Чтобы понять работу RPC, рассмотрим вначале выполнение вызова локальной процедуры в обычной машине, работающей автономно. Пусть это, например, будет системный вызов
Чтобы осуществить вызов, вызывающая процедура заталкивает параметры в стек в обратном порядке (рисунок 3.1). После того, как вызов read выполнен, он помещает возвращаемое значение в регистр, перемещает адрес возврата и возвращает управление вызывающей процедуре, которая выбирает параметры из стека, возвращая его в исходное состояние. Заметим, что в языке С параметры могут вызываться или по ссылке (by name), или по значению (by value). По отношению к вызываемой процедуре параметры-значения являются инициализируемыми локальными переменными. Вызываемая процедура может изменить их, и это не повлияет на значение оригиналов этих переменных в вызывающей процедуре.
Если в вызываемую процедуру передается указатель на переменную, то изменение значения этой переменной вызываемой процедурой влечет изменение значения этой переменной и для вызывающей процедуры. Этот факт весьма существенен для RPC.
Существует также другой механизм передачи параметров, который не используется в языке С. Он называется call-by-copy/restore и состоит в необходимости копирования вызывающей программой переменных в стек в виде значений, а затем копирования назад после выполнения вызова поверх оригинальных значений вызывающей процедуры.
Рис. 3.1. а) Стек до выполнения вызова read;
б) Стек во время выполнения процедуры;
в) Стек после возврата в вызывающую программу
Этапы выполнения RPC
Взаимодействие программных компонентов при выполнении удаленного вызова процедуры иллюстрируется рисунком 3.2. После того, как клиентский стаб был вызван программой-клиентом, его первой задачей является заполнение буфера отправляемым сообщением. В некоторых системах клиентский стаб имеет единственный буфер фиксированной длины, заполняемый каждый раз с самого начала при поступлении каждого нового запроса. В других системах буфер сообщения представляет собой пул буферов для отдельных полей сообщения, причем некоторые из этих буферов уже заполнены. Этот метод особенно подходит для тех случаев, когда пакет имеет формат, состоящий из большого числа полей, но значения многих из этих полей не меняются от вызова к вызову.
Затем параметры должны быть преобразованы в соответствующий формат и вставлены в буфер сообщения. К этому моменту сообщение готово к передаче, поэтому выполняется прерывание по вызову ядра.
Рис. 3.2. Remote Procedure Call
Когда ядро получает управление, оно переключает контексты, сохраняет регистры процессора и карту памяти (дескрипторы страниц), устанавливает новую карту памяти, которая будет использоваться для работы в режиме ядра. Поскольку контексты ядра и пользователя различаются, ядро должно точно скопировать сообщение в свое собственное адресное пространство, так, чтобы иметь к нему доступ, запомнить адрес назначения (а, возможно, и другие поля заголовка), а также оно должно передать его сетевому интерфейсу. На этом завершается работа на клиентской стороне. Включается таймер передачи, и ядро может либо выполнять циклический опрос наличия ответа, либо передать управление планировщику, который выберет какой-либо другой процесс на выполнение. В первом случае ускоряется выполнение запроса, но отсутствует мультипрограммирование.
На стороне сервера поступающие биты помещаются принимающей аппаратурой либо во встроенный буфер, либо в оперативную память. Когда вся информация будет получена, генерируется прерывание. Обработчик прерывания проверяет правильность данных пакета и определяет, какому стабу следует их передать. Если ни один из стабов не ожидает этот пакет, обработчик должен либо поместить его в буфер, либо вообще отказаться от него. Если имеется ожидающий стаб, то сообщение копируется ему. Наконец, выполняется переключение контекстов, в результате чего восстанавливаются регистры и карта памяти, принимая те значения, которые они имели в момент, когда стаб сделал вызов receive.
Теперь начинает работу серверный стаб. Он распаковывает параметры и помещает их соответствующим образом в стек. Когда все готово, выполняется вызов сервера. После выполнения процедуры сервер передает результаты клиенту. Для этого выполняются все описанные выше этапы, только в обратном порядке.
Рис. 3.3. Этапы выполнения процедуры RPC
Рис. 3.4. Распределение времени между 14 этапами выполнения RPC
3. Упаковать параметры
4. Заполнить поле заголовка
5. Вычислить контрольную сумму в сообщении
6. Прерывание к ядру
7. Очередь пакета на выполнение
8. Передача сообщения контроллеру по шине QBUS
9. Время передачи по сети Ethernet
10. Получить пакет от контроллера
11. Процедура обработки прерывания
12. Вычисление контрольной суммы
13. Переключение контекста в пространство пользователя
14. Выполнение серверного стаба
Динамическое связывание
Рис. 3.5. Спецификация сервера RPC
Формальная спецификация сервера используется в качестве исходных данных для программы-генератора стабов, которая создает как клиентские, так и серверные стабы. Затем они помещаются в соответствующие библиотеки. Когда пользовательская (клиентская) программа вызывает любую процедуру, определенную в спецификации сервера, соответствующая стаб-процедура связывается с двоичным кодом программы. Аналогично, когда компилируется сервер, с ним связываются серверные стабы.
При запуске сервера самым первым его действием является передача своего серверного интерфейса специальной программе, называемой binder’ом. Этот процесс, известный как процесс регистрации сервера, включает передачу сервером своего имени, номера версии, уникального идентификатора и описателя местонахождения сервера. Описатель системно независим и может представлять собой IP, Ethernet, X.500 или еще какой-либо адрес. Кроме того, он может содержать и другую информацию, например, относящуюся к аутентификации.
Когда клиент вызывает одну из удаленных процедур первый раз, например, read, клиентский стаб видит, что он еще не подсоединен к серверу, и посылает сообщение binder-программе с просьбой об импорте интерфейса нужной версии нужного сервера. Если такой сервер существует, то binder передает описатель и уникальный идентификатор клиентскому стабу.
Клиентский стаб при посылке сообщения с запросом использует в качестве адреса описатель. В сообщении содержатся параметры и уникальный идентификатор, который ядро сервера использует для того, чтобы направить поступившее сообщение в нужный сервер в случае, если их несколько на этой машине.
Этот метод, заключающийся в импорте/экспорте интерфейсов, обладает высокой гибкостью. Например, может быть несколько серверов, поддерживающих один и тот же интерфейс, и клиенты распределяются по серверам случайным образом. В рамках этого метода становится возможным периодический опрос серверов, анализ их работоспособности и, в случае отказа, автоматическое отключение, что повышает общую отказоустойчивость системы. Этот метод может также поддерживать аутентификацию клиента. Например, сервер может определить, что он может быть использован только клиентами из определенного списка.
Однако у динамического связывания имеются недостатки, например, дополнительные накладные расходы (временные затраты) на экспорт и импорт интерфейсов. Величина этих затрат может быть значительна, так как многие клиентские процессы существуют короткое время, а при каждом старте процесса процедура импорта интерфейса должна быть снова выполнена. Кроме того, в больших распределенных системах может стать узким местом программа binder, а создание нескольких программ аналогичного назначения также увеличивает накладные расходы на создание и синхронизацию процессов.
Семантика RPC в случае отказов
На практике ни один из этих подходов не желателен, более того, уничтожение сирот может усугубить ситуацию. Например, пусть сирота заблокировал один или более файлов базы данных. Если сирота будет вдруг уничтожен, то эти блокировки останутся, кроме того уничтоженные сироты могут остаться стоять в различных системных очередях, в будущем они могут вызвать выполнение новых процессов и т.п.