Кратко
- Транспортные стороны выбирали две 16-битные ссылки, по которым находили Transport Connection независимо от Network Connection, несущей TPDU.
- Multiplexing помещал несколько транспортных соединений в одно сетевое, а splitting в классе 4 позволял одному транспортному состоянию использовать несколько носителей.
- Независимость ограничивали качество сети, pervasive-функции, подтверждённый класс и правила восстановления. Путь не был идентичностью соединения, но оставался его реальной зависимостью.
В RFC 892 Transport Connection (TC) должна была быть назначена на Network Connection (NC) до передачи данных. При splitting разрешалось несколько NC. Подходящее нижнее соединение можно было взять из уже существующих или создать заново.
Назначение не превращало два объекта в один. NC доставляла протокольные единицы между транспортными сущностями. TC представляла двустороннее состояние, которое видели пользователи транспорта. Один носитель мог пережить отдельную TC, а одна TC — при наличии нужного класса — сменить носитель.
Статус документа также был ограничен. RFC 892 распространяла текст ISO для информации и прямо не являлась стандартом ARPA Internet. RFC 905 заменила её более поздней редакцией ISO DP 8073, сохранив информационную роль. Публикация RFC не доказывает, что Интернет принял пятиуровневую модель ISO transport.
Ссылку выбирал тот, кто будет её распознавать
Инициатор отправлял Connection Request TPDU (CR) со своей source reference. Ответчик посылал Connection Confirm (CC) со своей ссылкой. После этого каждый использовал чужое значение как destination reference.
Поле имело 16 бит и локальный смысл. Ноль, занятое или ещё замороженное значение использовать нельзя. Это не глобальное имя и не удостоверение стороны. Значение указывало на живую запись в таблице получателя.
RFC 892 называла схему симметричной: роли master и slave не требовались, а одновременные вызовы не зависели от единственного распределителя. Так TC получала идентификацию, независимую от NC.
Однако TPDU с правильным числом всё равно должна была прийти через допустимое назначение, на верном этапе и между теми же транспортными сущностями. Ссылка доказывала принадлежность к протокольному состоянию, а не личность, полномочие или результат приложения.
Предпочтение в CR не имело силы выбора в CC
Класс 0 был простым. Класс 1 восстанавливался после сигнализированных ошибок. Класс 2 давал multiplexing. Класс 3 совмещал восстановление и multiplexing. Класс 4 обнаруживал и исправлял потерю, повтор, повреждение и нарушение порядка.
Инициатор помещал в CR preferred class и альтернативы; для предпочтения class 0 альтернативы запрещались. До ответа он мог начать функции в расчёте на первый выбор. Но расчёт оставался временным. CC сообщал selected class, и инициатор перестраивался под разрешённый ответ.
Максимальный размер TPDU согласовывался отдельно. Ответчик мог принять предложение или уменьшить его до допустимой величины. Proposed options также требовали selected options. Существующая NC, корректный CR, желание вызывающей стороны и подтверждённая TC — не одно событие.
Нижнее качество влияло на выбор. RFC 892 различала Network Service по остаточным ошибкам и сообщаемым отказам, учитывала требования и стоимость. Доступная NC могла быть непригодной из-за качества или несовместимой pervasive-функции, уже общей для её транспортных соединений.
Общий носитель не делал общим транспортное состояние
Multiplexing позволял нескольким TC делить одну NC. Destination reference в TPDU направляла данные в правильную запись. Экономия на нижних соединениях не объединяла последовательности, окна и жизненный цикл разных разговоров.
При этом pervasive-функция создавала общее условие: после включения для первой TC её следовало применять ко всем TC на данной NC до конца её жизни. Носитель не определял идентичность, но связывал поведение соседей.
Splitting and recombining менял мощность отношения в другую сторону. Одна TC могла использовать несколько NC ради устойчивости или throughput. Таблица RFC 892 относила функцию к class 4, а не ко всем соединениям. Это спецификация ограниченной возможности, не утверждение о всеобщем multipath.
Reassignment давал другой вид продолжения. В классах, использовавших механизм, provider-initiated disconnect позволял назначить TC на новую NC и выполнить resynchronization. Партнёр узнавал продолжение по допустимой TPDU, адресам тех же transport entities и существующим ссылкам.
Class 0 показывал предел: отдельной процедуры освобождения транспорта не было, жизнь TC напрямую коррелировала с NC. Поэтому реальную независимость нельзя выводить из одного слоистого рисунка — нужен выбранный class.
Позднее нижним сервисом стал TCP
RFC 983 предложила предоставлять наружу ISO TSAP, а внутри опираться на TCP/IP. Верхние ISO session, presentation и application entities могли не знать о нижней замене. Полный план перехода документ не обещал.
RFC 1006 заменила предложение версией 3 и стандартизовала ISO transport class 0 поверх TCP. TCP передаёт поток октетов, тогда как TP0 ждёт дискретные единицы. Поэтому TPDU заключили в TPKT с длиной. Обрамление восстанавливало границу, но не аутентифицировало источник.
TCP open представлял нижнее установление, TCP close — disconnect. Для class 0 сроки жизни вновь сближались. Тем не менее интерфейс ISO transport и TPDU сохранились поверх другого нижнего протокола.
RFC 2126 уточнила работу по TCP через IPv4 или IPv6 и описала варианты class 0 и class 2. Версию TPKT сохранили ради установленной базы RFC 1006. Порт TCP 102 был зарезервирован, но не объявлен обязательным для любого соединения.
Современный реестр IANA имён служб и портов содержит iso-tsap на 102. Запись доказывает координацию номера, не запущенную реализацию, подтверждённый class, живую reference или успех приложения.
Источники и границы
Материал опирается на RFC 892, RFC 905, RFC 983, RFC 1006, RFC 2126 и реестр IANA. Они устанавливают механизмы, статус текста и отображение на TCP. Они не доказывают современное внедрение, принятие OSI Интернетом, прямую родословную QUIC или SCTP, всеобщий splitting, аутентификацию партнёра или поведение названного продукта.
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
