Файл: Учебнометодическое пособие Томск 2016 2 удк 004. 451(075. 8) Ббк 32. 973. 2018. 2я73 к 754 Рецензенты.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 07.11.2023
Просмотров: 354
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
128 сообщений сервера к клиенту, который, таким образом, не заметит замену мо- дели ОС.
Другое принципиальное отличие ядра UNIX от некоторых других ОС со- стоит в том, что ядро разделяется внешними параллельными процессами по- следовательно. То есть до тех пор, пока ядро занято обслуживанием какого-то конкретного процесса и это обслуживание не завершится, оно не начнет обслу- живание никакого другого процесса. При этом на время системного обслужи- вания программа ядра «подсоединяется» к прикладной программе процесса, не образуя никакого нового процесса ядра. Реализация такого подхода обеспе- чивает целостность системных данных ядра.
Заметим, что ядро UNIX имеет несколько своих внутренних процессов ядра, но эти процессы выполняют общесистемные функции, не принимая непо- средственного участия в выполнении системных вызовов. Для сравнения в Windows-NT основное системное обслуживание прикладных процессов вы- полняют процессы ядра, которые, таким образом, являются серверами. Подоб- ная видоизмененная модель «клиент-сервер» требует меньше переключений
ЦП из одного режима в другой по сравнению с классической моделью «клиент- сервер».
Модель «клиент-сервер» применяется не только для организации опера- ционных систем, но и для реализации распределенных прикладных программ.
Примером такой распределенной программы является программа rlogin
(см. п. 4.1). Для выполнения распределенных программ требуется помощь со стороны ОС, которая для этого должна быть сетевой. Рассмотренная выше общая структура ОС может быть использована и для реализации сетевой опе- рационной системы.
1 ... 8 9 10 11 12 13 14 15 ... 23
4.4 Структура сетевой операционной системы
Краткое определение:
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Сеть передачи данных – совокупность ЭВМ, связанных ка-
налами передачи данных.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
В общем случае такая сеть нужна для того, чтобы прикладная программа, выполняющаяся на одной ЭВМ, могла использовать ресурсы (аппаратные, про- граммные и информационные) другой ЭВМ. При этом под прикладными про- граммами будем понимать не только собственно прикладные программы, но и
129 системные обрабатывающие программы, например утилиты (вспомним, что ОС не отличает системные обрабатывающие программы от обычных прикладных программ).
Любое сетевое взаимодействие предполагает участие двух удаленных друг от друга программ: клиентской и серверной. Клиентская программа дела- ет запрос на получение удаленного ресурса, а серверная программа выполняет получение и использование запрашиваемого ресурса. Далее будем называть
ЭВМ, содержащую клиентскую программу, узлом-клиентом, а ЭВМ, содержа- щую серверную программу, узлом-сервером. В состав любого из этих узлов входит сетевая операционная система, которая может рассматриваться как расширение обычной локальной ОС.
Прикладные программы, выполняемые в сети, можно разделить на ло- кальные и распределенные. Распределенные программы разрабатываются спе- циально для выполнения в сети. Примером такой программы является рассмот- ренная в п. 4.1 программа rlogin. Другими примерами являются распределенные СУБД, а также сетевые игры. Каждая такая программа содер- жит серверную часть и одну или несколько клиентских частей, расположенных в различных узлах сети. В отличие от локальной реализации модели «клиент- сервер» удаленные модули распределенной программы находятся на разных
ЭВМ, и, следовательно, для передачи информации между ними не могут ис- пользоваться общие области ОП. Единственным способом информационного обмена между ними является использование информационного канала, выпол- няющего передачу сообщений (см. п. 3.5).
Так как клиентская и серверная части распределенной программы выпол- няют общую работу, то эти два модуля должны «общаться» на понятном им обоим языке. Иными словами, они должны выполняться согласно общему ал- горитму взаимодействия. Вспомним, что алгоритм взаимодействия двух сосед- них модулей называется интерфейсом. Так как удаленные клиент и сервер не имеют общей границы, то понятие интерфейса между ними не имеет смысла.
Это понятие заменяется понятием протокола.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Протокол – алгоритм взаимодействия модулей, удаленных
друг от друга.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Протокол взаимодействия клиентской и серверной частей распределен- ной программы будем называть далее прикладным протоколом. Подобно ин-
130 терфейсу, протокол имеет статическую и динамическую части. Статика про-
токола описывает состав и структуру информационных конструкций, которы- ми могут обмениваться партнеры по диалогу. Динамика протокола регламен- тирует порядок выдачи этих конструкций относительно друг друга и, возможно, во времени. В зависимости от реализации прикладного протокола в распределенной программе существуют два основных подхода к разработке таких программ.
В первом из подходов статика и динамика прикладного протокола рас- пределенной программы реализуются ее разработчиками без использования ка- кой-то особой помощи со стороны системных программ. Единственная допол- нительная помощь, которая требуется при выполнении распределенной программы от сетевых ОС, – предоставление ей информационного канала, вы- полняющего передачу удаленных сообщений. Допустим, что такой канал предоставляет модуль ОС – транспорт сообщений (рис. 4.4). Реализация дан- ного модуля выходит за рамки данного курса, и для нас важен лишь тот факт, что модуль транспорта обеспечивает передачу сообщения требуемому удален- ному программному процессу.
Рис. 4.4 Выполнение распределенной программы в сети
131
Второй подход к реализации распределенной программы называется уда-
ленным вызовом процедур – RPC (remote procedure call). В этом подходе при- кладная программа освобождена от выполнения прикладного протокола за счет того, что клиентская часть программы выполняет нужные ей подпрограммы серверной части, используя обычные локальные вызовы процедур с помощью команды call. Это не означает, что прикладной протокол теперь вовсе не ну- жен. Просто этот протокол выносится за пределы прикладной программы и вы- полняется вызываемыми ею системными подпрограммами (рис. 4.5).
Рис. 4.5 Распределенная программа с удаленным вызовом процедур
При проектировании распределенной программы производится распреде- ление ее подпрограмм между клиентом и сервером. Все процедуры сервера, ко-
132 торые могут потребоваться клиенту, нумеруются, и для каждой из них создают- ся две процедуры-«заглушки», одна из которых подсоединяется к программе- клиенту, а другая – к серверу. Такое связывание выполняется или статически, или динамически. В первом случае «заглушка» является модулем обычной биб- лиотеки, а во втором – модулем DLL.
Допустим, что в программе-клиенте требуется вызвать какую-то удален- ную процедуру, принадлежащую программе-серверу. Тогда клиент вызывает свою локальную процедуру-«заглушку», имеющую точно такой же интерфейс
(имя процедуры и состав параметров), как и настоящая удаленная процедура.
Далее «заглушка» представляет полученные ею параметры в стандартном виде и передает их, а также свой номер в системную процедуру, ответственную за реализацию прикладного протокола. Эта процедура определяет сетевой адрес серверной части прикладной программы и отправляет по этому адресу сообще- ние (с помощью модуля транспорта), содержащее номер требуемой процедуры сервера и значения ее входных параметров.
В узле-сервере модуль транспорта передает полученное сообщение про- цедуре, ответственной за реализацию прикладного протокола, которая по номе- ру процедуры сервера определяет требуемую «заглушку» и инициирует ее. Да- лее «заглушка» преобразует полученные параметры в обычный формат и вызывает по имени (с помощью команды call) настоящую процедуру сервера.
Когда эта процедура завершится, «заглушка» получит ее выходные параметры и передаст их в процедуру, ответственную за прикладной протокол, для пере- дачи в узел клиента.
В узле клиента полученные выходные параметры поступают в «заглуш- ку», которая, возвращая управление в программу-клиент (с помощью машин- ной команды ret), одновременно передает в нее и эти параметры. В результате программа-клиент имеет дело только со своей локальной заглушкой, не замечая все действия по взаимодействию с сервером. Несмотря на то что процедуры, ответственные за прикладной протокол, являются системными, они не являют- ся частью ОС, а подсоединяются к частям прикладной программы (клиенту и серверу) как модули DLL.
Новые модули должны быть включены в сетевую ОС в том случае, когда она обслуживает локальные (нераспределенные) прикладные программы. Рас- смотрим несколько примеров таких прикладных программ и используемых ими удаленных ресурсов:
133 1) допустим, что пользователя интересует содержимое магнитного дис- ка, принадлежащего удаленной ЭВМ. В этом случае в качестве при- кладной программы можно рассматривать утилиту ls (в UNIX) или dir (в MS-DOS), а в качестве удаленного информационного ресурса – содержимое корневого каталога соответствующего магнитного диска;
2) если пользователь хочет распечатать содержимое своего текстового файла на принтере, связанном с удаленной ЭВМ, то в качестве при- кладной программы выступает утилита печати, а в качестве удаленно- го аппаратного ресурса – принтер;
3) пусть пользователь хочет вывести текстовое сообщение на экран, принадлежащий другой ЭВМ. В этом случае в качестве прикладной программы можно рассматривать простую утилиту, выполняющую перенос символьной строки с клавиатуры на экран. При этом экран является удаленным аппаратным ресурсом.
Во всех приведенных примерах прикладная программа представляет со- бой обычную локальную программу, не предназначенную для сетевого исполь- зования. Кроме того, каждой локальной программе требуется выполнить какие- то операции с удаленным файлом (устройство ввода-вывода – тоже файл). Для того чтобы подобная локальная программа могла получить доступ к удаленной файловой системе, сетевая ОС должна содержать модули, обеспечивающие взаимодействие между ними. В зависимости от того, как реализованы эти мо- дули, будем различать два способа реализации сетевой ОС. В первом из этих способов оба модуля, обеспечивающие сетевое взаимодействие, входят в состав ядра ОС. Так как в данном методе учитываются особенности реализации фай- ловой системы, то он будет рассмотрен позже в п. 7.3.
Другой способ реализации сетевой ОС предполагает, что по крайней мере один из взаимодействующих системных модулей находится вне ядра своей ОС.
При этом в качестве такого модуля в узле-клиенте используется управляющая подпрограмма – редиректор, а в узле-сервере – процесс-сервер (рис. 4.6).
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Редиректор – подпрограмма сетевой ОС, выполняющая об-
работку тех системных вызовов из прикладных программ, которые
требуют выполнения операций с файлами (в том числе и с устрой-
ствами ввода-вывода).
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
134
Рис. 4.6 Сетевое обслуживание локальной прикладной программы
Если файл, упомянутый в данном вызове, является локальным (находится в том же узле), то системный вызов направляется для выполнения в свою ло- кальную ОС. Если требуемый файл находится в каком-то другом узле сети, то редиректор посылает в этот узел сообщение для сервера файловой системы с просьбой выполнить требуемую операцию.
Реализация редиректора зависит от типа локальной ОС. Например, в сре- де MS-DOS редиректор может быть реализован в виде резидентной программы, перехватывающей системные вызовы (программные прерывания), предназна- ченные для инициирования файловой подсистемы. Если локальной ОС является
UNIX, то редиректор может быть реализован как подпрограмма ядра, запускае- мая из интерфейса системных вызовов при поступлении запроса на работу с файлами. При этом, как и другие подпрограммы ядра, редиректор подсоеди- няется к программе процесса, выдавшего системный вызов.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Сервер файловой системы – процесс (демон), предназначен-
ный для выполнения удаленных системных вызовов.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Этот процесс инициируется при поступлении сообщения от какого-то удаленного редиректора. Так как правомочность операций с файлами зависит
135 от имени пользователя, то это имя является предметом обсуждения между ре- директором и сервером ФС. Именно от этого имени сервер будет выдавать си- стемные вызовы для файловой подсистемы своей локальной ОС. Полученные результаты в виде сообщений будут пересылаться редиректору.
Редиректор и сервер «беседуют» друг с другом в соответствии с некото- рым прикладным протоколом. Это может показаться странным, так как обе эти программы являются системными, а редиректор даже принадлежит ядру. При- чина этого заключается в том, что в данном случае термин «прикладной» озна- чает «несетевой», а это означает неучастие данного протокола в транспорти- ровке информации по сети.
В рассмотренной выше схеме предполагалось, что конкретная ЭВМ явля- ется или узлом-сервером, или узлом-клиентом, участвующим в реализации од- ной из трех схем взаимодействия удаленных программных процессов. В дей- ствительности, один и тот же узел может выполнять функции и клиента, и сервера, одновременно выполняя обслуживание «чужих» прикладных про- грамм и обращаясь в сеть с целью обслуживания «своих» программ. При этом различные клиенты и серверы в данном узле могут использовать разные схемы сетевого взаимодействия.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Контрольные вопросы по главе 4
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
1. Какие из перечисленных программ и подпрограмм выполняются только в привилегированном режиме работы? а. Ядро ОС. б. Файловая система. в. Подсистема управления процессами. г. Подсистема управления памятью. д. Интерфейс системных вызовов. е. Подсистема ввода/вывода. ж. Виртуальная файловая система. з. Диспетчер ЦП.
2. Зачем нужна процедура «заглушка»?
3. Приведите схему удаленного доступа пользователя к системе UNIX.
4. В чем особенность микроядра?