3.5. Устройства сетей Ethernet

Повторители

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

Рис. 3.8

Также в следующий сегмент передаётся состояние коллизии. Никакого изменения или анализа поступающих данных не производится. Задержка сигнала повторителем не должна превышать 7,5 битовых интервалов.

Хабы

Сетевой концентратор или хаб (англ. hub) - это многопортовый повторитель.

Битовые импульсы, поступающие на порт хаба, хаб восстанавливает и передаёт на все остальные порты. Также хаб передаёт на все свои порты состояние коллизии. Физические сегменты, объединённые при помощи хабов и повторителей, являются разделяемой средой передачи данных. Сеть, построенная только на хабах и повторителях, является одним большим доменом коллизий с присущими ему недостатками. Современные сети Ethernet строятся преимущественно на коммутаторах.

Мосты. Алгоритм работы моста

Мост (bridge) является устройством канального уровня, т.е. “понимает” формат фреймов. Мост используется для объединения двух сегментов сети. Во включённом состоянии мост формирует таблицу MAC-адресов (рис.3.9), каждая запись которой содержит MAC-адрес и номер порта моста, через который должен быть отправлен фрейм, чтобы он попал на компьютер с данным MAC-адресом. Таблица MAC-адресов формируется на основе изучения поля “адрес отправителя”, содержащегося в заголовках фреймов, поступающих на порты моста. Например, если компьютер A отправит фрейм, то мост принимает этот фрейм на порт 1 и заносит в таблицу MAC-адресов информацию о том, что для отправки фрейма на компьютер А его нужно передать через порт 1.

Рис. 3.9

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

Коммутаторы

Коммутатор (англ. switch) можно рассматривать как многопортовый мост. Коммутатор формирует таблицу MAC-адресов, на основании которой принимает решение о перенаправлении фрейма (рис.3.10.).

Рис. 3.10

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

Коммутатор – сложное устройство. Для обеспечения более тонкой настройки производятся т.н. интеллектуальные (managable) коммутаторы, параметры настройки которых можно программно изменять.

Возникновение коллизий.

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

Коллизия - это нормальная ситуация в работе сетей Ethernet. В примере, изображенном на рис. 3.4, коллизию породила одновременная передача данных узлами 3 и У. Для возникновения коллизии не обязательно, чтобы несколько станций начали передачу абсолютно одновременно, такая ситуация маловероятна. Гораздо вероятней, что коллизия возникает из-за того, что один узел начинает передачу раньше другого, но до второго узла сигналы первого просто не успевают дойти к тому времени, когда второй узел решает начать передачу своего кадра. То есть коллизии - это следствие распределенного характера сети.

Чтобы корректно обработать коллизию, все станции одновременно наблюдают за возникающими на кабеле сигналами. Если передаваемые и наблюдаемые сигналы отличаются, то фиксируется обнаружение коллизии (collision detection, CD). Для увеличения вероятности скорейшего обнаружения коллизии всеми станциями сети станция, которая обнаружила коллизию, прерывает передачу своего кадра (в произвольном месте, возможно, и не на границе байта) и усиливает ситуацию коллизии посылкой в сеть специальной последовательности из 32 бит, называемой jam-последовательностью.

Рис. 3.4. Схема возникновения и распространения коллизии

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

Пауза = L *(интервал отсрочки),

где интервал отсрочки равен 512 битовым интервалам (в технологии Ethernet принято все интервалы измерять в битовых интервалах; битовый интервал обозначается как bt и соответствует времени между появлением двух последовательных бит данных на кабеле; для скорости 10 Мбит/с величина битового интервала равна 0,1 мкс или 100 нс);

L представляет собой целое число, выбранное с равной вероятностью из диапазона [0, 2^N ], где N - номер повторной попытки передачи данного кадра: 1,2,..., 10.

После 10-й попытки интервал, из которого выбирается пауза, не увеличивается. Таким образом, случайная пауза может принимать значения от 0 до 52,4 мс.

Если 16 последовательных попыток передачи кадра вызывают коллизию, то передатчик должен прекратить попытки и отбросить этот кадр.

Из описания метода доступа видно, что он носит вероятностный характер, и вероятность успешного получения в свое распоряжение общей среды зависит от загруженности сети, то есть от интенсивности возникновения в станциях потребности в передаче кадров. При разработке этого метода в конце 70-х годов предполагалось, что скорость передачи данных в 10 Мбит/с очень высока по сравнению с потребностями компьютеров во взаимном обмене данными, поэтому загрузка сети будет всегда небольшой. Это предположение остается иногда справедливым и по сей день, однако уже появились приложения, работающие в реальном масштабе времени с мультимедийной информацией, которые очень загружают сегменты Ethernet. При этом коллизии возникают гораздо чаще. При значительной интенсивности коллизий полезная пропускная способность сети Ethernet резко падает, так как сеть почти постоянно занята повторными попытками передачи кадров. Для уменьшения интенсивности возникновения коллизий нужно либо уменьшить трафик, сократив, например, количество узлов в сегменте или заменив приложения, либо повысить скорость протокола, например перейти на Fast Ethernet.

Следует отметить, что метод доступа CSMA/CD вообще не гарантирует станции, что она когда-либо сможет получить доступ к среде. Конечно, при небольшой загрузке сети вероятность такого события невелика, но при коэффициенте использования сети, приближающемся к 1, такое событие становится очень вероятным. Этот недостаток метода случайного доступа - плата за его чрезвычайную простоту, которая сделала технологию Ethernet самой недорогой. Другие методы доступа - маркерный доступ сетей Token Ring и FDDI, метод Demand Priority сетей 100VG-AnyLAN - свободны от этого недостатка.

Время двойного оборота и распознавание коллизий.

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

Для надежного распознавания коллизий должно выполняться следующее соотношение:

T_min >=PDV,

где Т_min - время передачи кадра минимальной длины, a PDV - время, за которое сигнал коллизии успевает распространиться до самого дальнего узла сети. Так как в худшем случае сигнал должен пройти дважды между наиболее удаленными друг от друга станциями сети (в одну сторону проходит неискаженный сигнал, а на обратном пути распространяется уже искаженный коллизией сигнал), то это время называется временем двойного оборота (Path Delay Value, PDV).

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

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

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

В стандарте Ethernet принято, что минимальная длина поля данных кадра составляет 46 байт (что вместе со служебными полями дает минимальную длину кадра 64 байт, а вместе с преамбулой - 72 байт или 576 бит). Отсюда может быть определено ограничение на расстояние между станциями.

Итак, в 10-мегабитном Ethernet время передачи кадра минимальной длины равно 575 битовых интервалов, следовательно, время двойного оборота должно быть меньше 57,5 мкс. Расстояние, которое сигнал может пройти за это время, зависит от типа кабеля и для толстого коаксиального кабеля равно примерно 13 280 м. Учитывая, что за это время сигнал должен пройти по линии связи дважды, расстояние между двумя узлами не должно быть больше 6 635 м. В стандарте величина этого расстояния выбрана существенно меньше, с учетом других, более строгих ограничений.

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

Повторители увеличивают мощность передаваемых с сегмента на сегмент сигналов, в результате затухание сигналов уменьшается и можно использовать сеть гораздо большей длины, состоящую из нескольких сегментов. В коаксиальных реализациях Ethernet разработчики ограничили максимальное количество сегментов в сети пятью, что в свою очередь ограничивает общую длину сети 2500 метрами. Даже в такой многосегментной сети условие обнаружения коллизий по-прежнему выполняется с большим запасом (сравним полученное из условия допустимого затухания расстояние в 2500 м с вычисленным выше максимально возможным по времени распространения сигнала расстоянием 6635 м). Однако в действительности временной запас является существенно меньше, поскольку в многосегментных сетях сами повторители вносят в распространение сигнала дополнительную задержку в несколько десятков битовых интервалов. Естественно, небольшой запас был сделан также для компенсации отклонений параметров кабеля и повторителей.

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

С увеличением скорости передачи кадров, что имеет место в новых стандартах, базирующихся на том же методе доступа CSMA/CD, например Fast Ethernet, максимальное расстояние между станциями сети уменьшается пропорционально увеличению скорости передачи. В стандарте Fast Ethernet оно составляет около 210 м, а в стандарте Gigabit Ethernet оно было бы ограничено 25 метрами, если бы разработчики стандарта не предприняли некоторых мер по увеличению минимального размера пакета.

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

Таблица 3.1. Параметры уровня MAC Ethernet

Концепции распределенной обработки в сетевых ОС

 

Объединение компьютеров в сеть предоставляет возможность программам, рабо­тающим на отдельных компьютерах, оперативно взаимодействовать и сообща ре­шать задачи пользователей. Связь между некоторыми программами может быть настолько тесной, что их удобно рассматривать в качестве частей одного прило­жения, которое называют в этом случае распределенным, или сетевым.

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

 

Модели сетевых служб

и распределенных приложений

 

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

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

Целесообразно выделить три основных параметра организации работы приложе­ний в сети. К ним относятся:

□  способ разделения приложения на части, выполняющиеся на разных компью­терах сети;

□  выделение специализированных серверов в сети, на которых выполняются не­которые общие для всех приложений функции;

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

 

Способ разделения приложений на части

 

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

□  средства представления данных на экране, например средства графического пользовательского интерфейса;

□  логика представления данных на экране описывает правила и возможные сце­нарии взаимодействия пользователя с приложением: выбор из системы меню, выбор элемента из списка и т. п.;

□   прикладная логика — набор правил для принятия решений, вычислительные процедуры и операции;

□  логика данных — операции с данными, хранящимися в некоторой базе, кото­рые нужно выполнить для реализации прикладной логики;

□   внутренние операции базы данных — действия СУБД, вызываемые в ответ на выполнение запросов логики данных, такие как поиск записи по определен­ным признакам;

□   файловые операции — стандартные операции над файлами и файловой систе­мой, которые обычно являются функциями операционной системы.

На основе этой модели можно построить несколько схем распределения частей приложения между компьютерами сети.

 

Двухзвенные схемы

 

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

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

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

В централизованной схеме (рис. 9.1, а) компьютер пользователя работает как тер­минал, выполняющий лишь функции представления данных, тогда как все ос­тальные функции передаются центральному компьютеру. Ресурсы компьютера пользователя используются в этой схеме в незначительной степени, загружен­ными оказываются только графические средства подсистемы ввода-вывода ОС, отображающие на экране окна и другие графические примитивы по командам центрального компьютера, а также сетевые средства ОС, принимающие из сети команды центрального компьютера и возвращающие данные о нажатии клавиш и координатах мыши. Программа, работающая на компьютере пользователя, час­то называется эмулятором терминала — графическим или текстовым, в зависи­мости от поддерживаемого режима. Фактически эта схема повторяет организа­цию многотерминальной системы на базе мэйнфрейма с тем лишь отличием, что вместо терминалов используются компьютеры, подключенные не через локаль­ный интерфейс, а через сеть, локальную или глобальную.

 

 

Главным и очень серьезным недостатком централизованной схемы является ее недостаточная масштабируемость и отсутствие отказоустойчивости. Произво­дительность центрального компьютера всегда будет ограничителем количества пользователей, работающих с данным приложением, а отказ центрального ком­пьютера приводит к прекращению работы всех пользователей. Именно из-за этих недостатков централизованные вычислительные системы, представленные мэйн­фреймами, уступили место сетям, состоящим из мини-компьютеров, RISC-сер­веров и персональных компьютеров. Тем не менее централизованная схема иногда применяется как из-за простоты организации программы, которая почти цели­ком работает на одном компьютере, так и из-за наличия большого парка не рас­пределенных приложений.

В схеме «файловый сервер» (рис. 9.1, б) на клиентской машине выполняются все части приложения, кроме файловых операций. В сети имеется достаточно мощ­ный компьютер, имеющий дисковую подсистему большого объема, который хра­нит файлы, доступ к которым необходим большому числу пользователей. Этот компьютер играет роль файлового сервера, представляя собой централизованное хранилище данных, находящихся в разделяемом доступе. Распределенное при­ложение в этой схеме мало отличается от полностью локального приложения. Единственным отличием является обращение к удаленным файлам вместо ло­кальных. Для того чтобы в этой схеме можно было использовать локальные при­ложения, в сетевые операционные системы ввели такой компонент сетевой фай­ловой службы, как редиректор, который перехватывает обращения к удаленным файлам (с помощью специальной нотации для сетевых имен, такой, например, как //server1/doc/file1.txt) и направляет запросы в сеть, освобождая приложение от необходимости явно задействовать сетевые системные вызовы.

Файловый сервер представляет собой компонент наиболее популярной сетевой службы — сетевой файловой системы, которая лежит в основе многих распре­деленных приложений и некоторых других сетевых служб. Первые сетевые ОС (NetWare компании Novell, IBM PC LAN Program,Microsoft MS-Net) обычно поддерживали две сетевые службы — файловую службу и службу печати, остав­ляя реализацию остальных функций разработчикам распределенных приложе­ний.

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

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

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

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

 

Трехзвенные схемы

 

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

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

Сервер баз данных, как и в двухзвенной модели, выполняет функции двух по­следних слоев — операции внутри базы данных и файловые операции. Приме­ром такой схемы может служить неоднородная архитектура, включающая кли­ентские компьютеры под управлением Windows95/98, сервер приложений с монитором транзакций TUXEDO в среде Solaris на компьютере компании Sun Microsystems и сервер баз данныхOracle в среде Windows 2000 на компьютере компании Compaq.

 

                        

 

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

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

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

В крупных сетях для связи клиентских и серверных частей приложений также используется и ряд других средств, относящихся к классуmiddleware, в том числе:

□  средства асинхронной обработки сообщений (message-oriented middleware, MOM);

□  средства удаленного вызова процедур (Remote Procedure Call, RPC);

□  брокеры запроса объектов (Object Request Broker, ORB), которые находят объекты, хранящиеся на различных компьютерах, и помогают их использо­вать в одном приложении или документе.

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

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

 

Механизм передачи сообщений в распределенных системах

 

Единственным по-настоящему важным отличием распределенных систем от цен­трализованных является способ взаимодействия между процессами. Принципиально межпроцессное взаимодействие может осуществляться одним из двух спо­собов:

□   с помощью совместного использования одних и тех же данных (разделяемая память);

□   путем передачи друг другу данных в виде сообщений.

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

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

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

□   Адрес — набор символов, уникально определяющих отправляющий и полу­чающий процессы. Адресное поле, таким образом, состоит из двух частей — адреса процесса-отправителя и адреса процесса-получателя. Адрес каждого процесса может, в свою очередь, иметь некоторую структуру, позволяющую

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

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

□   Структурированная информация, состоящая в общем случае из нескольких частей: поля типа данных, поля длины данных и поля значения данных (то есть собственно данных). Поле типа данных определяет, например, что дан­ные являются целым числом или же представляют собой строку символов (это поле может также содержать признак нерезидентности данных, то есть указатель на данные, которые хранятся где-то вне данного сообщения). Вто­рое поле определяет длину передаваемых в сообщении данных (обычно в бай­тах), то есть размер следующего поля сообщения. Сообщение может включать несколько элементов, состоящих из описанных трех полей. В тех случаях, ко­гда сообщение всегда переносит данные одного и того же типа, поле типа может быть опущено. То же касается поля длины данных — для тех типов со­общений, которые переносят данные фиксированного формата, но такая си­туация характерна только для протоколов низкого уровня (например, ATM, имеющего фиксированный размер поля данных в 48 байт).

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

Транспортная подсистема сетевой ОС имеет обычно сложную структуру, отра­жающую структуру семиуровневой модели взаимодействия открытых систем (Open System Interconnection, OSI). Представление сложной задачи сетевого взаимодействия компьютеров в виде иерархии нескольких частных задач позво­ляет организовать это взаимодействие максимально гибким образом. В то же время каждый уровень модели OSIэкранирует особенности лежащих под ним уровней от вышележащих уровней, что делает средства взаимодействия компью­теров все более универсальными по мере продвижения вверх по уровням. Таким образом, в процесс выполнения примитивов send и receive вовлекаются средства всех нижележащих коммуникационных протоколов (рис. 9.3).

 

 

Несмотря на концептуальную простоту примитивов send и receive, существуют различные варианты их реализации, от правильного выбора которых зависит эф­фективность работы сети. В частности, эффективность зависит от способа зада­ния адреса получателя. Не менее важны при реализации примитивов передачи сообщений ответы и на другие вопросы. В сети всегда имеется один получатель или их может быть несколько? Требуется ли гарантированная доставка сообще­ний? Должен ли отправитель дождаться ответа на свое сообщение, прежде чем продолжать свою работу? Как отправитель, получатель и подсистема передачи сообщений должны реагировать на отказы узла или коммуникационного канала во время взаимодействия? Что нужно делать, если приемник не готов принять сообщение, нужно ли отбрасывать сообщение или сохранять его в буфере? А если сохранять, то как быть, если буфер уже заполнен? Разрешено ли приемнику из­менять порядок обработки сообщений в соответствии с их важностью? Ответы на подобные вопросы составляют семантику конкретного протокола, передачи сообщений.

 

Синхронизация

 

Центральным вопросом взаимодействия процессов в сети является способ их син­хронизации, который полностью определяется используемыми в операционной

системе коммуникационными примитивами. В этом отношении коммуникационные примитивы делятся на блокирующие {синхронные) инеблокирующие (асинхрон­ные), причем смысл данных терминов в целом соответствует смыслу аналогич­ных терминов, применяемых при описании системных вызовов (см. подраздел «Системные вызовы» раздела «Мультипрограммирование на основе прерываний» в главе 4 «Процессы и потоки») и операций ввода-вывода (см. подраздел «Под­держка синхронных и асинхронных операций ввода-вывода» раздела «Задачи ОС по управлению файлами и устройствами» в главе 7 «Ввод-вывод и файловая система»). В отличие от локальных системных вызовов (а именно такие систем­ные вызовы были рассмотрены в главах 4 и 7) при выполнении коммуникацион­ных примитивов завершение запрошенной операции в общем случае зависит не только от некоторой работы локальной ОС, но и от работы удаленной ОС.

Коммуникационные примитивы могут быть оформлены в операционной системе двумя способами: как внутренние процедуры ядра ОС (в этом случае ими могут использоваться только модули ОС) или как системные вызовы (доступные в этом случае процессам в пользовательском режиме).

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

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

□   Опрос (polling). Этот метод предусматривает наличие еще одного базового при­митива test (проверить), с помощью которого процесс-получатель может ана­лизировать состояние буфера.

□   Прерывание (interrupt). Этот метод использует программное прерывание для уведомления процесса-получателя о том, что сообщение помещено в буфер. Хотя такой метод и очень эффективен (он исключает многократные проверки состояния буфера), у него имеется существенный недостаток — усложненное программирование, связанное с прерываниями пользовательского уровня, то есть прерываниями, по которым вызываются процедуры пользовательского режима (например, вызов процедур АРС в ОС Windows NT по завершении операции ввода-вывода, рассмотренный в главе 8 «Дополнительные возмож­ности файловых систем»).

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

Если при взаимодействии двух процессов оба примитива — send и receive — явля­ются блокирующими, говорят, что процессы взаимодействуют по сети синхронно (рис. 9.4), в противном случае взаимодействие считается асинхронным (рис. 9.5).

 

 

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

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

 

 

 

 

Буферизация в примитивах передачи сообщений

 

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

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

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

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

Именно поэтому при использовании синхронных примитивов все же предусмат­ривают буферизацию. При этом буфер, как правило, выбирается размером в одно сообщение, так как процесс-отправитель не может послать следующее сообще­ние, не получив подтверждения о приеме предыдущего. Сообщение помещается в буфер, поддерживаемый операционной системой компьютера-получателя, если в момент его прихода процесс-получа1ель не может обработать сообщение не­медленно, например из-за того, что процесс либо не является текущим, либо не готов к приему сообщения, так как не обратился к примитиву receive. Буфер может располагаться как в системной области памяти, так и в области памяти пользовательского процесса, в любом случае буфером управляет операционная система, модули которой получают сообщения по сети.

Для всех вариантов обмена сообщениями с помощью асинхронных примитивов необходима буферизация. Поскольку при асинхронном обмене процесс-отправи­тель может посылать сообщение всегда, когда ему это требуется, не дожидаясь подтверждения от процесса-получателя, для исключения потерь сообщений тре­буется буфер неограниченной длины. Так как буфер в реальной системе всегда имеет ограниченный размер, то могут возникать ситуации с переполнением бу­фера и на них нужно каким-то образом реагировать. Для уменьшения вероят­ности потерь сообщений степень асинхронности процесса обмена сообщениями обычно ограничивается механизмом управления потоком сообщений. Управле­ние потоком заключается в том, что при заполнении буфера на принимающей стороне до некоторого опасного порога процесс-передатчик блокируется до тех пор, пока процесс-приемник не обработает часть принятых сообщений и не раз­грузит буфер до безопасной величины. Конечно, вероятность потерь сообщений из-за переполнения буфера все равно сохраняется, например из-за того, что слу­жебное сообщение о необходимости приостановки передачи сообщений может быть потеряно сетью. Асинхронный обмен с управлением потоком — это наибо­лее сложный способ организации обмена сообщениями, так как для повышения эффективности, то есть максимизации скорости обмена и минимизации потерь, он требует применения сложных алгоритмов приостановки и возобновления про­цесс передачи, например таких, которые применяются в протоколе TCP.

Обычно операционная система предоставляет для прикладных процессов специ­альный примитив для создания буферов сообщений. Такого рода примитив, на­зовем его, например, create_buffer (создать буфер), процесс должен использовать перед тем, как отправлять или получать сообщения с помощью примитивов send и receive. При создании буфера его размер может либо устанавливаться по умол­чанию, либо выбираться прикладным процессом. Часто такой буфер носит на­звание порта (port), или почтового ящика (mailbox).

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

узнать, какому процессу адресовано вновь поступившее сообщение, если имеет­ся несколько активных процессов? И как оно узнает, куда его скопировать? Один из вариантов — просто отказаться от сообщения в расчете на то, что отпра­витель после тайм-аута передаст сообщение повторно и к этому времени полу­чатель уже создаст буфер. Этот подход не сложен в реализации, но, к сожале­нию, отправитель (или скорее ядро его компьютера) может сделать несколько таких безуспешных попыток. Еще хуже то, что после достаточно большого числа безуспешных попыток ядро отправителя может сделать неправильный вывод об аварии на машине получателя или о неправильности его адреса. Второй подход к этой проблеме заключается в том, чтобы хранить хотя бы не­которое время поступающие сообщения в ядре получателя в расчете на то, что вскоре будет выполнен соответствующий примитив createbuffer. Каждый раз, когда поступает такое «неожидаемое» сообщение, включается таймер. Если за­данный временной интервал истекает раньше, чем происходит создание буфера, то сообщение теряется.

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

 

Способы адресации

 

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

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

Наибольшее распространение получила система адресации, в которой адрес со­стоит из двух частей, определяющих компьютер и процесс, которому предна­значено сообщение, то есть адрес имеет вид пары числовых идентификаторов: machine_id@loca1_id. В качестве идентификатора компьютера machinejd наиболее употребительным на сегодня является использование IP-адреса, который пред­ставляет собой 32-битовое число, условно записываемое в виде четырех деся­тичных чисел, разделенных точками, например 185.23.123.26. Идентификатором компьютера может служить любой другой тип адреса узла, который воспринимается транспортными средствами сети, например IPX-адрес, ATM-адрес или уже упоминавшийся аппаратный адрес сетевого адаптера, если система передачи сообщений ОС работает только в пределах одной локальной сети.

Для адресации процесса в этом способе применяется числовой идентификатор local_id, имеющий уникальное в"пределах узла machine_idзначение. Этот иден­тификатор может однозначно указывать на конкретный процесс, работающий на данном компьютере, то есть являться идентификатором типа process_id. Однако существует и другой подход, функциональный, при котором используется адрес службы, которой пересылается сообщение, при этом идентификатор принимает вид service_id. Последний вариант более удобен для отправителя, так как служ­бы, поддерживаемые сетевыми операционными системами, представляют собой достаточно устойчивый набор (в него входят, как правило, наиболее популяр­ные службы FTP, SMB, NFS, SMTP, HTTP, SNMP) и этим службам можно дать вполне определенные адреса, заранее известные всем отправителям. Такие адре­са называют «хорошо известными» (well-known). Примером хорошо известных адресов служб являются номера портов в протоколах TCP и UDP. Отправитель всегда знает, что, посылая с помощью этих протоколов сообщение на порт 21 не­которого компьютера, он посылает его службе FTP, то есть службе передачи файлов. При этом отправителя не интересует, какой именно процесс (с каким локальным идентификатором) реализует в настоящий момент времени услуги FTP на данном компьютере.

Ввиду повсеместного применения стека протоколов TCP/IP номера портов яв­ляются на сегодня наиболее популярными адресами служб в системах обмена сообщениями сетевых ОС. Порт TCP/UDP является не только абстрактным ад­ресом службы, но и представляет собой нечто более конкретное — для каждого порта операционная система поддерживает буфер в системной памяти, куда по­мещаются отправляемые и получаемые сообщения, адресуемые данному порту. Порт задается в протоколах TCP/UDP двухбайтным адресом, поэтому ОС мо­жет поддерживать до 65 535 портов. Кроме хорошо известных номеров портов, которым отводится диапазон от 1 до 1023, существуют и динамически исполь­зуемые порты со старшими номерами. Значения этих портов не закрепляются за определенными службами, поэтому они часто дополняют хорошо известные порты для обмена в рамках обслуживания некоторой службы сообщениями спе­цифического назначения. Например, клиент FTP всегда начинает взаимодейст­вие с сервером FTP отправкой сообщения на порт 21, а после установления сеан­са обмен данными между клиентом и сервером выполняется уже по порту, номер которого динамически выбирается в процессе установления сеанса.

Описанная схема адресации типа «машина-процесс» или «машина-служба» хо­рошо зарекомендовала себя, работая уже на протяжении многих лет в Интерне­те, а также в корпоративных сетях IP и IPX (в этих сетях также используется адресация службы, а не процесса). Однако эта схема имеет один существенный недостаток — она не гибка и не прозрачна, так как пользователь должен явно указывать адрес машины-получателя. В этом случае, если в один прекрасный день машина, на которой работает некоторая служба, отказывает, то программа, в ко­торой все обращения к данной службе выполняются по жестко заданному адресу, не сможет использовать аналогичную службу, установленную на другой ма­шине.

Основным способом повышения степени прозрачности адресации является исполь­зование символьных имен вместо числовых. Примером такого подхода является характерная для сегодняшнего Интернета нотация URL (Universal Resource Loca­tor, универсальный указатель ресурса), в соответствии с которой адрес состоит из символьного имени узла и символьного имени службы. Например, если в сообщения указан адресftp://arc.bestcompany.ru/, то это означает, что оно отправ­лено службе ftp, работающей на компьютере arc.bestcompany.ru.

Использование символьных имен требует создания в сети службы оперативного отображения символьных имен на числовые идентификаторы, поскольку имен­но в таком виде адреса распознаются сетевым оборудованием. Применение сим­вольного имени позволяет разорвать жесткую связь адреса с одним-единственным компьютером, так как символьное имя перед отправкой сообщения в сеть заменяется на числовое, например на IP-адрес. Этап замены позволяет сопоста­вить с символьным именем различные числовые адреса и выбрать тот компью­тер, который в данный момент в наибольшей степени подходит для выполнения запроса, содержащегося в сообщении. Например, отправляя запрос на получение услуг службы Web от компании Microsoft по адресу http://www.microsoft.com/, вы точно не знаете, какой из нескольких серверов этой компании, предоставляющих данный вид услуг и обслуживающих один и тот же символьный адрес, ответит вам.

Для замены символьных адресов на числовые применяются две схемы: широко­вещание и централизованная служба имен. Широковещание удобно в локальных сетях, в которых все сетевые технологии нижнего уровня, такие как Ethernet, Token Ring, FDDI, поддерживают широковещательные адреса в пределах всей сети, а пропускной способности каналов связи достаточно для обслуживания та­ких запросов для сравнительного небольшого количества клиентов и серверов. На широковещании были построены все службы ОС NetWare (до версии 4), став­шие в свое время эталоном прозрачности для пользователей. В этой схеме сервер периодически широковещательно рассылает по сети сообщения о соответствии числовым адресам его имени и имен служб, которые он поддерживает. Клиент также может сделать широковещательный запрос о наличии в сети сервера, под­держивающего определенную службу, и если такой сервер в сети есть, то он от­ветит на запрос своим числовым адресом. После обмена подобными сообщения­ми пользователь должен явно указать в своем запросе имя сервера, к ресурсам которого он обращается, а клиентская ОС заменит это имя на числовой адрес в соответствии с информацией, широковещательно распространенной сервером.

Однако широковещательный механизм разрешения адресов плохо работает в территориальных сетях, так как наличие большого числа клиентов и серверов, а также использование менее скоростных по сравнению с локальными сетями каналов делают широковещательный трафик слишком интенсивным, практиче­ски не оставляющим пропускной способности для передачи пользовательских данных. В территориальных сетях для разрешения символьных имен компьюте­ров применяется другой подход, основанный на специализированных серверах, хранящих базу данных соответствия между символьными именами и числовыми адресами. Эти серверы образуют распределенную службу имен, обрабатывающую запросы многочисленных клиентов. Хорошо известным примером такой службы является служба доменных имен Интернета (Domain NameService, DNS). Эта служба позволяет обрабатывать в реальном масштабе времени многочисленные запросы пользователей Интернета, обращающихся к ресурсам серверов по составным име­нам, таким как http://www.microsoft.com/ или http://www.gazeta.ru/. Другим при­мером может служить служба каталогов (NetWare Directory Sevices, NDS) ком­пании Novell, которая выполняет в крупной корпоративной сети более общие функции, предоставляя справочную информацию по любым сетевым ресурсам, в том числе и по соответствию символьных имен компьютеров их числовым ад­ресам.

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

По пути применения централизованной службы-посредника между клиентами и ресурсами идут и разработчики распределенных приложений, например разра­ботчики технологии CORBA, в которой запросы к программным модулям при­ложений обрабатывает специальный элемент — брокер запросов.

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

 

Надежные и ненадежные примитивы

Ранее подразумевалось, что когда отправитель посылает сообщение, адресат его обязательно получает. Но на практике сообщения могут теряться. Предположим, что для обмена сообщениями используются блокирующие примитивы. Когда от­правитель посылает сообщение, то он приостанавливает свою работу до тех пор, пока сообщение не будет послано. Однако нет никаких гарантий, что после того, как он возобновит свою работу, сообщение будет доставлено адресату.

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

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

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

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

В хорошей подсистеме обмена сообщения должны поддерживаться как ненадеж­ные примитивы, так и надежные. Это позволяет прикладному программисту ис­пользовать тот тип примитивов, который в наибольшей степени подходит для организации взаимодействия в той или иной ситуации. Например, для передачи данных большого объема, транспортируемых по сети в нескольких сообщениях (в сетях обычно существует ограничение на максимальный размер поля данных, из-за чего данные приходится пересылать в нескольких сообщениях), больше под­ходит надежный вид обмена с упорядочиванием сообщений. А вот для взаимо­действия типа «короткий запрос — короткий ответ» предпочтительны ненадеж­ные примитивы. Действительно, вероятность потери отдельного сообщения не так уж велика, а скорость такого обмена будет выше, чем при применении на­дежных примитивов, поскольку на установление необходимого в этом случае со­единения тратится дополнительное время.

Для реализации примитивов с различной степенью надежности передачи сооб­щений система обмена сообщениями ОС использует различные коммуникаци­онные протоколы. Так, если сообщения передаются через IP-сеть, то для надеж­ной передачи сообщений используется протокол транспортного уровня TCP, работающий с установлением соединений, обеспечивающий гарантированную и упорядоченную доставку и управляющий потоком данных при обмене. Если же надежность при передаче сообщений не требуется, то будет использован прото­кол UDP, обеспечивающий быструю доставку небольших сообщений без всяких гарантий. Аналогично при работе через сети Novell для надежной доставки сооб­щений используется протокол SPX, а для дейтаграммной — IPX. В стеке OSI су­ществует один транспортный протокол, но он поддерживает несколько режимов, отличающихся степенью надежности.