Взаимодействие между клиентом и сервером в WWW

Содержание.

 

1.Обработчик прерываний в ОС с разделением времени. Промоделировать предлагаемое решение ……………………………………………………..3

2. Методы обнаружения тупика по наличию замкнутой цепочки запросов…………………………………………………………………………………6

3.Разработка и моделирование способов репликации (тиражирования) файлов……………………………………...……………………………………..9

4.Почтовые ящики………………………………………………..………10

5.Принцип параметрической настраиваемости………….….….……….14

 5.1 Понятие дистрибутива ОС………………………….…….………16

5.2 Генерация версий ОС…………………………………………….17

6.Взаимодействие между клиентом и сервером в WWW………………18

Список литературы………………………………………………...……..22

 

1. Обработчик прерываний в ОС с разделением времени. Промоделировать предлагаемое решение

 

При разработке первых систем ресурсами считались процессорное время, память, каналы ввода / вывода и периферийные устройства. Однако очень скоро понятие ресурса стало гораздо более универсальным и общим. Различного рода программные и информационные ресурсы также могут быть определены для системы как объекты, которые могут разделяться и распределяться и доступ к которым необходимо соответствующим образом контролировать. В настоящее время понятие ресурса превратилось в абстрактную структуру с целым рядом атрибутов, характеризующих способы доступа к этой структуре и её физическое представление в системе. Более того, помимо системных ресурсов, о которых мы сейчас говорили, как ресурс стали толковать и такие объекты, как сообщения и синхросигналы, которыми обмениваются задачи.

В первых вычислительных системах любая программа могла выполняться только после полного завершения предыдущей. Поскольку эти первые вычислительные системы были построены в соответствии с принципами, изложенными в известной работе Яноша Джон фон Неймана, все подсистемы и устройства компьютера управлялись исключительно центральным процессором. Центральный процессор осуществлял и выполнение вычислений, и управление операциями ввода / вывода данных. Соответственно, пока осуществлялся обмен данными между оперативной памятью и внешними устройствами, процессор не мог выполнять вычисления. Введение в состав вычислительной машины специальных контроллеров позволило совместить во времени (распараллелить) операции вывода полученных данных и последующие вычисления на центральном процессоре. Однако все равно процессор продолжал часто и долго простаивать, дожидаясь завершения очередной операции ввода / вывода. Поэтому было предложено организовать так называемый мультипрограммный (мультизадачный) режим работы вычислительной системы. Суть его заключается в том, что пока одна программа (один вычислительный процесс или задача, как мы теперь говорим) ожидает завершения очередной операции ввода / вывода, другая программа (а точнее, другая задача) может быть поставлена на решение.

При мультипрограммировании повышается пропускная способность системы, но отдельный процесс никогда не может быть выполнен быстрее, чем если бы он выполнялся в однопрограммном режиме (всякое разделение ресурсов замедляет работу одного из участников за счёт дополнительных затрат времени на ожидание освобождения ресурса).

Как мы уже отмечали, операционная система поддерживает мультипрограммирование (многопроцессность) и старается эффективно использовать ресурсы путём организации к ним очередей запросов, составляемых тем или иным способом. Это требование достигается поддерживанием в памяти более одного процесса, ожидающего процессор, и более одного процесса, готового использовать другие ресурсы, как только последние станут доступными. Общая схема выделения ресурсов такова. При необходимости использовать какой-либо ресурс (оперативную память, устройство ввода / вывода, массив данных и т.п.) задача обращается к супервизору операционной системы - её центральному управляющему модулю, который может состоять из нескольких модулей, например: супервизор ввода / вывода, супервизор прерываний, супервизор программ, диспетчер задач и т.д. - посредством специальных вызовов (команд, директив) и сообщает о своём требовании. При этом указывается вид ресурса и, если надо, его объём (например, количество адресуемых ячеек оперативной памяти, количество дорожек или секторов на системном диске, устройство печати и объём выводимых данных и т.п.).

Директива обращения к операционной системе передаёт ей управление, переводя процессор в привилегированный режим работы, если такой существует. Не все вычислительные комплексы имеют два (и более) режима работы: привилегированный (режим супервизора), пользовательский, режим эмуляции какого-нибудь другого компьютера и т.д.

Ресурс может быть выделен задаче, обратившейся к супервизору с соответствующим запросом, если:

1) он свободен и в системе нет запросов от задач более высокого приоритета к этому же ресурсу;

2) текущий запрос и ранее выданные запросы допускают совместное использование ресурсов;

3) ресурс используется задачей низшего приоритета и может быть временно отобран (разделяемый ресурс).

Получив запрос, операционная система либо удовлетворяет его и возвращает управление задаче, выдавшей данный запрос, либо, если ресурс занят, ставит задачу в очередь к ресурсу, переводя её в состояние ожидания (блокируя). Очередь к ресурсу может быть организована несколькими способами, но чаще всего это осуществляется с помощью списковой структуры.

После окончания работы с ресурсом задача опять с помощью специального вызова супервизора (посредством соответствующей директивы) сообщает операционной системе об отказе от ресурса, или операционная система забирает ресурс сама, если управление возвращается супервизору после выполнения какой-либо системной функции. Супервизор операционной системы, получив управление по этому обращению, освобождает ресурс и проверяет, имеется ли очередь к освободившемуся ресурсу. Если очередь есть - в зависимости от принятой дисциплины обслуживания (правила обслуживания) и приоритетов заявок он выводит из состояния ожидания задачу, ждущую ресурс, и переводит её в состояние готовности к выполнению. После этого управление либо передаётся данной задаче, либо возвращается той, которая только что освободила ресурс.

При выдаче запроса на ресурс задача может указать, хочет ли она владеть ресурсом монопольно или допускает совместное использование с другими задачами. Например, с файлом можно работать монопольно, а можно и совместно с другими задачами.

Если в системе имеется некоторая совокупность ресурсов, то управлять их использованием можно на основе определенной стратегии. Стратегия подразумевает четкую формулировку целей, следуя которым можно добиться эффективного распределения ресурсов.

При организации управления ресурсами всегда требуется принять решение о том, что в данной ситуации выгоднее: быстро обслуживать отдельные наиболее важные запросы, предоставлять всем процессам равные возможности либо обслуживать максимально возможное количество процессов и наиболее полно использовать ресурсы.

 

2. Методы обнаружения тупика по наличию замкнутой цепочки запросов.

Алгоритм был разработан сотрудниками фирмы IBM и использовался в одной из ОС этой компании. Он использует информацию о состоянии системы, содержащуюся в двух таблицах:  
1) RATBL - таблица текущего распределения (назначения) ресурсов; 
2) PWTBL - таблица заблокированных процессов (для каждого вида ресурса может быть свой список заблокированных процессов).  
При каждом запросе на получение или освобождении ресурсов содержимое этих таблиц модифицируется, а при запросе - анализируется в соответствии со следующим алгоритмом.

1.Запрос от процесса J на занятый ресурс I.

2 Поместить номер ресурса I в PWTBL в строке с номером процесса J.

3 Использовать I в качестве смещения в RATBL, чтобы найти номер процесса К, который владеет ресурсом. 
4.Использовать К в качестве смещения в PWTBL.

5.Проверить, ждет ли процесс К освобождения какого-либо ресурса I¢. Если нет, то перейти к шагу 6, в противном случае -- к шагу 7

6.Перевести J в состояние ожидания и выйти из алгоритма.

7. Использовать I¢ в качестве смещения в RATBL, чтобы найти номер блокирующего его процесса К'. 
8 .Проверить К' = J. Если нет, то перейти к шагу 9, в противном случае - к шагу 11. 
9. Проверить, вся ли таблица PWTBL просмотрена. Если да, то перейти к шагу 6, в противном случае - к шагу 10.

10.Присвоить К:= К' и перейти к шагу 4.

11. Сделать вывод о наличии тупика с последующим восстановлением.

Конец алгоритма. 
Пример 5.6. Рассмотрим следующую последовательность событий. 
1 Процесс Р2 занимает ресурс R1. 
2 Процесс Р3 занимает ресурс R2. 
3 Процесс Р3 занимает ресурс R3. 
4 Процесс Р1 занимает ресурс R4. 
Таблица распределения ресурсов (RATBL) будет иметь вид таблицы 5.2.

Таблица 5.2 - Таблица распределения ресурсов RATBL

Ресурсы	Процессы
1	2
2	3
3	3
4	1

Выполним алгоритм по шагам. 
1 Пусть процесс Р1 пытается занять ресурс R1, тогда J = 1, I = 1, К=2. Процесс К не ждет никакого ресурса I¢, поэтому процесс Р1 блокируется по ресурсу R1. 
2 Пусть процесс Р2 пытается занять ресурс R2, тогда J =2, I =2, К =3. 
3 Процесс К не ждет никакого ресурса, поэтому процесс Р2 блокируется по ресурсу R2. 
4 Теперь пусть процесс Р3 пытается обратиться к ресурсу R4. Тогда J=3, I = 4, К = 1, I¢ = 1, К¢= 2, К'<> J, поэтому берем К = 2, I¢ = 2, К¢ = 3. 
В этом случае К' = J, то есть тупик определен. Таблица заблокированных процессов (PWTBL) теперь имеет вид таблицы 5.3.

Таблица 5.3 - Таблица заблокированных процессов PWTBL

Процесс	Ресурс
1	1
2	2
3	4

Равенство J = К' означает, что существует замкнутая цепь взаимоисключающих и ожидающих процессов, то есть выполняются все четыре условия существования тупика. 
Модель Холта для описанного примера приведена на рисунке 5.7. На рисунке пронумерованы дуги запросов, которые процессы последовательно генерировали в соответствии с примером. Из рисунка сразу видно, что в результате такой последовательности запросов образовалась замкнутая цепочка: (5, 1, 6, 2, 7, 4), что и говорит о существовании тупика. 
                                

Рисунок 5.7 - Граф распределения ресурсов

 

3. Разработка и моделирование способов репликации (тиражирования) файлов

 

Распределенные системы часто обеспечивают репликацию (тиражирование) файлов в качестве одной из услуг, предоставляемых клиентам. Репликация - это асинхронный перенос изменений данных исходной файловой системы в файловые системы, принадлежащие различным узлам распределенной файловой системы. Другими словами, система оперирует несколькими копиями файлов, причем каждая копия находится на отдельном файловом сервере. Имеется несколько причин для предоставления этого сервиса, главными из которых являются:

1) увеличение надежности за счет наличия независимых копий каждого файла на разных файл-серверах;

2) распределение нагрузки между несколькими серверами.

Как обычно, ключевым вопросом, связанным с репликацией является прозрачность. До какой степени пользователи должны быть в курсе того, что некоторые файлы реплицируются? Должны ли они играть какую-либо роль в процессе репликации или репликация должна выполняться полностью автоматически? В одних системах пользователи полностью вовлечены в этот процесс, в других система все делает без их ведома. В последнем случае говорят, что система репликационно прозрачна.

При использовании первого способа (а) программист сам управляет всем процессом репликации. Когда процесс создает файл, он делает это на одном определенном сервере. Затем, если пожелает, он может сделать дополнительные копии на других серверах. Если сервер каталогов разрешает сделать несколько копий файла, то сетевые адреса всех копий могут быть ассоциированы с именем файла, как показано на рисунке снизу, и когда имя найдено, это означает, что найдены все копии. Чтобы сделать концепцию репликации более понятной, рассмотрим, как может быть реализована репликация в системах, основанных на удаленном монтировании, типа UNIX. Предположим, что рабочий каталог программиста имеет имя /machine1/usr/ast. После создания файла, например, /machine1/usr/ast/xyz, программист, процесс или библиотека могут использовать команду копирования для того, чтобы сделать копии /machine2/usr/ast/xyz и machine3/usr/ast/xyz. Возможно программа использует в качестве аргумента строку /usr/ast/xyz и последовательно попытается открывать копии, пока не достигнет успеха. Эта схема хотя и работает, но имеет много недостатков, и по этим причинам ее не стоит использовать в распределенных системах.

 

4. Почтовые ящики

 

Тесное взаимодействие между процессами предполагает не только синхронизацию - обмен временными сигналами, но также передачу и получение произвольных данных, то есть обмен сообщениями. В системе с одним процессором посылающий и получающий процессы не могут работать одновременно. В мультипроцессорных системах также нет никакой гарантии их одновременного исполнения. Следовательно, для хранения посланного, но еще не полученного сообщения необходимо место. Оно называется буфером сообщений, или почтовым ящиком.

Если процесс Р1 хочет общаться с процессом Р2, то Р1 просит систему предоставить или образовать почтовый ящик, который свяжет эти два процесса так, чтобы они могли передавать друг другу сообщения. Для того чтобы послать процессу Р2 какое-то сообщение, процесс Р1 просто помещает это сообщение в почтовый ящик, откуда процесс Р2 может его в любое время получить. При применении почтового ящика процесс Р2 в конце концов обязательно получит сообщение, когда обратится за ним (если вообще обратится). Естественно, что процесс Р2 должен знать о существовании почтового ящика. Поскольку в системе может быть много почтовых ящиков, необходимо обеспечить доступ процессу к конкретному почтовому ящику. Почтовые ящики являются системными объектами, и для пользования таким объектом необходимо получить его у операционной системы, что осуществляется с помощью соответствующих запросов.