AppleTalk
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Сеть APPLETALK разработана компанией apple computer inc. (ЭВМ Macintosh, 1987 г) Эти сети могут работать в среде Ethernet, Token Ring, FDDI и localtalk (собственная сеть apple, использующая скрученные пары). В AppleTalk специфицирован собственный стек протоколов, которые управляют потоком данных в сети. Для целей маршрутизации AppleTalk использует модифицированную версию внутреннего протокола маршрутизации IGRP. Стек протоколов appletalk phase ii включает в себя (схема структуры стека протоколов показана на рис. 4.2.2.1; смотри , а также RFC-1378, -1419, -1504, -1742):
Протокол доступа к каналу Tokentalk (TLAP - Tokentalk link access protocol)
Протокол доступа к каналу Ethertalk (ELAP - Ethertalk link access protocol)
Протокол доступа к каналу Localtalk (LLAP - Localtalk link access protocol)
Протокол доставки дейтограмм (DDP - datagram delivery protocol)
протокол поддержки маршрутных таблиц (RTMP - routing table maintenance protocol)
Протокол определения адресов Appletalk (AARP - appletalk address resolution protocol)
Протокол работы с именами (NBP - name binding protocol)
Протокол для работы с зонной информацией (ZIP - zone information protocol)
Протокол откликов в Appletalk (AEP - appletalk echo protocol)
Протокол актуализации маршрутной информации (AURP - Appletalk update routing protocol)
Протокол управления потоком данных (adsp - appletalk data stream protocol)
Протокол сессий (ASP - Appletalk session protocol)
Протокол доступа к принтеру (PAP - printer access protocol)
Протокол операций (ATP - Appletalk transaction protocol)
Файловый протокол (AFP - Appletalk filing protocol)
Из рисунка 4.2.2.1 видно, что стек протоколов appletalk полностью согласуется с семиуровневой схемой OSI. DDP представляет собой протокол передачи данных, не ориентированный на соединение. Дейтограмма DDP использует 13-байтовый заголовок, который включает в себя:
поле числа маршрутизаторов (число шагов), через которые прошел пакет; поле длины дейтограммы; поле контрольной суммы; поля сети назначения и отправителя и т.д. (см.
рис. 4.2.2.2. - смотри ).
Вслед за заголовком следует информация, которая может содержать до 586 байт. Максимальный размер пакета (MTU) равен 599 байтам. Число узлов в сети может достигать 16 миллионов.
Рис. 4.2.2.1. Диаграмма стека протоколов appletalk
Протокол adsp позволяет двум программам обмениваться потоками информации в полном дуплексном режиме с гарантией доставки. Протоколы TLAP, ELAP и LLAP служат для обеспечения сопряжения с соответствующими физическими протоколами (Token Ring, Ethernet и Arcnet), скрывая от программ других уровней специфические особенности используемого сетевого оборудования. Протокол ATP надежно передает запросы и отклики, детектирует ошибки и организует пакетный обмен. Этот протокол используется в свою очередь протоколами ZIP, ASP и PAP, что видно из рис. 4.2.2.1. Протокол AFP является протоколом поддержки приложений и позволяет пользователям ЭВМ Macintosh работать с общими файлами. Программное обеспечение Netware для Macintosh включает в себя файл AFP NLMtm, который обеспечивает поддержку Netware-серверов. Протокол AURP (appletalk update-based routing protocol) служит для целей маршрутизации, но в отличии от некоторых других протоколов передает маршрутную информацию только в случае изменения ситуации. Он поддерживает также IP-туннели.
Рис. 4.2.2.2. Формат пакетов в сети Apple Talk Phase II (в скобках указаны размеры полей в байтах)
Адрес отправителя и получателя имеют по 24 бита, из них 16 бит составляет адрес сети. Идентификатор узла назначения (локальная часть адреса) выбирается произвольно самой рабочей станции при установлении связи. ЭВМ берет случайное 8-битовое число в качестве локального адреса и посылает его в сеть. Если какая-то ЭВМ использует этот адрес, она откликается, тогда код меняется и делается повторная попытка. Процесс продолжается пока не будет найден свободный адрес. Протокол RTMP является протоколом маршрутизации, где в качестве метрики используется вектор расстояния до адресата, этот протокол собирает маршрутную информацию и предоставляет ее протоколу DDP для обеспечения транспортировки пакетов по сети.
Маршрутные таблицы RTMP хранятся в каждом из маршрутизаторов AppleTalk и базируются на номерах сетей адресатов. Таблица содержит в себе расстояние до адресата, измеренное в шагах (hop), идентификатор порта маршрутизатора, через который достижим адресат, и статус маршрута.
Маршрутизаторы AppleTalk формируют и актуализируют маршрутные таблицы, посылая регулярно (раз в 10 сек) широковещательные RTMP-пакеты соседним узлам и сетям. Запись в маршрутной таблице, своевременно не подтвержденная, спустя определенное время стирается. Записи в маршрутной таблице попадают в разряд “подозреваемых” при отсутствии отклика от них в течение 20 сек, в разряд “умирающих” - спустя 40 сек, в категорию “умерших” - через 60 сек. Запись удаляется из таблицы, если отклик не удается получить в течение 80 сек.
Адреса сетевого уровня ставятся в соответствие адресам MAC-уровня с помощью адресного протокола AARP. Узлы сети Apple Talk хранят эту информацию в специальных таблицах (AMT - Address Mapping Table). Таблица просматривается всякий раз, когда AppleTalk посылает пакет. Если поиск не увенчался успехом, узел-отправитель посылает широковещательный AARP-запрос. При получении отклика на этот запрос вносятся коррективы в AMT-таблицу. Особенностью сети AppleTalk является согласование при присвоении локальных адресов объектам сети. При инициализации узла ему присваивается временный адрес. Протокол AARP проверяет, не принадлежит ли данный адрес кому-то еще, для этого он посылает 10 AARP-запросов. Если данный временный адрес уже используется, инициализируемому узлу присваивается новый временный адрес и процедура проверки повторяется до тех пор, пока узлу не будет присвоен уникальный адрес. Протокол NBP преобразует локальные AppleTalk адреса в имена, присвоенные сетевому объекту пользователем и наоборот. Это избавляет пользователя от необходимости помнить полный сетевой адрес принт- или файл-сервера, почтового сервера и т.д..
Протокол ZIP допускает логическое группирование оконечных сетевых узлов в некоторые объединения, называемые зонами, что позволяет ЭВМ, принадлежащие к одному отделу, но расположенные в разных зданиях, находиться в одной зоне (субсети).
Зона может представлять собой комбинацию локальных сетей, а в случае EtherTalk Phase II - часть локальной сети. Информация о зонах хранится в маршрутизаторах в виде специальных таблиц (ZIT - Zone Information Table). Таблица содержит по одной записи на сетевой сегмент. Запись включает в себя номер сетевого сегмента и список объектов, входящих в зону. Протокол ZIP отслеживает изменения в RTMP-таблицах и при появлении в них записей, относящихся к новым объектам или сетям, маршрутизатор посылает ZIP -запрос и на основе полученной информации корректирует ZIT-таблицу.
Протокол AEP выполняет отладочные и диагностические функции, предоставляя возможность выполнения процедур ping (до какой-то степени это аналог протокола ICMP). При необходимости проверить состояние сети или какого-либо узла посылается AEP-дейтограмма, а зондируемый узел, который при ее получении должен послать отклик отправителю исходного запроса. Протокол позволяет проверить время распространения пакетов между узлами сети. Протокол может использоваться в начале любой сессии для проверки доступности того или иного сетевого объекта.
Протокол AURP является внешним протоколом сетевой маршрутизации и служит для взаимодействия сетей AppleTalk c Интернет. Протокол поддерживает технологию IP-туннелей с использованием UDP/IP инкапсуляции. Рассылка сетевой информации осуществляется AURP только при возникновении каких-либо изменений в состоянии сети. Протокол AURP поддерживает гибкую систему переадресаций, исключая конфликты адресов при подключении новых сетей AppleTalk, и выявляет маршрутные петли. Существуют специальные фильтры, которые позволяют разделять пакеты по приоритетам, что бывает важно, например, при передаче мультимедиа информации. Сети AppleTalk хорошо согласуются с другими сетями, например, NetWare. Следует иметь в виду, что ЭВМ, работающие с протоколами Phase I и Phase II, могут работать друг с другом только через специальные мосты, так как форматы пакетов для этих протоколов не совместимы.
Управление сетями Apple Talk осуществляется с помощью протокола SNMP и управляющей базы данных MIB.
IPX-протокол
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Протокол IPX предназначен для передачи дейтограмм в системах, неориентированных на соединение (также как и IP или NETBIOS, разработанный IBM и эмулируемый в Novell), он обеспечивает связь между NetWare серверами и конечными станциями. Максимальный размер IPX-дейтограммы составляет 576 байт, из них 30 байта занимает заголовок. Предполагается, что сеть, через которую транспортируются эти дейтограммы, способна пересылать пакеты соответствующей длины. IPX-пакеты могут рассылаться широковещательно, для этого поле типа должно принять значение 0x14, адрес сети назначения должен соответствовать локальной сети, адрес узла назначения при этом принимает значение 0xFFFFFF.
Оригинальный транспортный протокол Novell, на мой взгляд, не способствует успеху этой сети. Не успев своевременно переориентироваться на транспортные и маршрутные протоколы стека TCP/IP этот крайне популярный совсем недавно вид сетей в настоящее время имеет шансы исчезнуть.
IPX-пакеты, передаваемые по сети Ethernet, могут иметь несколько разных форматов. Старейший из них носит в Novell название “802.3” (информацию об интеграции сетей Novell и Интернет можно найти в документах: RFC-1234, -1420, -1553, -1634, -1792) и используется по умолчанию в версиях вплоть до 3.11. В последующих версиях форматом по умолчанию является “802.2”. Применим также и формат, называемый Ethernet II, который наиболее близок идеологии TCP/IP. Сеть в Netware - это логический канал, который используется совместно рядом узлов так, что они могут взаимодействовать друг с другом непосредственно. Так процессы, реализуемые на одном сервере, считаются подключенными к внутренней IPX-сети. Все пользователи сети типа Ethernet II образуют логическую сеть IPX. Все пользователи одной сети типа 802.3 рассматриваются как узлы различных сетей IPX. Сопоставление форматов пакетов для различных сетевых стандартов представлено на рис. 4.2.1.1.
Рис. 4.2.1.1. Форматы сетевых пакетов
Из рисунка видно, что различия непринципиальны и не препятствуют сосуществованию всех перечисленных форматов в пределах одной локальной сети.
IPX- заголовок начинается сразу после поля Тип или Длина в зависимости от используемого протокола.
Серверы Netware можно сконфигурировать так, чтобы они воспринимали пакеты разных типов, и поэтому могли иметь непосредственные связи с разными сетями. IPX-сервер может выполнять и функции маршрутизатора. Формат заголовка пакета IPX показан на рис. 4.2.1.2. За заголовком следуют данные, их объем определяется кодом поля Длина пакета (минус 30) и лежит в диапазоне от 0 до 546 байт.
Рис. 4.2.1.2. Формат заголовка IPX-пакета
Поле Контрольная сумма (2 байта) устанавливается ipx-драйвером равным 0xffff, это означает, что контрольного суммирования не производилось. Приложениям разрешено использовать поле контрольной суммы при работе с кадрами Ethernet II, ieee 802.2 и Ethernet SNAP и запрещено для работы с кадрами ieee 802.3. Данное ограничение можно легко понять, обратившись к рис. 4.2.1.1. Контрольная сумма служит лишь для контроля правильности IPX-заголовка и не имеет никакого отношения к полю данных IPX-дейтограммы. Для того чтобы работать с контрольными суммами на NetWare-сервере, следует выдать команду set enable IPX checksum=n, где n указывает на то, что контрольная сумма использована. Возможные значения n и их смысл приведены ниже в таблице 4.2.1.1.
Таблица 4.2.1.1
| Код n | Назначение в сервере |
| 0 | Контрольная сумма не используется |
| 1 | Контрольная сумма используется, если доступна клиенту |
| 2 | Контрольная сумма должна использоваться |
| То же для клиента | |
| 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-драйвер заполняет остальные поля. Возможные значения кода поля тип пакета представлены в таблице 4.2.1.2.
Таблица 4.2.1.2 Коды типа 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; cм. также RFC-1058) обеспечивает конечные станции информацией, которая необходима для динамического управления оптимизацией маршрутов.
Рассылка маршрутной информации производится с помощью широковещательных пакетов. Как видим, сети Novell являются источником значительных потоков широковещательных пакетов. Аналогичным образом объекты сети оповещаются о других изменениях в сетевой среде, например, рассылка информации о доступных услугах (SAP - service advertisement protocol). Протокол SAP позволяет узлам, которые предлагают определенные услуги (например, файл-серверы или принт-серверы), сообщать о своих адресах и видах доступных услуг. Администратор может регулировать поток таких пакетов, задавая постоянные времени для таймеров обновления информации. Маршрутизаторы рассылают маршрутную информацию в пяти случаях:
При инициализации.
В случае, когда необходима исходная маршрутная информация (напр. в случае сбоя или порчи маршрутной таблицы).
Периодически для обновления маршрутных таблиц.
При изменении конфигурации маршрутов.
При отказе или отключении маршрутизатора.
Маршрутизация пакетов в сети достаточно проста. Каждому сетевому сегменту маршрутизатор присваивает номер в пределах от 1 до fffffffe. Каждой группе устройств присваивается “сетевой номер”, который представляет эту группу во всех маршрутизаторах сети. Пакеты, посылаемые от одного члена группы другому, посылаются непосредственно. Пакеты от одного члена группы к объекту из другой группы будут пересланы через маршрутизаторы. Для выбора маршрута в пределах локальной сети используется маршрутный протокол RIP. Формат пакета NetWare RIP показан на рис. 4.2.1.3.
Рис. 4.2.1.3. Формат 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-маршрутизаторы хранят полную карту сети, по которой принимаются решения о наилучших возможных маршрутах.
На рис. 4.2.1.4 представлена схема соответствия протоколов Novell и 7-уровневой модели osi.
Рис. 4.2.1.4. Схема соответствия протоколов Novell и модели osi
Протокол SAP (service advertising protocol) служит для получения информации обо всех серверах, имеющихся в сети, и поддерживает следующие виды запросов и функции:
запрос SAP-сервиса;
оповещение об отключении сервера;
мониторинг откликов и некоторые другие.
Каждому серверу NetWare присваивает номер, а некоторые сервера могут иметь и имя. Номер сервера и его имя хранятся в базе данных объектов bindary каждого сервера. Пакет запроса SAP-сервиса содержит 2 байта типа пакета и два байта типа сервера. Поле тип пакета определяет, является ли данный пакет общим запросом сервиса (код=0x0003), или запросом ближайших услуг (код=0x0001). Таблица кодов поля тип сервера приведена ниже (4.2.1.3).
Таблица 4.2.1.3 Коды тип сервера (cм. также )
| Тип сервера | Описание |
| 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-пакеты-отклики ( периодически рассылаемые пакеты) имеют следующий формат (рис. 4.2.1.5).
Рис. 4.2.1.5. Формат пакета SAP
Поле тип пакета принимает значение 0x0002 для SAP-откликов общего обслуживания (General Service Response) и 0x0004 для отклика ближайшего сервера. Запросы о ближайшем сервере используются для поиска в сети сервера конкретной разновидности (пакет запроса содержит лишь первые два поля). Реально отклик будет получен от всех серверов данного типа, а не только от ближайшего. Насколько данный сервер близок, определяется по числу маршрутизаторов до него. Эти запросы/отклики служат для составления списка доступных серверов. Поле тип сервера содержит код доступного вида услуг, а в поле наименование сервиса записывается имя услуги уникальное для данного сервера (длина поля на рис. 4.2.1.5 равна N). Поле адрес сети представляет собой 4-байтовое число, которое идентифицирует адрес сервера. Поле адрес узла характеризует адрес сервера в сети. Службы NetWare указывают адрес 0x00.00.00.00.00.01. Поле дескриптор соединителя характеризует код соединителя, который будет использовать сервер. Последнее поле - число шагов до сервера (число транзитных сетей) характеризует число маршрутизаторов между сервером и клиентом. При отключении сервера от сети он должен широковещательно разослать SAP-уведомление “Останов сервера”. Уведомление содержит код сервера и его полный адрес.
Наложенные сети
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
В отличие от локальных наложенные сети не требуют использования специальных аппаратных средств для подключения. Так, если ЭВМ подключена к Ethernet (к ArcNet или Token Ring), нужны только соответствующие программные средства, чтобы она стала узлом сети Novell. Почтовая сеть (протоколы SMTP или UUCP) и сеть новостей (Usenet, протокол NNTP) относятся к наложенным сетям. Интернет (семейство протоколов TCP/IP) является также примером наложенной сети. Проблематика Интернет выделена в самостоятельный раздел лишь в силу объема и разнообразия материалов. Одна и та же ЭВМ может быть узлом нескольких разных наложенных сетей. Смешанные сети могут создавать проблемы для администраторов сетей, но для пользователей они дают лишь дополнительные возможности. В таких сетях неизбежно возникает проблема присвоения имен и установки соответствия между виртуальными и физическими адресами (в Интернет эта проблема решается с помощью протокола ARP).
NetBIOS
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Протокол NetBIOS был создан для работы в локальных сетях. Система NetBIOS предназначена для персональных ЭВМ типа IBM/PC в качестве интерфейса, независящего от фирмы-производителя. NetBIOS использует в качестве транспортных протоколов TCP и UDP. Описание NetBIOS содержится в документе IBM 6322916 "Technical Reference PC Network" (см. также RFC-1001-2, -1088 и STD-48).
Пакет NETBIOS (см. также ) создан для использования группой ЭВМ, поддерживает как режим сессий (работа через соединение), так и режим дейтограмм (без установления соединения). 16-и символьные имена объектов в netbios распределяются динамически. netbios имеет собственную dns, которая может взаимодействовать с интернетовской. Имя объекта при работе с NETBIOS не может начинаться с символа *.
Приложения могут через netbios найти нужные им ресурсы, установить связь и послать или получить информацию. NETBIOS использует для службы имен порт - 137, для службы дейтограмм - порт 138, а для сессий - порт 139.
Любая сессия начинается с netbios-запроса, задания ip-адреса и определения tcp-порта удаленного объекта, далее следует обмен NETBIOS-сообщениями, после чего сессия закрывается. Сессия осуществляет обмен информацией между двумя netbios-приложениями. Длина сообщения лежит в пределах от 0 до 131071 байт. Допустимо одновременное осуществление нескольких сессий между двумя объектами.
При организации IP-транспорта через NETBIOS IP-дейтограмма вкладывается в NETBIOS-пакет. Информационный обмен происходит в этом случае без установления связи между объектами. Имена Netbios должны содержать в себе IP-адреса. Так часть NETBIOS-адреса может иметь вид, ip.**.**.**.**, где IP указывает на тип операции (IP через Netbios), а **.**.**.** - ip-адрес. Система netbios имеет собственную систему команд (call, listen, hang up, send, receive, session status, reset, cancel, adapter status, unlink, remote program load) и примитивов для работы с дейтограммами (send datagram, send broadcast datagram, receive datagram, receive broadcast datagram).
Все оконечные узлы netbios делятся на три типа:
Широковещательные ("b") узлы;
узлы точка-точка ("p");
узлы смешанного типа ("m").
IP-адрес может ассоциироваться с одним из указанных типов. B-узлы устанавливают связь со своим партнером посредством широковещательных запросов. P- и M-узлы для этой цели используют netbios сервер имен (NBNS) и сервер распределения дейтограмм (NBDD).
В настоящее время (1985 г) разработана улучшенная версия протокола NETBIOS - NetBeui (NetBios extended user interface). Этот новый протокол используется операционными системами LAN manager, LAN server, Windows for Workgroups и Windows NT, а по своей функции занимает нишу протоколов TCP/IP, охватывая связной, сетевой и транспортный уровни. Здесь стандартизован формат пакетов NetBios, добавлены некоторые новые функции. netbuei базируется на протоколе OSI LLC2, вводит стандарт на формат кадра netbios (NDF) и использует NetBios в качестве интерфейса высокого уровня. Протокол обладает высоким быстродействием и служит для объединения небольших локальных сетей (20-200 ЭВМ) друг с другом или с главной ЭВМ. Этот протокол соответствует связному, сетевому и транспортному уровню модели OSI. В новых версиях NetBuei (3.0 и выше) снято ограничение на число одновременных сессий (254). Среди ограничений NetBuei следует назвать отсутствие внутренней маршрутизации и серьезные ограничения при работе в региональных сетях. По этой причине netbuei рекомендуется для локальных сетей (здесь они предпочтительнее других протоколов), а для внешних связей использовать, например, TCP/IP.
Для подключения терминальной системы к локальной сети или к другой терминальной системе разработан протокол NBFCP (NetBios frames control protocol, код поля протокола = 803F), который в свою очередь базируется на протоколе PPP.
Формат кадра протокола NBFCP показан на рис. 4.2.3.1.
Рис. 4.2.3.1. Формат кадра NBFCP
Поле тип содержит код 2, поле длина определяет размер заголовка, если длина=8, имя партнера отсутствует.
Поле класс партнера идентифицирует тип системы отправителя (см. таблицу 4.2.3.1). Таблица возможных значений поля класс партнера приведена ниже. Поле имя партнера может иметь до 32 октетов.
Таблица 4.2.3.1 Коды класса партнера
Код класса | Описание |
| 1 | Зарезервировано |
| 2 | Сервер внешнего порта PPP NetBIOS |
| 3 | Зарезервировано |
| 4 | Сервер локального доступа PPP NetBIOS |
| 5 | Зарезервировано |
| 6 | Мост PPP NetBIOS |
| 7 | Зарезервировано |
| 8 | Терминальная система PPP |
Протокол WINS
Протокол WINS разработан компанией MicroSoft для операционной среды Windows и предназначен для расширения возможностей NetBIOS.
WINS-запросы обычно транспортируются в UDP-дейтограммах. При этом используется порт отправителя=137. В поле данных размешается 2-октетное поле идентификатора, позволяющего связать запрос с откликом. Далее следует 2 байта флагов, в случае запроса туда записывается 0. За ним размещается два октета, содержащие число вопросов, 2 октета числа ответов и еще 4 нулевых октетов. Завершается кадр запроса двумя октетами поля типа (00 21 -> статус узла NetBIOS) и полем класса (для Интернет 00 01 -> (IN,1)). Такие запросы позволяют получить дополнительные данные (имя узла, его MAC-адрес, NetBIOS-имя, имя группы) об ЭВМ с заданным IP-адресом. Причем эта ЭВМ может находиться где угодно в Интернет, но непременно работать в OS Windows. Формат поля данных UDP-дейтограммы запроса показан на рис. 1.
Рис. 4.2.3.2. Формат запроса WINS
В поле данных UDP-дейтограммы отклика располагается 2-байтовое поле идентификатора, аналогичного содержащемуся в пакете запроса. Далее следует поле флагов с длиной в два октета. Формат поля данных UDP-дейтограммы отклика показан на рис. 2.
Рис. 4.2.3.2. Формат отклика WINS
Поле флаги имеет следующую структуру:
0 _ _ _ | _ _ _ _ | Команда |
_ 000 | 0 _ _ _ | Запрос |
_ _ _ _ | _ _ 0 _ | Не укорочено |
_ _ _ _ | _ _ _ 0 | Рекурсия нежелательна |
_ _ _ _ | _ _ _ 0 | Рекурсия нежелательна |
1_ _ _ | _ _ _ _ | Отклик |
_ 000 | 0 _ _ _ | Запрос |
_ _ _ _ | _ _ 0 _ | Не укорочено |
_ _ _ _ | _ 1 _ _ | Официальный ответ |
/p> Для поля флаги имени характерна следующая структура
0_ _ _ | _ _ _ _ | Уникальное имя NetBIOS |
_ 10 _ | _ _ _ _ | |
_ _ _ _ | _ 1 _ _ _ | Активное имя |
_ _ _ _ | _ _ 0_ | Временное имя |
Для поля флагов имени группы характерно следующее назначение бит
1 _ _ _ | _ _ _ _ | Имя группы NetBIOS |
_ 10 _ | _ _ _ _ | Узел М-типа |
_ _ _ _ | _ 1 _ _ _ | Активное имя |
_ _ _ _ | _ _ 0_ | Временное имя |
Протокол WINS весьма удобен для сбора данных о МАС-адресах ЭВМ в многоранговой сети, где получить эти данные с помощью ARP-запросов невозможно. Какие-то данные можно извлечь из кэша маршрутизаторов или таблиц сетевых переключателей, если они доступны с помощью SNMP-запросов. Но WINS может дать больше данных, если рабочая станция использует операционную систему Windows. Так что, когда, скажем, программа Black ICE Defender пришлет вам MAC-адрес атакера, сидящего на другом континенте, не удивляйтесь, на помощь был призван протокол WINS.
Протокол ядра NetWare (NCP)
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
NCP представляет собой язык общения серверов и клиентов в среде NetWare. NCP-пакет вкладывается в SPX. Рабочие станции передают свои запросы на запись или чтение файлов, на создание очереди заданий, на поиск в дисковых каталогах и т.д. в виде NCP-сообщений. Прежде чем клиент пошлет NCP-запрос, он должен подключиться к серверу и выдать заявку на формирование NCP-канала связи. Сервер в ответ на этот запрос присылает отклик, в котором содержится подтверждение создания такого канала связи, если запрос удовлетворен. Каждому запросу должен соответствовать отклик. Формат NCP-запроса показан на рис. 4.2.1.3.1.
Рис. 4.2.1.3.1. Формат заголовка пакета NCP
Поле тип запроса характеризует запрос, передаваемый от клиента к серверу, возможные значения кодов этого поля приведены ниже (таблица 4.2.1.4).
Таблица 4.2.1.3.1 Значения кодов поля тип запроса
| Код | Описание запроса |
| 1111 | Создание канала обслуживания |
| 2222 | Запрос сервиса |
| 5555 | Ликвидация канала обслуживания |
| 7777 | Пересылка в пакетном режиме |
Поле номер по порядку используется для отслеживания последовательности связи между клиентом и сервером. Клиент записывает в это поле код, равный номеру по порядку плюс единица. В полях номера канала записан номер, присвоенный клиенту при его регистрации сервером. Поле номер задачи идентифицирует каждую из задач, сделавших запрос. Сервер следит за выполнением задачи и освобождает ресурсы при завершении выполнения. Номер задачи равный нулю говорит серверу, что все задания окончены. Старшая часть номера канала используется лишь при наличии более чем 1000 пользователей, в остальных вариантах это субполе содержит нуль. Сервер в своем отклике сообщает клиенту результаты выполнения его запроса. Отклик, также как и запрос, вкладывается в IPX/SPX-пакет. Формат пакета-отклика показан на рис. 4.2.1.3.2.
Рис. 4.2.1.3.2. Формат заголовка NCP-отклика
Поле тип отклика может содержать следующие коды (таблица 4.2.1.3.2):
Таблица 4.2.1.3.2 Коды откликов
| Код типа отклика | Описание |
| 3333 | Отклик |
| 7777 | Соединение для протокола Burst Mode |
| 9999 | Запрос обрабатывается |
Сервер отвечает на большую часть запросов, помещая код 3333 в поле типа отклика. Если запрос клиента помещен в очередь, а клиент по таймауту выдал еще один запрос, ему присылается отклик типа "Запрос обрабатывается". Станция клиента при этом сбросит таймер в исходное состояние, добавит 1 к счетчику попыток и продолжит ожидание. По умолчанию запрос можно повторить 20 раз. Поле код завершения указывает на характер завершения выполнения запроса клиента. Код нуль говорит об успешном завершении, любое другое число - об ошибке. Поле состояние канала содержит флаги, характеризующие статус канала, клиенты NetWare должны проверять код этого поля во всех пакетах, приходящих от сервера. Кроме заголовка (запросов и откликов) каждое NCP-сообщение должно содержать в себе код NCP-процедуры, характеризующий запрашиваемую услугу. Часто помимо кода процедуры необходимо указать и ее субкод. Перечень кодов процедур и их функций приведен в приложении.
Помимо стандартных пакетов в среде Novell используются несколько вспомогательных видов пакетов. Это пакеты "сторожевая собака" (Watchdog), сериализации (serialization) и сообщения. Пакеты "сторожевая собака" после IPX-заголовка имеет поля номера канала и сигнатура. Поле номера канала отмечает канал станции, присвоенный ей при регистрации. Поле сигнатура содержит код 0x3F. Если отклика от рабочей станции нет, то сервер передает с интервалом 59 сек 10 аналогичных "собачих" пакетов. Если отклика добиться не удастся, связь со станцией будет разорвана. Период и число таких запросов администратор может изменять в широких пределах.
Так как система NetWare продается для каждого сервера отдельно, чтобы контролировать случаи нелегальной загрузки, по сети рассылаются широковещательные пакеты сериализации. Цель такой рассылки - проверка наличия в сети нескольких копий одного и того же программного обеспечения. Пакеты сериализации содержат 36 байт, включая IPX-заголовок, и передаются раз в 66 сек. Эти пакеты помимо IPX-заголовка включают в себя только поле данных (6 байт), где содержится информация о серийном номере программного продукта.Пакеты сериализации всегда посылаются на вход соединителя (socket) с номером 0x0457. При обнаружении нелегальной копии всем пользователям рассылается уведомление "Copyright violation".
Пользователи NetWare могут передавать сообщения рабочим станциям, группам и другим пользователям. Для каждой станции NetWare резервирует буфер для сообщений. Консоль отображает принятое сообщение немедленно, буфер же сохраняет сообщение и может уведомлять о нем пользователя. Для передачи сообщений используется команда SEND.
Протокол межсетевой передачи больших пакетов (LIP)
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Новый протокол LIP (Large Internet Packet Protocol, 1992 год) разработан Novell для того, чтобы максимально эффективно реализовать возможности, предоставляемые внешними каналами связи. Для повышения производительности операций чтения и записи разработан также протокол пакетного режима (Burst Mode Protocol). Этот протокол позволяет рабочим станциям передавать один запрос на чтение или запись и получать в ответ до 64 Кбайт данных, не посылая дополнительных запросов (используется технология BNETX и VLM). Длина пакета является результатом соглашения между отправителем и получателем, которое достигается в результате диалога. При этом прикладные программы не должны поддерживать пакетный режим (он реализован в оболочке системы). При использовании протокола пакетного режима BNETX клиент и сервер должны быть соответственно подготовлены. На сервере загружается модуль NLM (PBURST.NLM). Согласование размера пакета реализуется путем посылки оболочкой пакетного режима специального запроса на установление соединения с сервером. Это в свою очередь накладывает ограничение на минимальный размер каждого из используемых буферов. Если совершается попытка клиента установить связь в пакетном режиме с сервером, который этот режим не поддерживает, то будет послано сообщение "NO Such Property", а обмен будет производиться в обычном режиме (NCP-запрос-отклик). Отличие пакетных режимов в BNETX и VLM заключается в управлении скользящим окном. VLM (VLM.EXE), в отличии от BNETX, не устанавливает верхнего предела размера окна. По умолчанию размер окна (число посланных пакетов без подтверждения получения) при чтении равно 16, а при записи - 10. Формат кадров протокола пакетного режима предполагает наличие IPX-заголовка, за которым следует NCP-заголовок пакетного режима. Далее следуют данные. Формат кадра пакетного режима показан на рис. 4.2.1.10. Поле тип запроса NCP-запроса или отклика содержит код 0x7777. Возможные значения флагов перечислены ниже (таблица 4.2.1.6).
Таблица 4.2.1.4.1 Значения поля флаги
| Флаг | Описание |
| sys | При равенстве 1 указывает на то, что это системный пакет и не несет в себе данных |
| sak | Пока не используется, но равенство 1 должно потребовать от получателя присылки списка утраченных фрагментов |
| eob | Равенство 1 показывает, что пакет содержит последнюю порцию данных, присланных отправителем. |
| bsy | Пока не используется, зарезервирован для индикации занятости сервера. |
| abt | Равенство 1 сообщает клиенту о том, что сессия прервана. |
Рис. 4.2.1.10 Формат кадра пакетного режима
В скобках на рисунке указаны размеры полей в байтах. Поле тип потока в данное время может содержать только код 0x02 и означает, что передаются длинные блоки пакетов. Поле идентификатор отправителя является случайным числом и представляет собой уникальный идентификатор канала, работающего в пакетном режиме. Код этого поля формируется отправителем и не должен равняться нулю. Идентификатор канала получателя также случайное число, но задается адресатом и также не должно содержать нуль. Поле номер пакета по порядку служит для отслеживания текущей пакетной операции и увеличивается на единицу для каждого нового пакета. Поле время задержки передачи означает величину задержки между отправкой пакетов и измеряется в сотнях микросекунд. Поле номер блока пакетов идентифицирует принадлежность пакета к конкретному блоку (данные, посылаемые по запросу, образуют один блок). При установлении связи код этого поля делается равным нулю. В дальнейшем при выполнении каждого запроса его значение увеличивается на 1. Поле порядковый номер подтверждения содержит номер блока пакетов, ожидаемый следующим. Поле служит для контроля доставки блоков пакетов. Поле полная длина блока пакетов задает длину блока в байтах и равно сумме длин всех пакетов в блоке. Поле указатель блока пакетов определяет положение конкретного пакета, указатель равный нулю говорит о том, что это первый пакет. Поле длина блока задает длину блока пакетов в октетах. Поле элементы списка фрагментов задает число элементов, пропущенных в процессе реализации пакетной сессии.Если это число равно нулю, пропущенных фрагментов не было. Поле функция определяет разновидность операции (чтение или запись), реализуемой в данной сессии. Последующие поля служат для операций с файлами.
Протоколы Novell (IPX/SPX)
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Межсетевой протокол IPX - (Internetwork Packet eXchange; Novell (См. также А.В.Фролов, Г.В.Фролов, “Локальные сети персональных компьютеров. Использование протоколов IPX, SPX, NETBIOS. Москва, “Диалог-МИФИ”, 1993), ) соответствует сетевому уровню модели ISO, до какой-то степени это аналог IP-протокола в Интернет. IPX-протокол может работать совместно с SPX при обеспечении обменов, ориентированных на соединение, где гарантируется доставка информации. IPX произошел от протокола XNS (Xerox Network Services) и имеет ряд уникальных черт. Так IPX может использовать различные схемы инкапсуляции в зависимости от физической сетевой среды. В операционной среде MS-DOS за реализацию протокола IPX отвечает программа IPX.COM или IPXODI.COM. Оболочка же системы NetWare (NETX.COM) и DOS Requester (VLM.COM) используют протокол IPX для пересылки запросов файл-серверу.
Первоначально пакеты Novell инкапсулировались в кадры IEEE 802.3. В настоящее время схема инкапсуляции поддерживает 802.2 и протокол SNAP (Sub-Network Access Protocol).
Служба каталогов NetWare (NDS)
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
С точки зрения службы каталогов netware (NDS - netware directory services) сеть - это не совокупность ЭВМ, а интегрированная информационная среда. При регистрации в сети клиент получает доступ ко всем ее ресурсам. Для повышения надежности и сокращения времени доступа к сети база данных службы каталогов netware распределена по сети. Отдельные фрагменты базы данных могут располагаться на разных серверах, и могут быть задублированы на нескольких серверах, имеются специальные сетевые средства для синхронизации изменений в этих секциях. Все эти вещи порождают в сети дополнительный трафик, ведь необходимо сравнивать содержимое секций базы данных, их обновление, читать и изменять записи и т.д. Одной из важнейших функций службы каталогов является синхронизация работы ее частей. Синхронизация предполагает определение порядка операций по обслуживанию каталога. В службе каталогов все серверы делятся на:
Главный эталонный временной сервер (устанавливает время для вторичных серверов и клиентов, время устанавливается супервизором, при наличии в сети таких серверов применение первичных и эталонных временных серверов не допускается);
Первичный сервер (синхронизует сетевое время, по крайней мере, с еще одним первичным или эталонным сервером, время устанавливается по выбранному сетевому времени);
Эталонный сервер (задает время для всех остальных серверов и клиентов, синхронизируется от внешнего источника, например, службы времени, первичные серверы должны согласовывать свое время с эталонным сервером);
Вторичный сервер (синхронизируется от главного эталонного, первичного или просто эталонного сервера).
Существует пять функций NCP, которые поддерживают взаимодействие со службой каталогов Netware. Имеются также функции службы каталогов. Коды функций вставляются в пакеты, посылаемые службой каталогов, и служат в качестве субфункций основных NCP-операций. Таблица (4.2.1.5.1) функций и субфункций службы каталогов представлена ниже.
Таблица 4.2.1.5.1 Основные NCP-функции
Вид сервиса | Тип запроса | Код операции | Код субфункции |
| ping для nds ncp (запрос о NDS) | 2222 | 104 | 01 |
| Посылка фрагментированного NDS запроса/отклика | 2222 | 104 | 02 |
| Закрытие NDS-фрагмента | 2222 | 104 | 03 |
| Возврат контекста bindary | 2222 | 104 | 04 |
| Мониторирование NDS-связи | 2222 | 104 | 05 |
Запрос nds в режиме ping позволяет запросить сервер о поддержке им операции с кодом 104. Если сервер может выполнить эту операцию, он посылает позитивный отклик, который содержит имя дерева каталога и его глубину. При посылке фрагментированного nds запроса присылается фрагментированный отклик. При обновлении секции каталога netware передает последовательность nds-фрагментов, содержащих изменения данной секции. Формат таких пакетов показан на рис. 4.2.1.5.1. В скобках указаны размеры полей в байтах. Поле максимальный размер фрагмента несет в себе максимальное число байт, которое может быть послано в качестве отклика. Код в этом поле соответствует максимуму, поддерживаемому сетевой средой минус 8 (сумма длин поля длины отклика и поля дескриптора фрагмента). Поле флага фрагмента всегда содержит нуль. Поле внутренняя функция хранит в себе код операции для службы каталогов netware. Таблица команд службы каталогов приведена в приложении .
В netware имеется развитая собственная система сетевой диагностики, которая позволяет выяснить реальную конфигурацию сети (возможно, что-то не включено или уже сломалось), ее загруженность или частоту ошибок (diagnostic responder). Узлы сети с загруженной программой diagnostic responder должны откликаться на диагностические пакеты, адресованные им или разосланные широковещательно. Наличие отклика говорит о доступности данного сетевого объекта, а его содержимое может нести в себе информацию о конфигурации (наличие IPX/SPX, драйвера локальной сети, программы маршрутизатора или файлового сервера).
Рис. 4.2.1.5.1. Формат пакетов "Фрагментированный NDS-запрос/отклик"
Диагностические запросы содержат код 0x0456 в поле соединителя получателя IPX-заголовка. Формат такого запроса показан на рис. 4.2.1.5.2.
Однобайтовое поле счетчика исключаемых узлов задает число станций, которые могут не присылать отклик. Нуль в этом поле предполагает, что все станции должны откликнуться. Допустимый диапазон значений кодов в этом поле 0 - 79. При широковещательной рассылке запроса можно сделать так, чтобы сервер и определенные клиенты на запрос не реагировали. Для этого их адреса помещаются в поля адресов исключаемых узлов. Число таких исключений может достигать 80.
Рис. 4.2.1.5.2. Формат диагностического запроса
Структура пакета-отклика показана на рис. 4.2.1.5.3. В зависимости от числа компонентов конфигурации пакет-отклик может иметь различную длину. Поля базового и вспомогательного номера версии характеризуют вариант программы diagnostic responder (например, 1.1). Поле номер диагностического соединителя SPX указывает на соединитель, которому отсылаются все диагностические отклики. Поле счетчик компонентов содержит число описаний компонентов, содержащихся в пакете. Поле тип компонента описывает один из компонентов (или процессов) узла, посылающего отклик. Описание компонента может быть простым и расширенным. Простое описание содержит один байт идентификатора компонента. Расширенное описание компонента включает в себя информацию о маршрутизаторах, файл-серверах и невыделенных IPX/SPX. Первое поле в этом случае представляет собой идентификатор расширенного описания, который характеризует тип компонента:
Таблица 4.2.1.5.1. Коды типа компонентов
| Код компонента | Тип компонента | Описание |
| 0 | IPX/SPX | IPX/SPX-процесс или модуль на выделенном файл-сервере, маршрутизаторе или у клиента. |
| 1 | Драйвер маршрутизатора | Процесс драйвера маршрутизации. |
| 2 | Драйвер локальной сети | Процесс драйвера интерфейса локальной сети на файл-сервере или маршрутизаторе. |
| 3 | Оболочка | Модуль-эмулятор или оболочка DOS на рабочей станции (netx.com) |
| 4 | vap | Модуль-эмулятор или оболочка DOS на сервере netware 2.x или внешнем маршрутизаторе для поддержания VAP. |
| 5 | Маршрутизатор | Маршрутизирующий компонент внешнего порта сети (gateway) |
| 6 | Файловый сервер/маршрутизатор | Маршрутизирующий компонент файл-сервера (внутренний маршрутизатор или мост). |
| 7 | Невыделенный IPX/SPX | IPX/SPX-процесс на невыделенном файл-сервере netware 2.x, внешнем порте сети или локальной сети версий 3.x. |
Далее следует поле числа локальных сетей, характеризующее количество сетей, обменивающееся данными с данным компонентом. Для каждой из сетей указывается ее тип, а также адрес сети и узла. Поле типа сети содержит код типа (таблица 4.2.1.5.2).
Таблица 4.2.1.5.2 Коды типа сети
| Код типа сети | Компонент |
| 0 | Интерфейс локальной сети |
| 1 | Невыделенный файл-сервер |
| 2 | Перенаправленная удаленная линия |
Поле адреса сети имеет 4 байта, а поле адреса узла 6 байт, перенаправленные удаленные линии имеют адрес узла 0x00-00-00-00-00-00. Внутренние сети IPX версий 3.x и 4.x имеют адрес узла 0x00-00-00-00-00-01.
Рис. 4.2.1.5.3 Формат пакета диагностического отклика
Сервера Novell за счет протоколов RIP и SAP могут заметно загрузить локальную сеть широковещательными сообщениями. По этой причине не следует бездумно множить число таких серверов.
SPX-протокол
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
SPX (Sequence Packet eXchange) и его усовершенствованная модификация SPX II представляют собой транспортные протоколы 7-уровневой модели ISO. Это протокол гарантирует доставку пакета и использует технику скользящего окна (отдаленный аналог протокола TCP). В случае потери или ошибки пакет пересылается повторно, число повторений задается программно. В протоколе SPX не предусмотрена широковещательная или мультикастинг-адресация. В SPX индицируется ситуация, когда партнер неожиданно прерывает соединение, например из-за обрыва связи. Пакеты SPX вкладываются в пакеты IPX. При этом в поле тип пакета IPX записывается код 5. Заголовок пакета SPX всегда содержит 42 байта, включая 30 байт заголовка IPX-пакета, куда он вложен (см. рис. 4.2.1.2.1).
Рис. 4.2.1.2.1. Формат заголовка SPX-пакета
Поле управления соединением определяет, является ли данный пакет системным или прикладным. Это поле содержит однобитовые флаги, используемые spx и spx ii для управления потоком данных в виртуальном канале.
| 0x01 XHD | Зарезервировано SPX II для расширения заголовков; |
| 0x02 RES1 | Назначение поля не определено, должно быть равно нулю; |
| 0x04 NEG | SPX II (SIZ) согласует размер запроса/отклика, для spx должно быть равно нулю; |
| 0x08 SPX2 | Тип пакета SPX II, для spx должно быть равно нулю; |
| 0x10 EOM | Устанавливается клиентом spx для индикации конца сообщения (end-of-message); |
| 0x20 ATN | (attention) зарезервировано для специальных запросов (не поддерживается SPX); |
| 0x40 ACK |
Устанавливается для запроса подтверждения получения данного пакета. Запросы и отклики обрабатываются на уровне SPX (приложение не должно модифицировать этот код); |
| 0x80 SYS |
Устанавливается, если данный пакет является системным и служит для подтверждения. Приложения не используют пакеты этого типа. |
Поле тип потока данных характеризует тип данных, помещенных в пакет. Значения этого поля перечислены ниже:
| 0x00-0x07 | определяется клиентом и может использоваться в приложениях; |
| 0x80-0xfb | зарезервированы на будущее; |
| 0xfc | spx ii, упорядоченное освобождение запроса; |
| 0xfd | spx ii, упорядоченное освобождение подтверждения; |
| 0xfe | указывает на окончание связи (end-of-connection). При закрытии канала spx-драйвер посылает клиенту пакет, где в поле тип потока записан данный код; |
| 0xff |
подтверждение получения сообщения об окончании связи (end-of-connection-acknowledgment). Этим кодом помечается пакет, подтверждающий закрытие канала, в прикладную программу такой пакет не передается |
/p> Поля идентификатора отправителя и получателя содержат коды, определяющие участников информационного обмена, присваиваются 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 тем, что необходимо согласовать размер пересылаемых пакетов.
Рис. 4.2.1.2.2. Формат заголовка SPX-II
Управление сетями Novell осуществляется с помощью стандартного протокола SNMP (Simple Network Management Protocol) и управляющей базы данных MIB.
