Пример поля аутентификации UNIX

Размер поля аутентификации в сообщении RPC зависит от его содержания. Например, второе поле в структуре аутентификации UNIX представляет собой имя компьютера в формате переменной длины. Стандарт XDR предусматривает представление строки переменной длины в виде 4-байтового целочисленного поля с обозначением длины, за которым следуют байты самой строки. На рис. 21.8 показано представление поля аутентификации UNIX. В данном примере имя компьютера (merlin.cs.purdue.edu) содержит 20 символов. Значения для этого примера взяты из сообщения, отправленного пользователем с числовым идентификатором регистрационной записи 30 компьютера merlin.cs.purdue.edu. Для путешественников авиабилеты онлайн Украина на 711.ua быстро и недорого.

Резюме

Модель дистанционного вызова процедур упрощает проектирование и изучение распределенных программ, поскольку предусматривает применение средств взаимодействия типа клиент/сервер для осуществления вызова процедур. В модели дистанционного вызова процедур каждый сервер рассматривается как удаленная программа, в которой реализована одна или несколько процедур. Сообщение, переданное от клиента к серверу, соответствует "вызову" удаленной процедуры, а ответ сервера клиенту соответствует "возврату управления" из вызванной процедуры.

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

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

Компания Sun Microsystems определила конкретную форму дистанционного вызова процедур, которая фактически признана в качестве стандарта. Спецификация ONC RPC определяет общий принцип обозначения удаленных процедур, а также стандартный формат сообщений RPC. В этом стандарте для обеспечения независимости передаваемых сообщений от архитектуры компьютера используется стандарт внешнего представления данных XDR.

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

Материал для дальнейшего изучения

В документе определен стандарт для ONC RPC и описана основная часть концепций, представленных в этой главе. В документе содержится новая версия RPC, которая представляет собой проект стандарта. С дополнительной информацией можно ознакомиться в оперативной документации, которая входит в поставку операционной системы Linux.

  1. Прочитайте спецификацию ONC RPC и подготовьте схему с указанием размеров полей в типичном ответном сообщении.
  2. Проведите эксперимент по измерению издержек, связанных с использованием службы привязки портов.
  3. В клиентской программе можно избежать ненужных издержек, кэшируя информацию о привязке портов протокола. Это означает, что после передачи запроса к службе привязки портов для получения номера порта протокола намеченной программы RPC клиент может сохранить информацию о привязке в кэше, чтобы избежать повторного поиска. Как долго эта информация будет оставаться действительной?
  4. Может ли принцип использования службы привязки портов быть распространен на службы, отличные от RPC? Поясните свой ответ.
  5. В чем состоят основные преимущества и недостатки применения службы привязки портов вместо общепринятых портов?
  6. При передаче запроса в службу привязки портов клиент RPC должен либо указать, что намеченная программа открыла порт UDP или TCP, либо узнать, так ли это на самом деле. Внимательно прочитайте спецификацию, чтобы найти ответ на вопрос о том, как клиент RPC различает эти две ситуации.
  7. Если на вашем компьютере есть вспомогательная программа rpcinfo, прочитайте справочное руководство для определения ее возможностей. Воспользуйтесь программой rpcinfo для получения списка программ и версий RPC, доступных на вашем компьютере.
  8. Прочитайте литературу по проектам RPC, предложенным другими поставщиками. Реализованы ли в них принципы, не представленные в спецификации ONC RPC?
  9. Рассмотрите схему аутентификации, применяемую в ONC RPC. Обеспечивает ли эта схема полную защиту, позволяющую использовать ее для обмена данными в пределах одного предприятия? Между несколькими предприятиями?
  10. Сравните спецификации DCE RPC и ONC RPC. В чем их различия?
  11. Прочитайте литературу по архитектуре CORBA (Common Object Request Broker Architecture — Общая архитектура брокера объектных запросов). Какие новые средства предоставляет эта архитектура для RPC?
Похожие статьи Меню Опрос Фото Популярное