Мережі та системи зв'язку online
Відображення імен NetBIOS в мережах TCP / IP
Про пераціонние системи Microsoft Windows 95 і Windows NT надають користувачам набір простих і зручних засобів для спільного доступу до ресурсів один одного. При цьому немає необхідності використовувати виділений файл-сервер, централізовану систему безпеки і інші складні мережеві технології.
Зазначені системи - два представника великого сімейства, яке включає також Microsoft Windows for Workgroups, Microsoft LAN Manager for OS / 2, IBM LAN Server, PathWorks для ОС VMS корпорації Digital Equipment, SAMBA і LAN Manager для ОС UNIX (від компаній Hewlett-Packard, NCR, Santa Cruz Operation і ін.). Фірма Novell також пропонує ПЗ, що дозволяє серверам NetWare взаємодіяти з робочими групами на базі LAN Manager.
Стрижневими технологіями, які пов'язують ці системи разом, є протокол SMB (Server Message Blocks) і протокол NetBIOS-over-TCP / IP (NBT). Протокол SMB, що виконує рутинні операції з розділення файлів і принтерів, "невидимий" кінцевим користувачам, так як міжсистемними комунікаціями керують мережеві драйвери. Однак NBT неможливо "заховати" - в основному тому, що цей протокол добре працює тільки в локальних широкомовних мережах. Якщо не вжити відповідних попередніх заходів, доступ до віддалених мереж і систем і робота з ними при використанні NBT можуть бути значно ускладнені. Розглянемо різні варіанти реалізації служби NBT в ЛВС.
Чому NetBIOS погано працює у великих мережах
Концепція даної розробки допускала наявність в мережі всього декількох вузлів, і при цьому пристрої могли з'являтися і зникати випадковим чином (що характерно для персональних комп'ютерів). Тому найкращою реалізацією даної концепції представлялася можливість локалізації пристроїв за допомогою широкомовних запитів, а не застосування будь-якого роду централізованої реєстрації або розподіленої служби каталогів. Система NetBIOS була розроблена таким чином, щоб використовувати широкомовні повідомлення як єдиний засіб локалізації пристроїв. І ось по сьогоднішній день ми стикаємося з цим обмеженням.
Однак оскільки вузли NetBIOS посилають багато широкомовних повідомлень, то великі мережі, в яких використовуються мости, працюють незадовільно. На рис. 1 представлена невелика за розміром ЛВС, що складається з двох сегментів і використовує тільки широкомовні повідомлення.
У цих документах розглянуто ще один тип вузла - h-вузол, дія якого обернено дії m-вузла, а саме: спочатку виконується спрямований запит, а при невдачі використовуються широкомовні запити. Модель h-вузла застосовується мережевими клієнтами Microsoft за замовчуванням щоразу, коли при конфігуруванні клієнта вказано WINS-сервер.
Ще один метод розпізнавання імені - застосування WINS-серверів, які, як описано в RFC 1001 і 1002, по суті своїй є p-вузлами. Можна також використовувати DNS-сервери (служби доменних імен), хоча цей метод функціонально обмежений.
За допомогою рекурсивного пошуку NBT здійснює відображення імен до тих пір, поки не буде знайдений ресурс, який відповідає цьому імені. За замовчуванням мережевими клієнтами Microsoft виконайте таку послідовність дій (за умови, що кожен з цих механізмів доступний): NBT переглядає свій внутрішній кеш імен; NBT запитує відомі WINS-сервери; потім видається широковещательное повідомлення; далі NBT шукає файл LMHOSTS і, нарешті, видає запит DNS-серверів для розглянутого імені NetBIOS.
Якщо відповідність, не знайдено, то повідомлення про помилку типу "ім'я не знайдено" повертається з додатком NetBIOS. Для досягнення максимальної продуктивності необхідно так конфігурувати клієнтські програми, щоб найбільш часто зустрічаються NetBIOS-імена попередньо завантажувалися в кеш клієнта. Однак майте на увазі, що обсяг пам'яті клієнтського кеша досить малий і імена в ньому будуть часто "затирається", особливо якщо клієнти підключені до одного сервера. Це може привести до того, що в кожному разі будуть використовуватися широкомовні запити і запити до WINS-сервера. Розмір кешу можна збільшити, але тоді зменшиться доступний клієнтові обсяг пам'яті. Напевно, це найбільша прикрість, до якого привела благородна мета спроектувати NetBIOS для невеликих мереж.
База даних LMHOSTS
Ви повинні уважно ставитися до внесення записів в файл LMHOSTS. Причиною виникнення деяких найбільш часто зустрічаються проблем є неточне "з точки зору" системи призначення NetBIOS-імені для хоста. Наприклад, ім'я хоста FTP можна визначити просто як "FTPSERVER". В цьому випадку система призначення "побачить", що запит призначений іншому хосту NetBIOS, і проігнорує його.
Вам також може знадобитися визначити відображення імен сервісів NetBIOS, а не просто відображення імен хостів. Додатки для робочих груп можуть мати NetBIOS-імена, включаючи Lotus Notes, шлюзи SNA і ін. Оскільки NetBIOS не використовує номера портів або гнізда (sockets), як це роблять IPX або TCP / IP, його обмежений простір імен повинно бути здатне підтримувати безліч імен для кожної системи призначення. Наприклад, якщо на одній і тій же системі реалізовані міжмережевий інтерфейс SNA, ліцензійний сервер і додаток "клієнт-сервер", то кожен з цих сервісів повинен мати відмінне від інших NetBIOS-ім'я, яке визначає сам сервіс, а не тільки NetBIOS-ім'я робочої станції . Сервіс призначення не буде відповідати на запит додатка, якщо приходить ім'я точно не буде відповідати імені необхідного сервісу.
Приклад запису для застосування в файлі LMHOSTS виглядає точно так само, як ім'я робочої станції. При виконанні на одній робочій станції декількох додатків вам доведеться завести стільки ж записів в файлі LMHOSTS.
Згодом деякі фірми-виробники ПЗ стали привласнювати досить витончені NetBIOS-імена своїх сервісів, використовуючи для цього різні регістри, прогалини всередині імені або додаючи недруковані знаки з розширеного ASCII-набору.
Для визначення таких імен відповідне поле записи укладають в лапки. Крім того, якщо вам необхідно використовувати в імені шістнадцятковий знак, його має передувати префіксом \ 0х. Імена NetBIOS обмежені 15 знаками, тому шістнадцятиричні знаки слід розмістити на початку розширеного імені. Наприклад, запис для якогось сервісу могла б виглядати так: 127.1.1.1 "SNA Gateway1 \ 0х20" # NetBIOS-ім'я сервісу з шістнадцятковим знаком в кінці. У наведеному вище прикладі шістнадцятковий знак 20 буде поміщений в 16-й розряд NetBIOS-імені "SNA Gateway1".
Попереднє завантаження записів в кеш NBT
WINS-сервери можна конфігурувати і для обміну інформацією з іншими WINS-серверами, що дозволить вам мати копії ваших баз даних імен.
Ви також можете конфігурувати ваші ПК як повноважні (proxy) WINS-сервери, які відповідаючи на широкомовні повідомлення, тим не менш не будуть використані як чисто p-вузлові сервери. Коли клієнт, для якого режим WINS є недоступним, пошле широковещательное повідомлення, proxy-сервер видасть запит заздалегідь визначеному WINS-сервера. Потім результат запам'ятається в його локальному NBT-кеші і proxy-сервер відповість на кожний наступний запит NetBIOS-імені вузла (рис. 3). Оскільки більшість клієнтів видають багаторазові широкомовні повідомлення, то proxy-сервер WINS, взагалі кажучи, може реагувати на початковий запит перш, ніж настане тайм-аут для клієнтського широкомовного повідомлення. Запис міститься в кеші до закінчення терміну її дії або поки простір кешу не знадобиться для нових записів. У ПК обсяг пам'яті кешу зазвичай невеликий, тому в сильно завантаженої мережі не слід очікувати великих переваг.
Використання серверів DNS
На рис. 4 показано, як запити служби DNS для вузлів у віддалених доменах стають марними при використанні NBT, за винятком мереж, в яких на всіх клієнтах і серверах встановлена Windows NT 4.0.