Кратко

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

Срок закончился, но стек SCTP всё ещё мог проверить сообщение позже. RFC 3758 не смешивал момент истечения с моментом, когда реализация обнаружит это состояние.

Расширение частичной надёжности не отменило надёжную доставку в целом. Оно позволило верхнему уровню задавать для каждого сообщения, как долго транспорт должен продолжать отправку и повторные попытки. Если обе стороны согласовали поддержку FORWARD TSN при создании ассоциации, отправитель может отказаться от сообщения и попросить получателя продвинуть накопительную границу Transmission Sequence Number (TSN). Для упорядоченных данных в сигнал включаются и номера последовательности потока — так получатель может освободить сообщения, которые ожидали за пропуском.

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

Разница видна при сравнении с исходным SCTP. В RFC 2960 параметр lifetime позволял не отправлять устаревшее сообщение, которое ещё не передавалось впервые. Но если первая передача успела произойти до истечения срока, сообщение становилось обычным надёжным сообщением и подлежало повторным передачам. Сервис timed reliability в RFC 3758 снял это ограничение: после истечения срока можно отказаться и от уже отправленного сообщения.

Однако это не сделало lifetime точным таймером. Отправитель должен проверить срок перед назначением TSN, а если TSN уже назначен — перед передачей или повторной передачей. Одновременно RFC 3758 поясняет, что отдельный таймер для каждого сообщения не нужен. Реализация может оценивать срок при уже существующих событиях обработки: назначении TSN, отправке, срабатывании таймера повторной передачи или при другой удобной возможности. Немедленная проверка ровно в момент истечения не требуется.

Поэтому поле lifetime в интерфейсе само по себе не обещает жёсткого срока доставки или мгновенного отказа. Оно задаёт условие, при котором сообщение должно быть прекращено после проверки; момент самой проверки может зависеть от цикла обработки стека. Для приложения, чувствительного ко времени, задержка обнаружения — часть контракта сервиса, а не мелкая деталь реализации.

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

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

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

Позднее RFC 7496 добавил политики ограничения повторных передач и приоритета. Критерии отказа могут различаться, а механизм продвижения остаётся общим. Верхний уровень решает, когда новая попытка утратила смысл; транспорт определяет, как сообщить об этом и продолжить последовательность.

Источники