А. Робачевский - Операционная система UNIX (1114671), страница 83
Текст из файла (страница 83)
Удаленный вызовпроцедурВ предыдущих разделах рассматривался программный интерфейс доста!точно низкого уровня — по существу программа взаимодействовала непо!средственно с транспортным протоколом, самостоятельно реализуя неко!торый протокол верхнего уровня при обмене данными. В приведенныхпримерах легко заметить, что значительная часть кода этих программ по!священа созданию коммуникационных узлов, установлению и завершениюсвязи.С точки зрения разработчика программного обеспечения, более перспек!тивным является подход, когда используется прикладной программныйинтерфейс более высокого уровня, изолирующий программу от спецификисетевого взаимодействия. В данном разделе мы рассмотрим один из такихподходов, на базе которого, в частности, разработана файловая системаNFS, получивший название удаленный вызов процедур (Remote ProcedureCall,www.books-shop.comПрограммные интерфейсыИспользование подпрограмм в программе — традиционный способ струк!турировать задачу, сделать ее более ясной.
Наиболее часто используемыеподпрограммы собираются в библиотеки, где могут использоваться раз!л и ч н ы м и программами. В данном случае речь идет о локальном (местном)вызове, т. е. ии вызываемый объекты работают в рамкаходной программы на одном компьютере.В случае удаленного вызова процесс, выполняющийся на одном компью!тере, запускает процесс на удаленном компьютере (т. е.
фактически запус!кает код процедуры на удаленном компьютере). Очевидно, что удаленныйвызов процедуры существенным образом отличается от традиционного ло!кального, однако с точки зрения программиста такие отличия практическиотсутствуют, т. е. архитектура удаленного вызова процедуры позволяетсымитировать вызов локальной.Однако если в случае локального вызова программа передает параметры ввызываемую процедуру и получает результат работы через стек или общиеобласти памяти, то в случае удаленного вызова передача параметров пре!вращается в передачу запроса по сети, а результат работы находится впришедшем отклике.Данный подход является возможной основой созданияпри!ложений, и хотя многие современные системы не используют этот меха!низм, основные концепции и термины во многих случаях сохраняются.
Приописании механизма RPC мы будем традиционно называть вызывающийпроцесс — клиентом, а удаленный процесс, реализующий процедуру, —Удаленный вызов процедуры включает следующие шаги:1. Программа!клиент производит локальный вызов процедуры, называе!мой заглушкой (stub). При этом клиенту "кажется", что, вызывая за!глушку, он производит собственно вызов процедуры!сервера. И дейст!вительно, клиент передает заглушке необходимые параметры, а онавозвращает результат.
Однако дело обстоит не совсем так, как это себепредставляет клиент. Задача заглушки — принять аргументы, предна!значаемые удаленной процедуре, возможно, преобразовать их в некийстандартный формат и сформировать сетевой запрос. Упаковка аргу!ментов и создание сетевого запроса называется сборкой (marshalling).2.
Сетевой запрос пересылается по сети на удаленную систему. Для этогов заглушке используются соответствующие вызовы, например, рас!смотренные в предыдущих разделах. Заметим, что при этом могут бытьиспользованы различные транспортные протоколы, причем не толькосемейства TCP/IP.На удаленном хосте все происходит в обратном порядке. Заглушкасервера ожидает запрос и при получении извлекает параметры — ар!гументы вызова процедуры.может включатьwww.books-shop.com442Глава 6.сети в операционной системе UNIXнеобходимые преобразования (например, изменения порядка распо!ложения байтов).4. Заглушка выполняет вызов настоящей процедуры!сервера, которой ад!ресован запрос клиента, передавая ей полученные по сети аргументы.5.
После выполнения процедуры управлениев заглушкусервера, передавая ей требуемые параметры. Как и заглушказаглушка сервера преобразует возвращенные процедуройформируя сетевое сообщение!отклик, который передается по сети сис!теме, от которой пришел запрос.6. Операционная система передает полученное сообщение заглушке кли!ента, которая, после необходимого преобразования, передает значения(являющиеся значениями, возвращенными удаленной процедурой) кли!енту, воспринимающему это как нормальный возврат изТаким образом, с точки зрения клиента, он производит вызов удаленнойпроцедуры, как он это сделал бы для локальной.
То же самое можно ска!зать и о сервере: вызов процедуры происходит стандартным образом, не!кий объект (заглушка сервера) производит вызов локальной процедуры иполучает возвращенные ею значения. Клиент воспринимает заглушку каквызываемую процедуру!сервер, а сервер принимает собственную заглушкуза клиента.Таким образом, заглушки составляют ядро системы RPC, отвечая за всеаспекты формирования и передачи сообщений между клиентом и удален!ным сервером (процедурой), хотя и клиент и сервер считают, что вызовыпроисходят локально. В этом!то и состоит основная к о н ц е п ц и я—полностью спрятать распределенный (сетевой) характер взаимодействия вкоде заглушек.
Преимущества такого подхода очевидны: и клиент и серверявляются независимыми от сетевой реализации, оба они работают в рам!ках некой распределенной виртуальной машины, и вызовы процедур име!ют стандартныйПередача параметровПередача параметров!значений не вызывает особых трудностей.
Вслучае заглушка клиента размещает значение параметра в сетевом запросе.возможно, выполняя преобразования к стандартному виду (например, из!меняя порядок следования байтов). Гораздо сложнее обстоит дело с' Кроме прочего, благодаря такому подходу, достигается независимостькомпо!распределенного приложения (клиента и сервера) не только от сетевойции, но и от типа операционных систем, под управлением которых онииот языка программирования, на котором написаны сами компоненты.
Скажем,может быть создан в виде программы на языке С, выполняющейся пол у п р а в л е н и е мв тов качестве клиента может выступатьразработанная наязыке Pascal, выполняющаяся в среде Windows NT!www.books-shop.comПрограммные интерфейсы443дачей указателей, когда параметр представляет собой адрес данных, а неих значение. Передача в запросе адреса лишена смысла, так как удаленнаявыполняется в совершенно другом адресном пространстве. Са!мым простым решением, применяемым в RPC, является запрет клиентампередавать параметры иначе, как по значению, хотя это, безусловно на!кладывает серьезныеСвязывание (binding)Прежде чем клиент сможет вызвать удаленную процедуру, необходимосвязать его с удаленной системой, располагающей требуемым сервером.Таким образом, задача связывания распадается на две:Нахождение удаленного хоста с требуемым серверомНахождение требуемого серверного процесса на данном хостеДля нахождения хоста могут использоваться различные подходы.
Возмож!ный вариант — создание некоего централизованного справочника, в кото!ром хосты анонсируют свои серверы, и где клиент при желании можетвыбратьдля него хост и адрес процедуры.Каждая процедура RPC однозначно определяется номером программы ипроцедуры. Номер программы определяет группу удаленных процедур,каждая из которых имеет собственный номер. Каждой программе такжеприсваивается номер версии, так что при внесении в программу незначи!тельных изменений (например, при добавлении процедуры) отсутствуетнеобходимость менять ее номер. Обычно несколько функционально сход!ных процедур реализуются в одном программном модуле, который призапуске становится сервером этих процедур, и который идентифицируетсяномером программы.Таким образом, когда клиент хочет вызвать удаленную процедуру, ему не!обходимо знать номера программы, версии и процедуры, предоставляю!щей требуемый сервис.Для передачи запроса клиенту также необходимо знать сетевой адрес хостаи номер порта, связанный с программой!сервером, обеспечивающей тре!буемыеДля этого используется демон(в некото!рых системах он называетсяДемон запускается на хосте, ко!торый предоставляет сервис удаленных процедур, и использует общеизве!стный номер порта.
При инициализации процесса!сервера он регистриру!ет всвои процедуры и номера портов. Теперь, когда клиентутребуется знать номер порта для вызова конкретной процедуры, он посы!лает запрос на серверкоторый, в свою очередь, либо возвра!Более сложныеподобныхиихсоздавать(напримеррядом дополнительных возможностей, чтораспределенные системы.лишенысwww.books-shop.com444Глава 6.сети в операционнойUNIXномер порта, либо перенаправляет запрос непосредственно серверуудаленной процедуры и после ее выполненияклиенту отклик.В любом случае, если требуемая процедураклиент получает отсервераномер порта процедуры, и дальнейшие запросы можетделать уже непосредственно на этот порт.Обработка особых ситуацийОбработка особых ситуаций при вызове локальных процедур не представ!ляет особой проблемы. U N I X обеспечивает обработку ошибок процессов,таких как деление на ноль, обращение к недопустимой области памяти ит.
д. В случае вызова удаленной процедуры вероятность возникновенияошибочных ситуаций увеличивается.ошибкам сервера и заглушек до!бавляются ошибки, связанные, например, с получением ошибочного сете!вого сообщения.Например, при использовании UDP в качестве транспортного протоколапроизводится повторная передача сообщений после определенного тайм!аута. Клиенту возвращается ошибка, если, спустя определенное число по!отклик от сервера так и не был получен. В случае, когда использу!ется протокол TCP, клиенту возвращается ошибка, если сервер оборвалTCP!соединение.Семантика вызоваВызов локальной процедуры однозначно приводит к ее выполнению, по!сле чего управление возвращается в головную программу.