Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 27
Текст из файла (страница 27)
2.14. Этапы написания клиента и сервера согласно DOE RPCВ системе клиент-сервер клеем, соединяющим все в единую систему, является описание интерфейса, которое создается с помощью языка определения интерфейсов {Interface Definition Language, IDL). Он позволяет описать процедурыв виде, очень похожем на прототипы функций в ANSI С. Файлы IDL могут также содержать определения типов, описания констант и другую информацию, необходимую для правильного маршалинга параметров и демаршалинга результатов, В идеале описание интерфейсов содержит также формальное определениедействий, осуществляемых процедурой, но это выходит за рамки современных возможностей программирования, так что определение интерфейса включает в себя только его синтаксис, но не семантику.
В лучшем случае программистможет лишь добавить комментарии, описывающие, что делает та или иная функция.Важнейшим элементом каждого файла IDL является глобальный уникальный идентификатор описываемого интерфейса. Клиент пересылает этот идентификатор в первом сообщении RPC, а сервер проверяет его правильность. В этомслучае если клиент по ошибке пытается выполнить привязку не к тому серверу2.2. Удаленный вызов процедур109или к старой версией правильного сервера, сервер обнаружит ошибку и привязки не произойдет.Описания интерфейсов и уникальные идентификаторы в DCE в значительной степени взаимозависимы. Как показано на ppic. 2.14, первым шагом при написании приложения клиент-сервер является запуск программы Uuidgen, от которой мы хотим создания прототипа файла IDL, содержащего идентификаторинтерфейса, гараитрфованно не использовавшийся ни в одном интерфейсе, созданном при помощи программы Uuidgen.
Уникальность обеспечивается путемкодирования идентификатора машины и времени созданрш. Идентификатор представляет собой 128-битное число, представляемое в файле IDL в шестнадцатеричном формате в виде строки ASCII.Следующим шагом является редактрфование файла IDL, задание в нем именудаленных процедур и их параметров. Несмотря на то что RPC не является полностью прозрачной системой (например, клиент и сервер не могут совместно использовать глобальные переменные), правила IDL делают описание неподдерживаемых конструкций невозможным.После того как файл IDL будет закончен, для его обработки вызывается компилятор IDL. В результате работы компилятора мы получаем три файла:4- заголовочный файл (то есть interface.h, в терминологии С);> файл клиентской заглушки;^ файл серверной заглушки.Заголовочный файл содержит уникальный идентификатор, определения типов, констант и описания функций.
Он может быть включен (с помощью директивы #1 л elude) в код сервера и клиента. Клиентская заглушка клиента содержитте процедуры, которые будет непосредственно вызывать клиентская программа.Эти процедуры отвечают за подбор параметров и упаковку их в исходящие сообщенР1я с последующими обращениями к системе для их отправки. Клиентскаязаглушка также занимается распаковкой ответов, приходящих от сервера, и передачей значений, содержащихся в этих ответах, клиенту. Серверная заглушкасодержит процедуры, вызываемые системой на машине сервера по приходе нанее сообщений. Они, в свою очередь, вызывают процедуры сервера, непосредственно выполняющие необходимую работу.Следующим шагом программиста является написание кода клиента и сервера.После этого они оба, а также обе заглушки, компилируются. Полученные объектные файлы клиента и клиентской заглушки компонуются с библиотекамивремени выполнения, что дает в результате исполняемый файл клиента.
Такимже точно образом из файлов сервера и серверной заглушки после компиляции икомпоновки получается исполняемый файл сервера. Во время исполнения клиент и сервер будут запущены, и приложение начнет свою работу.Привязка клиента к серверуЧтобы позволить клиенту вызывать сервер, необходимо, чтобы сервер был зарегистрирован и готов к приему входящих вызовов. Регистрация сервера дает кли-110Глава 2. Связьенту возможность реально обнаружить сервер и выполнить привязку к нему.
Обнаружение сервера происходит в два этапа.1. Обнаружение машины сервера.2. Обнаружение сервера (то есть нужный процесс) на этой машине.Второй шаг немного непонятен. В общем случае для того, чтобы связатьсяс сервером, клиенту нужно знать конечную точку (endpoint) машины сервера, которой он может посылать сообщения. Конечная точка (более известная под названием порт) используется операцрюнноР! системой сервера для получениявходящих сообщений от различных внешних процессов. В DCE на каждой из серверных машин процессом, известным под названием DCE-демон (DCE daemon)^поддерживается таблица пар сервер — конечная точка. Перед тем как сервер станет доступным для входящих запросов, он должен запросить у операционнойсистемы конечную точку. Далее сервер регистрирует эту конечную точку у DCEдемона.
DCE-демон записывает эту информацию (включая и протоколы, по которым может осуществляться обмен информацией с сервером) в таблицу конечных точек для последующего использования.Сервер также регистрирует (с помощью службы каталогов) предоставленныесерверной машине сетевой адрес и имя, под которым сервер будет доступен. Затем происходит привязка клиента к серверу, как показано на рис. 2.15.Машина службы каталоговСерверслужбыкаталоговМашина клиентаКлиент3Машина сервераСерверО,DCBдемонТаблицаконечныхточекРис. 2.15.
Привязка клиента к серверу в DCEКак показано на рисунке, привязка выполняется в несколько этапов.1. Регистрация конечной точки.2. Регистрация службы.3. Поиск сервера службы каталогов.4. Запрос конечной точки.5. Выполнение вызова RPC.Предположим, клиенту требуется привязка к серверу видеоинформации, локально доступному под именем /local/multimedia/video/movies. Он передает это2.3. Обращение к удаленным объектам111имя серверу службы каталогов. Последний возвращает сетевой адрес машины, на которой работает сервер видеоданных. После этого клиент обращаетсяк DCE-демону этой машины (имеющему общеизвестную конечную точку) и просит его найти в его таблице конечных точек конечную точку сервера видеоинформации. Теперь, вооружившись полученными данными, мы можем выполнитьвызов RPC.
В ходе последующих вызовов RPC нам нет нужды проделывать всюпроцедуру поиска заново.При необходимости система DCE дает клиенту возможность усложненногопоиска необходимого сервера. Безопасность RFC также входит в ее задачи.Выполнение вызова RPCРеальный вызов RPC происходит прозрачно и обычным образом. Клиентская заглушка выполняет маршалинг параметров в том порядке, который необходим длябиблиотечных функций, осуществляющих передачу с использованием выбранного при привязке протокола. Когда сообщение приходит на машину с серверами,оно передается нужному серверу в соответствии с содержащейся в сообщении конечной точкой.
Библиотека времени выполнения передает сообщение сервернойзаглушке, которая выполняет демаршалинг параметров и вызывает сервер. Ответотправляется назад по тому же маршруту.DCE предоставляет программистам некоторые семантические возможности.По умолчанию поддерживается одноразовая операция (at-most-once operation), всоответствие с которой ни один вызов не может осуществляться более одногораза, даже в случае краха системы. На практике это означает, что если сервер в ходе вызова RPC «рухнул», а затем был быстро восстановлен, клиент не долженповторять операцрпо, поскольку она, возможно, уже выполнена.С другой стороны, можно пометить (в файле IDL) удаленную процедуру какидемпотентпую (idempotent), в этом случае не возбраняются многочисленные повторы запросов. Так, например, чтение некоторого блока из файла можно повторять снова и снова, пока оно не будет успешно закончено.
Если выполнениеидемпотентного блока из-за сбоя сервера срывается, клиент может подождатьперезагрузки сервера и сделать новую попытку. Также имеется и другая (редкоиспользуемая) семантика, включающая в себя широковещательные рассылкивызовов RPC всем машинам текущей локальной сети. Мы вернемся к семантикеRPC в главе 7 при рассмотрении работы RPC в условиях сбоев.2.3. Обращение к удаленным объектамОбъектно-ориентированная технология показала свое значение при разработкенераспределенных приложений. Одним из наиболее важных свойств объекта является то, что он скрывает свое внутреннее строение от внешнего мира посредством строго определенного интерфейса.
Такой подход позволяет легко заменятьили изменять объекты, оставляя интерфейс неизменным.По мере того как механизм RPC постепенно становился фактическим стандартом осуществления взаимодействия в распределенных системах, люди начали112Глава 2. Связьпонимать, что принципы RPC могут быть равно применены и к объектам. В этомразделе мы распространим идею RFC на обращения к удаленным объектами рассмотрим, как подобный подход может повысить прозрачность распределенияпо сравнению с вызовами RPC.
Мы сосредоточимся на относительно простыхудаленных объектах. В главе 10 мы коснемся нескольких объектных распределенных систем, включая CORBA и DCOM, каждая из которых поддерживает более серьезную, совершенную объектную модель, чем та, которую мы будем рассматривать сейчас.2 . 3 . 1 . Распределенные объектыКлючевая особенность объекта состоит в том, что он инкапсулирует данные, называемые состоянием {state), и операции над этими данными, называемые л/^шодами {methods).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
