Терминология:
Windows* - MS Windows 95, 98, NT 3.5x/4.
1.1. NetBIOS - это session-level интерфейс. Используется программами для общения over NetBIOS совместимых транспортных протоколов. Транспортные протоколы - это NetBEUI, TCP/IP, IPX/SPX. Cеть Windows* не живет без NetBIOS. Никогда. Ни при каких условиях. Даже под угрозой расстрела. Неважно, что там у вас написано в свойствах сетевого окружения - если есть это самое окружение, значит есть и NetBIOS. Он отвечает за логические имена компьютеров на сети и передачу данных между двумя компьютерами, установившими между собой сессию.
NetBIOS over TCP/IP называется NetBT.
1.2. NetBIOS names
NetBIOS name закрепляется за ресурсом - не за компьютером! - только за
ресурсом, имеет размер в 16 байт. Первые 15 - собственно имя, 16-й - тип
ресурса, (00-FF hex), типы стандартизованы.
Имена делятся на:
1.3. Name Resolution
Name Resolution в NetBIOS от рождения основано на broadcasts, что сильно осложняет жизнь уже в средних размеров сети - любой свитч[c2] broadcast'ы через себя не пропускает, и правильно делает[3]. Ранние версии NetBIOS'а умели пользваться для распознавания имен только
К версии NT 3.5 MS одумался и ввел улучшения. Сейчас NetBIOS умеет пользоваться
102.54.94.97 rhino #PRE #DOM:networking #net group's DC
102.54.94.102 "RTS \0x1c"[4] #special app server
102.54.94.123 popular #PRE #source server
102.54.94.117 localsrv #PRE #needed for the include
#BEGIN_ALTERNATE
#INCLUDE \\localsrv\public\lmhosts
#INCLUDE \\rhino\public\lmhosts
#END_ALTERNATE
Директивы (#PRE, #DOM, etc) описаны внутри lmhosts.sam.
1.4. Что бы хоть как-то управлять этим разнотравьем, вводится понятие NodeType для порядка регистрации и распознавания имен[5]:
B-node (Broadcast) |
Использует только broadcasts. |
P-node (Point-to-Point) |
Использует только WINS. Если WINS не работает, то ни регистрации, ни распознавания[c1]. |
M-node (Mixed) | Для регистрации использует broadcasts. Для распознавания использует broadcasts, но если не получает ответа, то переключается в P-node. |
H-node (Hybrid) | Пытается стать P-node; если WINS не работает, переключается в B-node. Переключается в P-node, как только находит WINS server. |
NodeType раздаются DHCP сервером либо (surprise, surprise!) выставляются в registry
По умолчанию (при сконфигурированном WINS server'e ) Windows* встает в H-node.
WINS.
2.1. WINS - Windows Internet Naming Service.Поля A и S - Active и Static, Version ID - уникальный номер, который используется MS WINS'ом при репликации - для поиска новых записей (репликация - процедура слияния баз нескольких WINS серверов).
WINS - в своей работе использует UDP -137 и 138 порт (и broadcast'ы - если поймает).
На сегодняшний день я знаю два WINS сервера - один из них поставляется с NT server, второй включен в пакет SAMBA. Какой из них использовать - дело вкуса; если хочется [псевдо]спокойной жизни, надо использовать сервер от MS. Упадет NT с WINS сервером - последствия для своего случая прикидывайте сами.
Если доверять продукции MS не хочется, то придется использовать samba, несмотря на ее недостатки. К недостаткам относятся два пункта:
Основная задача WINS server'а - уметь отвечать на вопрос - а какой адрес у сервиса "name".
Функции Name Registration, Refresh, and Release: Сервис грузится, шлет на WINS сервер пакет Registration. В ответ получает подтверждение ( различные ошибки и конфликты опускаю ) и время, в течение которого его регистрация действительна - TTL. Согласно описанию от MS через TTL/2 NT[6] (остальные клиенты могут делать refresh с другой частотой, но до истечения TTL) должна прислать Refresh - мол вот она я, жива. И снова получить TTL. И так до окончания работы, когда сервис должен послать пакет Release. Если TTL истек, а сервис Refresh не прислал, WINS server о нем забывает.
MS WINS server умеет реплицировать свою базу с другими MS WINS серверами.
Итак, с помощью WINS сервера можно получить адрес ресурса по имени "name". Но как увидеть список всех компьютеров в сети/домене/рабочей_группе? WINS на такие вопросы не отвечает - не обучен. Занимаются этим всяческие browser'ы. В каждой подсети есть master browser(domain\0x1d), backup browser, potential browser и preferred master browser, их в последнее время называют segment browsers ( изобретенными в MS терминами можно, наверное, библиотеку заполнить ).
Компьютеры, таким образом, разделяются на:
Неважно, что у вас в подсети/домене/рабочей_группе одна машина - она будет и master, и backup, и potential. На каждые 32 компьютера добавляется еще один backup browser. Master browser'ы занимаются тем, что обрабатывают broadcast'ы, которые раз в time=12 минут выдает каждый компьютер и складывают результаты в browsing lists глубоко внутри себя.
Если компьютер в течении time*3 признаков жизни не подает, master browser удаляет его из browsing list. Итого тайм-аут между выключением компютера и пропаданием его из neighborhood составляет 36 мин. - внутри одного сегмента. Если компьютер выключен "gracefully", browser (имеется в виду сервис computer browser) пошлет master browser'у соответствующее сообщение и будет вычищен из списков сразу.
В дополнение все master browser'ы периодически[8] анонсируют себя принадлежащими к группе \0x01\0x02__MSBROWSE__\0x02\0x01[9] в локальной подсетке - без использования WINS, broadcast'ом. В анонсе присутствуют имя домена и имя domain master browser'a. Master Browser'ы, получающие такие анонсы, хранят их в internal browse lists[10] вместе с именем компьютера, пославшего анонс.
Backup browser кэширует browsing lists у себя и инициирует перевыборы, если не может найти master browser.
Domain master browser составляет список имен master browser'ов на основании полученных от них Master Announcement frames, которые ему присылают сначала после победы на выборах, а затем каждые 12 (у самбы - 15) минут. На основании этого списка domain master browser раз в 15 минут опрашивает всех master browsers на предмет local browsing lists, соединяет полученное в domain browse list и раздает (по запросу, который раз в 12 минут) master browser'ам. Сами считайте, через сколько минут выключенный компьютер пропадет из browsing lists в остальных сегментах.
Свежезагрузившийся клиент шлет broadcast[11] на имя domain\0x1d. Master browser возвращает соответствующий список browser'ов, из коего списка клиент выбирает три сервера и, случайным образом образом из этих троих выбрав одного, шлет запрос. Результат появляется в network neighborhood'e. При обращении к компьютеру, нарисованному в Network Neighborhood идет запрос к WINS серверу о его адресе.
В NT за browser'енье отвечает сервис Computer Browser.
Кусок документации от samba - объяснение на пальцах того, как синхронизируются Browsing lists в подсетях, взято из файла browsing.txt; переводить мне его лень.
Итого, в сегментированной сети с Windows*-клиентами без WINS'а Browsing lists не работают. А поскольку слова "сеть работает" проверяются наличием соседских компьютеров в Network Neighborhood, то ...
Хотелось бы добавить пару слов о multihomed master browsers - у которых
более одной сетевой карты.
Собственно, MS их категорически не рекомендует.
Дело в том, что NT'шный browser отдает не полный browse list, а только ту его
часть, которая относится к подсети откуда пришел запрос (возможно, в
действительности значение имеет то, на какой адрес он пришел - негде
сейчас проверить). MS объясняет, что, мол, browser знать ничего не знает о
роутинге между подсетями, и поэтому отдавать чужую подсеть ему не с
руки.
Кое-как это лечится при помощи Q158487 - оставляем компьютер
browser'ом только в одном из сегментов. Если бедной кляче к тому же
посчастливилось быть PDC, то придется прописать в WINS (или в lmhosts на
potential browsers) static mapping типа multihomed для имени domain\0x1b с
адресом интерфейса из этого сегмента - это чтобы master browser'ы всегда
обращались по правильному адресу.
Самба всегда отдает объединенный browse
list, поэтому делать ее master browser'ом бывает очень чисто и сухо.
Уф. Комментировать такой подход я не в силах, но вот коротенькое резюме:
Все, что касается browsing lists, происходит, как это водится у MS, "автомагически". Влиять на эту политику я умею только одним способом - поубивав[12] сервис computer browser на всех NT в подсетке, кроме одной, это оставит ее local/backup master browser'ом, навсегда. Но как только эта единственная NT упадет, пропадет содержимое neighborhood.
Так что и этот подход на практике использовать нельзя...
Материалы для внеклассного чтения от MS: winswp, tcpipimp2, ntbrowse.
Предложения, пожелания, bugfixes(к тексту, не к MS) шлите мне.
Maxim Berlin, 31.01.2000.
Выношу благодарности за помощь в работе над этим материалом:
Александру
Калагову (ТЦ РТС),
Игорю Нестерову (ТЦ РТС),
Владимиру
Чухареву,
Vladimir Pastukhov,
Sergei V. Dubrov.
[1] За счет пункта a) NetBEUI остается самым быстрым и маленьким сетевым протоколом
[2] NetBIOS изначально находился в ROMе сетевых карт для писюковой сетки от IBM.
1. Не путай роутер и свитч. Далеко не всякий свитч режет броадкасты.
2. Обычным свитчом я называю железяку, работающую только на уровне MAC-адресов, т.е., также, как и старые добрые бриджи. Классические, первые свитчи - это просто многопортовые буферированные бриджи, они пересылают пакеты из-в сегмента в сегмент только на основании MAC-адреса фрейма (Ethernet, FDDI, и пр.). Они ничего не знают про .255 бродкаст (IP-level) - для них это такой же пакет, как и остальные. Если чуть вдаться в подробности, даже классический свитч, работающий на втором уровне, но имеющий достаточно мозгов внутри, может в принципе иметь возможность строить фильтры по различным полям принимаемых-передаваемых фреймов, т.е., его можно научить, например, зная структуру IP-пакета, упакованного в Ethernet-фрейм, откидывать бродкасты сетевого уровня. Из примеров таких железок - LanPlex2500 (сейчас - CorePlex2500) от 3Com.
Новые, современные и достаточно навороченные свитчи уже обычно могут работать с третьим уровнем - сетевым (те же VLAN-ы), вот на них уже действительно можно без приседаний в виде писания фильтров на птичьем языке машины а-ля Тьюринг работать с пакетами на уровне IP или IPX, например, в т.ч. устраивая no passaran для IP-бродкастов ;-). Хотя, с другой стороны, и сейчас выпускается масса дешевых свитчей фирмами типа D-Link, SMC и т.п., которые про сетевой уровень (и про VLAN-ы) ничего знать не знают.
Про канальный, сетевой и прочие уровни можно прочитать здесь: Протокол, интерфейс, стек протоколов. Модель ISO/OSI.
[3] Документация от MS всегда ставит проблему злобных роутеров на первое место. Роутеры, мол, не пропускают броадкасты. Вторым пунктом упоминают, что броадкаст должен быть обработан каждой машиной, имевшей счастье его словить, за что его роутеры и не пускают...
[4] Внимательно считаем пробелы между именем и типом. Тип должен быть 16-м.
[5] Я видел упоминание о "Microsoft-enhanced - Local LMHOSTS file or WINS proxies plus Windows Sockets gethostbyname() calls (using standard DNS and/or local HOSTS files) in addition to standard node types.", но живьем ее никогда не видел.
c1 Владимир Чухарев:
Мои эсперименты с node type на W95 (до OSR2) показывали, что p-type при отсутствии wins сваливается в b-type (по крайней мере начинает слать broadcast's). В отличии от h-type - необратимо. По этой причине им пользоваться просто не стоит никогда. И, если склероз мне не изменяет, именно p-type стоит по умолчанию на указанных w95 (при сконфигуренном wins и запрете быть броузером). Это было лет пять назад...
c3 Vladimir Pastukhov: Ключ IsDomainMasterBrowser на самом деле называется IsDomainMaster - документированные грабли.
[7] В его registry есть некий(не уточняется) ключ, который помогает ему выиграть на выборах титул Domain Master Browser'а. "This allows browsing to be effective when a domain spans multiple subnets." Не спрашивайте, чем оно будет эффективнее - не скажу. Не знаю.
[8] Написано - "periodically". Подозреваю, что либо раз в 12, либо раз в 15 минут.
[9] WINS server на запрос о таком имени всегда возвращает broadcast адрес соответствующей сети
[10] Понятия не имею, что это такое. Нашел только одно упоминание:": In addition, master browser servers receive these domain announcements to this name and maintain them in their internal browse list along with the announcer's computer name."
[11] "A client will broadcast to this name to get a list of browser servers from the Master Browser." Возможно, имелся в виду multicast...
Vladimir Pastukhov: Это действительно broadcast в терминах IP. Просто в неком поле указывается имя получателя - domain\0x1d. Пакет обрабатывается только теми, кто назвался таким именем, а это в данном случае master browser. Остальные получившие пакет его игнорируют. Все вместе MS называет "to broadcast a datagram toname". Еще бывает directed datagram - когда IP получателя есть конкретный IP адрес.
[12] Или запретив в registry. Чревато. Установка Option pack для NT server с выключенным computer browser оканчивается (не начавшись) сообщением "Cannot detect OS type".