Кратко

  • RFC 2353 сознательно использовал UDP/IPv4 как нативный канальный уровень для APPN/HPR: восстановление и порядок обеспечивал HPR RTP, проверку жизни — LDLC.
  • Остановка проверок на простаивающем канале экономила трафик, но позволяла одному узлу удалить отказавшую связь, пока сосед сохранял её активной.
  • Повторную активацию могли отвергнуть как неподдерживаемый параллельный канал, а новую сессию — отправить в уже удалённое состояние. Согласие возвращалось через измерение и перестроение.

Распределённая система редко узнаёт об отказе одновременно. У каждого участника есть собственный таймер, пакет и момент наблюдения. RFC 2353 превратил эту банальность в подробный механизм восстановления APPN/HPR поверх IP.

Документ опубликован в мае 1998 года как Informational RFC, а не Internet Standard. Он фиксировал архитектуру, которую APPN Implementers’ Workshop утвердил в статусе “Closed Pages” в декабре 1997 года. Это означало детализацию для совместимых реализаций в рамках процесса, не современную распространённость.

IP становился нативным канальным управлением для HPR, сохранялись выбор пути и классы обслуживания APPN, а модель connection network уменьшала объём предварительной настройки. UDP выбрали потому, что функции надёжности уже жили выше.

UDP не хранил связь

RFC 768 задаёт минимальную службу датаграмм с портами, длиной и контрольной суммой. RFC 791 задаёт IPv4-датаграммы и маршрутизацию. Они не сообщают HPR о завершении соединения.

RFC 2353 отдавал потерю, дублирование, задержку, нарушение порядка и потерю связности верхним слоям. Собственный RTP протокола HPR — не позднейший IETF Real-time Transport Protocol — выполнял выборочные повторы, восстановление порядка и адаптивное управление. LDLC отвечал за логический канал и liveness. TCP дублировал бы очереди и таймеры.

Получались разные квитанции: наблюдение UDP/IP, восстановление RTP, ответ LDLC. Ни одна не содержала состояние памяти соседа.

Экономия проверок создавала разные часы

Поскольку UDP не уведомлял об обрыве, LDLC периодически проверял HPR/IP-каналы. Среди значений по умолчанию документ называл десять секунд для liveness, пятнадцать для retry и три попытки.

Опция разрешала прекратить проверки, если данных нет. Нижняя инфраструктура могла отдыхать. Но после сбоя одна сторона могла узнать о нём раньше.

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

Оба журнала оставались честными. Разными были моменты знания.

Отказ требовал проверки старого состояния

При отказе из-за параллельного канала RFC требовал запустить liveness на связанных активных каналах, особенно при одинаковой паре IP и иных парах SAP. Старая запись должна была снова доказать актуальность.

Если activation XID совпадал с активным каналом по IP и SAP, прежний экземпляр следовало деактивировать и разрешить его восстановление; таймер ограничивал влияние случайных XID. Перед окончательной реакцией на LDLC-отказ рекомендовалась повторная активация.

Коды X'10160045' и X'10160046' объясняли локальную причину отказа для определённых или динамических параллельных связей. Они не доказывали первую точку отказа, удалённую обработку или результат сессии.

Надёжность и общий статус — разные свойства

HPR RTP мог восстановить порядок и доставку в своём диапазоне, не синхронизируя автоматы LDLC. Успешная проверка жизни не означала успешной APPN-сессии. Sense data не воспроизводили всю удалённую историю.

Безопасность также стояла отдельно: SNA-аутентификация и шифрование сессий, IPsec для UDP, фильтры межсетевого экрана. Защищённый пакет не согласовывает устаревшие состояния.

RFC Editor и Datatracker подтверждают статус документа. RFC 1122 даёт требования к хостам, но не состояние удалённого HPR-канала.

Принцип Лу Хэна о первичности работающего кода ограничивает локальную запись тем, что примет работающий сосед. Минимальная спецификация и локальные решения требуют проверяемых переходов, а уровни реальности разделяют датаграмму, жизнь, канал, сессию и итог.

RFC 2353 не объявлял каждую тишину отказом. Он показывал, что тишина не подтверждает согласие. Если измерение отключено, восстановление должно создать новое доказательство.