ОСиС_2008

Рис. 63. Логическая схема блочного драйвера с ПДП:

u — указатель на дескриптор буфера блока; A — реальный адрес буфера блока; v — тип операции (0 — чтение, 1 — запись);

n — число читаемых (записываемых) байтов

Интересно отметить взаимосвязь между критерием эффективности работы драйвера и критерием производительности реальной ФС (см. п. 6.2.1). Организация информации на носителе в соответствии с требованием производительности реальной ФС лишь создает предпосылки для повышения фактической средней скорости информационного обмена между носителем ВП и ОП. Действительное увеличение данной скорости произойдет только

втом случае, если драйвер обеспечивает эффективность этого обмена.

Выбрав очередной элемент из очереди, процедура «Чтениезапись блока» вызывает процедуру «Подготовка ПДП», входящую

всостав драйвера ПДП, передав ей на вход параметры:

1)A — реальный адрес буфера блока. Для расчета данного адреса процедура «Чтение-запись блока» использует одно из полей дескриптора буфера блока, содержащее линейный виртуальный адрес Ab. Сам расчет производится так, как это делает ЦП. Отли-

чие состоит в том, что расчет реального адреса выполняется не аппаратно, а программно;

2)v — тип операции (0 — чтение, 1 — запись);

3)n — число читаемых (записываемых) байтов.

Целью применения прямого доступа в память (ПДП) явля-

ется существенное снижение затрат времени ЦП на обслуживание информационного обмена между устройством ВП и ОП за счет того, что ЦП не отвлекается для передачи каждого байта, а обрабатывает лишь завершение передачи всего блока. Для реализации данного метода синхронизации требуется наличие специального контроллера ПДП. В процессе ввода-вывода с использованием ПДП обмен байтами данных между ИУ и ОП производится не через регистр RD и регистры ЦП, а через этот контроллер. При этом роль ЦП ограничивается выдачей разрешений на занятие ОШ (а точнее — шины данных). Обычно контроллер ПДП рассчитан на одновременное обслуживание нескольких ИУ, каждое из которых подключается к нему набором проводников. Часть контроллера ПДП, предназначенная для обслуживания одного ИУ, называется каналом ПДП. В соответствии с классификацией информационных каналов из подразд. 2.5 канал ПДП представляет собой устойчивый

полудуплексный моноканал, предназначенный для передачи потока данных.

На рис. 63 приведена упрощенная логическая схема контроллера ПДП, согласно которой он представляет собой совокупность параллельных логических процессов (каналов ПДП) и имеет всего один регистр состояния и управления RS2. В нерабочем состоянии канал ПДП ожидает записи инициирующего значения в регистр RS2, находясь в состоянии «Вход 1». Процедура «Подготовка ПДП» не только помещает это значение в RS2, но и записывает в этот регистр те параметры A, v, n, которые были переданы ей при вызове. Считав эти параметры, канал ПДП переходит в состояние «Вход 2», ожидая поступления команды от контроллера дисковода начать передачу информации.

Передав содержимое некоторых полей дескриптора буфера блока в процедуру «Подготовка ПДП», процедура «Чтение-запись блока» помещает преобразованное содержимое некоторых других полей этого дескриптора в регистр RS1:

1)номер однотипного устройства, обслуживаемого данным контроллером (и драйвером) дисковода. Данный номер получается дешифрацией младшего номера устройства;

2)физический адрес сектора на устройстве (номер цилиндра; номер поверхности; номер сектора). Для получения этих параметров процедура «Чтение-запись блока» использует поле дескриптора, содержащее порядковый номер сектора на диске;

3)тип операции (чтение или запись).

Так как контроллер дисковода обслуживает подключенные к нему дисководы только последовательно, то он изображен на логической схеме в виде одного логического процесса. Находясь в состоянии своего входа, этот логический процесс ожидает записи инициирующего значения в свой регистр состояния и управления RS1. После того как процедура «Чтение-запись блока» запишет в RS1 перечисленные выше значения, контроллер дисковода начинает работу по записи или чтению требуемого сектора диска. Для этого он сначала передает команду требуемому дисководу, а затем инициирует подключенный к нему канал ПДП. После этого между двумя контроллерами начинается побайтовый обмен данными, считываемыми с диска или записываемыми на него.

По завершении передачи сектора диска контроллер дисковода выдает в ЦП сигнал прерывания. Обработчик этого прерывания, входящий в состав драйвера дисковода, выполняет деблокирование

процесса, ожидающего в состоянии «Сон» завершения операции чтения или записи дискового блока. После этого управление передается диспетчеру процессов, который или передает управление разбуженному процессу, или помещает его в список готовности.

8. ПРИКЛАДНОЙ УРОВЕНЬ СЕТИ

8.1. Общая структура сетевого приложения

Прикладной уровень сети образуют сетевые приложения — распределенные обрабатывающие программы. Каждая распределенная программа одновременно выполняется на нескольких ЭВМ, являющихся конечными узлами сети, называемыми хостами. Кроме хостов сеть обычно имеет внутренние узлы, обеспечивающие транспортировку информации между хостами. Так как внутренние узлы сети «не видны» из сетевых приложений, то мы их рассмотрим в другом разделе. Напомним, что распределенная программа обязательно имеет серверную часть и одну или несколько клиентских частей. При этом каждая из этих частей выполняется на своем хосте.

На рис. 64 приведена укрупненная структура распределенной программы, имеющей одну серверную и две клиентские части. В свою очередь, клиентская часть сама состоит из двух частей — интерфейсной и протокольной. При этом функцией протокольной части является обмен данными с удаленным сервером, имеющим для этого свою протокольную часть. Обе протокольные части взаимодействуют друг с другом согласно общему прикладному протоколу. Интерфейсная часть клиента обеспечивает его взаимодействие со своим пользователем, выполняя несетевую обработку команд пользователя и представляя для него на экране результирующую информацию клиента. Иными словами, интерфейсная часть клиента предоставляет в распоряжение пользователя пользовательский интерфейс.

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

Например, для рассмотренной в подразд. 3.1 распределенной программы rlogin, обеспечивающей доступ удаленного пользователя в UNIX-систему, протокольную часть серверной части содержит rlogin-сервер. А роль подсистемы управления данными выполняет псевдотерминал. Что касается самих этих данных, то это множество файлов в UNIX-системе, доступных по правам доступа

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

Пользовательский

интерфейс

Сеть передачи данных

Рис. 64. Распределенная программа из трех частей

Протокольные части клиента и сервера «беседуют» друг с другом, используя для передачи своих сообщений модули транспорта сообщений, входящие в состав ОС. Благодаря этому взаимодействующие процессы имеют в своем распоряжении транспортный информационный канал. Непосредственное взаимодействие протокольной части клиента (или сервера) со своим модулем транспорта производится по правилам транспортного интерфейса (см. рис. 64). Так как при разработке любого сетевого приложения обязательно решаются вопросы выбора транспортного информационного канала и транспортного интерфейса, необходимо остановиться на этих вопросах более подробно.

8.2. Выбор транспортного информационного канала

В отличие от локальных информационных каналов, рассмотренных ранее, транспортный канал является протяженным информационным каналом, так как соединяет программные процессы, удаленные в пространстве. Для характеристики протяженных информационных каналов могут использоваться признаки, приведенные в подразд. 2.5 для локальных информационных каналов:

1)направление передачи данных. Информационные каналы делятся на симплексные, полудуплексные и дуплексные;

2)устойчивость информационного канала. Различают вир-

туальные соединения (устойчивые каналы) и датаграммные каналы (неустойчивые каналы);

3)структурированность передаваемых данных. Различают информационные каналы, передающие потоки данных и передающие сообщения;

4)параллельность передаваемых данных. Различают монока-

налы и мультиплексные каналы.

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

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

1)достоверность передачи данных — вероятность искажения или потери единицы информации, передаваемой по каналу. В качестве единицы информации для транспортного канала целесообразно брать сообщение. Некоторые приложения отличают искажение сообщения от его потери, так как имеют возможность восстанавливать первоначальное содержимое сообщения, используя избыточные данные. В общем случае такое различие нецелесообразно;

2)порядок приема информации. По этому признаку тран-

спортные каналы делятся на каналы, которые обеспечивают пра-

вильный порядок приема информации, и такие, которые этот порядок не обеспечивают;

3)задержка — время (в секундах) между началом передачи сообщения по каналу и моментом завершения приема этого сообщения;

4)скорость передачи информации в канал — предельное число единиц информации, гарантированно передаваемых в канал

втечение одной секунды. В качестве единицы информации при этом используется 1 кбит или 1 Мбит. Термин «гарантированно» вовсе не означает, что переданная информация успешно достигнет удаленного конца канала. Это лишь говорит о том, что канал примет эту информацию для передачи.

Рассмотрим перечисленные характеристики протяженного информационного канала более внимательно. Во-первых, заметим, что обеспечить достаточно высокую достоверность передачи данных можно двумя путями: а) благодаря использованию для связи между хостами высококачественной сети передачи данных; б) путем выполнения повторных передач данных в случае их потерь и искажений. Первый из этих путей обусловлен тем, что транспортный канал физически «прокладывается», используя линии связи и внутренние узлы сети, соединяющие эти линии. В том случае если используются линии связи с высокой надежностью передачи данных, а внутренние узлы сети не перегружаются поступающими в них данными, и поэтому эти данные не отбрасывают, то достоверность передачи сообщений по транспортному каналу будет достаточно высока. В действительности лишь близко расположенные хосты соединяются (и то далеко не всегда) высококачественными сетями передачи данных. Что касается больших сетей, наибольшая из которых — Internet, то они не обеспечивают высокую достоверность передачи данных без использования повторных передач.

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

1)в передающем хосте приложение создает копию сообщения, отправляемого по транспортному каналу. Кроме того, сообщение снабжается порядковым номером, а также вспомогательной кодовой последовательностью, полученной в результате некоторой обработки сообщения. Все это вместе с сообщением передается по транспортному каналу;

2)в приемном хосте проверяется факт получения сообщения (по порядковому номеру) и проверяется его правильность (по соответствию сообщения и его кодовой последовательности). В зависимости от результатов проверки в обратном направлении посылается или служебное сообщение, подтверждающее успешный прием — положительная квитанция, или сообщение об ошибке — отрицательная квитанция. В конкретном прикладном протоколе, как правило, используется лишь один тип квитанций;

3)при получении отрицательной квитанции или длительном неполучении положительной квитанции передающий прикладной процесс повторяет передачу сообщения.

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

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

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

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

Перечисленные критерии оценки транспортных каналов используются для выбора того канала, который наиболее удовлет-

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

(Transmission Control Protocol — протокол управления передачей)

и UDP (User Datagram Protocol — протокол пользовательских датаграмм). Первый из этих протоколов предназначен для организации транспортных информационных каналов в виде виртуальных соединений, а второй — в виде датаграммных каналов.

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

Транспортный канал на основе протокола UDP является датаграммным каналом и не обеспечивает поэтому для приложения ни хорошую достоверность передаваемых сообщенийдатаграмм, ни правильный порядок их приема. Первое обусловлено тем, что в случае потери датаграммы внутри сети или на приемном хосте никто внутри транспортного канала не занимается повторной передачей этой датаграммы. Второе свойство обусловлено тем, что транспортный канал на основе UDP не занимается «сортировкой» принимаемых датаграмм по времени их отправления, а просто передает их приложению по мере их получения из сети.

Характеристики — задержка и скорость передачи информации в канал — для датаграммного канала на основе протокола UDP существенно лучше, чем для виртуального соединения на основе протокола TCP. Это объясняется тем, что датаграммный транспортный канал не занимается ни повторной передачей сообщений-датаграмм, ни «торможением» их приема от приложения в передающем хосте. Поэтому передающая часть приложения направляет свои сообщения в транспортный канал с достаточно