NetBIOS, NetBEUI и Server Message Blocks
Опубликовано: 04.09.2018
NetBIOS, NetBEUI и Server Message Blocks
Несмотря на то, что TCP /IP является наиболее популярным стеком протоколов, функционирующим на Сетевом и Транспортном уровнях эталонной модели OSI , альтернатива ему все еще существует. NetBEUI ( NetBIOS Extended User Interface , расширенный пользовательский интерфейс сетевой BIOS ) это один из наиболее старых, но все еще использующихся протоколов для локальных сетей, и он продолжает оставаться прекрасным решением для сравнительно небольших сетей, так как издержки на его обслуживание меньше, чем требуемые для более комплексных протоколов.
NetBEUI был разработан в середине 1980-х, с целью предоставить сетевые транспортные услуги для программ, базирующихся на NetBIOS ( Network Basic Input /Output System , сетевая базовая система ввода/вывода). NetBEUI просто один из методов передачи данных NetBIOS по сети. Также возможна инкапсуляция информации NetBIOS при помощи протоколов TCP /IP или IPX .
Когда Microsoft начала вводить сетевые возможности в свои операционные системы, она остановила свой выбор на NetBEUI . Первоначально и Windows for Workgroups и Windows NT использовали NetBEUI в качестве протокола по умолчанию. Только позже Microsoft последовала за инициативой остальной сетевой индустрии и стала для передачи данных NetBIOS опираться на TCP /IP .
Причина выбора стека TCP /IP заключается в его возможностях взаимодействия. Протоколы были изначально разработаны для того, чтобы поддерживать обмен сообщениями между различными вычислительными платформами и операционными системами. Вдобавок, как только технологии локальных сетей стали глубже проникать в сферу обеспечения ведения бизнеса, недостатки NetBEUI отчетливо продемонстрировали его непригодность для чего-либо большего, чем небольшие сети рабочих групп.
Сегодня NetBEUI наиболее часто применяется в малых по размерам сетях Microsoft Windows , так как он обеспечивает хорошую производительность, фактически не требует поддержки (протокол является самоконфигурирующимся и самонастраивающимся) и использует сравнительно немного памяти. Несмотря на критику, ведущуюся в сетевых кругах, в случае, если устанавливается домашняя или небольшая офисная сеть, состоящая из компьютеров под управлением Windows , NetBEUI все еще остается прекрасным решением в качестве протокола.
Основной недостаток NetBEUI заключается в том, что он немаршрутизируемый и по большинству может применяться только в сетях, составляющих один домен коллизий. Последнее вызвано тем, что протокол для выполнения некоторых из своих основных функций полагается на широковещательные сообщения и не имеет возможности идентифицировать сеть, в которой расположена система. В следующих разделах рассматривается архитектура протокола NetBEUI и его совместное использование с NetBIOS и Server Message Blocks для обеспечения базовых сетевых услуг в сетях Windows .
NetBIOS
NetBIOS был разработан для того, чтобы предоставить стандартизованный программный интерфейс между программными приложениями и сетевым оборудованием и сделать более легким процесс переноса приложений с системы на систему. Интерфейс включает пространство имен, которое в операционных системах фирмы Microsoft до сей поры служит для идентификации компьютеров в сети. Имя компьютера, назначаемое Windows -системе во время установки операционной системы, в действительности является именем NetBIOS так же, как и имена доменов и рабочих групп.
Имена NetBIOS имеют длину 16 байтов. Последний байт задействуется для указания типа ресурса, который представляет имя. Первые 15 символов могут быть символами алфавита или цифрами. Пространство имен NetBIOS выполняет те же функции, что и IP -адреса, используемые стеком протоколов TCP /IP , и адреса сети и узла, присваиваемые протоколами IPX /SPX . Указанные адреса предоставляют собой уникальные идентификаторы для каждого компьютера в сети, исходя из чего, системы могут посылать однонаправленные сообщения непосредственно друг другу. По этой причине индивидуальные имена систем называются уникальными именами ( unique names ), в то время как имена NetBIOS , описывающие группы систем в целях обеспечения возможности осуществления групповой передачи, называются групповыми именами ( group names ).
Главное отличие между пространством имен NetBIOS и адресами TCP /IP и IPX /SPX заключается в том, что пространство имен NetBIOS плоское. Нет иерархии имен, делящей сеть на отдельные подсети. 32 бита, составляющие IP -адрес, разделяются на биты адреса сети и адреса узла, адреса IPX /SPX также изначально имеют аналогичное разбиение. В противовес этому, имя NetBIOS представляет собой просто имя и не содержит идентификационной информации о сети.
В связи с тем, что NetBEUI использует для взаимодействия с другими системами пространство имен NetBIOS , а пространство имен не имеет встроенного механизма для идентификации и адресации сетей, NetBEUI не может осуществлять адресное взаимодействие с системами в других сетях. Это единственная причина, по которой NetBEUI является немаршрутизируемым протоколом.
Кадр NetBEUI
Исходя из положения, что NetBIOS является программным интерфейсом приложения (API), а не протоколом, можно сделать логический вывод, что расширенный пользовательский интерфейс NetBIOS также не может быть протоколом. Операционные системы Windows рассматривают его именно в таком плане, и, тем не менее, применяют термин кадр NetBEUI (или иногда кадр NetBIOS, или что более часто NBF (NetBIOS frame)) для того, чтобы описать соответствующий своему названию действующий протокол, с помощью которого выполняется передача данных NetBEUI по сети.
NBF функционирует на Сеансовом, Транспортном и Сетевом уровнях эталонной модели OSI, хотя можно привести аргументы в пользу того, что NBF не относится к Сетевому уровню, поскольку он лишен способности к маршрутизации, которая в большой степени определяет функциональность отмеченного уровня. В Windows этот протокол применяется для регистрации имен NetBIOS систем, находящихся в сети, установления сеансов связи между ними и передачи данных, созданных несколькими различными протоколами Прикладного уровня и интерфейсами API. Наиболее важным API-интерфейсом является Server Message Blocks (SMB, блоки серверных сообщений) протокол передачи файлов и данных для принтеров, выделенных в совместное пользование.
В модели OSI функциональные возможности протокола NBF снизу стыкуются с интерфейсом NDIS, который обеспечивает универсальный. интерфейс к сетевому оборудованию. Услуги Канального уровня предоставляются кадром IEEE 802.2 Logical Link Control (LLC), который обрамляет сообщение протокола NBF. Кадр 802.2 для пакетов NBF содержит (шестнадцатеричное) значение F0 для точки доступа к службе назначения (DSAP) и точки доступа к службе источника (SSAP).
На своей вершине протокол либо непосредственно взаимодействует с интерфейсом NetBIOS, либо в системах Windows NT и выше с интерфейсом транспортного драйвера (TDI), который представляет собой уровень абстракций, лежащий между интерфейсом NetBIOS и протоколами Транспортного уровня.
Функции протокола NBF разделяются на несколько различных сервисов, которые иногда рассматриваются как отдельные протоколы. (Отсутствие определенного стандарта делает сложным составление их точного перечня.) Эти сервисы обеспечивают регистрацию и разрешение имен, доставку дейтаграмм без установления соединения, функции диагностики и мониторинга, а также доставку, основанную на сеансах. Все они имеют одинаковый формат базовых сообщений.
•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).
•1 C продолжение приема ( RECEIVE CONTINUE ).
•1F сессия активна (SESSION ALIVE).
Данные 1 (Data1) , 1 байт. Содержит необязательные данные, специфические для типа сообщения. Данные 2 (Data2) , 2 байта. Содержит необязательные данные, специфические для типа сообщения. Коррелятор передачи (Transmit Correlator) , 2 байта . Представляет собой шестнадцатеричное значение от 0001 до FFFF, используемое для связи запроса с ответом. Коррелятор ответа (Response Correlator) , 2 байта . Объявляет шестнадцатеричное число от 0001 до FFFF, которое указывает на значение, ожидаемое в поле коррелятора передачи в ответном сообщении. Имя назначения (Destination Name) , 16 байтов. Определяет имя NetBIOS системы, которой предназначено сообщение (не включается в пакеты, доставляемые в рамках сессии). Имя источника (Source Name) , 16 байтов. Идентифицирует NetBIOS имя локальной системы (не включается в пакеты, доставляемые в рамках сессии). Номер сессии назначения (Destination Number) , 1 байт. Указывает номер сессии системы-получателя (не включается в служебные пакеты дейтаграмм, диагностики и сервиса имен). Номер сессии источника (Source Name) , 1 байт. Указывает номер сессии системы-отправителя (не включается в служебные пакеты дейтаграмм, диагностики и сервиса имен). Необязательное поле (Optional) , переменная длина. Размещает в себе содержательные данные, передаваемые в рамках сессии и пакетами дейтаграмм (не включается в служебные пакеты диагностики и имен).Сообщения NBF подразделяют на четыре сервиса: службу имен, службу дейтаграмм, диагностический сервис и обслуживание сессий. Иногда они рассматриваются как отдельные протоколы. Эти службы описываются в следующих разделах.
Протокол управления именами
Служба имен, также называемая протоколом управления именами (NMP, Name Management Protocol), предоставляет для систем сети услуги по реги¬страции и разрешению имен. Во время загрузки компьютера в 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А и включает в себя имя системы, с которой нужно установить контакт, в поле имени назначения (Destination Name).
Если система не получает ответа на сообщение NAME QUERY, то она полагает, что имя в сети не существует. Любой компьютер, использующий объявляемое имя, обязан ответить однонаправленным подтверждением N AM E RECOGNIZED на каждое принимаемое сообщение NAME QUERY. Сообщение NAME RECOGNIZED идентифицируется значением 0Е в качестве кода команды. Поле имени назначения (Destination Name) содержит имя системы, которая создала сообщение NAME QUERY, а поле имени источника (Source Name) имя локальной системы.
Протокол транспортировки дейтаграмм
Помимо сообщений службы имен, NBF также поддерживает сервис транспортировки дейтаграмм, который обеспечивает доставку небольшого количества данных при помощи таких же ненадежных передач без установления соединения. Протокол SMB часто пользуется службой дейтаграмм для своих транзакций вида запрос/ответ.
Эта служба иногда называется UDP (User Datagram Protocol, протокол пользовательских дейтаграмм), что является не очень удачным названием, так как TCP/IP имеет на Транспортном уровне протокол с точно таким же названием (который преимущественно обеспечивает похожие услуги). В подавляющем большинстве случаев, если в документе встречается упоминание о UDP, то это относится к протоколу TCP/IP, а не его NetBEUI-эквиваленту.
Сообщения DATAGRAM, служащие для передачи данных UDP, имеют командный код 08 и не задействуют ни полей данных, ни полей корреляторов. Поле имени назначения (Destination Name) всегда содержит имя NetBIOS системы назначения, а поле имени источника имя отправителя. Необязательное поле (Optional) размещает в себе данные, предназначенные для получателя. Также существует сообщение DATAGRAM BROADCAST, применяемое для передачи всем системам в сети. Оно идентично сообщению DATAGRAM за исключением того, что значение в поле кода, идентифицирующего сообщение, равно 09, и не определено имя назначения.
Протокол диагностики и мониторинга
Протокол диагностики и мониторинга ( DMP , Diagnostic and Monitoring Protocol ) прямой аналог протокола SNMP в TCP /IP , применяется для сбора информации о функционировании систем в сети. Типичный обмен сообщениями DMP начинается с формирования системой сообщения STATUS QUERY (код команды 03) и передачи его по функциональному адресу NetBIOS .
В ответ на сообщение STATUS QUERY компьютер получателя создает сообщение STATUS RESPONSE (код 0 F), которое передается запрашивающей системе как однонаправленное.
Сервис DMP также включает два сообщения для прекращения сетевой трассировки, они имеют одинаковые названия. Сообщение Terminate Trace с опознавательным кодом 07 останавливает трассировку на удаленной системе, в то время как его одноименный близнец TERMINATE TRACE с кодом 13 завершает процесс отслеживания сообщений на обеих взаимодействующих системах. Интерфейс NetBIOS никогда не создает сообщений последнего типа, но распознает их, если они сгенерированы другим приложением.
Протокол управления сессией
Большая часть трафика NetBEUI , произведенная в сети Windows типичными сетевыми задачами, распределяется в рамках сессии между двумя машинами. Сессия имеет место, когда две системы устанавливают соединение до того момента, как в действительности начинается передача каких-либо данных приложения. Соединение гарантирует, что каждая из систем готова к приему и передаче данных, а также позволяет каждой из машин управлять потоком данных и подтверждать успешное завершение передачи. Протокол управления сессией ( SMP , Session Management Protocol ) предоставляет полнодуплексный, надежный сервис с установлением соединения между двумя системами NetBIOS .
Создание сессии
Процесс создания сессии между двумя машинами начинается с процедуры разрешения имени, описанной ранее в этой главе. Клиентский компьютер, желающий инициировать сессию, посылает всем системам NetBIOS в сети сообщение NAME QUERY , содержащее идентификатор сессии (то есть значение, отличное от 00) в поле Data 2. Сервер, которому предназначен запрос, отвечает сообщением NAME RECOGNIZED , которое включает его аппаратный адрес и оповещает о том, что он ожидает от отправителя дальнейших сообщений.
Перед последующим затем обменом сообщениями NBF две системы выполняют процедуру создания сессии на уровне LLC , которая состоит из передачи клиентом сообщения SABME ( Set Asynchronous Balance Mode Extended ) и ответа сервера в виде кадра ненумерованного подтверждения ( Unnumbered Acknowledgement ). Затем клиент отправляет сообщение RR ( Receive Ready ), свидетельствующее о том, что он готов к приему данных.
После того, как сессия на уровне LLC активирована, прежде чем система сможет начать передавать данные приложения, необходимо провести транзакцию установки сессии NBF. Этот процесс запускается посылкой клиентской системой серверу однонаправленного сообщения (с кодом 19) SESSION INITIALIZE.
В отличие от сообщений для других служб, сообщения SMP не содержат полей адреса назначения и адреса источника. Вместо этого они имеют 1- байтовые поля номера назначения (Destination Number) и номера источника (Source Number), представляющих собой уникальные идентификаторы, которые системы задействуют для обращения друг к другу. Каждый компьютер поддерживает свой собственный номер сессии.
В ответ на сообщение 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 аварийное завершение сессии (вследствие тайм-аута или по иным причинам).Протокол SMB
В некоторых случаях непосредственно сам кадр NBF является полезными данными пакета. Например, когда Windows-система осуществляет доступ к файлу, расположенному на диске другой системы, файл передается в кадрах данных NBF. Тем не менее, сообщения NBF могут также переносить сообщения протокола вышележащего уровня. Server Message Blocks (SMB, блоки серверных сообщений) это протокол Прикладного уровня, который редиректор Windows (модуль, отвечающий за отправку запросов приложений к определенным сетевым ресурсам) привлекает для выполнения множества задач по управлению файлами и аутентификации на удаленных системах. Например, перед копированием на локальный диск файла с сетевого диска, предоставленного в совместное пользование, две системы вовлекаются в обмен сообщениями SMB, в ходе которого проверяются права пользователя на доступ к ресурсу и создается сессия с общим ресурсом.
Сессия, учрежденная на Прикладном уровне протоколом SMB, не зависит от других сессий, рассмотренных ранее в этой главе: сессии NBF и сессии LLC. Все три процесса создания сессии должны быть завершены, прежде чем две сетевые Windows-системы смогут передавать данные приложения.
Сообщения SMB
Сообщения SMB не ограничены исключительно парным применением с NetBEUI, но они тесно связаны с NetBIOS. Когда сеть Windows использует в качестве сетевого протокола TCP/IP, кадры NetBT (NetBIOS через TCP/IP) обрамляют сообщения SMB. В сети NetBEUI сообщения SMB переносятся внутри следующих типов сообщений NBF:
DATAGRAM; DATAGRAM BROADCAST; DATA FIRST MIDDLE; DATA ONLY LAST.Существует несколько десятков сообщений SMB, распределенных в четыре основные категории.
Управление сессией. Предназначены для установления и разрыва соединения с выделенным для совместной работы ресурсом, расположенным на сервере. Доступ к файлам. Служат для доступа и управления файловой системой диска, предоставленного в совокупное пользование на удаленном сервере. Сервис печати. Задействуются для постановки задач печати, созданных локальными приложениями, в очередь на удаленном сервере. Сервис сообщений. Оказывает услуги по переносу сообщений между системами в сети.Каждое сообщение SMB включает в себя 1-байтовое поле кода, которое идентифицирует функцию сообщения.
Помимо кода команды, каждое сообщение содержит 1-байтовое поле Flags (флаги) и 2-байтовое поле Flags2 (флаги 2). Эти поля включают информацию о сообщении и возможностях системы, создавшей его, а также о том, было ли сообщение послано сервером в ответ на запрос клиента. Под возможностями системы подразумевается поддержка длинных имен файлов и расширенных атрибутов, в частности, различает ли система символы различных регистров в путях файлов.
Флаг, несущий информацию о том, является ли сообщение ответом, включен в структуру сообщения вследствие того, что не для каждой команды SMB существуют отдельные сообщения запроса и ответа. Система, получившая команду SMB, которая требует выполнения определенных действий, обычно отправляет ответ с тем же кодом команды, что и у исходного сообщения, и с какими-либо признаками успеха или неудачи завершения вызванной процедуры. Флаг ответа устанавливается тогда, когда нужно гарантировать, чтобы получатель этого сообщения ассоциировал его с предыдущим своим запросом.
Остальные поля сообщения варьируются в зависимости от его типа и роли.
Обмен сообщениями SMB
Сообщения SMB обеспечивают услуги сетевого взаимодействия для Windows-систем. Сами они не выполняют транзакции целиком. В ходе типичного процесса клиент/сервер в сети NetBEUI, такого как доступ с рабочей станции к файлу на диске, предоставленном в совместное использование, на различных этапах процедуры осуществляется обмен сообщениями LLC, NBF и SMB.