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

Лекция №22

Тема. Способи адресації. Надійні і ненадійні примітиви. Механізм Sockets ОС UNIX

Цель. Объяснить способы адресации, механизм Sockets ОС UNIX.

1. Учебная. Рассказать о способах адресации, надежных и ненадежных примитивах, механизме Sockets ОС UNIX.

2. Развивающая. Развивать логическое мышление и естественное - научное мировоззрение.

3. Воспитательная. Воспитывать интерес к научным достижением и открытиям.

Межпредметные связи:

· Обеспечивающие: информатика, математика, вычислительная техника и МП, системы программирования.

· Обеспечиваемые: Стажерская практика

Методическое обеспечение и оборудование:

1. Методическая разработка к занятию.

2. Учебный план.

3. Учебная программа

4. Рабочая программа.

5. Инструктаж по технике безопасности.

Технические средства обучения: персональный компьютер.

Обеспечение рабочих мест:

· Рабочие тетради

Ход лекции.

Организационный момент.

Анализ и проверка домашней работы

3. Ответьте на вопросы:

1. Какими преимуществами обладают распределенные приложения по сравнению с локальными.

2. Как называется другими словами распределенное системное программное обеспечение?

3. Что относят к основным параметрам организации работы приложе­ний в сети.

4. Перечислите шесть функциональных частей распределенных приложений.

5. К чему приводит распределение приложения между большим числом компьютеров?

6. Основной не достаток централизованной схемы?

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

8. Чего позволяет добиться трехзвенная архитектура?

9. Какие средства используют в крупных сетях для связи клиентских и серверных частей, приложений?

10. Что упрощает централизованная реализация логики

11. Какую роль играют средства относящиеся к классу middleware?

12. Какими основными свойствами должен обладать сервер приложений?

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

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

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

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

Для адресации процесса в этом способе применяется числовой идентификатор local_id, имеющий уникальное в пределах узла machine_id значение. Этот иден­тификатор может однозначно указывать на конкретный процесс, работающий на данном компьютере, то есть являться идентификатором типа processed Однако существует и другой подход, функциональный, при котором используется адрес службы, которой пересылается сообщение, при этом идентификатор принимает вид 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), став­шие в свое время эталоном прозрачности для пользователей. В этой схеме сервер периодически широковещательно рассылает по сети сообщения о соответствии числовым адресам его имени и имен служб, которые он поддерживает. Клиент также может сделать широковещательный запрос о наличии в сети сервера, под­держивающего определенную службу, и если такой сервер в сети есть, то он от­ветит на запрос своим числовым адресом. После обмена подобными сообщения­ми пользователь должен явно указать в своем запросе имя сервера, к ресурсам которого он обращается, а клиентская ОС заменит это имя на числовой адрес в соответствии с информацией, широковещательно распространенной сервером.

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

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

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

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

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

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

Для решения этой проблемы существуют три подхода.

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

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

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

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

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

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

Поиск по сайту: