Обмен данными между уровнями

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

Взаимодействие уровней

Как показано на рис.1-4, уровень "N" взаимодействует с уровнями "N-1" и "N+1" посредством параметров, которые посылаются в и из этих уровней. Каждый уровень предоставляет лежащему выше уровню услуги. Протоколы усиливают равноправный обмен данными внутри уровня протокола: каждый объект уровня обменивается данными с объектом другого уровня.

Уровень протокола передает пакет лежащему под ним уровню, до тех пор, пока он не пройдет через сеть и получающий узел. Уровень "N" знает только то, что происходит на уровнях "N-1" и "N+1". Это означает, что разработчики системы протоколам, так как они в минимальной степени влияют на систему.

Коллективное использование информации в ЛВС на основе NETBIOS требует наличия трех важнейших элементов программного обеспечения: 1) PC-DOS 3.Х; 2) самого NETBIOS; 3) подпрограммы переадресатора сообщений. На рис 1-5 показан способ соединения этих трех компонентов в систему. NET, доступный из прикладной программы или программы переназначения через прерывание 2AH, является частью Программы ЛВС ПЭВМ IBM. Полная реализация Программы Сети ПЭВМ показана на правой стороне рисунка; файловый процессор и процессор печати показаны на заднем плане.

Прикладная программа может выполнять одну из трех операций, касающихся сети: пользовательская прикладная программа (например, система подготовки текстов) вызовет DOS и заставит подпрограмму переадресатора послать ввод-вывод в/из спецпроцессора через программу NET; многопользовательская система подготовки текстов будет использовать вызовы расширенной версии DOS для блокировки/разблокировки файлов; специализированная прикладная программа спецпроцессора вызовет NETBIOS непосредственно, используя прерывание 5CH. Четвертая опция для прикладной программы - непосредственно вызвать файловый процессор/процессор печати (если он реализован) через Программу ЛВС ПЭВМ, используя прерывание 2AH или 2FH.

Краткий обзор функций, предоставляемых прерываниями 2FH,

21H и 2AH дан на рис.1-6. В последующих главах будет подробно

описано прерывание 5СH NETBIOS.

Реализации NETBIOS

Важно учесть, что опцией NETBIOS, доступной для ЭКС Token-Ring,является эмуляция NETBIOS, содержащаяся на оригинальной плате Адаптера Сети ПЭВМ. Следовательно, хотя фактические используемые на разных уровнях протоколы могут быть различными в ЭКС (Token-Ring, к примеру) и Сети ПЭВМ, пользователь или программист видит ОДИНАКОВЫЕ интерфейсы и работу системы, за исключением того, что время получения ответа в ЭКС Token-Ring меньше.

В ЭКС Token-Ring рабочий процессор должен оперировать протоколами, в то время как в Сети ПЭВМ IBM (IBM PC) процессор на плате 80188 выполняет обработку протоколов. Интересно, что проверка работы NETBIOS на обеих сетях показала, что производительность (скорость передачи данных) в ЭКС Token-Ring в два раза выше, чем в сети ПЭВМ. Это обусловлено потерями между четырьмя микропроцессорами в Адаптере Сети ПЭВМ и способом программирования оригинальных протоколов NETBIOS.

Рабочая ЭВМ осуществляет обмен данными с NETBIOS через Блок управления сетью (NCB) (также именуемый Блоком управления сообщений в Справочном руководстве по Адаптеру сети ПЭВМ IBM Token-Ring). Об этом блоке в деталях будет рассказано в Главе 2. Если этот блок установлен рабочей ЭВМ, он прерывает NETBIOS для услуги. Затем NETBIOS вызывает услугу, запрошенную рабочей ЭВМ (хотя некоторые услуги, например, запрос на выполнение местного диагностирования или на получение адреса адаптера, могут и не потребовать протоколы).

На практике, NETBIOS вызывает два уровня протокола - сеансовый и канальный (уровни 5 и 2 в модели соединения открытых систем). В данной реализации NETBIOS фирмой Sytek, рабочая ЭВМ осуществляет обмен данными только с сеансовым уровнем, но в действительности некоторые запросы просто передаются канальному уровню.

Канальный уровень предоставляет Сети ПЭВМ или ЭКС Token-Ring протокол доступа к каналу (LAP в терминологии сети ПЭВМ). В этом заключается существенное различие между двумя сетями в отношении реализации NETBIOS. ЭКС Token-Ring обеспечивает управляющую процедуру (DLC) стандарта IEEE 802.2 и управление доступом к носителям (MAC) стандарта 802.5 - вызовы NETBIOS непосредственно переводятся в кадры 802.2 и 802.5, обходя любые сетевые или транспортные протоколы.

Сеть IBM PC обеспечивает собственную управляющую процедуру (DLC) и управление доступом к носителям (MAC) стандарта 802.5 (Множественный доступ с контролем несущей и обнаружением конфликтов -CSMA/CD и формат кадра). Протокол доступа к каналу Сети ПЭВМ (LAP) предоставляет услугу для протокола передачи пакетов (PTP). Этот протокол реализует сетевой уровень в Сети ПЭВМ и обеспечивает маршрутизацию, обнаружение адреса и услугу по передаче неквитированных пакетов (дейтаграмм). Протокол передачи пакетов (PTP) используется протоколом надежного потока (RSP) и транспортным протоколом дейтаграмм (DTP).

Протокол передачи пакетов (PTP) является слабым местом в оригинальной Сети ПЭВМ, потому что функция маршрутизации представляет собой простейшую схему установки соответствия между именами. Этот протокол не располагает средствами для реализации межсетевого взаимодействия, что затрудняет создание шлюзов между двумя сетями и делает эти шлюзы функционально ограниченными. Например, Программа соединения Сети ПЭВМ с ЭКС может соединить две сети вместе, но максимальное количество услуг между ними будет равно всего 16.

Протокол надежного потока (RSP) Сети ПЭВМ находится на транспортном уровне. Он обеспечивает безошибочные виртуальные услуги связи с другими пользователями через сквозное квитирование и повторную передачу. Этот протокол предоставляет протоколу управления сеансами (SMP) услуги транспортного уровня. Транспортный протокол дейтаграмм (DTP) также находится на этом уровне. Он обеспечивает услуги квитированных дейтаграмм между объектами сеансового уровня, включая протокол пользовательских дейтаграмм (UDP) и протокол управления и диагностирования (DMP).

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

Кроме поименования протокол пользовательских дейтаграмм (UDP) обеспечивает поддержку для дейтаграмм между двумя именами (узлами). Протокол управления именами сети ПЭВМ (NMP) осуществляет связывание "родственных" узлов и адресов сети внутри всей локальной сети. Этот протокол (NMP) предоставляет все виды услуг по управлению именами, включая переадресацию удаленных имен в адреса сети. Функционирование этой части протокола служит од- ной из причин того, что в начале работы требуется довольно длительное время, чтобы стать частью сети NETBIOS - узел будет передавать свое имя многократно, пока не "удостоверится", что все прочие станции получат это имя. Это также происходит и в том случае, когда протокол управления сеансами (SMP) устанавливает связь с другим именем.

Одним из наиболее интересных протоколов сети ПЭВМ является протокол управления и диагностирования (DMP). Он предоставляет информацию по состоянию (статусу) и диагностике. Этот протокол может через сеть запрашивать другие платы адаптера с целью выяснения их статуса/состояния.

Версии NETBIOS

Версии NETBIOS до появления Служебной программы ЛВС IBM (так называемая Support Program IBM LAN) были обозначены как "Версии номер 1.Х". Служебная программа ЛВС IBM, версия 1.00, имеет версию NETBIOS 2.0; служебная программа, версия 1.01, - версию NETBIOS 2.1, а служебная программа, версия 1.02, версию NETBIOS 2.2. Эта информация важна, так как позднее мы будем рас- сматривать дополнительные команды и функции, включенные в последние версии.

NETBIOS ИЛИ APPC/PC ?

Подобно большинству высокоуровневых протоколов, NETBIOS не зависит от аппаратного обеспечения, что позволяет использовать его на разнообразных системах. Однако, в связи с введением IBM для ЭКС Token-Ring Перспективной системы межпрограммного взаимодействия для ПЭВМ ("Advanced Program-to-Progran Communication", "APPC/PC"), будущее NETBIOS представляется неопределенным. Важность APPC для разработчиков прикладных программ для ЭВМ IBM весьма велика, потому, что фирма IBM предлагает свою новую систему для каждой большой компьютерной серии, активно рекламируя ее как "открытый" интерфейс. Расширенная версия OS/2 для PS/2 включает в себя APPC/PC.

Преимуществом NETBIOS является то, что он уже установлен на сотнях ЛВС ПЭВМ, в то время, как APPC/PC придется догонять NETBIOS в период с 1988 по 1990 год. Кроме того. NETBIOS имеет еще одно достоинство, - оно заключается в том, что APPC содержит протоколы сетевой архитектуры систем (SNA), которые потребляют большую часть ресурсов системы (ОЗУ + ЦПУ). Для ПЭВМ эти расходы будет необходимо снизить; причем данную проблему можно решить, при условии широкого использования более мощных ЭВМ серии PS/2 или совместимых с ними.

Разработка прикладных программ для NETBIOS в ЭКС потребует интерфейса со спецпроцессорами и шлюзами в "стиле" ПЭВМ (смотри Главу 5). Однако, это также означает, что такие прикладные программы, возможно, не будут подходить для других больших систем, которые IBM поддерживает в ЭКС, например System/36 и 9370. В стратегическом отношении APPC превосходит NETBIOS, который расчитан на тактическое (ближайшее) применение, если только IBM не разработает эмулятор NETBIOS для неперсональных ЭВМ, что, впрочем, представляется маловероятным.

Как считает IBM, назначение APPC состоит в том, чтобы стать "одной архитектурой для межпрограммного взаимодействия программ общего назначения"; кроме того, APPC должна обеспечивать универсальную связь (соединение), т.е. соединять "все со всем". Более того, стоимость установки APPC невелика, а функциональность - высока. APPC является основой для разработки распре- деленных прикладных программ.

Подведя итог, можно сказать следующее: используйте NETBIOS для поддержки традиционных прикладных программ для ПЭВМ, а APPC/PC для прикладных программ взаимодействия ПЭВМ с большой ЭВМ и прикладных программ взаимодействия равноправных ЭВМ; либо применяйте NETBIOS для ЛВС только персональных компьютеров, а APPC/PC для смешанных сред, которые поддерживают прикладные программы IBM рабочей ЭВМ, например программы, попадающие в раз- ряд Прикладной архитектуры систем (SAA) IBM.

Домашнее задание

1. Учить конспект, Баканов В.М.Программное обеспечение компьютерных сетей и информационных систем, стр. . 33

2. Оформить собранную информацию в виде презентации.

Не нашли, что искали? Воспользуйтесь поиском по сайту: