NETBIOS, по определению
IBM, не стал сам по себе стандартом, хотя и принимается как таковой.
Предпринимаются попытки реализовать NETBIOS в других сетевых средах,
например, основанных на Протоколе управления транспортом/Межсетевом
протоколе (TСP/IP), или же основанных на Транспортных и Сетевых протоколах
Международной организации по стандартизации (ISO). Министерство обороны
США определило TCP/IP для Arpanet и теперь он широко используется
во многих коммерческих системах. Сетевые и транспортные протоколы
ISO несколько новее, и многие фирмы рассматривают их как настоящий
международный стандарт.
Протокол управления транспортом/Межсетевой
протокол (TCP/IP)
Предлагаемый ниже
материал представляет собой (в основном) Докладную записку, в которой
охарактеризована концепция и методология NETBIOS Internet. Вот список
фирм, которые в основу NETBIOS положили TCP/IP: Excelan, Ungermann-Bass,
3Com/Bridge, Syntax и Communication
Machinery Corporation.
[начало] [оглавление]
Статус Докладной записки
Докладная записка
определяет предложенный стандарт для сети Internet. Система, описываемая
Докладной запискрой, не отражает никакую из существующих реализаций
NETBIOS на основе TCP (Протокол управления транспортом), однако, проект
в значительной степени основывавется на предыдущих разработках (информация
о которых была предоставлена фирмами CMS/Syros, Excelan, Sytek и Ungermann-Bass).
[начало] [оглавление]
Введение
Докладная записка
описывает концепции и основные методы, используемые для реализации
NETBIOS на основе TCP (Протокол управления транспортом) и UDP (Протокол
пользовательских дейтаграмм). Приложение к Докладной записке, "Стандарт
протокола для услуги (сервиса) NETBIOS на основе транспорта TCP/UDP:
ДЕТАЛЬНАЯ СПЕЦИФИКАЦИЯ" содержит подробное описание форматов
пакетов, протоколов и определенных констант и переменных.
Услуга NETBIOS стала
главным механизмом для организации сети вычислительных машин. NETBIOS
обеспечивает независимый от фирмы-продавца интерфейс для PC IBM и
совместимых с ними систем. NETBIOS определяет программный интерфейс,
а не протокол: "официального" стандарта услуги NETBIOS не
существует. На практике, однако, версия IBM Сети ПЭВМ (IBM PC Network)
используется в качестве руководства. Данная версия описана в документе
N 6322916 компании IBM "Техническое руководство IBM по Сети ПЭВМ" (IBM PC Network Technical Reference).
Протоколы, поддерживающие
услуги NETBIOS, были построены на различном аппаратном обеспечении
и на основе различных протоколов. Для обеспечения взаимодействия NETBIOS
в Internet, Докладная записка определяет стандартный протокол, поддерживающий
услуги NETBIOS с использованием TCP и UDP.
В настоящее время
применение NETBIOS в основном ограничено ПЭВМ. Однако, вследствие
того, что более мощные ЭВМ лучше подходят для выполнения некоторых
прикладных программ NETBIOS (например, файловый процессор), данная
спецификация была построена таким образом, чтобы позволить осуществить
реализацию NETBIOS на любом типе системы, где может быть использован
набор протоколов TCP/IP (Протокол управления транспортом/Межсетевой
протокол).
Данный стандарт
определяет набор протоколов, поддерживающих услуги NETBIOS.
Докладная записка
описывает протоколы не столько как простую коммуникационную услугу,
включающую два объекта, сколько как распределенную систему, где задействовано
множество объектов, даже если они и не участвуют в качестве оконечной
точки какого-либо соединения NETBIOS.
Настоящий стандарт
не ограничивает и не определяет, каким образом эти услуги представлены
для прикладных программ. Тем не менее, считается желательным, чтобы
разработчики сохранили бы существующий интерфейс NETBIOS на компьютерах,
действующих под управлением операционных систем PC-DOS и MS-DOS.
[начало] [оглавление]
Принципы проектирования
Для разработки спецификации
были приняты следующие принципы проектирования. Большинство из них
типичны для процесса стандартизации любых протоколов; некоторые -
специфичны именно для NETBIOS.
1. Сохранение услуг NETBIOS. При отсутствии "официального"
стандарта для услуг NETBIOS, используется версия, содержащаяся в "Техническом
руководствке IBM по Сети ПЭВМ". NETBIOS лежит в основе большого
набора существующих прикладных программ. Представляется желательным
работать с этими прикладными программами в сетях TCP и расширить их
примененипе от ПЭВМ до более мощных рабочих ЭВМ. Для поддержки этих
прикладных пргограмм, NETBIOS на основе TCP должен точно соответствовать
услугам, предлагаемым существующими системами NETBIOS. NETBIOS в Сети
ПЭВМ IBM (IBM PC Network) имеет некоторые специфичные для данной реализации
характеристики. Настоящий стандарт не собирается жестко регламентировать
эти особенности.
2. Использование существующих разработок стандартов
протокола. Создание новых протоколов должно быть сведено к минимуму.
Существенным является то, что существующие стандарты, разумно сочетая
необходимую функциональность с достаточной производительностью работы,
должны всегда иметь приоритет перед новыми протоколами. При использовании
стандартного протокола, вносить в него изменения НЕЛЬЗЯ.
3. Сведение к минимуму количества опций. Стандарт NETBIOS
на TCP должен содержать минимальное число опций. Если они имеются,
эти опции должны быть спроектированы таким образом, чтобы устройства
с различными опциями могли бы взаимодействовать.
4. Устойчивость к ошибкам и сбоям. Сети NETBIOS обычно
работают в неконтролируемом режиме; машины включаются и выключаются
в сети через произвольные промежутки времени; программное обеспечение
используется пользователями, незнакомыми с сетями; часто эти пользователи
могут нарушить отладку сети. Несмотря на этот хаос, сети NETBIOS работают.
NETBIOS на TCP должен быть способен хорошо функционировать в подобной
среде. Ошибкоустойчивая работа не обязательно означает, что сеть защищена
от любых сбоев, как вызванных непроизвольно, так и в результате намеренных
действий пользователя.
5. Децентрализация управления. NETBIOS на TCP должен
работать, при необходимости, и при отсутствии централизированного
управления.
6. Возможность межсетевого взаимодействия. Предлагаемый
стандарт признает необходимость работы NETBIOS в наборе сетей, взаимосвязанных
посредством межсетевых шлюзов. Стандарт, однако, признает и тот факт,
что этот тип функционирования встречается реже, чем работа в ЛВС,
связанной посредством мостов между местными носителями.
7. Сведение к минимуму широковещательных операций.
Стандарт предполагает, что единственным типом широковещательных услуг
должны быть услуги, поддерживаемые UDP (Протоколом пользовательских
дейтаграмм). Групповые операции в любой форме должны быть исключены.
Несмотря на допустимость широковещательных операций, стандарт признает,что
некоторые администраторы сети МОГУТ неинтенсивно использовать широковещательные
сообщения, например, исключить отправку и прием широковещательных
сообщений для отдельных оабочих ЭВМ.
8. Реализация на существующих операционных системах.
NETBIOS на основе протокола TCP должен иметь возможность реализации
на распостраненных операционных системах, например, UNIX и VAX/VMS,
без сложных преобразований. Протоколы NETBIOS не должны нуждаться
в услугах, которые обычно не являются доступными в существующих в
настоящее время разработках TCP/UDP/IP (Протокол управления транспортом/Протокол
пользовательских дейтаграмм/Межсетевой протокол).
9. Сведение к минимуму необходимых протоколов. Определение
протокола должно описывать только минимальный набор протоколов, необходимых
для взаимодействия. Дополнительные элементы протоколов могут, впрочем,
потребоваться для увеличения производительности.
10. Максимальная эффективность. Чтобы быть полезным,
протокол должен действовать быстро.
11. Сведение к минимуму нововведений. Если существующий
протокол не в состоянии поддержать необходимую функцию, необходимо
внести в него небольшие изменения (это проще, чем разработать новый
протокол), - однако, число таких изменений должно быть минимально.
Поддерживаемые средства
Протокол, определяемый данным стандартом, позволяет
разработчику обеспечить все услуги NETBIOS, описанные в "Техническом
руководстве IBM по Сети ПЭВМ".
Следующие средства не входят в этот список:
- Переустановка (RESET);
- Статус сеанса (SESSION STATUS);
- Прерывание связи (UNLINK);
- Удаленная загрузка программы (RPL).
[начало] [оглавление]
Необходимые интерфейсы
и требуемые определения
Протоколы, описываемые
в данной Докладной записке, требуют взаимодействаия услуг со следующим:
- Протокол управления транспортом (TCP);
- Протокол пользовательских дейтаграмм (UDP).
Упорядочение байт,
условия адресации (включая адреса, используемые для широковещательных
и групповых сообщений) определяются последней версией:
- Assigned Numbers (Присвоенных номеров).
Дополнительные определения и ограничения содержатся
в:
- Межсетевом протоколе (IP);
- Подсетях Internet (internet Subnets).
[начало] [оглавление]
Соответсвующие протоколы и услуги
Построение протоколов,
описанных в Докладной записке, позволяет объединять в будущем следующие
протоколы и услуги. Однако, прежде чем это произойдет, для протоколов,
содержащихся в Докладной записке, равно как и для нижеприведенных
услуг и протоколов могут потребоваться некоторые добавления (расширения):
- Услуга "имя домена" (Domain Name Service);
- Протокол "Групповое сообщение Internet"
(Internet Group Multicast).
[начало] [оглавление]
Масштаб NETBIOS
"Масштабом
NETBIOS" является группа компьютеров, которым известно зарегистрированное
имя NETBIOS. Широковещательные и групповые операции с дейтаграммами
NETBIOS должны охватывать весь масштаб NETBIOS. Internet может поддерживать
множественные, непересекающиеся масштабы NETBIOS.
Каждый масштаб NETBIOS
имеет "идентификатор масштаба". Этим идентификатором является
символьная строка, отвечающая требованиям системы имен доменов к именам
доменов. ПРИМЕЧАНИЕ: Каждая разработка NETBIOS на TCP должна обеспечивать
механизмы для управления используемыми идентификаторами масштаба.
Управление идентификаторами масштаба предполагает наличие дополнительных
возможностей интерфейса NETBIOS, например, расширение интерфейса пользовательских
услуг и прочее (скажем, параметры отладки узла). Природа подобных
расширений не описывается настояшщей спецификацией.
[начало] [оглавление]
Оконечные узлы NETBIOS
Стандарт описывает три типа оконечных узлов:
- Широковещательные узлы (B-узлы):
- Двухточечные узлы (P-узлы);
- Узлы смешанного режима (M-узлы).
Любой адрес IP (Межсетевого
протокола) может быть ассоциирован только с одним экземпляром вышеприведенных
типов узлов. Без предварительной загрузки адресно-именных таблиц,
перед "участниками" NETBIOS стоит задача динамического распределения
взаимных ссылок. Это может быть осуществлено посредством широковещательного
или двухточечного обмена данными.
В-узлы используют
широковещательные сообщения в локальной сети для обмена данными с
одним или более реципиентов (получателей). Узлы Р и М используют Спецпроцессор
имен NETBIOS (NBNS) и Спецпроцессор распределения дейтаграмм NETBIOS
(NBDD) для этой же цели.
Оконечные узлы могут
быть скомбинированы по различным топологиям; в любых топологиях их
функции остаются прежними.
ПРИМЕЧАНИЕ: Рекомендуется
не использовать М и В-узлы в одном и том же масштабе. Масштаб NETBIOS
должен содержать либо только узлы В, либо только узлы Р и М.
[начало] [оглавление]
Широковещательные узлы
Широковещательные
(или В-) узлы осуществляют коммуникацию, используя комбинацию дейтаграмм
UDP (как широковещательных, так и направленных) и связей TCP. В широковещательной
области В-узлы могут свободно взаимодействовать друг с другом. Широковещательной
областью является отдельная "В-ЛВС" со связанными мостами
носистелями.
[начало] [оглавление]
Двухточечные узлы
Двухточечные (или
Р-) узлы осуществляют коммуникацию, используя только направленные
дейтаграммы UDP и сеансы TCP. Р-узлы не выполняют ни генерацию, ни
"прослушивание" (получение) широковещательных пакетов UDP.
Однако, эти узлы предлагают услуги широковещательных и групповых сообщений,
используя возможности, предоставляемые Спецпроцессором имен NETBIOS
и Спецпроцессором распределения дейтаграмм NETBIOS (NBNS и NBDD соответственно).
Двухточечные узлы основываются на спецпроцессоре имен и спецпроцессоре
распределения дейтаграмм; эти спецпроцессоры могут быть местными или
удаленными, - в любом случае Р-узлы работают одинаково. Узлы смешанного
режима
Узлы смешанного
режима (М-узлы) представляют собой Р-узлы, которые обладают некоторыми
характеристиками В-узлов. М-узлы используют как широковещательные,
так и направленные ("одноцелевые") сообщения. Широковещательные
сообщения используются для экономии времени ответа, основываясь на
предположении, что большинство ресурсов находятся скорее на местном
широковещательном носителе, чем где-либо в сети Internet. М-узлы основываются
на Спецпроцессоре имен и Спецпроцессоре распределения дейтаграмм (NBNS
и NBDD). Однако, если эти спецпроцессоры временно становятся недоступными,
М-узлы могут продолжать работать в ограниченном режиме.
[начало] [оглавление]
Вспомогательные спецпроцессоры
Стандарт описывает
два типа вспомогательных спецпроцессоров:
- узлы Спецпроцессора имен NETBIOS (NBNS);
- узлы Спецпроцессора распределения дейтаграмм NETBIOS (NBDD).
Узлы NBNS и NBDD невидимы для приклалдных
программ NETBIOS и являются частью основного механизма NETBIOS. Эти
спецпроцессоры (серверы) являются ядром работы Р- и М-узлов с именами
и дейтаграммами. Как NBNS, так и NBDD могут передавать часть своей
работы оконечному узлу Р или М, который запрашивает услугу.
Вследствие того,
что ответственность возлагается динамически, а узлы Р и М должны быть
подготовлены к приему управления от спецпроцессора NETBIOS, система
обычно совершенствует функцию спецпроцессора NETBIOS. Например,с расширением
протокола Групповых сообщений Internet (Internet Group Multicasting),
новые реализации Спецпроцессора распределения дейтаграмм NETBIOS (NBDD)
могут возлагать ответственность за распределение дейтаграмм NETBIOS
в полном объеме.
Взаимодействие различных
реализаций обеспечивается наложением ограничений на действие оконечных
узлов таким образом, чтобы они могли принимать полный диапазон приемлимых
ответов от NBNS и NBDD.
[начало] [оглавление]
Узлы спецпроцессора имен
Спецпроцессор имен
NETBIOS (NBNS) построен таким образром, чтобы обеспечить достаточную
гибкость управления именами NETBIOS. С одной стороны, NBNS может не
принимать полной ответственности, оставляя узлам Р и М т.н. "бюллетень",
куда информация об именах/ адресах заносится и удаляется свободно,
без ее оценки Спецпроцессором имен NETBIOS. С другой стороны, NBNS
может взять на себя полную ответственность за управление именами и
их оценку. Степень принимаемой Спецпроцессором имен ответственности
оценивается NBNS каждый раз, когда предоставляется заявка на имя.
Если Спецпроцессор имен NETBIOS (NBNS) не принимает на себя полное
управление, он возвращает запрашивающему узлу достваточное количество
информации, чтобы любой узел мог бы вызвать (определить) любого предполагаемого
владельца имени.
Возможность переносить
ответственность за управлениен именами между Спецпроцессором имен
NETBIOS и узлами Р и М позволяет администратору сети (или продавцу)
достичь разумного компромисса между простотой, надежностью и быстротой
действия Спецпроцессора имен NETBIOS (NBNS). Отдельный NBNS может
быть реализован как распределенный объект, например, Услуга "имя
домена" (Domain Name Service). Обнако, внутренняя структура обменов
данных не определяется Докладной запиской.
[начало] [оглавление]
Топологии
Узлы В, Р, М, а
также узлы NBNS и NBDD могуть быть скомпонованы различными путями.
Имеется три класса операций:
- Класс 0: только В-узлы;
- Класс 1: только Р-узлы;
- Класс 2: Р-узлы и М-узлы вместе.
На рисунках, приводимых
ниже, любой Р-узел может быть заменен любым М-узлом. Последствия подобной
замены будут объясняться вместе с каждым приводимым примером.
Местный масштаб
Масштаб NETBIOS
является местным: все объекты находятся внутри одной и той же широковещательной
области.
В-узлы
Местные операции
только с В-узлами являются наиболее распостраненными. Процедуры обнаружения
и регистрации имен используют механизмы широковещательных сообщений.
Масштаб NETBIOS ограничен размерами широковещательной области. Эта
конфигурация, показанная на рис. 7-1, не требует наличия вспомогательных
спецпроцессоров NETBIOS.
----------------- Широковещательная область -----------------------
! ! ! ! !
! ! ! ! !
! ! ! ! !
----- ----- ----- ----- -----
! В ! ! В ! ! В ! ! В ! ! В !
----- ----- ----- ----- -----
Рис. 7-1. В-узлы.
Р-узлы
Данная конфигурация
обычно используется, когда администратор сети хочет исключить широковещательные
операции. Данная конфигурация, как это показано на рис. 7-2, работает
также, как если бы она была в Internet. Здесь она приводится только
для того, чтобы показать ее удобство как средства ограничения использования
широковещательных соощений.
Замена одного или
более Р-узлов М-узлами не повлияет на работу ни Р-, ни М-узлов. Р-
и М-узлы смогут взаимодействовать друг с другом. Вследствие того,
что М-узлы используют широковещательные сообщения, общий объем широковещательных
операций возрастет.
----------------- Широковещательная область -----------------------
! ! ! ! ! !
! ! ! ! ! !
! ! ! ! ! !
----- ----- ----- ----- ----- -----
! Р ! ! Р ! !NB NS! ! Р ! !NB DD! ! Р !
----- ----- ----- ----- ----- -----
Рис. 7-2. Р-узлы.
ПРИМЕЧАНИЕ: NBNS - Спецпроцессор имен NETBIOS.
NBDD - Спецпроцессор распределения дейтаграмм
NETBIOS.
Комбинация В- и Р-узлов
Узлы Р- и В- не
взаимодействут друг с другом. Замена Р-узлов М-узлами позволит узлам
В и М взаимодействовать друг с другом.
Internet
Р-узлы
Р-узлы могут быть
разбросаны по разным местам в Internet, как показано на рис. 7-3.
Для поддержки имен и дейтаграмм NETBIOS им требуется NBNS и NBDD,
соотвественно. Масштаб NETBIOS определяется идентификатором масштаба
NETBIOS (имя домена), используемого различными Р- (и М-) узлами. Internet
может содержать многочисленные масштабы NETBIOS. Любой узел Р может
быть заменен любым узлом М, причем функции обоих типов узлов сохраняются.
Однако, в случае замены на М-узел увеличится объем широковещательных
операций в той широковещательной области, к которой этот узел относится.
-----
! P !
----- !
! ! -----
! !-----! Р !
! ! -----
! !
----- !----------! -------- ! -----
! P ! --------! Internet !-----! ШЛЮЗ !---------! Р !
----- !----------! -------- ! -----
! ! !
! ! ! -----
! ! !-----! Р !
! ! ! -----
! ! !
! ---------
! ! NB DD !
--------- ---------
! NB NS !
---------
Рис. 7-3. Р-узлы Internet.
Комбинация М- и Р-узлов
Как показано на
рис. 7-4, узлы Р и М могут использоваться в сочетании друг с другом.
При обнаружении местонахождения имен NETBIOS, М-узлы будут стремиться
найти скорее те имена, которые относятся к другим М-узлам в общей
широковещательной области, чем имена Р- или М-узлов где-либо еще в
сети.
ПРИМЕЧАНИЕ: В среде Internet комбинировать узлы В и
М не следует, иначе могут возникнуть непредсказуемые конфликтные ситуации
с именами NETBIOS.
-----
! P !
-----
!
!
!
!
----- !----------! --------
! P ! --------! Internet !-----! NBDD !
----- !----------! --------
! !
! !
! !
! !
! !
! ---------
! ! ШЛЮЗ !
--------- ---------
! NB NS ! !
--------- !
!
!
!
-----------------!Широковещательная область -----------------------
! ! ! ! ! !
! ! ! ! ! !
! ! ! ! ! !
----- ----- ----- ----- ----- -----
! М ! ! Р ! ! М ! ! Р ! ! М ! ! Р !
----- ----- ----- ----- ----- -----
Рис. 7-4. Р-узлы и М-узлы Internet.
[начало] [оглавление]
Общие способы взаимодействия
Ниже приводятся
некоторые общие способы взаимодействия между объектами.
ВЗАИМОДЕЙСТВИЕ ЗАПРОС/ОТВЕТ
Большинство типов
взаимодействия составляет взаимодействие между запросом, движущемся
в одном направлении, и последующим ответом, движущимся в другом направлении.
В тех ситуациях,
когда взаимодействие происходит в ненадежном транспорте (т.е. UDP
- Протокол пользовательских дейтаграмм), или когда запрос является
широковещательным, жесткой взаимосвязи или отношения один к одному
между запросом и ответом может и не быть.
В любом случае,
это более, чем один ответ, вырабатываемый на полученный запрос. В
то время, когда ответ ожидает, отвечающий объект может посылать одно
или более подтверждение приема с ожиданием.
ПОВТОРНАЯ ПЕРЕДАЧА ЗАПРОСОВ
Протокол пользовательских
дейтаграмм (UDP) является ненадежным механизмом отправки сообщений,
где пакеты могут быть утеряны, получены не в последовательности их
передачи, дублированы, кроме того, отправка может происходить со значительной
задержкой. Вследствие того, что протоколы NETBIOS интенсивно используют
UDP, они компенсируют недостаток надежности UDP дополнительными механизмами.
Каждый пакет NETBIOS
содержит всю необходимую информацию для его обраотки. Ни один из протоколов
не использует несколько пакетов UDP для передачи одиночного запроса
или ответа. Если требуется больше исформации, чем может поместиться
в один пакет UDP, например, когда узел типа "Р" хочет получить
от спецпроцессора NETBIOS всех владельцев группового имени, используется
связь TCP (Протокол управления транспортом). Следовательно, в протоколах
не произойдет сбой из-за нарушения последовательности отправки пакетов
UDP.
Для того, чтобы
исключить потерю пакета ответа или пакета запроса, каждая операция
запроса повторно передаст запрос, если ответ не будет получен в течение
определенного промежутка времени.
Операции с протоколами,
чуствительные к успешной передаче пакетов ответов, например, операции
обнаружения конфликтов с именами, защищены от дублирования пакетов
вследствие того, что они игнорируют последовательные пакеты с одной
и той же информацией NETBIOS. Так как никакое состояние в отвечающем
узле не ассоциируется с запросом, ответчик просто посылает подходящий
ответ, когда бы не прибыл пакет с запросом. Следовательно, дублирующиеся
или задержанные пакеты запросов игнорируются.
Для всех запросов,
если пакет ответа задерживается слишком долго, то посылается другой
пакет запроса. Второй пакет ответа, посылаемый "в ответ" на второй пакет запроса, эквивалентен дублирующемуся пакету. Следовательно,
протоколы проигнорируют второй полученный пакет. Если отправка ответа
задерживается до завершения операции запроса (успешной или нет), пакет
ответа будет проигнорирован.
ЗАПРОСЫ БЕЗ ОТВЕТОВ
Некоторые типы запросов
не имеют соответствующих ответов. Эти запросы называются "требованиями".
В целом, требование представляет собой запрос-приказание (императивный
запрос), которому получающий узел должен подчиниться. Однако, вследствие
того, что требования не подтверждаются, они применяются только в тех
ситуациях, когда при утере пакета требования произошло бы ограниченное
повреждение. Пакеты требований не передаются повторно.
ТРАНЗАКЦИИ
Взаимодействия между
парой объектов группируются в "транзакции". Эти транзакции
объединяют одну или более пару типа "запрос/ответ".
Идентификатор транзакции
Вследствие того,
что между парой объектов может происходить несколько одновременных
транзакций, используется "идентификатор транзакции". Инициатор
транзакции выбирает идентификатор, уникальный для данного инициатора.
Идентификатор транзакции перемещается вперед и назад при каждом взаимодействии
внутри данной транзакции. Партнеры по транзакции должны устанавливать
соответствие ответов и запросов, сравнивая идентификатор транзакции
и адрес IP (IP - Межсетевой протокол) партнера по транзакции. Если
соответствующий запрос не находится, ответ должен быть сброшен.
Для каждой транзакции
используется новый идентификатор. Генератором идентификатора транзакции
должен быть простой 16-битовый счетчик транзакций. Необходимости искать
и отфильтровывать дублирующийся идентификатор транзакции нет: вероятность
существования такой транзакции, чей "срок жизни" превышал
бы небольшую долю обычного циклического периода счетчика, чрезвычайна
мала. Применение адресов IP вместе с идентификатором транзакции значительно
сокращает вероятность сбоев, в том случае, если идентификатор транзакции
был бы использован повторно.
[начало] [оглавление]
Основания для TCP и UDP
Данная версия NETBIOS
на основе протоколов TCP (Протокол управления транспортом) использует
UDP (Протокол пользховательских дейтаграмм) для многих видов взаимодействий.
В будущем, такие взаимодейс твия могут происходить на основе связей
TCP (для увеличения эффективности, если несколько взаимодействий происходят
в течение короткого отрезка времени, или если трафик дейтаграмм NETBIOS
обнаружит,что прикладная програма использует дейтаграммы NETBIOS для
поддержки услуги, ориентированной на связь).
[начало] [оглавление]
Услуга сеанса NETBIOS
Услуга сеанса NETBIOS
начинается после того, как для требуемого имени было найдено один
или более адресов IP (IP - Межсептевой протокол). Эти адреса могли
быть получены с использованием транзакций запроса имени NETBIOS или
же других средств, например, таблица местных имен или кэш (сверхоперативная
память).
Транзакции, пакеты
и протоколы услуги сеанса NETBIOS одинаковы для оконечных узлов всех
типов. Они включают только направленный (двухточетный) обмен данными.
Услуга сеанса имеет три фазы.
[начало] [оглавление]
УСТАНОВЛЕНИЕ СЕАНСА.
Во время этой фазы
определяется адрес IP и порт TCP вызываемого имени, а с удаленным
партнером устанавливается связь TCP. СТАБИЛЬНОЕ СОСТОЯНИЕ. Во время
этой фазы происходит обмен сообщениями данных в сеансе. Может происходить
обмен "живыми" (keep-alive) пакетами, если участвующие в
таком обмене узлы конфигурированы (отлажены) подобным образом. ЗАКРЫТИЕ
СЕАНСА. Сеанс закрывается: это происходит тогда, когда одна из сторон
(в сеансе) закрывает его, либо когда один из партнеров прекратил работу.
Услуга дейтаграммы NETBIOS
Каждая дейтаграмма
NETBIOS имеет поименованный источник и назначение. Для передачи дейтаграммы
NETBIOS, услуга дейтаграммы должна выполнить операцию запроса имени
для того, чтобы узнать адрес IP и атрибуты имени назначения NETBIOS.
(Эта информация может храниться в кэш, чтобы избежать излишних расходов
при запросах имен для последующих дейтаграмм NETBIOS).
Дейтаграммы NETBIOS
передаются в пакетах UDP. Если размер дейтаграммы NETBIOS превосходит
размер отдельного пакета UDP, она может быть разбита на несколько
пакетов UDP.
Оконечные узлы могут
получать дейтаграммы NETBIOS, адресованные именам, владельцем которых
получающий узел не является. Подобные дейтаграммы должны сбрасываться.
Если это имя уникально, то источнику дейтаграммы NETBIOS посылается
пакет DATAGRAM ERROR (ОШИБКА ДЕЙТАГРАММЫ).
Разбивка дейтаграмм
Если заголовок и
данные дейтаграммы NETBIOS превышают максимальное количество данных
для одного пакета UDP, дейтаграмма NETBIOS перед передачей должна
быть разбита (расчленена).
Дейтаграмма NETBIOS
состоит из следующих элементов протокола:
- Заголовок IP размером 20 байт (минимум);
- Заголовок UDP размером 8 байт;
- Заголовок дейтаграммы NETBIOS размером 14 байт;
- Данные дейтаграммы NETBIOS.
Последний элемент
состоит из трех частей:
- Имя источника NETBIOS (255 байт максимум);
- Имя назначения NETBIOS (255 байт максимум);
- Пользовательские данные NETBIOS (512 байт максимум);
- Два поля имени находятся в закодированном формате второго уровня.
Максимальный размер
дейтаграммы NETBIOS - 1064 байт. Минимальный размер максимальной дейтаграммы
IP - 576 байт. Следовательно, дейтаграмма NETBIOS может не поместиться
в одну дейтаграмму IP, - тогда ее необходимо разбить. В сетях, отвечающих
требованиям или превышающих требования минимальной длины дейтаграммы
IP в 576 байт, дейтаграмма NETBIOS будет разбита на две. Протоколы
и форматы пакетов предусматривают разбивку на три и более частей.
Параметры конфигурации
узла
- В-УЗЛЫ:
- Уникальное постоянное имя узла.
- Используется ли Протокол групповых сообщений Internet (IGMP).
- Используемый широковещательный адрес IP.
- Необходимы ли "живые" (keep-alive) пакеты для сеанса NETBIOS.
- Используемая длина поля данных UDP (для управления разбивкой).
- Р-УЗЛЫ:
- Уникальное постоянное имя узла.
- Адрес IP Cпецпроцессора имен NETBIOS.
- Адрес IP (IP - Межсетевой протокол) Спецпроцессора распределения
дейтаграмм NETBIOS.
- Необходимы ли "живые" (keep-alive) пакеты для сеанса NETBIOS.
- Используемая длина поля данных UDP (для управления разбивкой).
- М-УЗЛЫ:
- Уникальное постоянное имя узла.
- Адрес IP Cпецпроцессора имен NETBIOS.
- Адрес IP (IP - Межсетевой протокол) Спецпроцессора распределения
дейтаграмм NETBIOS.
- Необходимы ли "живые" (keep-alive) пакеты для сеанса NETBIOS.
- Используемая длина поля данных UDP (для управления разбивкой).
- Используется ли IGMP.
- Используемый широковещательный адрес IP.
[начало] [оглавление]
Минимальное соответствие
Для того, чтобы
обеспечить взаимное соответствие разработок между фирмами-продавцами,
реализация на основе настоящей спецификации должна удовлетворять следующим
правилам:
А. Узел, предназначенный для работы только в широковещательной
области, должен отвечать характеристикам В-узла.
Б. Узел, предназначенный для работы только в Internet,
должен отвечать характеристикам Р-узла.
[начало] [оглавление]
МЕЖДУНАРОДНАЯ ОРГАНИЗАЦИЯ ПО СТАНДАРТИЗАЦИИ
(ISO)
Следующая информация,
касающаяся NETBIOS для Сетей Международной организации по стандартизации
(ISO Networks), была написана Стивеном Томасом из корпорации CMC (Соmmunication
Machinery Corp.) (США). Первоначально она была напечатана в журнале
"Computer Communication Review" (июль/август 1987г.).
[начало] [оглавление]
Введение
Набор протоколов,
определенный ISO, обещает обеспечить универсальное взаимодействие.
Сетевые продукты различных фирм-продавцов смогут взаимодействовать
друг с другом, а пользователи - компоновать различное оборудование
для более полного удовлетворения своих потребностей. К сожалению,
набор протоколов ISO еще не создан, и пользователи еще не могут использовать
все необходимые им сегодня прикладные программы ISO.
В мире персональных
компьтеров IBM, большинство сетевых прикладных программ используют
интерфейс фирмы IBM - "NETBIOS", и, пока эти прикладные
программы не будут заменены прикладными программами, отвечающими стандартам
ISO, пользователям будут по-прежнему необходимы сети, совместимые
с NETBIOS. К счастью, интерфейс NETBIOS может быть добавлен к сетевым
продуктам ISO. Когда продукт ISO включит в себя совместимый с NETBIOS
интерфейс, пользователи смогут работать как с прикладными программами
ISO, так и стандартными прикладными программами для ПЭВМ в одной и
той же сети.
Корпорация CMC включила
совместимый с NETBIOS интерфейс в свой продукт "Протокол технического
бюро" (Technical Office Protocol - сокращенно TOP) для ПЭВМ IBM,
и, вследствие популярности интерфейса NETBIOS,некоторые другие фирмы-продавцы
также будут предлагать интерфейсы NETBIOS для своих продуктов ISO.
Простейший способом
добавления совместимости с NERTBIOS в этот набор протоколов - определить
"протокол NETBIOS" на самом верхнем уровне данного набора.
Этот подход был использован группой фирм-продавцов, стандартизирующих
NETBIOS в сетях TCP/IP. Они определили новый протокол, который находится
над TCP в их сетевых продуктах.
Недостатком этого
метода является то, что новый протокол должен использоваться обеими
оконечными точками в связи. ПЭВМ с таким протоколом NETBIOS может
обмениваться данными с системой UNIX, например, только если система
UNIX работает со специальной программой, которая поддерживает протокол
NETBIOS, а использование этой специальной управляющей программы может
помешать нормальной работе сетевых прикладных программ UNIX.
Корпорация CMC устранила
эту проблему в своих продуктах ISO посредством определения интерфейса
NETBIOS для ISO, который служит только как интерфейс. Фирма CMC достигла
совместимости с NETBIOS без добавления нового протокола, а NETBIOS
фирмы CMC стал прозрачным интерфейсом для нормальных протоколов ISO.
Даже стандвартные прикладные программы ISO осуществляют обмен данными
с аппаратным робеспечением CMC через интерфейс NETBIOS. ПЭВМ, оснащенные
NETBIOS, осуществляют коммуникацию с UNIX, VMS и другими системами,
которые даже не осознают, что они "разговаривают" с ПЭВМ.
Открывая сведения о своей реализамции NETBIOS, корпорация CMC надеется
убедить других продавцов принять тот же подход в решении проблемы
добавления совместимости с NETBIOS к их сетевым продуктам ISO. Подобная
стандартизация позволит продуктам NETBIOS-ISO, предлагаемым многими
фирмами, осуществлять взаимное общение, - от этого выиграют не только
фирмы, но и, что более важно, пользователи сетей.
[начало] [оглавление]
NETBIOS как интерфейс транспортного
уровня
Если NETBIOS служит
в качестве прозрачного интерфейса для набора протоколов ISO, он дожен,
конечно, взаимодействовать с одним или более протоколами. Вследствие
того, что спецификация NETBIOS обеспечивает надежную отправку данных
по логическим связям, он, вероятнее всего, должен взаимодействовать
с транспортным уровнем ISO. На рис. 7-5 показано место интерфейса
NETBIOS в модели Соединения открытых систем (OSI).
----------------------------------------------
!Прикладной уровень ISO ! !
!------------------------ Прикладные !
!Уровень представл.ISO ! программы !
!------------------------ PC-DOS, не !
!Сеансовый уровень ISO ! являющиеся ISO !
Интерфейс __________>!--------------------------------------------!
NETBIOS >!--------------------------------------------!
! Транспортный уровень ISO !
!--------------------------------------------!
! Сетевой уровень ISO !
!--------------------------------------------!
! Канальный уровень ISO !
!--------------------------------------------!
! Физический уровень ISO !
!--------------------------------------------!
Рис. 7-5. Интерфейс NETBIOS и Модель Соединения открытых систем (OSI).
Для NETBIOS требуются
четыре различных типа сетевых услуг: общие услуги, услуги имени, услуги
сеанса, услуги дейтаграмм. Первые два типа услуг, услуги имен и общие
услуги, не соответствуют ни одному протоколу ISO, так что выбор уровня
протокола целиком зависит только от последних двух видов услуг. Вследствие
того, что сеансы NETBIOS должны быть надежными, NETBIOS должен взаимодействовать
с транспортным уровнем или более высоким уровнем.
Но NETBIOS не обеспечивает
интерфейс с услугами более высоких уровней, например, синхронизацией,
управлением активностью, управлением маркером.Если бы NETBIOS был
выбран как интерфейс для уровня протоколов, находящегося выше транспортного
уровня, он бы только смог обеспечить взаимодействие с небольшим подмножеством
услуг уровня. Таким образом, оптимальным уровнем для интерфейса NETBIOS
является транспортный. Выбор транспортного уровня противоречит терминологии
"Технического руководства IBM по Сети ПЭВМ", где NETBIOS
описан как интерфейс сеансового уровня. Это противоречие возникает
вследствие того, что протокол сеансового уровня, с которым взаимодействует
NETBIOS фирмы IBM, не является сеансовым протоколом ISO. В действительности,
сеансовый уровень IBM не удовлетворяет общим критериям для сеансового
уровня, установленным моделью Соединения открытых систем (OSI).
Внутри транспортного
уровня, Класс 4 транспортного протокола (TP4) с установлением логического
соединения наилучшим образом поддерживает сеансы NETBIOS. Так как
сеансы NETBIOS должны быть надежными, а сам NETBIOS, будучи интерфейсом,
не может осуществлять обнаружение ошибок и восстановление, NETBIOS
потребует услуги обнаружения ошибок и восстановления, которые обеспечивает
TP4.
[начало] [оглавление]
Имена NETBIOS
Имена NETBIOS определяют
компьтер, на котором они находятся, а, так как одна машина может иметь
несколько имен, они также определяют "точку доступа с сервису
NETBIOS" в этой ЭВМ. Если NETBIOS взаимодействует с транспортным
уровнем ISO, то, по определению, имена NETBIOS должны соответствовать
адресам ISO на транспортном уровне. Каждое имя NETBIOS, следовательно,
соответствует уникальной паре: Точка доступа к сетевой услуге (NSAP)
и Точка доступа к транспортной услуге (TSAP). Интерфейс NETBIOS осуществляет
трансляцию между именами и парами NSAP-TSAP до того, как послать команды
NETBIOS транспортному протоколу ISO.
Протокол услуги
местного каталога фирмы CMC, Протокол динамического поименования (DNP)
фактически выполняет трансляцию. Этот протокол обеспечивает услуги
имени для всех протоколов ISO фирмы CMC, а не только для интерфейса
NETBIOS.
Когда пользователь
NETBIOS выдает команду ADD NAME или ADD GROUP NAME, интерфейс NETBIOS
формулирует TSAP для имени и просит Протокол динамического поименования
(DNP) зарегистрировать определенное имя с этим TSAP. Так как NETBIOS
стыкуется с транспортным уровнем, имя NETBIOS не имеет точки доступа
к услуге сеансового уровня (SSAP) или уровня представления данных
(PSAP).
Когда пользователь
выдает команду DELETE NAME, интерфейс NETBIOS проверяет, имеет ли
определенное имя "активные" сеансы. Если нет, интерфейс
NETBIOS немедленно стирает это имя и просит Протокол динамического
поименования (DNP) "вычеркнуть" это имя. Если это имя имеет
активные сеансы, интерфейс NETBIOS просто помечает его соответствующим
образом. Только после закрытия всех сеансов, интерфейс NETBIOS просит
DNP "вычеркнуть" это имя.
Пользователи NETBIOS
могут по желаню использовать постоянные имена узлов вместо сетевых
имен. Постоянное имя узла состоит из 10 байт нулей, за которыми следует
6 байт, обозначающие имя узла ЭВМ. NETBIOS ISO фирмы CMC принимает
шесть ненулевых байт, становясь Подсетевой точкой подключения (SNPA
- Sub-network point of attachment) для компьтера, и выстраивает Точку
доступа к сетевой услуге (NSAP) из этой SNPA. Для остальных NSAP постоянного
имени узла, интерфейс просто копирует из своей собственной Подсетевой
точки подключения (SNPA). Все постоянные имена узлов для данной ЛВС
будут, следовательно, иметь одинаковые Идентификаторы полномочия и
формата (AFI - Authority and Format Identifiers), одинаковые Сетевые
идентификаторы (NIP - Network Identifiers), одинаковые Первичные подсетевые
идентификаторы (PSI - Primary Subnetwork Identifiers), суффиксы Точки
доступа к канальной услуге (LSAP) - "LSS" и суффиксы Точки
доступа к сетевой услуге (NSAP) - "NSS".
Интерфейс NETBIOS
также использует особую, обозначенную Точку доступа к транспортной
услуге (TSAP) для постоянных име узлов. Эта TSAP равна 2 байт, с шестнадцатиричной
величиной FE. На рис. 7-6 показан пример трансляции между постоянным
именем узла и адресом NSAP-TSAP. (Заметьте, что интерфейс NETBIOS
распознает и транслирует постоянные имена узлов; Протокол динамического
поименования (DNP) фирмы CMC не имеет представления о постоянных именах
узлов).
Если местная NSAP есть:
49 01 00 00 00 00 01 y1 y2 y3 y4 y5 y6 FE 00
постоянное имя узла:
00 00 00 00 00 00 00 00 00 00 x1 x2 x3 x4 x5 x6
преобразуется в:
NSAP - 49 01 00 00 00 00 01 x1 x22 x3 x4 x5 x6 FE 00
TSAP - FE FE
Рис. 7-6. Имя узла в преобразовании NSAP.
[начало] [оглавление]
Сеансовые услуги NETBIOS
Интерфейс NETBIOS
прозрачно отображает сеансы в связях TP4. Каждый сеанс имеет свою
собственную связь, а интерфейс посылает данные для сеанса непосредственно
его связи.
Когда пользователь
NETBIOS просит интерфейс NETBIOS установить сеанс, пользователь обычно
обращается к оконечным точкам данного сеанса с именами NETBIOS. Интерфейс
должен, конечно, транслировать эти имена в адреса сети (Точки NSAP
и Точки TSAP) перед тем, как он сможет установить транспортную связь.
Протокол динамического поименования (DNP) фирмы CMC выполняет эту
трансляцию.
Если интерфейс установил
транспортную связь, прикладная программа может передавать данные по
этой связи, выдавая команды SEND, CHAIN SEND, RECEIVE и RECEIVE ANY.
В целом, эти команды просто посылают и получают данные в связи TP4;
однако небольшие различия между передачей данных NETBIOS и передачей
данных TP4 существуют.
Наиболее очевидное
из них заключается в том, что NETBIOS не поддерживает конценпцию TP4
"срочных данных". Следовательно, прикладные программы, ограниченные
стандартным интерфейсом NETBIOS, не в состоянии посылать TP4 срочные
данные. Для прикладных программ, которые требуют применения срочных
данных, фирма CMC разработала расширения к NETBIOS. О них рассказывается
в последующем разделе. Второе различие между TP4 и NETBIOS состоит
в небольших отклонениях от интерфейса NETBIOS, определенного в "Техническом
руководстве по Сети ПЭВМ". Отправка данных, обеспечиваемая транспортным
уровнем ISO, является неподтвержденной услугой. Когда пользователь
TP4 посылает данные, он может посчитать посылаемые данные, но TP4
не показывает, когда полученные данные фактически отправляются к удаленному
пользователю. Как следствие этого, пользователь-отправитель должен
доверять TP4 в отправке данных.
Интерфейс NETBIOS,
однако, определяет, что команда SEND (или SEND CHAIN) не может быть
завершена, пока удаленный пользователь действительно не получит данные.
Вследствие того, что интерфейс NETBIOS фирмы CMC использует только
услуги, которые обычно доступны из TP4, он возвращает завершенные
команды SEND, когда TP4 показывает, что команды завершены. TP4 может
просигнализировать о завершении команд до того, как удаленный пользователь
фактически получит данные, то есть команда SEND может завершиться
до того, как завершится команда удаленного пользователя RECEIVE. Такое
поведение немного отличается от спецификации NETBIOS, но, кроме как
в чрезвычайных обстоятельствах, прикладные программы не замечают эту
разницу.
[начало] [оглавление]
Услуги дейтаграмм NETBIOS
Этот вид услуг является
наиболее сложным для реализации в сети ISO. Дейтаграммы NETBIOS, подобно
услугам дейтаграмм для других наборов протоколов, предназначены для
применения в качестве простого, быстрого и эффективного метода передачи
данных. Дейтаграммы NETBIOS, однако, используют сетевые имена, а услуги
имен редко когда бывают быстры, просты или эффективны.
Из-за этой базовой
несовместимости, все попытки реализовать дейтаграммы NETBIOS в пределах
ISO оканчивались компромиссами. Фирма CMC выбрала, вероятно, оптимальный
из компромиссов. О нем и будет рассказано ниже, как, впрочем, и о
других возможных решениях
этой проблемы.
Одно из незамысловатых
решений заключается в том, чтобы дейтаграммы NETBIOS использовали
бы транспортный протокол без установления логической связи ISO так
же, как сеансы NETBIOS используют TP4. Когда пользователь посылает
дейтаграмму, интерфейс NETBIOS запрашивает, чтобы услуги имени преобразовали
имя назначения в точку NSAP и TSAP (точка доступа к сетевой и транспортной
услуге,соответственно); затем интерфейс посылает дейтаграмму этой
NSAP-TSAP. Когда узел назначения получает дейтаграмму, он просит услуги
имени преобразовать исходные NSAP и TSAP в сетевое имя отправителя.
Затем интерфейс отправляет дейтаграмму удаленному пользователю.
Этот способ имеет
два серьезных минуса, и, следовательно, интерфейс NETBIOS фирмы CMC
не может применить его. Первый минус - неэффективность данного метода:
он требует осуществления пяти сетевых транзакций для отправки одной
дейтаграммы (этими транзакциями являются: запрос на обнаружение имени,
ответ об обнаружении имени, дейтаграмма, запрос на решение адреса,
ответ о решении адреса).
Данный метод, кроме
того, недостаточно эффективно обрабатывает групповые имена, - это
его второй недостаток. Когда прикладная программа направляет дейтаграмму
групповому имени, этот способ потребует того, чтобы был идентифицирован
каждый узел в групповом имени для того, чтобы дейтаграмма могла быть
скопирована и отправлена каждому из этих узлов. В качестве альтернативы,
интерфейс NETBIOS может отправлять как широковещательное сообщение
любую дейтаграмму и включать в дейтаграмму имена источника и назначения.
Этот подход значительно увеличивает производительность по сравнению
с первым способом: услуги имен не требуются, и, следовательно, каждой
дейтаграмме будет соответствовать только одна сетевая транзакция.
На первый взгляд
может показаться, что это преимущество изчезает, если все узлы в сети
получают дейтаграмму. Но более детальное обследование показывает,
что это предположение неверно. Первый метод также требует, чтобы все
узлы обрабатывали одну сетевую транзакцию на дейтаграмму. Вместо самой
дейтаграммы каждый узел должен обработать запрос на обнаружение имени.
Фирма CMC использует
этот второй способ в своем интерфейсе NETBIOS. Интерфейс помещает
прикладную дейтаграмму, вместе с именем источника и назначения и типом
дейтаграммы, в Блоки данных сервиса (услуги) (Service Data Unit, сокращенно
SDU) транспортного протокола ISO без установления логического соединения
(CLTP), DIS 8602. На рис.7-7 показан формат Блока данных услуги транпортного
уровня (TSDU) Транспортного протокола CLTP.
0 1 2 3 4 5 6 7
-----------------------------
! ! 0 - обычная,
1 байт ! Тип дейтаграммы ! 1- широковещательная
!---------------------------!
. .
16 байт . Имя источника .
!---------------------------!
. .
16 байт . Имя назначения .
!---------------------------!
до . .
512 байт .Данные пользователя NETBIOS.
-----------------------------
Рис. 7-7. Блок данных транспортной услуги протокола
CLTP дейтаграммы NETBIOS.
Для транслирования
этих дейтаграмм, фирма CMC применяет Точку назначения NSAP, которая
содержит широковещательный адрес уровня MAC (Управления доступом к
носителям) в качестве подсетевой точки подсоединения (SNPA). Все другие
поля Точки доступа к сетевой услуге (NSAP) - AFI, NID, PSI, LSS и
NSS - копируются из местной NSAP адаптера. Образец NSAP, которую могут
использовать услуги дейтаграмм NETBIOS, будет выглядеть как (в шестнадцатиричной
системе): 49 01 00 00 00 00 01 FF FF FF FF FF FF FE 00 Все дейтаграммы
NETBIOS также используют простую, хорошо известную Точку доступа к
транспортной услуге TSAP как для источника, так и для назначения.
Эта TSAP состоит из 2 байт: первый байт имеет величину ноль, а второй
- величину 81 (в шестнадцатиричнрой системе счисления).
Этот метод имеет один серьезный
минус - недостаток прозрачности. Включая имена источника и назначения
в Блок данных услуги транспортного протокола без установления логического
соединения, версия фирмы CMC требует, чтобы узел нзначения поддеорживал
интерфейс NETBIOS. К счастью, NETBIOS поддерживают только те узлы,
которые получают дейтаграммы. Интерфейс NETBIOS направляет все дейтаграммы
в определоенную TSAP, так что только те протоколы, которые "ожидают" дейтаграмм в этой Точке доступа к транспортной услуге (TSAP), будут
получать
дейтаграммы NETBIOS.
[начало] [оглавление]
Расширения ISO версии NETBIOS
Вследствие того,
что интерфейс NETBIOS не был специально создан для протоколов ISO,
он не обеспечивает оптимальное взаимодействие с этими протоколами.
Фирмой CMC это несоответствие было уменьшено как результат выбора
транспортного уровня для стыка; тем не менее, некоторые свойства протоколов
ISO не могут быть поддержаны стандартной версией NETBIOS.
В частности, прикладные
программы не имеют прямого доступа к точкам NSAP и TSAP для адресации;
они не могут посылать срочные данные и не могут явно показывать конец
текста в сообщении. Чтобы поддержать эти свойства, корпорация CMC
расширила стандартную версию интерфейса NETBIOS с помощью своих продуктов
TOP-NETBIOS.
Для получения доступа
к этим расширениям ISO, прикладные программы помещают специальную
"подпись" в Блок управления сетью (NCB) NETBIOS. Эта подпись
помещается в первые четыре байта поля CALLNAME Блока управления сетю
(NCB). Она состоит из байта с двоичной величиной ноль, за которым
следуют три байта с величинами (в коде ASCII): для заглавной "I,
заглавная "S" и заглавная "O". Так как стандартная
версия NETBIOS не позволяет именам начинаться с двоичной величины
ноль, прикладные программы, не являющиеся ISO, не будут использовать
имя, начинающееся с подписи ISO, а прикладная программа, не являющаяся
ISO, не может запросить эти расширения ISO.
Более того, если
прикладная программа ISO попытается использовать расширение ISO в
NETBIOS, не являющемся ISO, сетевой адаптер (в большинстве случаев)
просто "отвергнет" Блок управления сетью (NCB), как имеющий
неверное имя. Этот метод гарантирует, что только прикладные программы
ISO используют расширение ISO; кроме того, если прикладная программа
по ошибке попытается использовать сеть, не являющуюся ISO, то не будет
причинено никакого вреда.
Первое расширение
ISO позволяет прикладным программам определять Точку доступа к транспортной
услуге (TSAP), когда они регистрируют имя. Обычно, интерфейс NETBIOS
выбирает для них TSAP. Для того, чтобы определить TSAP, прикладная
программа помещает подпись ISO в байтах от нуля до трех в поле CALLNAME
Блока управления сетью (NCB) по команде NCB "ADD NAME".
Она также помещает указатель на определенную TSAP в байтах с четырех
до семи в поле CALLNAME Блока управления сетью (NCB). Этот указатель,
как и все в NETBIOS, состоит из смещения и сегмента. Четвертый байт
содержит наименее значимый байт смещения, пятый байт наиболее важен,
байт шесть содержит наименее значительный байт сегмента и седьмой
байт содержит наиболее значимый байт. Указатель указывает на структуру
Точки доступа к транспортной услуге (TSAP), первый байт которой содержит
длину TSAP. Байты, которые фактически составляют TSAP, следуют за
индикатором длины. По традиции ISO индикатор длины не включается в
подсчет. Остальная часть Блока управления сетью (NCB), включая само
имя, дублирует стандартную команду NETBIOS "ADD NAME". На
рис.7-8 показан образец расширенной версии ISO команды "ADD NAME".
---------------------
NCB_COMMAND ! 0x30 или 0xВ0 !
!-------------------!
NCB_RETCODE ! !
!-------------------!
NCB_LSN ! !
!-------------------!
NCB_NUM ! !
!-------------------!
NCB_BUFFER@ ! !
!-------------------!
NCB_LENGTH ! !
!-------------------!
! \0ISO ! -------- Длина
NCB_CALLNAME ! парам. TSAP---------! ! 2 ! TSAP
! ! ! !----- !
!-------------------! !---->!Байт 1! Величина
! Имя ! !------! TSAP
NCB_NAME !-------------------! !Байт 2!
! ! ! !
NCB_RTO !-------------------! --------
! !
NCB_STO !-------------------!
! необязательно !
NCB_POST@ !-------------------!
! 0 !
NCB_LANA_NUM !-------------------!
! !
NCB_CMD_CPLT ---------------------
Рис. 7-8. Расширенная версия ISO команды ADD NAME.
Второе расширение
ISO позволяет прикладным программам вызывать друг друга путем непосредственного
определения удаленных NSAP и TSAP. Обычно, естественно, NETBIOS ожидает,
чтобы прикладные программыв определили удаленное имя; затем он использует
Протокол динамического поименования для обнаружения имени этого адреса.
Для того, чтобы непосредственно (напрямую) использовать Точки NSAP
и TSAP, прикладная программа снова помещает подпись ISO в поле CALLNAME
Блока NCB. Следом за этой подписью она помещает указатель на ту NSAP,
которую она вызывает, а затем указатель на TSAP, которую она вызывает.
Оба этих указателя также определяются смещениями и сегментами. Указатель
NSAP занимает байты с четвертого по седьмой в поле NCB_CALLNAME, а
указатель TSAP - байты с восьмого по одиннадцатый. Каждый указатель
указывает на индикатор длины, а сами байты NSAP и TSAP немедленно
следуют за указателем длины. На рис. 7-9 показан образец расширенной
версии ISO команды CALL.
---------------------
NCB_COMMAND ! 0x10 или 0x90 !
!-------------------!
NCB_RETCODE ! !
!-------------------!
NCB_LSN ! !
!-------------------! -------- Длина
NCB_NUM ! ! ! 15 ! NSAP
!-------------------! ---->!------!
NCB_BUFFER@ ! ! ! !Байт 1! Величина
!-------------------! ! !------! NSAP
NCB_LENGTH ! ! ! !Байт 2!
!-------------------! ! --------
! \0ISO ! ! -------- Длина
NCB_CALLNAME ! парам. NSAP--------- ! 2 ! TSAP
! парам. TSAP--------- !----- !
!-------------------! !---->!Байт 1! Величина
! lclname ! !------! TSAP
NCB_NAME !-------------------! !Байт 2!
! тайм-аут ! ! !
NCB_RTO !-------------------! --------
! тайм-аут !
NCB_STO !-------------------!
! необязательно !
NCB_POST@ !-------------------!
! 0 !
NCB_LANA_NUM !-------------------!
! !
NCB_CMD_CPLT ---------------------
Рис. 7-9. Расширенная версия ISO команды CALL.
Третье расширение
ISO обеспечивает прикладные программы услугами срочных данных. Оно
также позволяет прикладной программе явно определять, установлен ли
(или нет) флаг конца передачи. Чтобы использовать эти средства, прикладная
программа помещает подпись ISO в SEND NCB. (Эти свойства не могут
быть использованы в команде SEND CHAIN).
В байте четыре поля
NCB_CALLNAME прикладная программа устанавливает особые биты для обозначения
того, использовать или не использовать срочные данные и устанавливать
или не устанавливать флаг конца передачи. Установив четвертый менее
значимый бит как один, (xxxx1xxx), прикладная программа выбирает опцию
установки флага конца передачи; ноль (xxxx0xxx) обозначает дополнительные
данные. Подобным же образом, пятый наименее значимый бит выбирает
срочную (xxx1xxxx) или обычную (xxx0xxxx) отправку данных. Для получения
срочных данных, прикладная программа должна поместить подпись ISO
в свои команды RECEIVE и RECEIVE ANY. Когда NETBIOS возвращает NCB,
он заполняет байт четыре поля NCB_CALLNAME битами, о которых говорилось
выше. Четвертый наименее значимый бит обозначает конец передачи (xxxx1xxx
или xxxx0xxx), а пятый наименее значимый бит обозначает срочные данные
(xxx1xxxx или xxx0xxxx)>
Подпись ISO также
сообщает интерфейсу NETBIOS, что прикладная программа может принять
расширенный код возврата "Сообщение прервано" (шестнадцатиричная
величина 0x07). Интерфейс NETBIOS использует этот нестандартный код
возврата, когда он начал перекомпоновку сообщения данных и получает
срочные данные до того, как закончилось сообщение. Очевидно, что NETBIOS
не может преобразовать срочные данные в текущее сообщение, поэтому
он возвращает NCB (Блок управления сетью), который использовался для
преобразования вместе с кодом возврата "Сообщение прервано".
Следующая команда RECEIVE или RECEIVE ANY, которая будет завершена,
будет содержать срочные данные, а затем следующий NXCB будет содержать
остальную часть первого сообщения.
Если прикладная
программа не помещает подпись ISO в свои команды RECEIVE или RECEIVE
ANY, и NETBIOS получает срочные данные, NETBIOS все равно попытается
отправить эти данные. Пока NETBIOS не начал процесс перекомпоновки
(преобразования) для этого NCB,он может поместить в пакет полученные
данные и возвратить завершенный Блок управления сетью (NCB). Прикладная
программа, естественно, не будет знать о срочных данных. Если процесс
перекомпоновки начался в NCB, интерфейс NETBIOS не сможет использовать
расширенный код возврата, и ему придется экстренно прервать сеанс.
В данной главе было рассказано
о взаимодействии протоколов NETBIOS - ISO, разработанном корпорацией
CMC. Вследствие прозрачности этого интерфейса, как прикладные программы
ISO, так и стандартные прикладные программы для ПЭВМ IBM могут использовать
NETBIOS в качестве интерфейса для сети. Стандартные прикладные программы
ПЭВМ в состоянии осуществлять коммуникацию друг с другом, а прикладные
программы ISO на ПЭВМ в состоянии обмениваться данными друг с другом
и с обычными прикладными программами ISO в других системах (системах
на основе неперсональных ЭВМ).
Предыдущая
страница | Следующая
страница
