Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 50
Текст из файла (страница 50)
Изменения не окажут влияния на су-192Глава 3. Процессышествующие клиентские приложения, связанные с сервером. Существуют, разумеется, и недостатки. Наиболее серьезный, который мы будем обсуждать в главе 8, связан с безопасностью. Слепо верить в то, что загружаемый код реализуеттолько объявленные интерфейсы доступа к вашему незащищенному жесткомудиску и не отправляет наиболее интересные фрагменты неизвестно кому, — невсегда оправдано.Модели переноса кодаХотя перенос кода подразумевает только перемещение кода с машины на машину, этот термин имеет более широкую область применения. Традиционно связьв распределенных системах основана на обмене данных между процессами. Перенос кода в широком смысле связан с переносом программ с машины на машинус целью исполнения этих программ в нужном месте.
В некоторых случаях, такихкак перенос процессов, также должны переноситься состояние программы, получаемые сигналы и прочие элементы среды.Для лучшего понимания различных моделей переноса кода используем шаблон, описанный в [156]. Согласно этому шаблону, процесс состоит из трех сегментов. Сегмент кода — это часть, содержащая набор инструкций, которые выполняются в ходе исполнения программы. Сегмент ресурсов содержит ссылки навнешние ресурсы, необходимые процессу, такие как файлы, принтеры, устройства, другие процессы и т. п. И наконец, сегмент исполнения используется для хранения текущего состояния процесса, включая закрытые данные, стек и счетчикпрограммы.Абсолютный минимум для переноса кода предлагает модель слабой мобильности {weak mobility).
Согласно этой модели допускается перенос только сегментакода, возможно вместе с некоторыми данными инициализации. Характернойчертой слабой мобильности является то, что перенесенная программа всегда запускается из своего исходного состояния.
Это происходит, например, с Java-anплетами. Достоинство подобного подхода в его простоте. Слабая мобильностьтребуется только для того, чтобы мaшpп^a, на которую переносится код, была всостоянии его исполнять. Этого вполне достаточно, чтобы сделать код переносимым. Мы вернемся к данному вопросу, когда будем обсуждать перенос программв гетерогенных системах.В противоположность слабой мобильности, в системах, поддерживающихсильную мобильность {strong mobility), переносится также и сегмент исполнения.Характерная черта сильной мобильности — то, что работающий процесс можетбыть приостановлен, перенесен на другую машину и его выполнение продолженос того места, на котором оно было приостановлено. Ясно, что сильная мобильность значительно мощнее слабой, но и значительно сложнее в реализации.
Примером системы, поддерживающей сильную мобильность, является система D'Agents,которую мы рассмотрим позднее в этой главе.Независимо от того, является мобильность слабой или сильной, следует провести разделение на системы с переносом, инициированным отправителем, и системы с переносом, инициированным получателем. При переносе, инициированном отправителем, перенос инициируется машиной, на которой переносимый3.4. Перенос кода193код постоянно размещен или выполняется. Обычно перенос, инициированныйотправителем, происходит при загрузке программ на вычислительный сервер.Другой пример — передача поисковых программ через Интернет на сервер базданных в Web для выполнения запроса на этом сервере.
При переносе, инициированном получателем, инициатива в переносе кода принадлежит машине-получателю. Пример такого подхода — Java-апплеты.Перенос, инициируемый получателем, обычно реализуется проще. Во многихслучаях перенос кода происходит между клиентом и сервером, причем инициатива исходит от клиента. Безопасный перенос кода на сервер, как это происходит при переносе, инициированном отправителем, часто требует, чтобы клиентбыл сначала зарегистрирован и опознавался сервером. Другими словами, сервердолжен знать всех своих клиентов, поскольку клиенты, естественно, имеют доступ к ресурсам сервера, таким как его диск. Защита этих ресурсов является необходимым делом. В противоположность этому, загрузка кода в случае инициирования этого процесса принимающей стороной может осуществляться анонимно.Более того, сервер обычно не заинтересован в ресурсах клиента.
Напротив, перенос кода на клиента производится исключительно с целью увеличения производительности клиента. С этой стороны в защите нуждается лишь небольшоеколичество ресурсов, таких как память и сетевое соединение. Мы вернемся к защите переноса кода позже и подробно рассмотрим ее в главе 8.В случае слабой мобильности следует также разделять варианты, когда перенесенный код выполняется в процессе-приемнике или когда он выполняетсяв новом, специально запущенном процессе. Так, например, Java-апплеты простозагружаются в web-браузер и выполняются в адресном пространстве браузера.Преимущество этого подхода состоит в том, что нам нет необходимости запускать новый процесс PI разрывать из-за этого связь с машиной-приемником.
Основной недостаток состоит в том, что процесс-приемник приходится защищатьот злонамеренного или случайного выполнения кода. Простое решение — потребовать от операционной системы для перемещенного кода создать отдельныйпроцесс. Отметим, что, как уже говорилось, это решение не решает проблем с доступом к ресурсам.Помимо переноса работающего процесса, называемого также миграцией процесса, сильная мобильность может также осуществляться за счет удаленногоклонирования.
В отличие от миграции процесса клонирование создает точнуюкопию исходного процесса, которая выполняется на удаленной машине. Клонпроцесса выполняется параллельно оригиналу. В UNIX-системах удаленное клонирование имеет место при ответвлениях дочернего процесса в том случае, когдаэтот дочерний процесс продолжает выполнение на удаленной машине. Преимущество клонирования — в схожести со стандартными процедурами, осуществляемыми в многочисленных приложениях. Единственная разница между ними состоит в том, что клонированный процесс выполняется на другой машине.
С этойточки зрения миграция путем клонирования — самый простой способ повышения прозрачности распределения.Различные варианты переноса кода иллюстрирует рис. 3.9.194Глава 3. ПроцессыИсполнениеПеренос,' инициируемыйотправителем/Слабая мобильность.Перенос,' инициируемыйполучателемМеханизм переносаПеренос,' инициируемыйотправителемв процессе-приемникеИсполнениев отдельном процессе.
Исполнениев процессе-приемнике. Исполнениев отдельном процессе' Перенос процесса' Клонирование процесса^Сильная мобильность.Перенос,' инициируемыйполучателем' Перенос процесса* Клонирование процессаРис. 3.9. Варианты переноса кода3.4.2. Перенос и локальные ресурсыРанее мы рассматривали перенос только сегментов кода и исполнения. Сегментресурсов требует отдельного рассмотрения. Перенос кода нередко сильно затрудняет то, что сегмент ресурсов не всегда можно перенести с такой же легкостью безизменений, как другие сегменты. Так, например, рассмотрим процесс, содержащрш ссылку на конкретный порт TCP, посредством которого он взаимодействуетс другими (удаленными) процессами.
Эта ссылка находится в сегменте ресурсовпроцесса. При переносе процесса на другую машину процесс должен освободитьзанятый им порт и запросить другой — на той машине, на которую он был перемещен. В других случаях перенос ссылки проблем не создает. Например, ссылкана файл с использованием абсолютного URL-адреса останется верной независимо от того, на какой машине выполняется процесс, содержащий этот URL-адрес.Чтобы понять, какое влияние оказывает перенос кода на сегмент ресурсов,было выделено три типа связи процесса с ресурсами [156].
Наиболее сильнаясвязь наблюдается, когда процесс ссылается на ресурс по его идентификатору.В этом случае процесс требует в точности тот ресурс, на который ссылается. Примером подобной привязки по идентификатору {binding by identifier) являетсяиспользование процессом URL-адреса для ссылки на конкретный web-сайт илиИнтернет-адреса для ссылки на FTP-сервер. По этим же причинам ссылка на локальную конечную точку взаимодействия также будет считаться привязкой поидентификатору.Более слабая связь процесса с ресурсами будет иметь место в том случае, еслипроцессу необходимо только значение ресурса.
В этом случае выполненрге процесса ничуть не изменится, если такое же значение ему предоставит другой ресурс. Типичным примером привязки по зпачепию {binding by value) являются обращения программ к стандартным библиотекам, как при программировании наязыке С или Java. Эти библиотеки всегда доступны на локальной машине, но их3.4. Перенос кода195истинное местоположение в локальной файловой системе может быть различным. Для правильного выполнения процесса важны не конкретные имена файлов, а их содержимое.И, наконец, наиболее слабая форма связи имеет место в том случае, когдапроцесс указывает на необходимость использования ресурса определенного типа. Подобная привязка по типу {binding by type) может быть проиллюстрированассылками на локальные устройства, такие как принтеры, мониторы и т. п.При переносе кода мы часто нуждаемся в изменении ссылок на ресурсы, приэтом изменять тип привязки ресурса к процессу запрещено. Можно ли изменятьресурсы, и если да, то как, зависит от того, могут ли они быть перенесены на машину-приемник вместе с кодом.
Конкретнее, нам нужно определить связь ресурсов с машиной и рассмотреть варианты. Неприсоедипенные ресурсы {unattachedresources) могут быть с легкостью перенесены с машины на машину. Файлы(данных) в этом случае обычно связаны только с переносимой программой.В противоположность им, перенос или копирование связанных ресурсов {fastened resources) возможно лишь с относительно большими затратами. Типичнымипримерами связанных ресурсов могут быть локальные базы данных или webсайты целиком.
Несмотря на то что эти ресурсы теоретически не зависят от текущей машины, часто бывает невозможно перенести их в другую среду.И, наконец, фиксированные ресурсы {fixed resources) изначально привязанык конкретной машине или среде и не могут быть перенесены на другую. Фиксированными ресурсами часто бывают локальные устройства. Другой пример фиксированных ресурсов ~ локальные конечные точки взаимодействия.Скомбинировав три типа привязки ресурсов к процессам и три типа привязки ресурсов к машине, получим девять комбинаций, которые следует рассмотреть, обсуждая вопрос переноса кода.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
