|
Architecture Technology Corporation США 1988 Второе издание П Р Е Д И С Л О В И Е Сетевая базовая система ввода-вывода (NETBIOS) представляет со- бой высокоуровневый интерфейс программирования для локальных вы- числительных сетей (LAN) IBM. Он был первоначально разработан фир- мой Sytek,Inc.(США) для Сети ПЭВМ IBM (IBM PC Network) с модулиро- ванной передачей. Основу NETBIOS составляют три продукта: кольцевая сеть с эстафетной передачей Token-Ring, эмулятор NETBIOS и Служеб- ная программа ЛВС ПЭВМ (PC LAN Support Program), (которая включает управляющую программу NETBIOS). Служебная программа ЛВС ПЭВМ объе- диняет эмулятор NETBIOS для работы в Сети ПЭВМ (PC Network) с модулированной передачей, Сети ПЭВМ с немодулированной передачей, а также адаптеры эстафетной кольцевой сети Token-Ring, и действует на ЭВМ серии Personal System/2. С О Д Е Р Ж А Н И Е Предисловие Содержание Перечень схем и рисунков ГЛАВА 1. Введение Историческая справка Определение протокола Сеть ПЭВМ и кольцевая сеть с эстафетной передачей Программа ЛВС ПЭВМ IBM Проект стандарта OSI - Соединение открытых систем Обмен данными между уровнями Взаимодействие уровней Связь с PC-DOS и прикладными программами Реализации NETBIOS Версии NETBIOS NETBIOS или APPC/PC ГЛАВА 2. Программирование Общая процедура Интерфейс программирования NETBEUI Драйвер Программирование Команды NETBIOS NETBIOS в ЭКС Token-Ring Различия в реализации Драйвер протокола ГЛАВА 3. Протоколы и форматы пакетов Сеть ПЭВМ Команды сеансового уровня/действия протокола Транспортный уровень Сетевой уровень ЭКС Token-Ring ГЛАВА 4. Протокол Блока сообщений спецпроцессора Обзор Поименование Установка соединения ПЭВМ - спецпроцессор Протоколы Блока сообщений спецпроцессора (SMB) Формат SMB ГЛАВА 5. Разработки NETBIOS, сделанные другими фирмами Разработки NETBIOS, отличные от разработки фирмы IBM Фирма AST Research Фирма Excelan Фирма Novell Фирма The Software Link Другие фирмы Фирма CSI Фирма NCR Компания Network Research Corporation Фирма Pathway Design,Inc Фирма Sytek Анализатор протоколов "ИЩЕЙКА" (Sniffer) ГЛАВА 6. Microsoft и IBM Историческая справка Microsoft Сети Microsoft Сети Microsoft и NETBIOS Администратор ЛВС Взаимодействие Администратора ЛВС и API NETBIOS Вызовы процедур Функционирование Компания IBM Программа ЛВС ПЭВМ Спецпроцессор ЛВС ГЛАВА 7. Стандартизация NETBIOS Протокол управления транспортом/Межсетевой протокол Статус Докладной записки Введение Принципы проектирования Поддерживаемые средства Необходимые интерфейсы и требуемые определения Соответствующие протоколы и услуги Масштаб NETBIOS Оконечные узлы NETBIOS Широковещательные узлы Двухточечные узлы Узлы смешанного режима Вспомогательные спецпроцессоры Узлы спецпроцессора имен Топологии Общие способы взаимодействия Основания для TCP и UDP Услуга сеанса NETBIOS Услуга дейтаграммы NETBIOS Минимальное соответствие Международная организация по стандартизации (ISO) Введение NETBIOS как интерфейс транспортного уровня Имена NETBIOS Сеансовые услуги NETBIOS Услуги дейтаграмм NETBIOS Расширения ISO версии NETBIOS ПРИЛОЖЕНИЕ. Список сокращений. ПЕРЕЧЕНЬ СХЕМ И РИСУНКОВ Рис. 1-1. Типичный формат сообщения Рис. 1-2. Реализация NETBIOS Рис. 1-3. Проект стандарта соединения открытых систем Рис. 1-4. Взаимодействие уровней в соединении открытых систем Рис. 1-5. Услуга NETBIOS/DOS Рис. 1-6. Функции прерывания 2FH, 21H, 2AH Рис. 2-1. Параметры драйвера устройства NENBIOS Рис. 2-2. Блок управления сетью (NCB) Рис. 2-3. Коды возврата ошибок NETBIOS Рис. 3-1. Общая схема синхронизации пакетов сеанса Рис. 3-2. Отношения протоколов Сети ПЭВМ Рис. 3-3. Пакет "заявка на имя/отмена имени" Рис. 3-4. Пакет ответа на заявку на имя Рис. 3-5. Пакет "запрос на имя" Рис. 3-6. Пакет запроса на сеанс Рис. 3-7. Пакет "сеанс принят" Рис. 3-8. Пакет данных сеанса Рис. 3-9. Пакет квитирования Рис. 3-10.Пакет дейтаграмм Рис. 3-11.Формат кадра NETBIOS в ЭКС Token-Ring Рис. 3-12.Кадры управленипя именами NETBIOS в Token-Ring Рис. 3-13.Кадры управления сеансами NETBIOS в Token-Ring Рис. 3-14.Кадры передачи данных NETBIOS в Token-Ring Рис. 3-15.Дополнительные кадры NETBIOS в Token-Ring Рис. 4-1. Типичный формат SMB Рис. 4-2. Режим открытия файлов и типы доступа Рис. 5-1. Реализация NETBIOS фирмой AST Research Рис. 5-1. Реализация NETBIOS фирмой Excelan Рис. 5-1. Реализация NETBIOS фирмой Novell Рис. 5-1. Реализация NETBIOS фирмой The Software Link Рис. 6-1. Блок управления транспортом (TCB) Рис. 6-2. Программа ЛВС ПЭВМ (PC LAN) Рис. 7-1. В-узлы Рис. 7-2. Р-узлы Рис. 7-3. Р-узлы Internet Рис. 7-4. Р-узлы и М-узлы Internet Рис. 7-5. Интерфейс NETBIOS и Модель Соединения открытых систем Рис. 7-5. Имя узла в преобразовании NSAP Рис. 7-7. Блок данных транспортной услуги протокола CLTP дейтаграммы NETBIOS Рис. 7-8. Расширенная версия ISO команды ADD NAME Рис. 7-9. Расширенная версия ISO команды CALL Г Л А В А 1 ВВЕДЕНИЕ -------- Историческая справка Сетевая базовая система ввода-вывода (NETBIOS) представляет со- бой высокоуровневый интерфейс программирования для локальных вычис- лительных сетей (LAN) IBM. Он был создан фирмой Sytek.Inc для широ- кополосной Сети IBM PC. Основу NETBIOS составляют три продукта: кольцевая сеть с эстафетной передачей (Token-Ring),эмулятор NETBIOS (который позволяет работать с прикладными программами, первоначаль- но созданными для Сети ПЭВМ (PC Network), в кольцевой сети с эста- фетной передачей - Token-Ring) и Служебная программа ЛВС ПЭВМ (PC LAN Support Program). Последняя включает в себя управляющую прог- рамму (драйвер) NETBIOS. Слцужебная программа ЛВС ПЭВМ объединяет эмулятор NETBIOS для работы в Сети ПЭВМ (PC Network) с модулиро- ванной передачей, Сети ПЭВМ (PC Network) с немодулированной пере- дачей, а также адаптеры Noken-Ring. Эта программа действует на компьютерах серии Personal System/2. Многие разработчики программного обеспечения для локальных вы- числительных сетей (ЛВС) ожидают, чтобы NETBIOS под управлением DOS 3.Х (здесь и далеее: 3.Х означает версия 3.1 или более позд- няя) стал стандартным интерфейсом для ЛВС ПЭВМ (PC LAN), что оста- новило бы распостранение нестандартных, "индивидуальных" интерфей- сов и протоколов, таких как, например, Сетевые системы Ксерокс (Xerox Network Systems (XNS), Протокол управления передачей ARPANET (Transmission Control Protocol), Межсетевой протокол ARPANET (Internetwork Protocol) - TCP/IP. NETBIOS не стал бы фактическим стандартом для ЛВС ПЭВМ, если бы он не был предложен IBM. Вследст- вие того, что NETBIOS был создан как открытый интерфейс в сети ПЭВМ IBM, он все-таки может стать стандартом, по крайней мере как интер- фейс сеансового уровня (это пятый уровень взаимодействия компонен- тов сети в модели соединения открытых систем; подробно см. далее). Однако, несмотря на широкое распостранение NETBIOS, он еще не стал стандартом. Определение протокола Протоколы представляют собой просто набор условий (пра- вил),которые регламентируют формат и процедуры обмена информацией между двумя или несколькими независимыми устройствами или про- цессами. Протокол имеет три важнейших элемента: синтаксис, семан- тику и синхронизацию (timing). Синтаксис протокола определяет по- ля; например, может быть 16-байтовое поле для адресов, 32-байто- вое поле для контрольных сумм и 512 байт на пакет. Семантика про- токола придает этим полям значение: например, если адресное поле состоит из всех адресов, это "широковещательный" па- кет. Синхронизация - количество битов в секунду - это скорость передачи данных. Она важна не только на самых низких уровнях протокола, но и на высших. На рис 1-1 показан типичный формат сообщения. В начале сооб- щения, передаваемого в сети, присваиваются символы синхронизации, с той целью, чтобы другой узел в сети мог увидеть, что "приходит" сообщение и смог синхронизировать приемник с передатчиком. Заго- ловок сообщения содержит информацию об адресе - откуда и куда поступает сообщение. Текст сообщения - это сама информация, посы- лаемая по сети. Он имеет заголовок и иногда концевик, показываю- щий, где заканчивается сообщение. В конце сообщения также могут быть символы управления и синхронизации. Начало Д А Н Н Ы Е Конец сообщения сообщения ! СООБЩЕНИЯ ! ! ! ! ! ! ! ! !! !! ! ---------------------------------------------- ! ! ! ! ! ! !Символы !Заго- ! !Конце-!Управ- ! Направление !управле- !ловок ! Т Е К С Т !вик !ляющие ! потока !ния и !сооб- ! !сооб- !симво- ! данных !синхро- !щения ! СООБЩЕНИЯ !щения !лы ! <----------------!низации ! ! ! ! ! ! ! ! ! ! ! ---------------------------------------------- Рис 1-1. Типичный формат сообщения. Существует несколько проблем, связанных с транспортными протоколами. Одна из них заключается в структуре адресации: долж- на ли она быть простой (одна область адресации для взаимосвязан- ной системы) или иерархической (древовидная структура адресов та- кая, как сеть, станция или гнездо в станции)? Что представляет собой область адресации системы - сколько узлов или ПЭВМ могут логически быть адресованы в системе? Количество ПЭВМ, подключае- мых к системе намного меньше,чем область адресации. Каков должен быть размер единицы данных? В этом вопросе необходимо компромисс- ное решение, потому что большие единицы данных могут "покоробить" систему, а передача маленьких единиц может быть неэкономична. Имеет ли система некоторый способ контроля ошибок? Если происхо- дят какие-либо неполадки,сможет ли система протоколов показать, в чем состоит проблема, и сможет ли она исправить эту ошибку? Каким образом синхронизируются пакеты в уровнях протокола? Предположим, что-то неисправимо повредило чей-либо пакет данных или записало в неправильный файловый процессор - будет ли обеспечена защита? Име- ется ли управление протоколами для контроля распределения ресур- сов и анализа производительности системы? Как мы увидим далее, NETBIOS удовлетворяет многим, но не всем этим требованиям. Сеть ПЭВМ и кольцевая сеть с эстафетной передачей Прикладные программы,написанные в NETBIOS для Сети ПЭВМ (PC Network), будут работать с эмулятором кольцевой эстафетной сети (Token-Ring), но эти две сети по-разному реализуют свои протоколы. Например,прикладные программы NETBIOS, предлагаемые IBM, включают Программу ЛВС ПЭВМ IBM (PC LAN), Спецпроцессор асинхронной связи и Программу SNA 3270 (сетевая архитектура систем). Реализация NETBIOS для Сети ПЭВМ (PC Network) и кольцевой сети с эстафетной передачей (Token-Ring) показана на рис.1-2. Важное различие заключается в том, что NETBIOS в Сети ПЭВМ полностью содержится на Адаптере сети ПЭВМ, в то время как в эстафетной кольцевой сети (Token-Ring) он полностью содержится в самой рабочей ПЭВМ. Также учтите, что в реализации эстафетной кольцевой сети не имеется ни сетевого, ни транспортного уровня протокола. Существуют разногла- сия по поводу того, может ли реализация эстафетной кольцевой сети (Token-Ring) действовать столь же эффективно без специализирован- ного со-процессора NETBIOS. Испытания, произведенные IBM, показа- ли по меньшей мере двукратное увеличение производительности Token-Ring с эмулятором Token-Ring NETBIOS. СЕТЬ ПЭВМ ЭКС ПЭВМ (Token-Ring) ----------------------------------------------------------------- ! ! ! Прикладная программа NETBIOS ! ! ! ----------------------------------------------------------------- ----------------------------------------------------------------- ! ! ! Интерфейс NETBIOS ! ! ! ----------------------------------------------------------------- --------------------------- ! ! ! Программа NETBIOS ! Адаптер сети ПЭВМ ! ! ------------------------- --------------------------- ! ! ! ! ! Сеансовый уровень ! ! Сеансовый уровень ! ! ! ! ! !-----------------------! !-------------------------! ! ! ! ! ! Транспортный уровень ! ! ! ! ! ! ! !-----------------------! !-------------------------! ! ! ! ! ! Сетевой уровень ! ! ! ! ! ! ! !-----------------------! !-------------------------! ! ! ! ! ! ! ! ! IEEE 802.2 ! DIRECT ! ! ! !-------------------------! ! ! ! Подпрограмма взаимо- ! ! CSMA/CD ! ! действия с адаптером ! ! ! ! ! ! ! --------------------------- ! Канальный уровень ! ! ! Адаптер ЭКС (Token-Ring) ! ! --------------------------- ! ! !=LLC 80-2.2=! ! ! ! !------------! MAC 802.5 ! ! ! ! ! ------------------------- !-------------------------! ! ! ! ! ! Физический транспортн.!---! ! Физический транспортн. !---! ! ! ! ! ! ! !-----------! !-! ! !-------------! !-! ! !---------! ! !---------! ! ! ! ! ! ! ! !-----------------------! ! !------------------------! ! ! ЛВС с модулированной ! ! ! ЛВС с немодулированной ! ! ! передачей !---! ! передачей !---! ! ! ! ! !-----------------------! !------------------------! Рис1-2. Реализация NETBIOS. ПРИМЕЧАНИЕ: Здесь и далее: "ЭКС" - эстафетная кольцевая сеть (Token-Ring) CSMA/CD - Множественный доступ с контролем несущей и обнаружением конфликтов LLC - Управление логическим каналом MAC - Управление доступом к носителям Программа ЛВС IBM PC Программа "Локальная вычислительная сеть ПЭВМ IBM" (IBM PC LAN Program) (бывшая Программа Сети ПЭВМ IBM ) (IBM PC Network Program) является примером прикладной программы, которая основыва- ется для своей работы на NETBIOS. Она реализует протокол "Блок сообщения спецпроцессора" (SMB). Программа ЛВС ПЭВМ IBM дает пользователю функции рабочей станции (переадресатор, получатель и отправитель сообщений) и неспециализированные функции спецпроцес- сора (функции рабочей станции и спецпроцессора). Переадресатор (созданный Microsoft и включенный IBM в Программу ЛВС ПЭВМ ) перехватывает запросы из DOS с целью определения, предназна- чен ли запрос отдаленному ресурсу. Получатель позволяет рабочей станции получать текстовые сообщения от других пользователей, а отправитель - посылать сообщения другим пользователям. Спецпро- цессор является неспециализированным файловым процессором, который позволяет пользователю совместно с другими пользователями в сети использовать жесткие диски и печатающие устройства, относящиеся к его/ее ПЭВМ. Проект стандарта OSI - Соединение открытых систем Рассматривая NETBIOS, будет полезно изучить предложенный Международной организацией по стандартизации проект стандарта вза- имодействия открытых систем. Эта модель представляет собой архи- тектуру соединения и взаимодействия вычислительной техники в не- однородной среде. Модель охватывает не только ЛВС, но и другие сети, например сети типа Х.25 - ARPANET, TELENET и сети больших ЭВМ. Большинство комитетов по стандартизации, включая Институт инженеров по электротехнике и радиоэлектронике (IEEE) и ИСО (Меж- дународную организацию по стандартизации) создали специальную се- мантику и синтаксис протоколов для реализации различных уровней. Модель ИСО представлена семью уровнями протокола, как это показано на рис.1-3. Каждый уровень обслуживает непосредственно расположенный над ним и базируется на лежащем под ним уровне (за исключением, естественно, самого нижнего уровня - физического). Ниже кратко описываются каждый из этих уровней. Первый уровень - физический. Он состоит из потока бит, посы- лаемых и получаемых из сети данных. В него входит скорость пере- дачи (2,5 мегабайт/сек в Сети ПЭВМ, 4 мегабайт/сек в ЭКС Token-Ring) и схемы кодирования (обе сети используют кодирование Manchester, сеть ПЭВМ - в канале модулированной передачи, ЭКС - в канале немодулированной передачи). Второй уровень - канальный. Этот уровень определяет значение структуры потока бит. Формат пакета, который описывает второй уровень, передается в сети, используя услуги первого уровня. ЭКС использует протокол управления логическим каналом (LLC) - IEEE 802.2 и протокол управляющей процедуры (DLC) IEEE 802.5. Третий уровень - сетевой. Он ответственен за маршрутизацию и коммутацию данных в ЛВС и взаимосвязанных ЛВС. Он должен распоз- навать адреса в сети и осуществлять маршрутизацию информации (па- кетов) в соответствующих сетях или передавать их на транспортный уровень для дальнейшей интерпретации. Третий уровень - одно из слабых мест в NETBIOS. При создании NETBIOS не учитывалась возможность его работы в условиях взаимо- действия сетей, поэтому в нем отсутствуют свойства, необходимые для эффективного поддержания этой функции. Сетевое взаимодействие между Сетью ПЭВМ и ЭКС Token-Ring, (поддерживаемое Программой соединения IBM) (IBM Interconnect Program), осуществляется прикладной программой, которая резидентно находится в ПЭВМ в ка- честве шлюза и передает имена между системами и пакеты между сеансами (способом передачи с буферизацией). Заметьте, что Программа соединения IBM может соединять только две ЛВС. Четвертый уровень - транспортный. Он несет ответственность за надежную передачу информации между станциями в сети. Этот уро- вень реализует такие свойства, как квитирование, номера последо- вательности (упорядочение) и истечение времени ожидания события. В Сети ПЭВМ (с модулированной передачей) NETBIOS использует спе- циальные протоколы Sytek для реализации транспортных протоколов. Пятый уровень - сеансовый - является самым высоким для NETBIOS. На этом уровне происходит взаимодействие между NETBIOS и рабочей ПЭВМ. Сеансовый уровень поддерживает идентификацию (пои- менование) и устанавливает сеансы или логические каналы между двумя именами в сети или даже двумя именами в ПЭВМ. Как и сетевой и транспортный уровень, сеансовый уровень в NETBIOS является собственной (специфичной) реализацией. Интерфейс для NETBIOS представляет собой бесплатную открытую информацию, и мно- гие фирмы-продавцы программного обеспечения, такие как Novell или 3Com предлагают для своих сетей эмуляторы NETBIOS. Так как интер- фейс для рабочей ЭВМ остается тем же, для фактических равноправ- ных протоколов в уровнях могут быть использованы любые протоколы. Шестой уровень - уровень представления данных. Он не входит в NETBIOS. Этот уровень ответственен за согласование синтаксиса, который будет использован при передачи информации в и из прик- ладного (седьмого) уровня. Уровень представления данных включает форматы символов, например, EBCDIC и другие форматы для представ- ления чисел или файловых форматов. Он может осуществлять преобра- зование , если формат прикладного уровня несовместим с форматом прикладного уровня другой ПЭВМ или услуги в сети. Уровень представления в Сети ПЭВМ или в ЭКС виртульно явля- ется несуществующим. До некоторой степени, PC-DOS является частью этого уровня, т.к. она представляет собой формат, используемый для взаимодействия с прикладными программами. Однако, PC-DOS не способна узнавать формат других файлов или символов, отличных от ее собственных. Седьмой уровень - прикладной. Он несет ответственность за предоставление конечному пользователю услуг. Примерами прикладных программ являются Программа ЛВС ПЭВМ IBM и Программа соединения IBM PC (см.выше). Программа ЛВС ПЭВМ IBM основывается на PC-DOS 3.Х и NETBIOS. Она дает оконечному пользователю услуги печати и файла в сети. Равноправные протоколы ------------------- ------------------- !7 Прикладной !<-------------------->! ! ! уровень ! ! ! !-----------------! !-----------------! !6 Уровень пред- !<-------------------->! ! ! ставления ! ! ! !-----------------! !-----------------! !5 Сеансовый !<-------------------->! ! ! уровень ! ! ! !-----------------! !-----------------! !4 Транспортный !<-------------------->! ! ! уровень ! ! ! !-----------------! !-----------------! !3 Сетевой !<-------------------->! ! ! уровень ! ! ! !-----------------! !-----------------! !2 Канальный !<-------------------->! ! ! уровень ! ! ! !-----------------! !-----------------! !1 Физический !<-------------------->! ! ! уровень ! ! ! !----------------------------------------------------------------! ! ! ! Физические средства соединения ! ! ! !----------------------------------------------------------------! Рис 1-3. Проект стандарта соединения открытых систем. Обмен данными между уровнями В модели взаимодействия открытых систем каждый уровень обмени- вается данными с уровнем, лежащим ниже его; добавляется заголовок сообщения, а затем пакет данных передается следующему уровню. Этот процесс продолжается до тех пор, пока пакет не достигнет физичес- кого уровня. Тогда оформленный пакет целиком посылается в сеть в виде потока бит. Когда поток бит достигает получающего узла, он становится неоформленным на канальном уровне. Если этот уровень уз- нает пакет данных, и адрес указан правильно, он передаст пакет вверх следующему уровню. Данный процесс продолжается, пока пакет данных не достигнет прикладного уровня. Хотя и возможно посылать тысячи байт данных в секунду через физический и канальный уровень, реальный объем посылаемых данных невелик, вследствие оформления и добавления заголовков. Взаимодействие уровней Как показано на рис.1-4, уровень "N" взаимодействует с уровня- ми "N-1" и "N+1" посредством параметров, которые посылаются в и из этих уровней. Каждый уровень предоставляет лежащему выше уровню услуги. Протоколы усиливают равноправный обмен данными внутри уровня протокола: каждый объект уровня обменивается данными с объектом другого уровня. Уровень протокола передает пакет лежащему под ним уровню, до тех пор, пока он не пройдет через сеть и получающий узел. Уровень "N" знает только то,что происходит на уровнях "N-1" и "N+1". Это означает,что разработчики системы могут легко изменять уровни про- токола для приспособления к новым стандартам и новым протоколам, так как они в минимальной степени влияют на систему. A B A B ^ ^ ^ ^ ! ! ! ! Уровень N+1 ! ! ! ! ---------------!--!----------------!----!------------ ! !Верхняя граница ! ! ! \/ ! \/ ---------- ---------- ! Объект ! C ! Объект ! Уровень N ! уровня !<----->! уровня ! ! ! ! ! ---------- ---------- ^ ^ Нижняя граница ^ ^ ----------------!---!----------------!--!------------ ! ! ! ! ! ! ! ! Уровень N-1 ! ! ! ! ! \/ ! \/ A B A B A - услуги уровня В - параметры С - равноправный протокол Рис. 1-4. Взаимодействие уровней в Соединении открытых систем. Связь с PC-DOS и прикладными программами Коллективное использование информации в ЛВС на основе NETBIOS требует наличия трех важнейших элементов программного обеспечения: 1). PC-DOS 3.Х; 2). самого NETBIOS; 3). подпрограммы переадресатора сообщений. На рис 1-5 показан способ соединения этих трех компонен- тов в систему. NET, доступный из прикладной программы или программы переназначения через прерывание 2AH, является частью Программы ЛВС ПЭВМ IBM. Полная реализация Программы Сети ПЭВМ показана на правой стороне рисунка; файловый процессор и процессор печати показаны на заднем плане. Рабочая станция Спецпроцессор !----------! !-------------! !Прикладная!<---------! !----------------->! Прикладная ! !программа ! ! INT 2AH! ----->! программа ! !----------! ! INT 2FH! ! !-------------! ^ ! ! ! ^ ! ! ! ! ! ! INT 2AH ! ! ! ! INT 21H ! ! ! ! ! \ / ! \!/ ! \ / ---------- ! !----------! ! -------------- ! ! Пр ! ! !Файловый ! ! !Прог- ! ! ! ! ог ! ! !процессор/!<-------->!рам- ! ! !DOS! ра ! ! !процессор ! ! !ма ! ! !3.Х! мма!<---------->! !печати ! ! !пере- ! DOS ! ! ! пе ! !INT 2AH ! ! !<---->!наз- ! 3.Х ! ! ! ре ! \!/ !----------! ! !наче- ! ! ! ! на ! ------- ^ ! !ния ! ! ! ! зн.! ! NET ! ! ! ! ! ! ---------- ------- ! ! !------------! ^ ^ -------------! ! SHARE ! ! !INT 5CH ! !------------! \ / \ / !INT 2AH ! PSPRINT ! \ / \ / \ / -------------- ! ! ------- ^ ---------- ----------- ! NET ! ! ! ! ! ! ------- ! ! PC ! ! ! ^ ! ! BIOS ! ! NETBIOS ! !INT 5CH ! ! ! ! ! \ / \ / ---------- ----------- ----------- ------------- ^ ^ ! ! ! ! ! ! ! NETBIOS ! ! PC ! \ / \ / ! ! ! BIOS ! ----------- ---------- ! ! ! ! ! ! ! ! ----------- ------------- !Аппарат- ! ! Аппарат! ^ ^ !ное ! ! ное ! ! ! !обеспе- ! ! обеспе ! \ / \ / !чение ! ! чение ! ----------- ------------ !ПЭВМ ! ! сети ! ЛВС ! ! ! ! ! ! ! !<----->! Аппарат.! ! Аппаратн.! ----------- ---------- ! обесп. ! ! обеспеч. ! ! сети ! ! ПЭВМ ! ! ! ! ! ----------- ------------ Рис 1-5. Услуга NETBIOS/DOS. Прикладная программа может выполнять одну из трех операций, касающихся сети: пользовательская прикладная программа (напри- мер,система подготовки текстов) вызовет DOS и заставит подпрог- рамму переадресатора послать ввод-вывод в/из спецпроцессора че- рез программу NET; многопользовательская система подготовки тек- стов будет использовать вызовы расширенной версии DOS для блоки- ровки/разблокировки файлов; специализированная прикладная прог- рамма спецпроцесора вызовет NETBIOS непосредственно, используя прерывание 5CH. Четвертая опция для прикладной программы - непо- средственно вызвать файловый процессор/процессор печати (если он реализован) через Программу ЛВС ПЭВМ, используя прерывание 2AH или 2FH. Краткий обзор функций, продоставляемых прерываниями 2FH, 21H и 2AH дан на рис.1-6. В последующих главах будет подробно описано прерывание 5СH NETBIOS. Регистр AX ------ ------ !... ! !,,, ! ! .. ! AH ! ,, ! AL ------ ------ Все величины даны в 16-ричной сис- теме счисления Прерывание 2F ----------------------------------------------- ! ..! ,,, ! ! ! ..! 00 ,, ! Проверка настройки команды NET! ! ..!-----------------------------------------! ! ! ,,, ! ! ! BB! 03 ,, ! Получить адрес спецпроцессора ! ! !-----------------------------------------! ! ..! ,,, ! ! ! ..! 04 ,, ! Получить адрес спецпроцессора ! ----------------------------------------------- Прерывание 2A ----------------------------------------------- ! ..! ! ! 00! Проверка настройки ! !---!-----------------------------------------! ! ..! ! ! 01! Выполнить запрос NETBIOS ! !---!-----------------------------------------! ! ..! ! ! 02! Установить режим печати NET ! !---!-----------------------------------------! ! ..! ! ! 03! Получить статус разделения устройства ! ----------------------------------------------- Прерывание 21 ----------------------------------------------- ! ..! ! ! 3D! Открыть файл,если определено разделение ! !---!-----------------------------------------! ! ..! ,,, ! ! ! ..! 09 ,, ! Переназначить ли устройство? ! ! ..!-----------------------------------------! ! ..! ,,, ! ! ! 44! 0A ,, ! HANDLE местный или удаленный ! ! ..!------------------------------------------ ! ..! ,,, ! ! ! ..! 0B ,, ! Изменить счетчик разделения ! ----------------------------------------------- ! ..! ! ! 59! Получить расширенную ошибку ! !---!-----------------------------------------! ! ..! ! ! 5A! Создать рабочий файл с уникальным именем! !---!-----------------------------------------! ! ..! ! ! 5B! Создать новый файл ! !---!-----------------------------------------! ! ..! ,,, ! ! ! ..! 00 ,, ! Блокировать диапазон байт ! ! 5С!-----------------------------------------! ! ..! ,,, ! ! ! ..! 01 ,, ! Разблокир.диапазон байт ! !---!-----------------------------------------! ! ..! ,,, ! ! ! ..! 00 ,, ! Получить имя машины ! ! 5E!------------------------------------------ ! ..! ,,, ! Установить управляющую строку ! ! ..! 02 ,, ! для печати ! !---!-----------------------------------------! ! ..! ,,, ! Получить элемент ! ! ..! 02 ,, ! списка присваивания ! ! ..!-----------------------------------------! ! ..! ,,, ! ! ! 5F! 03 ,, ! Переназначить устр-во в NET ! ! ..!-----------------------------------------! ! ..! ,,, ! ! ! ..! 04 ,, ! Отменить переназначение ! !---------------------------------------------- ! ..! * ! ! 67! Установить счетчик handle ! !---!-----------------------------------------! ! ..! * ! ! 68! Выполнить (commit) файл ! ----------------------------------------------! * - только для DOS 3.3 и более поздних версий. Рис. 1-6. Функции прерывания 2FH, 21H, 2AH. Реализации 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. Г Л А В А 2 ПРОГРАММИРОВАНИЕ -------------------- Общая процедура Для прикладных программ конечного пользователя, которые на- ходятся над седьмым уровнем модели Соединения открытых систем, не требуется знания NETBIOS. Сетевые прикладные программы, нахо- дящиеся на седьмом уровне (например, обеспечиваемая DOS блоки- ровка файла и записи), требуют большей функциональности, чем предоставляется PC-DOS; для них необходимо детальное знание то- го, что может делать NETBIOS, как он себя ведет, и как взаимо- действовать с ним. Эти прикладные программы обычно требуют пря- мой отправки и получения сообщений между станциями. Примером такой сетевой прикладной програмы будет спецпроцессор, который обслуживает обмен данными (такой как порты RS-232 или контроллер 3274 на базе ПЭВМ) или обеспечивает доступ к периферии, к приме- ру, сменным жекстким дискам большой емкости. Чтобы использовать NETBIOS, к таблице имен сначала добав- ляется имя станции. Последнее представляет собой уникальное имя, под которым данная станция известна в сети. Как альтернативу можно использовать постоянный адрес узла (уникальный 48-битовый адрес в ПЗУ присваивается этому адаптеру), - в этом случае вво- дить "имя" нет необходимости. Однако, присвоение станции фонети- ческого имени делает имя станции более значимым. После назначения имени станции, прикладная программа может установить сеанс с другим именем в сети. Это имя может даже су- ществовать в таблице имен станции, - в этом случае устанавлива- ется "местный" (локальный) сеанс. Однако, обычно, сеансы уста- навливаются с "удаленными" именами, например, сеанс спецпроцес- сора на другой машине. Если сеанс установлен, можно передавать и получать сообще- ния по логическому каналу. Сеанс обеспечивает надежную передачу данных, при которой все сообщения квитируются; в противном слу- чае, можно установить передачу дейтаграмм, - тогда NETBIOS будет посылать сообщения непосредственно на канальный уровень без кви- тирования. Передача дейтаграмм подходит для "широковещательных" сообщений. Интерфейс программирования В настоящем разделе будет рассматриваться интерфейс програм- мирования с точки зрения прикладных программ. В оригинальной Сети ПЭВМ, NETBIOS находится в ПЗУ на плате адаптера. В ЭКС Token-Ring, NETBIOS загружается по подсказке PC-DOS, используя находящийся резидентно в памяти файл COM - NETBEUI (Расширенный пользовательский интерфейс NETBIOS), либо драйвер устройства, используя управляющую Служебную программу ЛВС ПЭВМ. Эта программа также работает с адаптером Сети ПЭВМ с модулированной передачей и с адаптером Сети ПЭВМ с немодулиро- ванной передачей. Рассмотрим сначала NETBEUI. NETBEUI Форматом для NETBEUI является: work0,SAP0,stn0,work1,SAP1,stn1. Параметры имеют следующее значение: work0/work1: Объем рабочей памяти (ОЗУ) ПЭВМ, выделяемый для адаптера, составляет от 1 кбайт до 18 кбайт. Объем в 18 кбайт рекомендует- ся выделить для ПЭВМ, которая также работает и в качестве спецп- роцессора. Так как NETBEUI поддерживает два адаптера, work0 и work1 являются рабочими областями для соответствующих адаптеров. Ограничение состоит в том, чтобы объем work0 плюс work1 был меньше 18 кбайт. Если этот параметр отсутствует, принимается ем- кость в 9 кбайт по умолчанию. SAP0/SAP1: Точка доступа к сервису (точка для соединения между двумя узлами в логическом канале - или уровне 2 - урровне для адапте- ра0/адаптера1). Существуют дополнительные точки доступа к серви- су (SAP), запрашиваемые по OPEN. В поддерживающей прикладной программе (которая не является NETBIOS) может иметься до девяти дополнительных точек доступа к сервису. Величина по умолчанию равна 0. stn0/stn1: Количество дополнительных станций канала (до 9), запрашив- ваемых по неявной OPEN. Он уравнивыает станции с числом дополни- тельных удаленных точек доступа к сервису (не являющихся NETBIOS), с которыми могут одновременно взаимодействовать другие прикладные программы. В памяти рабочей ПЭВМ NETBEUI занимает примерно 46 кбайт оперативной памяти. ДРАЙВЕР NETBIOS входит в Служебную программу ЛВС ПЭВМ IBM в качест- ве драйвера устройства. Прикладные программы (т.е. Программа Се- ти ПЭВМ), записанная в NETBIOS для сети ПЭВМ, будет работать как таковая с эмулятором ЭКС. (См. рис.1-2 о реализации NETBIOS для сети ПЭВМ и ЭКС Token-Ring). По умолчанию, драйвер устройства занимает 23 кбайт оперативной памяти. Со Служебной программой ЛВС ПЭВМ, NETBIOS имеет больше па- раметров, чем в более ранних версиях. Поддержка для параметров NETBIOS более ранних версий осуществляется таким образом, что могут быть использованы все предыдущие параметры (в качестве средства миграции). Одна из новых опций обеспечивает поддержку для высокоско- ростных асинхронных адаптероов - параметртры под названием ENABLE, которые выделяют NETBIOS меньше времени, а большее коли- чество времени - для операций асинхронного адаптера. В таблице на рис.2-1 сведены все доступные параметры. Эти параметры предоставляются посредством DEVICE = DXMT0MOD.SYS в файле CONFIG.SYS и являются позиционно независимыми (в отличие от старой версии NETBEUI). Пример: DEVICE=DXMT0MOD.SYS ST=50 N=40- S=30: осуществляется поддержка 50 станций, 40 имен и 30 сеансов. Ключевое слово Сокра- Допустимые Минимальн. Величина по щение величины величина умолчанию ---------------------------------------------------------------- Станции ST 0-254 * 1 6 Сеансы S 0-254 1 6 Команды C 0-255 1 12 Имена N 0-254 2 17 Откр. при загрузке O Да/Нет - Да Макс.дейтаграмм DG Да/Нет - Нет Закр. при переустановке CR Да/Нет - Нет Размер DHB DS 200-9999 * 200 ** Номер DHB DN 0-9 * - ** Размер получаю- щего буфера R 0-9999 * *** ** Тайм-аут передачи TT 0-20 0 2 Подсчет передач TC 0-10 0 3 DLC Maxout MO 0-9 0 2 DLC Maxin MI 0-9 0 1 Доступ к кольцу RA 0-7 0 0 Доп.точки дос- тупа к сервису ES 0-99 * 0 0 Доп.станции EST 0-99 * 0 0 ---------------------------------------------------------------- ПРИМЕЧАНИЯ: * - Если эта величина будет слишком большой, произойдет сбой в открытом адаптере ** - Если используется величина по умолчанию, Драйвер NETBIOS установит величины этих параметров в зависимости от ресурсов адаптера. *** - Минимальная величина устанавливается адаптером при открытии, а не NETBIOS. DLC - Управляющая процедура Рис 2-1. Параметры драйвера устройства NETBIOS. ПРОГРАММИРОВАНИЕ Прикладная программа, требующая услуг NETBIOS, установит Блок управления сетью (NCB) (соответствующий Блоку управления сообщениями (MCB) в ЭКС Token-Ring) и выдаст прерывание 5CH. На рис.2-2 проиллюстрирована структура Блока управления сетью (NCB) и общее значение каждого поля. Если адаптер не был предваритель- но инициализирован загрузкой Интерфейса поддержки адаптера ЭКС Token-Ring, который называется TOKREUI (Расширенный пользова- тельский интерфейс ЭКС Token-Ring), NETBIOS сделает это автома- тически. ИМЯ ПОЛЯ ДЛИНА (байт) И ЗНАЧЕНИЕ ---------------------------------------------------------------- NCB_COMMAND 1 Поле команды Блока управления сетью (NCB) NCB_RETCODE 1 Поле кода возврата NCB NCB_LSN 1 Поле номера локального сеанса NCB NCB_NUM 1 Поле номера Вашего имени NCB NCB_BUFFER@ 4 Указатель NCB на адрес буфера сообщений (смещение:сегмент) NCB_LENGTH 2 Длина буфера NCB (в байтах) NCB_CALLNAME 16 Имя NCB на местном или удаленном адаптере Если сообщение отправляется по цепочке, первые 2 байта обозначают длину второго буфера Следующие 4 байта обозначают адрес второго буфера NCB_NAME 16 Имя NCB на местном адаптере NCB_RTO 1 Величина тайм-аута получения сообщения NCB_STO 1 Величина тайм-аута отправления сообщения NCB_POST@ 4 Указатель NCB на подпрограмму регистрации (смещение:сегмент) NCB_LANA_NUM 1 Номер адаптера NCB; 00H для первого адаптера, 01H для второго адаптера NCB_CMD_CPLT 1 Поле состояния команды NCB NCB_RESERVE 14 Зарезервированная область NCB ---------------------------------------------------------------- Рис. 2-1. Блок управления сетью (NCB). Далее мы подробно раскажем о каждом поле. NCB_COMMAND Когда прикладная программа выдает NETBIOS команды, она мо- жет сделать выбор: либо ждать, пока они будут завершены, либо прерваться по их завершению. Программа может установить величину 1 для ожидания, либо величину 0 для прерывания. Если выбрана операция ожидания, управление передается следущей команде, толь- ко когда NETBIOS завершит данную команду. Вызывающая подпрограм- ма должна затем проверить регистр AL или поле NCB_RETCODE на состояние завершенной команды. Предпочтительней выбрать, однако, другую опцию - прерывание (неожидание), потому что NETBIOS рабо- тает как фоновая задача, таким образом, что может выстраиваться очередь нескольких команд. Управление возвращается следующей ко- манде прикладной программы, с кодом возврата в AL. Возможными кодами возврата будут: 00H - успешное завершение команды; 03H - неверная команда; 21H - интерфейс занят; 22H - слишком много команд находимтся в очереди; 23H - неверное поле NCB_LANA_NUM; 24H - команда завершена в то время как произошла отмена; 26H - команда не может быть отменена; 4XH - неверное ус- ловие сети; 50-FEH - сбой в адаптере. Величины кода возврата 40H - 4FH являются уникальными для реализации NETBIOS в ЭКС Token-Ring. Прикладная программа может выбрать также следующее: быть прерванной по коду возврата 00H (OK), либо опросить поле NCB_CMD_CPLT (первоначально установленное во время выполнения команды на FFH). Если выбрана опция прерывания, тогда поле NCB_POST@ должно быть установлено как ненулевое (non-zero). Если программа прерывается, она может проверить AL или NCB_RETCODE на конечный код возврата от NETBIOS. NCB_RETCODE NETBIOS отражает код возврата в регистре AL. Возможные ве- личины кода возврата даны выше. Если код возврата не равет 00H, тогда прикладная программа должна предпринять соответствующее действие по восстановлению при ошибках. NCB_LSN После выполнения командв CALL или LISTEN это поле будет по- казывать номер, присвоенный местному сеансу. Это поле должно быть установлено при выдаче команды SEND или RECEIVE для данного сеанса. NETBIOS присваивает номер последовательно, начиная с 254 до 1 (255 или FFH и 0 никогда не используются). NCB_NUM Номер, ассоциированный с именем. NETBIOS возвращает его после запроса прикладной программы ADD NAME или ADD GROUP NAME. Также, как и в случае с полем NCB_LSN, NETBIOS присваивает этот номер последовательно, начиная с 254 до 1. Этот номер должен использоваться при отправлении дейтаграмм и для команды RECEIVE ANY. NCB_BUFFER@ Если этого требует команда, (такая как SEND), NCB_BUFFER@ представляет собой 4-байтовый указатель, который обозначает ад- рес смещения:сегмента того буфера, который использует команда. NCB_LENGTH Длина (в байтах) буфера, на который указывает NCB_BUFFER. Для команды SEND, это фактическое количество посылаемых байт. Для команды RECEIVE, NETBIOS устанавливает его к фактическому количеству принимаемых байт. NCB_CALLNAME 16-байтовое имя сеанса, с которым осуществляется обмен дан- ными. Когда выполняется отправка ообщения по цепочке, первые 2 байта определяют длину, а следующие 4 байта - адрес буфера, в том же формате, что и NCB_BUFFER@. NCB_NAME 16-байтовое имя станции пользователя. Если используется постоянный адрес узла, тогда первые 10 байт устанавливаются как 0, за которыми следует 48-битовый (6-байтовый) адрес узла. NCB_RTO Определяет тайм-аут получения сообщения в шагах, равных 500 мсек, перед истечением времени ожидания команды RECEIVE. Величи- на 0 означает отсутствие тайм-аута. NCB-RTO устанавливается, ес- ли устанавливается сеанс. NCB_STO То же, что и для поля NCB_RTO, на данное поле относится к команде SEND. NCB_POST@ Адрес смещение:сегмент подпрограммы, которая выполняется после того, как NETBIOS завершит команду прерывания (неожида- ния). Прикладная программа должна установить подпрограмму POST, а подпрограмма POST - регистр DS. Стандартная команда возврата прерывания, IRET, исполдьзуется по завершении выполнения прог- раммы POST. Если величина поля NCB_POST@ равна 0, тогда NETBIOS не вызовет подпрограмму POST, и прикладной программе придется управлять полем NCB_CMD_CPLT. NCB_LANA_NUM Используется для обозначения того, какому адаптеру предназ- начена команда. Величина 00H - для первого адаптера, величина 01H - для второго адаптера. NCB_CMD_CPLT Величина FFH показывает, что команда еще не выполнена. Ве- личина 00H показывает, что команда завершена. Как было отмечено выше, ненулевая величина указывает на ошибку. NCB_RESERVE 14-байтовая зарезервированная область, частично используе- мая реализацией NETBIOS в ЭКС Token-Ring. КОМАНДЫ NETBIOS Команды NETBIOS могут быть разделены на 4 группы: общие, команды поддержки имени, поддержки сеанса и команды поддержки дейтаграмм. Общие команды - это команды (не имеющие отношения к обмену данными), которые, главным образом, относятся к самому адаптеру.Команды поддержки имени позволяют прикладным программам ассоциировать (связывать) ресурсы и услуги с логическими имена- ми, а не с дискретными именами. Команды поддержки сеанса позво- ляют прикладной программе устанавливать надежную связь между двумя именами для обмена информацией. Учтите, что сеансовый ка- нал может находиться в самом адаптере, или вместе с именем на удаленном адаптере. Команды поддержки дейтаграмм позволяют тран- слировать короткие (менее 5 байт) сообщения и отправлять некви- тированные сообщения другому имени. Ниже приводится краткий обзор всех возможных команд. За- метьте, что, кроме полей, которые требует каждая команда, должна быть установлена соответствующая величина поля NCB_COMMAND (в шестнадцатиричном счислении). Номер адаптера (0 или 1) должен быть выбран установкой поля NCB_LANA_NUM, и команды NETBIOS воз- вратят результат в поле NCB_RETCODE. Прикладная програма может запросить, чтобы команда была выполнена NETBIOS на фоне других задач, либо может подождать, пока NETBIOS завершит выполнение опции. Некоторые команды не имеют этой опции и рассматриваются как команды типа "ожидать до завершения". Команда/NCB_COMMAND. Функция. ОБЩИЕ КОМАНДЫ RESET/32H. Переустанавливает состояние местного адаптера и очищает таблицы имен и сеансов. Переустановив адаптер, прикладная программа может изменить количество сеансов и количество командных блоков NCB (Блок уп- равления сетью), поддерживаемых NETBIOS. Величины по умолчанию для Сети ПЭВМ равны 6 и 12, соответственно. Эти величины влияют на производительность работы, потому, что, чем больше будет се- ансов и командных блоков NCB, тем меньше окажутся размеры паке- тов, в зависимости от доступной памяти адаптера. Для команды RESET (кроме полей NCB_COMMAND и NCB_LANA_NUM) потребуются только поля NCB_LSN, NCB_NUM. CANCEL/35H. Дает запрос, чтобы была отменена ждущая коман- да, чей Блок управления сети (NCB) найден в NCB_BUFFER@. Можно отменить любую ждущую команду NETBIOS, кроме ADD (GROUP) NAME, DELETE NAME, SEND DATAGRAM, SEND BROADCAST DATAGRAM, SESSION STATUS, CANCEL и RESET. Отмена команды SEND прервет сеанс. Необ- ходимо полу NCB_BUFFER@ (буфер, который отменяется). STATUS/33H (ожидание) B3H (возврат). Дает информацию о сос- тоянии местного или удаленного буфера. Эта команда выполняет диагностирование местных и удаленных адаптеров, даже если удаленная ПЭВМ не может нормально обмени- ваться данными со своим адаптером, либо она "зависла". Для ко- манды требуются поля: NCB_BUFFER@, NCB_LENGTH, NCB_CALLNAME и NCB_POST (только для операции неожидания (прерывания)). Информация, возвращаемая в буфер, для Сети ПЭВМ включает 6-байтовый постоянный адрес узла, 1-байтовое состояние внешних передатчиков управления (переходников) на плате адаптера сети, 1-байтовый результат последней самопроверки, 2-байта, содержащие номер проверки программного обеспечения, 48 байт статистики трафика и ошибок, 26 байт статистики ресурсов адаптера, 2 байта для количества имен в местной таблице и 16 элементов - каждый размером в 18 байт - для таблицы местных имен. Статистика трафика и ошибок, возвращаемая для Сети ПЭВМ, включает 2 байта для периода отчета (в минутах), 2 байта для ко- личества ошибок контроля при помощи циклического избыточного кода, 2 байта для количества ошибок согласования, 2 байта для числа конфликтов, 2 байта для количества экстренно прерванных передач, 4 байта для количества успешно переданных пакетов, 4 байта для количества успешно принятых пакетов, 2 байта для коли- чества повторных передач и 2 байта для количества раз, когда по- лучатель исчерпывал свои ресурсы. Статистика ресурсов адаптера, возвращаемая для сети ПЭВМ, включает 8 байт для зарезервированной области, 2 байта для коли- чества свободных командных блоков, 2 байта для максимального ко- личества отлаженных Блоков управления сетью (NCB), 2 байта для максимального количества свободных командных блоков, 4 заразер- вированных байта, 2 байта для количества ждущих сеансов, 2 байта для максимального количества ждущих сеансов, 2 байта для общего максимального количества сеансов и 2 байта для максимального размера пакета данных сеанса. TRACE/79H (ожидание) F9H (возврат). Только в ЭКС Token-Ring. Команда начинает выполнять трассировку всех команд Блока управления сообщениями (MCB) и некоторых команд Блока уп- равления (CCB), выдаваемых программой NETBIOS. UNLINK/70H. Используется с удаленной загрузкой программы (RPL) для разрыва сеанса с IBMNETBOOT. Эта команда применяется, только если был сделан вызов в IBMNETBOOT во время работы ПЭВМ, т.е. была осуществлена удаленная начальная загрузка. Сеанс с IBMNETBOOT прерывается и прерывается программа переадресации (INT 13). КОМАНДЫ ПОДДЕРЖКИ ИМЕНИ Имена позволяют прикладной программе и ПЭВМ, на которой она работает, быть узнанными другими прикладными программами и ПЭВМ в сети. Длина имен - 16 байт; они вводятся в таблицу местных имен, оригинальная Сеть ПЭВМ с модулированной передачей размеща- ет до 16 имен, в то время, как Служебная программа ЛВС ПЭВМ раз- мещает более 32 имен. Имя, уникальное для ПЭВМ, может также быть частью группы (имени группы). Учтите, что каждой станции всегда присваивается постоянное имя узла (6 байт адреса, за которыми следует 10 нулей) по умолчанию. Прикладная программа может обра- щаться к этому имени, выполняя команду ADAPTER STATUS со звез- дочками (символ *) в поле CALLNAME. Первые 6 байт в буфере возврата показывают адрес адаптера. Как Сеть ПЭВМ, так и ЭКС Token-Ring, используют 6-байтовые адреса узлов. ADD NAME/30H (ожидание) B0H (возврат). Добавляет (уникаль- ное) 16-символьное имя в таблицу имен (возврата). NETBIOS выполняет передачу сообщения, чтобы удостовериться, что это имя является уникальным. Если применяется опция неожи- дания, команде потребуется поле NCB_POST@. Коды ошибок будут возвращены, - они показывают на заполненную таблицу, дублирующи- еся имя, имя, не являющееся уникальным, и т.п. ADD GROUP NAME (ожидание) B6H (возврат). Добавляет имя группы в таблицу имен. NETBIOS осуществляет передачу сообщения, чтобы удостове- риться, что это имя не используется в качестве уникального на другой ПЭВМ. Поля NCB и условия ошибок такие же, как и для кро- манды ADD NAME. Так как имена могут иметь длину до 16 байт, а фактический размер адреса равен (на канальном уровне) только 6 байт, NETBIOS получит адрес группы для себя, используя один из двух способов. Первый способ требует применения следующей функции: group_name = 000-0 concat (N1 xor N2...N5 xor N6) concat FF где N1...N5 являются с первого по пятое символьными полями имени, а N6 - последним символом имени. Второй способ - получить адрес группы из постоянного имени узла, используя следующую функцию: group_name = 0000 concat (ID3 ID2 ID1) concat FF где ID3...ID1 являются байтами низкого порядка постоянного имени узла. Эти адреса, полученные NETBIOS, обычно являются недоступны- ми для прикладной программы, но могут быть вычислены с помощью формул. Вышеприведенные формулы были выбраны, чтобы снизить до минимума риск того, что два различных 16-байтовых имени будут "обррублены" до одного и того же 6-байтового адреса группы. DELETE NAME/31 (ожидание) B1H (возврат). Стирает имя из таблицы имен. Эта команда убирает имя, введенное командой ADD NAME или ADD GROUP NAME, из таблицы местных имен. Команда DELETE NAME обычно выполняется после завершения сеанса с помощью команды HANG UP (см.ниже). Если все еще имеются активные сеансы, NETBIOS отложит выполнение команды стирания имени, пока не будут завер- шены все активные сеансы. Эта команда, (если применяется опция возврата (неожидания), требует наличия поля NCB_POST@. КОМАНДЫ ПОДДЕРЖКИ СЕАНСА Эти команды образуют ядро NETBIOS, они несут ответствен- ность за фактическую передачу информации (до 65535 байт по зап- росу) в сети. Прикладная программа использует команды поддержки сеанса для установления канала между двумя любыми именами в се- ти, или даже внутри самой ПЭВМ. Заметьте, что имена используются для инициации процесса, а NETBIOS возвращает номер в поле NCB_LSN, которое и будет применяться с этого момента далее. CALL/10H (ожидание) 90H (возврат). Открывает сеанс с другим именем, определенным полем NCB_CALLNAME. Команда CALL инициирует сеанс с именем, определенным в поле NCB_CALLNAME, используя местное имя, предоставляемое полем NCB_NAME. При вызове (командой CALL) другого имени, оно уже дол- жно установить команду LISTEN. NETBIOS возвращает номер сеанса в поле NCB_LSN. Необходимые для команды поля Блока управления сети (NCB) включают поля: NCB_RTO, NCB_STO и NCB_POST@ (если выбрана опция возврата (неожидания)). LISTEN/11H (ожидание) 91H (возврат). Позволяет осуществлять установку сеанса с именем, определенным в поле NCB_CALLNAME. Выполенение команд CALL, LISTEN позволяет устанавливать се- анс с именем в поле NCB_CALLNAME и с именем в поле NCB_NAME. Поле NCB_CALLNAME может быть установлено с символами "*", - в этом случае из команды CALL принимается любое имя. Имя, кото- рое инициирует команду CALL, затем возвращается в поле NCB_CALLNAME. Важно учесть, что уоманда LISTEN занимает ввод се- анса. Требуемые поля включают: NCB_NAME, NCB_RTO, NCB_STO и поле NCB_POST@ (если используется опция неожидания). HANG UP/12H (ожидание) 92H (возврат). Закрывает сеанс с другим именем. Эта команда завершает сеанс и все ждущие кеоманды RECEIVE. Команда HANG UP требует поля NCB_POST@ для опции неожидания. SEND/14H (ожидание) 94H (возврат). Посылает данные по номе- ру сеанса, показанному номером местного сеанса (LSN). SEND NO_ACK/71H (ожидание) F1H (возврат). Обеспечивает ко- манду SEND, которая не требует NO_ACK NETBIOS для передачи кви- тирования данных. Доступна только в версии NETBIOS 2.2 и выше. Команда SEND (надежно) передает буфер емкостью до 65535 байт, на который указывает NCB_BUFFER@ посредством сеанса, пока- занного NCB_LSN. Несколько команд SEND могут выстраиваться в че- редь. Если команда SEND не может завершиться, сеанс заканчивает- ся и должен быть переустановлен. CHAIN SEND/17H (ожидание) 97H (возврат). Подобна команде SEND, за исключением того, что данные берутся из буферов для указанного числа байт. Вместе в цепочку могут быть связаны два буфера. CHAIN SEND NO_ACK/72H (ожидание) F2H (возврат). Обеспечива- ет команду CHAIN SEND, которая не требует NETBIOS для передачи квитирования данных. Доступна только в версии NETBIOS 2.2 и выше. NETBIOS посылает буферы как одно конкатенированное сообще- ние, предел для размера которого состоявляет 65535 байт. Поле NCB_CALLNAME используется для определения длины (пер- вые 2 байта) и адреса (последующие 4 байта) второго буфера. Не- обходимые для команды поля включают: NCB_BUFFER@, NCB_LENGTH, NCB_CALLNAME (формат длины 0000H, формат адреса 00000000H) и по- ле NCB_POST@, если используется опция неожидания. RECEIVE/15H (ожидание) 95H (возврат). Получает данные из определенной области. Могут быть определены величины тайм-аута. Эта команда устанавливает адаптер для получения данных из определенной области. Если объем получаемых данных превышает доступный размер буфера, будет возвращен код 06H в поле NCB_RETCODE. Требуемые поля включают: NCB_BUFFER@, NCB_LENGTH, и поле NCB_POST@, если используется опция неожидания. RECEIVE ANY/16H (ожидание) 96H (возврат). Получает данные от любой станции, с которой был установлен сеанс. Подобна коман- де RECEIVE, за исключением того, что эта команда позволяет полу- чать данные от любого сеанса. Поле NCB_NUM (как возвращеное из команд ADD NAME или ADD GROUP NAME) должно быть использовано вместо имени. Требуемые поля такие же как и для команды RECEVE. SESSION STATUS/34H (ожидание) B4H (возврат). Получает сос- тояние всех активных сеансов для имени станции. Эта команда возвращает информацию о состоянии всех активных сеансов ддя данного локального имени (NCB_NAME) или для всех локальных имен (если символ звездочки (*) является первым байтом поля NCB_NAME). Требуемые поля включают NCB_BUFFER@, NCB_LENGTH, и NCB_POST@, если используется опция неожидания. Формат возвращаемой информации о состоянии является следую- щим: 1 байт для количества сеансов, о которых дается отчет, 1 байт для количества сеансов с данным именем, 1 байт для количес- тва ждущих команд дейтаграмм, 1 байт для количества ждущих ко- манд RECEIVE ANY, 36 байт для информации о сеансе, которая вклю- чает: 1 байт для номера местного сеанса, 1 байт для состояния сеанса (01H - ждущая команда LISTEN, 02H - ждущая команда CALL, 03H - установка сеанса, 04H - ждущая команда HANG UP, 05H - за- вершена команда HANG UP, 06H - экстренное прерывание сеанса); 16 байт для местного имени, 16 байт для удаленного имени, 1 байт для количества ждущих команд RECEIVE и 1 байт для количества ждущих команд SEND и CHAIN SEND. КОМАНДЫ ПОДДЕРЖКИ ДЕЙТАГРАММ Последняя группа команд NETBIOS предназначена для дейтаг- рамм. Дейтаграммы позволяют пользователю посылать неквитирован- ные собщения размером до 512 байт в имя, или имя группы, или же передавать сообщение всем именам. SEND DATAGRAM/20H (ожидание) A0H (возврат). Посылает дей- таграмму в уникальное имя или имя группы в местном или удаленном узле. Данная команда посылает дейтаграмму в имя или групповое имя. Такое имя должно быть установлено для этой команды. Требу- ются поля: NCB_BUFFER@, NCB_LENGTH, NCB_NUM и поле NCM_POST@, если используется опция неожидания. SEND BROADCAST DATAGRAM/22H (ожидание) A2H (возврат). Посы- лает сообщение всем именам, которые имеют ждущую команду RECEIVE DROADCAST DATAGRAM. Требуются те же поля, что и для команды SEND DATAGRAM. RECEIVE DATAGRAM/21H (ожидание) A1H (возврат). Получает дейтаграмму от любого имени в сети. Эта команда получает любую дейтаграмму, адресованную ло- кальному имени или имени группы в данной ПЭВМ. Требуются те же поля, что и для команды SEND DATAGRAM. Если величина поля NCB_NUM установлена как FFH, то дейтаграма может быть получена от любого имени для любого из местных имен. RECEIVE BROADCAST DATAGRAM/23H (ожидание) A3H (возврат). Получает дейтаграмму от любого имени,которое выдает команду SEND BROADCAST DATAGRAM. Эта команда получает любую переданную широ- ковещательную дейтаграму. Требуемые поля совпадают с полями для команды SEND DATAGRAM. На рис.2-3 дан список всех возможных кодов ошибок, которые возвращает NETBIOS, когда прикладная программа использует Блок управление сетью (NCB) и прерывание 5CH. Величина (в 16-ричной Значение системе счисления) ---------------------------------------------------------------- 00H Хороший возврат, команда завершена Неправильная длина буфера для команд SEND DATAGRAM, SEND BROADCAST, 01H ADAPTER STATUS или SESSION STATUS. 03H Неверный код команды 05H Истек период тайм-аута команды Полученное сообщение было частичным, т.к. была недостаточна длина 06H буфера получения Определен номер сеанса, который не 08H является активным В адаптере нет достаточного места 09H для сеанса 0AH Сеанс закрыт 0BH Команда не отменена Дублирующееся имя в таблице 0DH местных имен 0EH Таблица местных имен переполнена 0FH Имя, которое стирается, является активным в сеансе 11H Переполнена таблица местных сеансов Открытый сеанс был отменен, т.к. нет ожидающей команды LISTEN в удаленной 12H ЭВМ. 13H Неверный номер имени Не могу найти вызванное имя или 14H ответа не существует 15H Имя в местной таблице не найдено 16H Имя где-то используется Имя стерто без наличия ожидающих 17H команд для этого имени 18H Аварийное завершение сеанса NETBIOS обнаружил два или более одинаковых имени, которые используются 19H в сети 1AH Получен несовместимый протокол пакета 21H Интерфейс занят Количество ожидающих команд слишком 22H велико 23H Неправильный номер в поле NCB_LANA_NUM Команда завершена до запроса об отмене 24H или такой команды не существует 26H Команду отменять нельзя 4XH Неопределяемая ошибка в сети 50-FEH Произошел сбой в адаптере FFH Команда все еще ожидает ---------------------------------------------------------------- Рис 2-3. Коды возврата ошибок NETBIOS. NETBIOS в ЭКС TOKEN-RING Как было замечено в Главе 1, NETBIOS в адаптере оригинальной Сети ПЭВМ (с модулированной передачей) не реализует стандарт 802.2 LLC или MAC. В ЭКС Token-Ring NETBIOS был присво- ен функциональный адрес 00000080H, чтобы он удовлетворял требо- ваниям стандарта 802.2. При рабочей программе NETBIOS, все адаптеры с набором функциональных адресов получат все кадры, предназначенные для данного адреса. Величина точки доступа к сервису по умолчанию F0H. Кадры, предназначенные для управляю- щей процедуры (DLC) точки доступа к сервису F0H, маршрутизируются в программу NETBIOS, вне зависимости от того, получены ли они пос- редством обнаружения функционального адреса, или же обнаружения особого адреса узла. NETBIOS в Token-Ring использует свойство кольца передавать шириковещательные сообщения. Во всех случаях, кроме одного, кад- ры посылаются как "ограниченное широковещательное сообщение", то есть промежуточные звенья (мосты) выдают каждому кольцу в мно- го-мостовой кольцевой сети только один кадр. Бит широковещатель- ного сообщения и бит ограниченного широковещательного сообщения в поле управления маршрутизацией установлены как 1. В другом случае,кадр посылается как общее "широковещатель- ное сообщение", - то есть кадр будут ретранслироывать все мосты. Бит сообщения в поле управления маршрутизацией будет установлен как1, а бит ограниченного широковещательного сообщения - как 0. Рассмотрим NETBIOS в Token-Ring. Инициализация драйвера адаптера может быть осуществлена - явно - прикладной программой, в которой используется установленный коллективный адрес в ОЗУ, а приложения ошибок определяются либо прикладной программой, ли- бо - неявно - программой NETBIOS, когда встречается RESET или первый Блок управления сетью (NCB). В нашем случае,бу- дут использоваться коллективные адреса в ОЗУ D8000H/D4000H для адаптеров 00/01, а приложения ошибок будет определять сама программа NETBIOS. OPEN CCB является опциональным вызовом NETBIOS, который ис- пользуется для определения набора особых параметров программы NETBIOS. OPEN CCB может быть явно выполнен прикладной програм- мой;он должен быть запрошен перед первым Блоком управления сетью (NCB) и после того, как будет загружен NETBIOS. OPEN CCB может быть явно выполнен RESET или первым Блоком управления сетью (NCB). Типичной последовательностью инициализации будет: драйвер устройства NETBIOS запрашивает в ЭКС Token-Ring драйвер DIR.INITIALIZE, DIR.OPEN.ADAPTER, DIR.STATUS, DLP.OPEN.SAP (с точкой доступа к сервису (SAP), установленной как F0H), DIR.SET.FUNCTIONAL.ADDRESS, DLP.MODIFY и SET.TIMER. Приведем последовательность событий, происходящих в NETBIOS при запрашивании прикладной программой команды NETBIOS (через Блок управления сетью) для установки сеанса: драйвер устройства NETBIOS запрашивает в ЭКС драйвер DIR.SET.TIMER (для ответа с узнанным именем), запрашивает DIR.TRANSMIT.UI (широковещательное сообщение NAME.QUERY), возвращает непосредственный код возврата (если не была установлена опция неожидания для Блока управления сети - NCB), получает (RECEIVE) данные ответа (имя узнано), зап- рашивает DIR.CANCEL.TIMER, запрашивает DIR.FREE.BUFFER, запра- шивает DLC.OPEN.STATION (устанавливает станцию канала), запраши- вает DLC.CONNECT_STATION (соединяет узлы), запрашивает DIR.TRANSMIT.FRAME (посылает инициализированное сообщение), по- лучает (RECEIVE) данные ответа (сеанс подтвержден) и возвращает конечный код возврата NCB. Различия в реализации Между NETBIOS в оригинальной Сети ПЭВМ и эмуляцией Служеб- ной программы ЛВС ПЭВМ имеются некоторые неявные различия. Реа- лизация Служебной программы содержит некоторые усовершенствова- ния, которые не должны использоваться, если требуется совмести- мость с сетью ПЭВМ. Ниже приводятся основные различия. NETBIOS в NETBIOS в оригинальной Служебной программе Сети ПЭВМ с модулиро- ванной передачей ---------------------------------------------------------------- 254 каналов на адаптер 16 254 сеансов на адаптер 32 254 имен 17 255 ожидающих команд 32 ---------------------------------------------------------------- Эмулятор NETBIOS в ЭКС имеет дополнительные коды возврата NETBIOS. Когда следующие коды возврата устанавливаются в Блоке управления сетью, эмулятор также возвращает соответствующую ин- формацию о состоянии в поле RESERVE Блока управления сетью (NCB). Расширенный код возврата Значение ---------------------------------------------------------------- 4EH Кольцо в нерабочем состоянии 4FH Ошибка постоянного состояния кольца F7H Ошибка в явном INITIALIZE F8H Ошибка в неявном OPEN F9H Внутренняя ошибка TOKREUI FAH Машинная проверка адаптера FBH Нет эмулятора NETBIOS FCH Сбой OPEN адаптера или OPEN_SAP FDH Неожиданное закрытие адаптера ---------------------------------------------------------------- Как адаптер Сети ПЭВМ (с модулированной и немодулированной передачей), так и адаптер ЭКС Token-Ring могут сосуществовать в одной и той же ПЭВМ. Если имеется адаптер Сети ПЭВМ, и он нахо- дится в рабочем состоянии, все команды Блока управления сетью (NCB), запрошенные для этого номера адаптера, будут маршрутизи- рованы к нему. Если адаптер Сети ПЭВМ не присутствует, то все запрошенные для этого номера адаптера команды NCB маршрутизиру- ются к программе NETBIOS в Token-Ring. Пользователь может сам выбрать, какой адаптер является первичным (00), а какой - вто- ричным (01). Драйвер протокола Драйвер протокола Сети ПЭВМ IBM - новый продукт, выпущенный одновременно с Personal System/2. Драйвер протокола обеспечивает эмуляцию NETBIOS для новых адаптеров Сети ПЭВМ (с модулированной передачей) (как Microchannel, так и PC), которые также были выпущены одновременно с PS/2, для поддержания совместимости с адаптером оригинальной Сети ПЭВМ. Однако, драйвер протокола не будет обмениваться данными с адаптерами новой сети ПЭВМ, работа- ющей со Служебной программой ЛВС ПЭВМ. Еще одно различие заклю- чается в количестве поддерживаемых имен и сеансов - до 62 и до 64 соответственно. Серьезным недостатком драйвера протокола является то, что, в отличие от Служебной программы ЛВС ПЭВМ, он не обеспечивает интерфейс управления логическим каналом (LLC) (второй уровень стандарта соединения открытых систем) стандарта IEEE 802.2. Это означает, что некоторое программное обеспечение, не принадлежа- щее NETBIOS, например APPC/PC, не сможет работать в сети с драй- вером протокола. Как мы можем увидеть, драйвер протокола имеет несколько ог- раниченный характер. Он существует только как механизм сохране- ния обратной совместимости с NETBIOS в оригинальной установке Сети ПЭВМ (PC Network) с модулированной передачей. Г Л А В А 3 ПРОТОКОЛЫ И ФОРМАТЫ ПАКЕТОВ ------------------------------- Общий обзор протоколов NETBIOS был дан в Главе 1. Основным ти- пом операции для обмена информацией между двумя именами в сети яв- ляется следующий: 1). добавить имена в таблицу местных имен соот- ветствующей прикладной программы на данной ПЭВМ; 2). установить се- анс между двумя именами, используя команды CALL и LISTEN; 3). пере- дать данные, используя команды SEND и RECEIVE; 4). завершить сеанс используя команды HANG UP или RESET. На рис 3-1 показана общая син- хронизация обменов пакетами. 1. УСТАНОВКА СЕАНСА Инициатор Ответчик ----------> Открыть запрос -----------> <---------- Открыть ACK <----------- ----------> Запрос сеанса -----------> <---------- Сеанс принят <----------- или отвергнут 2. ПЕРЕДАЧА ДАННЫХ Инициатор Ответчик ----------> Данные -----------> <---------- ACK или NACK <----------- ----------> Данные -----------> ----------> Данные (нет -----------> повторной передачи ACK) <---------- ACK или NACK <----------- 3. ЗАВЕРШЕНИЕ СЕАНСА Инициатор Ответчик <---------- Закрыть <----------- ----------> Закрыть -----------> <---------- Закрыто <----------- ПРИМЕЧАНИЕ: ACK - символ подтверждения; NACK - символ отрицательного квитирования. Рис.3-1. Общая схема синхронизации пакетов сеанса. В данной главе будет рассказано о фактической реализации про- токолов и форматов пакетов для переноса информации между станциями в NETBIOS. В качестве примеров приводятся два типа сети: оригиналь- ная сеть ПЭВМ IBM с модулированной передачей и ЭКС IBM PC Token-Ring. Сеть ПЭВМ (PC Network) На рис 3-2 показана зависимость между различными протоколами, реализованными в апдаптере оригинальной Сети ПЭВМ IBM с модулиро- ванной передачей. Услуги ------ Модель OSI Сеанс Имя Дейтаграмма Состояние ! ! ! ! !---------------! ! ! ! ! ! ! \ / \ / \ / \ / ! Сеансовый ! SMP------->NMP<------ UDP ! ! ! ! ^^<<--------!-----------DMP !---------------! - - - ! - - - - ! - - - - - ! - - - - - -!- - - ! ! \ / ! \ / ! ! Транспортный ! RSP<-------! DTP<----------! ! ! ! ! !---------------! - - - ! - - - - - - - - - - ! - - - - - - - - - ! ! ! ! ! Сетевой ! !-------->PTP<--------! ! ! ! !---------------! - - - - - - - - -!- - - - - - - - - - - - - - - ! ! \ / ! Канальный ! LAP ! ! ! !---------------! - - - - - - - - -!- - - - - - - - - - - - - - - ! ! ! ! Физический ! \ / ! ! ШИРОКОПОЛОСНАЯ ЛВС !---------------! Условные обозначения: SMP - Протокол управления сеансами UDP - Протокол пользовательских дейтаграмм NMP - Протокол управления именами DMP - Протокол диагностирования и управления RSP - Протокол надежного потока DTP - Транспортный протокол дейтаграмм PTP - Протокол передачи пакетов LAP - Протокол доступа к каналу Рис 3-2. Отношения протоколов Сети ПЭВМ. Команды сеансового уровня/действия протокола В эом разделе рассматриваются предпринимаемые NETBIOS действия для различных команд Блока управления сетью (NCB). Команды и прото- колы ассоциируются с Протоколом управления сеансами (SMP) Сети ПЭВМ IBM. Ниже дается высокоуровневое описание протоколов, используемых Протоколом управления сеансами - SMP. Также приводятся форматы па- кетов, если на них делается ссылка впервые. Форматы используются NETBIOS на Сети IBM PC с модулированной передачей; в зависимости от конкретной реализации, эти пакеты могут отличаться друг от друга. Все пакеты, полученные NETBIOS, уже прошли проверку при помощи избыточного циклического кода и узнавание адреса на канальном уровне. В широкополосной сети ПЭВМ IBM, это осуществляется контрол- лером CSMA Intel 82586; в ЭКС Token-Ring - собственными драй- верами протокола IBM. ADD NAME NETBIOS проверяет имя, чтобы удостовериться, что оно правильно и продолжает работу, если это так. Если он не находит имени в таб- лице местных имен, он передает широковещательный пакет "заявка на имя" (рис 3-3) несколько раз, чтобы все станции смогли увидеть этот запрос. Если ответ будет получен, пакет будет в форме, показанной на рис 3-4, если нет - имя будет добавлено в таблицу местных имен. DELETE NAME Как и в случае с ADD NAME, NETBIOS проверит правильность имени и продолжит работу, если все верно. Если он обнаружит неактивный сеанс, ассоциированный с этим именем, он завершит работу. В против- ном случае, NETBIOS поставит запрос на удаление имени в очередь, пока "подсчет сеансов" (активных сеансов) будет равен нулю, - в этом случае имя будет затем удалено из таблицы имен. ---------------------------------------------------------------- !НАЧАТЬ!АДРЕС !ИСХОДН!ДЛИНА!Величина!Заявка=10H!#пакетов !ИД !УДАЛЕН!НАЗНАЧ!АДРЕС ! !5000H !Отмена=A0H!для получ!СОЕДИН ... ! 7EH ! 6 ! 6 ! 2 ! ! ! 0?H ! 2 ---------------------------------------------------------------- ---------------------------------------------------------------- !Велич !Все !Велич !Все !Величина!Велич !ИМЯ НАЗН !ПРЕДЫД. !0202H !равно !0400H !равно!10XXH !0000H !ASCII !ИД СОЕДИН ... ! ! 2 ! ! 4 ! ! ! 16 !СЕТИ 2 ---------------------------------------------------------------- ---------------------------------------------------------------- ! ПОДСЧЕТ ПОВ- ! ИД СОЕДИНЕН ! ИД НА- ! ИСХОДН ! ПРЕДЫДУЩ. ! ТОРН.ПЕРЕДАЧИ! ИСХОДН УЗЛА ! ЗНАЧЕН. ! ИД ! ИД УЗЛА ... ! 2 ! 2 ! 6 ! 6 ! 6 ---------------------------------------------------------------- ----------------------- ! СRC ! КОНЕЦ-КАДРА ! ! ! Величина 7EH ! ! 4 ! ! ----------------------- Рис. 3-3. Пакет "заявка на имя/отмена имени" ---------------------------------------------------------------- !НАЧАТЬ!АДРЕС !ИСХОДН!ДЛИНА!Величина!Величинва !#пакетов !ИД !УДАЛЕН!НАЗНАЧ!АДРЕС ! !6000H !30H !для получ!СОЕДИН ... ! 7EH ! 6 ! 6 ! 2 ! ! ! 0?H ! 2 ---------------------------------------------------------------- ---------------------------------------------------------------- !Все !Причина поче-!Все !Величина!Все !Велич!Велич!ИМЯ НАЗН !равно !му NAK пакета!равно!0400H !равно!10XXH!0000H!ASCII ... ! 2 ! 1 ! 1 ! ! 4 ! ! ! 16 ---------------------------------------------------------------- -------------------------------------- ! ИД СОЕДИНИНЕН ! СRC ! КОНЕЦ-КАДРА ! ! УЗЛА НАЗНАЧ. ! 4 ! Величина 7EH ! ! 2 ! ! ! -------------------------------------- Рис. 3-4. Пакет ответа на заявку на имя ПРИМЕЧАНИЕ: Здесь и далее: ИД - идентификатор; CRC - контроль циклическим избыточным кодом CALL NETBIOS сначала осуществляет проверку, чтобы убедиться в том, что местное имя в таблице имен найдено. Если это так, NETBIOS про- верит удаленное имя в таблице имен, и, если оно не будет найдено, передаст пакет "запроса на имя" в сеть (рис.3-5). Если оно найдено, или узел отвечает на запрос об имени, то тогда получателю посыла- ется пакет "запрос на сеанс" (рис.3-6), и NETBIOS выполнит команду LISTEN для ожидания ответа. Если пакет "сеанс принят" (рис.3-7) бу- дет получен до истечения времени ожидания (тайм-аута) команды LISTEN, тогда NETBIOS установит флаг (установленного) сеанса в таб- лице сеансов,возвратит номер местного сеанса (LSN) и вернет состоя- ние завершения команды (CMD_CPLT) прикладной программе. ---------------------------------------------------------------- !НАЧАТЬ!АДРЕС !ИСХОДН!ДЛИНА!Величина!Величина0H!#пакетов !ИД !УДАЛЕН!НАЗНАЧ!АДРЕС ! !5000H !10H !для получ!СОЕДИН ... ! 7EH ! 6 ! 6 ! 2 ! ! ! 0?H ! 2 ---------------------------------------------------------------- ---------------------------------------------------------------- !Велич !Все !Велич !Все !Величина!Велич !ИМЯ НАЗН !ИСХОДН. !0202H !равно !0100H !равно!10XXH !XX10H !ASCII !ИМЯ ASCII ... ! ! 2 ! ! 4 ! ! ! 16 ! 16 ---------------------------------------------------------------- ---------------------------------------------------------------- !ИД СОДИН ПОВ-!ПОДСЧЕТ ПОВТОР!ИД СОЕДИН! ИД. ! ИСХОДН. !ПРЕДЫД СЕТИ !ПЕРЕДАЧН УЗЛА !ИСХ.УЗЛА ! НАЗНАЧ. ! ИД ... ! 2 ! 2 ! 2 ! 6 ! 6 ---------------------------------------------------------------- -------------------------------------- !ИД ПРЕДЫДУЩ. ! СRC ! КОНЕЦ-КАДРА ! !УЗЛА ! ! Величина 7EH ! ! 6 ! 4 ! ! -------------------------------------- Рис. 3-5. Пакет "запрос на имя" ----------------------------------------------------------------- !НАЧАТЬ!АДРЕС!ИСХОДН!ДЛИНА!Велич!00-07H=нет опроса!#пакетов !ИД !УДАЛЕН!НАЗН !АДРЕС ! !0040H!80-0FH=Послать !для получ!СОЕД ... ! 7EH ! 6 ! 6 ! 2 ! !Вернуть пакет ! 0?H ! 2 ----------------------------------------------------------------- ---------------------------------------------------------------- !Послед!Послед!Велич !Размер !Велич!Велич!ИСХОДН. ! ИМЯ НАЗН !сеанса!ов ACK!0001H !пакета !0000H!1010H!ИМЯ ASCII! ASCII ... !# 1 ! # 1 ! !ответа 2! ! ! 16 ! 16 ---------------------------------------------------------------- -------------------------------------- ! ИД СОЕДИНИНЕН ! СRC ! КОНЕЦ-КАДРА ! ! УЗЛА НАЗНАЧ. ! 4 ! Величина 7EH ! ! 2 ! ! ! -------------------------------------- Рис. 3-6. Пакет запроса на сеанс. ----------------------------------------------------------------- !НАЧАТЬ!АДРЕС!ИСХОДН!ДЛИНА!Велич!00-07H=нет опроса!#пакетов !ИД !УДАЛЕН!НАЗН !АДРЕС ! !0040H!80-0FH=Послать !для получ!СОЕД ... ! 7EH ! 6 ! 6 ! 2 ! !Вернуть пакет ! 0?H ! 2 ----------------------------------------------------------------- ------------------------------------------------------------------ !Послед!Послед!Велич!Размер !Велич!Велич!ИД СОЕДИН!CRC!КОНЕЦ-КАД! !сеанса!ов ACK!0002H!пакета !0000H!1010H!УЗЛА НАЗН! 4 !РА Велич ! !# 1 !# 1 ! !ответа 2! ! ! 2 ! ! 7EH ! ------------------------------------------------------------------ Рис. 3-7. Пакет "сеанс принят". LISTEN/LISTEN ANY Сначала NETBIOS осуществляет проверку с целью удостовериться, что местное имя в таблице имен найдено. Если это так, NETBIOS про- веряет наличие места в таблице сеансов и ждет пакета "запрос на се- анс". Если источник этого пакета совпадает с удаленным именем, оп- ределенным прикладной программой, то выполняется команда LISTEN. Пакет "сеанс принят" будет возвращен в источник, в таблице сеансов будет установлен флаг (установленного) сеанса, будет установлен но- мер местного сеанса (LSN) и прикладной программе будет возвращено соответствующее состояние. Если это запрос LISTEN ANY, тогда любой пакет "запрос на сеанс" будет удовлетворять запросу. HANG UP Если запрошенный номер сеанса верен и сеанс является "откры- тым", NETBIOS завершит любые команды RECEIVE, а затем окончит се- анс. Если ожидающей является команда SEND, то NETBIOS ждет, пока не будет завершено выполнение команды SEND, либо пока не исте- чет время ожидания (т.е. наступит тайм-аут). SEND/CHAIN SEND Если номер сеанса верен и сеанс "открыт", NETBIOS пошлет пакет данных сеанса (рис.3-8), на который указывает NCB_BUFFER@, в узел назначения и ждет пакет квитирования (рис.3-9), либо - по наступле- нии тайм-аута - возвращает соответствующее состояние прикладной программе. ----------------------------------------------------------------- !НАЧАТЬ!АДРЕС!ИСХОДН!ДЛИНА!Велич!00-07H=нет опроса!#пакетов !ИД !УДАЛЕН!НАЗН !АДРЕС ! !4000H!80-0FH=Послать !для получ!СОЕД ... ! 7EH ! 6 ! 6 ! 2 ! !Вернуть пакет ! 0?H ! 2 ----------------------------------------------------------------- ---------------------------------------------------------------- !Последов!Последов!80-F0H = Конец! ПОЛЕ ДАТЫ !сеанса #!ACK # !сообщения ! ... ! 1 ! 1 ! ! Переменная длина ---------------------------------------------------------------- -------------------------------------- ! ИД СОЕДИНИНЕН ! СRC ! КОНЕЦ-КАДРА ! ! УЗЛА НАЗНАЧ. ! 4 ! Величина 7EH ! ! 2 ! ! ! -------------------------------------- Рис.3-8. Пакет данных сеанса. ----------------------------------------------------------------- !НАЧАТЬ!АДРЕС!ИСХОДН!ДЛИНА!Велич!00-07H=нет опроса!#пакетов !ИД !УДАЛЕН!НАЗН !АДРЕС ! !0040H!80-0FH=Послать !для получ!СОЕД ... ! 7EH ! 6 ! 6 ! 2 ! !Вернуть пакет ! 0?H ! 2 ----------------------------------------------------------------- ---------------------------------------------------------------- ! Послед ! Послед ! Все ! ИД СОЕДИН ! CRC ! КОНЕЦ-КАДРА ! ! сеанса ! ов ACK ! равно ! УЗЛА НАЗНАЧ. ! ! Величина 7EH ! ! # 1 ! # 1 ! 1 ! 2 ! 4 ! ! ---------------------------------------------------------------- Рис. 3-9. Пакет квитирования. RECEIVE/RECEIVE ANY Если номер сеанса верен и сеанс "открыт", NETBIOS ждет особое сообщение сеанса в течение времени тайм-аута пакета получения, ус- тановленного прикладной программой. Если NETBIOS получает пакет се- анса в течение времени тайм-аута, то квитирование посылается обрат- но источнику и данные передаются буферу, на который указывает NCB_BUFFER@. NETBIOS также выполняет проверку, чтобы убедиться, что длина получаемого сообщения не превышает установленную NCB_LENGTH длину буфера. Действие команды RECEIVE ANY сходно с действием ко- манды RECEIVE, за исключением того, что в первом случае сообщение может быть принято от любого имени. SEND DATAGRAM/SEND BROADCAST DATAGRAM Для команды SEND DATAGRAM, NETBIOS сравнивает номер запрошен- ного имени с образцом в таблице имен. Если имя найдено, NETBIOS по- сылает пакет дейтаграмм (рис.3-10) в узел назначения.Для BROADCAST, проверяется номер имени, и, если он верен, дейтаграмма посылается всем узлам в сети. Дейтаграмма посылается только один раз, и поле адреса на канальном уровне устанавливается как единица. RECEIVE DATAGRAM/RECEIVE BROADCAST DATAGRAM Если NETBIOS находит номер имени в таблице местных имен, он будет ожидать появления дейтаграммы (отличной от широковещательной). Прикладная программа может установить особое имя, откуда получается дейтаграмма или любое (ANY) имя. Если NETBIOS получает дейтаграмму, но она не от имени, которое запросила прикладная прогпрамма, то NETBIOS продолжает ждать. Если прикладной программе нужна любая дейтаграмма, то NETBIOS вернется к прикладной программе. В обоих случаях, получаемое сообщение копируется в NCB_BUFFER@, а номер местного имени получамой дейтаграммы возвращается прикладной прог- рамме. RECEIVE BROADCAST DATAGRAM - особый случай, где дейтаграмма передается всем узлам назначения (станциям сети). --------------------------------------------------------------- !НАЧАТЬ!АДРЕС!ИСХОДН!ДЛИНА!Велич!Велич!Велич!Велич!Велич !УДАЛЕН!НАЗН !АДРЕС ! !5100H!0100H!0001H!1010H!0000H ... ! 7EH ! 6 ! 6 ! 2 ! ! ! ! ! --------------------------------------------------------------- --------------------------------------------------------------- ! ИМЯ ИСТОЧН ! ИМЯ НАЗН ! ПОЛЕ ДАТЫ ! ПОДСЧЕТ ПОВТОРН ! ASCIIса ! ASCII ! ! ПЕРЕДАЧ ... ! 16 ! ! Переменная длина ! 2 --------------------------------------------------------------- ------------------------------------------------------------ !ИД СОЕДИН! ИД ! ИД ! ИД ПРЕДЫД7! CRC ! КОНЕЦ-КАДРА ! !ИСХ.УЗЛА !НАЗНАЧ!ИСТОЧН.! УЗЛА ! ! Величина 7EH ! ! 2 ! 6 ! 6 ! 7 ! 4 ! ! ------------------------------------------------------------ Рис. 3-10. Пакет дейтаграмм. Транспортный уровень Сеансовый уровень вызывает транспортный уровень для установки надежной связи между двумя именами (ПЭВМ назначения и ПЭВМ-источни- ком). NETBIOS пытается максимальное количество раз установить эту связь. Если получено квитирование (см.рис.3-9), то соединение прош- ло успешно. С этого момента NETBIOS будет использовать протокол на- дежного потока (RSP). Этот протокол специфичен для оригинальной Се- ти ПЭВМ. Другие реализации NETBIOS имеют отличные от данного про- токолы, например Сетевые системы Xerox (Xerox Network Systems - XNS), Протокол управления передачей (Transmission Control Protocol - TCP), либо протоколы транспортного уровня ISO/NBS. Сетевой уровень Сетевой уровень в сети ПЭВМ IBM использует протокол передачи пакетов (PTP). Этот протокол состоит из четырех важнейших процедур: послать пакет PTP, послать кадр протокола доступа к каналу (LAP), получить кадр LAP и процедура полученного кадра. Процедура отправки PTP требует того, чтобы буфер был послан особенному идентификатору сетевого соединения. Если соединение су- ществует, то PTP форматирует буфер и посылает его через кадр LAP. Учтите, что, хотя этот протокол/процедура позволяет осуществить взаимодействие, реализация NETBIOS в Сети ПЭВМ IBM позволяет выпол- нять обработку пакета только в одну другую сеть (адааптер). Процедура отправки кадра LAP посылает буфер в определеный узел нгазначения или передает адрес посредством передачи правильно от- форматированного запроса канальному уровню. Процедура получения кадра LAP получает достоверные кадры не- посредственно из канального уровня. Эта процедура также ответствен- на за выделение и закрытие буферов при получении кадров. Если кадр получен от предыдущей процедуры, тогда вовлекается процедура полученного кадра. Эта процедура проверяет тип пакета на соответствие одному из следующих: данные соединения, завершение маршрута, открытие, дейтаграмма, установление маршрута или дубли- кат (в этом случае он игнорируется). Дейтаграммы передаются транс- портному уровню для дальнейшей обработки. Дейтаграммы представляют собой самую низкоуровневую форму пакета в сети, а все протоколы высшего уровня, включающие команды NETBIOS SEND, опосредственно ис- пользуют их в цепочке событий (сеансовый - транспортный - сетевой - канальный). ЭКС Token-Ring В ЭКС IBM Token-Ring, кадр NETBIOS непосредствено вложен в кадр управления логическим каналом (LLC) стандарта IEEE 802.2 на втором уровне модели соединения открытых систем. Кадры уровня 2 в свою очередь инкапсулируются в кадр управления ЭКС на первом уровне, уровне управления доступом к носителям (MAC), стандарт IEEE 802.5. Далее будет рассматриваться базовый формат. На рис. 3-11 показан базовый формат кадра NETBIOS. Этот кадр вложен в информационное поле кадра 802.2, который, в свою очередь, вложен в информационное поле кадра 802.5. Кадр 802.5 сам передается по кольцу в станцию назначения, где он разбивается, пока эмулятор не сможет обработать сам фактический кадр NETBIOS. Кадр ЭКС Token-Ring стандарта IEEE 802.5 (Маршрутизация источ- ника для реализации IBM) ----------------------------------------------------------- ! ! ! ! ! !Маршрути-!Инфор-! ! ! ! ! ! ! ! ! !зация ис-!маци- ! ! ! ! ! SD ! AC ! FC ! DA ! SA !точника !онн- ! FCS ! ED ! FS ! ! ! ! ! ! !(необяза-!ое ! ! ! ! ! ! ! ! ! ! тельна) !поле ! ! ! ! ----------------------------------------------------------- ! ! ! ! ! ! ! Кадр управления !! ! ! логическим каналом ------------------------------- (LLC) IEEE 802.2 !Адрес!Адрес!Управление!Инфор-! !DSAP !SSAP !(8-16 бит)!мация ! !8 бит!8 бит! !(8*М ! ! ! ! ! бит) ! ! ! ! ! ! ! ------------------------------- ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ----------------------------------------------------------- !Дли-!CMD !OPT1!OPT2! !Имя наз- !Имя !Необязательные ! !на !8 !8 !16 !X/R !начения !источ-!данные ! !16 !бит !бит !бит ! !16 симво-!ника ! ! !бит ! ! ! ! !лов !16 ! ! ! ! ! ! ! ! !симв. ! ! ----------------------------------------------------------- !_________________________________________! Заголовок NETBIOS ИЛИ ----------------------------------------------------------- !Дли-!CMD !OPT1!OPT2! !Номер !Номер !Необязательные ! !на !8 !8 !16 !X/R !назначе- !источ-!данные ! !16 !бит !бит !бит ! !ния !ника ! ! !бит ! ! ! ! !8 бит !8 ! ! ! ! ! ! ! ! !бит ! ! ----------------------------------------------------------- !_________________________________________! Заголовок NETBIOS УСЛОВНЫЕ ОБОЗНАЧЕНИЯ: SD - разделитель начала (8 бит) AC - управление доступом (8 бит) FC - управление кадром (8 бит) DA - адрес назначения (48 бит) SA - адрес источника (48 бит) FCS - последовательность проверки кадра (32-битовый контроль циклическим избыточным кодом) ED - разделитель конца (8 бит) FS - состояние кадра (8 бит) DSAP - Точка доступа к сервису назначения (F0 для NETBIOS) SSAP - Точка доступа к исходному сервису (F0 для NETBIOS) CMD - команда NETBIOS OPT1 - необязательные данные 1 OPT2 - необязательные данные 2 X/R - коррелятор передачи/ответа (4 байт) Рис.3-11. Формат кадра NETBIOS в ЭКС Token-Ring. Первые 16 бит кадра NETBIOS содержат длину заголовка NETBIOS, включая само поле длины. Следующие 16 бит (2 байта) содержат шест- надцатиричную величину EFFF, которая является разделитилем, указы- вающим, что последующие данные предназначены для эмулятора NETBIOS. Следующий байт является фактической функцией кадра NETBIOS. В ЭКС Token-Ring функции с шестнадцатиричными величинами от 00 до 13 яв- ляются несеансовыми кадрами, которые посылаются с использованием непронумерованных (U) информационных кадров 802.2, в то время, как функции с шестнадцатиричными величинами от 14 до 1F являются кадра- ми сеансов, которые посылаются с использованием информационных (I) кадров 802.2. Кадры U аналогичны дейтаграммам (замкнутые кадры без номеров последовательности), в то время, как кадры I содержут номе- ра последовательности и надежно передаются и получаются в ЭКС. Следующие 8 бит (1 байт) является необязательным байтом данных на определенную команду. Аналогично, следующие 2 байта представляют собой необязателные байты данных на особую команду. Следующие 4 байта в кадре являются коррелятором - один или два номера в шестнадцатиричном диапазоне от 0001 до FFFF. Он использу- ется для связывания (ассоциирования) полученных ответов с передава- емыми запросами. Коррелятор передачи возвращается в ответе к данно- му запросу (эта величина была получена как коррелятор ответа). Кор- релятор ответа представляет собой ожидаемую величину (в поле кор- релятора передачи), когда получается ответ на это сообщение. Несеансовые кадры содержат 16-символьное имя назначения NETBIOS, за которым следует 16-символьное имя источника. Сеансовые кадры содержат 1-байтовый номер сеанса назначения, за которым сле- дует 1-байтовый номер исходного сеанса. Как Вы можете увидеть, несеансовые кадры имеют заголовок NETBIOS общей длиной 43 байта, в то время как сеансовые кадры имеют заголовок длиной 13 байт. На рис.3-12 - 3.15 показаны кадры, которые используются в эмуляторе NETBIOS ЭКС Token-Ring. Следующие кадры используются для обеспечения функций управле- ния именами. ------------------------------------------------------------------ ! ! ! ! ! ИМЯ КОМАНДЫ ! КОД ! ФУНКЦИЯ ! !---------------------!--------!---------------------------------! ! ! ! ! !ADD_GROUP_NAME_QUERY ! X'00' ! Проверяет наличие дубликата ! ! ! ! имени группы в сети ! !----------------------------------------------------------------! ! ! ! ! !ADD_NAME_QUERY ! X'01' ! Проверяет наличие дубликата ! ! ! ! имени в сети ! !----------------------------------------------------------------! ! ! ! ! !ADD_NAME_RESPONSE ! X'0D' ! Отрицательный ответ: добавляе- ! ! ! ! мое имя является дубликатом ! !----------------------------------------------------------------! ! ! ! ! !NQAME_IN_CONFLICT ! X'02' ! Обнаружено дублирующееся имя ! ! ! ! ! !----------------------------------------------------------------! Рис. 3-12. Кадры управления именами NETBIOS в Token-Ring. Следующие кадры используются для установки, поддержания и завершения сеансов. ------------------------------------------------------------------ ! ! ! ! ! ИМЯ КОМАНДЫ ! КОД ! ФУНКЦИЯ ! !---------------------!--------!---------------------------------! ! ! ! ! !NAME_QUERY ! X'0A' ! Дает запрос на обнаружение ! ! ! ! имени в сети ! !----------------------------------------------------------------! ! ! ! ! !NAME_RECOGNIZED ! X'OE' ! Имя узнано: ответ NAME_QUERY ! ! ! ! ! !----------------------------------------------------------------! ! ! ! ! !SESSION_ALIVE ! X'1F' ! Удостоверивается в активности ! ! ! ! сеанса ! !----------------------------------------------------------------! ! ! ! ! !SESSION_CONFIRM ! X'17' ! Квитирование SESSION_INITIALIZE ! ! ! ! ! !----------------------------------------------------------------! ! ! ! ! !SESSION_END ! X'18' ! Завершение сеанса ! ! ! ! ! !----------------------------------------------------------------! ! ! ! ! !SESSION_INITIALIZE ! X'19' ! Сеанс был установлен ! ! ! ! ! ------------------------------------------------------------------ Рис. 3-13. Кадры управления сеансами NETBIOS в Token-Ring. Следующие кадры используются для передачи как сеансовых, так несеансовых данных. ------------------------------------------------------------------ ! ИМЯ КОМАНДЫ ! КОД ! ФУНКЦИЯ ! !---------------------!--------!---------------------------------! ! ! ! ! !DATA_ACK ! X'14' ! Квитирование DATA_ONLY_LAST ! ! ! ! ! !----------------------------------------------------------------! ! ! ! ! !DATA_FIRST_MIDDLE ! X'15' ! Сообщение данных сеанса - первый! ! ! ! или средний кадр ! !----------------------------------------------------------------! ! ! ! ! !DATAGRAM ! X'08' ! Сгенерированная прикладной про- ! ! ! ! граммой (ПП) дейтаграмма ! !----------------------------------------------------------------! ! ! ! ! !DATAGRAM_BROADCAST ! X'09' ! Сгенерированная ПП широковеща- ! ! ! ! тельная дейтаграмма ! !----------------------------------------------------------------! ! ! ! ! !DATA_ONLY_LAST ! X'16' ! Сообщение данных сеанса - един- ! ! ! ! ственный или последний кадр ! !----------------------------------------------------------------! ! ! ! ! !NO_RECEIVE ! X'1A' ! Нет команды получения для под- ! ! ! ! держки получаемых данных ! ------------------------------------------------------------------ ! ! ! ! !RECEIVE_CONTINUE ! X'1C' ! Показывает ожидающую команду ! ! ! ! получения (RECEIVE) ! !----------------------------------------------------------------! ! ! ! ! !RECEIVE_OUTSTANDING ! X'1B' ! Повторная передача последних ! ! ! ! данных - ожидает команда RECEIVE! ------------------------------------------------------------------ Рис. 3-14. Кадры передачи данных NETBIOS в Token-Ring. ------------------------------------------------------------------ ! ИМЯ КОМАНДЫ ! КОД ! ФУНКЦИЯ ! !---------------------!--------!---------------------------------! ! ! ! ! !STATUS_QUERY ! X'03' ! Дает запрос о состоянии ! ! ! ! удаленного узла ! !----------------------------------------------------------------! ! ! ! ! !STATUS_RESPONSE ! X'OF' ! Информация о состоянии ! ! ! ! удаленного узла ! !----------------------------------------------------------------! ! ! ! ! !TERMINATE_TRACE ! X'07' ! Завершает трассировку в ! ! ! ! удаленных узлах ! !----------------------------------------------------------------! ! ! ! ! !TERMINATE_TRACE ! X'13' ! Завершает трассировку в местных ! ! ! ! и удаленных узлах ! !----------------------------------------------------------------! Рис. 3-15. Дополнительные кадры NETBIOS в Token-Ring. Г Л А В А 4 ПРОТОКОЛ БЛОКА СООБЩЕНИЙ СПЕЦПРОЦЕССОРА --------------------------------------- О Б З О Р Протокол блока сообщений спецпроцессора (SMB), разработанный фирмами Microsoft, Intel и IBM, воплощает функции спецпроцессора и переадресатора Программы ЛВС ПЭВМ IBM. Этот протокол работает на прикладном уровне, и версия IBM требует для его успешного функ- ционирования NETBIOS. Данный протокол разработан таким образом, чтобы не зависеть ни от ЭВМ, ни от ОС, однако реализация IBM тесно связана с PC-DOS. Хотя, по заявлению IBM, протокол SMB является открытым, очень малое количество фирм-продавцов программного обеспечения решили ре- ализовать его в своих ЛВС ПЭВМ. Фирма 3Com Corporation собирается использовать этот протокол в своей реализации 3+. Одной из причин такого решения послужило то, что компании 3Сom и AT&T заключили соглашение по изготовлению комплексного оборудования, по которому AT&T стандартизирует программное обеспечение 3Com с помощью своей ЛВС с немодулированной передачей STARLAN 1 Мбайт/сек для небольших ЭВМ AT&T (6300 и 7300). Другая причина - тесные связи 3Сom с Microsoft - обе фирмы работали над созданием Администратора ЛВС для OS/2 (см. Главу 6). Другие фирмы-продавцы, например, Novell, реа- лизовали свои собственные протоколы переадресатора (оболочку) и протоколы спецпроцессора. Программа ЛВС ПЭВМ IBM может быть разбита на четыре основных части: переадресатор, получатель, отправитель сообщений и спецпро- цессор. Переадресатор перехватывет вызовы функций DOS 21H и опреде- ляет, предназначен ли запрос для местного или удаленного устройст- ва. Если устройство является местным, переадресатор просто передаст запрос местной операционной системе (DOS 3.1 или более высокая вер- сия для Cети IBM PC или DOS 3.2 или более поздняя версия для ЭКС). Если запрос предназначен для удаленного устройства, то переадреса- тор транслирует его в протоколы блока сообщений спецпроцессора. Получатель "слушает" протоколы SMB, передаваемые от другой ПЭВМ в сети, а затем удаляет ту часть сообщения, которая может быть прочитана человеком, и передает ее местному устройству - экрану, файлу или печатающему устройству. Отправитель подобен получателю: кроме обработки сообщений, он также посылает их в другом направлении. Он может пересылать сообщения от пользователя в SMB, с тем, чтобы они транслировались по сети к другой ПЭВМ. Сервер (спецпроцессор) - наиболее сложная часть программы, т.к. он воплощает в себе полный набор протоколов SMB и управляет коллективаным доступом других ПЭВМ в сети к местным устройствам. Он предназначен для обработки двух типов запросов, поступающих от дру- гих ПЭВМ, - запрос на доступ к файлам и запрос на буферизацию печа- ти. Первые три функции - переадресатор, получатель и отправитель - могут рассматриваться как подмножество (поднабор) спецпроцессора. Обмены информацией всегда запускаются каким-либо действием от зап- рашивающей ПЭВМ. Как правило, запросчиком является переадресатор, а запрос посылается одному из четырех устройств, как это описано выше. Поименование Поименование поддерживает обмен данными между двумя точками в сети. SMB поддерживает два класса имен - имена сети и имена маршру- тов сети. Имена сети представляют собой 16-байтовые символьные строки, обозначающие имена машины, спецпроцессора, переадресатора, главно- го пользователя и дополнительных пользователей, которые добавля- ются в таблицу местных имен каждой ПЭВМ. Максимальная длина имени может составлять до 15 байт, если необходимо, в имени могут прос- тавляться пробелы. Суффикс длиной в 1 байт обозначает тип имени. Имя машины имеет длину до 15 символов. Это имя придается ЭВМ программным обеспечением, под управлением оконечного пользователя. Имя спецпроцессора имеет длину 16 байт и состоит из имени машины с 20H в шестнадцатом байте. Это имя используется в ПЭВМ рабочей стан- ции для обмена данными с ПЭВМ спецпроцессора. Для обмена данными с переадресатором используется 16-байтовое имя, состоящее из имени машины с 00H в шестнадцатом байте. Имя дополнительного пользователя состоит из имени машины с 03H в шестнадцатом байте. Оно предназначе- но для отправки и приема сообщений. Имя главного или дополнительного пользователя, чей шестнадцатый байт изменен на 05H, является ретранслируемым. Имена маршрутов сети ассоциируются с разделяемыми ресурсами. Для каждого ресурса, такого как подкаталог на жестком диске спец- процессора, создается имя маршрута сети для подкаталога (маршрута) посредством прибавления имени машины (префиксации) впереди имени ресурса (маршрута). Имя маршрута сети имеет следующий формат: \\nnnnnnnnnnnnnnn\ddddddddd...ddd где nnn...n - имя машины, состоящее из от 1 до 15 символов, а ddd...d - имя устройства или маршут (путь доступа) каталога. Макси- мальная длина имени маршрута сети - 146 байт. Установка соединения ПЭВМ-спецпроцессор Когда пользователь пытается "подсоединиться" к ресурсам спецп- роцессора (например, посредством команды Программы ЛВС ПЭВМ NET USE), переадресатор осуществит попытку установить сеанс со спецпро- цессором. Если в таблице адресов местного адаптера есть свободное место, начинается сеанс, в котором переадресатор и спецпроцессор договариваются о протоколе, и начинается обмен данными. Со стороны спецпроцессора, переадресатор делает запрос, чтобы установить соединение с общим ресурсом, таким как подкаталог. Спец- процессор удостоверится, что запрашиваемый ресурс существует, и, если это так, проверит достоверность пароля. Затем спецпроцессор выдаст максимальный размер блока передачи спецпроцессора и handle соединения, называемый идентификатором маршрута сети (подобный возвращаемому PC-DOS при открытии файла) для всех будущих запросов к ресурсам. Когда соединение завершается, переадресатор "приказыва- ет" спецпроцессору закончить соединение и освободить идентификатор. Пользователь может ретранслировать сообщения другму компьютеру. В этом случае, отправитель (например, спецпроцессор) делает запрос, чтобы компьютер, получающий ретранслируемое сообщение, добавил имя пользователя в сеть как ретранслируемое имя. С этого момента сооб- щения для данного пользователя будут передаваться требуемой ЭВМ. Протоколы блока сообщений спецпроцессора (SMB) Набор протоколов SMB состоит из четырех типов блоков соощений спецпроцессора: управления сеансом (соединением), файла, печатающе- го устройства и сообщения. Управление сеансом выполняет две основ- ные функции: определение диалекта и управление соединением. Если Программа ЛВС ПЭВМ работает (и, следовательно, задейство- ваны протоколы SMB), после установки сеанса между ПЭВМ-переадреса- тором и ПЭВМ-спецпроцесором, переадресатор посылает команду VERIFY DIALECT вместе со списком поддерживваемых диалектов обратно спецп- роцессору. Последний затем определяет, может ли он поддержать один из этих диалектов. Если да, то он затем отсылает обратно переадре- сатору указание о том, какой диалект будет использоваться. Если спецпроцессор не сможет поддержать ни один из диалектов, он посылает сообщение об ошибке обратно ПЭВМ-переадресатору, и се- анс завершается. Управление соединением состоит из команд, которые начинают и оканчивают соединение переадресатора с общим ресурсом в спецпроцес- соре. Команда START CONNECTION устанавливает соединение между ПЭВМ-переадресатором и общим ресурсом в ПЭВМ-спецпроцессоре. Все дальнейшие команды и ответы используют этот сеанс. Команда END CONNECTION завершает соединение между переадресатором и общим ре- сурсом. Переадресатор может использовать команды доступа к файлу для обращения к файлам в спецпроцессоре, если командой START CONNECTION было установлено соединение. Эти команды подобны вызовам функций местной PC-DOS, которые позволяют получить доступ к файлам и ката- логам. Для определения конфигурации и состояния удаленных общих ре- сурсов были введены дополнительные команды. Поддерживаемые команды доступа к файлу включают: преверить, создать и удалить каталоги; создать файл, создать рабочий файл, создать новый файл; стереть или переименовать файл, получить или установить атрибуты файла, поиск нескольких файлов и получение ат- рибутов диска; открыть и закрыть файлы, прочитать и записать блок байт, выполнить процесс и закончить процесс; блокировать и разбло- кировать блок байт. Команды процессора печати позволяют переадресатору посылать файлы в очередь печати спецпроцессора и получать информацию о состоянии очереди печати. Эти команды включают: создать буфер- ный файл, буферизировать блок байт, закрыть буферный файл, возвра- тить очередь печати. Прикладная программа может использовать команды сообщений для отправки и получения сообщений. Эти команды включают команды для отправки и получения коротких сообщений (одна передача) или длинных сообщений (несколько передач), команды для ретрансляции или отмены сообщений и команды для отправки широковещательных (только корот- ких) сообщений. В то время как протоколы сообщений позволяют нес- кольким пользовательским именам в одной ПЭВМ получать или отправ- лять сообщения, реализация Программы ЛВС ПЭВМ IBM позволяет посы- лать сообщения только от одного имени. Команды, поддерживающие со- общения, включают: послать сообщение, состоящее из одного блока, послать широковещательное сообщение, послать начало сообщения сос- тоящего из нескольких блоков, послать текст сообщения, состоящего из нескольких блоков, послать конец сообщения состоящего из нес- кольких блоков, ретранслировать имя пользователя, отменить ретранс- ляцию, получить имя машины. Формат Блока сообщений спецпроцессора (SMB) В этом разделе описывается общая структура и поля SMB (фор- мат). Заметьте, что термины "имя устройства", "имя каталога" и "имя файла" относятся к своим эквивалентам в PC-DOS (например, имя уст- ройства PRN обозначает принтер). Имя диалекта представляет собой строку символов, которая имеет те же ограничения, что и имя файла (8 символов плюс необязательное расширение из 3 символов). В начале данной главы описывается структура имени сети. Имя источника и наз- начения представляют собой имена длиной от 1 до 15 символов (см.вы- ше). Пароль представляет собой имя длиной от 1 до 8 символов, ко- торое имеет те же ограничения, что и имя файла PC-DOS. На рис. 4-1 показан типичный формат SMB. ПОЛЕ РАЗМЕР ОПИСАНИЕ ------------------------------------------------------------------- !SMB_ID ! DB 0FFH ! Программа Сети РС 1.0 Тип сообщения ! ------------------------------------------------------------------- !SMB_SERVER ! DB 'SMB' ! Тип спецпроцессора SMB ! ------------------------------------------------------------------- !SMB_FUNCTION! DB 0 ! Код функции ! ------------------------------------------------------------------- !SME_RETCLASS! DB 0 ! Класс ошибки возврата ! ------------------------------------------------------------------- !SMB_HEINFO ! DB 0 ! Величина AH по прерыванию INT 24H ! ! ! ! или зарезервировано = 0 ! ------------------------------------------------------------------- !SMB_RETCODE ! DW 0 ! Код ошибки возврата ! ------------------------------------------------------------------- !SMB_RESV1 ! DB 0 ! Зарезервировано; должно быть 0 ! ------------------------------------------------------------------- !SMB_RESV2 ! DB 0 ! Зарезервировано; должно быть 0 ! ------------------------------------------------------------------- ! ! ! ! ------------------------------------------------------------------- ! ! ! ! ------------------------------------------------------------------- ! ! ! ! ------------------------------------------------------------------- ! ! ! ! ------------------------------------------------------------------- ! ! ! ! ------------------------------------------------------------------- !SMB_RESV8 ! DW 0 ! Зарезервировано; должно быть 0 ! ------------------------------------------------------------------- !SMB_NPID ! DW 0 ! Идентификатор маршрута сети ! ------------------------------------------------------------------- !SMB_PID ! DW 0 ! Идентификатор процесса ! ------------------------------------------------------------------- !SMB_RESV9 ! DW 0 ! Зарезервировано; должно быть 0 ! ------------------------------------------------------------------- !SMB_RES10 ! DW 0 ! Зарезервировано; должно быть 0 ! ------------------------------------------------------------------- !SMB_PARMCNT ! DB 0 ! Подсчет параметров в SMB ! ------------------------------------------------------------------- !SMB_P1-PN ! DW 0 ! Функционально-зависимые параметры SMB ! ------------------------------------------------------------------- !SMB_BUFLEN ! DW 0 ! Длина буфера SMB ! ------------------------------------------------------------------- !SMB_BUF ! DB'bytes'! Начало области буфера SMB ! ------------------------------------------------------------------- Рис 4-1. Типичный формат SMB. Поле SMB_FUNCTION может принимать следующие величины: Величина Значение -------- -------- 00H Создать каталог 01H 02H Открыть файл 03H Создать файл 04H Закрыть файл 05H Выполнить все файлы 06H Стереть файл 07H Переименовать файл 08H Получить атрибут файла 09H Установить атрибут файла 0AH Прочитать байтовый блок 0BH Записать байтовый блок 0CH Блокировать байтовый блок 0DH Разблокировать байтовый блок 0EH Создать уникальный файл 0FH Создать новый файл 10H Проверить каталог 11H Конец процесса 12H LSEEK (см.далее) 70H Начать соединение 71H Закончить соединение 72H Проверить диалект 80H Получить атрибуты диска 81H Поиск нескольких файлов C0H Создать буферный файл C1H Буферизировать байтовый блок C2H Закрыть буферный файл C3H Возвратить очередь печати D0H Послать сообщение D1H Послать широковещательное сообщение D2H Ретранслировать имя пользователя D3H Отменить ретрансляцию D4H Получить имя машины D5H Начать много-блоковое сообщение D6H Закончить много-блоковое сообщение D7H Текст много-блокового сообщения Поле SMB_RETCODE может принимать следующие величины (если SMB_RETCLASS = 00H): Величина Значение -------- -------- 0054H Сообщение было буферизировано 0055H Сообщение было зарегистрировано 0056H Показано сообщение пользователя. Поле SMB_RETCODE может принимать следующие величины (если SMB_RETCLASS = 02H): Величина Значение -------- -------- 0000H Зарезервировано 0001H Неизвестная ошибка 0002H Неверный пароль 0003H Не соответствует присвоенный тип устройства 0004H Нарушен уровень доступа к имени сети 0005H Неверный идентификатор маршрута сети 0006H Не найден маршрут сети 0007H Неправильное устройство 0031H Очередь печати заполнена (число файлов) 0032H Очередь печати не помещается в свободное место 0033H Конец файла в очереди печати 0034H Неверный идентификатор файла печати 0051H Пауза спецпроцессора 0052H Нет получаемых сообщений 0053H Нет места для буферизации сообщения 0057H Чрезмерное количество отдаленных пользовательских имен 0058H Дублирующееся имя в сети FFFFH Функция не поддерживается Команды управления сеансом VERIFY DIALECT - Команда посылается переадресатором спецпро- цессору для установки диалекта. START CONNECTION - Команда устанавливает соединение между пе- реадресатором и общим ресурсом спецпроцессора. Спецпроцессор содер- жит таблицу, которая устанавливает соответствие общего ресурса из имени маршрута сети с местным именем, определяет тип ресурса и со- держит произвольный пароль. Спецпроцессор возвращает идентификатор маршрута сети для использования в последующих запросах этого ресур- са. Прикладная программа может также использовать команду START CONNECTION для обмена данными ПЭВМ-ПЭВМ, в котором максимальный размер передачи составляет 512 байт. Команды файла CREATE DIRECTORY - Посылается от переадресатора к спецпроцес- сору для выполнения функции PC-DOS MKDIR (создать каталог). REMOVE DIRECTORY - Посылается от переадресатора к спецпроцес- сору для выполнения функции PC-DOS RMDIR (удалить каталог). CHECK DIRECTORY - Посылается переадресатором для определения, существует ли каталог спецпроцессора, когда пользователь выполняет команду DOS CHDIR (изменить каталог). OPEN FILE - Посылается от переадресатора к спецпроцессору для открытия файла и возврата handle файла (подобно операции местной PC-DOS). Начиная с версии PC-DOS 3.1, для многопользова- тельской среды поддерживаются несколько дополнительных режимов отк- рытия файлов. Они приводятся ниже в таблице. Режим открытия файлов Значение --------------------- -------- Совместимость Обеспечивает совместимость с прикладными программами, которые использовали предыду- щие версии PC-DOS. Файл может быть открыт любое количество раз, если он не открыва- ется в PC-DOS 3.1 и позднейших версиях. Отказ в Используется для получения монопольного чтении/записи доступа к файлу. На запрос получается отказ, если файл уже был открыт в любом другом режиме. Отказ в записи Позволяет открывать файл столько раз, сколько это требуется для чтения. На запрос получается отказ, если файл уже был открыт в доступе записи или в режиме совместимости. Отказ в чтении Позволяет открывать файл для записи. На запрос получается отказ, если файл уже был открыт для чтения в режиме совместимости (эмуляции). Нет отказа Позволяет открывать файл любое требу- емое количество раз для чтения/записи. На запрос будет дан отказ, если файл уже был открыт в любом другом режиме. Если прикладная программа открывает файл,используя более ста- рый метод Блока управления файлами (FCB) посредством прервывания DOS INT21H, функция 0FH, то режимы коллективного пользования не поддерживаются. На рис. 4-2 даны различные режимы открытия файлов и типы дос- тупа. Открытие второго и последующих файлов ----------------------------------------------- !Отказ в !Отказ в !Отказ в !Запись/ ! Совме- ! !чтении/ !записи !чтении !чтение ! сти- ! !записи ! ! !разре- ! мость ! ! ! ! !шены ! ! !--------!--------!--------!--------!---------- !I !I/!O !I !I/!O !I !I/!O !I !I/!O !I !I/! O ! ! ! O! ! ! O! ! ! O! ! ! O! ! ! O! ! -----------!-------------------------------------------------- !Отказ в ! I ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !чтении/ !-------------------------------------------------! !записи !I/O! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !-------------------------------------------------! ! ! O ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !------------------------------------------------------------! ! ! I ! ! ! !##! ! ! ! ! !##! ! !**! ! ! !Отказ в !-------------------------------------------------! !записи !I/O! ! ! ! ! ! ! ! ! !##! ! ! ! ! ! ! !-------------------------------------------------! ! ! O ! ! ! ! ! ! !##! ! !##! ! ! ! ! ! РЕ- !------------------------------------------------------------! ЖИМ ! ! I ! ! ! ! ! !##! ! ! ! ! !##! ! ! ! !Отказ в !-------------------------------------------------! ОТК- !чтении !I/O! ! ! ! ! ! ! ! ! ! ! !##! ! ! ! РЫ- ! !-------------------------------------------------! ТИЯ ! ! O ! ! ! ! ! ! ! ! !##! ! !##! ! ! ! !------------------------------------------------------------! ПЕР- !Чтение/ ! I ! ! ! !##!##!##! ! ! !##!##!##!**! ! ! ВОГО !запись !-------------------------------------------------! !разрешены !I/O! ! ! ! ! ! ! ! ! !##!##!##! ! ! ! ФАЙ- ! !-------------------------------------------------! ЛА ! ! O ! ! ! ! ! ! !##!##!##!##!##!##! ! ! ! !------------------------------------------------------------! ! ! I ! ! ! !**! ! ! ! ! !**! ! !##!##!## ! !Совмес- !-------------------------------------------------! !тимость !I/O! ! ! ! ! ! ! ! ! ! ! ! !##!##!## ! ! !-------------------------------------------------! ! ! O ! ! ! ! ! ! ! ! ! ! ! ! !##!##!## ! !------------------------------------------------------------! ПРИМЕЧАНИЯ: Доступ к файлу: I - ввод = Чтение из файла I/O - ввод/вывод = Чтение/запись из/в файл O - вывод = Запись в файл ---- !##! - Разрешено открытие последующего файла ---- ---- ! ! - Не разрешено открытие последующего файла ---- ---- !**! - Разрешено открытие последующего файла, если ---- файл доступен только для чтения Рис 4-2. Режимы открытия файлов и типы доступа. CREATE FILE - Посылается переадресатором спецпроцессору для создания нового файла и возврата handle файла. Эта команда также используется для уничтожения старого файла и создания нового с таким же именем. На запрос будет дан отказ, если файл открыт или атрибут файла установлен как только для чтения. CLOSE FILE - Посылается переадресатором спецпроцессору для закрытия файла. Переадресатор посылает handle файла. COMMIT FILE - Посылается переадресатором спецпроцессору для осуществления запроса, что все буферы для файла были записаны на жесткий диск спецпроцессора. Переадресатор определяет handle файла, и спецпроцессор выдает ответ, когда операция завершена. Нес- колько файлов могут быть выполнены, если переадресатор определяет, что должны быть выполнены все файлы, открытые в соединении, которое представлено идентификатором маршрута сети в поле SMB_NPID. DELETE FILE - Посылается переадресатором спецпроцессору для уничтожения файла. Переадресатор определяет handle файла. На запрос будет получен отказ, если файл открыт или помечен как дос- тупный только для чтения. RENAME FILE - Посылается переадресатором спецпроцессору для переименования файла. GET FILE ATTRIBUTES - Посылается переадресатором спецпроцессо- ру для получения атрибутов файла, времени последнего доступа к фай- лу и размера. SET FILE ATTRIBUTES - Посылается переадресатором спецпроцессо- ру для установки атрибутов файла. READ BYTE BLOCK - Посылается переадресатором спецпроцессору для считывания блока данных из файла. WRITE BYTE BLOCK - Посылается переадресатором спецпроцессору для записи блока данных из файла. LSEEK - сокращение от LONG SEEK (Длительный поиск). Посылается спецпроцессору для передвижения указателя файла. Программа ЛВС ПЭВМ использует эту функцию для определения размера файла. Файл должен быть предварительно открыт в режиме, который поддерживает коллек- тивное чтение. LOCK BYTE BLOCK - Поддерживает расширенную функцию блокировки файлов по байтам, которая имеется в версии PC-DOS 3.1 и выше. Посы- лается переадресатором спецпроцессору для блокировки области байт в файле. Размер этой области может быть от одного байта до целого файла. На запрос будет получен отказ, если какой-либо байт входит в уже заблокированную область. Заметьте, что эта функция неадекватно поддерживает обработку транзакции, т.к. не поддерживаются элемен- тарные блокировки (несколько запросов о блокировке в одном запросе для выполнения транзакции). Некоторые спецпроцессоры, например, NetWare фирмы Novell, поддерживают элементарные блокировки. UNLOCK BYTE BLOCK - Дополняет прудыдущую; передается переад- ресатором спецпроцессору для разблокирования области байт в файле. CREATE UNIQUE FILE - Посылается переадресатором спецпроцессору для генерации уникального имени файла спецпроцессором (фактически PC-DOS, работающей на данном спецпроцессоре). Спецпроцессор затем возвращает уникальное имя переадресатору. Уникальные имена исполь- зуют прикладные программы, которые требуют наличия временных рабо- чих файлов. CREATE NEW FILE - Команда аналогична предыдущей, за исключени- ем того, что имя файла должно быть уникально для файлов, уже сущес- твующих в данном каталоге. END OF PROCESS - Посылается переадресатором спецпроцессору для окончания работы в соединении. Она посылается для каждого маршрута сети, который является активным для переадресатора. GET DISK ATTRIBUTES - Посылается переадресатором спецпроцес- сору для получения информации о размере памяти и формате жесткого диска. SEARCH MULTIPLE FILES - Посылается переадресатором спецпро- цессору для выполнения функций поиска Блока управления файлами (FCB) PC-DOS и функций поиска ASCII. Имя файла и маршрута передают- ся спецпроцессору. Также может вестись поиск скрытых (спрятанных) и системных файлов. Команды печати CREATE SPOOL FILE - Посылается переадресатором спецпроцессору для установки потока данных, в которых необходимо буферизировать данные печати. SPOOL BYTE BLOCK - Посылается переадресатором спецпроцессору для буферизации блока данных из файла. Первый посылаемый блок со- держит установочную информацию для печатающего устройства. CLOSE SPOOL FILE - Посылается переадресатором спецпроцессору для закрытия буферного файла. Затем спецпроцессор помещает файл в очередь для печати. RETURN PRINT CODE - Посылается переадресатором спецпроцессору для возврата содержимого очереди печати спецпроцессора. Команды сообщений SEND SINGLE BLOCK MESSAGE - Посылается от одного переадресато- ра другому. Команда посылает короткие (одноблочные) сообщения, максимальная длина которых 128 символов. SEND BROADCAST MESSAGE - Посылает короткое собщение всем полу- чателям в сети. Широковешательное сообщение посылается как дейтаг- рамма, - от получателей ответов не поступает. SEND START OF MULTI-BLOCK MESSAGE - Посылается отправителем для начала многоблочного сообщения. Получатель возвращает идентифи- катор группы сообщения, который используется блоками последующего сообщения. SEND TEXT OF MULTI-BLOCK MESSAGE - Посылается отправителем для отправки сообщения размером до 1600 символов по блокам длиной в 128 символов. SEND END OF MULTI-BLOCK MESSAGE - Посылается отправителем для указания конца многоблочного сообщения. FORWARD USER NAME - Посылается отправителем спецпроцессору запрашивающему, чтобы спецпроцессор получал сообщения для дополни- тельного имени пользователя. Для добавления этого имени, в таблице спецпроцессора должно быть свободное место. CANCEL FORWARD - Дополняет предыдущую команду. Спецпроцессор сотрет имя пользователя из своей таблицы. GET MACHINE NAME - Посылается для получения имени машины поль- зовательского имени. Данная команда обычно используется вместе с предылдущей, чтобы получить имя, на которое посылать команду CANCEL FORWARD. Г Л А В А 5 РАЗРАБОТКИ NETBIOS, CДЕЛАННЫЕ ДРУГИМИ ФИРМАМИ ------------------------------------------------- Разработки NETBIOS, отличные от разработки фирмы IBM В данной главе описываются разработки NETBIOS нескольких фирм-продавцов. В первой четверке таких компаний числится фирма - производитель плат ПЭВМ, производитель внешних плат Ethernet, фирма - продавец программного обеспечения для файлового процессора ЛВС ПЭВМ и компания-продавец многопользовательскаого программного обес- печения. Для всех них общим является совместимый с NETBIOS интер- фейс сеансового уровня, отвечающий вызовам функций прерывания 5CH NETBIOS и возвращаемым результатам. Различие между ними заключается в протоколах, использующихся для реализации высокоуровневых протоколов, которые находятся над сеансовым (пятым в модели Соеди- нения открытых систем) уровнем, - т.е. на транспортном и сетевом уровнях (см.Главу 1). Сетевой уровень часто взаимодействует с опре- деленным типом канального уровня; т.е. определенная разработка NETBIOS работает только на сетевой технологии определенного пользо- вателя, несмотря на "переносимость" высокоуровневых протоколов, включаяя NETBIOS. Необходимо отметить, однако, что все фирмы предс- тавляют свои промежуточные протоколы как открытые для подсоединения к другим технологиям ЛВС, что позволяет пользователям реализовать эмулятор NETBIOS своего соединения имеющейся технологии ЛВС так, как они находят необходимым для себя. Фирма AST Research Разработанная фирмой AST Research (США) версия NETBIOS полностью воплощает все функции NETBIOS, что позволяет Программе ЛВС ПЭВМ IBM или же любой другой прикладной программе, совместимой с NETBIOS, успешно функционировать. Значительные части этой программы были написаны на языке С, что делает ее переносимой. Данная реализация доступна для таких продуктов фирмы AST как PCnet, PCnet-II и RSN. Фирма планирует заключить контракт с изготовителями комплексного оборудования на отладку своей версии NETBIOS. Исполь- зуемые протоколы основаны на Сетевых системах Ксерокс (XNS - Xerox Network Systems). Реализация AST предоставляет пользователю больше средств уп- равления работой NETBIOS, чем другие версии, включая и версию IBM. При отладке программного обеспечения пользователь может принять оп- ции по умолчанию, либо определить величину тайм-аута положительной квитации (ACK), вызова (CALL), имени (NAME) и сеанса (SESSION); обратный счет(чик) дейтаграмм (DATAGRAM), отправки (SEND) и имени (NAME); количество открытых сеансов, количество ожидающих команд и размеры пакетов данных. На рис 5-1 показана общая схема разработанной фирмой AST вер- сии NETBIOIS. ------------------------- !7 ! ! ПРИКЛАДНОЙ ! Сетевые прикладные программы ------------------------- !6 ПРЕДСТАВЛЕНИЯ ! ! ДАННЫХ ! PC-DOS ------------------------- !5 ! ! СЕАНСОВЫЙ ! Эмулятор NETBIOS ------------------------- !4 ! ! ТРАНСПОРТНЫЙ ! Сетевые системы Xerox (XNS) ------------------------- !3 ! ! СЕТЕВОЙ ! XNS ------------------------- !2 ! ! КАНАЛЬНЫЙ ! CSMA ------------------------- !1 ! ! ФИЗИЧЕСКИЙ ! PCnet; PCnet-II; RSN ------------------------- Рис.5-1. Реализация NETBIOS фирмой AST Research. Фирма Excelan Фирма Excelan, Inc (США) имеет эмулятор NETBIOS для оконечных пользователей, который охватывает все команды преры- вания 5CH, имеющиеся в версии NETBIOS фирмы IBM. Эта разработка действует на основе протоколов TCP/IP (Transport Control Protocol/ Internet Protocol - Протокол управления транспортом/Межсетевой Про- токол) компании Excelan, которые, в свою очередь, обмениваются дан- ными с ЛВС Ethernet. Реализация протоколов TCP/IP, предлагаемая из- готовителем комплексного оборудования Excelan, спроектирована таким образом, чтобы обеспечить возможность работы с оборудованием Excelan (интерфейсные процессоры Ethernet). Фирма Excelan предлага- ет изготовителям комплексного оборудования одну из версий NETBIOS/TCP/IP, которая может быть отлажена. Необходимо отметить, что разработки TCP/IP, предлагаемые несколькими фирмами-продавцами, являются более совместимыми друг с другом,(что облегчает обмен дан- ными между ними), чем разработки, основанные на таких протоколах, как Сетевые системы Xerox (XNS). На рис. 5-2 показана общая схема разработанной фирмой Excelan реализации NETBIOS в ЛВС Ethernet. ------------------------- !7 ! ! ПРИКЛАДНОЙ ! Сетевые прикладные программы ------------------------- !6 ПРЕДСТАВЛЕНИЯ ! ! ДАННЫХ ! PC-DOS/Переадресатор ------------------------- !5 ! ! СЕАНСОВЫЙ ! Эмулятор NETBIOS ------------------------- !4 ! Протокол управления транспортом/ ! ТРАНСПОРТНЫЙ ! Межсетевой протокол (TCP/IP) ------------------------- !3 ! ! СЕТЕВОЙ ! TCP/IP ------------------------- !2 ! ! КАНАЛЬНЫЙ ! 802.3/802.2 ------------------------- !1 ! ! ФИЗИЧЕСКИЙ ! Еthernet (802.3) ------------------------- Рис.5-2. Реализация NETBIOS фирмой Excelan. Компании Novell и Excelan заключили совместное соглашение по рабочей станции TCP/IP фирмы Excelan для NetWare. (Этот программый/ аппаратный продукт является альтернативой применению коммуникацион- ных шлюзов и позволяет рабочей станции ПЭВМ в сети получать непос- редственный доступ к и передавать файлы параллельно со спецпроцес- сором NetWare и рабочей ЭВМ TCP/IP). По условиям этого соглашения, фирма Excelan разработала управ- ляющую программу для соединения NetWare с имеющимся решением NCP/IP-Ethernet для систем PC DOS. Компания Novell предоставляет поддержку управляющей программе Excelan в своем новом продукте NetWare 286. Рабочая станция TCP/IP фирмы Excelan дает пользователям служеб- ные и прикладные программы на основе NetWare, и прикладные прог- раммы Excelan на основе TCP/IP, включая FTP, Telnet, эмуляторы тер- минала VT100 и VT220, а также утилиты R (R Utilities).Таким образом, пользователи имеют прямой доступ к рабочим мини- или супермини-ЭВМ TCP/IP и к услугам NetWare. Разработка Excelan позволяет протоколам IPX ( Межсетевого обмена пакетами ) фирмы Novell и протоколам NCP/IP (Пролтокол управления сетью/Межсетевой протокол) фирмы Excelan работать в АРМ параллельно. Фирма Novell Компания Novell (США) внесла свой вклад в эмуляцию NETBIOS на- чиная с Версии 2.0 рабочей станции Аdvanced NetWare. В ней поддер- живаются все команды прерывания 5CH, характерные для NETBIOS фирмы IBM; все эти команды узнаются спецпроцессором. Фактически, как спецпроцессоры Novell, так и спецпроцессоры IBM (посредством Прог- раммы ЛВС ПЭВМ IBM), могут работать одновременно, и рабочая стан- ция, использующая либо оболочку Novell, либо Программу ЛВС ПЭВМ IBM, может иметь доступ к спецпроцессору Novell. Очевидно, что ра- бочая станция, использующая оболочку Novell может обращаться только к спецпроцессору Novell, а не к ПЭВМ, работающей в качестве спец- процессора по Программе ЛВС ПЭВМ IBM. Разработка Novell действует на основе протоколов IPX (Internet Packet eXchange - Межсетевой обмен пакетами). Это дает пользовате- лям совместимость NETBIOS с любой из двух десятков ЛВС ПЭВМ, под- держиваемой Advanced NetWare (включая Сеть ПЭВМ), а также повышает производительность работы. Интересно, что испытания, проведенные компанией Novell, показали, что производительность в сквозном взаи- модействии рабочих станций при использовании эмулятора возрастает вдвое по сравнению с оригинальным NETBIOS в Сети ПЭВМ. При установ- ке оболочки рабочей станции пользователь может определить, какую версию NETBIOS ему использовать. Фирма Novell добилась повышения эффективности и при передаче пакетов между уровнями. Теоретически, по уровням передаются только пакеты, а не информация и буферных и рабочих областях, используе- мых другим уровнем. Это обеспечивает совместимость с версией дан- ного протокола, разработанного другими фирмами. В реализации Novell, пакеты не посылаются от NETBIOS (на сеан- совом уровне) в транспортный уровень. Вместо этого от одного уровня следующему уровню передается указатель, что позволяет избежать из- лишней записи данных в шине и процессоре. Эта технология "выпрямля- ет" весь процесс, но нарушает правила модели Соединения открытых систем (OSI). Она используется и другими фирмами из-за соображений эффективности и конкурентоспособности. На рис 5-3 показана разработанная Novell версия NETBIOS для ЛВС ПЭВМ, поддерживаемых NetWare. Заметьте, что оболочка Novell фукционально эквивалентна переадресатору Microsoft. ------------------------- !7 ! ! ПРИКЛАДНОЙ ! Сетевые прикладные программы ------------------------- !6 ПРЕДСТАВЛЕНИЯ ! ! ДАННЫХ ! PC-DOS/Оболочка ------------------------- !5 ! ! СЕАНСОВЫЙ ! Эмулятор NETBIOS ------------------------- !4 ! Протокол межсетевого обмена ! ТРАНСПОРТНЫЙ ! пакетами (IPX) ------------------------- !3 ! ! СЕТЕВОЙ ! IPX ------------------------- !2 ! ! КАНАЛЬНЫЙ ! CSMA/Token-Bus/Token-Ring ------------------------- !1 ! ! ФИЗИЧЕСКИЙ ! Большинство основных ЛВС ПЭВМ ------------------------- Рис.5-3. Реализация NETBIOS фирмой Novell. Novell и операционная система OS/2 Генератор запросов NetWare вместе со Стандартной версией OS/2 поддерживает внешние прикладные программы на основе спецпроцессора. В соответствии с этой конфигурацией, Генератор запросов NetWare загружается как на рабочей станции (или пользователе), так и на спецпроцессоре прикладных программ. Пользовательский компонент прикладной программы осуществляет запросы на прикладные услуги че- рез Генератор запросов NetWare; сетевой механизм равноправной тран- спортировки затем посылает запрос прикладному спецпроцессору для обработки. Ответы отсылаются обратно на рабочую станцию по тому же маршруту. Если прикладная программа должна использовать файловую систему NetWare на физически отдельном файловом процессоре, Генера- тор запросов NetWare в прикладном спецпроцессоре передаст запросы ввода/вывода диска файловому спецпроцессору NetWare для прикладной программы. Novell поддерживает стандартные интерфейсы прикладного программирования (API),(определенные IBM),которые позволяют осу- ществлять совместную обработку данных: NETBIOS, APPC и API IBM для OS/2 (APPC - Перспективное межпрограммное взаимодействие). Novell не осуществляет поддержку Поименованных Каналов (Named Pipes), поскольку они не поддерживаются IBM. Поименованные каналы являются частью Администратора ЛВС Microsoft, который поддерживается 3Com. Прикладной сопроцесссор NetWare для Расширенной версии OS/2 поддерживает внутренние прикладные программы на основе спецпроцес- сора. Фирма The Software Link Компания The Software Link (США), в отличие от трех фирм, опи- санных выше, разработала эмулятор NETBIOS для не-сетевых продуктов. Она создала два продукта, которые позволяют пользователям IBM PC коллективно использовать ресурсы (печатающие устройства и жесткие диски). Первый продукт превращает PC или AT в многопользовательскую, многофункциональную машину. Multilink Advanced использует ОЗУ для параллельной работы до девяти прикладных программ. К рабочей ПЭВМ через порты RS-232 можно подсоединять до восьми терминалов ASCII (включая терминал с клавиатурой IBM и эмулятором экрана "Shadow" фирмы The Software Link). Второй продукт, LANlink, позволяет размещать низкоуровневую сеть, состоящую из взаимосвязанных ПЭВМ, по звездообразной тополо- гии. Звезды могут соединяться с другими звездами, а также и с уда- ленными ПЭВМ, что позволяет иметь довольно-таки произвольную топо- логию сети. В отличие от Multilink Advanced, ПЭВМ присоединяются к рабочей ЭВМ, а не к терминалам. Также как и в Multilink Advanced, применяются порты RS-232, однако скорость передачи данных через них равна 56 кбайт/сек и они имеют собственные механизмы сжатия данных, что позволяет увеличить производительность передачи данных до 115 кбайт/сек. "Спутниковые" (периферийные) ПЭВМ соединены с рабо- чей ПЭВМ и могут использовать жесткий диск спецпроцессора в качест- ве местного виртуального дисковода (как и в среде ЛВС ПЭВМ). Оба продукта могут работать с прикладными программами, совмес- тимыми с PC DOS 3.1 и/или NETBIOS. На рис 5-4 показана версия NETBIOS, разработанная фирмой The Software Link для LANlink. ------------------------- !7 ! ! ПРИКЛАДНОЙ ! Сетевые прикладные программы ------------------------- !6 ПРЕДСТАВЛЕНИЯ ! ! ДАННЫХ ! PC-DOS ------------------------- !5 ! ! СЕАНСОВЫЙ ! Эмулятор NETBIOS ------------------------- !4 ! ! ТРАНСПОРТНЫЙ ! Собственный ------------------------- !3 ! ! СЕТЕВОЙ ! Собственный ------------------------- !2 ! ! КАНАЛЬНЫЙ ! LANlink ------------------------- !1 ! ! ФИЗИЧЕСКИЙ ! RS-232 ------------------------- Рис.5-4. Реализация NETBIOS фирмой The Software Link. Другие фирмы Многие фирмы предлагают версию NETBIOS для своих сетей. Техно- логия их, в целом, сходна с описанной выше: они предоставляют эму- лятор сеансового уровня 5CH и используют транспортный и сетевой протоколы по своему выбору. Различия между фирмами касаются усовер- шенствований (по стоимости обратной совместимости с NETBIOS IBM) и оригинальных услуг (например, оболочка Novell), с которыми NETBIOS может сосуществовать в ЛВС фирмы-продавца. С целью увеличения про- изводительности, такие фирмы, как 3Com и Codenoll реализуют прото- колы NETBIOS в самих сетевых адаптерах. Далее мы кратко остановимся на разработках NETBIOS, представ- ляющих интерес. Фирма Communications Solutions, Inc (CSI) Фирма CSI (США) предоставляет изготовителям комплексного обо- рудования программное обеспечение шлюзов SNA (Сетевая архитектура систем), включая основанные на ЛВС версии этого программного обес- печения Access/SNA 3270, Access/SNA APPC и Access/DIA. Программное обеспечение ЛВС на основе NETBIOS фирмы CSI позво- ляет пользователям получать параллельный доступ к нескольким сеаен- сам SNA. Программное обеспечение было спроектировано таким образом, чтобы рабочие станции в сети могли использовать минимальный объем памяти. Программа разбита так, чтобы уровень представления физичес- ки находился на каждой отдельной рабочей станции. Ядро программного обеспечения находится в одной рабочей станции, которая служит в ка- честве шлюза. Фирма NCR Corporation Компания NCR Corp (США) предлагает Систему ЭКС ПЭВМ (NCR PC Token-Ring System), которая состоит из платы адаптера ПЭВМ, кабеля адаптера, расширенной версии сетевой операционной системы Microsoft Networks, NETBIOS, управляемых меню и командами пользовательских интерфейсов и программмного обеспечения для диагностирования. Программы ЛВС ПЭВМ NCR и NETBIOS совместимы с другими система- ми ЭКС. Программа ЛВС ПЭВМ NCR, являющаяся версией Microsoft Networks, управляет функциями сообщений в сети, печати, диска и ка- талога. Программа NETBIOS NCR обеспечивает совместимое с ПЭВМ сред- ство транспортировки для Управления логическим каналом (LLC) и Управления доступом к носителям (MAC) и работает с прикладными программами, предназначенными для использования со стандартной ЭКС NETBIOS. Компания Network Research Corporation (NRC) Фирма NRC (США) совместила возможности NETBIOS со своим сете- вым программным обеспечением FUSION, что позволяет интерфейсу NETBIOS работать в сетях нескольких фирм. Версия FUSION позволяет пользователям запускать любые приклад- ные программы NETBIOS в сети TCP/IP. Кроме того, пользователи NETBIOS могут перемещать файлы между своими системами. Системами, поддерживаемыми Сетевым программным обеспечением FUSION, являются компьтеры VAX/VMS Digital и рабочие станции UNIX.Пользователи могут также использовать различные канальные уровни, например Ethernet или RC, поставляемые различными фирмами. Версия FUSION NETBIOS отвечает Стандарту протокола RFC 1001 (Стандарт протокола для сервиса NETBIOS в транспортном протоколе NCP/UDP - КОНЦЕПЦИИ и МЕТОДЫ //см.Главу 7//) и Стандарту протокола RCF 1002 (Стандарт протокола для Сервиса NETBIOS в транспортном протоколе TCP/UDP - ДЕТАЛЬНАЯ СПЕЦИФИКАЦИЯ), что делает ее совмес- тимый с существующими прикладными программами. Эта опция доступна для MS-DOS/PC версии FUSION. Фирма Pathway Design, Inc Фирма Pathway Design (США) предлагает свой продукт - netPATH SNA-3770/NetBIOS - шлюз ЛВС для передачи данных между любыми сов- местимыми с NetBIOS ЛВС и большими ЭВМ IBM со скоростью до 56 кбайт/сек. Даннный шлюз является программным и аппаратным продуктом, ко- торый обеспечивает обмен данными между пользовательскими ПЭВМ, под- соединенными к ЛВС и рабочей большой ЭВМ, действующей в сети SNA (Сетевой архитектуры систем). Продукт NetPATH/NetBIOS содержит удаленный контроллер кластеров IBM 3274 с присоединенными рабочими станциями 3270. В каждой рабочей станции ЛВС ПЭВМ PC, AT или XT IBM могут устанавливать несколько параллельных сеансов ЛВС с рабочей ЭВМ и отдельными сеансами DOS. Этот шлюз также включает в себя программное обеспечение передачи файлов фирмы Pathway Design - ftPATH для 3270 PC. Данный шлюз содержит несколько инструментальных программных средств управления, включая Диспетчер (супервизор) Сети, (Network Supervisor), который обеспечивает статистическое рассмотрение (контроль) всех операций по обмену данными, например, интерактивного статуса сеанса и управления сеансами шлюза. Средство Сетевой Регистрации (Network Logging Facility) обеспечива- ет регистрацию в контрольном журнале всех сеансов, а Интерактивное Средство Трассировки (On-Line Trace Facility) позволяет анализиро- вать и регистрировать движение передаваемых и принимаемых сообщений. Фирма также предлагает продукт, названный COAXGATE, - шлюз, который обеспечивает до 40 сеансов коммуникации SNA-DFT по единому коаксиальному кабелю. Подсоединяя непосредственно к Центральному процессору IBM 3174 или 3274, или к процессору IBM 9370, этот шлюз позволяет пользователям ПЭВМ в ЛВС NETBIOS получать доступ к уда- ленным или местным рабочим ЭВМ. Плата коаксиального адаптера с мик- ропроцессором 20 Мегагерц и частной памятью, будучи установлена на рабочей станции, выбранной в качестве шлюза ЛВС, позволяет каждой ПЭВМ в сети запускать до пяти параллельных сеансов с большой ЭВМ, причем максимальное количество сеансов на шлюз равно 40. Типичная конфигурация COAXGATE состоит из ЛВС, соединенной посредством коаксиального кабеля или скрученного провода с портом мультиплексора в центральном процессоре IBM. Фирма Sytek Эта фирма предлагает изготовителям комплесного оборудования плату адаптера для ЭКС с немодулированной передачей, отвечающую стандарту управления логическим каналом IEEE 802.2 и стандарту эс- тафетного кольца IEEE 802.5. Плата подсоединяется в ЭКС IBM (IBM Token-Ring Network), используя NETBIOS как интерфейс программирова- ния, кабельную систему IBM для физического соединения и протокол доступа ЭКС для управления передачей и приемом сообщений в сети. Фирма Sytek также предлагает свою версию Программы NETBIOS Token-Ring. Плата адаптера поддерживает как Программу IBM ЛВС ПЭВМ, так и операционную систему Novell NetWare для ЭКС. Корпорация 3Сom Фирма 3Сom (США) объединяет в своей сетевой операционной сис- теме 3+ средство межсетевого взаимодействия, доступное для прог- раммного обеспечения на основе NETBIOS. ПЭВМ IBM скрыто разделяют (совместно используют) данные в ЛВС Ethernet и Token-Ring через удаленные модемы или межсетевые мосты. 3+ поддерживает такие основанные на NETBIOS прикладные прог- раммы, как MDBS III, версия 3.09, IBI PC Focus, Hayes SmartCom II (для PC Network), DCA Crosstalk XVI (Версия Network) и IrmaLan, PCOX 3270 gateway (шлюз), IBM Async Server (асинхронный спецпроцес- ссор), IBM PC Network Program (Программа Сети ПЭВМ), IBM PC 3270 Emulation Program (Программа эмуляции), Network Courier и Brightwork Software's Net Remote. 3Com достигает межсетевого взаимодействия с NETBIOS путем объ- единения интерфейса NETBIOS со своими управляющими программами (драйверами) коммуникации Сетевого стандарта Ксерокс (XNS - Xerox Networking Standard): 3+ транслирует запросы NETBIOS в запросы XNS, которые должны быть отправлены по сети; когда либо от удаленной, либо от местной сети получаются ответы, они затем обратно перево- дятся в формат вызова NETBIOS. Что касается прикладной программы NETBIOS, то все запросы и ответы NETBIOS (но не обязательно время ответа!) представляются как местные. 3Сom и OS/2 3+ open - новейший спецпроцессор 3Com, поддерживающий рабочие станции OS/2 и рабочие станции DOS. Поддерживаются интерфейс NETBIOS и интерфейс управляющей процедуры (DLC). Управляющая проце- дура поддерживает APPC (Перспективное Межпрограммное Взаимодейст- вие), которое использует интерфейс управляющей процедуры (DLC) в физическом сетевом соединении. Интерфейс управляющей процедуры (DLC) также поддерживает протоколы IBM NETBIOS и Token-Ring, используемые Спецпроцессором ЛВС OS/2 IBM (см.Главу 6). 3+ open подддерживает Поименованные Каналы (Named Pipes), средство Администратора (Manager) ЛВС Microsoft, если имеется ин- терфейс, который расширяет межпроцессовое взаимодействие OS/2 проз- рачно в сети. Поименованные каналы предоставляют более высокоуров- невый интерфейс для APPC, NETBIOS или транспортного уровня сети, что облегчает создание прикладной программы, которая использует удаленные вызовы процедур в сети. Поименованные каналы служат до- полнением к межпроцессовым каналам, используемым в OS/2. Поименованные каналы (Named Pipes) позволяют разработчику прик- ладной программы получать доступ к вычислительному ресурсу (находящемуся в любом месте сети), как будто он является местным. Поименованные каналы облегчают создание встроенных в сеть приклад- ных программ. Это не исключает наличие возможности для разработ- чика прикладных программ писать эти программы непосредственно используя интерфейсы прикладного программирования (API) транспорт- ного уровня, APPC (Перспективное межпрограммное взаимодействие) или NETBIOS. АНАЛИЗАТОР ПРОТОКОЛОВ С усложнением ЛВС возникает необходимость в применении специа- лизированных инструментальных программных средств, предназначенных для диагностирования, отладки, обслуживания, управления и контроля сети. Первыми средствами такого рода стали средства сбора статисти- ческих данных о работе сети (например, о загрузке сети, количестве передаваемых в секунду пакетов и т.п.) и о "здоровье" сети (напри- мер, ошибки контроля по циклическому избыточному коду, конфликты, утерянные лексемы). Эти средства управляют преимущественно физичес- ким и канальным уровнями ЛВС. Вторая - более высокоуровневая - категория таких средств позволяет управлять работой сети, например пользовательским досту- пом к узлам сети и портам, подсоединенным к этим узлам, а также оп- ределять различные параметры, при которых узлы будут работать (нап- ример, постоянные виртуальные каналы связи, характеристики термина- ла, управление потоком). Третья категория подобных средств - средства, могущие управ- лять промежуточными протоколами - Уровни с 3 по 6 Модели соединения открытых систем OSI. С помощью этих средств можно управлять работой протоколов и обнаруживать неполадки. Такие средства также позволяют разработчикам реализовывать и отлаживать протоколы, обеспечивая их совместимость с определенным набором протоколов (таким как NETBIOS, к примеру). "ИЩЕЙКА" (Sniffer) Первым появившимся в продаже анализатором протоколов для NETBIOS (и единственно доступным на время написания этой книги) стал продукт фирмы Network General Corporation (США) "The Sniffer" (ИЩЕЙКА). Он представляет собой комбинацию программного и аппаратного обеспечения, которое служит в качестве кадрового анализатора для IBM Token-Ring, Ethernet, Starlan и ARCNET. Он может получать для анализа все кадры, передаваемые в сети. Он управляет сетью и анали- зирует данные подобным же образом, как логический анализатор выпол- няет то же самое для цифровых сигналов. Программное обеспечение включает управление работой сети в реальном времени и фильтрацию требуемых типов пакетов. Для более сложных последовательностей со- бытий, пользователь может отладить программу на определенные усло- вия внутреннего прерывания. Все кадры имеют временную метку и могут храниться на диске для дальнейшего анализа. Еще одна полезная функция анализатора - его способность вво- дить кадры в сеть, что позволяет определять реакцию сети на возрас- тание нагрузки. Подобный "анализ загруженности сети" может опреде- лить последствия подключения более активных устройств в сеть. В сеть могут вводится также "экстра-пакеты" или пакеты с ошибками, чтобы установить как рабочая станция или спецпроцессор будет их об- рабатывать. Имеющиеся наборы протоколов включают: некоторые варианты TCP/IP (включая ARP, TCP, UDP, ICMP, DNS, Telnet); протокол NFS Sun Microsystems (включая RPC, YP и PMAP); ISO 8473 IP (межсетевой); ISO 8073 TP класс 4 (транспортный); протоколы XNS, используемые Xerox, 3Com 3Plus и Ungermann-Bass (включая PEP, SPP, RIP и Courier); протокол Блока сообщений спецпроцессора (SMB), разрабо- танный Microsoft для MS-Networks и также используемый в Программе IBM PC LAN; NETBIOS; NetWare Core Protocol, используемый для веде- ния диалога между рабочей станцией и файловым процессором; протоко- лы управления логическим каналом (LLC) IEEE 802.2 Тип 1 и Тип 2, используемые виртуально всеми ЛВС ЭКС и ЛВС Ethernet; протокол уп- равления доступом к носителям (MAC), являющийся разновидностью про- токола IEEE 802.5, используемого в IBM Token-Ring. Анализатор протоколов создан на основе высокопроизводительной ПЭВМ (портативная ЭВМ совместимая с IBM PC AT с процессором 8 Мгц), что позволяет применять это инструментальное средство как в стацио- наре, так и "в поле". Компания Excelan разработала средство, подобное Sniffer, но предназначенное для ЛВС Ethernet - LANanalyser. Также созданный на основе портативной ЭВМ, совместимой с IBM PC AT, (фирмы Compaq), этот анализатор позволяет проводить анализ трафика в ЛВС Ethernet. Программное обеспечение не обеспечивает непосредственную поддержку для управления протоколами NETBIOS, но оно позволяет осуществлять отладку для управления кадрами определенных битовых образцов. Поль- зователь, знающий поля битов в пакетах NETBIOS, может, таким обра- зом, установить систему для управления этими пакетами. Г Л А В А 6 MICROSOFT и IBM ----------------------------- Историческая справка Когда в 1984 году было впервые объявлено о Сети ПЭВМ IBM (IBM PC Network), возник вопрос: какое сетевое программное обеспечение реализовала фирма IBM ? Своеобразный ответ на него дали компании- продавцы ЛВС: они предложили Сети MICROSOFT (Microsoft Networks), думая, что именно это программное обеспечение используется в Сети ПЭВМ (PC Network). Принятие такого решения было обусловлено, в час- тности, еще и тем, что операционная система MS-DOS фирмы Microsoft стала PC-DOS для компании IBM. (Сети Microsoft (Microsoft Networks) безусловно являются продуктом изготовителей комплексного оборудования. Они не реализованы ни в какой определенной ЛВС - это обусловлено только фирмой-изготовителем комплексного оборудования). Та же история повторилась в апреле 1987 года, когда IBM объя- вила о создании OS/2 одновременно с фирмой Microsoft, которая зая- вила о своем новом продукте - Администраторе ЛВС (LAN Manager). В течение некоторого времени после этого события компания IBM не разглашала свою новинку - "стратегию спецпроцессора", пока не вышла на рынок с новым своим продуктом - Спецпроцессором ЛВС OS/2 IBM (IBM OS/2 LAN Server). И снова возникли затруднения - как же соот- носятся эти два продукта - Спецпроцессор IBM и Администратор Microsoft? В настоящей главе рассказывается об эволюции Сетей Microsoft (Microsoft Networks) и Программы ЛВС ПЭВМ IBM (IBM PC LAN Program), начиная с оригинальной разработки и до их реализации в OS/2. MICROSOFT --------- Сети Microsoft (Microsoft Networks) Только после выпуска Сети ПЭВМ (PC Network) с модулированной передачей фирмы-продавцы и пользователи стали осознавать, что сетевое программное обеспечение в Сети ПЭВМ (которое позднее стало известно как NETBIOS) является несовместимым с Сетями Microsoft (Microsoft Networks) и оно не было создано фирмой Microsoft. В ре- зультате, поток продуктов, совместимых с Сетями Micrsoft, о котором объявили многие фирмы-продывцы ЛВС, никогда не был реализован. После выпуска cети ПЭВМ (PC Network) фирма Microsoft действи- тельно изменила структуру пользовательских команд в Сетях Microsoft (Microsoft Networks), чтобы достигнуть более тесного соответствия с командами, используемыми IBM. (К примеру, команда CONNECT стала ко- мандой NET USE). Фактически, команды Сетей Microsoft являются в значительной степени "подмножеством" команд, используемых в Прог- рамме ЛВС ПЭВМ IBM (IBM PC LAN Program). Один из компонентов реализации IBM NETBIOS был написан фирмой Microsoft: это непопулярный в настоящее время передресатор. Он тес- то связан с PC/MS-DOS в том смысле, что используется протокол Блока сообщений спецпроцессора (SMB) (см. Главу 5), хотя остальная часть Сетей Microsoft и NETBIOS спроектирована таким образом, чтобы обес- печить независимость как от операционной системы, так и от ЛВС. Се- ти Microsoft (Microsoft Networks) доступны как для Xenix (реализа- ция UNIX, System V фирмой Microsoft), так и для MS-DOS. Переадреса- тор предназначен для того, чтобы запросы на услуги (например, отк- рытие или распечатка файлов), которые обычно обрабатываются в мест- ном "режиме", были, при необходимости, перехвачены, преобразованы в сетевой запрос и направлены для исполнения спецпроцессору. Подобно NETBIOS, Сети Microsoft (Microsoft Networks) предназ- начены для работы с MS-DOS 3.1 (на ней основан и спецпроцессор и рабочая станция) или же с более высокой версией этой операционной системы. Режимы коллективного использования файлов и режимы блоки- ровки файлов идентичны. Аналогична и расширенная схема поименова- ния: \\имя_спецпроцессора\каталог\файл (\\server_name\directory\file). Сети Microsoft и NETBIOS Основное различие между ранней версией Сетей Мicrosoft (Microsoft Networks) и NETBIOS заключается в том, что Сети Microsoft предоставляют интерфейс транспортного уровня, в то время как интерфейс NETBIOS находится на сеансовом уровне. Сети Microsoft также включают специализированной программное обеспечение спецпро- цессора и рабочей станции, тогда как Программа ЛВС IBM PC обеспечи- вает эти и другие функции, включая неспециализированный спецпроцес- сор. Транспортный уровень Сетей Microsoft используется для отправки сообщений через виртуальные каналы. По одному запросу может быть передано до 64 кбайт. Коммуникация (обмен данными) с транспортным уровнем осуществляется посредством прерывания 21H, функция 5BH (на- помним, что NETBIOS использует прерывание 21H, функция 5CH). Коммуникация с транспортным уровнем производится посредством установки Блока управления транспортом (Transport Control Block, сокращенно TCB), а затем выполнения прерывания 21H. Блок управления транспортом аналогичен Блоку управления сообщениями (MCB) или Блоку управления сетью (NCB) в NETBIOS. Фактически, многие поля являются общими как для реализации TCB, так и для реализации NCB/MCB. На рис. 6-1 показана структура Блока управления транспортом (TCB). ИМЯ ПОЛЯ ДЛИНА (байт) и ЗНАЧЕНИЕ ------------------------------------------------------------------- ! COMMAND ! 1 Поле команды ! ! ! ! ------------------------------------------------------------------- ! CID ! 1 Идентификатор команды ! ! ! ! ------------------------------------------------------------------- ! VCID ! 1 Идентификационный номер виртуального канала ! ! ! ! ------------------------------------------------------------------- ! LENGTH ! 2 Размер буфера данных ! ! ! ! ------------------------------------------------------------------- ! BADDR ! 4 Указаталь на адрес буфера сообщения ! ! ! (смещение:сегмент) ! ------------------------------------------------------------------- ! RES1 ! 2 Зарезервированное ! ! ! ! ------------------------------------------------------------------- ! LADDR ! 16 Местный адрес ! ! ! ! ------------------------------------------------------------------- ! RADDR ! 16 Удаленный адрес ! ! ! ! ------------------------------------------------------------------- ! ASYNC ! 4 Указатель на подпрограмму нотификации (объявления)! ! ! адреса (смещение:сегмент) ! ------------------------------------------------------------------- ! LNET ! 4 Местный номер ЛВС ! ! ! ! ------------------------------------------------------------------- ! RNET ! 4 Удаленный номер ЛВС ! ! ! ! ------------------------------------------------------------------- ! RTO ! 1 Тайм-аут получения (шаг равен 500 мсек) ! ! ! ! ------------------------------------------------------------------- ! STO ! 1 Тайм-аут отправки (шаг равен 500 мсек) ! ! ! ! ------------------------------------------------------------------- ! RES2 ! 8 Зарезервированное ! ! ! ! ------------------------------------------------------------------- Рис. 6-1. Блок управления транспортом (TCB). Как и для оригинального NETBIOS в Сети ПЭВМ с модулированной передачей (PC Network), сетевой уровень в Сетях Microsoft реализо- ван лишь в минимальной степени. Имеется поддержка для иерархическо- го адреса, состоящего из 4-байтового адреса сети и 16-байтового ад- реса станции. Также имеется низкоуровневая поддержка для услуги дейтаграмм, позволяющая отправлять/принимать неквитированные пакеты длиной до 512 байт. Изготовитель комплексного оборудования должен решить, как отобразить адреса станций в адресах сети и как реализо- вать алгоритм маршрутизации, если будет разработан шлюз. К сожалению, между Сетями Microsofdt и NETBIOS существует мно- го различий, что затрудняет совместимость этих продуктов. Кроме уже упромянутых различий, несовместимыми являются и две схемы поимено- вания. NETBIOS позоляет иметь несколько имен, динамически переназ- начать имена и транслировать их; в то сремя как в Сетях Microsoft требуется, чтобы администратор присваивал только одно логическое имя каждому физическому адресу. Несмотря на различия в обеих реализациях, у них есть один об- щий недостаток: обе основываются на MS-DOS для выполнения услуг в файловом процессоре. Другими словами, на них влияют недостатки опе- рационной системы - однопользовательской и "однозадачной". В первой редакции данной книги мы написали следующее: "Не совсем ясно, смо- жет ли 'многозадачная' версия DOS решить эту проблему, потому что для успешной своей работы она более чем вероятно НЕ будет совмес- тима с предыдущими версиями DOS,что полностью обезоружит пять мил- лионов владельцев ПЭВМ". Как оказалось, OS/2 поддерживает только некоторые команды DOS и лежащую в основе DOS файловую структуру, что не устраняет трудности в работе для любого спецпроцессора ЛВС, действующего под управлением OS/2. (Метод, имеющийся в DOS, - метод использования таблицы размещения (записей) файла (FAT) потребует проведения интенсивного табличного поиска при открытии, закрытии и поддержании файла). Некоторые фирмы-продавцы, объявившие о поддержке Сетей Microsoft, выпустили на рынок промышленные версии для своих сетей. Многие из них предлагают также и NETBIOS, т.к. Сети Microsoft вклю- чают "образец" эмулятора NETBIOS, который фирмы-изготовители комп- лексного оборудования могут предлагать наряду со своими продукта- ми. Получилось так, что первоначальная полезность Сетей Microsoft в чистой среде MS-DOS была некоторым образом ограничена. Первоначаль- но Сети Microsoft были для ЛВС с комбинацией операционных систем DOS и Xenix. Администратор ЛВС С появлением Администратора ЛВС (LAN Manager) Microsoft (од- новременно с PS/2 и OS/2), переадресатор стал называться Генерато- ром запросов (Запросчиком), а NETBIOS стал интерфейсом прикладного программирования (API) для OS/2. Администратор ЛВС работает под уп- равлением OS/2 на PC AT или PS/2 Модель 50 и выше с процессором 80286 или 80386. ПЭВМ рабочей стванции может действовать либо с М S-DOS и Программой ЛВС ПЭВМ (PC LAN Program), которая требует наличия NETBIOS, либо с OS/2 и новым интерфейсом прикладного прог- раммирования (API) NETBIOS. Администратор ЛВС OS/2 Microsoft (созданный совместно с 3Com) позволяет пользователям соединять системы ПЭВМ под управлением либо Microsoft OS/2, либо MS-DOS вместе в единую цепь. Системы под уп- равлением Microsoft XENIX и XENIX Net могут быть также подсоединены к этой же сети. В подобной сети система на основе Microsoft OS/2 может рабо- тать одновременно и как рабочая станция и как спецпроцессор; Систе- мы MS-DOS работающие в Сетях Microsoft, могут действовать как спец- процессор или рабочая станция. Системы на основе XENIX могут рабо- тать и как спецпроцессор и как рабочая станция одновременно. Администратор ЛВС OS/2 Microsoft дает такие сетевые возможнос- ти, как прозрачное совместное использование файлов и печати, средс- тва защиты пользователя и инструментальные средства управления сетью. Вследствие того, что Администратор ЛВС OS/2 Microsoft тесно связан с операционной системой MS OS/2, интерфейсы программирования работают во всей сети как прозрачные. Средство межпроцессовой ком- муникации (IPC) облегчает процесс непосредственного обмена данными (коммуникации между прикладными программами, хотя они и находятся на разных машинах в сети. Разработчики прикладных программ смогут создать единую версию программного продукта, который может работать как на отдельной машине, так и на нескольких мамшинах, соединенных Администратором ЛВС OS/2 Microsoft. Такие фирмы как Novell и 3Com предложили свои собственные версии Средства межпроцессовой коммуни- кации (IPC) до OS/2. Администратор ЛВС OS/2 Microsoft полностью совместим с сущест- вующими продуктами Сетей Microsoft как для операционной системы MS-DOS, так и для XENIX. Это позволяет новым системам под управле- нием MS-DOS взаимодействовать с существующими сетями, поддерживаю- щими Сети Microsoft. Большинство фирм-изготовителей комплексного оборудования, предлагающих Сети Microsoft (включая HEWLETT PACKARD, TandemTandem, DEC, Ungermann-Bass, 3Com/Bridge, AT&T, Nothern Telecom, AST Research, Apricot, Seimens, Bull, Intel, NEC Japan, XeroxXerox, SMT Goupil Research Machines и Digital Microsystems) также будут пред- лагать Администратор ЛВС Microsoft. Фирма IBM - заметное исключение из этого списка. Несмотря на то, что Сети Microsoft и Программа ЛВС ПЭВМ/NETBIOS имеют много общего, IBM не собирается поддерживвать Администратор ЛВС, планируя позже предложить программное обеспече- ние для Спецпроцессора ЛВС OS/2 (LAN Server). Еще одно различие между Microsoft и IBM - Расширенная версия OS/2 IBM (IBM OS/2 Extended Edition), которая стала собственной версией OS/2, создан- ной фирмой IBM. От изготовителей комплексного оборудования OS/2 Microsoft будет зависеть, оказать ли поддержку Расширенной версии IBM. Многие фирмы оснащают Стандартную версию дополнениями, напри- мер, пакетом APPC/PC. Взаимодействие Администратора ЛВС и API NETBIOS Интерфейсы прикладного программирования (API) для OS/2 Microsoft предоставляют доступ к сетевым функциям и используются языками высокого уровня. API обеспечивает два вида функций: 1. Вызовы функций, ориентированных на прикладные программы. Эти функции предназначены для сетевых прикладных программ, которые выполняют сложные задачи, например, используют сетевые ресурсы, запрашивают или управляют удаленным печатающим устройством с буфе- ризацией, посылают или получают сообщения и т.п. 2. Вызовы функций, ориентированных на управление. Эти функции позволяют получать полный доступ к или управлять удаленным спецпро- цессором, например, запускать, делать паузу или продолжать работу программ спецпроцессора, разделять и закрывать разделение ресурсов спецпроцессора, запрашивать/управлять сеансами спецпроцессора и т.п. Интерфейс прикладного программирования (API) Администратора ЛВС имеет те же ограничения, что и стандартный API DOS. API использует программную модель удаленного вызова процедуры, чтобы обеспечить уп- равление удаленными спецпроцессорами и их ресурсами как местными. Такие вызовы принимают параметр имени спецпроцессора, который ука- зывает цель операции. Для того, чтобы предотвратить несанкциониро- ванное использование, некоторые функции, вызванные удаленно, выпол- няются только, если запрашивающий пользователь имеет преимущество в управлении данным спецпроцессором. Управляющая программа (драйвер) NETBIOS - одна из категорий, определенная Интерфейсом прикладного программирования (API) Адми- нистратора ЛВС. Администратор ЛВС определяет и другие категории. Просто перечислим их. Рабочая станция (WORKSTATION) - Информация о конфигурации рабочей станции. Использование переназначения - Соединение удаленного (REDIRECT USE) устройства рабочей станции Сообщения (MESSAGING) - Отправка и прием сообщений от пользователя к пользователю Тревога (ALERT) - Управляет и поднимает тревогу в сети Каналы (PIPES) - Двустроронняя коммуникация процессов Почтовые участки (MAILSLOTS) - Односторонняя коммуникация процессов Параметры пользователя - Сохраняет/восстанавливает (PROFILE) активное использование/ совместное использование Конфигурация (CONFIG) - Устанавливает элементы из файла LANMAN.INI Спецпроцессор (SERVER) - Конфигурация спецпроцессора и статистические данные о нем Совместное использование - Совместное использование файла (SHARES) и устройства спецпроцессора Сеансы (SESSIONS) - Машинные сеансы спецпроцессора Cоединения (CONNECTIONS) - Пользовательские соединения спецпроцессора Файлы (FILES) - Открытые файлы спецпроцессора Регистрация (AUDITING) - Регистрация в контрольном журнале Регистрация ошибок - Регистрация системных ошибок (ERROR LOGGING) Символьные устройства - Соединения с удаленными (CHAR DEVICES) символьными устройствами Очереди печати (PRINT QUEUES) - Очереди заданий системы буферизации потоков I/O Задания печати (PRINT JOBS) - Задания печати системы буферизации Назначения печати - Виртуальные устройства в (PRINT DESTINATIONS) системе буферизации Разрешения на доступ - Разрешения на доступ к файлам (ACCESS PERMISSIONS) и другим ресурсам Пользователи (USERS) - Разрешения на пользование файлами и групповое членство Статистика (STATISTICS) - Статистические данные о работе рабочей станции и спецпроцессора Удаленные (REMOTE) - Удаленные функции, такие как удаленное выполнение програм- мы, копирование файлов и передвижение файлов Смешанные (MISCELLANEOUS) - Время дня в сети и т.п. Доступ к управляющей программе NETBIOS осуществляется вызовом Enum. Вызовы Enum перечисляют тип ресурса, является ли он именами пользователей, заданиями в очереди, очередями в спецпроцессоре и т.д. Вызовы всегда возвращают целое число частей ответа фиксирован- ной длины. Если буфер пользователя слишком мал,некоторые данные пе- ременной длины не возвращаются, вероятнее всего,для последнего эле- мента, хотя это и не обязательно. Кодом возврата является "больше данных", включая и данные переменной длины. Этот пераметр показыва- ет количество возвращенных "порций" фиксированной длины. Некоторые или все из них могут иметь только часть соответствующих переменных данных, возвращаемых вместе с ними. Вызовы Enum помещают фиксированные структуры в передней части буфера, чтобы дать Вам возможность выполнять в них итерацию. Пере- менные данные помещаются с другого конца буфера. Вызов Enum в NETBIOS обеспечивает два уровня информации: Уровень 0 --------- struct netbios_info_0 {char nb_net_name [16] }; /* nb_net_name is 16 character NETBIOS name */ Уровень 1 --------- struct netbios_info_1 {char nb_ntet_name [16]; char nb_driver_name [9]; /* OS/2 device driver name */ unsigned byte nb_lana_num; /* lan adapter number */ unsigned short nb_driver_type; /* 1 = ncb, 2 = mcb */ unsigned short nb_net_status; /* bit 0 on = net started */ /* bits 14/15 opcodes as follows: */ /* 0 = net not opened */ /* 1 = open in regular mode */ /* 2 = open in privileged mode */ /* 3 = open in exclusive mode */ unsigned long nb_net_bandeidth; /* network bandwidth bits/s */ unsigned short nb_max_sess; /* max number of sessions */ unsigned short nb_max_ncbs; /* max number of outstanding ncbs */ unsigned short nb_max_names; /* max number of names */ Вызовы процедур Вызов процедуры NETBIOSENUM Назначение: перечислить управляющие программы (драйверы) NETBIOS Условие вызова -------------- init far pascal NetBiosEnum(servername,level, buf,buflen,intritsread,totalentries) char far * servername; /* name of tart PC (null if local) */ char far * buf; /* pointer to info buffer */ unsigned short buflen; /* byte length of info buffer */ unsigned short far * entriesread; /* # of entries supplied on return */ unsigned short far * totalentries; /* total # of entries available */ Величина возврата ----------------- Содержимое буфера при возврате (формат для одного элемента) может быть одно из следующих: Уровень 0 содержит "struct_netbios_info_0", Уровень 1 содержит "struct_netbios_info-1". Возврат ошибки -------------- Возврат функции 0 означает, что все нормально. Возможными воз- вратами ошибок могут быть следующие: - сеть не начала работать; - устройство не найдено; - спецпроцессор не найден; - сбой в обмене данными с удаленным спецпроцессором. Вызов процедуры NETBIOSGETINFO Назначение: Получение информации о данной управляющей программе (драйвере) NETBIOS. Условие вызова -------------- int far pascal netbiosgetinfo (servername,netdevname,level,buf,buflen) int far pascal netbiosgetinfo (servername,netbiosname,level,buf,buflen) char far * servername; /* name of target pc (null if local) */ char far * netbiosname; /* netbios network name */ short level; /* level of info requested */ char far * buf; /* pointer to info buffer */ unsigned short buflen; /* byte length of info buffer */ Уровень 1 содержит "struct netbios_info_1". Возврат ошибки -------------- Функция возвращает 0, если все нормально. Ниже возможны даны возможные возвраты онибок: - слишком мал размер буфера для фиксированных полей; - устройство не найдено; - спецпроцессор не найден; - сбой в обмене данными с удаленным спецпроцессором. Вызов процедуры NETBIOSOPEN Назначение: Получает handle для отправки управляющей прог- рамме NETBIOS. Описание -------- Вызов этой процедуры создает handle для отправки Блоков управления сетью (NCB) в управляющую программу (драйвер) NETBIOS. Программа может определить, какими эти имена являются, путем вызова NETBIOSENUM. Нулевая (пустая) строка может быть использована как имя устройства для скрытой ссылки на первую установленную управляю- щую программу NETBIOS. NETBIOSOPT определяет открытые опции, которые включают в себя: Режим доступа: 1. Обычный (регулярный) (mask 0x3) 2. Привилегированный 3. Исключительный Режим доступа определяет каким образом пользователь хочет раз- делить доступ к управляющей программе NETBIOS с другими процедура- ми. В регулярном режиме драйвер (управляющая программа) может быть открыт любым количеством процедур. Помимо этих процессов, еще один процесс может открывать драйвер в привилегированном режиме. Один и только один процесс может открывать драйвер в исключительном режи- ме. В зависимости от режима доступа операции Блока управления сетью (NCB) ограничены. Режим Описание ----- -------- Регулярный Не позволяет переустанавливать, получать широковещательные дейтаграммы, получать "от любого к любому" Блоки управления сетью (NCB), или использовать постоянные имена в любом Блоке управления сетью (NCB). Превилеги- Не позвроляет переустанавливать или полу- рованный чать NCB "от любого к любому". Исключительный Позволяет выполнять любые операции NCB. Условие вызова -------------- int far pascal netbiosopen (netbiosname, netreserved, netopenopt, nethandle) char far * netbiosname; /* Name of NETBIOS network */ char far * netreserved; /* reserved pointer; must be 0 */ unsigned short netopenopt; /* open options */ int far * nethandle; /* word for returned handle */ Возврат ошибки -------------- Функция возвращает 0, если все нормально. Возможными возврата- ми ошибок являются: - Управляющая программа (драйвер) NETBIOS не существует; - неверная опция; - открытый режим противоречит существующему; - недоступны ресурсы системы. HANDLES NETBIOS являются связями процесс-драйвер. Только тот процесс, который создал данный драйвер, может его использовать. Вызов процедуры NETBIOSCLOSE Назначение: Закрывает handle драйвера NETBIOS. Описание -------- Вызов этой процедуры завершает доступ к драйверу NETBIOS, де- лает "ошибочным" handle и отменяет все Блоки управления сетью, вызванные процессом, который создал данный идентификатор. Условие вызова -------------- int far pascal netbiosclose (nethandle, netreserved) int nethandle; /* handle to close */ short netreserved; /* reserved, must be zero */ Возврат ошибки -------------- Функция возвращает 0, если все нормально. Возможные возвраты ошибок: - неверный handle. Вызов процедуры NETBIOSSUBMIT Назначение ---------- Передает Блок управления сетью (NCB) драйверу NETBIOS. handle 0 относится к первому установленному драйверу NETBIOS. Этот драйвер автоматически подвергнут действию процедуры NETBIOSOPEN при необходимости (в регулярном режиме) сразу же, как только вызов NETBIOS обратится к нему используя идентификатор 0. NETNCB указывает на Блок управления сетью (NCB), который дол- жен быть выполнен (несцепленный NCB) или на слово-связку, предшест- вующее NCB (сцепленный NCB). NETNCBOPT определяет опции обработки NCB, которые включают: Сцепление: 0 отдельных NCB передается (mask 0x3) 1 отдельный NCB с повторением при ошибке 2 NCB сцепливаются с продолжением при ошибке 2 NCB сцепливаются с остановкой при ошибке Опции сцепления определяют, передается ли отдельный NCB или цепочка NCB. Отдельный Блок NCB может быть выполнен с опцией пов- торной передачи при ошибке, - в этом случае ядро сети выдает NCB установленное количество раз в ответ на следующие ошибки: 09H - нет доступных ресурсов; 12H - отказано в открытии сеанса; 21H - занят интерфейс. Сцепленные NCB должны быть в одном и том же сегменте и должны быть связаны 16-битовым указателем смещения, который предшествует NCB. Смещение 0xFFFF определяет конец сцепливания. Хотя может быть сцеплена любая последовательность команд NCB, не все возможности являются приемлимыми. Например, Вы не можете от- крыть сеанс и послать пакет данных по нему, связав команды SEND и CALL. Поле NCB_LSN, возвращенное по команде CALL NCB, должно быть скопировано в SEND NCB - ядро сети не поддерживает этого автомати- чески. Блоки управления сетью (NCB) в цепочке "с продолжением при ошибке" выполняются независимо один от другого, и вне зависимости от ошибок в цепочке; подобная цепочка просто обеспечивает быструю передачу набора Блоков NCB драйверу. Блоки, которые не были обрабо- таны вследствие ошибки ранее в цепи, будут иметь свое поле NCB-CMD-CPLT установленное как 0xB (Команда отменена). Этот тип це- почки обычно должен иметь только режим ожидания. Неожидаемые Блоки NCB принимаются, но в этом случае именно немедленный (а не конеч- ный) возврат определяет, продолжится или остановится процесс. Условие вызова -------------- int far pascal netbiossubmit (nethandle, netncbopt, netncb) int nethandle; /* handle to issue ncb against */ unsigned short netncbopt; /* option flags */ struct ncb far * netncb; /* Address of NCB */ Функция возвращает 0, если все нормально. Возможными возвра- тами ошибок являются: - неверный handle; - неправильные опции; - отказано в доступе; - недоступны ресурсы драйвера; - определенные NETBIOS коды немедленного возврата (неожидаемый NCB); - определенные NETBIOS коды конечного возврата (режим ожидания NCB). Функционирование Ядро Сетей Microsoft (Microsoft Networks), используемое Адми- нистратором ЛВС (LAN Manager), поддерживает несколько управляющих программ (драйверов) NETBIOS посредством рассмотрения каждой как поименованного устанавливаемого драйвера устройства, который может быть открыт и закрыт. Прикладные программы, использующие один и тот же драйвер NETBIOS, могут получать совместный доступ к именам и се- ансам, которые они создали, просто путем передачи номера имени или сеанса другому процессу. Это позволяет другим процессам посылать и получать данные от имени процессов-"владельцев", или же высвобож- дать совместно используемые имена и сеансы. В защищенном режиме Блоки управления сетью (NCB) NETBIOS обрабатываются также, как и под управлением MS-DOS 3.X, посредством прерывания 5C и 2A, за исключением следующего: 1. Поле NCB_POST@ теперь содержит handle семафора системы, а не подпрограмму асинхронной нотификации (объявления). Ядро сети освободит этот семафор, когда завершится режим неожидания NCB.Иден- handle семафора, равный 0, считается пустым и не освобождается. 2. Поля NCB_POST@ и NCB_BUFFER@ временно изменены ядром сети во время обработки Блока управления сетью (NCB). Прикладные прог- раммы не должны зависеть от величин этих полей, пока не будет за- вершен NCB. 3. Некоторые функции NCB не разрешены, в зависимости от режима доступа, определенного вызовом NETBIOSOPEN. 4. Процессы могут коллективно использовать ресурсы NETBIOS, которыми они располагают, просто путем передачи номеров требуемых имен и сеансов другим процессам (как об этом сказамно выше). Полу- чающие процессы просто используют номера общих имен или сеансов в Блоках управления сетью (NCB), которые они создают. Такие процессы должны, безусловно,послать Блоки NCB против handle, которые они сами создали (процедурой NETBIOSOPEN), в этот же драйвер. Компания IBM -------------- Программа ЛВС ПЭВМ Программа ЛВС ПЭВМ IBM (IBM PC LAN Program), ранее носившая имя Программа Сети ПЭВМ IBM (IBM PC Network Program) была первона- чально предназначена для работы с DOS 3.1 и Сетью ПЭВМ IBM (IBM PC Network) с модулированной передачей. Программа ЛВС ПЭВМ требует поддержки NETBIOS посредством Служебной Программы ЛВС ПЭВМ (PC LAN Support Program) и DOS 3.2 или выше, для работы в ЭКС Token-Ring. Программа ЛВС ПЭВМ (PC LAN Program) состоит из одного большого файла, который может быть вызван одним из четырех способов: пользо- ватель выполняет команду NET START,а затем определяет переадресатор, получатель, отправитель или спецпроцессор. Первые три варианта (переадресатор,получатель, отправитель) предназначены для рабочих станций, а последний (спецпроцессор) является неспециализированным файловым процессором/процессором печати, который работает как фоно- вая задача на рабочей станции. На рис. 6-2 показан образец такой реализации, где одна ПЭВМ служит как файловый процессор, а другая - как процессор печати. Отправитель -------- Переазначатель ! !-----! Отправитель ---------- ------!- ! --------- ---------! ! ! !-----! ! ! --!------- ! -----!--- ! ! ! ! ! ! ! ! ! ! ! ! ! _____!____________!______!____________!___ ! ! ! ! ! !_!___________!________!__________!______! ! ! ! ! ! ------ ! ! ! ! ! ! ! ! ! ! ! ! ! --!------ ______ ! ! ! ! !_____!_____! ! ! ! --------- SP -----!-- ! ! Спецпроцессор ! !-------- ! ! -------- ! ---!----- Переназначатель !-----! @! SHD --------- Спецпроцессор ПРИМЕЧАНИЯ: -------- Логический маршрут комамуникации SHD - Коллективно используемый жесткий диск SP - Коллективно используемое печатающее устройство Рис. 6-2. Программа ЛВС ПЭВМ (PC LAN). Наиболее традиционный способ построения сети - с помощью пере- адресатора. Он перехватывает ввод/вывод диска и печатающего уст- ройства рабочей станции и посылает его на спецпроцессор; пользова- тели также могут посылать сообщения на другие машины. Получатель, отправитель и спецпроцессор делают то же, что и переназначатель, но со следующими добавлениями: получатель получает и регистрирует со- общения на любом устройстве или файле; отправитель позволяет поль- зователю передавать файлы; спецпроцессор позволяет совместно ис- пользовать жесткие диски и печатающие устройства. Процедура установки управляется меню. Если установка произве- дена, с Программой Сети ПЭВМ (PC Network Program) можно работать либо набирая команды на клавиатуре по подсказке DOS, либо с помощью меню. Первоначальная версия программы ЛВС ПЭВМ подверглась жесткой критике - главным образом из-за проблем, связанных с производитель- ностью. Эта проблема обусловлена тем, что, в отличие от NetWare фирмы Novell, Программа ЛВС ПЭВМ основывается на DOS для работы с файлами и печатью. Но с совершенствованием операционной системы и появлением OS/2, эта проблема потеряла свою остроту. Например, DOS 3.3 имеет дополнительно таблицу размещения записей файла (FAT) (команду FASTOPEN). Весия 1.3 Программы ЛВС ПЭВМ (PC LAN Program) имеет следующие свойства, которые облегчили по сравнению с первоначальной версией этой программы и проблему управления: контролируемый паролем доступ к спецпроцессору; централизированное определение ресурсов и управ- ление ими, включая установку времени/даты на главном спецпроцессоре для синхронизации даты и времени на всех спецпроцессорах и рабочих станциях, для управления печатью, определения пользователей и при- вилегий, а также для управления меню выбора прикладных программ для отдельных пользователей; доступ администратора к ресурсам с любой рабочей станции, поддержка для удаленной загрузки программ и опера- ционной системы (т.е. поддержка для рабочих станций, не имеющих дисков); возможность просматривать начавших сеанс пользователей, и, наконец, выбор печати, очередность и отображение состояния для уда- ленных рабочих станций. Версия 1.3 также обладает повышенной произ- водительностью работы. Спецпроцессор ЛВС Спецпроцессор ЛВС OS/2 IBM (LAN Server) использует NETBIOS для обмена данными (коммуникации) в ЛВС. Спецпроцессор обеспечивает, как для прикладных программ DOS (посредством Программы ЛВС ПЭВМ), так и для прикладных программ OS/2, совместное использование ресур- сов - дисков, печатающих устройств и подсоединенных устройств, плюс средства для определения, управления и руководства доступом к ре- сурсам ЛВС, наряду с повышенной защитой и управлением печатью (до восьми печатающих устройств). Эти преимущества сходны с теми, кото- рые обеспечиваются Программой ЛВС ПЭВМ (PC LAN Program), за исклю- чением того, что защита файлов снижена до файлового уровня. Для ра- боты Спецпроцессора ЛВС требуется Расширеная версия OS/2 (Extended Edition). Спецпроцессор ЛВС также обеспечивает удаленнрое выполне- ние программ. Часть программного обеспечения Спецпроцессора ЛВС бала создана фирмой Microsoft (в основном переадресатор). Фирма IBM не реализо- вала многие из Интерфейсов прикладного программирования (API) Microsoft в Администраторе ЛВС (LAN Manager), в частности, Средства межпроцессовой коммуникации, которые несовместимы с Прикладной ар- хитектурой систем (Systems Application Architecture - SAA). Вместо этого, для разработки распределенных прикладных программ необходимо использовать APPC/PC (Перспективное межпрограммное взаимодейст- вие/ПЭВМ), включенное вместе с Расширеной Версией OS/2, особенно в ЭКС Token-Ring со смешанными ЭВМ. Для ЛВС ПЭВМ эта проблема не столь остра - в них можно использовать Администратор ЛВС или другие продукты на основе спецпроцессора, чтобы обеспечить совмес- тимость продуктов. Крупные фирмы, такие как 3Com, Banyan и Novell, предлагают, по меньшей мере, некоторый уровень совместимос- ти (как, например, APPC) с Расширенной Версией OS/2 и Спецпроцессо- ром ЛВС OS/2. Таким образом, создается впечатление, что компания IBM рас- сматривает Спецпроцессор ЛВС как средство перехода от DOS к OS/2. В этом убеждает и тот факт, что Спецпроцессор ЛВС рабо- тает под управлением OS/2 и обслуживает как Программу ЛВС ПЭВМ (PC LAN Program) на основе DOS, так и эмулятор NETBIOS OS/2. Г Л А В А 7 СТАНДАРТИЗАЦИЯ NETBIOS ------------------------- NETBIOS, по определению IBM, не стал сам по себе стандартом, хотя и принимается как таковой. Предпринимаются попытки реализовать NETBIOS в других сетевых средах, например, основанных на Протоколе управления транспортом/Межсетевом протоколе (TСP/IP), или же основанных на Транспортных и Сетевых протоколах Международ- ной организации по стандартизации (ISO). Министерство обороны США определило TCP/IP для Arpanet и теперь он широко используется во многих коммерческих системах. Сетевые и транспортные протоколы ISO несколько новее, и многие фирмы рассматривают их как настоящий меж- дународный стандарт. Протокол управления транспортом/Межсетевой протокол (TCP/IP) ------------------------------------------------------------ Предлагаемый ниже материал представляет собой (в основном) Докладную записку, в которой охарактеризована концепция и методоло- гия NETBIOS Internet. Вот список фирм, которые в основу NETBIOS положили TCP/IP: Excelan, Ungermann-Bass, 3Com/Bridge, Syntax и Communication Machinery Corporation. Статус Докладной записки Докладная записка определяет предложенный стандарт для сети Internet. Система, описываемая Докладной запискрой, не отражает никакую из существующих реализаций NETBIOS на основе TCP (Протокол управ- ления транспортом), однако, проект в значительной степени основы- вавется на предыдущих разработках (информация о которых была пре- доставлена фирмами CMS/Syros, Excelan, Sytek и Ungermann-Bass). Введение Докладная записка описывает концепции и основные методы, ис- пользуемые для реализации NETBIOS на основе TCP (Протокол управле- ния транспортом) и UDP (Протокол пользовательских дейтаграмм). При- ложение к Докладной записке, "Стандарт протокола для услуги (сер- виса) NETBIOS на основе транспорта TCP/UDP: ДЕТАЛЬНАЯ СПЕЦИФИКАЦИЯ" содержит подробное описание форматов пакетов, протоколов и опреде- ленных констант и переменных. Услуга NETBIOS стала главным механизмом для организации сети вычислительных машин. NETBIOS обеспечивает независимый от фир- мы-продавца интерфейс для PC IBM и совместимых с ними систем. NETBIOS определяет программный интерфейс, а не протокол: "офи- циального" стандарта услуги NETBIOS не существует. На практике, од- нако, версия IBM Сети ПЭВМ (IBM PC Network) используется в качестве руководства. Данная версия описана в документе N 6322916 компании IBM "Техническое руководство IBM по Сети ПЭВМ" (IBM PC Network Technical Reference). Протоколы, поддерживающие услуги NETBIOS, были построены на различном аппаратном обеспечении и на основе различных протоколов. Для обеспечения взаимодействия NETBIOS в Internet, Докладная запис- ка определяет стандартный протокол, поддерживающий услуги NETBIOS с использованием TCP и UDP. В настоящее время применение NETBIOS в основном ограничено ПЭВМ. Однако, вследствие того, что более мощные ЭВМ лучше подходят для выполнения некоторых прикладных программ NETBIOS (например, файловый процессор), данная спецификация была построена таким об- разом, чтобы позволить осуществить реализацию NETBIOS на любом типе системы, где может быть использован набор протоколов TCP/IP (Протокол управления транспортом/Межсетевой протокол). Данный стандарт определяет набор протоколов, поддерживающих услуги NETBIOS. Докладная записка описывает протоколы не столько как простую коммуникационную услугу, включающую два объекта, сколько как расп- ределенную систему, где задействовано множество объектов, даже если они и не участвуют в качестве оконечной точки какого-либо соедине- ния NETBIOS. Настоящий стандарт не ограничивает и не определяет, каким об- разом эти услуги представлены для прикладных программ. Тем не менее, считается желательным, чтобы разработчики сохра- нили бы существующий интерфейс NETBIOS на компьютерах, действующих под управлением операционных систем PC-DOS и MS-DOS. Принципы проектирования Для разработки спецификации были приняты следующие принципы проектирования. Большинство из них типичны для процесса стандарти- зации любых протоколов; некоторые - специфичны именно для NETBIOS. 1. Сохранение услуг NETBIOS. При отсутствии "официального" стандарта для услуг NETBIOS, используется версия, содержащаяся в "Техническом руководствке IBM по Сети ПЭВМ". NETBIOS лежит в основе большого набора существующих прикладных программ. Представляется желательным работать с этими прикладными программами в сетях TCP и расширить их примененипе от ПЭВМ до более мощных рабочих ЭВМ. Для поддержки этих прикладных пргограмм, NETBIOS на основе TCP должен точно соответствовать услугам, предла- гаемым существующими системами NETBIOS. NETBIOS в Сети ПЭВМ IBM (IBM PC Network) имеет некоторые спе- цифичные для данной реализации характеристики. Настоящий стандарт не собирается жестко регламентировать эти особенности. 2. Использование существующих разработок стандартов протокола. Создание новых протоколов должно быть сведено к минимуму. Существенным является то, что существующие стандарты, разумно сочетая необходимую функциональность с достаточной производитель- ностью работы, должны всегда иметь приоритет перед новыми протоко- лами. При использовании стандартного протокола, вносить в него из- менения НЕЛЬЗЯ. 3. Сведение к минимуму количества опций. Стандарт NETBIOS на TCP должен содержать минимальное число опций. Если они имеются, эти опции должны быть спроектированы таким образом, чтобы устройства с различными опциями могли бы взаимодействовать. 4. Устойчивость к ошибкам и сбоям. Сети NETBIOS обычно работа- ют в неконтролируемом режиме; машины включаются и выключаются в се- ти через произвольные промежутки времени; программное обеспечение используется пользователями, незнакомыми с сетями; часто эти поль- зователи могут нарушить отладку сети. Несмотря на этот хаос, сети NETBIOS работают. NETBIOS на TCP должен быть способен хорошо функционировать в подобной среде. Ошибкоустойчивая работа не обязательно означает, что сеть за- щищена от любых сбоев, как вызванных непроизвольно, так и в резуль- тате намеренных действий пользователя. 5. Децентрализация управления. NETBIOS на TCP должен работать, при необходимости, и при отсутствии централизированного управления. 6. Возможность межсетевого взаимодействия. Предлагаемый стан- дарт признает необходимость работы NETBIOS в наборе сетей, взаимос- вязанных посредством межсетевых шлюзов. Стандарт, однако, признает и тот факт, что этот тип функционирования встречается реже, чем ра- бота в ЛВС, связанной посредством мостов между местными носителями. 7. Сведение к минимуму широковещательных операций. Стандарт предполагает, что единственным типом широковещательных услуг должны быть услуги, поддерживаемые UDP (Протоколом пользовательских дей- таграмм). Групповые операции в любой форме должны быть исключены. Несмотря на допустимость широковещательных операций, стандарт признает,что некоторые администраторы сети МОГУТ неинтенсивно испо- льзовать широковещательные сообщения, например, исключить отправку и прием широковещательных сообщений для отдельных оабочих ЭВМ. 8. Реализация на существующих операционных системах. NETBIOS на основе протокола TCP должен иметь возможность реализации на рас- постраненных операционных системах, например, UNIX и VAX/VMS, без сложных преобразований. Протоколы NETBIOS не должны нуждаться в услугах, которые обыч- но не являются доступными в существующих в настоящее время разра- ботках TCP/UDP/IP (Протокол управления транспортом/Протокол пользо- вательских дейтаграмм/Межсетевой протокол). 9. Сведение к минимуму необходимых протоколов. Определение протокола должно описывать только минимальный набор протоколов, не- обходимых для взаимодействия. Дополнительные элементы протоколов могут, впрочем, потребоваться для увеличения производительности. 10. Максимальная эффективность. Чтобы быть полезным, протокол должен действовать быстро. 11. Сведение к минимуму нововведений. Если существующий прото- кол не в состоянии поддержать необходимую функцию, необходимо внес- ти в него небольшие изменения (это проще, чем разработать новый протокол), - однако, число таких изменений должно быть минимально. Поддерживаемые средства Протокол, определяемый данным стандартом, позволяет разработ- чику обеспечить все услуги NETBIOS, описанные в "Техническом руко- водстве IBM по Сети ПЭВМ". Следующие средства не входят в этот список: - Переустановка (RESET); - Статус сеанса (SESSION STATUS); - Прерывание связи (UNLINK); - Удаленная загрузка программы (RPL). Необходимые интерфейсы и требуемые определения Протоколы, описываемые в данной Докладной записке, требуют взаимодействаия услуг со следующим: - Протокол управления транспортом (TCP); - Протокол пользовательских дейтаграмм (UDP). Упорядочение байт, условия адресации (включая адреса, исполь- зуемые для широковещательных и групповых сообщений) определяются последней версией: - Assigned Numbers (Присвоенных номеров). Дополнительные определения и ограничения содержатся в: - Межсетевом протоколе (IP); - Подсетях Internet (internet Subnets). Соответсвующие протоколы и услуги Построение протоколов, описанных в Докладной записке, позволя- ет объединять в будущем следующие протоколы и услуги. Однако, преж- де чем это произойдет, для протоколов, содержащихся в Докладной за- писке, равно как и для нижеприведенных услуг и протоколов могут потребоваться некоторые добавления (расширения): - Услуга "имя домена" (Domain Name Service); - Протокол "Групповое сообщение Internet" (Internet Group Multicast). Масштаб NETBIOS "Масштабом NETBIOS" является группа компьютеров, которым из- вестно зарегистрированное имя NETBIOS. Широковещательные и группо- вые операции с дейтаграммами NETBIOS должны охватывать весь масштаб NETBIOS. Internet может поддерживать множественные, непересекающиеся масштабы NETBIOS. Каждый масштаб NETBIOS имеет "идентификатор масштаба". Этим идентификатором является символьная строка, отвечающая требованиям системы имен доменов к именам доменов. ПРИМЕЧАНИЕ: Каждая разработка NETBIOS на TCP должна обеспечи- вать механизмы для управления используемыми идентификаторами масш- таба. Управление идентификаторами масштаба предполагает наличие до- полнительных возможностей интерфейса NETBIOS, например, расширение интерфейса пользовательских услуг и прочее (скажем, параметры от- ладки узла). Природа подобных расширений не описывается настояшщей спецификацией. Оконечные узлы NETBIOS Стандарт описывает три типа оконечных узлов: - Широковещательные узлы (B-узлы): - Двухточечные узлы (P-узлы); - Узлы смешанного режима (M-узлы). Любой адрес IP (Межсетевого протокола) может быть ассоциирован только с одним экземпляром вышеприведенных типов узлов. Без предварительной загрузки адресно-именных таблиц, перед "участниками" NETBIOS стоит задача динамического распределения вза- имных ссылок. Это может быть осуществлено посредством широковеща- тельного или двухточечного обмена данными. В-узлы используют широковещательные сообщения в локальной сети для обмена данными с одним или более реципиентов (получателей). Уз- лы Р и М используют Спецпроцессор имен NETBIOS (NBNS) и Спецпроцес- сор распределения дейтаграмм NETBIOS (NBDD) для этой же цели. Оконечные узлы могут быть скомбинированы по различным тополо- гиям; в любых топологиях их функции остаются прежними. ПРИМЕЧАНИЕ: Рекомендуется не использовать М и В-узлы в одном и том же масштабе. Масштаб NETBIOS должен содержать либо только узлы В, либо только узлы Р и М. Широковещательные узлы Широковещательные (или В-) узлы осуществляют коммуникацию, ис- пользуя комбинацию дейтаграмм UDP (как широковещательных, так и направленных) и связей TCP. В широковещательной области В-узлы мо- гут свободно взаимодействовать друг с другом. Широковещательной об- ластью является отдельная "В-ЛВС" со связанными мостами носистелями. Двухточечные узлы Двухточечные (или Р-) узлы осуществляют коммуникацию, исполь- зуя только направленные дейтаграммы UDP и сеансы TCP. Р-узлы не вы- полняют ни генерацию, ни "прослушивание" (получение) широковеща- тельных пакетов UDP. Однако, эти узлы предлагают услуги широковеща- тельных и групповых сообщений, используя возможности, предоставляе- мые Спецпроцессором имен NETBIOS и Спецпроцессором распределения дейтаграмм NETBIOS (NBNS и NBDD соответственно). Двухточечные узлы основываются на спецпроцессоре имен и спецп- роцессоре распределения дейтаграмм; эти спецпроцессоры могут быть местными или удаленными, - в любом случае Р-узлы работают одинаково. Узлы смешанного режима Узлы смешанного режима (М-узлы) представляют собой Р-узлы, ко- торые обладают некоторыми характеристиками В-узлов. М-узлы исполь- зуют как широковещательные, так и направленные ("одноцелевые") со- общения. Широковещательные сообщения используются для экономии времени ответа, основываясь на предположении, что большинство ре- сурсов находятся скорее на местном широковещательном носителе, чем где-либо в сети Internet. М-узлы основываются на Спецпроцессоре имен и Спецпроцессоре распределения дейтаграмм (NBNS и NBDD). Однако, если эти спецпро- цессоры временно становятся недоступными, М-узлы могут продолжать работать в ограниченном режиме. Вспомогательные спецпроцессоры Стандарт описывает два типа вспомогательных спецпроцессоров: - узлы Спецпроцессора имен NETBIOS (NBNS); - узлы Спецпроцессора распределения дейтаграмм NETBIOS (NBDD). Узлы NBNS и NBDD невидимы для приклалдных программ NETBIOS и являются частью основного механизма NETBIOS. Эти спецпроцессоры (серверы) являются ядром работы Р- и М-уз- лов с именами и дейтаграммами. Как NBNS, так и NBDD могут передавать часть своей работы око- нечному узлу Р или М, который запрашивает услугу. Вследствие того, что ответственность возлагается динамически, а узлы Р и М должны быть подготовлены к приему управления от спец- процессора NETBIOS, система обычно совершенствует функцию спецпро- цессора NETBIOS. Например,с расширением протокола Групповых сооб- щений Internet (Internet Group Multicasting), новые реализации Спецпроцессора распределения дейтаграмм NETBIOS (NBDD) могут воз- лагать ответственность за распределение дейтаграмм NETBIOS в полном объеме. Взаимодействие различных реализаций обеспечивается наложением ограничений на действие оконечных узлов таким образом, чтобы они могли принимать полный диапазон приемлимых ответов от NBNS и NBDD. Узлы спецпроцессора имен Спецпроцессор имен NETBIOS (NBNS) построен таким образром, чтобы обеспечить достаточную гибкость управления именами NETBIOS. С одной стороны, NBNS может не принимать полной ответственности, ос- тавляя узлам Р и М т.н. "бюллетень", куда информация об именах/ адресах заносится и удаляется свободно, без ее оценки Спецпроцессо- ром имен NETBIOS. С другой стороны, NBNS может взять на себя полную ответственность за управление именами и их оценку. Степень принима- емой Спецпроцессором имен ответственности оценивается NBNS каждый раз, когда предоставляется заявка на имя. Если Спецпроцессор имен NETBIOS (NBNS) не принимает на себя полное управление, он возвраща- ет запрашивающему узлу достваточное количество информации, чтобы любой узел мог бы вызвать (определить) любого предполагаемого владельца имени. Возможность переносить ответственность за управлениен именами между Спецпроцессором имен NETBIOS и узлами Р и М позволяет адми- нистратору сети (или продавцу) достичь разумного компромисса между простотой, надежностью и быстротой действия Спецпроцессора имен NETBIOS (NBNS). Отдельный NBNS может быть реализован как распределенный об- ъект, например, Услуга "имя домена" (Domain Name Service). Обнако, внутренняя структура обменов данных не определяется Докладной за- пиской. Топологии Узлы В, Р, М, а также узлы NBNS и NBDD могуть быть скомпонова- ны различными путями. Имеется три класса операций: - Класс 0: только В-узлы; - Класс 1: только Р-узлы; - Класс 2: Р-узлы и М-узлы вместе. На рисунках, приводимых ниже, любой Р-узел может быть заменен любым М-узлом. Последствия подобной замены будут объясняться вместе с каждым приводимым примером. Местный масштаб --------------- Масштаб NETBIOS является местным: все объекты находятся внутри одной и той же широковещательной области. В-узлы Местные операции только с В-узлами являются наиболее распост- раненными. Процедуры обнаружения и регистрации имен используют механизмы широковещательных сообщений. Масштаб NETBIOS ограничен размерами широковещательной области. Эта конфигурация, показанная на рис. 7-1, не требует наличия вспомогательных спецпроцессоров NETBIOS. ----------------- Широковещательная область ----------------------- ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ----- ----- ----- ----- ----- ! В ! ! В ! ! В ! ! В ! ! В ! ----- ----- ----- ----- ----- Рис. 7-1. В-узлы. Р-узлы Данная конфигурация обычно используется, когда администратор сети хочет исключить широковещательные операции. Данная конфигура- ция, как это показано на рис. 7-2, работает также, как если бы она была в Internet. Здесь она приводится только для того, чтобы пока- зать ее удобство как средства ограничения использования широковеща- тельных соощений. Замена одного или более Р-узлов М-узлами не повлияет на работу ни Р-, ни М-узлов. Р- и М-узлы смогут взаимодействовать друг с другом. Вследствие того, что М-узлы используют широковещательные сообщения, общий объем широковещательных операций возрастет. ----------------- Широковещательная область ----------------------- ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ----- ----- ----- ----- ----- ----- ! Р ! ! Р ! !NB NS! ! Р ! !NB DD! ! Р ! ----- ----- ----- ----- ----- ----- Рис. 7-2. Р-узлы. ПРИМЕЧАНИЕ: NBNS - Спецпроцессор имен NETBIOS. NBDD - Спецпроцессор распределения дейтаграмм NETBIOS. Комбинация В- и Р-узлов Узлы Р- и В- не взаимодействут друг с другом. Замена Р-узлов М-узлами позволит узлам В и М взаимодействовать друг с другом. Internet -------- Р-узлы Р-узлы могут быть разбросаны по разным местам в Internet, как показано на рис. 7-3. Для поддержки имен и дейтаграмм NETBIOS им требуется NBNS и NBDD, соотвественно. Масштаб NETBIOS определяется идентификатором масштаба NETBIOS (имя домена), используемого различными Р- (и М-) узлами. Internet может содержать многочисленные масштабы NETBIOS. Любой узел Р может быть заменен любым узлом М, причем функции обоих типов узлов сохраняются. Однако, в случае замены на М-узел увеличится объем широковещательных операций в той широковещательной области, к которой этот узел относится. ----- ! P ! ----- ! ! ! ----- ! !-----! Р ! ! ! ----- ! ! ----- !----------! -------- ! ----- ! P ! --------! Internet !-----! ШЛЮЗ !---------! Р ! ----- !----------! -------- ! ----- ! ! ! ! ! ! ----- ! ! !-----! Р ! ! ! ! ----- ! ! ! ! --------- ! ! NB DD ! --------- --------- ! NB NS ! --------- Рис. 7-3. Р-узлы Internet. Комбинация М- и Р-узлов Как показано на рис. 7-4, узлы Р и М могут использоваться в сочетании друг с другом. При обнаружении местонахождения имен NETBIOS, М-узлы будут стремиться найти скорее те имена, которые относятся к другим М-узлам в общей широковещательной области, чем имена Р- или М-узлов где-либо еще в сети. ПРИМЕЧАНИЕ: В среде Internet комбинировать узлы В и М не сле- дует, иначе могут возникнуть непредсказуемые конфликтные ситуации с именами NETBIOS. ----- ! P ! ----- ! ! ! ! ----- !----------! -------- ! P ! --------! Internet !-----! NBDD ! ----- !----------! -------- ! ! ! ! ! ! ! ! ! ! ! --------- ! ! ШЛЮЗ ! --------- --------- ! NB NS ! ! --------- ! ! ! ! -----------------!Широковещательная область ----------------------- ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ----- ----- ----- ----- ----- ----- ! М ! ! Р ! ! М ! ! Р ! ! М ! ! Р ! ----- ----- ----- ----- ----- ----- Рис. 7-4. Р-узлы и М-узлы Internet. Общие способы взаимодействия Ниже приводятся некоторые общие способы взаимодействия между объектами. ВЗАИМОДЕЙСТВИЕ ЗАПРОС/ОТВЕТ Большинство типов взаимодействия составляет взаимодействие между запросом, движущемся в одном направлении, и последующим отве- том, движущимся в другом направлении. В тех ситуациях, когда взаимодействие происходит в ненадежном транспорте (т.е. UDP - Протокол пользовательских дейтаграмм), или когда запрос является широковещательным, жесткой взаимосвязи или отношения один к одному между запросом и ответом может и не быть. В любом случае, это более, чем один ответ, вырабатываемый на полученный запрос. В то время, когда ответ ожидает, отвечающий об- ъект может посылать одно или более подтверждение приема с ожиданием. ПОВТОРНАЯ ПЕРЕДАЧА ЗАПРОСОВ Протокол пользовательских дейтаграмм (UDP) является ненадежным механизмом отправки сообщений, где пакеты могут быть утеряны, полу- чены не в последовательности их передачи, дублированы, кроме того, отправка может происходить со значительной задержкой. Вследствие того, что протоколы NETBIOS интенсивно используют UDP, они компен- сируют недостаток надежности UDP дополнительными механизмами. Каждый пакет NETBIOS содержит всю необходимую информацию для его обраотки. Ни один из протоколов не использует несколько паке- тов UDP для передачи одиночного запроса или ответа. Если требуется больше исформации, чем может поместиться в один пакет UDP, напри- мер, когда узел типа "Р" хочет получить от спецпроцессора NETBIOS всех владельцев группового имени, используется связь TCP (Протокол управления транспортом). Следовательно, в протоколах не произойдет сбой из-за нарушения последовательности отправки пакетов UDP. Для того, чтобы исключить потерю пакета ответа или пакета зап- роса, каждая операция запроса повторно передаст запрос, если ответ не будет получен в течение определенного промежутка времени. Операции с протоколами, чуствительные к успешной передаче па- кетов ответов, например, операции обнаружения конфликтов с именами, защищены от дублирования пакетов вследствие того, что они игнори- руют последовательные пакеты с одной и той же информацией NETBIOS. Так как никакое состояние в отвечающем узле не ассоциируется с зап- росом, ответчик просто посылает подходящий ответ, когда бы не при- был пакет с запросом. Следовательно, дублирующиеся или задержанные пакеты запросов игнорируются. Для всех запросов, если пакет ответа задерживается слишком долго, то посылается другой пакет запроса. Второй пакет ответа, посылаемый "в ответ" на второй пакет запроса, эквивалентен дублиру- ющемуся пакету. Следовательно, протоколы проигнорируют второй полу- ченный пакет. Если отправка ответа задерживается до завершения опе- рации запроса (успешной или нет), пакет ответа будет проигнорирован. ЗАПРОСЫ БЕЗ ОТВЕТОВ Некоторые типы запросов не имеют соответствующих ответов. Эти запросы называются "требованиями". В целом, требование представляет собой запрос-приказание (императивный запрос), которому получающий узел должен подчиниться. Однако, вследствие того, что требования не подтверждаются, они применяются только в тех ситуациях, когда при утере пакета требования произошло бы ограниченное повреждение. Пакеты требований не передаются повторно. ТРАНЗАКЦИИ Взаимодействия между парой объектов группируются в "транзак- ции". Эти транзакции объединяют одну или более пару типа "зап- рос/ответ". Идентификатор транзакции Вследствие того, что между парой объектов может происходить несколько одновременных транзакций, используется "идентификатор транзакции". Инициатор транзакции выбирает идентификатор, уникальный для данного инициатора. Идентификатор транзакции перемещается вперед и назад при каждом взаимодействии внутри данной транзакции. Партнеры по транзакции должны устанавливать соответствие ответов и запросов, сравнивая идентификатор транзакции и адрес IP (IP - Межсетевой про- токол) партнера по транзакции. Если соответствующий запрос не нахо- дится, ответ должен быть сброшен. Для каждой транзакции используется новый идентификатор. Гене- ратором идентификатора транзакции должен быть простой 16-битовый счетчик транзакций. Необходимости искать и отфильтровывать дублирующийся идентификатор транзакции нет: вероятность сущест- вования такой транзакции, чей "срок жизни" превышал бы небольшую долю обычного циклического периода счетчика, чрезвычайна мала. При- менение адресов IP вместе с идентификатором транзакции значитель- но сокращает вероятность сбоев, в том случае, если идентификатор транзакции был бы использован повторно. Основания для TCP и UDP Данная версия NETBIOS на основе протоколов TCP (Протокол уп- равления транспортом) использует UDP (Протокол пользховательских дейтаграмм) для многих видов взаимодействий. В будущем, такие взаимодейс твия могут происходить на основе связей TCP (для увеличения эффективности, если несколько взаимодействий происходят в течение короткого отрезка времени, или если трафик дейтаграмм NETBIOS обнаружит,что прикладная програма использует дейтаграммы NETBIOS для поддержки услуги, ориентированной на связь). Услуга сеанса NETBIOS Услуга сеанса NETBIOS начинается после того, как для требуемо- го имени было найдено один или более адресов IP (IP - Межсептевой протокол). Эти адреса могли быть получены с использованием транзак- ций запроса имени NETBIOS или же других средств, например, таблица местных имен или кэш (сверхоперативная память). Транзакции, пакеты и протоколы услуги сеанса NETBIOS одинаковы для оконечных узлов всех типов. Они включают только направленный (двухточетный) обмен данными. Услуга сеанса имеет три фазы: УСТАНОВЛЕНИЕ СЕАНСА. Во время этой фазы определяется адрес IP и порт TCP вызываемого имени, а с удаленным партнером устанавлива- ется связь TCP. СТАБИЛЬНОЕ СОСТОЯНИЕ. Во время этой фазы происходит обмен со- общениями данных в сеансе. Может происходить обмен "живыми" (keep-alive) пакетами, если участвующие в таком обмене узлы конфи- гурированы (отлажены) подобным образом. ЗАКРЫТИЕ СЕАНСА. Сеанс закрывается: это происходит тогда, ког- да одна из сторон (в сеансе) закрывает его, либо когда один из пар- тнеров прекратил работу. Услуга дейтаграммы NETBIOS Каждая дейтаграмма NETBIOS имеет поименованный источник и назначение. Для передачи дейтаграммы NETBIOS, услуга дейтаграммы должна выполнить операцию запроса имени для того, чтобы узнать ад- рес IP и атрибуты имени назначения NETBIOS. (Эта информация может храниться в кэш, чтобы избежать излишних расходов при запросах имен для последующих дейтаграмм NETBIOS). Дейтаграммы NETBIOS передаются в пакетах UDP. Если размер дейтаграммы NETBIOS превосходит размер отдельного пакета UDP, она может быть разбита на несколько пакетов UDP. Оконечные узлы могут получать дейтаграммы NETBIOS, адресован- ные именам, владельцем которых получающий узел не является. Подоб- ные дейтаграммы должны сбрасываться. Если это имя уникально, то ис- точнику дейтаграммы NETBIOS посылается пакет DATAGRAM ERROR (ОШИБКА ДЕЙТАГРАММЫ). Разбивка дейтаграмм Если заголовок и данные дейтаграммы NETBIOS превышают макси- мальное количество данных для одного пакета UDP, дейтаграмма NETBIOS перед передачей должна быть разбита (расчленена). Дейтаграмма NETBIOS состоит из следующих элементов протокола: - Заголовок IP размером 20 байт (минимум); - Заголовок UDP размером 8 байт; - Заголовок дейтаграммы NETBIOS размером 14 байт; - Данные дейтаграммы NETBIOS. Последний элемент состоит из трех частей: - Имя источника NETBIOS (255 байт максимум); - Имя назначения NETBIOS (255 байт максимум); - Пользовательские данные NETBIOS (512 байт максимум); - Два поля имени находятся в закодированном формате второго уровня. Максимальный размер дейтаграммы NETBIOS - 1064 байт. Минималь- ный размер максимальной дейтаграммы IP - 576 байт. Следовательно, дейтаграмма NETBIOS может не поместиться в одну дейтаграмму IP, - тогда ее необходимо разбить. В сетях, отвечающих требованиям или превышающих требования минимальной длины дейтаграммы IP в 576 байт, дейтаграмма NETBIOS будет разбита на две. Протоколы и форматы пакетов предусматривают разбивку на три и более частей. Параметры конфигурации узла - В-УЗЛЫ: - Уникальное постоянное имя узла. - Используется ли Протокол групповых сообщений Internet (IGMP). - Используемый широковещательный адрес IP. - Необходимы ли "живые" (keep-alive) пакеты для сеанса NETBIOS. - Используемая длина поля данных UDP (для управления разбивкой). - Р-УЗЛЫ: - Уникальное постоянное имя узла. - Адрес IP Cпецпроцессора имен NETBIOS. - Адрес IP (IP - Межсетевой протокол) Спецпроцессора распреде- ления дейтаграмм NETBIOS. - Необходимы ли "живые" (keep-alive) пакеты для сеанса NETBIOS. - Используемая длина поля данных UDP (для управления разбивкой). - М-УЗЛЫ: - Уникальное постоянное имя узла. - Адрес IP Cпецпроцессора имен NETBIOS. - Адрес IP (IP - Межсетевой протокол) Спецпроцессора распреде- ления дейтаграмм NETBIOS. - Необходимы ли "живые" (keep-alive) пакеты для сеанса NETBIOS. - Используемая длина поля данных UDP (для управления разбивкой). - Используется ли IGMP. - Используемый широковещательный адрес IP. Минимальное соответствие Для того, чтобы обеспечить взаимное соответствие разработок между фирмами-продавцами, реализация на основе настоящей специфика- ции должна удовлетворять следующим правилам: А. Узел, предназначенный для работы только в широковещательной области, должен отвечать характеристикам В-узла. Б. Узел, предназначенный для работы только в Internet, должен отвечать характеристикам Р-узла. МЕЖДУНАРОДНАЯ ОРГАНИЗАЦИЯ ПО СТАНДАРТИЗАЦИИ (ISO) ------------------------------------------------- Следующая информация, касающаяся NETBIOS для Сетей Международ- ной организации по стандартизации (ISO Networks), была написана Стивеном Томасом из корпорации CMC (Соmmunication Machinery Corp.) (США). Первоначально она была напечатана в журнале "Computer Communication Review" (июль/август 1987г.). Введение Набор протоколов, определенный ISO, обещает обеспечить универ- сальное взаимодействие. Сетевые продукты различных фирм-продавцов смогут взаимодействовать друг с другом, а пользователи - компоно- вать различное оборудование для более полного удовлетворения своих потребностей. К сожалению, набор протоколов ISO еще не создан, и пользователи еще не могут использовать все необходимые им сегодня прикладные программы ISO. В мире персональных компьтеров IBM, большинство сетевых прик- ладных программ используют интерфейс фирмы IBM - "NETBIOS", и, пока эти прикладные программы не будут заменены прикладными программами, отвечающими стандартам ISO, пользователям будут по-прежнему необ- ходимы сети, совместимые с NETBIOS. К счастью, интерфейс NETBIOS может быть добавлен к сетевым продуктам ISO. Когда продукт ISO включит в себя совместимый с NETBIOS интерфейс, пользователи смогут работать как с прикладными программами ISO, так и стандартными прикладными программами для ПЭВМ в одной и той же сети. Корпорация CMC включила совместимый с NETBIOS интерфейс в свой продукт "Протокол технического бюро" (Technical Office Protocol - сокращенно TOP) для ПЭВМ IBM, и, вследствие популярности интерфейса NETBIOS,некоторые другие фирмы-продавцы также будут предлагать ин- терфейсы NETBIOS для своих продуктов ISO. Простейший способом добавления совместимости с NERTBIOS в этот набор протоколов - определить "протокол NETBIOS" на самом вер- хнем уровне данного набора. Этот подход был использован группой фирм-продавцов, стандартизирующих NETBIOS в сетях TCP/IP. Они опре- делили новый протокол, который находится над TCP в их сетевых про- дуктах. Недостатком этого метода является то, что новый протокол дол- жен использоваться обеими оконечными точками в связи. ПЭВМ с таким протоколом NETBIOS может обмениваться данными с системой UNIX, нап- ример, только если система UNIX работает со специальной программой, которая поддерживает протокол NETBIOS, а использование этой специ- альной управляющей программы может помешать нормальной работе сете- вых прикладных программ UNIX. Корпорация CMC устранила эту проблему в своих продуктах ISO посредством определения интерфейса NETBIOS для ISO, который служит только как интерфейс. Фирма CMC достигла совместимости с NETBIOS без добавления нового протокола, а NETBIOS фирмы CMC стал прозрач- ным интерфейсом для нормальных протоколов ISO. Даже стандвартные прикладные программы ISO осуществляют обмен данными с аппаратным робеспечением CMC через интерфейс NETBIOS. ПЭВМ, оснащенные NETBIOS, осуществляют коммуникацию с UNIX, VMS и другими системами, которые даже не осознают, что они "разговаривают" с ПЭВМ. Открывая сведения о своей реализамции NETBIOS, корпорация CMC надеется убедить других продавцов принять тот же подход в решении проблемы добавления совместимости с NETBIOS к их сетевым продуктам ISO. Подобная стандартизация позволит продуктам NETBIOS-ISO, пред- лагаемым многими фирмами, осуществлять взаимное общение, - от этого выиграют не только фирмы, но и, что более важно, пользователи сетей. NETBIOS как интерфейс транспортного уровня Если NETBIOS служит в качестве прозрачного интерфейса для набора протоколов ISO, он дожен, конечно, взаимодействовать с одним или более протоколами. Вследствие того, что спецификация NETBIOS обеспечивает надежную отправку данных по логическим связям, он, ве- роятнее всего, должен взаимодействовать с транспортным уровнем ISO. На рис. 7-5 показано место интерфейса NETBIOS в модели Соедине- ния открытых систем (OSI). ---------------------------------------------- !Прикладной уровень ISO ! ! !------------------------ Прикладные ! !Уровень представл.ISO ! программы ! !------------------------ PC-DOS, не ! !Сеансовый уровень ISO ! являющиеся ISO ! Интерфейс __________>!--------------------------------------------! NETBIOS >!--------------------------------------------! ! Транспортный уровень ISO ! !--------------------------------------------! ! Сетевой уровень ISO ! !--------------------------------------------! ! Канальный уровень ISO ! !--------------------------------------------! ! Физический уровень ISO ! !--------------------------------------------! Рис. 7-5. Интерфейс NETBIOS и Модель Соединения открытых систем (OSI). Для NETBIOS требуются четыре различных типа сетевых услуг: об- щие услуги, услуги имени, услуги сеанса, услуги дейтаграмм. Первые два типа услуг, услуги имен и общие услуги, не соответ- ствуют ни одному протоколу ISO, так что выбор уровня протокола це- ликом зависит только от последних двух видов услуг. Вследствие то- го, что сеансы NETBIOS должны быть надежными, NETBIOS должен взаи- модействовать с транспортным уровнем или более высоким уровнем. Но NETBIOS не обеспечивает интерфейс с услугами более высоких уровней, например, синхронизацией, управлением активностью, управ- лением маркером.Если бы NETBIOS был выбран как интерфейс для уровня протоколов, находящегося выше транспортного уровня, он бы только смог обеспечить взаимодействие с небольшим подмножеством услуг уровня. Таким образом, оптимальным уровнем для интерфейса NETBIOS является транспортный. Выбор транспортного уровня противоречит терминологии "Техни- ческого руководства IBM по Сети ПЭВМ", где NETBIOS описан как ин- терфейс сеансового уровня. Это противоречие возникает вследствие того, что протокол сеансового уровня, с которым взаимодействует NETBIOS фирмы IBM, не является сеансовым протоколом ISO. В дейст- вительности, сеансовый уровень IBM не удовлетворяет общим критериям для сеансового уровня, установленным моделью Соединения открытых систем (OSI). Внутри транспортного уровня, Класс 4 транспортного протокола (TP4) с установлением логического соединения наилучшим образом под- держивает сеансы NETBIOS. Так как сеансы NETBIOS должны быть надеж- ными, а сам NETBIOS, будучи интерфейсом, не может осуществлять об- наружение ошибок и восстановление, NETBIOS потребует услуги обнару- жения ошибок и восстановления, которые обеспечивает TP4. Имена NETBIOS Имена NETBIOS определяют компьтер, на котором они находятся, а, так как одна машина может иметь несколько имен, они также опре- деляют "точку доступа с сервису NETBIOS" в этой ЭВМ. Если NETBIOS взаимодействует с транспортным уровнем ISO, то, по определению, имена NETBIOS должны соответствовать адресам ISO на транспортном уровне. Каждое имя NETBIOS, следовательно, соответствует уникальной паре: Точка доступа к сетевой услуге (NSAP) и Точка доступа к транспортной услуге (TSAP). Интерфейс NETBIOS осуществляет трансля- цию между именами и парами NSAP-TSAP до того, как послать команды NETBIOS транспортному протоколу ISO. Протокол услуги местного каталога фирмы CMC, Протокол динами- ческого поименования (DNP) фактически выполняет трансляцию. Этот протокол обеспечивает услуги имени для всех протоколов ISO фирмы CMC, а не только для интерфейса NETBIOS. Когда пользователь NETBIOS выдает команду ADD NAME или ADD GROUP NAME, интерфейс NETBIOS формулирует TSAP для имени и просит Протокол динамического поименования (DNP) зарегистрировать опреде- ленное имя с этим TSAP. Так как NETBIOS стыкуется с транспортным уровнем, имя NETBIOS не имеет точки доступа к услуге сеансового уровня (SSAP) или уровня представления данных (PSAP). Когда пользователь выдает команду DELETE NAME, интерфейс NETBIOS проверяет, имеет ли определенное имя "активные" сеансы. Ес- ли нет, интерфейс NETBIOS немедленно стирает это имя и просит Про- токол динамического поименования (DNP) "вычеркнуть" это имя. Если это имя имеет активные сеансы, интерфейс NETBIOS просто помечает его соответствующим образом. Только после закрытия всех сеансов, интерфейс NETBIOS просит DNP "вычеркнуть" это имя. Пользователи NETBIOS могут по желаню использовать постоянные имена узлов вместо сетевых имен. Постоянное имя узла состоит из 10 байт нулей, за которыми следует 6 байт, обозначающие имя узла ЭВМ. NETBIOS ISO фирмы CMC принимает шесть ненулевых байт, становясь Подсетевой точкой подключения (SNPA - Sub-network point of attachment) для компьтера, и выстраивает Точку доступа к сетевой услуге (NSAP) из этой SNPA. Для остальных NSAP постоянного имени узла, интерфейс просто копирует из своей собственной Подсетевой точки подключения (SNPA). Все постоянные имена узлов для данной ЛВС будут, следовательно, иметь одинаковые Идентификаторы полномочия и формата (AFI - Authority and Format Identifiers), одинаковые Сетевые идентификато- ры (NIP - Network Identifiers), одинаковые Первичные подсетевые идентификаторы (PSI - Primary Subnetwork Identifiers), суффиксы Точки доступа к канальной услуге (LSAP) - "LSS" и суффиксы Точки доступа к сетевой услуге (NSAP) - "NSS". Интерфейс NETBIOS также использует особую, обозначенную Точку доступа к транспортной услуге (TSAP) для постоянных име узлов. Эта TSAP равна 2 байт, с шестнадцатиричной величиной FE. На рис. 7-6 показан пример трансляции между постоянным именем узла и адресом NSAP-TSAP. (Заметьте, что интерфейс NETBIOS распознает и транслиру- ет постоянные имена узлов; Протокол динамического поименования (DNP) фирмы CMC не имеет представления о постоянных именах узлов). Если местная NSAP есть: 49 01 00 00 00 00 01 y1 y2 y3 y4 y5 y6 FE 00 постоянное имя узла: 00 00 00 00 00 00 00 00 00 00 x1 x2 x3 x4 x5 x6 преобразуется в: NSAP - 49 01 00 00 00 00 01 x1 x22 x3 x4 x5 x6 FE 00 TSAP - FE FE Рис. 7-6. Имя узла в преобразовании NSAP. Сеансовые услуги NETBIOS Интерфейс NETBIOS прозрачно отображает сеансы в связях TP4. Каждый сеанс имеет свою собственную связь, а интерфейс посылает данные для сеанса непосредственно его связи. Когда пользователь NETBIOS просит интерфейс NETBIOS установить сеанс, пользователь обычно обращается к оконечным точкам данного сеанса с именами NETBIOS. Интерфейс должен, конечно, транслировать эти имена в адреса сети (Точки NSAP и Точки TSAP) перед тем, как он сможет установить транспортную связь. Протокол динамического поиме- нования (DNP) фирмы CMC выполняет эту трансляцию. Если интерфейс установил транспортную связь, прикладная прог- рамма может передавать данные по этой связи, выдавая команды SEND, CHAIN SEND, RECEIVE и RECEIVE ANY. В целом, эти команды просто по- сылают и получают данные в связи TP4; однако небольшие различия между передачей данных NETBIOS и передачей данных TP4 существуют. Наиболее очевидное из них заключается в том, что NETBIOS не поддерживает конценпцию TP4 "срочных данных". Следовательно, прик- ладные программы, ограниченные стандартным интерфейсом NETBIOS, не в состоянии посылать TP4 срочные данные. Для прикладных программ, которые требуют применения срочных данных, фирма CMC разработала расширения к NETBIOS. О них рассказывается в последующем разделе. Второе различие между TP4 и NETBIOS состоит в небольших откло- нениях от интерфейса NETBIOS, определенного в "Техническом руковод- стве по Сети ПЭВМ". Отправка данных, обеспечиваемая транспортным уровнем ISO, является неподтвержденной услугой. Когда пользователь TP4 посылает данные, он может посчитать посылаемые данные, но TP4 не показывает, когда полученные данные фактически отправляются к удаленному пользователю. Как следствие этого, пользователь-отправи- тель должен доверять TP4 в отправке данных. Интерфейс NETBIOS, однако, определяет, что команда SEND (или SEND CHAIN) не может быть завершена, пока удаленный пользователь действительно не получит данные. Вследствие того, что интерфейс NETBIOS фирмы CMC использует только услуги, которые обычно доступны из TP4, он возвращает завершенные команды SEND, когда TP4 показыва- ет, что команды завершены. TP4 может просигнализировать о заверше- нии команд до того, как удаленный пользователь фактически получит данные, то есть команда SEND может завершиться до того, как завер- шится команда удаленного пользователя RECEIVE. Такое поведение нем- ного отличается от спецификации NETBIOS, но, кроме как в чрезвычай- ных обстоятельствах, прикладные программы не замечают эту разницу. Услуги дейтаграмм NETBIOS Этот вид услуг является наиболее сложным для реализации в сети ISO. Дейтаграммы NETBIOS, подобно услугам дейтаграмм для других на- боров протоколов, предназначены для применения в качестве простого, быстрого и эффективного метода передачи данных. Дейтаграммы NETBIOS, однако, используют сетевые имена, а услуги имен редко ког- да бывают быстры, просты или эффективны. Из-за этой базовой несовместимости, все попытки реализовать дейтаграммы NETBIOS в пределах ISO оканчивались компромиссами. Фир- ма CMC выбрала, вероятно, оптимальный из компромиссов. О нем и бу- дет рассказано ниже, как, впрочем, и о других возможных решениях этой проблемы. Одно из незамысловатых решений заключается в том, чтобы дей- таграммы NETBIOS использовали бы транспортный протокол без установ- ления логической связи ISO так же, как сеансы NETBIOS используют TP4. Когда пользователь посылает дейтаграмму, интерфейс NETBIOS запрашивает, чтобы услуги имени преобразовали имя назначения в точ- ку NSAP и TSAP (точка доступа к сетевой и транспортной услуге,соот- ветственно); затем интерфейс посылает дейтаграмму этой NSAP-TSAP. Когда узел назначения получает дейтаграмму, он просит услуги имени преобразовать исходные NSAP и TSAP в сетевое имя отправителя. Затем интерфейс отправляет дейтаграмму удаленному пользователю. Этот способ имеет два серьезных минуса, и, следовательно, ин- терфейс NETBIOS фирмы CMC не может применить его. Первый минус - неэффективность данного метода: он требует осуществления пяти сете- вых транзакций для отправки одной дейтаграммы (этими транзакциями являются: запрос на обнаружение имени, ответ об обнаружении имени, дейтаграмма, запрос на решение адреса, ответ о решении адреса). Данный метод, кроме того, недостаточно эффективно обрабатывает групповые имена, - это его второй недостаток. Когда прикладная программа направляет дейтаграмму групповому имени, этот способ пот- ребует того, чтобы был идентифицирован каждый узел в групповом име- ни для того, чтобы дейтаграмма могла быть скопирована и отправлена каждому из этих узлов. В качестве альтернативы, интерфейс NETBIOS может отправлять как широковещательное сообщение любую дейтаграмму и включать в дей- таграмму имена источника и назначения. Этот подход значительно уве- личивает производительность по сравнению с первым способом: услуги имен не требуются, и, следовательно, каждой дейтаграмме будет соот- ветствовать только одна сетевая транзакция. На первый взгляд может показаться, что это преимущество изче- зает, если все узлы в сети получают дейтаграмму. Но более детальное обследование показывает, что это предположение неверно. Первый ме- тод также требует, чтобы все узлы обрабатывали одну сетевую тран- закцию на дейтаграмму. Вместо самой дейтаграммы каждый узел должен обработать запрос на обнаружение имени. Фирма CMC использует этот второй способ в своем интерфейсе NETBIOS. Интерфейс помещает прикладную дейтаграмму, вместе с именем источника и назначения и типом дейтаграммы, в Блоки данных сервиса (услуги) (Service Data Unit, сокращенно SDU) транспортного протоко- ла ISO без установления логического соединения (CLTP), DIS 8602. На рис.7-7 показан формат Блока данных услуги транпортного уровня (TSDU) Транспортного протокола CLTP. 0 1 2 3 4 5 6 7 ----------------------------- ! ! 0 - обычная, 1 байт ! Тип дейтаграммы ! 1- широковещательная !---------------------------! . . 16 байт . Имя источника . !---------------------------! . . 16 байт . Имя назначения . !---------------------------! до . . 512 байт .Данные пользователя NETBIOS. ----------------------------- Рис. 7-7. Блок данных транспортной услуги протокола CLTP дейтаграммы NETBIOS. Для транслирования этих дейтаграмм, фирма CMC применяет Точку назначения NSAP, которая содержит широковещательный адрес уровня MAC (Управления доступом к носителям) в качестве подсетевой точки подсоединения (SNPA). Все другие поля Точки доступа к сетевой услу- ге (NSAP) - AFI, NID, PSI, LSS и NSS - копируются из местной NSAP адаптера. Образец NSAP, которую могут использовать услуги дейтаг- рамм NETBIOS, будет выглядеть как (в шестнадцатиричной системе): 49 01 00 00 00 00 01 FF FF FF FF FF FF FE 00 Все дейтаграммы NETBIOS также используют простую, хорошо из- вестную Точку доступа к транспортной услуге TSAP как для источника, так и для назначения. Эта TSAP состоит из 2 байт: первый байт имеет величину ноль, а второй - величину 81 (в шестнадцатиричнрой системе счисления). Этот метод имеет один серьезный минус - недостаток прозрачнос- ти. Включая имена источника и назначения в Блок данных услуги тран- спортного протокола без установления логического соединения, версия фирмы CMC требует, чтобы узел нзначения поддеорживал интерфейс NETBIOS. К счастью, NETBIOS поддерживают только те узлы, которые получают дейтаграммы. Интерфейс NETBIOS направляет все дейтаграммы в определоенную TSAP, так что только те протоколы, которые "ожидают" дейтаграмм в этой Точке доступа к транспортной услуге (TSAP), будут получать дейтаграммы NETBIOS. Расширения ISO версии NETBIOS Вследствие того, что интерфейс NETBIOS не был специально соз- дан для протоколов ISO, он не обеспечивает оптимальное взаимодейст- вие с этими протоколами. Фирмой CMC это несоответствие было умень- шено как результат выбора транспортного уровня для стыка; тем не менее, некоторые свойства протоколов ISO не могут быть поддержаны стандартной версией NETBIOS. В частности, прикладные программы не имеют прямого доступа к точкам NSAP и TSAP для адресации; они не могут посылать срочные данные и не могут явно показывать конец текста в сообщении. Чтобы поддержать эти свойства, корпорация CMC расширила стандартную вер- сию интерфейса NETBIOS с помощью своих продуктов TOP-NETBIOS. Для получения доступа к этим расширениям ISO, прикладные прог- раммы помещают специальную "подпись" в Блок управления сетью (NCB) NETBIOS. Эта подпись помещается в первые четыре байта поля CALLNAME Блока управления сетю (NCB). Она состоит из байта с двоичной вели- чиной ноль, за которым следуют три байта с величинами (в коде ASCII): для заглавной "I, заглавная "S" и заглавная "O". Так как стандартная версия NETBIOS не позволяет именам начинаться с двоич- ной величины ноль, прикладные программы, не являющиеся ISO, не бу- дут использовать имя, начинающееся с подписи ISO, а прикладная программа, не являющаяся ISO, не может запросить эти расширения ISO. Более того, если прикладная программа ISO попытается исполь- зовать расширение ISO в NETBIOS, не являющемся ISO, сетевой адаптер (в большинстве случаев) просто "отвергнет" Блок управления сетью (NCB), как имеющий неверное имя. Этот метод гарантирует, что только прикладные программы ISO используют расширение ISO; кроме того, ес- ли прикладная программа по ошибке попытается использовать сеть, не являющуюся ISO, то не будет причинено никакого вреда. Первое расширение ISO позволяет прикладным программам опреде- лять Точку доступа к транспортной услуге (TSAP), когда они регист- рируют имя. Обычно, интерфейс NETBIOS выбирает для них TSAP. Для того, чтобы определить TSAP, прикладная программа помещает подпись ISO в байтах от нуля до трех в поле CALLNAME Блока управления сетью (NCB) по команде NCB "ADD NAME". Она также помещает указатель на определенную TSAP в байтах с четырех до семи в поле CALLNAME Блока управления сетью (NCB). Этот указатель, как и все в NETBIOS, состоит из смещения и сегмента. Четвертый байт содержит наименее значимый байт смещения, пятый байт наиболее важен, байт шесть содержит наименее значитель- ный байт сегмента и седьмой байт содержит наиболее значимый байт. Указатель указывает на структуру Точки доступа к транспортной услу- ге (TSAP), первый байт которой содержит длину TSAP. Байты, которые фактически составляют TSAP, следуют за индикатором длины. По тради- ции ISO индикатор длины не включается в подсчет. Остальная часть Блока управления сетью (NCB), включая само имя, дублирует стандарт- ную команду NETBIOS "ADD NAME". На рис.7-8 показан образец расши- ренной версии ISO команды "ADD NAME". --------------------- NCB_COMMAND ! 0x30 или 0xВ0 ! !-------------------! NCB_RETCODE ! ! !-------------------! NCB_LSN ! ! !-------------------! NCB_NUM ! ! !-------------------! NCB_BUFFER@ ! ! !-------------------! NCB_LENGTH ! ! !-------------------! ! \0ISO ! -------- Длина NCB_CALLNAME ! парам. TSAP---------! ! 2 ! TSAP ! ! ! !----- ! !-------------------! !---->!Байт 1! Величина ! Имя ! !------! TSAP NCB_NAME !-------------------! !Байт 2! ! ! ! ! NCB_RTO !-------------------! -------- ! ! NCB_STO !-------------------! ! необязательно ! NCB_POST@ !-------------------! ! 0 ! NCB_LANA_NUM !-------------------! ! ! NCB_CMD_CPLT --------------------- Рис. 7-8. Расширенная версия ISO команды ADD NAME. Второе расширение ISO позволяет прикладным программам вызы- вать друг друга путем непосредственного определения удаленных NSAP и TSAP. Обычно, естественно, NETBIOS ожидает, чтобы прикладные программыв определили удаленное имя; затем он использует Протокол динамического поименования для обнаружения имени этого адреса. Для того, чтобы непосредственно (напрямую) использовать Точки NSAP и TSAP, прикладная программа снова помещает подпись ISO в поле CALLNAME Блока NCB. Следом за этой подписью она помещает указатель на ту NSAP, которую она вызывает, а затем указатель на TSAP, кото- рую она вызывает. Оба этих указателя также определяются смещениями и сегмента- ми. Указатель NSAP занимает байты с четвертого по седьмой в поле NCB_CALLNAME, а указатель TSAP - байты с восьмого по одиннадцатый. Каждый указатель указывает на индикатор длины, а сами байты NSAP и TSAP немедленно следуют за указателем длины. На рис. 7-9 показан образец расширенной версии ISO команды CALL. --------------------- NCB_COMMAND ! 0x10 или 0x90 ! !-------------------! NCB_RETCODE ! ! !-------------------! NCB_LSN ! ! !-------------------! -------- Длина NCB_NUM ! ! ! 15 ! NSAP !-------------------! ---->!------! NCB_BUFFER@ ! ! ! !Байт 1! Величина !-------------------! ! !------! NSAP NCB_LENGTH ! ! ! !Байт 2! !-------------------! ! -------- ! \0ISO ! ! -------- Длина NCB_CALLNAME ! парам. NSAP--------- ! 2 ! TSAP ! парам. TSAP--------- !----- ! !-------------------! !---->!Байт 1! Величина ! lclname ! !------! TSAP NCB_NAME !-------------------! !Байт 2! ! тайм-аут ! ! ! NCB_RTO !-------------------! -------- ! тайм-аут ! NCB_STO !-------------------! ! необязательно ! NCB_POST@ !-------------------! ! 0 ! NCB_LANA_NUM !-------------------! ! ! NCB_CMD_CPLT --------------------- Рис. 7-9. Расширенная версия ISO команды CALL. Третье расширение ISO обеспечивает прикладные программы услугами срочных данных. Оно также позволяет прикладной программе явно определять, установлен ли (или нет) флаг конца передачи. Чтобы использовать эти средства, прикладная программа помещает под- пись ISO в SEND NCB. (Эти свойства не могут быть использованы в ко- манде SEND CHAIN). В байте четыре поля NCB_CALLNAME прикладная программа устанав- ливает особые биты для обозначения того, использовать или не ис- пользовать срочные данные и устанавливать или не устанавливать флаг конца передачи. Установив четвертый менее значимый бит как один, (xxxx1xxx), прикладная программа выбирает опцию установки флага конца передачи; ноль (xxxx0xxx) обозначает дополнительные данные. Подобным же образом, пятый наименее значимый бит выбирает срочную (xxx1xxxx) или обычную (xxx0xxxx) отправку данных. Для получения срочных данных, прикладная программа должна по- местить подпись ISO в свои команды RECEIVE и RECEIVE ANY. Когда NETBIOS возвращает NCB, он заполняет байт четыре поля NCB_CALLNAME битами, о которых говорилось выше. Четвертый наименее значимый бит обозначает конец передачи (xxxx1xxx или xxxx0xxx), а пятый наименее значимый бит обозначает срочные данные (xxx1xxxx или xxx0xxxx)> Подпись ISO также сообщает интерфейсу NETBIOS, что прикладная программа может принять расширенный код возврата "Сообщение прерва- но" (шестнадцатиричная величина 0x07). Интерфейс NETBIOS использует этот нестандартный код возврата, когда он начал перекомпоновку со- общения данных и получает срочные данные до того, как закончилось сообщение. Очевидно, что NETBIOS не может преобразовать срочные данные в текущее сообщение, поэтому он возвращает NCB (Блок управ- ления сетью), который использовался для преобразования вместе с ко- дом возврата "Сообщение прервано". Следующая команда RECEIVE или RECEIVE ANY, которая будет завершена, будет содержать срочные дан- ные, а затем следующий NXCB будет содержать остальную часть первого сообщения. Если прикладная программа не помещает подпись ISO в свои ко- манды RECEIVE или RECEIVE ANY, и NETBIOS получает срочные данные, NETBIOS все равно попытается отправить эти данные. Пока NETBIOS не начал процесс перекомпоновки (преобразования) для этого NCB,он мо- жет поместить в пакет полученные данные и возвратить завершенный Блок управления сетью (NCB). Прикладная программа, естественно, не будет знать о срочных данных. Если процесс перекомпоновки начался в NCB, интерфейс NETBIOS не сможет использовать расширенный код возв- рата, и ему придется экстренно прервать сеанс. В данной главе было рассказано о взаимодействии протоколов NETBIOS - ISO, разработанном корпорацией CMC. Вследствие прозрач- ности этого интерфейса, как прикладные программы ISO, так и стан- дартные прикладные программы для ПЭВМ IBM могут использовать NETBIOS в качестве интерфейса для сети. Стандартные прикладные программы ПЭВМ в состоянии осуществлять коммуникацию друг с другом, а прикладные программы ISO на ПЭВМ в состоянии обмениваться данными друг с другом и с обычными прикладными программами ISO в других системах (системах на основе неперсональных ЭВМ). ПРИЛОЖЕНИЕ СПИСОК СОКРАЩЕНИЙ ------------------- API - Интерфейс прикладного программирования APPC - Перспективное межпрограммное взаимодействие ASCII - Американский стандартный код для обмена информацией ASYNC - Асинхронный BIOS - Базовая система ввода-вывода CPU - Центральный процессор CRC - Проверка циклическим избыточным кодом CSMA/CD - Множественный доступ с контролем несущей и обнаружением конфликтов DMA - Прямой доступ в память DOS - Дисковая операционная система DSAP - Точка доступа к сервису (услуге) назначения HDLC - Высокоуровневая управляющая процедура ID - Идентификатор IEEE - Институт инженеров по электротехнике и радиоэлектронике ISO - Международная организация по стандартизации Kbps - Тысяч бит в секунду LAN - Локальная вычислительная сеть LLC - Управление логическим каналом LPDU - Элемент данных протокола логического канала LSAP - Точка доступа к сервису канала MAC - Управление доступом к носистелям Mbps - Миллион бит в секунду MCB - Блок управления сообщениями MMIO - Ввод-вывод управления памяти MS-DOS- Дисковая операционная система Microsoft NCB - Блок управления сетью OS/2 - Операционная система/2 OSI - Соединение открытых систем PC - Персональная ЭВМ PC-DOS- Дисковая операционная система для ПЭВМ PDU - Элемент данных протокола PS/2 - Персональная система/2 RAM - Оперативное запоминающее устройство (ОЗУ) ROM - Постоянно запоминающее устройство (ПЗУ) SAA - Прикладная архитектура систем SAP - Точка доступа к сервису SMB - Блок сообщений спецпроцессора SNA - Сетевая архитектура систем SSAP - Точка доступа к сервису источника TCP/IP- Протокол управления транспортом/Межсетевой протокол VLSI - Очень широкомасштабная интеграция |