Кратко

  • RFC 2126 сохранил TPKT version 3 ради базы RFC 1006, но одинаковый номер больше не доказывал согласие по Class 0, Class 2 или опциям срочных данных.
  • Выбранный класс, второй канал, порядок между каналами и удалённая доставка при недеструктивном закрытии были разными состояниями с разными квитанциями.

RFC 2126 особенно ясно показывает границу между принятием в локальную ответственность и завершением удалённой доставки. Эта граница появилась в конце соединения, но выросла из решения, принятого в самом начале: оставить version 3.

Документ марта 1997 года обновлял RFC 1006 и описывал ISO Transport поверх TCP для IPv4 и IPv6. Class 0 сохранял прежнюю основу, Class 2 добавлял явное разъединение и новые варианты Expedited Data. Номер TPKT не сменили, чтобы не отсечь старые реализации.

Одинаковая версия не означала одинаковый класс

Старый peer мог не уметь согласовывать класс. Инициатор отправлял CR Class 2 без альтернативы, а получал CC Class 0. TCP работал, ответ разбирался, но его следовало отвергнуть по ISO 8073.

Version подтверждал знакомый конверт. CR фиксировал запрос, CC — выбор, локальное решение — приемлемость выбора. Сводное состояние connected скрывало несогласие. Reserved field также требовалось игнорировать на входе ради совместимости, а не превращать в неофициальный capability bit.

Независимость и порядок были разными свойствами

ED TPDU мог идти внутри normal channel. Forward или Reverse Connection создавал отдельный TCP, чтобы занятый обычный канал не блокировал срочный. Второй канал связывал ту же пару хостов, принадлежал одной Transport Connection и закрывался вместе с ней.

Эта привязка не доказывала момент готовности. Для Forward RFC оставлял время открытия реализации. И два независимых TCP не доказывали общий порядок.

Forward/Reverse обеспечивал independence. Expedited Data Acknowledgement или Non-blocking Expedited Data мог обеспечивать synchronisation. Независимость без синхронизации ослабляла определение ISO Transport и не соответствовала ISO 8072.

Обычная причина скрывала два контракта

Class 0 разрывал транспорт через TCP, то есть disruptive. Class 2 обменивался DR/DC и предлагал Disruptive и Non-Disruptive.

В первом случае оставшиеся у источника TPDUs не требовалось отправлять; reason 80 hex. Во втором всё уже переданное локальному TS-provider должно было попасть удалённому TS-user до закрытия. Reason оставался 80, а Additional Information 80 указывал усиленное обязательство.

Следовательно, локальный приём был началом custody, не удалённой квитанцией. Запись normal close без mode не позволяла восстановить договор.

Координация номера не доказывала работу

TCP 102 был зарезервирован, но не обязателен для каждой связи. Строка IANA iso-tsap подтверждает распределение номера, а не listener, Class 2 или результат приложения. RFC также не добавлял безопасности и прямо приравнивал её границы к TCP и ISO 8073.

Опубликованные тексты Lu Heng используются здесь как открытая современная линза: утверждение ограничивается наблюдаемым running code; минимальная спецификация не присваивает будущие решения; символический статус не заменяет исполняемый результат.

RFC 2126 не доказывает, что сохранять номер было ошибкой. Он показывает плату за разумную совместимость. Чем стабильнее внешний знак, тем важнее сохранить внутренние квитанции: version, запрос класса, выбор, принятие, второй канал, синхронизация, локальная custody и удалённая доставка.

Источники