NetBIOS

NetBIOS был разработан для того, чтобы предоставить стандартизованный программный интерфейс между программными приложениями и сетевым оборудованием и сделать более легким процесс переноса приложений с системы на систему. Интерфейс включает пространство имен, которое в операционных системах фирмы Microsoft до сей поры служит для идентификации компьютеров в сети. Имя компьютера, назначаемое Windows-системе во время установки операционной системы, в действительности является именем NetBIOS так же, как и имена доменов и рабочих групп.

Имена NetBIOS имеют длину 16 байтов. Последний байт задействуется для указания типа ресурса, который представляет имя. Первые 15 символов могут быть символами алфавита или цифрами. Пространство имен NetBIOS выполняет те же функции, что и IP-адреса, используемые стеком протоколов TCP/IP, и адреса сети и узла, присваиваемые протоколами IPX/SPX. Указанные адреса предоставляют собой уникальные идентификаторы для каждого компьютера в сети, исходя из чего, системы могут посылать однонаправленные сообщения непосредственно друг другу. По этой причине индивидуальные имена систем называются уникальными именами (uniquenames), в то время как имена NetBIOS, описывающие группы систем в целях обеспечения возможности осуществления групповой передачи, называются групповыми именами (groupnames).

Главное отличие между пространством имен NetBIOS и адресами TCP/IP и IPX/SPX заключается в том, что пространство имен NetBIOS плоское. Нет иерархии имен, делящей сеть на отдельные подсети. 32 бита, составляющие IP-адрес, разделяются на биты адреса сети и адреса узла, адреса IPX/SPX также изначально имеют аналогичное разбиение. В противовес этому, имя NetBIOS представляет собой просто имя и не содержит идентификационной информации о сети.

В связи с тем, что NetBEUI использует для взаимодействия с другими системами пространство имен NetBIOS, а пространство имен не имеет встроенного механизма для идентификации и адресации сетей, NetBEUI не может осуществлять адресное взаимодействие с системами в других сетях. Это единственная причина, по которой NetBEUI является немаршрутизируемым протоколом.

Кадр NetBEUI

Исходя из положения, что NetBIOS является программным интерфейсом приложения (API), а не протоколом, можно сделать логический вывод, что расширенный пользовательский интерфейс NetBIOS также не может быть протоколом. Операционные системы Windows рассматривают его именно в таком плане, и, тем не менее, применяют термин кадр NetBEUI (или иногда кадр NetBIOS, или что более часто — NBF (NetBIOSframe)) для того, чтобы описать соответствующий своему названию действующий протокол, с помощью которого выполняется передача данных NetBEUI по сети.

NBF функционирует на Сеансовом, Транспортном и Сетевом уровнях эталонной модели OSI, хотя можно привести аргументы в пользу того, что NBF не относится к Сетевому уровню, поскольку он лишен способности к маршрутизации, которая в большой степени определяет функциональность отмеченного уровня. В Windows этот протокол применяется для регистрации имен NetBIOS систем, находящихся в сети, установления сеансов связи между ними и передачи данных, созданных несколькими различными протоколами Прикладного уровня и интерфейсами API. Наиболее важным API-интерфейсом является ServerMessageBlocks (SMB, блоки серверных сообщений) — протокол передачи файлов и данных для принтеров, выделенных в совместное пользование.

В модели OSI функциональные возможности протокола NBF снизу стыкуются с интерфейсом NDIS, который обеспечивает универсальный. интерфейс к сетевому оборудованию. Услуги Канального уровня предоставляются кадром IEEE 802.2 LogicalLinkControl (LLC), который обрамляет сообщение протокола NBF. Кадр 802.2 для пакетов NBF содержит (шестнадцатеричное) значение F0 для точки доступа к службе назначения (DSAP) и точки доступа к службе источника (SSAP).

На своей вершине протокол либо непосредственно взаимодействует с интерфейсом NetBIOS, либо в системах Windows NT и выше — с интерфейсом транспортного драйвера (TDI), который представляет собой уровень абстракций, лежащий между интерфейсом NetBIOS и протоколами Транспортного уровня.

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

Длина (Length), 2 байта. Указывает длину поля заголовка NBF (включая поле длины).

Разделитель (Delimiter), 2 байта. Объявляет, что следующие за ним данные предназначены для интерфейса NetBIOS.

Команда (Command), 1 байт. Определяет функцию сообщения в соответствии с перечисленными далее кодами управляющих команд. Сообщения с кодами в диапазоне от 00 до 0Е передаются как кадры ненумерованной информации, в то время как коды команд, начиная с 0F и до 1F, пересылаются как протокольные блоки данных информационного формата LLC (I-format LPDU).

•00 — запрос добавления группового имени (ADD GROUP NAME QUERY).

•01 — запрос добавления имени (ADD NAME QUERY).

•02 — конфликтимен (NAME IN CONFLICT).

•03 — запрос статуса (STATUS QUERY).

•07 — прекращение трассировки (TERMINATE TRACE).

•08 — дейтаграмма (DATAGRAM).

•09 — широковещательная передача дейтаграммы (DATAGRAM BROADCAST).

•0A — запросимени (NAME QUERY).

•0D — ответ на запрос добавления имени (ADD NAME RESPONSE).

•0E — имяраспознано (NAME RECOGNIZED).

•0F — ответ на запрос статуса (STATUS RESPONSE).

•13 — прекращение (локальное и удаленное) трассировки (TERMINATE TRACE).

•14 — подтверждение приема данных (DATA АСК).

•15 — любой не последний сегмент (DATA FIRST MIDDLE).

•16 — последний сегмент (DATA ONLY LAST).

•17 — подтверждение сессии (SESSION CONFIRM).

•18 — завершение сессии (SESSION END).

•19 — инициализация сессии (SESSION INITIALIZE).

•1A — данные не приняты (NO RECEIVE).

•1B - ожиданиеприема (RECEIVE OUTSTANDING).

•1C — продолжение приема (RECEIVECONTINUE).

•1F — сессияактивна (SESSION ALIVE).

Данные 1 (Data1), 1 байт. Содержит необязательные данные, специфические для типа сообщения.

Данные 2 (Data2), 2 байта. Содержит необязательные данные, специфические для типа сообщения.

Корреляторпередачи (Transmit Correlator), 2 байта. Представляет собой шестнадцатеричное значение от 0001 до FFFF, используемое для связи запроса с ответом.

Корреляторответа (Response Correlator), 2 байта. Объявляет шестнадцатеричное число от 0001 до FFFF, которое указывает на значение, ожидаемое в поле коррелятора передачи в ответном сообщении.

Имя назначения (DestinationName), 16 байтов. Определяет имя NetBIOS системы, которой предназначено сообщение (не включается в пакеты, доставляемые в рамках сессии).

Имя источника (SourceName), 16 байтов. Идентифицирует NetBIOS имя локальной системы (не включается в пакеты, доставляемые в рамках сессии).

Номер сессии назначения (DestinationNumber), 1 байт. Указывает номер сессии системы-получателя (не включается в служебные пакеты дейтаграмм, диагностики и сервиса имен).

Номер сессии источника (SourceName), 1 байт. Указывает номер сессии системы-отправителя (не включается в служебные пакеты дейтаграмм, диагностики и сервиса имен).

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

Сообщения NBF подразделяют на четыре сервиса: службу имен, службу дейтаграмм, диагностический сервис и обслуживание сессий. Иногда они рассматриваются как отдельные протоколы. Эти службы описываются в следующих разделах.

Протокол управления именами

Служба имен, также называемая протоколом управления именами (NMP, NameManagementProtocol), предоставляет для систем сети услуги по регистрации и разрешению имен. Во время загрузки компьютера в Microsoft- сети система выполняет процедуру регистрации имени, разработанную для того, чтобы убедиться, что выделенное компьютеру имя NetBIOS уникально в пределах данной сети. Процесс разрешения имени запускается в случае, если система пытается получить доступ к ресурсам другой системы в сети. Из-за того, что имена NetBIOS не имеют постоянной связи с аппаратными адресами, используемыми для взаимодействия в локальных сетях, система, пытающаяся отправить однонаправленный трафик непосредственно другой системе, вначале должна выяснить ее аппаратный адрес.

Регистрация имен

Процедура регистрации имени в сети Windows стартует в процессе загрузки каждой из систем. Для того чтобы определить, не совпадает ли имя NetBIOS с именем другого компьютера в сети, система передает сообщение запроса на добавление имени (ADD NAME QUERY) по функциональному адресу NetBIOS (030000000001). Сообщение содержит значение кода команды 01 и имя NetBIOS системы в поле имени источника.

Другие системы NetBIOS в сети обязаны ответить, если им принадлежит такое же имя, как содержится в сообщении. Если после повторных попыток передающая система не получает ответов, имя считается зарегистрированным. В случае, когда другая машина имеет идентичное имя, она посылает отправителю однонаправленное сообщение ответа на запрос добавления имени (ADD NAME RESPONSE). Это сообщение отказывает первой системе в регистрации имени и вынуждает пользователя назначить ей другое имя.

Если система, пытающаяся зарегистрировать имя, примет сообщения ADD NAME RESPONSE от двух или более других систем (или если такое же имя уже существует как групповое и уникальное), она вырабатывает сообщение NAME IN CONFLICT и передает его по функциональному адресу NetBIOS. Такое же сообщение создается, когда система получает несколько ответов ADD NAME RESPONSE на сообщение ADD GROUP NAME QUERY или сообщения NAME RECOGNIZED от двух или более систем в ответ на NAME QUERY.

Разрешение имен

Процесс разрешения имени выполняется в том случае, если система пытается получить доступ к другой системе NetBIOS в сети. Прежде чем компьютер сможет отправить однонаправленные пакеты, он должен определить аппаратный адрес системы назначения. Чтобы осуществить это, компьютер генерирует сообщение NAME QUERY, которое передает по функциональному адресу NetBIOS. Данное сообщение соответствует управляющему коду 0А и включает в себя имя системы, с которой нужно установить контакт, в поле имени назначения (DestinationName).

Если система не получает ответа на сообщение NAME QUERY, то она полагает, что имя в сети не существует. Любой компьютер, использующий объявляемое имя, обязан ответить однонаправленным подтверждением NAME RECOGNIZED на каждое принимаемое сообщение NAME QUERY. Сообщение NAME RECOGNIZED идентифицируется значением 0Е в качестве кода команды. Поле имени назначения (DestinationName) содержит имя системы, которая создала сообщение NAME QUERY, а поле имени источника (SourceName) — имя локальной системы.

Протокол транспортировки дейтаграмм

Помимо сообщений службы имен, NBF также поддерживает сервис транспортировки дейтаграмм, который обеспечивает доставку небольшого количества данных при помощи таких же ненадежных передач без установления соединения. Протокол SMB часто пользуется службой дейтаграмм для своих транзакций вида запрос/ответ.

Эта служба иногда называется UDP (UserDatagramProtocol, протокол пользовательских дейтаграмм), что является не очень удачным названием, так как TCP/IP имеет на Транспортном уровне протокол с точно таким же названием (который преимущественно обеспечивает похожие услуги). В подавляющем большинстве случаев, если в документе встречается упоминание о UDP, то это относится к протоколу TCP/IP, а не его NetBEUI-эквиваленту.

Сообщения DATAGRAM, служащие для передачи данных UDP, имеют командный код 08 и не задействуют ни полей данных, ни полей корреляторов. Поле имени назначения (DestinationName) всегда содержит имя NetBIOS системы назначения, а поле имени источника — имя отправителя. Необязательное поле (Optional) размещает в себе данные, предназначенные для получателя. Также существует сообщение DATAGRAM BROADCAST, применяемое для передачи всем системам в сети. Оно идентично сообщению DATAGRAM за исключением того, что значение в поле кода, идентифицирующего сообщение, равно 09, и не определено имя назначения.

Протокол диагностики и мониторинга

Протокол диагностики и мониторинга (DMP, DiagnosticandMonitoringProtocol) — прямой аналог протокола SNMP в TCP/IP, применяется для сбора информации о функционировании систем в сети. Типичный обмен сообщениями DMP начинается с формирования системой сообщения STATUSQUERY (код команды 03) и передачи его по функциональному адресу NetBIOS.

В ответ на сообщение STATUSQUERY компьютер получателя создает сообщение STATUSRESPONSE (код 0F), которое передается запрашивающей системе как однонаправленное.

Сервис DMP также включает два сообщения для прекращения сетевой трассировки, они имеют одинаковые названия. Сообщение TerminateTrace с опознавательным кодом 07 останавливает трассировку на удаленной системе, в то время как его одноименный близнец TERMINATETRACE с кодом 13 завершает процесс отслеживания сообщений на обеих взаимодействующих системах. Интерфейс NetBIOS никогда не создает сообщений последнего типа, но распознает их, если они сгенерированы другим приложением.

Протокол управления сессией

Большая часть трафика NetBEUI, произведенная в сети Windows типичными сетевыми задачами, распределяется в рамках сессии между двумя машинами. Сессия имеет место, когда две системы устанавливают соединение до того момента, как в действительности начинается передача каких-либо данных приложения. Соединение гарантирует, что каждая из систем готова к приему и передаче данных, а также позволяет каждой из машин управлять потоком данных и подтверждать успешное завершение передачи. Протокол управления сессией (SMP, SessionManagementProtocol) предоставляет полнодуплексный, надежный сервис с установлением соединения между двумя системами NetBIOS.

Создание сессии

Процесс создания сессии между двумя машинами начинается с процедуры разрешения имени, описанной ранее в этой главе. Клиентский компьютер, желающий инициировать сессию, посылает всем системам NetBIOS в сети сообщение NAMEQUERY, содержащее идентификатор сессии (то есть значение, отличное от 00) в поле Data2. Сервер, которому предназначен запрос, отвечает сообщением NAMERECOGNIZED, которое включает его аппаратный адрес и оповещает о том, что он ожидает от отправителя дальнейших сообщений.

Перед последующим затем обменом сообщениями NBF две системы выполняют процедуру создания сессии на уровне LLC, которая состоит из передачи клиентом сообщения SABME (SetAsynchronousBalanceModeExtended) и ответа сервера в виде кадра ненумерованного подтверждения (UnnumberedAcknowledgement). Затем клиент отправляет сообщение RR (ReceiveReady), свидетельствующее о том, что он готов к приему данных.

После того, как сессия на уровне LLC активирована, прежде чем система сможет начать передавать данные приложения, необходимо провести транзакцию установки сессии NBF. Этот процесс запускается посылкой клиентской системой серверу однонаправленного сообщения (с кодом 19) SESSION INITIALIZE.

В отличие от сообщений для других служб, сообщения SMP не содержат полей адреса назначения и адреса источника. Вместо этого они имеют 1- байтовые поля номера назначения (DestinationNumber) и номера источника (SourceNumber), представляющих собой уникальные идентификаторы, которые системы задействуют для обращения друг к другу. Каждый компьютер поддерживает свой собственный номер сессии.

В ответ на сообщение SESSION INITIALIZE вторая система создает сообщение SESSION CONFIRM, которое и завершает инициализацию сессии.

Поддержка сессии

Во время периодов отсутствия активности задействованные в сессии компьютеры передают сообщения SESSION ALIVE для того, чтобы убедиться, что другая система все еще доступна и может принимать данные. Сообщение SESSION ALIVE имеет значение кода команды 1F. Все последующие поля не используются.

Передача данных

После создания сессии может начаться передача данных посредством сообщений NBF, которые могут переносить данные, сформированные протоколами вышележащего уровня (таким как SMB), а могут и не делать этого. Например, когда один компьютер соединяется с другим для того, чтобы скопировать файлы с сервера на локальный диск, системы оперируют кадрами NBF для передачи реальных данных. Если же из приложения Windows открывается файл на сетевом диске, то система применяет сообщения SMB (переносимые в кадрах NBF) для доступа к диску и передачи файла.

Тип кадров NBF, задействованных для передачи данных, зависит от их количества. Когда копируется файл, который может уместиться в одном сообщении, передающая система отправляет данные в сообщении DATA ONLY LAST. Когда файл разбивается на множество пакетов по причине того, что он слишком велик по сравнению с размером кадра или размером буфера передачи принимающего компьютера, то все сегменты доставляются в кадрах DATA FIRST MIDDLE за исключением последнего сегмента, который помещается в кадр DATA ONLY LAST.

Отправитель требует от получателя сообщение RECEIVE CONTINUE в том случае, если пакет содержит первый сегмент, отправленный в течение сессии, или если отправитель получил ответ NO RECEIVE во время предыдущей передачи сообщения. Если предыдущая передача была завершена, и за время ее выполнения от принимающей системы не поступило ответов NO RECEIVE, то отправитель не требует уведомления RECEIVE CONTINUE.

Поле Data2 представляет собой индикатор ресинхронизации со значением 0001 в случае, если это первый кадр DATA FIRST MIDDLE, следующий за получением сообщения RECEIPT OUTSTANDING (которое свидетельствует о способности получателя принять большее количество данных, следующих за сообщением NO RECEIVE). Это позволяет получателю повторно синхронизировать передаваемую последовательность с этим кадром для того, чтобы избежать проблем с передачей последующих пакетов.

Получатель кадра DATA ONLY LAST должен подтвердить его прием, ответив отправителю одним из следующих управляющих кадров:

DATA АСК;

NO RECEIVE;

RECEIVE OUTSTANDING;

DATA FIRST MIDDLE или DATA ONLY LAST (с поддержанной возможностью передачи подтверждения вместе с данными).

Сообщение DATA АСК (код 14) представляет собой одиночный кадр, который не делает ничего, кроме подтверждения корректного приема сообщения DATA ONLY LAST.

Сообщение RECEIVE CONTINUE создается системой, получившей кадр DATA FIRST MIDDLE, в котором восьмой бит поля Data1 имеет значение 1, свидетельствующее о том, что отправитель требует передачи ответа. Сообщение RECEIVE CONTINUE служит как подтверждение принятой до сего момента информации и указывает, что данные могут передаваться и дальше. Само сообщение идентифицируется кодом 1C и имеет незаполненные поля данных.

Когда система получает кадр DATA FIRST MIDDLE или DATA ONLY LAST, который заполняет ее буфер приема, она вырабатывает сообщение NO RECEIVE (с кодом 1А).

Как только отправитель получает сообщение NO RECEIVE, он останавливает передачу до тех пор, пока от принимающей системы не поступит сообщение RECEIVE OUTSTANDING (код 1В). Оно свидетельствует о том, что в буфере приема принимающей системы есть место, и отправитель может продолжить пересылку с байта, следующего сразу после последнего байта, прием которого был подтвержден, определенного в поле Data2.

Завершение сессии

Когда клиентская система хочет завершить сессию с сервером, она передает сообщение SESSION END с отличительным кодом 18. Поле Data1 этого сообщения не заполняется, а поле Data2 содержит описание причины, по которой сессия прекращается. Возможны следующие условия:

00 — нормальное завершение сессии (например, вызванное командой приложения);

01 — аварийное завершение сессии (вследствие тайм-аута или по иным причинам).