Кратко

  • sctp_peeloff выделяет уже установленную ассоциацию SCTP из сокета «один ко многим» в сокет «один к одному». Новая ассоциация взамен прежней не устанавливается.
  • Последующие операции с данными и управлением используют новый дескриптор. Закрытие исходного сокета не завершает выделенную ассоциацию, поэтому её жизненный цикл нужно учитывать отдельно.

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

Такое поведение не обязательно связано со сбоем. Оно прямо описано в RFC 6458, посвящённом сокетному API SCTP. Операция sctp_peeloff выделяет установленную ассоциацию в отдельный сокет, после чего закрытие исходного сокета её не прекращает.

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

Общий вход не означает независимых ресурсов

Сокет «один ко многим» позволяет приложению работать с несколькими ассоциациями через один дескриптор. Когда требуется выбрать конкретную ассоциацию, используется её идентификатор. Это удобная организация доступа, но она ничего автоматически не доказывает об изоляции ресурсов под этим доступом.

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

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

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

Дескриптор меняет адрес последующих команд

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

Раздел 9.2 требует выполнять все дальнейшие операции с данными и управлением этой ассоциации через новый сокет. Поэтому слово «управление» нельзя исключить из описания. Выделение — не просто незаметное перенаправление потока данных.

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

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

Настройка бездействия имеет область применения

RFC описывает параметры уровней сокета и IP как действующие в пределах сокета. Для модели «один ко многим» речь идёт о принадлежащих ему ассоциациях, для индивидуального сокета — о представленной им ассоциации. В разделах о буферах также отмечаются различия реализаций общей модели.

Показателен SCTP_AUTOCLOSE из раздела 8.1.8. Он документирован только для сокетов «один ко многим». Бездействие относится к обмену пользовательскими данными. Нулевое значение по умолчанию отключает функцию; ненулевое задаёт время в секундах. Чтобы узнавать о таких завершениях, приложению нужны уведомления об изменении состояния ассоциации.

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

Термин «закрытие» тоже объединяет разные последствия. Обычный close индивидуального сокета начинает упорядоченное завершение SCTP и делает дескриптор недоступным для последующих операций. Если SO_LINGER включён с нулевым временем ожидания, close вместо этого прерывает ассоциацию. Положительное время ограничивает ожидание вызова; протокольное завершение может продолжаться после его возврата.

Описанный интерфейс shutdown позволяет сохранить дескриптор для уведомлений в ходе завершения. Однако SHUT_WR запускает полное протокольное завершение SCTP, а не полузакрытие по образцу TCP. Ни освобождение дескриптора, ни состояние транспорта само по себе не удостоверяют результат прикладной деловой операции.

Где заканчивается документ и начинается анализ

В карточке RFC Editor документ отнесён к категории Informational и датирован декабрём 2011 года. Это не актуальная перепись возможностей всех операционных систем. В изученном списке исправлений есть проверенные изменения других фрагментов, но нет прямого исправления раздела 9.2. Отложенные для будущего обновления и отклонённые записи нельзя считать принятыми поправками.

Организационный вывод должен оставаться именно выводом. В эссе о проблеме принципала и агента Lu Heng рассматривает связь права принимать решения с воздействием их последствий. Здесь полезно спросить, знает ли утвердивший изоляцию, кто отвечает за завершение отделённой ассоциации. Это не утверждение о мотивах инженеров.

В объяснении предназначения BTW Media он отдаёт приоритет наблюдаемой действительности перед отстаиванием позиции. Для рассматриваемой процедуры это означает проследить реальные дескрипторы, которые ещё управляют работой, а не принять фразу «общий вход закрыт» за полный результат проверки.

Выделение создаёт полезную техническую границу. Эксплуатационный учёт должен провести границу ответственности в том же месте.