Сетевое ПО Лекция 7 (1061292), страница 2
Текст из файла (страница 2)
Лекция 7(2014 г.)Примитив Send используется процессом, намеревающимся передатьсообщение. Его параметрами являются идентификатор процесса-получателяи содержимое сообщения. Модуль передачи сообщений создает единуюструктуру данных, содержащую переданную информацию, и отправляет еена машину, где работает процесс-получатель, при, помощи некоторыхсредств коммуникации, например, используя протоколы TCP/IP.
Подостижении системы-получателя данные пересылаются ее средствамикоммуникации модулю передачи сообщений этой системы. Тот определяет(по содержимому поля идентификатора процесса) получателя данногосообщения и помещает полученную информацию в буфер этого процесса.В данном сценарии процесс-получатель должен объявить о своейготовности получать сообщения путем создания принимающего буфера иуведомления об этом модуля передачи сообщений вызовом примитиваReceive.
При альтернативном подходе такого оповещения не требуется.Вместо этого, получив сообщение, модуль передачи сообщений каким-топредопределенным образом сигнализирует об этом процессу-получателю ипомещает полученное сообщение в совместно используемый буфер.1.5.2 Вызов удалённых процедурВариацией базовой модели передачи сообщений является вызов удаленныхпроцедур (remote procedure call — RPC).Популярность этого подхода обусловлена рядом достоинств метода.1. Вызов процедуры — широко распространенная, используемая и понятнаяабстракция.2. Использование вызова удаленных процедур позволяет задавать удаленныйинтерфейс как множество именованных операций определенного типа.Такимобразом,интерфейсможноточнодокументировать,ираспределенные программы смогут выполнять статическую проверкутипов.3.
Посколькуинтерфейсыстандартизованыиточнокоммуникационный код может генерироваться автоматически.определены,9Сетевое ПО. Лекция 7(2014 г.)4. Посколькуинтерфейсыстандартизованыиточноопределены,разработчики могут создавать клиентские и серверные модули, которыетребуют минимальных доработок при переносе между различнымикомпьютерными платформами и операционными системами.Механизм вызова удаленных процедур может рассматриваться какусовершенствованнаянадежнаяблокирующаяпередачасообщений.Архитектура RPC приведена на рис.
7.6,б. Вызывающая программаосуществляет обычный вызов процедуры с параметрами на своей машине,например CALL P(X, Y), где Р — имя процедуры, X — передаваемыеаргументы, a Y — возвращаемые значения. Этот вызов может приводить кпрозрачному для пользователя выполнению удаленной процедуры на другоймашине.
В адресное пространство пользователя должна быть включенапроцедура-заглушка Р (которая также может быть динамически подключенавмоментвызова).Этапроцедурасоздаетсообщение,котороеидентифицирует вызываемую процедуру и включает передаваемые ейпараметры. Затем процедура-заглушка пересылает это сообщение удаленнойсистеме и ожидает от нее ответ. Когда ответ получен, заглушка возвращаетуправление вызывающей программе, передавая ей возвращаемые значения.На удаленной машине с вызываемой процедурой связана другаяпрограмма-заглушка.
Когда поступает сообщение, заглушка обрабатываетего и генерирует локальный вызов CALL P(X, Y). Таким образом, этаудаленная процедура вызывается локально, так что не надо специальнозаботиться о передаче параметров, состоянии стека и т.п. — вызов абсолютноидентичен вызову обычной локальной процедуры.С вызовом удаленных процедур связан ряд вопросов.Передача параметровБольшинствоязыковпрограммированияпозволяютиспользоватьпередачу параметров по значению либо как указатель на ячейки памяти,содержащиезначение(передачапараметровпоссылке).Передачапараметров по значению идеально подходит для вызова удаленной10Сетевое ПО. Лекция 7(2014 г.)процедуры: параметры при этом просто копируются в сообщение ипересылаются удаленной системе. Реализовать передачу параметров поссылке сложнее — при этом для каждого объекта потребуется свой,уникальный в пределах системы, указатель. Накладные расходы приреализации возможности передачи параметров по ссылке обычно настольковелики, что овчинка выделки не стоит.Представление параметровЕще один вопрос заключается в способе представления параметров ирезультата работы процедуры в сообщении.
Если вызывающая и вызываемаяпрограммы написаны на одном языке программирования для одного типамашин, находящихся под управлением одной и той же операционнойсистемы, то представление параметров проблем не вызывает. Однако еслиперечисленные характеристики различны, то немедленно возникают вопросыпредставления чисел (и даже текста) в различных системах. Использованиеархитектуры, в которой эти вопросы решаются на уровне представления,приводит к высоким накладным расходам, так что зачастую ответственностьза преобразование передаваемых параметров ложится на средства вызоваудаленных процедур .Наилучшийиспользованииподходкрешениюстандартизованногоэтойпроблемыформатадлязаключаетсявраспространенныхобъектов, таких, как целые числа, числа с плавающей запятой, символы истроки. В таком случае при передаче данные конвертируются изпредставления в данной конкретной машине в стандартное представление.Связывание клиент/серверСвязывание (binding) определяет, каким образом будет установленавзаимосвязь между удаленной процедурой и вызывающей программой.Связывание формируется, когда два приложения устанавливают логическуюсвязь и готовятся к обмену командами и данными.Непостоянное связывание (nonpersistent binding) означает, что логическаясвязь между двумя процессами устанавливается во время вызова удаленной11Сетевое ПО.
Лекция 7(2014 г.)процедуры и немедленно уничтожается после получения возвращаемогозначения. Поскольку соединение требует поддержки информации осостоянии на обоих концах, оно потребляет ресурсы. Соответственно,непостоянное связывание позволяет эти ресурсы сэкономить. Но, с другойстороны, при этом мы получаем излишние накладные расходы поустановлению связывания при каждом вызове процедуры, так что этот методплохо подходит в случае частого вызова удаленных процедур одной и той жевызывающей программой.При постоянном связывании (persistent binding) связь устанавливаетсяпри вызове удаленной процедуры, но по окончании вызова не уничтожается.Эта же связь может использоваться и для других вызовов удаленныхпроцедур.
Если i течение предопределенного промежутка времени неосуществляется ни один вызов, такая связь с целью экономии ресурсовразрывается. Этот метод хорошо подходит для интенсивного вызоваудаленных процедур, позволяя множеству вызовов использовать одно и тоже соединение.Синхронный и асинхронный вызовыКонцепция синхронных и асинхронных вызовов удаленных процедураналогичнаконцепцииблокирующихинеблокирующихсообщений.Традиционный вызов удаленных процедур — синхронный, при которомвызывающий процесс ожидает, пока вызываемый процесс не вернетрезультирующее значение; синхронный RPC ведет себя так же, как иобычный вызов процедуры.Синхронный RPC прост для понимания и программирования, посколькуего поведение предсказуемо. Однако такой вызов не позволяет в полной мереиспользовать возможность параллельных вычислений в распределенныхприложениях, что приводит к ограничению видов взаимодействия враспределенныхприложенияхпроизводительности.иможетпривестикснижению12Сетевое ПО.
Лекция 7(2014 г.)Для обеспечения большей гибкости и большей степени параллельности,реализованы различныеварианты асинхронного RPC, сохраняющиепростоту и удобство традиционных вызовов удаленных процедур.Асинхронные вызовы не блокируют вызывающую программу; ответможет быть получен вызывающей программой тогда, когда он ейпотребуется, так что клиент может продолжать работу параллельно собработкой его запроса сервером.Обычно асинхронный RPC используется для того, чтобы позволитьклиенту сделать несколько запросов к серверу, каждый со своим наборомданных, не дожидаясь его ответов.
Синхронизация клиента и сервера приэтом может быть выполнена одним из двух способов.1. Приложение-клиент дожидается ответа на все отправленные запросы.2. По окончании выполнения последовательности асинхронных RPC клиентвыполняет синхронный вызов удаленной процедуры. Сервер ответит насинхронныйвызовтолькопоокончанииобработкивсехпредшествующихасинхронных вызовов.В некоторых схемах асинхронные вызовы не требуют ответа от сервера,и сервер не может послать сообщение в ответ. В других схемах ответтребуется (или позволяется), но клиент его не ожидает, выполняя другиедействия.1.5.3 Объектно-ориентированный подходОбъектно-ориентированныетехнологиистановятсявсеболеераспространенными как при создании операционных систем, так и приразработке систем клиент/сервер.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
