ЭЛЕКТРОННАЯ БИБЛИОТЕКА КОАПП
Сборники Художественной, Технической, Справочной, Английской, Нормативной, Исторической, и др. литературы.



 

Часть 1

                            Дж.С.Хаугдахл
                СЕТЕВАЯ БАЗОВАЯ СИСТЕМА ВВОДА-ВЫВОДА
                           N E T B I O S
               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, отличные от разработки фирмы I
BM
               Фирма 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 NET
BIOS
                      Вызовы процедур
                      Функционирование
               Компания 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),эмулятор NETB
IOS
 (который позволяет работать с прикладными программами, первонача
ль-
 но созданными для Сети ПЭВМ (PC Network), в кольцевой сети с эст
а-
 фетной передачей - Token-Ring) и Служебная программа ЛВС ПЭВМ (P
 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), Протокол управления передачей ARPA
NET
 (Transmission Control Protocol), Межсетевой протокол ARPANET
 (Internetwork Protocol) - TCP/IP. NETBIOS не стал бы фактическим
 стандартом  для ЛВС ПЭВМ, если бы он не был предложен IBM. Вслед
ст-
 вие того, что NETBIOS был создан как открытый интерфейс в сети П
ЭВМ
 IBM, он все-таки может стать стандартом, по крайней мере как инт
ер-
 фейс сеансового уровня (это пятый уровень взаимодействия  компон
ен-
 тов  сети в модели соединения открытых систем; подробно см. дале
е).
 Однако, несмотря на широкое распостранение NETBIOS, он еще не  с
тал
 стандартом.
                      Определение протокола
      Протоколы  представляют  собой  просто  набор  условий (пра
 вил),которые регламентируют формат и процедуры обмена информацие
 между двумя или несколькими независимыми устройствами  или  про-
 цессами. Протокол имеет три важнейших элемента: синтаксис, семан
 тику и синхронизацию (timing). Синтаксис протокола определяет по
 ля; например, может быть 16-байтовое поле для адресов,  32-байто
 вое поле для контрольных сумм и 512 байт на пакет. Семантика про
 токола  придает этим полям значение: например, если адресное пол
 состоит   из   всех   адресов,   это   "широковещательный"    па
 кет. Синхронизация  -  количество битов в секунду - это скорость
 передачи данных. Она важна не только на самых низких  уровнях
 протокола, но и на высших.
      На рис 1-1 показан типичный формат сообщения. В начале сооб
 щения, передаваемого в сети, присваиваются символы синхронизации
 с той целью, чтобы другой узел в сети мог увидеть, что "приходит
 сообщение  и смог синхронизировать приемник с передатчиком. Заго
 ловок  сообщения  содержит  информацию  об адресе - откуда и куд
 поступает сообщение. Текст сообщения - это сама информация, посы
 лаемая по сети. Он имеет заголовок и иногда концевик,  показываю
 щий,  где  заканчивается сообщение. В конце сообщения также могу
 быть символы управления и синхронизации.
                     Начало          Д А Н Н Ы Е         Конец
                   сообщения                           сообщения
                               !      СООБЩЕНИЯ      !
                    !      !  !                       !  !     !
                   !        !!                         !!       !
                   ----------------------------------------------
                   !         !      !            !      !       !
                   !Символы  !Заго- !            !Конце-!Управ- !
    Направление    !управле- !ловок ! Т Е К С Т  !вик   !ляющие !
    потока         !ния и    !сооб- !            !сооб- !симво- !
    данных         !синхро-  !щения ! СООБЩЕНИЯ  !щения !лы     !
  <----------------!низации  !      !            !      !       !
                   !         !      !            !      !       !
                   ----------------------------------------------
      Рис 1-1. Типичный формат сообщения.
      Существует несколько  проблем,  связанных  с  транспортными
 протоколами. Одна из них заключается в структуре адресации: долж
 на ли она быть простой (одна область адресации для взаимосвязан-
 ной системы) или иерархической (древовидная структура адресов та
 кая,  как  сеть,  станция или гнездо в станции)? Что представляе
 собой область адресации системы - сколько узлов  или  ПЭВМ  могу
 логически  быть адресованы в системе? Количество ПЭВМ, подключае
 мых к системе намного меньше,чем область адресации. Каков  долже
 быть размер единицы данных? В этом вопросе необходимо компромисс
 ное решение, потому что большие единицы данных могут "покоробить
 систему,  а  передача  маленьких  единиц может быть неэкономична
 Имеет ли система некоторый способ контроля ошибок? Если  происхо
 дят какие-либо неполадки,сможет ли система протоколов показать, 
 чем состоит проблема, и сможет ли она исправить эту ошибку? Каки
 образом синхронизируются пакеты в уровнях протокола? Предположим
 что-то неисправимо повредило чей-либо пакет данных или записало 
 неправильный файловый процессор - будет ли обеспечена защита? Им
е-
 ется ли управление протоколами для контроля распределения  ресур
 сов  и  анализа  производительности системы? Как мы увидим далее
 NETBIOS удовлетворяет многим, но не всем этим требованиям.
         Сеть ПЭВМ и кольцевая сеть с эстафетной передачей
 Прикладные программы,написанные в NETBIOS для Сети ПЭВМ (PC Netw
ork),
 будут    работать    с   эмулятором   кольцевой   эстафетной   с
ети
 (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 и прикладными программами
      Коллективное использование информации в ЛВС на основе  NETB
IOS
 требует  наличия трех важнейших элементов программного обеспечен
ия:
 1). PC-DOS 3.Х; 2). самого NETBIOS; 3). подпрограммы переадресат
ора
 сообщений. На рис 1-5 показан способ соединения этих трех компон
ен-
 тов в систему. NET, доступный из прикладной программы или програ
ммы
 переназначения через прерывание 2AH, является частью Программы Л
ВС
 ПЭВМ IBM. Полная реализация Программы Сети ПЭВМ показана на  пра
вой
 стороне  рисунка; файловый процессор и процессор печати показаны
 на
 заднем плане.
       Рабочая станция                        Спецпроцессор
 !----------!                                        !-----------
--!
 !Прикладная!<---------!          !----------------->! Прикладная
  !
 !программа !          !   INT 2AH!            ----->! программа 
  !
 !----------!          !   INT 2FH!            !     !-----------
--!
      ^                !          !            !          ^
      !                !          !            !          !
      ! INT 2AH        !          !            !          ! INT 2
1H
      !                !          !            !          !
     \ /               !         \!/           !         \ /
 ----------            !        !----------!   !      -----------
---
 !   ! Пр !            !        !Файловый  !   !      !Прог- !   
  !
 !   ! ог !            !        !процессор/!<-------->!рам-  !   
  !
 !DOS! ра !            !        !процессор !   !      !ма    !   
  !
 !3.Х! мма!<---------->!        !печати    !   !      !пере- ! DO
S !
 !   ! пе !            !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-Rin
 протокол доступа к каналу (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  п
ро-
 веряет наличие места в таблице сеансов и ждет пакета "запрос на 
се-
 анс". Если источник этого пакета совпадает с удаленным именем, о
п-
 ределенным  прикладной  программой,  то выполняется команда LIST
EN.
 Пакет "сеанс принят" будет возвращен в источник, в таблице  сеан
сов
 будет установлен флаг (установленного) сеанса, будет установлен 
но-
 мер  местного  сеанса (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_LENGT
 длину буфера. Действие команды RECEIVE ANY сходно с  действием  
ко-
 манды  RECEIVE,  за исключением того, что в первом случае сообще
ние
 может быть принято от любого имени.
      SEND DATAGRAM/SEND BROADCAST DATAGRAM
      Для команды SEND DATAGRAM, NETBIOS сравнивает номер  запрош
ен-
 ного имени с образцом в таблице имен. Если имя найдено, NETBIOS 
по-
 сылает пакет дейтаграмм (рис.3-10) в узел назначения.Для BROADCA
ST,
 проверяется  номер  имени, и, если он верен, дейтаграмма посылае
тся
 всем узлам в сети. Дейтаграмма посылается только один  раз, и  п
оле
 адреса на канальном уровне устанавливается как единица.
      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 System
s -
 XNS), Протокол управления передачей (Transmission Control  Proto
col
 - TCP), либо протоколы транспортного уровня ISO/NBS.
                           Сетевой уровень
      Сетевой  уровень  в сети ПЭВМ IBM использует протокол перед
ачи
 пакетов (PTP). Этот протокол состоит из четырех важнейших процед
ур:
 послать пакет PTP, послать кадр протокола доступа к  каналу (LAP
),
 получить кадр LAP и процедура полученного кадра.
      Процедура  отправки  PTP  требует того, чтобы буфер был пос
лан
 особенному идентификатору сетевого соединения. Если соединение  
су-
 ществует,  то  PTP форматирует буфер и посылает его через кадр L
AP.
 Учтите, что, хотя  этот  протокол/процедура  позволяет  осуществ
ить
 взаимодействие, реализация 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 содержат длину заголовка NETBI
OS,
 включая само поле длины. Следующие 16 бит (2 байта) содержат  ше
ст-
 надцатиричную  величину EFFF, которая является разделитилем, ука
зы-
 вающим, что последующие данные предназначены для эмулятора NETBI
OS.
 Следующий  байт является фактической функцией кадра 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' ! Повторная передача последних   
 !
 !                     !        ! данных - ожидает команда RECEIV
E!
 ----------------------------------------------------------------
--
      Рис. 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-Rin
g.
                            Г Л А В А     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), переадресатор осуществит попытку установить сеанс со спецп
ро-
 цессором. Если в таблице адресов местного адаптера  есть  свобод
ное
 место,  начинается  сеанс,  в котором переадресатор и спецпроцес
сор
 договариваются о протоколе, и  начинается обмен данными.
      Со стороны спецпроцессора, переадресатор делает запрос,  чт
обы
 установить соединение с общим ресурсом, таким как подкаталог. Сп
ец-
 процессор  удостоверится,  что  запрашиваемый ресурс существует,
 и,
 если это так, проверит достоверность  пароля.  Затем  спецпроцес
сор
 выдаст  максимальный размер блока передачи спецпроцессора и hand
le
 соединения, называемый идентификатором маршрута сети (подобный
 возвращаемому PC-DOS при  открытии файла) для всех будущих запро
сов
 к ресурсам. Когда соединение завершается, переадресатор "приказы
ва-
 ет" спецпроцессору закончить соединение и освободить идентификат
ор.
      Пользователь может ретранслировать сообщения другму компьют
еру.
 В этом случае,  отправитель (например, спецпроцессор) делает зап
рос,
 чтобы компьютер, получающий ретранслируемое сообщение, добавил  
имя
 пользователя  в сеть как ретранслируемое имя. С этого момента со
об-
 щения для данного пользователя будут передаваться требуемой ЭВМ.
           Протоколы блока сообщений спецпроцессора (SMB)
      Набор протоколов SMB состоит из четырех типов блоков  сооще
ний
 спецпроцессора:  управления сеансом (соединением), файла, печата
юще-
 го устройства и сообщения. Управление сеансом выполняет две  осн
ов-
 ные функции: определение диалекта и управление соединением.
      Если Программа ЛВС ПЭВМ работает (и, следовательно, задейст
во-
 ваны  протоколы SMB), после установки сеанса между ПЭВМ-переадре
са-
 тором и ПЭВМ-спецпроцесором, переадресатор посылает команду  VER
IFY
 DIALECT  вместе со списком поддерживваемых диалектов обратно спе
цп-
 роцессору. Последний затем определяет, может ли он поддержать од
ин
 из этих диалектов. Если да, то он затем отсылает обратно  переад
ре-
 сатору указание о том, какой диалект будет использоваться.
      Если  спецпроцессор не сможет поддержать ни один из диалект
ов,
 он посылает сообщение об ошибке обратно ПЭВМ-переадресатору, и  
се-
 анс завершается.
      Управление  соединением  состоит из команд, которые начинаю
т и
 оканчивают соединение переадресатора с общим ресурсом в спецпроц
ес-
 соре.  Команда  START  CONNECTION  устанавливает  соединение  ме
жду
 ПЭВМ-переадресатором  и  общим  ресурсом в ПЭВМ-спецпроцессоре. 
Все
 дальнейшие команды и ответы используют  этот  сеанс.  Команда  E
ND
 CONNECTION  завершает  соединение между переадресатором и общим 
ре-
 сурсом.
      Переадресатор может использовать команды доступа к  файлу  
для
 обращения к файлам в спецпроцессоре, если командой START CONNECT
ION
 было  установлено  соединение.  Эти команды подобны вызовам функ
ций
 местной 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 - Команда устанавливает соединение между  
пе-
 реадресатором и общим ресурсом спецпроцессора. Спецпроцессор сод
ер-
 жит  таблицу,  которая устанавливает соответствие общего ресурса
 из
 имени маршрута сети с местным именем, определяет тип ресурса и  
со-
 держит  произвольный пароль. Спецпроцессор возвращает идентифика
тор
 маршрута сети для использования в последующих запросах этого рес
ур-
 са. Прикладная программа может  также  использовать  команду  ST
ART
 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 - Посылается  переадресатором  спецпроцессору  
для
 осуществления  запроса,  что  все буферы для файла были записаны
 на
 жесткий диск спецпроцессора. Переадресатор определяет      handl
 файла, и спецпроцессор выдает ответ, когда операция завершена. Н
ес-
 колько файлов могут быть выполнены, если переадресатор  определя
ет,
 что должны быть выполнены все файлы, открытые в соединении, кото
рое
 представлено идентификатором маршрута сети в поле 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 - Посылается для получения имени машины по
ль-
 зовательского  имени.  Данная  команда обычно используется вмест
е с
 предылдущей, чтобы получить имя, на которое посылать команду CAN
CEL
 FORWARD.
                           Г Л А В А    5
         РАЗРАБОТКИ  NETBIOS,  CДЕЛАННЫЕ  ДРУГИМИ  ФИРМАМИ
         -------------------------------------------------
        Разработки NETBIOS, отличные от разработки фирмы IBM
      В  данной  главе  описываются  разработки  NETBIOS  несколь
ких
 фирм-продавцов. В первой четверке таких компаний числится  фирма
  -
 производитель плат ПЭВМ, производитель внешних плат Ethernet, фи
рма
 -  продавец  программного  обеспечения для файлового процессора 
ЛВС
 ПЭВМ и компания-продавец многопользовательскаого программного об
ес-
 печения. Для всех них общим является совместимый с  NETBIOS  инт
ер-
 фейс  сеансового уровня, отвечающий вызовам функций прерывания 5
CH
 NETBIOS и возвращаемым результатам. Различие между ними заключае
тся
 в протоколах, использующихся для  реализации  высокоуровневых
 протоколов,  которые находятся над сеансовым (пятым в модели Сое
ди-
 нения открытых систем) уровнем, - т.е. на  транспортном  и  сете
вом
 уровнях (см.Главу 1). Сетевой уровень часто взаимодействует с оп
ре-
 деленным  типом  канального  уровня;  т.е.  определенная разрабо
тка
 NETBIOS работает только на сетевой технологии определенного поль
зо-
 вателя, несмотря  на  "переносимость"  высокоуровневых  протокол
ов,
 включаяя NETBIOS. Необходимо отметить, однако, что все фирмы пре
дс-
 тавляют свои промежуточные протоколы как открытые для подсоедине
ния
 к  другим  технологиям ЛВС, что позволяет пользователям реализов
ать
 эмулятор NETBIOS своего соединения имеющейся  технологии  ЛВС  т
ак,
 как они находят необходимым для себя.
                         Фирма AST Research
      Разработанная  фирмой  AST  Research (США) версия
 NETBIOS полностью воплощает  все  функции  NETBIOS,  что  позвол
яет
 Программе ЛВС ПЭВМ IBM или же любой другой прикладной программе,
 совместимой  с NETBIOS, успешно функционировать. Значительные ча
сти
 этой программы были написаны на языке С, что делает ее переносим
ой.
 Данная реализация доступна для таких продуктов фирмы AST как PCn
et,
 PCnet-II и RSN. Фирма планирует заключить контракт с изготовител
ями
 комплексного  оборудования на отладку своей версии NETBIOS. Испо
ль-
 зуемые протоколы основаны на Сетевых системах Ксерокс (XNS -  Xe
rox
 Network Systems).
      Реализация  AST  предоставляет пользователю больше средств 
уп-
 равления работой NETBIOS, чем другие версии, включая и версию  I
BM.
 При отладке программного обеспечения пользователь может принять 
оп-
 ции  по умолчанию, либо определить величину тайм-аута положитель
ной
 квитации (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  Protoc
ol/
 Internet Protocol - Протокол управления транспортом/Межсетевой П
ро-
 токол) компании Excelan, которые, в свою очередь, обмениваются д
ан-
 ными с ЛВС Ethernet. Реализация протоколов TCP/IP, предлагаемая 
из-
 готовителем комплексного оборудования Excelan, спроектирована та
ким
 образом,   чтобы  обеспечить  возможность  работы  с  оборудован
ием
 Excelan (интерфейсные процессоры Ethernet). Фирма Excelan предла
га-
 ет  изготовителям  комплексного   оборудования   одну   из   вер
сий
 NETBIOS/TCP/IP,  которая может быть отлажена. Необходимо отметит
ь,
 что разработки TCP/IP, предлагаемые несколькими фирмами-продавца
ми,
 являются более совместимыми друг с другом,(что облегчает обмен д
ан-
 ными между ними), чем разработки, основанные на  таких  протокол
ах,
 как Сетевые системы Xerox (XNS).
      На рис. 5-2  показана общая схема разработанной фирмой Exce
lan
 реализации 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 (Inter
net
 Packet  eXchange - Межсетевой обмен пакетами). Это дает пользова
те-
 лям совместимость NETBIOS с любой из двух десятков ЛВС  ПЭВМ,  п
од-
 держиваемой  Advanced NetWare (включая Сеть ПЭВМ), а также повыш
ает
 производительность работы. Интересно,  что  испытания,  проведен
ные
 компанией Novell, показали, что производительность в сквозном вз
аи-
 модействии  рабочих  станций при использовании эмулятора возраст
ает
 вдвое по сравнению с оригинальным NETBIOS в Сети ПЭВМ. При устан
ов-
 ке оболочки рабочей станции пользователь  может  определить,  ка
кую
 версию NETBIOS ему использовать.
      Фирма  Novell  добилась повышения эффективности и при перед
аче
 пакетов между уровнями. Теоретически, по уровням передаются  тол
ько
 пакеты,  а не информация и буферных и рабочих областях, использу
е-
 мых  другим уровнем. Это обеспечивает совместимость с версией да
н-
 ного протокола, разработанного другими фирмами.
      В реализации Novell, пакеты не посылаются от NETBIOS (на се
ан-
 совом уровне) в транспортный уровень. Вместо этого от одного уро
вня
 следующему уровню передается указатель, что позволяет избежать  
из-
 лишней записи данных в шине и процессоре. Эта технология "выпрям
ля-
 ет"  весь  процесс,  но нарушает правила модели Соединения откры
тых
 систем (OSI). Она используется и другими фирмами из-за  соображе
ний
 эффективности и конкурентоспособности.
      На  рис  5-3  показана разработанная Novell версия NETBIOS 
для
 ЛВС ПЭВМ, поддерживаемых NetWare.  Заметьте,  что  оболочка  Nov
ell
 фукционально эквивалентна переадресатору 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 вместе со Стандартной версией O
S/2
 поддерживает внешние прикладные программы на основе спецпроцессо
ра.
 В соответствии с этой  конфигурацией,  Генератор  запросов  NetW
are
 загружается  как на рабочей станции (или пользователе), так и на
 спецпроцессоре  прикладных  программ.  Пользовательский   компон
ент
 прикладной  программы осуществляет запросы на прикладные услуги 
че-
 рез Генератор запросов NetWare; сетевой механизм равноправной тр
ан-
 спортировки затем посылает запрос  прикладному  спецпроцессору  
для
 обработки.  Ответы отсылаются обратно на рабочую станцию по тому
 же
 маршруту. Если прикладная программа  должна  использовать  файло
вую
 систему NetWare на физически отдельном файловом процессоре, Гене
ра-
 тор запросов NetWare в прикладном спецпроцессоре передаст  запро
сы
 ввода/вывода  диска файловому спецпроцессору NetWare для приклад
ной
 программы.
      Novell поддерживает  стандартные  интерфейсы  прикладного
 программирования (API),(определенные IBM),которые позволяют осу-
 ществлять  совместную обработку данных: NETBIOS, APPC и API IBM 
для
 OS/2 (APPC - Перспективное межпрограммное взаимодействие). Novel
 не осуществляет поддержку Поименованных  Каналов  (Named  Pipes)
 поскольку они не поддерживаются IBM. Поименованные каналы являют
ся
 частью Администратора ЛВС Microsoft, который поддерживается 3Com
      Прикладной сопроцесссор NetWare для  Расширенной  версии  O
S/2
 поддерживает  внутренние прикладные программы на основе спецпроц
ес-
 сора.
                    Фирма   The  Software  Link
      Компания The Software Link (США), в отличие от трех фирм, о
пи-
 санных выше, разработала эмулятор NETBIOS для не-сетевых продукт
ов.
 Она создала два продукта, которые позволяют пользователям  IBM  
PC
 коллективно  использовать  ресурсы (печатающие устройства и жест
кие
 диски).
      Первый продукт превращает PC или AT  в  многопользовательск
ую,
 многофункциональную  машину.  Multilink Advanced использует ОЗУ 
для
 параллельной работы до девяти прикладных программ. К  рабочей  П
ЭВМ
 через  порты  RS-232  можно подсоединять до восьми терминалов AS
CII
 (включая терминал с клавиатурой IBM и  эмулятором  экрана  "Shad
ow"
 фирмы The Software Link).
      Второй  продукт,  LANlink,  позволяет размещать низкоуровне
вую
 сеть, состоящую из взаимосвязанных ПЭВМ, по звездообразной  топо
ло-
 гии.  Звезды могут соединяться с другими звездами, а также и с у
да-
 ленными ПЭВМ, что позволяет иметь довольно-таки произвольную  то
по-
 логию  сети. В отличие от Multilink Advanced, ПЭВМ присоединяютс
я к
 рабочей ЭВМ, а не к терминалам. Также как и в  Multilink  Advanc
ed,
 применяются порты 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), с которыми  NETB
IOS
 может  сосуществовать в ЛВС фирмы-продавца. С целью увеличения п
ро-
 изводительности, такие фирмы, как 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), которая состоит из платы адаптера ПЭВМ, каб
еля
 адаптера, расширенной версии сетевой операционной системы Micros
oft
 Networks, NETBIOS, управляемых меню  и  командами  пользовательс
ких
 интерфейсов и программмного обеспечения для диагностирования.
      Программы ЛВС ПЭВМ NCR и NETBIOS совместимы с другими систе
ма-
 ми  ЭКС.  Программа  ЛВС  ПЭВМ  NCR,  являющаяся  версией Micros
oft
 Networks, управляет функциями сообщений в сети, печати, диска и 
ка-
 талога. Программа NETBIOS NCR обеспечивает совместимое с ПЭВМ ср
ед-
 ство транспортировки для Управления логическим каналом (LLC)   и
 Управления доступом к носителям  (MAC)  и  работает  с  прикладн
ыми
 программами,  предназначенными для использования со стандартной 
ЭКС
 NETBIOS.
             Компания Network Research Corporation (NRC)
      Фирма NRC (США) совместила возможности NETBIOS со своим сет
е-
 вым  программным  обеспечением  FUSION,  что  позволяет  интерфе
йсу
 NETBIOS работать в сетях нескольких фирм.
      Версия FUSION позволяет пользователям запускать любые прикл
ад-
 ные  программы  NETBIOS  в  сети  TCP/IP.  Кроме того, пользоват
ели
 NETBIOS могут перемещать файлы между своими  системами.  Система
ми,
 поддерживаемыми  Сетевым  программным обеспечением FUSION, являю
тся
 компьтеры VAX/VMS Digital и рабочие станции UNIX.Пользователи мо
гут
 также использовать различные канальные уровни, например  Etherne
 или  RC, поставляемые различными фирмами.
      Версия  FUSION  NETBIOS  отвечает Стандарту протокола RFC 1
001
 (Стандарт протокола для сервиса NETBIOS  в  транспортном  проток
оле
 NCP/UDP - КОНЦЕПЦИИ и МЕТОДЫ //см.Главу 7//)  и Стандарту проток
ола
 RCF  1002  (Стандарт  протокола  для Сервиса NETBIOS в транспорт
ном
 протоколе TCP/UDP - ДЕТАЛЬНАЯ СПЕЦИФИКАЦИЯ), что делает ее  совм
ес-
 тимый  с существующими прикладными программами. Эта опция доступ
на
 для MS-DOS/PC версии FUSION.
                        Фирма Pathway Design, Inc
      Фирма Pathway Design (США) предлагает свой продукт  -  netP
ATH
 SNA-3770/NetBIOS  -  шлюз ЛВС для передачи данных между любыми с
ов-
 местимыми с NetBIOS ЛВС и большими  ЭВМ  IBM  со  скоростью  до 
 56
 кбайт/сек.
      Даннный  шлюз является программным и аппаратным продуктом, 
ко-
 торый обеспечивает обмен данными между пользовательскими ПЭВМ, п
од-
 соединенными  к  ЛВС  и рабочей большой ЭВМ, действующей в сети 
SNA
 (Сетевой архитектуры систем). Продукт NetPATH/NetBIOS  содержит
 удаленный  контроллер  кластеров  IBM  3274 с присоединенными
 рабочими станциями 3270. В каждой рабочей станции ЛВС ПЭВМ PC, A
 или XT IBM могут устанавливать несколько параллельных сеансов  Л
ВС
 с рабочей ЭВМ и отдельными сеансами DOS. Этот шлюз также включае
т в
 себя программное обеспечение передачи файлов фирмы Pathway Desig
n -
 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 также предлагает  свою  версию  Программы  NETB
IOS
 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) и IrmaL
an,
 PCOX 3270 gateway (шлюз), IBM Async Server (асинхронный спецпроц
ес-
 ссор), IBM PC Network Program (Программа Сети ПЭВМ),  IBM  PC  3
270
 Emulation   Program   (Программа   эмуляции),   Network  Courier
  и
 Brightwork Software's  Net  Remote.
      3Com достигает межсетевого взаимодействия с NETBIOS путем о
бъ-
 единения интерфейса  NETBIOS  со  своими  управляющими  программ
ами
 (драйверами)  коммуникации  Сетевого стандарта Ксерокс (XNS - Xe
rox
 Networking Standard): 3+ транслирует запросы NETBIOS в запросы X
NS,
 которые должны быть отправлены по сети; когда  либо  от  удаленн
ой,
 либо  от  местной сети получаются ответы, они затем обратно пере
во-
 дятся в формат вызова 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 Pipe
s),
 средство Администратора (Manager) ЛВС Microsoft, если  имеется  
ин-
 терфейс, который расширяет межпроцессовое взаимодействие OS/2 пр
оз-
 рачно  в сети. Поименованные каналы предоставляют более высокоур
ов-
 невый интерфейс для APPC, NETBIOS или  транспортного  уровня  се
ти,
 что  облегчает  создание  прикладной  программы, которая использ
ует
 удаленные вызовы процедур в сети. Поименованные каналы  служат  
до-
 полнением к межпроцессовым каналам, используемым в OS/2.
      Поименованные каналы (Named Pipes) позволяют разработчику п
рик-
 ладной программы получать доступ к вычислительному ресурсу
 (находящемуся в любом месте сети), как будто он является местным
 Поименованные каналы облегчают создание встроенных в сеть прикла
д-
 ных  программ.  Это не  исключает наличие возможности для разраб
от-
 чика прикладных программ писать  эти  программы  непосредственно
 используя  интерфейсы прикладного программирования (API) транспо
рт-
 ного уровня, APPC (Перспективное межпрограммное взаимодействие)
 или NETBIOS.
                       АНАЛИЗАТОР ПРОТОКОЛОВ
      С усложнением ЛВС возникает необходимость в применении спец
иа-
 лизированных инструментальных программных средств,  предназначен
ных
 для  диагностирования, отладки, обслуживания, управления и контр
оля
 сети.
      Первыми средствами такого рода стали средства сбора  статис
ти-
 ческих  данных о работе сети (например, о загрузке сети, количес
тве
 передаваемых в секунду пакетов и т.п.) и о "здоровье" сети  (нап
ри-
 мер,  ошибки  контроля по циклическому избыточному коду, конфлик
ты,
 утерянные лексемы). Эти средства управляют преимущественно физич
ес-
 ким и канальным уровнями ЛВС.
      Вторая - более высокоуровневая - категория таких средств
 позволяет управлять работой сети, например пользовательским  дос
ту-
 пом к узлам сети и портам, подсоединенным к этим узлам, а также 
оп-
 ределять различные параметры, при которых узлы будут работать (н
ап-
 ример, постоянные виртуальные каналы связи, характеристики терми
на-
 ла, управление потоком).
      Третья  категория  подобных средств - средства, могущие упр
ав-
 лять промежуточными протоколами - Уровни с 3 по 6 Модели соедине
ния
 открытых систем OSI. С помощью этих средств можно управлять рабо
той
 протоколов и обнаруживать неполадки. Такие средства также позвол
яют
 разработчикам реализовывать и отлаживать протоколы, обеспечивая 
 их
 совместимость с определенным набором протоколов (таким как NETBI
OS,
 к примеру).
                        "ИЩЕЙКА"   (Sniffer)
      Первым появившимся в продаже анализатором протоколов для
 NETBIOS (и единственно доступным на  время  написания  этой  кни
ги)
 стал  продукт фирмы Network General Corporation (США) "The Sniff
er"
 (ИЩЕЙКА).
      Он представляет собой комбинацию  программного  и  аппаратн
ого
 обеспечения,  которое  служит в качестве кадрового анализатора д
ля
 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, (фирмы Compa
q),
 этот анализатор позволяет проводить анализ трафика в ЛВС  Ethern
et.
 Программное  обеспечение не обеспечивает непосредственную поддер
жку
 для управления протоколами NETBIOS, но оно  позволяет  осуществл
ять
 отладку для управления кадрами определенных битовых образцов. По
ль-
 зователь,  знающий поля битов в пакетах NETBIOS, может, таким об
ра-
 зом, установить систему для управления этими пакетами.
                             Г Л А В А      6
                       MICROSOFT       и         IBM
                       -----------------------------
                          Историческая справка
     Когда  в  1984 году было впервые объявлено о Сети ПЭВМ IBM (
IBM
 PC Network), возник вопрос: какое сетевое  программное  обеспече
ние
 реализовала  фирма IBM ? Своеобразный ответ на него дали компани
и-
 продавцы ЛВС: они предложили Сети MICROSOFT  (Microsoft  Network
s),
 думая,  что  именно это программное обеспечение используется в С
ети
 ПЭВМ (PC Network). Принятие такого решения было обусловлено, в ч
ас-
 тности, еще и тем, что операционная система MS-DOS фирмы  Micros
oft
 стала   PC-DOS   для   компании  IBM.  (Сети  Microsoft  (Micros
oft
 Networks) безусловно являются продуктом изготовителей  комплексн
ого
 оборудования.  Они не реализованы ни в какой определенной ЛВС - 
это
 обусловлено только фирмой-изготовителем комплексного оборудовани
я).
      Та же история повторилась в апреле 1987 года, когда IBM  об
ъя-
 вила  о создании OS/2 одновременно с фирмой Microsoft, которая з
ая-
 вила о своем новом продукте -  Администраторе  ЛВС  (LAN  Manage
r).
 В течение некоторого времени после этого события компания IBM не
 разглашала свою новинку - "стратегию спецпроцессора", пока не вы
шла
 на  рынок  с  новым  своим продуктом - Спецпроцессором ЛВС OS/2 
IBM
 (IBM OS/2 LAN Server). И снова возникли затруднения - как же  со
от-
 носятся  эти  два  продукта  -  Спецпроцессор  IBM  и Администра
тор
 Microsoft?
      В настоящей главе рассказывается об эволюции  Сетей  Micros
oft
 (Microsoft Networks) и Программы ЛВС ПЭВМ IBM (IBM PC LAN Progra
m),
 начиная с оригинальной разработки и до их реализации в OS/2.
                             MICROSOFT
                             ---------
               Сети Microsoft (Microsoft Networks)
      Только  после  выпуска Сети ПЭВМ (PC Network) с модулирован
ной
 передачей фирмы-продавцы и пользователи стали осознавать, что
 сетевое программное обеспечение в Сети ПЭВМ (которое позднее  ст
ало
 известно  как  NETBIOS)  является  несовместимым с Сетями Micros
oft
 (Microsoft Networks) и оно не было создано фирмой Microsoft. В  
ре-
 зультате, поток продуктов, совместимых с Сетями Micrsoft, о кото
ром
 объявили многие фирмы-продывцы ЛВС, никогда не был реализован.
      После  выпуска cети ПЭВМ (PC Network) фирма Microsoft дейст
ви-
 тельно изменила структуру пользовательских команд в Сетях Micros
oft
 (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
      Основное  различие  между  ранней  версией   Сетей   Мicros
oft
 (Microsoft   Networks)  и  NETBIOS  заключается  в  том,  что  С
ети
 Microsoft предоставляют интерфейс транспортного уровня, в то вре
мя
 как интерфейс NETBIOS находится на сеансовом уровне. Сети Micros
oft
 также  включают специализированной программное обеспечение спецп
ро-
 цессора и рабочей станции, тогда как Программа ЛВС IBM PC обеспе
чи-
 вает эти и другие функции, включая неспециализированный спецпроц
ес-
 сор.
      Транспортный уровень Сетей Microsoft используется для отпра
вки
 сообщений  через  виртуальные  каналы. По одному запросу может б
ыть
 передано до 64 кбайт. Коммуникация (обмен данными)  с  транспорт
ным
 уровнем осуществляется посредством прерывания 21H, функция 5BH (
на-
 помним, что NETBIOS использует прерывание 21H, функция 5CH).
      Коммуникация  с  транспортным уровнем производится посредст
вом
 установки Блока управления транспортом  (Transport  Control  Blo
ck,
 сокращенно 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 позоляет иметь несколько имен, динамически перен
аз-
 начать имена и транслировать их; в то сремя как в  Сетях  Micros
oft
 требуется,  чтобы  администратор  присваивал только одно логичес
кое
 имя каждому физическому адресу.
      Несмотря на различия в обеих реализациях, у них есть один  
об-
 щий  недостаток:  обе основываются на MS-DOS для выполнения услу
г в
 файловом процессоре. Другими словами, на них влияют недостатки о
пе-
 рационной системы - однопользовательской и "однозадачной". В пер
вой
 редакции данной книги мы написали следующее: "Не совсем ясно,  с
мо-
 жет  ли  'многозадачная' версия DOS решить эту проблему, потому 
что
 для успешной своей работы она более чем вероятно НЕ будет  совме
с-
 тима  с предыдущими версиями DOS,что полностью обезоружит пять м
ил-
 лионов владельцев ПЭВМ". Как оказалось,  OS/2  поддерживает  тол
ько
 некоторые  команды  DOS  и лежащую в основе DOS файловую структу
ру,
 что не устраняет трудности в работе для любого спецпроцессора  Л
ВС,
 действующего под управлением OS/2. (Метод, имеющийся в DOS, - ме
тод
 использования таблицы размещения (записей) файла (FAT) потребует
 проведения интенсивного табличного поиска при открытии, закрытии
 и
 поддержании файла).
      Некоторые   фирмы-продавцы,  объявившие  о  поддержке  Сете
 Microsoft, выпустили на рынок промышленные версии для своих  сет
ей.
 Многие из них предлагают также и NETBIOS, т.к. Сети Microsoft вк
лю-
 чают  "образец" эмулятора NETBIOS, который фирмы-изготовители ко
мп-
 лексного оборудования могут предлагать наряду со своими  продукт
а-
 ми. Получилось так, что первоначальная полезность Сетей Microsof
t в
 чистой среде 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 (созданный совместно с 3C
om)
 позволяет пользователям соединять системы ПЭВМ под управлением л
ибо
 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  и  3
Com
 предложили свои собственные версии Средства межпроцессовой комму
ни-
 кации (IPC) до OS/2.
      Администратор ЛВС OS/2 Microsoft полностью совместим с суще
ст-
 вующими  продуктами  Сетей  Microsoft  как для операционной сист
емы
 MS-DOS, так и для XENIX. Это позволяет новым системам под  управ
ле-
 нием  MS-DOS взаимодействовать с существующими сетями, поддержив
аю-
 щими Сети Microsoft.
      Большинство  фирм-изготовителей   комплексного   оборудован
ия,
 предлагающих Сети Microsoft (включая HEWLETT PACKARD, TandemTand
em,
 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 O
S/2
 Extended Edition), которая стала собственной версией OS/2,  созд
ан-
 ной  фирмой  IBM.  От  изготовителей комплексного оборудования O
S/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 nam
e */
  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 n
cbs */
 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 buffe
r */
unsigned short far *   entriesread;  /* # of entries supplied on 
return */
unsigned short far *   totalentries; /* total # of entries availa
ble */
      Величина возврата
      -----------------
      Содержимое  буфера  при  возврате (формат для одного элемен
та)
 может быть одно из следующих:
      Уровень 0 содержит "struct_netbios_info_0", Уровень 1 содер
жит
 "struct_netbios_info-1".
      Возврат ошибки
      --------------
      Возврат функции 0 означает, что все нормально. Возможными в
оз-
 вратами ошибок могут быть следующие:
      - сеть не начала работать;
      - устройство не найдено;
      - спецпроцессор не найден;
      - сбой в обмене данными с удаленным спецпроцессором.
                   Вызов процедуры   NETBIOSGETINFO
 Назначение: Получение информации  о  данной  управляющей  програ
мме
             (драйвере) NETBIOS.
      Условие вызова
      --------------
int far pascal netbiosgetinfo (servername,netdevname,level,buf,bu
flen)
int far pascal netbiosgetinfo (servername,netbiosname,level,buf,b
uflen)
char far *      servername;    /* name of target pc (null if loca
l) */
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) в управляющую программу (драйвер) NETBI
OS.
 Программа может определить, какими эти имена являются, путем выз
ова
 NETBIOSENUM. Нулевая (пустая) строка может  быть  использована  
как
 имя устройства для скрытой ссылки на первую установленную управл
яю-
 щую программу NETBIOS.
      NETBIOSOPT определяет открытые опции, которые включают в се
бя:
      Режим доступа:               1. Обычный (регулярный)
      (mask 0x3)                   2. Привилегированный
                                   3. Исключительный
      Режим доступа определяет каким образом пользователь хочет р
аз-
 делить  доступ к управляющей программе NETBIOS с другими процеду
ра-
 ми. В регулярном режиме драйвер (управляющая программа) может  б
ыть
 открыт любым количеством процедур. Помимо этих процессов, еще од
ин
 процесс  может открывать драйвер в привилегированном режиме. Оди
н и
 только один процесс может открывать драйвер в исключительном  ре
жи-
 ме. В зависимости от режима доступа операции Блока управления се
тью
 (NCB) ограничены.
      Режим              Описание
      -----              --------
      Регулярный         Не позволяет переустанавливать, получать
                         широковещательные дейтаграммы, получать
                         "от любого к любому" Блоки управления
                         сетью (NCB), или использовать постоянные
                         имена в любом Блоке управления сетью (NC
B).
      Превилеги-         Не позвроляет переустанавливать или полу
      рованный           чать NCB "от любого к любому".
      Исключительный     Позволяет выполнять любые операции NCB.
      Условие вызова
      --------------
int far pascal netbiosopen (netbiosname, netreserved,
                            netopenopt, nethandle)
char far *           netbiosname;     /* Name of NETBIOS network 
*/
char far *           netreserved;     /* reserved pointer; must b
e 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 определяет конец сцепливания.
      Хотя может быть сцеплена любая последовательность команд  N
CB,
 не все возможности являются приемлимыми. Например, Вы не можете 
от-
 крыть  сеанс и послать пакет данных по нему, связав команды 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. Процессы могут коллективно  использовать  ресурсы  NETBI
OS,
 которыми  они  располагают, просто путем передачи номеров требуе
мых
 имен и сеансов другим процессам (как об этом сказамно выше).  По
лу-
 чающие  процессы  просто используют номера общих имен или сеансо
в в
 Блоках управления сетью (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, либо с помо
щью
 меню.
      Первоначальная версия программы ЛВС ПЭВМ  подверглась  жест
кой
 критике - главным образом из-за проблем, связанных с производите
ль-
 ностью.  Эта  проблема  обусловлена  тем, что, в отличие от NetW
are
 фирмы Novell, Программа ЛВС ПЭВМ основывается на DOS для  работы
  с
 файлами  и  печатью. Но с совершенствованием операционной систем
ы и
 появлением OS/2, эта проблема потеряла свою остроту. Например,
 DOS  3.3 имеет дополнительно таблицу размещения записей файла (F
AT)
 (команду FASTOPEN).
      Весия 1.3 Программы ЛВС ПЭВМ (PC LAN Program) имеет  следую
щие
 свойства,  которые  облегчили по сравнению с первоначальной верс
ией
 этой программы и проблему управления: контролируемый паролем дос
туп
 к спецпроцессору; централизированное определение ресурсов и  упр
ав-
 ление ими, включая установку времени/даты на главном спецпроцесс
оре
 для  синхронизации даты и времени на всех спецпроцессорах и рабо
чих
 станциях, для управления печатью, определения пользователей и  п
ри-
 вилегий, а также для управления меню выбора прикладных программ 
для
 отдельных  пользователей;  доступ администратора к ресурсам с лю
бой
 рабочей станции, поддержка для удаленной загрузки программ и опе
ра-
 ционной системы (т.е. поддержка для  рабочих  станций,  не  имею
щих
 дисков); возможность просматривать начавших сеанс пользователей,
 и,
 наконец, выбор печати, очередность и отображение состояния для у
да-
 ленных рабочих станций. Версия 1.3 также обладает повышенной про
из-
 водительностью работы.
                       Спецпроцессор ЛВС
      Спецпроцессор ЛВС OS/2 IBM (LAN Server) использует NETBIOS 
для
 обмена  данными  (коммуникации)  в ЛВС. Спецпроцессор обеспечива
ет,
 как для прикладных программ DOS (посредством Программы  ЛВС  ПЭВ
М),
 так и для прикладных программ OS/2, совместное использование рес
ур-
 сов - дисков, печатающих устройств и подсоединенных устройств, п
люс
 средства для определения, управления и руководства доступом  к  
ре-
 сурсам  ЛВС,  наряду с повышенной защитой и управлением печатью 
(до
 восьми печатающих устройств). Эти преимущества сходны с теми, ко
то-
 рые обеспечиваются Программой ЛВС ПЭВМ (PC LAN Program), за  иск
лю-
 чением того, что защита файлов снижена до файлового уровня. Для 
ра-
 боты  Спецпроцессора ЛВС требуется Расширеная версия OS/2 (Exten
ded
 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 и теперь он широко используется во
 многих коммерческих системах. Сетевые и транспортные протоколы I
SO
 несколько новее, и многие фирмы рассматривают их как настоящий м
еж-
 дународный стандарт.
     Протокол управления транспортом/Межсетевой протокол (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 Netw
ork
 Technical Reference).
      Протоколы, поддерживающие услуги NETBIOS,  были  построены 
 на
 различном  аппаратном обеспечении и на основе различных протокол
ов.
 Для обеспечения взаимодействия NETBIOS в Internet, Докладная зап
ис-
 ка определяет стандартный протокол, поддерживающий услуги NETBIO
S с
 использованием TCP и UDP.
      В настоящее время применение  NETBIOS  в  основном  огранич
ено
 ПЭВМ.  Однако, вследствие того, что более мощные ЭВМ лучше подхо
дят
 для выполнения некоторых  прикладных  программ  NETBIOS  (наприм
ер,
 файловый  процессор), данная спецификация была построена таким о
б-
 разом, чтобы позволить осуществить реализацию  NETBIOS  на  любо
 типе  системы,  где может быть использован набор протоколов TCP/
IP
 (Протокол управления транспортом/Межсетевой протокол).
      Данный стандарт определяет набор  протоколов,  поддерживающ
их
 услуги NETBIOS.
      Докладная  записка  описывает протоколы не столько как прос
тую
 коммуникационную услугу, включающую два объекта, сколько как  ра
сп-
 ределенную систему, где задействовано множество объектов, даже е
сли
 они и не участвуют в качестве оконечной точки какого-либо  соеди
не-
 ния NETBIOS.
      Настоящий  стандарт не ограничивает и не определяет, каким 
об-
 разом эти услуги представлены для прикладных программ.
      Тем не менее, считается желательным, чтобы разработчики сох
ра-
 нили  бы существующий интерфейс NETBIOS на компьютерах, действую
щих
 под управлением операционных систем PC-DOS  и MS-DOS.
                      Принципы проектирования
      Для разработки спецификации были  приняты  следующие  принц
ипы
 проектирования.  Большинство из них типичны для процесса стандар
ти-
 зации любых протоколов; некоторые - специфичны именно для NETBIO
S.
      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.  Реализация  на существующих операционных системах. NETB
IOS
 на основе протокола 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 (NBD
D).
 Узлы NBNS и NBDD невидимы для приклалдных программ  NETBIOS  и
 являются частью основного механизма NETBIOS.
      Эти  спецпроцессоры (серверы) являются ядром работы Р- и М-
уз-
 лов с именами и дейтаграммами.
      Как NBNS, так и NBDD могут передавать часть своей работы  о
ко-
 нечному узлу Р или М, который запрашивает услугу.
      Вследствие того, что ответственность возлагается динамическ
и,
 а узлы Р и М должны быть подготовлены к приему управления от спе
ц-
 процессора  NETBIOS, система обычно совершенствует функцию спецп
ро-
 цессора NETBIOS. Например,с расширением протокола Групповых сооб
 щений Internet (Internet Group Multicasting), новые реализации
 Спецпроцессора распределения дейтаграмм NETBIOS (NBDD) могут воз
 лагать ответственность за распределение дейтаграмм NETBIOS
 в полном объеме.
      Взаимодействие  различных реализаций обеспечивается наложен
ием
 ограничений на действие оконечных узлов таким  образом,  чтобы  
они
 могли принимать полный диапазон приемлимых ответов от NBNS и NBD
D.
                     Узлы спецпроцессора имен
      Спецпроцессор  имен  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 определяется идентификатором масштаба NETB
IOS
 (имя домена), используемого различными Р- (и М-)  узлами.  Inter
net
 может содержать многочисленные масштабы 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, нап
ри-
 мер, когда узел типа "Р" хочет получить от  спецпроцессора  NETB
IOS
 всех  владельцев группового имени, используется связь TCP (Прото
кол
 управления транспортом). Следовательно, в протоколах не  произой
дет
 сбой из-за нарушения последовательности отправки пакетов UDP.
      Для того, чтобы исключить потерю пакета ответа или пакета з
ап-
 роса, каждая операция запроса повторно передаст запрос, если  от
вет
 не будет получен в течение определенного промежутка времени.
      Операции с протоколами, чуствительные к успешной передаче  
па-
 кетов ответов, например, операции обнаружения конфликтов с имена
ми,
 защищены  от дублирования пакетов вследствие того, что они игнор
и-
 руют последовательные пакеты с одной и той же информацией  NETBI
OS.
 Так как никакое состояние в отвечающем узле не ассоциируется с з
ап-
 росом, ответчик просто посылает подходящий ответ, когда бы не  п
ри-
 был  пакет с запросом. Следовательно, дублирующиеся или задержан
ные
 пакеты запросов  игнорируются.
      Для всех запросов, если  пакет  ответа  задерживается  слиш
ком
 долго,  то посылается другой пакет запроса. Второй пакет ответа,
 посылаемый "в ответ" на второй пакет запроса, эквивалентен дубли
ру-
 ющемуся пакету. Следовательно, протоколы проигнорируют второй по
лу-
 ченный пакет. Если отправка ответа задерживается до завершения о
пе-
 рации запроса (успешной или нет), пакет ответа будет проигнориро
ван.
      ЗАПРОСЫ БЕЗ ОТВЕТОВ
      Некоторые  типы запросов не имеют соответствующих ответов. 
Эти
 запросы называются "требованиями". В целом, требование представл
яет
 собой  запрос-приказание (императивный запрос), которому получаю
щий
 узел должен подчиниться. Однако, вследствие того,  что  требован
ия
 не  подтверждаются,  они  применяются только в тех ситуациях, ко
гда
 при утере пакета требования произошло бы ограниченное повреждени
е.
      Пакеты требований не передаются повторно.
      ТРАНЗАКЦИИ
      Взаимодействия между парой объектов группируются  в  "транз
ак-
 ции".  Эти  транзакции  объединяют  одну  или более пару типа "з
ап-
 рос/ответ".
      Идентификатор транзакции
      Вследствие того, что между парой объектов  может  происходи
ть
 несколько  одновременных  транзакций, используется "идентификато
 транзакции".
      Инициатор транзакции выбирает  идентификатор,  уникальный  
для
 данного инициатора.  Идентификатор транзакции перемещается впере
д и
 назад при каждом взаимодействии внутри данной транзакции. Партне
ры
 по транзакции должны устанавливать соответствие ответов и запрос
ов,
 сравнивая идентификатор транзакции и адрес 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  байт,  дейтаграмма  NETB
IOS
 будет  разбита  на две. Протоколы и форматы пакетов предусматрив
ают
 разбивку на три и более частей.
      Параметры конфигурации узла
      - В-УЗЛЫ:
      - Уникальное постоянное имя узла.
      - Используется ли Протокол групповых сообщений
        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
.)
 (США).   Первоначально  она  была  напечатана в  журнале  "Compu
ter
 Communication Review" (июль/август 1987г.).
                              Введение
      Набор протоколов, определенный ISO, обещает обеспечить унив
ер-
 сальное  взаимодействие. Сетевые продукты различных фирм-продавц
ов
 смогут взаимодействовать друг с другом, а пользователи  -  компо
но-
 вать  различное оборудование для более полного удовлетворения св
оих
 потребностей. К сожалению, набор протоколов ISO еще  не  создан,
  и
 пользователи еще не могут использовать все необходимые им сегодн
 прикладные программы ISO.
      В  мире персональных компьтеров IBM, большинство сетевых пр
ик-
 ладных программ используют интерфейс фирмы IBM - "NETBIOS", и, п
ока
 эти прикладные программы не будут заменены прикладными программа
ми,
 отвечающими стандартам ISO, пользователям будут по-прежнему необ
 ходимы  сети,  совместимые  с NETBIOS. К счастью, интерфейс NETB
IOS
 может быть добавлен к сетевым  продуктам  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 достигла совместимости  с  NETBI
OS
 без  добавления нового протокола, а NETBIOS фирмы CMC стал прозр
ач-
 ным интерфейсом для нормальных протоколов  ISO.  Даже  стандварт
ные
 прикладные  программы  ISO  осуществляют обмен данными с аппарат
ным
 робеспечением  CMC  через  интерфейс  NETBIOS.   ПЭВМ,   оснащен
ные
 NETBIOS, осуществляют коммуникацию с UNIX, VMS и другими система
ми,
 которые даже не осознают, что они "разговаривают" с ПЭВМ.
      Открывая  сведения о своей реализамции NETBIOS, корпорация 
CMC
 надеется убедить других продавцов принять тот же подход  в  реше
нии
 проблемы  добавления совместимости с NETBIOS к их сетевым продук
там
 ISO. Подобная стандартизация позволит продуктам NETBIOS-ISO,  пр
ед-
 лагаемым многими фирмами, осуществлять взаимное общение, - от эт
ого
 выиграют не только фирмы, но и, что более важно, пользователи се
тей.
             NETBIOS как интерфейс транспортного уровня
      Если NETBIOS служит в качестве  прозрачного  интерфейса  дл
 набора протоколов ISO, он дожен, конечно, взаимодействовать с од
ним
 или более протоколами. Вследствие того,  что  спецификация  NETB
IOS
 обеспечивает надежную отправку данных по логическим связям, он, 
ве-
 роятнее всего, должен взаимодействовать с транспортным уровнем I
SO.
 На  рис.  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 был выбран как интерфейс для уро
вня
 протоколов, находящегося выше транспортного уровня,  он  бы  тол
ько
 смог  обеспечить  взаимодействие  с  небольшим  подмножеством ус
луг
 уровня. Таким образом, оптимальным уровнем для  интерфейса  NETB
IOS
 является транспортный.
      Выбор  транспортного  уровня противоречит терминологии "Тех
ни-
 ческого руководства IBM по Сети ПЭВМ", где NETBIOS описан  как  
ин-
 терфейс  сеансового  уровня.  Это противоречие возникает вследст
вие
 того, что протокол сеансового  уровня,  с  которым  взаимодейств
ует
 NETBIOS  фирмы IBM, не является сеансовым протоколом ISO. В дейс
т-
 вительности, сеансовый уровень IBM не удовлетворяет общим критер
иям
 для  сеансового  уровня,  установленным моделью Соединения откры
тых
 систем (OSI).
      Внутри транспортного уровня, Класс 4 транспортного протокол
 (TP4) с установлением логического соединения наилучшим образом п
од-
 держивает сеансы NETBIOS. Так как сеансы NETBIOS должны быть над
еж-
 ными, а сам NETBIOS, будучи интерфейсом, не может осуществлять  
об-
 наружение ошибок и восстановление, NETBIOS потребует услуги обна
ру-
 жения ошибок и восстановления, которые обеспечивает TP4.
                           Имена NETBIOS
      Имена NETBIOS определяют компьтер, на котором  они  находят
ся,
 а,  так как одна машина может иметь несколько имен, они также оп
ре-
 деляют "точку доступа с сервису NETBIOS" в этой ЭВМ.  Если  NETB
IOS
 взаимодействует  с  транспортным  уровнем  ISO, то, по определен
ию,
 имена NETBIOS должны соответствовать адресам  ISO  на  транспорт
ном
 уровне. Каждое имя NETBIOS, следовательно, соответствует уникаль
ной
 паре:  Точка доступа к сетевой услуге (NSAP) и Точка доступа к
 транспортной услуге (TSAP). Интерфейс NETBIOS осуществляет транс
ля-
 цию между именами и парами NSAP-TSAP до того, как  послать  кома
нды
 NETBIOS транспортному протоколу ISO.
      Протокол  услуги местного каталога фирмы CMC, Протокол дина
ми-
 ческого поименования (DNP) фактически  выполняет  трансляцию.  Э
тот
 протокол  обеспечивает  услуги  имени для всех протоколов ISO фи
рмы
 CMC, а не только для интерфейса NETBIOS.
      Когда пользователь NETBIOS выдает команду ADD  NAME  или  A
DD
 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  постоянного имени узла, интерфейс про
сто
 копирует из своей собственной Подсетевой точки подключения  (SNP
A).
 Все  постоянные  имена  узлов  для данной ЛВС будут, следователь
но,
 иметь  одинаковые  Идентификаторы  полномочия  и  формата  (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  прозрачно  отображает сеансы в связях T
P4.
 Каждый сеанс имеет свою собственную  связь,  а  интерфейс  посыл
ает
 данные для сеанса непосредственно его связи.
      Когда пользователь NETBIOS просит интерфейс NETBIOS установ
ить
 сеанс, пользователь обычно обращается к  оконечным  точкам  данн
ого
 сеанса  с именами NETBIOS. Интерфейс должен, конечно, транслиров
ать
 эти имена в адреса сети (Точки NSAP и Точки TSAP) перед тем, как
 он
 сможет установить транспортную связь. Протокол динамического пои
ме-
 нования (DNP) фирмы CMC выполняет эту трансляцию.
      Если интерфейс установил транспортную связь, прикладная  пр
ог-
 рамма  может передавать данные по этой связи, выдавая команды SE
ND,
 CHAIN SEND, RECEIVE и RECEIVE ANY. В целом, эти команды просто  
по-
 сылают  и  получают  данные  в связи TP4; однако небольшие разли
чия
 между передачей данных NETBIOS и передачей данных TP4 существуют
      Наиболее очевидное из них заключается в том,  что  NETBIOS 
 не
 поддерживает  конценпцию TP4 "срочных данных". Следовательно, пр
ик-
 ладные программы, ограниченные стандартным интерфейсом NETBIOS, 
 не
 в  состоянии посылать TP4 срочные данные. Для прикладных програм
м,
 которые требуют применения срочных данных, фирма  CMC  разработа
ла
 расширения к NETBIOS. О них рассказывается в последующем разделе
      Второе различие между TP4 и NETBIOS состоит в небольших отк
ло-
 нениях от интерфейса NETBIOS, определенного в "Техническом руков
од-
 стве  по  Сети  ПЭВМ". Отправка данных, обеспечиваемая транспорт
ным
 уровнем ISO, является неподтвержденной услугой. Когда  пользоват
ель
 TP4  посылает данные, он может посчитать посылаемые данные, но T
P4
 не показывает, когда полученные данные  фактически  отправляются
  к
 удаленному пользователю. Как следствие этого, пользователь-отпра
ви-
 тель должен доверять 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. Когда пользователь  посылает  дейтаграмму,  интерфейс  NETB
IOS
 запрашивает, чтобы услуги имени преобразовали имя назначения в т
оч-
 ку NSAP и TSAP (точка доступа к сетевой и транспортной услуге,со
от-
 ветственно);  затем  интерфейс посылает дейтаграмму этой NSAP-TS
AP.
 Когда узел назначения получает дейтаграмму, он просит услуги име
ни
 преобразовать исходные NSAP и TSAP в сетевое имя отправителя. За
тем
 интерфейс отправляет дейтаграмму удаленному пользователю.
      Этот способ имеет два серьезных минуса, и, следовательно, и
н-
 терфейс  NETBIOS  фирмы  CMC не может применить его. Первый мину
с -
 неэффективность данного метода: он требует осуществления пяти се
те-
 вых  транзакций  для отправки одной дейтаграммы (этими транзакци
ями
 являются: запрос на обнаружение имени, ответ об обнаружении  име
ни,
 дейтаграмма, запрос на решение адреса, ответ о решении адреса).
      Данный метод, кроме того, недостаточно эффективно обрабатыв
ает
 групповые имена, - это  его  второй  недостаток.  Когда  приклад
ная
 программа направляет дейтаграмму групповому имени, этот способ п
от-
 ребует того, чтобы был идентифицирован каждый узел в групповом и
ме-
 ни  для того, чтобы дейтаграмма могла быть скопирована и отправл
ена
 каждому из этих узлов.
      В качестве альтернативы, интерфейс  NETBIOS  может  отправл
ять
 как широковещательное сообщение любую дейтаграмму и включать в д
ей-
 таграмму имена источника и назначения. Этот подход значительно у
ве-
 личивает производительность по сравнению с первым способом:  усл
уги
 имен не требуются, и, следовательно, каждой дейтаграмме будет со
от-
 ветствовать только одна сетевая транзакция.
      На первый взгляд может показаться, что это преимущество  из
че-
 зает, если все узлы в сети получают дейтаграмму. Но более деталь
ное
 обследование показывает, что это предположение неверно. Первый  
ме-
 тод  также  требует, чтобы все узлы обрабатывали одну сетевую тр
ан-
 закцию на дейтаграмму. Вместо самой дейтаграммы каждый узел  дол
жен
 обработать запрос на обнаружение имени.
      Фирма  CMC  использует  этот  второй способ в своем интерфе
йсе
 NETBIOS. Интерфейс помещает прикладную дейтаграмму, вместе с име
нем
 источника  и назначения и типом дейтаграммы, в Блоки данных серв
иса
 (услуги) (Service Data Unit, сокращенно SDU) транспортного прото
ко-
 ла  ISO  без установления логического соединения (CLTP), DIS 860
2.
 На рис.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 - копируются из местной N
SAP
 адаптера. Образец 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, прикладные пр
ог-
 раммы помещают специальную "подпись" в Блок управления сетью  (N
CB)
 NETBIOS. Эта подпись помещается в первые четыре байта поля CALLN
AME
 Блока управления сетю (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 в байтах с четырех до семи  в  поле  CALLNA
ME
 Блока управления сетью (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 позволяет прикладным программам выз
ы-
 вать друг друга путем непосредственного определения удаленных  N
SAP
 и  TSAP.  Обычно,  естественно,  NETBIOS  ожидает, чтобы приклад
ные
 программыв определили удаленное имя; затем он  использует  Прото
кол
 динамического  поименования для обнаружения имени этого адреса. 
Для
 того, чтобы непосредственно (напрямую) использовать Точки  NSAP 
 и
 TSAP,  прикладная  программа  снова  помещает  подпись  ISO  в п
оле
 CALLNAME Блока NCB. Следом за этой подписью она помещает  указат
ель
 на  ту NSAP, которую она вызывает, а затем указатель на TSAP, ко
то-
 рую она вызывает.
      Оба этих указателя также определяются смещениями и сегмента
 ми.  Указатель  NSAP  занимает байты с четвертого по седьмой в п
оле
 NCB_CALLNAME, а указатель TSAP - байты с восьмого по  одиннадцат
ый.
 Каждый  указатель указывает на индикатор длины, а сами байты NSA
P и
 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_CALLN
AME
 битами,  о которых говорилось выше. Четвертый наименее значимый 
бит
 обозначает конец передачи (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  - Очень широкомасштабная интеграция


Яндекс цитирования