Кратко

  • RFC 2351 определил сеанс MATIP поверх TCP, чтобы согласовать тип трафика, мультиплексирование, заголовки, представление символов и состав терминалов.
  • Open Confirm подтверждал параметры связи, но не резерв места, выписку билета или окончательную доставку сообщения Type B.
  • Разрешение повторить Type-A-запрос после отсутствия ответа обнажило неопределённость: молчание не показывает, потерялся запрос, ответ или только наблюдение пользователя.

Самая важная граница появляется в RFC 2351 ещё до описания форматов пакетов. Интерактивный трафик Type A мог быть отброшен; если ответа не было, пользователь мог продублировать запрос. Это практическое правило восстановления не доказывало, что первая попытка не изменила систему.

Запрос мог не дойти. Центральное приложение могло его отклонить. Оно могло изменить остаток мест, после чего пропал только обратный ответ. На терминале все варианты выглядели одинаково. Для учёта и повторной отправки они означали разное.

MATIP решал более узкую задачу. Авиационные терминалы и центральные приложения появились раньше массового TCP/IP. Их одновременная замена была слишком дорогой. Общая схема инкапсуляции позволяла использовать стандартный транспорт, сохраняя прикладные протоколы и установленные устройства.

Общий транспорт не стал общей бизнес-логикой

Документ различал Type A для диалога и обмена между хостами и Type B для сообщений с повышенной защитой, несколькими адресатами и уровнями приоритета. Детальные форматы оставались в стандартах IATA и двусторонних соглашениях.

MATIP располагался между TCP и авиационным приложением. Порты 350 и 351 разделяли типы. После установки TCP стороны обменивались Session Open и Open Confirm, согласуя подтип, мультиплексирование, заголовок, кодировку и, при необходимости, список ASCU. Разные наборы параметров требовали отдельных сеансов.

Карточка RFC Editor называет документ Informational. Это не обязательный стандарт Интернета и не отчёт о внедрении. Это совместимый способ объявить характеристики канала между уже существующими системами.

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

Open Confirm отвечал на ограниченный вопрос

Для диалогового Type A ответ мог отклонить сеанс, принять его полностью или условно, перечислив настроенные либо отвергнутые ASCU. Он служил точным доказательством согласованной конфигурации.

Он не содержал универсального идентификатора брони, версии инвентаря, фиксации тарифа или бухгалтерской записи билета. Смысл payload задавало авиационное приложение. MATIP переносил этот смысл, но не получал власть объявлять итог.

Особенно показателен новый Session Open в уже открытом сеансе: прежняя конфигурация очищалась и заменялась. TCP-соединение могло оставаться непрерывным, хотя прикладной состав терминалов менялся. Непрерывность транспорта не равна непрерывности сеанса, а та не равна непрерывности транзакции.

Type B сохранял ту же границу. Рукопожатие проверяло совместимость характеристик связи. Сообщение всё ещё должно было соответствовать правилам выбранного сервиса. Принятый сеанс не доказывал доставку каждому адресату или завершение последующей операции.

TCP надёжен в пределах собственного объекта

RFC 793 определяет надёжный упорядоченный поток байтов между процессами. Подтверждение TCP относится к байтам. Оно не санкционирует бронирование и не вносит запись в билетный учёт.

После разрыва удалённый стек мог подтвердить байты до прикладного commit. Возможна и обратная картина: приложение совершило commit, но клиент не получил ответ. Для фактически однократного выполнения нужны устойчивый бизнес-идентификатор, сохранённое состояние и способ прочитать результат после переподключения. IP-адрес, ASCU и сеанс MATIP автоматически такой ролью не обладают.

Защита канала также не заменяет результат. RFC упоминает статическую конфигурацию, имя и пароль, межсетевой экран и необязательный IPsec; опубликованное предупреждение говорит, что безопасность раскрыта недостаточно. Целостность канала, допуск стороны, разрешение приложения и итоговая запись — четыре разных свидетельства.

История без выдуманной статистики внедрения

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

Аргумент Lu Heng о первичности работающего кода помогает прочитать эту сдержанность: общий сигнал силён ровно настолько, насколько независимые системы могут проверить его смысл. Если «сеанс принят» превращается в «билет выписан», символ получает полномочие без наблюдаемого исполнения. Принцип минимальной начальной спецификации предлагает нормировать только необходимое для совместимости, оставляя локальные решения тем, кто несёт последствия.

RFC 2351 вывел старые авиационные терминалы на дорогу IP. Реестр мест остался в приложении.