Відмінності між версіями «IPX/SPX»

Матеріал з Вікі ЦДУ
Перейти до: навігація, пошук
Рядок 9: Рядок 9:
 
<center>[[Image:1 005.gif]]</center>
 
<center>[[Image:1 005.gif]]</center>
  
<center>Мал 1. Стек IPX / SPX</center>
+
<center>Мал 1. Стек IPX/SPX</center>
  
 
На фізичному і канальном рівнях в мережах Novell використовуються всі популярні протоколи цих рівнів (Ethernet, Token Ring, FDDI та інші).  
 
На фізичному і канальном рівнях в мережах Novell використовуються всі популярні протоколи цих рівнів (Ethernet, Token Ring, FDDI та інші).  

Версія за 12:38, 19 жовтня 2011

Стек 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.

1 005.gif
Мал 1. Стек IPX/SPX

На фізичному і канальном рівнях в мережах 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.

Imag223.gif
Мал 2. Формати мережних пакетів

З малюнка видно, що відмінності непринципові і не перешкоджають співіснування всіх перерахованих форматів у межах однієї локальної мережі. IPX-заголовок починається відразу після поля Тип або Довжина у залежності від використовуваного протоколу.

Сервери Netware можна настроїти так, щоб вони сприймали пакети різних типів, і тому могли мати безпосередні зв'язки з різними мережами. IPX-сервер може виконувати і функції маршрутизатора. Формат заголовка пакета IPX зображений на Мал 3. За заголовком слідують дані, їх обсяг визначається кодом поля Довжина пакета (мінус 30) і лежить в діапазоні від 0 до 546 байт.

Imag224.gif
Мал 3. Формат заголовка IPX-пакета

Поле Контрольна сума (2 байти) встановлюється IPX-драйвером рівним 0xffff, це означає, що контрольного підсумовування не проводилося. Додаткам дозволено використовувати поле контрольної суми при роботі з кадрами Ethernet II, ІЕЕЕ 802.2 і Ethernet SNAP і заборонено для роботи з кадрами ІЕЕЕ 802.3. Контрольна сума служить лише для контролю правильності IPX-заголовка і не має ніякого відношення до поля даних IPX-дейтаграми. Для того щоб працювати з контрольними сумами на NetWare-сервері, слід виконати команду set enable IPX checksum = n, де n вказує на те, що контрольна сума використана. Можливі значення n і їхній зміст наведено нижче в Таблиці 1 і Таблиці 2.

Таблиця 1.Поля заголовка IPX пакета для сервера
Код n Призначення для сервера
0 Контрольна сума не використовується
1 Контрольна сума використовується, якщо доступна клієнту
2 Контрольна сума повинна використовуватися


Таблиця 2.Поля заголовка IPX пакета для клієнта
Код 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.


Таблиця 3. Коди типу IPX-пакета
Тип пакета Значення
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.

Imag225.gif
Мал 4. Формат RIP-пакета в NetWare

Поле тип пакету містить код 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.

Imag226.gif
Мал 5. Схема відповідності протоколів Novell і моделі OSI

Протокол SAP (service advertising protocol) служить для отримання інформації про всі сервера, що є в мережі, і підтримує такі види запитів та функції:

  • запит SAP-сервісу;
  • оповіщення про відключення сервера;
  • моніторинг відгуків і деякі інші.

Кожному серверу NetWare присвоює номер, а деякі сервера можуть мати й ім'я. Номер сервера і його ім'я зберігаються в базі даних об'єктів bindary кожного сервера. Пакет запиту SAP-сервісу містить 2 байта типу пакету і два байти типу сервера. Поле тип пакета визначає, чи є даний пакет загальним запитом сервісу (код = 0x0003), або запитом найближчих послуг (код = 0x0001). Таблиця кодів поля тип сервера наведена нижче в Таблиці 4.


Таблиця 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


SAP-пакети-відгуки мають наступний формат (Мал. 6).

Imag227.gif
Мал 6. Формат пакета SAP

Поле тип пакета приймає значення 0x0002 для SAP-відгуків загального обслуговування (General Service Response) і 0x0004 для відгуку найближчого сервера. Запити про найближче сервері використовуються для пошуку в мережі сервера конкретного різновиду (пакет запиту містить лише перші два поля). Реально відгук буде отримано від всіх серверів даного типу, а не тільки від найближчого. Наскільки цей сервер близький, визначається за кількістю маршрутизаторів до нього. Ці запити / відгуки служать для складання списку доступних серверів. Поле тип сервера містить код доступного виду послуг, а в полі найменування сервісу записується ім'я послуги унікальне для даного сервера (довжина поля на рис. 4.2.1.5 дорівнює N). Поле адреса мережі являє собою 4-байтове число, яке ідентифікує адресу сервера. Поле адресу сайту характеризує адресу сервера в мережі. Служби NetWare вказують адресу 0x00.00.00.00.00.01. Поле дескриптор з'єднувача характеризує код з'єднувача, який буде використовувати сервер. Останнє поле - число кроків до сервера (число транзитних мереж) характеризує число маршрутизаторів між сервером і клієнтом. При відключенні сервера від мережі він повинен широкомовно розіслати SAP-повідомлення "Зупинка сервера". Повідомлення містить код сервера і його повна адреса.

SPX - протокол

SPX (Sequence Packet eXchange) і його вдосконалена модифікація SPX II є транспортні протоколи 7-рівневої моделі ISO. Це протокол гарантує доставку пакета і використовує техніку ковзаючого вікна (віддалений аналог протоколу TCP). У разі втрати або помилки пакет пересилається повторно, число повторень задається програмно. У протоколі SPX не передбачена широкомовна або мультікастінг-адресація. У SPX індукується ситуація, коли партнер несподівано перериває з'єднання, наприклад через обрив зв'язку. Пакети SPX вкладаються в пакети IPX. При цьому у полі тип пакета IPX записується код 5. Заголовок пакета SPX завжди містить 42 байта, включаючи 30 байт заголовка IPX-пакета, куди він вкладений.

Imag228.gif
Мал 7. Формат заголовка SPX-пакета

Поле управління з'єднанням визначає, чи є даний пакет системним чи прикладним. Це поле містить однобітові прапорці, використовувані 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 Встановлюється, якщо даний пакет є системним і служить для підтвердження. Додатки не використовують пакети цього типу.
Imag229.gif
Мал 8. Формат заголовка SPX-II

Управління мережами Novell здійснюється за допомогою стандартного протоколу SNMP (Simple Network Management Protocol) і керуючої бази даних MIB.