Кратко

  • Строка каталога в RFC 2024 показывала, где узел DLSw считал доступным MAC-адрес или имя NetBIOS; она не объявляла канал конечных станций работающим.
  • Транспорт, канал, управление темпом и сведения об отключении отвечали на разные вопросы и составляли цепочку доказательств.

Операторский вопрос «доступен ли ресурс?» кажется единым. RFC 2024 отвечал несколькими таблицами. Каталог указывал местонахождение. Таблица транспорта показывала, завершили ли два узла DLSw обмен возможностями. Таблица каналов отслеживала путь между конечными станциями. Поля темпа сообщали, сколько сообщений SSP ещё разрешено отправить до ожидания. Ни одна запись не создавала состояние, описанное другой.

Каталог хранил локальное представление

Таблицы MAC-адресов и имён NetBIOS связывали ресурс с указателем местонахождения. Он мог вести к локальному интерфейсу, настроенному транспортному соединению, действующему соединению, пустой ссылке или таблице конкретной реализации. Состояние «неизвестно», «доступно» или «недоступно» выражало то, что DLSw в данный момент считал верным для этого места.

Статические примеры подчёркивают ограниченность. Запись могла начинаться как неизвестная. Один удалённый ресурс мог быть указан через нескольких партнёров. Порядок кандидатов не гарантировался, а спор одинаково точных статических и динамических сведений мог решаться реализацией. После неудачного поиска состояние «недоступно» могло прежде всего предотвращать немедленный повтор.

Каталог сокращал область поиска. Он не доказывал подключение выбранного партнёра, начало установления канала или ответ конечной станции.

У транспорта была собственная шкала времени

Операционное соединение проходило состояния установления, начального обмена возможностями, подключения, успокоения, разрыва и отключения. «Подключено» означало, что партнёры определили возможности друг друга и готовы к сообщениям установления каналов. Это не было результатом от конца до конца.

Связь с конфигурацией также могла устареть. dlswTConnOperConfigIndex указывал на управляющую строку, но становился нулём после её удаления. Изменения после подключения не обязательно описывали все ранее согласованные условия. Поэтому время подключения следовало сравнивать со временем последнего изменения настроек.

Реализация могла сохранять операционную строку после разрыва ради статистики и причины отказа, без обязательного срока. Полученные от партнёра возможности оставались читаемыми в истории. Заполненное поле не подтверждало текущую доступность.

Канал появлялся после обнаружения

RFC 2024 разделял запуск на два этапа. Сначала исследовательские сообщения находили адрес или имя, затем начиналось установление канала. Строка канала появлялась только на втором этапе.

У канала была отдельная последовательность состояний. Записываемым являлось лишь disconnectPending; команды на повторное установление не было, поскольку процесс инициировали конечные станции. Причины разрыва и ссылки на нижележащие MIB LLC или SDLC сужали поиск. Некоторые показатели трафика также требовали перехода по ссылкам. Это подсказки, а не самостоятельный отчёт о первопричине.

Квоты темпа имели столь же точный смысл: сколько синхронизированных сообщений SSP сторона вправе отправить до остановки. Ноль мог означать, что темп не используется. Текущее или наибольшее окно не считало доставленные сообщения и не доказывало завершение прикладной работы.

Уведомление фиксировало переход

При переходе транспорта или канала в подключённое состояние агент мог отправить trap. Отправка настраивалась и могла быть отключена. Полученное уведомление доказывало локально отмеченный переход и доставку самого сообщения, но не сохранение состояния, согласие второго узла или отсутствие последующего разрыва. Отсутствие trap также не доказывало, что перехода не было.

Время и причина разрыва, а также признак активных каналов уточняли картину. Последний говорил, что пользователи могли пострадать, но не считал их и не подтверждал деловой ущерб. Позднее RFC 2166 добавил к RFC 1795 общие причины HALT: отключение станцией, ошибка DLC, ошибка протокола канала, действие оператора. Старые партнёры могли не передать причину, а детали поставщиков различались. Сигнал становился точнее, но не превращался в окончательную причину.

Полная картина могла быть распределена

RFC 2024 прямо предупреждал: для полной картины может понадобиться опрос нескольких узлов DLSw. Чтобы не дублировать сведения, часть данных определялась как полученная от партнёра. Протокол также не связывал управляемый транспортный адрес партнёра с адресом его протокола управления.

Каждая строка была локальным свидетельством с ограниченной областью. Различие Heng Lu между записью и описываемой ею реальностью даёт полезную современную оптику: запись может быть точной, не охватывая всё рабочее состояние. Это аналитическое применение, а не утверждение о намерениях авторов RFC.

Нужно не отвергать таблицы, а сохранять связи. Каталог поддерживает вывод о местонахождении, транспорт — состояние партнёров и время согласования, канал — путь станций, нижние MIB — локальные признаки линии. При сравнении обоих узлов они объясняют услугу; сведённые к зелёному индикатору, скрывают решающее различие.

Источники