приложение может передавать данные в третьем и четвертом пакетах четырехэтажного рукопожатия, если для неявной установки соединения используются функции
sendmsg
и
sctp_sendmsg
;
отсутствует необходимость в отслеживании состояния на транспортном уровне. Другими словами, приложение просто запрашивает данные из дескриптора сокета, не вызывая традиционных функций
connect
и
accept
для получения сообщений.
Есть у этого интерфейса и недостатки. Самый существенный из них состоит в том, что интерфейс типа «один-ко-многим» затрудняет написание параллельного сервера (многопоточного или порождающего процессы). Для
устранения этого недостатка была придумана функция
sctp_peeloff
. Она принимает в качестве аргумента дескриптор сокета типа «один-ко-многим» и идентификатор ассоциации, а возвращает новый дескриптор сокета типа «один-к-одному» с единственной ассоциацией (сохраняя все уведомления и данные, помещенные в очередь этой ассоциации). Исходный сокет остается открытым, причем все остальные ассоциации проведенной операцией извлечения никак не затрагиваются.
Выделенный сокет может быть передан потоку или дочернему процессу для обработки запросов клиента. Листинг 23.15 демонстрирует новую модифицированную версию сервера, который обрабатывает первое сообщение клиента, выделяет ассоциацию при помощи
sctp_peeloff
, порождает дочерний процесс и вызывает функцию
str_echo
для TCP, которая была написана в разделе 5.3. Адрес из полученного сообщения мы передаем нашей функции из раздела 23.8, которая по этому адресу определяет идентификатор ассоциации. Идентификатор хранится также в поле
sri
,
sinfo_assoc_id
. Наша функция служит лишь иллюстрацией использования альтернативного метода. Породив процесс, сервер переходит к обработке следующего сообщения.
Сервер получает и обрабатывает первое сообщение клиента.
Преобразование адреса в идентификатор ассоциации
31-35
Сервер вызывает функцию из листинга 23.13 для получения идентификатора ассоциации по ее адресу. Если что-то
мешает серверу получить идентификатор, он не делает попыток породить дочерний процесс, а просто переходит к обработке следующего сообщения.
Выделение ассоциации
36-40
Сервер выделяет ассоциацию в отдельный дескриптор сокета при помощи
sctp_peeloff
. Полученный сокет типа «один-к-одному» может быть без проблем передан написанной ранее для TCP функции
str_echo
.
Передача работы дочернему процессу
41-47
Сервер порождает дочерний процесс, который и выполняет всю обработку по конкретному дескриптору.
23.11. Управление таймерами
Протокол SCTP имеет множество численных пользовательских параметров. Все они устанавливаются через параметры сокетов, рассмотренные в разделе 7.10. Далее мы займемся рассмотрением нескольких параметров, определяющих задержку перед объявлением об отказе ассоциации или адреса собеседника.
Время обнаружения отказа в SCTP определяется семью переменными (табл. 23.1).
Таблица 23.1. Поля таймеров SCTP
Поле
Описание
По умолчанию
Единицы
srto_min
Минимальный тайм-аут повторной передачи
1000
Мс
srto_max
Максимальный тайм-аут повторной передачи
60000
Мс
srto_initial
Начальный тайм-аут повторной передачи
3000
Мс
sinit_max_init_timeo
Максимальный тайм-аут повторной передачи сегмента INIT
3000
Мс
sinit_max_attempts
Максимальное количество повторных передач сегмента INIT
8
попыток
spp_pathmaxrxt
Максимальное количество повторных передач по адресу
5
попыток
sasoc_asocmaxrxt
Максимальное количество повторных передач на ассоциацию
10
попыток
Эти параметры можно воспринимать как регуляторы, укорачивающие и удлиняющие время обнаружения отказа. Рассмотрим два сценария.
1. Конечная точка SCTP пытается открыть ассоциацию с собеседником, отключившимся от сети.
2. Две многоинтерфейсные конечные точки SCTP обмениваются данными. Одна из них отключается от сети питания в момент передачи данных. Сообщения ICMP фильтруются защитными экранами и потому не достигают второй конечной точки.