Кратко

  • Частичная надёжность SCTP позволяет прекратить передачу отдельного сообщения, не закрывая ассоциацию и не отменяя надёжную передачу остальных сообщений.
  • FORWARD TSN передаёт получателю границу, до которой ожидание можно прекратить. Эта граница учитывает отказ от данных, а не только их фактическое получение.
  • Время жизни, число повторов и приоритет в буфере определяют усилия отправителя. Они не доказывают доставку и не отменяют действия, которые приложение получателя уже совершило.

Три разных значения слова «остановиться»

Для SCTP фраза «перестать отправлять сообщение» скрывает три разных состояния. Первое возникает до присвоения TSN: сообщение так и не заняло место в общей последовательности. Второе — после присвоения TSN: отправитель локально отказался от дальнейших попыток, но у другой стороны всё ещё может быть ожидание этого номера. Третье — получатель получил право продвинуться через точно ограниченный пропуск.

Эти состояния нельзя заменить одним полем «истекло». У каждого свой владелец доказательства. До-TSN состояние известно очереди отправителя. Локальный отказ после TSN следует из политики сообщения и отправляющей реализации. Разрешение получателю пропустить позицию существует только внутри согласованной процедуры FORWARD TSN, а фактическое продвижение подтверждается уже состоянием получателя.

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

Остановка до номера: обязательство не стало общим

Срок жизни присутствовал уже в интерфейсе RFC 2960. Если первая попытка не могла начаться вовремя, транспорт мог отказаться от задания и уведомить верхний уровень. Если попытка началась до истечения срока, базовая служба требовала продолжить надёжную передачу. Это различие сохранили RFC 4960 и RFC 9260.

Примечание к реализации разрешало откладывать назначение TSN и для простоты считать назначение номера моментом обязательства. В политике с ограничением времени RFC 3758 проверка перед TSN особенно ясна: если сообщение уже просрочено, номер не выдаётся, сообщение отбрасывается, верхний уровень следует известить. FORWARD TSN не требуется, потому что у получателя не возникло нумерованной дырки.

Доказательство здесь отрицательное и локальное: ни одна часть сообщения не была отправлена и TSN не связал её с последовательностью. Оно не равно сетевой потере и не говорит о состоянии получателя — получателю в этой ветви нечего разрешать пропускать.

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

Остановка после номера: отправитель меняет свою обязанность

После присвоения TSN сообщение уже вошло в транспортный контекст. Перед передачей или повторной передачей политика времени может обнаружить истечение; тогда от сообщения отказываются по правилам расширения. Приложение не должно менять срок после передачи сообщения SCTP.

Локальная бухгалтерия рассматривает DATA-блок, от которого отказались, как окончательно закрытый и больше не держит его среди незавершённых отправок. Но такая внутренняя обработка не является подтверждением получения. Байты отброшенных данных запрещено включать в partial_bytes_acked и использовать для роста окна перегрузки. Отказ от усилия не создаёт доказательство пропускной способности пути.

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

Именно отправитель хранит различие между реальным накопительным подтверждением из SACK и Advanced.Peer.Ack.Point, рассчитанным с учётом отказов. В примере RFC исходная отметка равна 102, TSN 103 и 104 помечены как отброшенные, 105 остаётся надёжным и неподтверждённым — от него не отказались, — а 106 подтверждён. Локальная граница достигает только 104. Поздний успех 106 не даёт права перепрыгнуть обязательство 105.

Остановка ожидания: разрешение принадлежит общей процедуре

Когда Advanced.Peer.Ack.Point превышает реальный накопительный SACK, отправитель может послать FORWARD TSN — но лишь если поддержка расширения была согласована при установлении ассоциации. Способность реализации сама по себе недостаточна. Если сторона не объявила поддержку или старый партнёр промолчал, отправлять этот блок нельзя.

В согласованной ассоциации FORWARD TSN сообщает границу, до которой получатель может перестать ждать TSN, от которых отправитель отказался. Он не утверждает, что эти данные получены. Для упорядоченных сообщений он также несёт сведения о потоке и номере сообщения, чтобы освободить последующие сообщения. Неупорядоченные данные не следует помещать в записи упорядоченной последовательности.

У получателя есть отдельный пример. Его накопительная отметка равна 102, 103 отсутствует, 104 и 105 уже находятся у него; 106 отсутствует, а 107 присутствует. FORWARD TSN до 103 сначала разрешает перейти на 103. Затем реально имеющиеся 104 и 105 двигают отметку до 105. До 106 она не доходит.

Это продвижение сложено из разрешённого отсутствия и фактического наличия. Оно не превращает содержимое 103 в доставленное. Тем более Advanced.Peer.Ack.Point отправителя не становится фактическим накопительным подтверждением до того, как другая сторона обработает переход.

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

FORWARD TSN может потеряться. Отправитель поддерживает необходимый таймер повторной передачи и при его срабатывании снова проверяет возможность продвижения. Старый или равный блок не откатывает получателя, но может вызвать новый SACK, если прежний потерялся. Поздний DATA после перехода считается дубликатом и отбрасывается; это не отзыв копии, которую приложение успело принять раньше.

Причины остановки расширились, состояния остались разными

Информационный RFC 6458 описал выбор политики и значения: надёжный режим отделён от временной частичной надёжности, где значение задаётся в миллисекундах. Это не доказывает одинаковые числовые константы или исходные настройки во всех реализациях.

RFC 7496 добавил ограничение числа повторных передач каждого DATA-блока сообщения. Если следующая повторная передача любого блока превысила бы предел, всё сообщение отбрасывается; считаются быстрые и таймерные повторы. Ноль означает отказ при необходимости первого повтора, а не запрет первого отправления и не доказательство его успеха.

Его политика приоритета работает с местом в буфере отправки. Ради новой записи можно отказаться от менее приоритетных сообщений той же ассоциации; надёжные сообщения стоят выше участвующих в этой политике. Это локальная эвакуация памяти, не приоритет в сети и не команда планировщику получателя.

Для каналов данных WebRTC RFC 8831 потребовал временную и ограниченную повторами частичную надёжность. Упорядоченность и надёжность остаются разными выборами; канал использует пару встречных потоков SCTP, а SCTP работает поверх DTLS поверх ICE/UDP. Требование не является сегодняшней статистикой браузеров или универсальным свойством любого SCTP-потока.

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

Источники

  • RFC 2960: исходное время жизни и начало передачи.
  • RFC 3758: частичная надёжность и обработка FORWARD TSN.
  • RFC 4960: последующая базовая спецификация.
  • RFC 6458: информационный интерфейс выбора политики.
  • RFC 7496: ограничения повторов, приоритеты и счётчики.
  • RFC 8831: каналы данных WebRTC и протокольные слои.
  • RFC 9260: базовый интерфейс SCTP в 2022 году.