IPX/SPX
Стек IPX/SPX
Стек IPX/SPX є оригінальним стеком протоколів фірми Novell, розробленим для мережевої операційної системи NetWare ще на початку 80-х років. Протоколи мережевого і сеансового рівнів Internetwork Packet Exchange (IPX) і Sequenced Packet Exchange (SPX), які й дали назву стеку, є прямою адаптацією протоколів XNS фірми Xerox, поширених набагато менше, ніж стек IPX/SPX. Популярність стека IPX/SPX безпосередньо пов'язана з операційною системою Novell NetWare, що ще зберігає світове лідерство за числом встановлених систем, хоча останнім часом її популярність дещо знизилася і за темпами росту вона відстає від Microsoft Windows NT. Багато особливостей стека IPX/SPX обумовлені орієнтацією ранніх версій ОС NetWare (до версії 4.0) на роботу в локальних мережах невеликих розмірів, що складаються з персональних комп'ютерів із скромними ресурсами. Зрозуміло, що для таких комп'ютерів компанії Novell потрібні були протоколи, для реалізації яких потрібна була б мінімальна кількість оперативної пам'яті (обмеженої в IBM-сумісних комп'ютерах під керуванням MS-DOS обсягом 640 Кбайт) і які б швидко працювали на процесорах невеликої обчислювальної потужності. У результаті, протоколи стека IPX/SPX донедавна добре працювали в локальних мережах, і не дуже – у великих корпоративних мережах, тому що вони занадто перевантажували повільні глобальні зв'язки широкомовними пакетами, що інтенсивно використовуються декількома протоколами цього стека (наприклад, для встановлення зв'язку між клієнтами і серверами). Ця обставина, а також той факт, що стек IPX/SPX є власністю фірми Novell і на його реалізацію потрібно одержувати ліцензію (тобто відкриті специфікації не підтримувалися), довгий час обмежували поширеність його тільки мережами NetWare. Проте з моменту випуску версії NetWare 4.0 Novell внесла і продовжує вносити у свої протоколи серйозні зміни, спрямовані на їхню адаптацію для роботи в корпоративних мережах. Зараз стек IPX/ SPX реалізований не тільки в NetWare, але й у декількох інших популярних мережевих ОС, наприклад SCO UNIX, Sun Solaris, Microsoft Windows NT.
Сімейство протоколів фірми Novell і їх відповідність моделі ISO / OSI представлено на Мал 1.
На фізичному і канальном рівнях в мережах Novell використовуються всі популярні протоколи цих рівнів (Ethernet, Token Ring, FDDI та інші).
На мережевому рівні в стеке Novell працює протокол IPX, а також протоколи обміну маршрутною інформацією RIP і NLSP (аналог протоколу OSPF стека TCP / IP). IPX є протоколом, який займається питаннями адресації і маршрутизації пакетів в мережах Novell. Маршрутні рішення IPX засновані на адресних полях в заголовку його пакету, а також на інформації, що надходить від протоколів обміну маршрутною інформацією. Наприклад, IPX використовує інформацію, що поставляється або протоколом RIP, або протоколом NLSP (NetWare Link State Protocol) для передачі пакетів комп'ютера призначення або наступного маршрутизатора. Протокол IPX підтримує тільки дейтаграммний спосіб обміну повідомленнями, за рахунок чого економно споживає обчислювальні ресурси. Отже, протокол IPX забезпечує виконання трьох функцій: завдання адреси, встановлення маршруту та розсилку дейтаграмм.
Транспортному рівню моделі OSI в стеке Novell відповідає протокол SPX, який здійснює передачу повідомлень з встановленням сполук.
На верхніх прикладному, представницькому і сеансовом рівнях працюють протоколи NCP і SAP. Протокол NCP (NetWare Core Protocol) є протоколом взаємодії сервера NetWare і оболонки робочої станції. Цей протокол прикладного рівня реалізує архітектуру клієнт-сервер на верхніх рівнях моделі OSI. За допомогою функцій цього протоколу робоча станція проводить підключення до сервера, відображає каталоги сервера на локальні букви дисководів, переглядає файлову систему сервера, копіює вилучені файли, змінює їх атрибути і т.п., а також здійснює розподіл мережевого принтера між робочими станціями.
SAP (Service Advertising Protocol) - протокол оголошення про сервіс - концептуально подібний до протоколу RIP. Подібно до того, як протокол RIP дозволяє маршрутизаторам маршрутної обмінюватися інформацією, протокол SAP дає можливість мережних пристроям обмінюватися інформацією про наявні мережевих сервісах.
Сервери та маршрутизатори використовують SAP для оголошення про своїх сервісних послуги та мережевих контактах. Протокол SAP дозволяє мережних пристроїв постійно коригувати дані про те, які сервісні послуги є зараз у мережі. При старті сервери використовують SAP для оповіщення що залишилася частини мережі про свої послуги. Коли сервер завершує роботу, то він використовує SAP для того, щоб сповістити мережа про припинення дії своїх послуг.
У мережах Novell сервери NetWare 3.x кожну хвилину розсилають шіроковещательние пакети SAP. Пакети SAP в значній мірі засмічують мережу, тому однією з основних завдань маршрутизаторів, що виходять на глобальні зв'язку, є фільтрація трафіку SAP-пакетів і RIP-пакетів.
Інформація взята звідси
IPX - протокол
Протокол IPX (Internetwork Packet Exchange) призначений для передачі дейтограмм в системах, неорієнтованих на з'єднання (також як і IP або NETBIOS, розроблений IBM і емульований в Novell), він забезпечує зв'язок між NetWare серверами і кінцевими станціями. Максимальний розмір IPX-дейтограмми становить 576 байт, з них 30 байта займає заголовок. Передбачається, що мережа, через яку транспортуються ці дейтограмми, здатна пересилати пакети відповідної довжини. IPX-пакети можуть розсилатися широкомовно, для цього поле типу має значення 0x14, адреса мережі призначення повинен відповідати локальної мережі, адреса вузла призначення при цьому приймає значення 0xFFFFFF.
Оригінальний транспортний протокол Novell, на мій погляд, не сприяє успіху цієї мережі. Не встигнувши вчасно переорієнтуватися на транспортні й маршрутні протоколи стека TCP / IP цей украй популярний зовсім недавно вид мереж в даний час має шанси зникнути.
IPX-пакети, що передаються по мережі Ethernet, можуть мати кілька різних форматів. Найстарший з них носить в Novell назву "802.3" і використовується за замовчанням в версіях аж до 3.11. У наступних версіях форматом за замовчанням є "802.2". Використовуємо також і формат, названий Ethernet II, який найбільш близький ідеології TCP/IP. Мережа в Netware - це логічний канал, який використовується спільно рядом вузлів так, що вони можуть взаємодіяти один з одним безпосередньо. Так процеси, реалізовані на одному сервері, вважаються підключеними до внутрішньої IPX-мережі. Всі користувачі мережі типу Ethernet II утворюють логічну мережу IPX. Всі користувачі однієї мережі типу 802.3 розглядаються як вузли різних мереж IPX. Зіставлення форматів пакетів для різних мережевих стандартів представлено на Мал. 2.
З малюнка видно, що відмінності непринципові і не перешкоджають співіснування всіх перерахованих форматів у межах однієї локальної мережі. IPX-заголовок починається відразу після поля Тип або Довжина у залежності від використовуваного протоколу.
Сервери Netware можна настроїти так, щоб вони сприймали пакети різних типів, і тому могли мати безпосередні зв'язки з різними мережами. IPX-сервер може виконувати і функції маршрутизатора. Формат заголовка пакета IPX зображений на Мал 3. За заголовком слідують дані, їх обсяг визначається кодом поля Довжина пакета (мінус 30) і лежить в діапазоні від 0 до 546 байт.
Поле Контрольна сума (2 байти) встановлюється IPX-драйвером рівним 0xffff, це означає, що контрольного підсумовування не проводилося. Додаткам дозволено використовувати поле контрольної суми при роботі з кадрами Ethernet II, ІЕЕЕ 802.2 і Ethernet SNAP і заборонено для роботи з кадрами ІЕЕЕ 802.3. Контрольна сума служить лише для контролю правильності IPX-заголовка і не має ніякого відношення до поля даних IPX-дейтаграми. Для того щоб працювати з контрольними сумами на NetWare-сервері, слід виконати команду set enable IPX checksum = n, де n вказує на те, що контрольна сума використана. Можливі значення n і їхній зміст наведено нижче в Таблиці 1 і Таблиці 2.
| Код n | Призначення для сервера |
|---|---|
| 0 | Контрольна сума не використовується |
| 1 | Контрольна сума використовується, якщо доступна клієнту |
| 2 | Контрольна сума повинна використовуватися |
| Код n | Призначення для клієнта |
|---|---|
| 0 | Контрольна сума не використовується (за замовчуванням) |
| 1 | Контрольна сума використовується, але позбавлена пріоритету |
| 2 | Контрольна сума використовується і має пріоритет |
| 3 | Контрольна сума повинна використовуватися |
Поле Довжина пакета (2 байти) містить число байт в пакеті, включаючи заголовок, і може бути в межах від 30 (тільки заголовок) до 576. Насправді максимальна довжина IPX-пакета дорівнює 1518 байт, але при проходженні пакетів через маршрутизатори, коли не використовується протокол LIP (large internet packet, протокол міжмережевого пересилання великих пакетів) максимальна довжина може бути рівна лише 576 байт (що й прийнято за замовчуванням). Слід також мати на увазі, що згідно регламентациям Novell довжина пакета може приймати лише парні значення. Програміст не повинен турбуватися про зміст цього поля, це за нього зробить сам протокол IPX. Поле у правління пересиланням (1 байт) встановлюється IPX-драйвером рівним нулю перед посилкою пакета. Кожен маршрутизатор збільшує значення цього поля на 1. Якщо пакет пройшов через 15 маршрутизаторів, черговий - видалить пакет з мережі (в певному сенсі це аналог поля час життя - TTL в протоколах TCP/IP). Поле управління пересиланням можна використовувати для оптимізації маршрутів в локальній мережі. Якщо станція спілкується тільки з серверами сусідній субмережі, її слід переключити туди і знизити тим самим навантаження маршрутизатора. Контроль за вмістом цього поля виконується протоколом IPX. Поле тип пакету (1 байт) встановлюється прикладною програмою. При використанні протоколу ipx це поле повинно містити нуль (або 4), у разі використання протоколу SPX - 5, а для протоколу NCP (Netware core protocol) -17. Поля адресу вузла призначення і а дрес вузла відправника містять 12-байтові структури ipxaddr_1. Ця структура включає в себе 4 байта адреси мережі (присвоюється адміністратором мережі при встановленні мережі Novell), 6 байт адреси вузла (фізична адреса, задається виробником мережевого інтерфейсу) і 2 байти дескриптора з'єднувача (socket, необхідний для адресації програми, що приймає пакети заповнююься додатком ). Пакети, адресовані серверу в NetWare 3.x або 4.x містять в полі адреси вузла одержувача код 0x00 00 00 00 00 01 (аналогічний код буде записаний в поле адресу відправника, якщо ним є сервер). Адреса ж вузла одержувача на рівні Ethernet або Token Ring дорівнюватиме фізичній мережевій адресі інтерфейсу або локального маршрутизатора, якщо сервер розміщений в іншій субмережі. З'єднувачі (socket) служать для управління обробки пакетів. Широкомовний пакет буде отриманий ЕОМ, якщо вона має відкритий з'єднувач для процесу, якому він адресований. З цієї причини повинні прийматися спеціальні заходи, щоб запобігти можливості посилки двома програмами пакетів різного типу на один і той же з'єднувач. Ряд номерів з'єднувачів зарезервовано IPX-протоколом для певних цілей:
2 - з'єднувач протокольних відгуків, 3 - обробник помилок.
Деякі номери зайняті під потреби Netware:
- 0x451 Протокол ядра NetWare (NCP - netware core protocol);
- 0x452 Протокол NetWare для оповіщення про послуги (SAP - service advertising protocol);
- 0x453 Маршрутний протокол NetWare (RIP - routing information protocol);
- 0x455 Пакет протоколу netbios;
- 0x456 Діагностичний протокол NetWare;
- 0x457 Пакет серіалізациї (serialization).
Дескриптори з'єднувачів для робочих станцій задаються динамічно та їх коди лежать в діапазоні 0x4000 - 0x8000. На відміну від протоколів TCP/IP IPX не має фіксованих адрес для мереж або інтерфейсів, які слід конфігурувати. Замість цього робочі станції отримують свої мережеві кімнати від маршрутизатора, до якого вони приєднані, і використовують Ethernet-адресу як номери вузла.
Додаток повинен встановлювати поля тип пакета та адресу вузла призначення, а IPX-драйвер заповнює інші поля. Можливі значення коду поля тип пакета представлені в Таблиці 3.
| Тип пакета | Значення |
|---|---|
| 0 | Звичайний IPX-пакет |
| 1 | Пакет з маршрутною інформацією (RIP - routing information protocol) |
| 2 | Відгук |
| 3 | Помилка |
| 4 | Інформаційний пакетний обмін (pep - packet exchange protocol) |
| 5 | Послідовний пакетний обмін (SPX - sequence packet exchange) |
| 17 | Протоколи ядра NetWare (NCP) |
| 20 | Іменний пакет netbios (широкомовний) |
Програма, що використовує IPX-протокол для передачі інформації повинна записувати в поле тип пакета код 4.
Маршрутна інформація передається між серверами і маршрутизаторами. Динамічний маршрутний протокол RIP (routing information protocol, базується на стандарті Xerox IP) забезпечує кінцеві станції інформацією, яка необхідна для динамічного управління оптимізацією маршрутів. Розсилка маршрутної інформації проводиться за допомогою широкомовних пакетів. Як бачимо, мережі Novell є джерелом значних потоків широкомовних пакетів. Аналогічним чином об'єкти мережі оповіщаються про інші зміни в мережевому середовищі, наприклад, розсилка інформації про доступні послуги (SAP - service advertisement protocol). Протокол SAP дозволяє вузлам, які пропонують певні послуги (наприклад, файл-сервери або принт-сервери), повідомляти про свої адреси і видах доступних послуг. Адміністратор може регулювати потік таких пакетів, задаючи постійний час для таймерів оновлення інформації. Маршрутизатори розсилають маршрутну інформацію в п'яти випадках:
- При ініціалізації.
- У випадку, коли необхідна вихідна маршрутна інформація (напр. в разі збою або псування маршрутної таблиці).
- Періодично для оновлення маршрутних таблиць.
- При зміні конфігурації маршрутів.
- При відмові або відключенні маршрутизатора.
Маршрутизація пакетів в мережі досить проста. Кожному мережному сегменту маршрутизатор присвоює номер в межах від 1 до fffffffe. Кожній групі пристроїв присвоюється "мережевий номер", який представляє цю групу у всіх маршрутизаторах мережі. Пакети що посилаються від одного члена групи іншому, надсилаються безпосередньо. Пакети від одного члена групи до об'єкту з іншої групи будуть переслані через маршрутизатори. Для вибору маршруту в межах локальної мережі використовується маршрутний протокол RIP. Формат пакета NetWare RIP зображений на Мал 4.
Поле тип пакету містить код 0x0001, якщо це запит, і 0x0002, якщо відгук. У полі адреси мережі записується адреса мережі місця призначення, якщо пакет є запитом. Якщо в полі записаний код 0xff ff ff ff, це означає, що запит відноситься до всіх відомих мереж. Поле число кроків до мети має сенс лише у випадку пакетів-відгуків. У цьому випадку сюди заноситься число маршрутизаторів, які повинен пройти пакет по дорозі до мережі призначення. Поле час має сенс для пакетів-відгуків і вказує на час, необхідний для досягнення мережі адресата. Один час дорівнює 1 / 18 секунди. Подібний протокол маршрутизації використовується в мережах appletalk (RTMP).
Для міжмережевої маршрутизації в Novell розроблений протокол NLSP (NetWare link services protocol). NLSP базується на тій же ідеології, що і протокол IS-IS (intermediate system-to-intermediate system), створений для мереж OSI і IP. У NLSP значення метрики маршруту задається вручну. nlsp-маршрутизатори зберігають повну карту мережі, по якій приймаються рішення про найкращих можливих маршрутах.
На Мал 5. представлена схема відповідності протоколів Novell і 7-рівневої моделі osi.
Протокол SAP (service advertising protocol) служить для отримання інформації про всі сервера, що є в мережі, і підтримує такі види запитів та функції:
- запит SAP-сервісу;
- оповіщення про відключення сервера;
- моніторинг відгуків і деякі інші.
Кожному серверу NetWare присвоює номер, а деякі сервера можуть мати й ім'я. Номер сервера і його ім'я зберігаються в базі даних об'єктів bindary кожного сервера. Пакет запиту SAP-сервісу містить 2 байта типу пакету і два байти типу сервера. Поле тип пакета визначає, чи є даний пакет загальним запитом сервісу (код = 0x0003), або запитом найближчих послуг (код = 0x0001). Таблиця кодів поля тип сервера наведена нижче в Таблиці 4.
| Тип сервера | Опис |
|---|---|
| 0x0001 | Користувач |
| 0x0004 | Файл-сервер |
| 0x0005 | Сервер завдань |
| 0x0006 | Зовнішній мережевий порт (gateway) |
| 0x0007 | Принт-сервер |
| 0x0009 | Сервер архіву |
| 0x000a | Черга завдань |
| 0x0017 | Діагностика |
| 0x0020 | NetBios |
| 0x0021 | NAS SNA порт |
| 0x0027 | TCP/IP сервер порту |
| 0x0028 | Сервер моста x.25 точка-точка |
| 0x02e | Динамічний SAP |
| 0x0047 | Сповіщає принт-сервер |
| 0x004b | vap 5.0 |
| 0x004c | SQL VAP |
| 0x007a | TES-NetWare VMS |
| 0x0098 | Сервер доступу до NetWare |
| 0x009a | Сервер іменованих труб |
| 0x009e | Портативний NetWare-Unix |
| 0x0107 | NetWare 386 |
| 0x0111 | Тест-сервер |
| 0x0166 | Управління NetWare |
| 0x026a | Управління NetWare |
| 0x026b | Тимчасова синхронізація |
| 0x0278 | Сервер каталогів NetWare |
Формат пакета протоколу IPX
Пакет протоколу IPX має набагато більш просту структуру в порівнянні з пакетом IP, що, власне, і відбиває менші функціональні можливості протоколу IPX.
IPX-пакет має наступні поля:
| Поле заголовка | Довжина в байтах |
|---|---|
| Checksum-контрольна сума | 2 |
|
Length-общая длина пакета |
2 |
| TransportControl-счетчик пройденных мостов | 1 |
| PacketType тип пакета | 1 |
| DestNetwork-адрес сети получателя | 4 |
| DestNode-адрес станции получателя | 6 |
| DestSocet-сокет программы- получателя | 2 |
| SourceNetwork-адрес сети отправителя | 4 |
| SourceNode-адрес узла отправителя | 6 |
| SourceSocet-сокет программы-отправителя | 2 |
| DATA-данные | 0-564 |
Контрольна сума (Checksum) - це 2-байтовое поле, що є «пережитком минулого», що протокол IPX веде від протоколу IDP стека Xerox. Тому що низкоуровневые протоколи (наприклад, Ethernet) завжди виконують перевірку контрольних сум, то IPX не використовує це поле і завжди встановлює його в одиниці.
Довжина (Length) займає 2 байти і задає розмір усього пакета, включаючи IPX-заголовок і поле даних. Самий короткий пакет - 30 байт - включає тільки IPX-заголовок, а рекомендува максимально великий - 576 байт - включає IPX-заголовок плюс 546 байт даних. Максимальний розмір пакета в 576 байт відповідає рекомендаціям стандартів Internet для складених мереж. Протокол IPX обчислює значення цього полючи, ґрунтуючись на інформації, наданою прикладною програмою при виклику функції IPX. IPX-пакет може перевершувати максимум, що рекомендується, у 576 байт, що і відбувається в локальних мережах Ethernet, де використовуються IPX-пакети в 1500 байт із полем даних у 1470 байт.
Керування транспортом (Transport control) має довжину 8 біт. Це поле визначає час життя пакета в хопах. IPX-пакет може перетнути до 15 маршрутизаторів. Протокол IPX установлює це однобайтовое поле в 0 до початку передачі, а потім збільшує його на 1 щораз, коли пакет проходить через маршрутизатор. Якщо лічильник перевищить 15, то пакет анулюється.
Тип пакета (Packet type) має довжину 8 біт. Фірма Xerox визначила у свій час визначені значення для різних типів пакетів: прикладні програми, що посилають IPX-пакети, повинні встановлювати це поле в значення, рівне 4. Значення 5 відповідає службовим IPX-пакетам, використовуваним протоколом SPX як службові повідомлення. Значення 17 указує на те, що в поле даних IPX-пакета знаходиться повідомлення протоколу NetWare Core Protocol (NCP) - основного протоколу файлової служби NetWare.
Адреса призначення (Destination address) - складається з трьох полів: номера мережі призначення, номера вузла призначення, номера сокета призначення. Ці поля займають відповідно 4, 6 і 2 байти.
Адреса відправника (Source address) - номер вихідної мережі, номер вихідного вузла, номер вихідного сокета. Аналогічні адресним полям призначення.
Поле даних (Data). Може займати від 0 до 546 байт. Поле даних нульової довжини може використовуватися в службових пакетах, наприклад, для підтвердження одержання попереднього пакета. З аналізу формату пакета можна зробити деякі висновки про обмеження протоколу IPX.
Відсутня можливість динамічної фрагментації на мережному рівні. У IPX-пакеті немає полів, за допомогою яких маршрутизатор може розбити занадто великий пакет на частині. При передачі пакета в мережу з меншим значенням MTU IPX-маршрутизатор відкидає пакет. Протокол верхнього рівня, наприклад NCP, повинний послідовно зменшувати розмір пакета доти, поки не одержить на нього позитивну квитанцію.
Великі накладні витрати на службову інформацію. Порівняно невелика максимальна довжина полючи даних IPX-пакета (546 байт при довжині заголовка 30 байт) приводить до того, що як мінімум 5 % даних є службовими.
Час життя пакета обмежено числом 15, що може виявитися недостатнім для великої мережі (для порівняння, у IP-мережах пакет може пройти до 255 проміжних маршрутизаторів).
Відсутнє поле якості сервісу, що не дозволяє маршрутизаторам автоматично підбудовуватися до вимог додатка до якості передачі трафика.
Крім того, деякі недоліки мереж Novell зв'язані не з протоколом IPX, a із властивостями інших протоколів стека IPX/SPX. Багато недоліків виявляються при роботі стека IPX/SPX на повільних глобальних лініях зв'язку, і це закономірно, тому що ОС NetWare оптимизировалась для роботи в локальній мережі.
Наприклад, неефективна робота по відбудові загублених і перекручених пакетів на низкоскоростных глобальних каналах обумовлена тим, що протокол NCP, що виконує цю роботу, використовує метод одержання квитанцій із простоями. У локальних мережах зі швидкістю 10 Мбит/з такий метод працював цілком ефективно, а на повільних каналах час чекання квитанції помітно гальмує роботу передавального вузла.
У версіях ОС NetWare до 4.0 відповідність символьних імен серверів їхнім мережним адресам установлювалося тільки за допомогою широкомовного протоколу Service Advertising Protocol (SAP). Однак широкомовні розсилання помітно засмічують повільні глобальні канали. Модернізуючи свій стек для застосування у великих корпоративних мережах, компанія Novell використовує тепер довідкову службу NDS (NetWare Directory Services) для перебування різноманітної інформації про наявним у мережі ресурсах і службах, у тому числі і про відповідність імені сервера його мережній адресі. Тому що служба NDS підтримується тільки серверами з версією NetWare 4.x і вище, те для роботи з версіями NetWare 3.x маршрутизатори розпізнають SAP-пакети по номері їх сокета і передають них на всі порти, імітуючи широкомовні розсилання локальної мережі, на що витрачається значна частина пропускної здатності повільних глобальних ліній. Крім того, така «псевдошироковещательность» зводить нанівець ізоляцію мереж від некоректних SAP-пакетів.
В останніх версіях своєї операційної системи NetWare компанія Novell значно модифікувала свій стек для того, щоб він міг більш ефективно використовуватися у великих складених мережах.
Служба NDS дозволяє відмовитися від широкомовного протоколу SAP. Служба NDS заснована на ієрархічній розподіленій базі даних, що зберігає інформацію про користувачів і поділювані ресурси мережі. Додатки звертаються до цієї служби по протоколі прикладного рівня NDS.
Додано модуль для реалізації методу ковзного вікна - так називаний Burst Mode Protocol NLM.
Додано модуль для підтримки довгих IPX-пакетів у глобальних мережах - Large Internet Packet NLM.
Крім того, постійне підвищення швидкодії глобальних служб зменшує недоліки оригінальних протоколів стека IPX/SPX, що дозволяє деяким оглядачам говорити про успішну роботу операційної системи NetWare у глобальних мережах і без зазначених нововведень.
Інформація взята звідси
SPX - протокол
SPX (Sequence Packet eXchange) і його вдосконалена модифікація SPX II є транспортні протоколи 7-рівневої моделі ISO. Це протокол гарантує доставку пакета і використовує техніку ковзаючого вікна (віддалений аналог протоколу TCP). У разі втрати або помилки пакет пересилається повторно, число повторень задається програмно. У протоколі SPX не передбачена широкомовна або мультікастінг-адресація. У SPX індукується ситуація, коли партнер несподівано перериває з'єднання, наприклад через обрив зв'язку. Пакети SPX вкладаються в пакети IPX. При цьому у полі тип пакета IPX записується код 5. Заголовок пакета SPX завжди містить 42 байта, включаючи 30 байт заголовка IPX-пакета, куди він вкладений.
Поле управління з'єднанням визначає, чи є даний пакет системним чи прикладним. Це поле містить однобітові прапорці, використовувані spx і spx ІІ для управління потоком даних у віртуальному каналі.
- 0x01 XHD Зарезервовано SPX II для розширення заголовків;
- 0x02 RES1 Призначення поля не визначено, має дорівнювати нулю;
- 0x04 NEG SPX II (SIZ) погоджує розмір запиту / відгуку, для spx має дорівнювати нулю;
- 0x08 SPX2 Тип пакета SPX II, для spx має дорівнювати нулю;
- 0x10 EOM Встановлюється клієнтом spx для індикації кінця повідомлення (end-of-message);
Поле тип потоку даних характеризує тип даних, поміщених в пакет. Значення цього поля перераховані нижче:
- 0x00-0x07 визначається клієнтом і може використовуватися в додатках;
- 0x80-0xfb зарезервовані на майбутнє;
- 0xfc spx ІІ, впорядковане звільнення запиту;
- 0xfd spx ІІ, впорядковане звільнення підтвердження;
- 0xfe вказує на закінчення зв'язку (end-of-connection). При закритті каналу spx-драйвер посилає клієнтові пакет, де в полі тип потоку записаний даний код;
- 0xff підтвердження отримання повідомлення про закінчення зв'язку (end-of-connection-acknowledgment). Цим кодом позначається пакет, що підтверджує закриття каналу, в прикладну програму такий пакет не передається
Поля ідентифікатора відправника і одержувача містять коди, що визначають учасників інформаційного обміну, присвоюються SPX-драйвером у момент встановлення зв'язку. У запитах на з'єднання це поле містить код 0xffff. Дане поле служить для забезпечення демультиплексування пакетів, що надходять на один і той же з'єднувач (socket). Поле послідовний номер визначає число пакетів пересланих в одному напрямку. Кожен з партнерів обміну має свій лічильник, який скидається в нуль після досягнення 0xffff, після чого рахунок може продовжуватися. Для програми це поле, також як і наступні два, недоторкане. spx-пакети підтвердження містять в цьому полі порядковий номер останнього посланого пакета. Поле номер підтвердження характеризує послідовний номер наступного пакета, який spx очікує отримати. Будь-який пакет з порядковим номером менше, ніж задано в полі номера підтвердження, доставлений благополучно і не вимагає ретрансміссіі. Поле число буферів служить для вказівки числа доступних на станції буферів (буфера нумеруються, починаючи з 0, один буфер здатний прийняти один пакет) і використовується для організації управління потоком даних між додатками. Код цього поля інформує партнера по найбільшому порядковому номері пакету, який може бути посланий. Протокол spx посилає пакети до тих пір, поки локальний послідовний номер не стане рівним числу-вказівником на віддаленій ЕОМ.
SPX-протокол не посилає наступний пакет до тих пір, поки не отримає підтвердження отримання попереднього. Хоча в протоколі SPX передбачений алгоритм ковзаючих вікон (як і в TCP), практично він у даний час не використовується, що цілком виправдано для локальних мереж. Слід зауважити, що для досить великих LAN, де пакет проходить через кілька маршрутизаторів, нехтування технікою вікон стає недозволеною розкішшю. На випадок непередбачених обривів зв'язку в spx є алгоритм "сторожова собака". Цей алгоритм реалізується спеціальною програмою, яка активується лише у випадку, коли протягом певного часу в каналі відсутній трафік в будь-якому з напрямів (машина все зробила, а оператор заснув). У цьому випадку програма посилає спеціальні пакети і, якщо через певне число спроб "достукатися" до партнера не вдається, сесія переривається. Якщо партнер не надсилає відгук за обумовлений час (RTT), проводиться повторна посилка пакета, при цьому RTT збільшується на 50%. Значення RTT не повинно перевищити величини max_retry_delay, яка за замовчуванням дорівнює 5 секундам. Якщо зв'язок не відновилася, відправник намагається знайти інший маршрут до адресата. Якщо маршрут знайдений, лічильник спроб скидається в нуль і процедура відправки запускається знову. Допустима кількість спроб може лежати в діапазоні 1-255 (за замовчуванням - 10). При відсутності успіху сесія переривається.
Значення RTT визначається за часом відгуку найближчого маршрутизатора, яке подвоюється, а до отриманої величини додається деяка константа. Для кожної з сесій RTT визначається незалежно. Багаточасові константи задаються адміністратором мережі.
Протокол spx дозволяє здійснити від 100 до 2000 з'єднань одночасно (за умовчанням це число дорівнює 1000). Конфігураційні параметри SPX-протоколу (і мережі) зберігаються в файлах shell.cfg і net.cfg.
У 1992 році була розроблена нова версія SPX - SPX II. Головне удосконалення протоколу пов'язано із застосуванням пакетів більшого розміру. Раніше довгі spx-пакети фрагментувалися і пересилалися по частинах, враховуючи, що черговий пакет може бути посланий лише після отримання підтвердження, неважко зрозуміти крайню неефективність такої схеми. Стандарт spx дозволяє обмін пакетами з розміром, обмеженим тільки використовуваної мережевим середовищем. Так в Ethernet пакет SPX II може мати довжину 1518 байт. Крім того, SPX II допускає використання технології вікон, тобто можна послати кілька кадрів, не чекаючи отримання підтвердження на кожен з вже посланих. Розмір вікна встановлюється відповідно до кодом, що міститься в полі число-покажчик (число буферів / пакетів). При необхідності адміністратор може задати розмір вікна раз і назавжди. Формат пакетів SPX II дещо відрізняється від SPX. У SPX II збільшено число допустимих кодів для поля управління з'єднанням, введено додаткове поле в заголовок підтвердження (два байти, ім'я поля "розширене підтвердження"). Нове поле додано після поля число буферів. Алгоритм встановлення зв'язку в SPX II відрізняться від варіанту spx тим, що необхідно узгодити розмір пересилаються пакетів.
- 0x20 ATN (Attention) зарезервовано для спеціальних запитів (не підтримується SPX);
- 0x40 ACK Встановлюється для запиту підтвердження отримання даного пакету. Запити і відгуки обробляються на рівні SPX (додаток не повинно модифікувати цей код);
- 0x80 SYS Встановлюється, якщо даний пакет є системним і служить для підтвердження. Додатки не використовують пакети цього типу.
Управління мережами Novell здійснюється за допомогою стандартного протоколу SNMP (Simple Network Management Protocol) і керуючої бази даних MIB.
