Кратко

  • Мастер MTP ставил accepted, увидев data[eom] и все промежуточные пакеты; неполное сообщение оставалось pending либо становилось rejected в зависимости от оценки состояния отправителя.
  • Скользящий вектор передавал три состояния последних двенадцати сообщений и не позволял вытеснить unresolved pending: выдача новых токенов должна была остановиться.
  • Успешные потребители обычно молчали, а потери вызывали NAK, поэтому транспортное согласие не было индивидуальной квитанцией, аутентификацией, обработкой или операционным итогом.

Протокол выбрал действие перед знанием причины

Одна из самых честных частей RFC 1301 описывает повторный запрос токена. Управляющие пакеты не расходовали обычные номера, поэтому мастер не всегда мог понять, новая это просьба или повтор старой. Производитель мог не получить подтверждение. Он мог получить его и отправить данные, которые целиком пропустил мастер. Наконец, повторный запрос мог обогнать задержавшееся подтверждение.

MTP не назначал одной версии прошлого. Пока токен выглядел pending, мастер мог назначить его снова. Получив дубликат token confirm, производитель считал его аналогом NAK и повторял данные с тем же номером сообщения. Ненужный токен возвращался через empty[cancel].

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

Best effort был исходным условием

RFC 1112 определял IP multicast для динамической группы хостов. Доставка имела ту же надёжность best effort, что и обычный IP: не гарантировались ни целостная доставка каждому участнику, ни относительный порядок.

RFC 1301 добавлял транспорт. Совокупность процессов называлась web. Один участник обязательно был мастером; остальные могли производить и потреблять данные либо только потреблять. Мастер управлял членством, параметрами и токенами передачи. Производитель получал токен с номером сообщения, прежде чем отправлять обычные клиентские данные.

Сетевой слой размножал дейтаграммы. Токен задавал очередь производителей. Статус создавал общее решение. Приложение всё ещё находилось выше и одно знало смысл байтов.

Успех оставался без положительного ответа

MTP использовал отрицательные подтверждения. Обнаружив пропуск, потребитель отправлял NAK. Не обнаружив пропуска, он обычно не посылал производителю положительный ACK. Так протокол избегал шквала обратного трафика от большой группы.

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

Если поздний отчёт пишет «все подтвердили», он добавляет свидетельства, которых дизайн намеренно не создавал. Допустимо записать решение мастера и известные NAK; подтверждение приложения нужно искать отдельно.

Accepted означал полноту у мастера

Мастер принимал сообщение, если видел data[eom] и все предшествующие пакеты. Неполное сообщение оставалось pending, пока отправитель считался работающим и связанным с мастером. Если мастер считал, что отправитель отказал или оказался за разделением сети, сообщение получало rejected.

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

Клиентские данные для MTP были неинтерпретируемыми октетами. Транспорт мог принять полный поток, а приложение — отвергнуть просроченную, повторную, неверную или неразрешённую операцию. Эти два результата принадлежат разным уровням.

Двенадцатая позиция не позволяла забыть pending

Запись принятия содержала флаг синхронизации и двенадцать двухбитовых элементов. Accepted, pending и rejected относились к предыдущим номерам. При продвижении новые состояния сдвигали старые, и завершённая история исчезала из заголовка.

Но нерешённый pending нельзя было вытолкнуть за край. Мастер обязан был перестать подтверждать новые token requests, пока самое старое сообщение не станет accepted или rejected. Неопределённость превращалась в видимую остановку, а не маскировалась новыми номерами.

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

Шестнадцатибитные номера сообщений инициализировал и увеличивал мастер. Выданный номер считался израсходованным и требовал финального состояния. Он задавал порядок внутри экземпляра транспорта, но не вечную идентичность бизнес-действия.

Heartbeat и retention ограничивали доказательство

heartbeat задавал общий ритм. window ограничивал сумму новых и повторных пакетов производителя за один интервал. retention определял, сколько интервалов хранить данные и состояние для восстановления.

Если полного пакета клиентских данных ещё не было, а сообщение не завершилось, производитель отправлял empty[dally]. Короткие сообщения дополнялись пустыми пакетами до количества не меньше retention. Это увеличивало вероятность, что потребитель увидит хотя бы один пакет и распознает производителя; оно не гарантировало наблюдение каждым.

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

Если данные уже вышли из хранения, nak[deny] сообщал невозможность восстановления. Получатель докладывал сбой клиенту и мог покинуть web. Завершение retention не превращало прежнее молчание в доказанный успех.

Транспортные имена не удостоверяли участника

MTP поверх IP требовал Level 2 RFC 1112, использовал постоянную группу 224.0.1.9 и bridge-заголовок с портами, длиной и необязательной checksum под IP protocol 92. TSAP и connection identifier различали транспортные экземпляры.

Они не аутентифицировали владельца. RFC 1301 прямо не рассматривал безопасность. Членство, роль мастера и токен — состояния протокола, а не доказательства личности, организации или административного разрешения.

Поздняя оценка показала стоимость центра

RFC 1458 рассматривал MTP для доставки больших изображений. Он описал токены, flow control, выборочное восстановление NAK и дубликаты, но указал на внешние зависимости адресов и идентификаторов и на задержку и перегрузку, когда почти весь управляющий трафик проходит через мастера. Для изученной нагрузки MTP сочли неподходящим.

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

Источники

Источники устанавливают исторические правила и обзор дизайна, но не реальный MTP web, число получателей, аутентифицированных участников, обработку приложением, инцидент, распространение или современный итог.