Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
ПРОТОКОЛИ IPX, SPX, NETBIOS.
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Телекомунікації
Інформація про роботу
Рік:
2002
Тип роботи:
Методичні вказівки до лабораторної роботи
Предмет:
Телекомунікаційні мережі
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
Національний Університет «Львівська політехніка»
Кафедра «Телекомунікації»
ПРОТОКОЛИ IPX, SPX, NETBIOS.
Методичні вказівки до лабораторних робіт з курсу
«Телекомунікаційні мережі ч.І»
Для студентів спеціальності
«Інформаційні мережі зв’язку»
Львів 2002
« ПРОТОКОЛИ IPX, SPX, NETBIOS ». Методичні вказівки до лабораторних робіт з курсу «Телекомунікаційні мережі ч.І» для студентів спеціальності «Інформаційні мережі зв’язку. Львів 2002. 18.
Автори: к.т.н. доц. Павликевич М.Й.
ст. викладач Костів О.Л.
асистент Кирик М.І.
Рецензент: професор д.т.н. Тимченко О.В.
У лабораторних роботах розглянуто принципи роботи протоколів IPX, SPX, NETBIOS.
Методичні вказівки розглянуто на засіданні кафедри «Телекомунікації» Національного університету «Львівська політехніка» від______2002р. протокол №____.
Вступ
Передача пакетів даних між робочими станціями без підтвердження – це тип зв’язку між робочими станціями на рівні датаграм (datagram). Рівень датаграм відповідає мережевому рівню (Network Layer) семирівневої моделі OSI.
Що ж означає “передача без підтвердження”? Це означає , що не гарантується доставка пакета від передаючої станції до приймаючої. В результаті, наприклад, перевантаження мережі або по інших причинах приймаюча сторона може так і не дочекатись призначеного їй пакета даних. При чому, що характерно для рівня датаграм, передаюча сторона так і не взнає , отримала приймаюча сторона пакет, чи не отримала.
Більш того, на рівні датаграм не гарантується також, що приймаюча сторона отримає пакети в тій послідовності , в якій вони посилаються передаючою станцією.
Для чого потрібна така передача даних , яка не гарантує доставки? Однак програми , які обмінюються даними , можуть самі організувати провірку. Наприклад , приймаюча програма може сама посилати підтвердження передаючій програмі що пакет даних отримано.
Протокол передачі даних IPX – міжмережевий протокол передачі пакетів (Internetwork Packet Exchange) – використовується в мережевому програмному забезпеченні Novell і є реалізацією рівня датаграм. Протокол NETBIOS, розроблений фірмою IBM, також може працювати на рівні датаграм.
Багато задач в мережі можна вирішити на рівні датаграм, тому виділимо багато уваги протоколам IPX і NETBIOS.
Одна з переваг рівня датаграм – можливість посилки пакетів даних одночасно всім станціям в мережі. Якщо ж для програм потрібна гарантована доставка даних, можна використати протокол більш високого рівня – рівня сеанса зв’язку.
На рівні сеансів зв’язку (Session Layer) дві робочі станції перед початком обміна даними встановлюють між собою канал зв’язку – обмінюються пакетами спеціального виду. Після цього починається обмін даними.
На рівні сеансів зв’язку при потребі виконуються повторні передачі пакетів даних, які з різних причин “не дійшли” до адресата. Крім цього гарантується , що приймаюча станція отримає пакети даних саме в цьому порядку , в якому вони були передані.
При використанні рівня сеансів зв’язку неможливо організувати “широкомовну” передачу пакетів одночасно всім станціям – для передачі даних необхідно організувати канал зв’язку між однією і другою станцією. Отже в процесі передачі даних можуть брати участь лише дві станції.
Як і слідувало очікувати, в мережевому програмному забезпеченні Novell рівень сеансів зв’язку реалізований як надбудова над рівнем датаграм. На базі протокола IPX реалізований протокол SPX – протокол послідовної передачі пакетів (Sequenced Packet Exchange Protocol).
Протокол NETBIOS реалізує рівень датаграм і сеансовий рівень. В мережі Novell є емулятор протокола NETBIOS. Цей емулятор використовує протокол IPX для реалізації як рівня датаграм , так і сеансового рівня.
Мережева адреса складається з декількох компонент . Це номер мережі, адреса станції в мережі, індентифікатор програми на робочій станції – сокет.
Номер мережі (network number) – це номер сегмента мережі (кабельного господарства), який визначається системним адміністратором при установці Novell NetWare. Не плутайте цей номер з внутрішнім номером мережі файл-сервера. Нагадаємо, якщо в одному сегменті є два файл-сервера NetWare то вони оба мають однаковий номер мережі, але різні внутрішні номера мережі. Якщо в спільній мережі є мости, кожна окрема мережа, яка підключена через міст повинна мати свій унікальний номер мережі.
Адреса станції (node address) – це число яке є унікальним для кожної робочої станції. При використанні адаптерів Ethernet унікальність забезпечується виробником мережевого адаптера (адреса станції записана в мікросхемі постійного запам’ятовуючого пристрою, яка знаходиться всередині самого адаптера). Для адаптерів ArcNet адресу станції потрібно виставляти за допомогою перемикачів або перемикачів на платі мережевого адаптера. Встановлюючи в мережі адаптери ArcNet, потурбуйтесь щоби всі вони мали в мережі різні адреса.
Спеціальна адреса FFFFFFFFFFFFh використовується для посилки пакета даних всім станціям даної мережі одночасно. Пакет з такою адресою нагадує відкритий лист опублікаваний в пресі.
Ідентифікатор програми на робочій станції - сокет (socket) – число яке використовується для адресації конкретної програми, яка працює на станції. В середовищі мультизадачних операційних систем, до яких можна віднести OS/2 і Microsoft Windows на кожній робочій станції в мережі одночасно можуть бути запущені декілька програм. Для того щоб послати дані конкретній програмі, використовується ідентифікація програм за допомогою сокетів. Кожна програма , яка бажає передавати чи приймати дані по мережі, повина отримати свій унікальний для даної робочої станції, ідентифікатор – сокет.
Лабораторна робота № 1
Мета роботи: Ознайомлення зі структурою і принципом роботи протоколу IPX . Реалізація системи клієнт-сервер за допомогою протокола ІРХ.
Теоретичні відомості
Першим комунікаційним протоколом, реалізованим в операційному середовищі NetWare, був протокол IPX (Internetwork Packet Exchange). Він використовувався виключно для обміну даними між робочими станціями і серверами NetWare. IPX являє собою не вимагаючий підключення протокол, реалізований на основі протоколу IDP (Internetwork Datagram Protocol) Xerox Network System (XNS). Хоч IPX - це “рідний” протокол NetWare, деякі незалежні розробники також використовують його як комунікаційний протокол.
IPX використовується для передачі і отримання пакетів інформації між робочими станціями і серверами. Така передача даних є негарантованою в тому значенні, що IPX не передбачає підтвердження успішного отримання пакету цільовим адресатом. Однак, він дозволяє визначити, чи був пакет переданий.
Протокол IPX надає можливість програмам, запущеним на робочих станціях, обмінюватись пакетами даних на рівні датаграм тобто без підтвердження.
В мережі Novell NetWare найбільш швидка передача даних при найбільш економічному використанні пам’яті реалізується саме протоколом IPX. Протоколи SPX і NETBIOS зроблені на базі IPX і тому потребують додаткових ресурсів. Тому починати програмування для локальних мереж краще саме з протокола IPX.
Якщо на робочій станції використовується операційна система MS-DOS, функції потрібні для реалізації протокола , реалізуються резидентними програмами ipx.com або ipxodi.com, які входять в склад мережевої оболонки робочої станції мережі Novell NetWare.
Для того щоби навчитись складати програми, які можуть передавати дані по мережі з використанням протоколу IPX, необхідно познайомитися зі структурою пакета IPX і навчитись користуватись функціями IPX, які реалізовані в рамках мережевої оболонки робочої станції. Спочатку познайомимось зі структурою пакета IPX, а потім з функціями.
Формат пакета IPX
Формат пакетів які передаються по мережі на рис 1.
Рис. 1. Структура пакета IPX
Пакет можна розділити на дві частини – заголовок і дані. Всі поля з рис.1, крім останнього (Data), становлять заголовок пакета. Заголовок пакета виконує роль, що і конверт звичайного листа – там міститься адреса призначення, зворотня адреса і деяка службова інформація.
Особливістю формата пакета є те що всі поля заголовка містять значення в перевернутому форматі тобто по молодшому адресау записується старший байт даних, а не молодший , як це прийнято в процесорах фірми Intel. Тому перед записом значень в багатобайтні поля заголовка потрібно виконати відповідні перетворення.
Робота з драйвером IPX/SPX
Перше що повинна зробити програма, яка бажає працювати в мережі з протоколом IPX чи SPX, - перевірити встановлений драйвер відповідного протокола. Потім потрібно отримати адресу виклику цього драйвера – точку входа API (Application Programm Interface – інтерфейс для додатків). В подальшому програма викликає драйвер за допомогою команди міжсегментного виклику по адресі точки входа API драйвера IPX/SPX.
Точка входу API драйвера IPX/SPX
Для того щоб перевірити завантажений драйвер IPX, необхідно завантажити в регістр AX значення 7А00h і викликати мультиплексне переривання INT 2Fh.
Якщо після повернення з переривання в регістрі AL буде значення FFh, драйвер IPX завантажений. Адреса точки входу для виклика АРІ драйвера при цьому буде знаходитися в регістровій парі ES:DI
Якщо ж вміст регістра АL після повернення з переривання INT 2Fh буде відмінний від FFh , то драйвер IPX не завантажений. Це значить, що в даній робочій станції не завантажені резидентні програми ipx. exe або ipxodi. exe, які забезпечують API для роботи з протоколами IPX і SPX.
Прийом і передача пакетів даних
Розглянемо тепер процедуру прийому пакетів даних засобами IPX.
Прийом і передачу пакетів виконує мережевий адаптер, працюючий з використанням переривань. Деякі мережеві адаптери працюють з пам'яттю через канал прямого доступу DMA. Переривання від мережевого адаптера-обробляє драйвер мережевого адаптера. Наприклад, в операційній системі MS-DOS для адаптерів, сумісних з адаптером Novell NE2000 в складі Novell NetWare постачається драйвер ne2000.com, реалізований у вигляді резидентної програми.
Прикладні програми не працюють напряму з драйвером мережевого адаптера. Всі свої запити на прийом і передачу пакетів вони спрямовують драйверу IPX (програма ipx. exe або ipxodi. exe), що, у свою чергу, звертається до драйвера мережевого адаптеру.
Для прийому або передачі пакета прикладна програма повинна підготувати пакет даних, сформувавши його заголовок, і побудувати так званий блок керування подією ЕСВ (Event Control Block). У блоці ЕСВ задається адресна інформація для передачі пакета, адресу самого переданого пакета в оперативній пам'яті і деяка інша інформація.
Підготовивши блок ЕСВ, прикладна програма передає його адресу відповідній функції IPX для виконання операції прийому або передачі пакета.
Функції IPX, які приймають або передають пакет, не виконують очікування завершення операції, а відразу повертають керування їхній програмі , що викликала. Прийом або передача виконуються мережним адаптером автономно й асинхронно стосовно програми, що викликала функцію IPX для передачі даних. Після того, як операція передачі даних завершилася, у відповідному полі блока ЕСВ встановлюється ознака /прапорець/. Програма може періодично перевіряти ЕСВ для виявлення ознаки завершення операції.
Є й інша можливість. У блоці ЕСВ можна зазначити адресу процедури, що буде викликана при завершенні виконання операції передачі даних. Такий спосіб , тому що прикладна програма не буде витрачати час на періодичну перевірку блока ЕСВ.
Формат блока ЕСВ
Формат блока ЕСВ поданий на мал. 2.
Рис. 2. Формат блока ЕСВ
Схема "клієнт-сервер"
Звичайно в мережі одна з робочих станцій приймає запити на виконання яких-небудь дій від інших робочих станцій. Така станція що обслуговує запити, називається сервером (serve - обслуговувати, server - обслуговуючий устрій). Виконавши запит, сервер посилає відповідь у станцію, що запросила, яка називається клієнтом.
У мережі може бути багато серверів і багато клієнтів. Ті самі клієнти можуть посилати запити різним серверам.
Говорячи більш строго, сервером або клієнтом є не робоча станція, а запущена на ній програма. У мультизадачному середовищі різні програми, запущені одночасно на одной і тій же робочій станції можуть бути і клієнтами, і серверами.
Програма-сервер, виконавши черговий запит, переходить в стан очікування. Вона чекає приходу пакету даних від програми-клієнта. В залежності від вмісту цього пакету, програма-сервер може виконувати різні дії, відповідно до логіки роботи програми. Наприклад, вона може прийняти від програми-клієнта додаткові пакети даних або передати свої пакети.
Сервер і клієнт при необхідності на деякий час або назавжди можуть помінятися місцями, змінивши своє призначення на протилежне.
Для того, щоб створювати програми-сервери і програми-клієнти, нам необхідно навчитися виконувати дві задачі:
• ініціалізацію сервера і клієнта;
• прийом і передачу пакетів даних.
Ініціалізація сервера і клієнта
Для ініціалізації програм сервера і клієнта, працюючих на базі IPX, недостатньо пересвідчитися в наявності відповідного драйвера і отримати точку входу в його API. Вам необхідно виконати деякі підготовчі дії для того, щоб програма могла приймати і передавати пакети даних.
Передусім необхідно, щоб програма-сервер або програма-клієнт ідентифікували себе в мережі за допомогою механізму сокетів.
Для зберігання сокета використовується двохбайтове слово, так що діапазон можливих значень тягнеться від 0 до FFFFh. Однак ви не можете використати довільні значення.
Деякі значення зарезервовані для використання певними програмами. Це так звані "добре відомі" сокети ( "well-known" sockets).
Оскільки протокол IPX є практичною реалізацією протоколу Xerox Internetwork Packet Protocol, первинний розподіл сокетів виконується фірмою Xerox. Згідно з цим розподілом сокети від 0 до 3000 зарезервовані статично за певним програмним забезпеченням. Зокрема, фірма Novell отримала від фірми Xerox діапазон сокетів для своєї мережевої операційної системи NetWare. У специфікації Xerox сокети зі значенням, більшим ніж 3000, можуть розподілятися динамічно.
Сокети, що динамічно розподіляються видаються програмам як би у тимчасове користування (на час їх роботи) по спеціальному запиту. Перед початком роботи програма повинна запитати сокет у протоколу IPX, а перед завершенням - звільнити його.
Розподіл сокетів в мережі Novell NetWare дещо відрізняється від розподілу, встановленого фірмою Xerox. Сокети від 0 до 4000h зарезервовані і не повинні використовуватися в програмному забезпеченні користувачів. Сокети від 4000h до 8000h розподіляються динамічно. Діапазон "добре відомих" сокетів, що розподіляються Novell персонально розробникам програмного забезпечення, розташований вище за значення 8000h.
Ви, як розробник програмного забезпечення для мереж NetWare, можете отримати у Novell для своєї програми персональний сокет (якщо зумієте це зробити) або скористатися сокетом, отриманим динамічно. Можна задавати сокет як параметр при запуску програми. Якщо ви виявите, що значення сокета, яке використовується вами конфліктує з іншим програмним забезпеченням, ви легко зможете змінити його, просто задаючи нове значення для відповідного параметра.
При реалізації схеми обміну даними "клієнт-сервер" сервер звичайно приймає пакети на сокеті, значення якого відоме програмам-клієнтам. Самі ж програми-клієнти можуть використати або те ж caме значення сокета, або отримувати свій сокет динамічно. Клієнт може повідомити серверу свій сокет просто передавши його в пакеті даних (оскільки ми передбачаємо, що сокет сервера відомий програмі-клієнту).
Після визначення сокета необхідно взнати мережеву адресу станцій-одержувачів. Для того щоб клієнт міг послати запит серверу, необхідно крім сокета сервера знати його мережеву адресу - номер мережі і адреса робочої станції в мережі.
Якщо програма-клієнт знає тільки сокет програми-сервера, але не знає його мережеву адресу, останній можна запитати у сервера, пославши запит у всі станції одночасно. Такий запит в межах одного сегмента мережі можна виконати, якщо в якості адреси робочої станції вказати спеціальне значення FFFFFFFFFFFFh. Це так звана "широкомовна" (broadcast) адреса.
Клієнт посилає запит на відомий йому сокет програми-сервера і використовує адресу FFFFFFFFFFFFh. Такий запит приймають всі програми на всіх робочих станціях, чекаючі пакети по даному сокеті. Отримає його і наша програма-сервер. А вона може визначити свою власну мережеву адресу (виконавши виклик відповідної функції IPX) і послати його клієнту. Адресу ж клієнта програма-сервер може взяти із заголовка прийнятого пакету.
Зрозуміло, існує спосіб визначення адреси робочої станції по імені користувача, що підключився на ній до файла-сервера. Це можна зробити за допомогою API мережевої оболонки робочої станції (резидентна програма netx.exe). Однак цей спосіб не дозволить вам визначити адресу станції, на якій не виконане підключення до файл-сервера або незапущена мережева оболонка netx.exe. Пакет, переданий за адресою FFFFFFFFFFFFh, буде прийнятий всіма станціями мережі навіть в тому випадку, якщо файл-сервер вимкнений або його зовсім немає. Тому спосіб визначення мережевої адреси через запит по всій мережі більш універсальний.
Проста система "клієнт-сервер”
Розглянемо дві програми. Перша з них є сервером, друга – клієнтом
Після запуску сервер чекає пакет від клієнта. У свою чергу, клієнт після запуску посилає пакет одночасно всім станціям даної мережі, тому на якій би станції не працював сервер, він обов'язково прийме пакет від клієнта.
Коли сервер прийме пакет від клієнта, в полі ImmAddress блоку ЕСВ сервера виявиться безпосередня адреса клієнта. Тому сервер зможе відповісти клієнту індивідуально, за його адресою в поточній мережі.
Клієнт, в свою чергу, отримавши пакет від сервера, зможе дізнатися його мережеву адресу (по вмісту поля ImmAddress блоку ЕСВ). Наступний пакет клієнт відправить серверу використовуючи отриману безпосередню адресу сервера.
Починаючи з цього моменту сервер знає адресу клієнта, а клієнт знає адресу сервера. Вони можуть обмінюватися пакетами один з одним не вдаючись до посилки пакетів за адресою FFFFFFFFFFFFh.
Початковий текст програми-сервера приведений в додатку.
Спочатку за допомогою функції ipx_init() сервер перевіряє наявність драйвера IPX і отримує адресу його API. Потім за допомогою функції IPXOpenSocket() програма відкриває короткоживучий сокет з номером 0х4567. Цей номер ми вибрали довільно з діапазону сокетів, що розподіляються динамічно.
Далі програма-сервер готує блок ЕСВ для прийому пакету від клієнта (RxECB). Спершу весь блок заповнюється нулями. Потім заповнюються поля номера сокета, лічильник фрагментів (усього використовуються два фрагменти) і дескриптори фрагментів. Перший фрагмент призначений для заголовка пакету, другий - для прийнятих даних.
Підготовлений блок ЕСВ ставиться в чергу на прийом пакету за допомогою функції IPXListenForPacke().
Потім програма в циклі опитує, вміст поля InUse блоку ЕСВ, очікуючи приходу пакету. В цикл очікування вставляється виклик функції IPXRelinquishControl() і функція опиту клавіатури getch(). За допомогою останньою можемо перервати очікування, якщо натиснемо на будь-яку клавішу.
Після того, як сервер прийме пакет від клієнта, вміст поля даних (передане клієнтом у вигляді текстового рядка, закритого двійковим нулем) буде виведений на екран монітора.
Прийнявши пакет, сервер готує ще один блок ЕСВ для передачі пакета у відповідь. Фактично сервер буде використати той же самий блок ЕСВ, що і для прийому. Поле безпосередньої адреси в блоці ЕСВ вже містить адресу клієнта, оскільки коли драйвер IPX прийняв пакет, він записав фактичне значення безпосередньої адреси у відповідному полі блока ЕСВ. Для того, щоб використати блок ЕСВ для передачі, нам досить змінити дескриптори фрагментів - вони повинні вказувати на заголовок пакету, що передається і на буфер, що містить дані, що передаються.
Як дані, що передаються сервер використовує буфер TxBuffer із записаним в нього текстовим рядком "SERVER *DEMO*". Цей рядок буде виведений клієнтом на консоль після прийому від сервера пакет у відповідь.
Підготувавши блок ЕСВ для передачі, програма ставить його в чергу на передачу за допомогою функції IPXSendPacket(), після чого закриває сокет і завершує свою роботу.
Порядок виконання лабораторної роботи
Запустіть програму ipx_spx_net.ехе /головне вікно/.
Натисніть кнопку “Лабораторна робота № 1”.
Запустіть спочатку кнопку “Сервер”, яка запустить програму ірх_server.exe потім кнопку “Клієнт”, яка запустить програму ірх_client.exe
Ознайомитись з повідомленнями виведеними на екран монітора.
Натиснути кнопку “Версія” і переконатись чи завантажений протокол ІРХ, а також переписати точку входу в АРІ драйвера ІРХ.
Примітка: якщо протокол ІРХ не загружений програма видасть повідомлення “ірх не завантажений”, для цього потрібно увійти Start SettingControl PanelNetworkAdd із контекстного меню вибрати Protocol фірми Microsofft IPX/SPX –protocol. Перезавантажити комп’ютер.
Завдання на лабораторну роботу
Використовуючи функції вводу з клавіатури модернізувати програму Клієнта і Сервера.
Модернізуйте програму таким чином щоби в якості параметра при запуску програми задавати сокети із динамічного діапазону /4000h-8000h/.
Контрольні запитання
Що таке сокет?
Структура протоколу ІРХ?
Як відбувається адресація протоколу ІРХ?
На якому рівні семирівневої моделі OSI працює протокол і чи маршрутизується потокол ІРХ?
Пояснити процес ініціалізації клієнта і сервера на базі протокола ІРХ?
Лабораторна робота № 2
Мета роботи: Ознайомлення зі структурою і принципом роботи діагностичного сервісу на базі протоколу ІРХ ,визначення топології мережі за допомогою протокола ІРХ
Теоретичні відомості
Визначення топології мережі
Якщо засобами IPX або SPX необхідно передавати дані між робочими станціями, розташованими в різних мережах, сполучених мостами, нам не обійтися без визначення топології мережі. Коли програма передає дані в межах однієї мережі, вона повинна знати адресу станції, якій буде посилатися пакет. У якості номера мережі можна зазначити нуль, при цьому нам не треба буде навіть знати номер мережі, у якій розташована; станція , що приймає. Ми вже приводили приклади програм, що передають дані в межах однієї мережі.
Інша справа, якщо в передачі даних використовується міст. Якщо пакет повинний пройти міст, у поле ImmAddress блока ЕСВ необхідно зазначити мережеву адресу моста, тому що для того, щоб потрапити в іншу мережу, пакет повинний бути переданий насамперед у міст. У заголовку пакета при цьому повинний бути зазначена адреса приймаючої станції її мережева адреса, у тому числі номер мережі, у якій розташована станція.
Пригадаємо, яким чином в приведених раніше прикладах програмах клієнт і програма-сервер довідувалися мережну адресу один одного.
Програма-клієнт знала номер сокета, що використовується програмою-сервером. Клієнт посилав пакет на цей сокет, при цьому в якості номера мережі використовувалася нульове значення (пакет призначений для передачі в межах тієї мережі, у якому знаходиться передаюча станція), а в якості мережної адреси станції - значення FFFFFFFFFFFFh (пакет призначений для всіх станцій у мережі). Сервер, розташований у тієї ж мережі, що і клієнт, приймав такий пакет. Аналізуючи поле "зворотньої адреси" пакета, сервер міг визначити точну мережеву адресу клієнта. Більш того, у поле ImmAddress блока ЕСВ, що використовувався для прийому пакета, стояла безпосередня адреса станції, від якої прийшов пакет (пакет міг прийти і з іншої мережі через міст, у цьому випадку в полі ImmAddress стояла би адреса моста).
Взнавши мережеву адресу клієнта, сервер відправляв йому пакет. Прийнявши пакет від сервера, клієнт міг визначити мережеву адресу сервера із заголовка пакета , що прийшов до нього. Поле ImmAddress блока ЕСВ, що використовувався при прийомі пакета від сервера, містило безпосередню адресу станції, від якої прийшов пакет.
Якщо сервер і клієнт розташовані в різних мережах, ситуація сильно ускладнюється. Якщо клієнт буде посилати пакет за адресою FFFFFFFFFFFFh, вказавши нульовий номер мережі, пакет буде прийнятий тільки тими станціями, що розташовані в тій же мережі, що і передаюча станція. Через міст такий пакет не пройде, тому якщо програма-сервер працює на станції, котра знаходиться в іншій мережі, вона не одержить пакет від клієнта.
Для того, щоб пакет був прийнятий усіма станціями мережі, залученої через міст, нам необхідно послати цей пакет у міст, вказавши в заголовку пакета номер мережі у який передається пакет, а також адресу станції, рівну FFFFFFFFFFFFh. Для того, щоб послати пакет у міст, у полі ImmAddress відповідного блока ЕСВ треба зазначити адресу моста.
Отже, для того щоб встановити зв'язок із сервером, програма-клієнт повинна дізнатися номер мережі, у якій розташований сервер, і мережеву адресу моста, через який можна послати пакет у цю мережу. На жаль, жодна з функцій драйвера IPX або SPX не повертає інформації про конфігурацію мережі, тому , наша програма повинна вміти одержувати таку інформацію самостійно.
Але ми зможемо з'ясувати конфігурацію мережі, якщо скористаємось спеціальним діагностичним сервісом, реалізованим у рамках драйверів протоколів IPX і SPX.
Мережева оболонка, запущена, на робочих станціях у мережі Novell NetWare, може приймати пакети на спеціальному діагностичному сокеті з номером 0456h. У відповідь на прийнятий пакет діагностичний сервіс повертає станції, що послала такий пакет, інформацію про конфігурацію мережного програмного й апаратного забезпечення станції.
Основна ідея визначення конфігурації мережі полягає в тому, що програма-клієнт надсилає запит про конфігурацію одночасно всім станціям даної мережі на сокеті 0456h, вказавши в якості номера мережі нуль, а в якості адреси станції значення FFFFFFFFFFFFh. Аналізуючи приходячу від станцій діагностичну інформацію, програма-клієнт може виявити в мережі мости і визначити як номера підключених до мостів мереж, так і мережні адреси самих мостів.
Знаючи мережеву адресу мостів і номера підключених до них мереж, програма-клієнт зможе посилати запити для пошуку програми-сервера у всі підключені до мостів мережі.
Очевидно, можна посилати діагностичні запити на сокеті 0456h і в інші мережі з метою пошуку наявних там мостів. У такий спосіб можна з'ясувати конфігурацію всієї мережі і встановити зв'язок із програмою-сервером, де б вона не знаходилася.
Драйвери протоколів IPX і SPX забезпечують два види діагностичного сервісу: IPX-діагностику і SPX-діагностику. Для визначення конфігурації мережі потрібна тільки IPX-діагностика. SPX-діагностика призначена в основному для вимірів продуктивності мережі і для одержання уточненої інформації про склад і конфігурацію програмного забезпечення робочих станцій. Докладний розгляд SPX-діагностики виходить за рамки нашого проекту.
Діагностичний сервіс IPX
Програма може посилати діагностичні запити до конкретної станції в мережі, або всім станціям, або всім станціям, за винятком перерахованих у списку.
Для посилки діагностичного запиту програма повинна підготувати IPX-пакет, який складається зі звичайного заголовка розміром 30 байт і блока даних, що має таку структуру:
struct _req {
unsigned char Exclusions;
unsigned char List[80][6];
};
Заголовок пакета підготовляється звичайною чином. У якості номера мережі можна вказувати або дійсний номер мережі, або нульове значення. У якості мережної адреси можна вказувати або адреса конкретної станції, або адресу FFFFFFFFFFFFh. У полі сокета необхідно проставить значення 0456h.
У полі Exclusions блока даних необхідно проставити кількість станцій, від яких не потрібно одержувати діагностику. Адреси таких станцій повинні бути перераховані в масиві List. Якщо вам треба одержати діагностику від усіх станцій, зазначте в поле Exclusions нульове значення. У будь-якому випадку, якщо діагностика повинна бути отримана від декількох станцій, у якості адреси в заголовку пакета необхідно вказувати значення FFFFFFFFFFFFh.
Блок ЕСВ для передачі діагностичного запиту також підготовляється звичайною чином. При першому діагностичному запиті в полі ImmAddress вказується значення FFFFFFFFFFFFh. Надалі при визначенні конфігурації мережі, підключеної через міст, у цьому полі ви будете вказувати мережеву адресу моста.
Важливе зауваження щодо сокета 0456h: ми не повинні відчиняти або закривати цей сокет. Діагностичний сокет уже відкритий, ми повинні використовувати його для формування адреси при передачі діагностичного запиту. Для прийому відповідних пакетів конфігурації (а також для передачі запиту) вам належить динамічно одержати від драйвера IPX інший сокет.
Після прийому діагностичного пакета кожна станція відповідає на нього посилкою пакета конфігурації. Всі ці пакети посилаються з невеличкою затримкою (приблизно півсекунди), значення якої залежить від останнього байта мережної адреси станції. Затримка використовується для вуникнення перевантаження мережі пакетами конфігурації, що посилаються одночасно багатьма станціями.
Пославши діагностичний пакет усім станціям, наша програма одержить декілька пакетів конфігурації, тому вона повинна заздалегідь (перед посилкою діагностичного пакета) зарезервувати достатню кількість блоків ЕСВ і буферів для прийому пакетів конфігурації.
Прийнятий пакет конфігурації складається зі стандартного заголовка IPX-пакета і блока даних. Прийнятий блок даних складається з двох частин. Перша частина має фіксовану структуру, структура другої частини залежить від конфігурації програмного й апаратного забезпечення станції, від котрої прийшов пакет конфігурації.
Приведемо структуру першої частини:
struct _RESPONSE {
unsigned char MajorVersion;
unsigned char MinorVersion;
unsigned SPXDiagnosticSocket;
unsigned char ComponentCount;
};
У полях MajorVersion і MinorVersion знаходиться відповідно верхній і нижній номер версії діагностичного сервісу.
Поле SPXDiagnosticSocket містить номер сокета, що повинний бути використаний для SPX-діагностики.
Саме цікаве поле - ComponentCount. У ньому знаходиться кількість компонентів програмного й апаратного забезпечення, інформація про які є в прийнятому пакеті конфігурації.
Далі в прийнятому пакеті відразу за полем ComponentCount слідують структури, що описують окремі компоненти. Вони можуть бути двох типів - прості і розширені. Перше поле розміром в один байт має однакове значення в обох типах структур - це ідентифікатор компоненти. По ідентифікаторі компоненти можна однозначно судити про те, яка використовується структура - проста або розширена.
Проста структура і справді нескладна. Вона складається усього з одного байта ідентифікатора компоненти:
struct _SiMPLE_COMPONENT {
unsigned char ComponentID;
};
Значеннями поля ComponentID для простої структури можуть бути числа 0, 1, 2, 3 або 4:
Розширена структура сама по собі складається з двох частин, що мають відповідно, фіксовану і перемінну структуру. Приведемо формат фіксованої частини:
Struct _EXTENDED_COMPONENT {
unsigned char ComponentID;
unsigned char NumberOfLocalNetworks;
};
Поле ComponentID може містити значення 5, б або 7:
Для визначення конфігурації мережі важливо досліджувати компоненти з типом 5, 6 і 7, тому що саме вони мають відношення до з'єднань мереж через мости.
Перемінна частина описує мережі, залучені до компонентів із типом 5, 6 або 7. Кількість таких мереж знаходиться в полі NumberOfLocalNetworks фіксованої частини.
Для опису мереж використовується масив структур (розмірністю NumberOfLocalNetworks):
struct _NETWORK_COMPONENT {
unsigned char NetworkType;
unsigned char NetworkAddress[4]; unsigned char NodeAddress[6];
};
Поле NetworkType описує тип мережі:
Поле NetworkAddress містить номер мережі, до якої підключений відповідний адаптер, а поле NodeAddress - мережеву адресу адаптера. Саме ці поля нам і потрібні для визначення номерів мереж, підключених до мостів, і мережних адрес самих мостів.
Приклад програми
Приведемо приклад програми, що демонструє спосіб визначення конфігурації поточної мережі, тобто тієї мережі, у якій працює дана програма.Структурна схема на рис.4. Програма створює 20 блоків ЕСВ для прийому пакетів конфігурації від робочих станцій, ставить їх у чергу на прийом пакетів і посилає діагностичний пакет у поточну мережу за адресою FFFFFFFFFFFFh. Потім після невеличкої затримки програма аналізує блоки ЕСВ, поставлені в чергу на прийом. Якщо був прийнятий пакет конфігурації, він розшифровується і в текстовому виді виводиться в стандартний вихідний потік.
У функції main створюється об'єкт класу IPX_CLIENT, що по своїх функціях є клієнтом. У нашому випадку задача клієнта - послати діагностичний запит усім станціям мережі й одержати від них пакет конфігурації. Можна вважати, що програма діагностики, що працює на кожній станції, є сервером. Приймаючи запити від клієнтів на діагностичному сокеті, вона посилає їм у відповідь пакети конфігурації.
При створенні об'єкта класу IPX_CLIENT визивається конструктор, що виконує всі необхідні дії . Конструктор ініціалізує драйвер IPX одержує його точку входу і відчиняє динамічний сокет. Відповідний деструктор автоматично закриває отриманий сокет при завершенні роботи програми.
Опис класу IPX_CLIENT знаходиться у файлі ipx. hpp.
Після того як відпрацює конструктор об'єкта IPX_CLIENT, для створеного об'єкта визивається функція go(), що і виконує всі необхідні дії. У тілі функції визначений масив ЕСВ *RxECB[20] із 20 покажчиків на об'єкти класу ЕСВ. Ці об'єкти використовуються для прийому пакетів конфігурації. Крім того, визначений один об'єкт ЕСВ ТхЕСВ для посилки пакета з діагностичним запитом.
Програма в циклі створює 20 об'єктів класу ЕСВ і за допомогою функції ListenForPacket ставить їх у чергу на прийом пакетів. Потім програма посилає в мережу пакет із діагностичним запитом і чекає одну секунду. За цей час станції мережі надсилають пакети конфігурації.
Отримані пакети конфігурації виводяться в стандартний потік функцією PrintDiagriostics, визначеної в класі ЕСВ. Ця функція виводить для кожної станції , що відповіла , версію використовуваної діагностики, номер сокета для роботи з SPX-діагностикою, кількість програмних компонентів, що працюють на станції, номер мережі і мережної адреса станції (вузла). Для файлів-серверів і мостів додатково виводиться кількість залучених до них мереж. Для кожної мережі виводиться її номер і мережної адреса відповідного адаптеру.
Для спрощення програми ми обмежилися діагностикою тільки однієї мережі. Крім того, ми послали тільки один діагностичний запит, у якому не виключали жодної станції. Якщо нам потрібно визначити конфігурацію всієї мережі, нам треба зробити таке.
По-перше, після прийому пакетів конфігурації запишемо адреси станцій, що відповіли, в список станцій, виключених із діагностичного запиту. Потрібно проставити кількість виключених станцій. Потім виконаємо повторну передачу діагностичного запиту. Виконувати цю операцію до тих пір поки у відповідь на діагностичний запит не прийде жодного пакета конфігурації. В цьому випадку адреси всіх станцій текучої мережі, будуть записані в список станцій, які виключені із діагностичного запиту.
По-друге, виконаємо аналіз пакетів конфігурації, що надійшли. Найдемо пакети що надійшли від файл-серверів і мостів. Визначимо номери мереж, підключених до них. Потім виконаємо процедуру багатократної посилки діагностичних пакетів в інші мережі. Для цього при передачі діагностичного пакета в заголовку вкажемо номер мережі, яку бажаємо перевірити. В якості мережевої адреси станції використаємо значення FFFFFFFFFFFFh. В блоці ЕСВ в полі безпосередньої адреси вкажіть мережеву адресу моста, через яку можна отримати доступ в досліджувану мережу.
Порядок виконання лабораторної роботи
Запустіть програму ipx_spx_net.ехе /головне вікно/.
Натисніть кнопку “Лабораторна робота № 2”.
Натисніть кнопку “Діагностика”, яка запустить програму diagn.exe
Ознайомитись з повідомленнями виведеними на екран монітора. Натиснути кнопку “Версія” і переконатись чи завантажений протокол ІРХ, а також переписати точку входу в АРІ драйвера ІРХ.
Примітка: якщо протокол ІРХ не загружений програма видасть повідомлення “ірх не завантажений”, для цього потрібно увійти Start SettingControl PanelNetworkAdd із контекстного меню вибрати Protocol фірми Microsofft IPX/SPX –protocol. Перезавантажити комп’ютер.
Завдання на лабораторну роботу
Переписати результати виконання програми “діагностика” і детально проаналізувати пакети конфігурації.
Модернізуйте програму “діагностика” таким чином щоби вона посилала діагностичний запит конкретній станції в мережі.
Контрольні запитання
Що таке адреса станції і як її визначити?
Для чого потрібна ІРХ-діагностика?
Яка структура діагностичного пакету?
Яка структура пакету конфігурації?
Лабораторна робота № 3
Мета роботи: Ознайомлення зі структурою і принципом роботи протоколу SPX . Реалізація системи клієнт-сервер за допомогою протокола SРХ.
Теоретичні відомості
Для деяких програм (наприклад, для програм, що передають файли між робочими станціями) зручніше використати мережевий протокол більш високого рівня, що забезпечує гарантовану доставку пакетів в правильній послідовності. Зрозуміло, наша програма може сама стежити за тим, щоб всі передані пакети були прийняті. Однак в цьому випадку нам доведеться робити власну надбудову над протоколом IPX - власний протокол передачі даних.Перш ніж ухвалити рішення про створення власного протоколу, вивчимо протокол SPX - протокол послідовного обміну пакетами (Sequenced Packet Exchange Protocol), розроблений Novell. Можливо, що протокол SPX задовольнить потреби нашої програми в гарантованій передачі даних по мережі.
Формат пакету SPX
Пакет, що передається за допомогою протоколу SPX, має більш довгий заголовок. Додатково до 30 байтів стандартного заголовка пакету IPX додається ще 12 байт (рис. 5).
Рис. 5. Формат заголовка пакета SPX
Поле ConnControl можна розглядати як набір бітових прапорців, керуючих передачею даних по каналу SPX:
Поле DataStreamType також складається з однобітових прапорів, які використовуються для класифікації даних, що передаються або що приймаються за допомогою протоколу SPX. Приведемо можливі значення поля DataStreamType:
Поле SourceConnID містить номер каналу зв'язку передаючої програми, привласнений драйвером SPX при створенні каналу зв'язку. Цей номер повинен вказуватися функції передачі пакету коштами SPX.
Поле DestConnID містить номер каналу зв'язку приймаючої сторони. Оскільки всі пакети приходять на один номер сокета і можуть належати різним каналам зв'язку (на одному сокеті можна відкрити декілька каналів зв'язку), вам необхідно класифікувати приходячі пакети по номеру каналу зв'язку.
Поле SeqNumber містить лічильник пакетів, переданих по каналу в одному напрямі. На кожній стороні каналу використовується свій лічильник. Після досягнення значення FFFFh лічильник скидається в нуль, після чого процес рахунку продовжується.
Вмістом цього поля управляє драйвер SPX, тому програма не повинна міняти його значення.
Поле AckNumber містить номер наступного пакету, який повинен бути прийнятий драйвером SPX.
Вмістом цього поля управляє драйвер SPX, тому програма не повинна міняти його значення.
Поле AllocNumber містить кількість буферів, розподілених програмою для прийому пакетів.
Вмістом цього поля управляє драйвер SPX, тому програма не повинна міняти його значення.
Блок ЕСВ
Для протоколу SPX використовується точно такий самий блок ЕСВ, що і для протоколу IPX.
"Проста система "клієнт-сервер" на базі SPX
Приведемо найпростіший приклад, що демонструє використання основних функцій SPX. Цей приклад зроблений на базі попереднього, в якому дві програми - клієнт і сервер - спілкувалися між собою за допомогою протоколу IPX.
Після визначення наявності драйвера IPX і отримання адреси його API програма-сервер за допомогою функції SPXCheckSPXIn...
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора