UNIX: разработка сетевых приложений — страница 10 из 42

Основы сокетов SCTP

9.1. Введение

SCTP — новый транспортный протокол, принятый IETF в качестве стандарта в 2000 году. (Для сравнения, протокол TCP был стандартизован в 1981 году.) Изначально SCTP проектировался с учетом потребностей растущего рынка IP-телефонии, и предназначался, в частности, для передачи телефонного сигнала через Интернет. Требования, которым должен был отвечать SCTP, описываются в RFC 2719 [84]. SCTP — надежный протокол, ориентированный на передачу сообщений, предоставляющий возможность работать с несколькими потоками каждой паре конечных точек, а также обеспечивающий поддержку концепции многоинтерфейсного узла на транспортном уровне. Поскольку это относительно новый протокол, он распространен не так широко, как TCP и UDP, однако он обладает особенностями, облегчающими проектирование некоторых видов приложений. Выбору между SCTP и TCP будет посвящен раздел 23.12.

Несмотря на принципиальную разницу между SCTP и TCP, с точки зрения приложения интерфейс SCTP типа «один-к-одному» почти ничем не отличается от интерфейса TCP. Это делает перенос приложений достаточно тривиальным, однако при таком переносе некоторые усовершенствованные функции SCTP остаются незадействованными. Интерфейс типа «один-ко-многим» задействует эти функции «на всю катушку», но переход к нему может потребовать значительной переделки существующих приложений. Новый интерфейс рекомендуется использовать большинству новых приложений, разрабатываемых в расчете на SCTP.

Эта глава описывает дополнительные элементарные функции сокетов, которые могут использоваться с SCTP. Сначала мы опишем две модели интерфейса, доступные разработчику приложения. В главе 10 мы разработаем новую версию эхо-сервера, использующую модель «один-ко-многим». Кроме того, мы опишем новые функции, которые предназначены только для SCTP. Особое внимание будет уделено функции shutdown и отличиям процедуры завершения ассоциации SCTP от процедуры завершения соединения TCP. В разделе 23.4 мы рассмотрим пример использования уведомлений для оповещения приложения о важных событиях, связанных с протоколом (помимо прибытия новых пользовательских данных).

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

9.2. Модели интерфейса

Сокеты SCTP бывают двух типов: «один-к-одному» и «один-ко-многим». Сокету типа «один-к-одному» всегда сопоставляется ровно одна ассоциация SCTP. Вспомните, что в разделе 2.5 мы отмечали, что ассоциация является соединением между двумя системами, которое может задействовать более двух IP-адресов, если хотя бы одна из систем имеет несколько интерфейсов. Связь между сокетом и ассоциацией SCTP такая же, как между сокетом и соединением TCP. Сокету типа «один-ко-многим» может сопоставляться одновременно несколько активных ассоциаций. То же самое имеет место и в UDP, где сокет, привязанный к конкретному порту, может получать дейтаграммы от нескольких конечных точек UDP, передающих данные одновременно.

Выбор интерфейса при разработке приложения должен осуществляться с учетом нескольких факторов:

■ тип сервера (последовательный или параллельный);

■ количество дескрипторов сокетов, с которыми должен работать сервер;

■ важно ли оптимизировать работу приложения, разрешив передачу данных в третьем (и, возможно, четвертом) пакете четырехэтапного рукопожатия;

■ для какого количества соединений существует необходимость хранить информацию о состоянии.

ПРИМЕЧАНИЕ

Когда API сокетов для протокола SCTP еще только разрабатывался, сокеты разных типов назывались по-разному. Читатели до сих пор могут столкнуться со старой терминологией в документации или исходном коде. Изначально сокет типа «один-к-одному» назывался сокетом типа TCP (TCP-style socket), а сокет типа «один-ко-многим» — сокетом типа UDP (UDP-style socket).

Впоследствии от этих терминов пришлось отказаться, так как они создавали впечатление, что SCTP будет вести себя, как TCP или UDP, при использовании сокетов соответствующих типов. На самом деле имелось в виду только одно различие между TCP и UDP: возможность одновременной работы с несколькими адресатами на транспортном уровне. Современные термины («один-к-одному» и «один-ко-многим») фокусируют наше внимание на главном отличии двух типов сокетов.

Наконец, обратите внимание, что некоторые авторы используют термин «несколько-к-одному» вместо «один-ко-многим». Эти термины взаимозаменяемы.

Сокет типа «один-к-одному»

Данный тип сокета был разработан специально для облегчения переноса существующих приложений с TCP на SCTP. Его модель практически идентична описанной в главе 4. Существуют, конечно, некоторые отличия, о которых следует помнить (в особенности, при переносе приложений):

1. Все параметры сокетов должны быть преобразованы к соответствующим эквивалентам SCTP. Чаще всего используются параметры TCP_NODELAY и TCP_MAXSEG, вместо которых следует задавать SCTP_NODELAY и SCTP_MAXSEG.

2. Протокол SCTP сохраняет границы сообщений, поэтому приложению не приходится кодировать их самостоятельно. Например, приложение, основанное на TCP, может отправлять записи, чередуя двухбайтовые поля длины с полями данных переменной длины (каждое поле записывается в буфер отправки отдельным вызовом write). Если так поступить с SCTP, адресат получит два отдельных сообщения, то есть функция read возвратится дважды: один раз с двухбайтовым сообщением (поле длины), а второй — с сообщением неопределенной длины.

3. Некоторые TCP-приложения используют половинное закрытие для извещения собеседника о конце считываемых данных. Для переноса таких приложений на SCTP потребуется переписать их таким образом, чтобы сигнал о конце данных передавался в обычном потоке.

4. Функция send может использоваться обычным образом. Функции sendto и sendmsg трактуют информацию об адресе получателя как приоритетную перед основным адресом собеседника (см. раздел 2.8).

Типичное приложение, работающее в стиле «один-к-одному», будет вести себя так, как показано на временной диаграмме рис. 9.1. Запущенный сервер открывает сокет, привязывается к адресу, после чего ожидает подсоединения клиента в системном вызове accept. Через некоторое время запускается клиент, который открывает свой сокет и инициирует установление ассоциации с сервером. Предполагается, что клиент отправляет серверу запрос, сервер обрабатывает этот запрос и отправляет свой ответ обратно клиенту. Взаимодействие продолжается до тех пор, пока клиент не начнет процедуру завершения ассоциации. После закрытия ассоциации сервер либо завершает работу, либо ожидает установления новой ассоциации. Из сравнения с временной диаграммой TCP (см. рис. 4.1) становится ясно, что обмен пакетами через сокет SCTP типа «один-к-одному» осуществляется приблизительно так же.

Рис. 9.1. Временная диаграмма для сокета SCTP типа «один-к-одному»

Сокет SCTP типа «один-к-одному» является IP-сокетом (семейство AF_INET или AF_INET6) со значением типа SOCK_STREAM и значением протокола IPPROTO_SCTP.

Сокет типа «один-ко-многим»

Сокет типа «один-ко-многим» дает разработчику приложения возможность написать сервер, не использующий большого количества дескрипторов сокетов. Один дескриптор для такого сервера будет представлять несколько ассоциаций, подобно сокету UDP, способному принимать дейтаграммы от множества клиентов. Для обращения к конкретной ассоциации, установленной для сокета типа «один-ко-многим», используется идентификатор. Идентификатор ассоциации представляет собой значение типа sctp_assoc_t (обычно это целое число). Значение идентификатора скрывается от приложения, то есть оно не должно использовать идентификатор, если тот еще не был предоставлен приложению ядром.

При написании приложения, использующего сокеты данного типа, рекомендуется помнить о следующих важных моментах:

1. Когда клиент закрывает ассоциацию, она автоматически закрывается и на стороне сервера. При этом удаляются все сведения о состоянии ассоциации в ядре.

2. Только при использовании типа «один-ко-многим» возможна передача данных в третьем и четвертом пакетах четырехэтапного рукопожатия (см. упражнение 9.3).

3. Вызов sendto, sendmsg или sctp_sendmsg для адресата, с которым еще не установлена ассоциация, приведет к попытке активного открытия, в результате чего будет создана новая ассоциация с указанным адресом. Это происходит даже в том случае, если приложение, вызвавшее send, перед этим вызвало для того же сокета функцию listen, запросив пассивное открытие.

4. Приложение должно использовать функции sendto, sendmsg и sctp_sendmsg, но не send и write. (Если вы создали сокет типа «один-к-одному» вызовом sctp_peeloff, то send и write вызывать можно.)

5. При вызове одной из функций отправки данных используется основной адрес получателя, выбранный системой в момент установки ассоциации (раздел 2.8), если вызывающий процесс не установит флаг MSG_ADDR_OVER в структуре sctp_sndrcvinfo. Для этого необходимо вызвать функцию sendmsg с вспомогательными данными или воспользоваться функцией sctp_sendmsg.

6. Уведомление о событиях для ассоциации может быть включено по умолчанию, так что если приложению не требуется получать эти уведомления, оно должно явным образом отключить их при помощи параметра сокета SCTP_EVENTS. (Одно из множества уведомлений SCTP обсуждается в разделе 9.14.) По умолчанию единственным включенным событием является sctp_data_io_event. Уведомление о нем передается в виде вспомогательных данных при вызове recvmsg и sctp_recvmsg. Это относится к сокетам обоих типов.

ПРИМЕЧАНИЕ

Когда интерфейс API сокетов SCTP находился на стадии разработки, для сокетов типа «один-ко-многим» по умолчанию было включено еще и уведомление об установке ассоциации. В более поздних версиях документации API говорится о том, что по умолчанию для сокетов обоих типов отключены все уведомления, за исключением sctp_data_io_event. Однако не все реализации могут соответствовать этому утверждению. Хорошим тоном будет включать все нужные уведомления и отключать ненужные в явном виде. Благодаря этому разработчик получает гарантию того, что приложение будет вести себя так, как он этого хочет, в любой операционной системе.

Типичная временная диаграмма для сокета типа «один-ко-многим» приведена на рис. 9.2. Сначала запускается сервер, который создает сокет, привязывает его к адресу, вызывает функцию listen для того, чтобы разрешить клиентам устанавливать ассоциации, после чего он вызывает sctp_recvmsg и приостанавливается в ожидании первого сообщения. В свою очередь, клиент открывает сокет и вызывает функцию sctp_sendto, которая неявно инициирует ассоциацию и вкладывает данные в третий пакет четырехэтапного рукопожатия. Сервер получает запрос, обрабатывает его и отсылает свой ответ. Клиент получает ответ сервера и закрывает сокет, тем самым закрывая и ассоциацию. Сервер переходит к ожиданию следующего сообщения.

Рис. 9.2. Временная диаграмма работы сокета типа «один-ко-многим»

В этом примере рассматривается последовательный сервер, один программный поток которого обрабатывает сообщения, полученные через несколько ассоциаций. SCTP позволяет использовать сокет типа «один-ко-многим» с функцией sctp_peeloff (см. раздел 9.12) для реализации комбинированной параллельно- последовательной модели сервера.

1. Функция sctp_peeloff позволяет выделить конкретную ассоциацию (например, долговременный сеанс связи) из сокета типа «один-ко-многим» в отдельный сокет типа «один-к-одному».

2. Полученный таким образом сокет типа «один-к-одному» может быть передан новому потоку или порожденному процессу (как в модели параллельного сервера).

3. Основной поток обрабатывает сообщения от всех остальных ассоциаций в последовательном режиме.

Сокет SCTP типа «один-ко-многим» является IP-сокетом (семейство AF_INET или AF_INET6) со значением типа SOCK_SEQPACKET и значением протокола IPPROTO_SCTP.

9.3. Функция sctp_bindx

Сервер SCTP может привязаться к некоторому подмножеству IP-адресов узла, на котором он запущен. Серверы TCP и UDP могли привязываться либо к одному, либо ко всем адресам узла, но не могли указывать конкретный набор адресов. Функция sctp_bindx делает программирование приложений более гибким, предоставляя возможность связывать сокет SCTP с заданными адресами.

#include 

int sctp_bindx(int sockfd, const struct sockaddr *addrs, int addrcnt, int flags);
Возвращает: 0 в случае успешного завершения, -1 в случае ошибки

Аргумент sockfd представляет собой дескриптор сокета, возвращаемый функцией socket. Второй аргумент — указатель на упакованный список адресов. Каждая структура адреса сокета помещается в буфер непосредственно после предшествующей структуры, без всяких дополняющих нулей (пример приводится на рис. 9.3).

Рис. 9.3. Формат упакованного списка адресов для функций SCTP

Количество адресов, передаваемых sctp_bindx, указывается в параметре addrcnt. Параметр flags сообщает функции sctp_bindx о необходимости выполнения действий, перечисленных в табл. 9.1.

Таблица 9.1. Флаги функции sctp_bindx

Значение аргумента flags	Описание
SCTP_BINDX_ADD_ADDR	Добавляет адреса к уже определенным для сокета
SCTP_BINDX_REM_ADDR	Удаляет адреса из списка адресов сокета

Функцию sctp_bindx можно вызывать независимо от того, привязан ли сокет к каким-нибудь адресам. Для несвязанного сокета вызов sctp_bindx приведет к привязке указанного набора адресов. При работе с уже связанным сокетом указание флага SCTP_BINDX_ADD_ADDR позволяет добавить адреса к данному дескриптору. Флаг SCTP_BINDX_REM_ADDR предназначен для удаления адресов из списка связанных с данным дескриптором. Если sctp_bindx вызывается для прослушиваемого сокета, новая конфигурация будет использоваться только для новых ассоциаций; вызов никак не затронет уже установленные ассоциации. Флаги sctp_bindx взаимно исключают друг друга: если указать оба, функция вернет ошибку EINVAL. Номер порта во всех структурах адреса сокета должен быть одним и тем же. Он должен совпадать с тем номером порта, который был связан с данным сокетом ранее. В противном случае sctp_bindx тоже вернет ошибку EINVAL.

Если конечная точка поддерживает динамическую адресацию, вызов sctp_bindx с флагом SCTP_BINDX_REM_ADDR или SCTP_BINDX_ADD_ADDR приведет к передаче собеседнику сообщения о необходимости изменения списка адресов. Поскольку изменение списка адресов для установленной ассоциации не является обязательным, реализации, не поддерживающие эту функцию, будут при попытке ее использования возвращать ошибку EOPNOTSUPP. Обратите внимание, что для нормальной работы динамической адресации она должна поддерживаться обеими сторонами. Все это полезно в том случае, если система поддерживает динамическое предоставление интерфейсов: когда открывается доступ к новому интерфейсу Ethernet, приложение может вызвать SCTP_BINDX_ADD_ADDR и начать работать с этим интерфейсом по уже установленным ассоциациям.

9.4. Функция sctp_connectx

#include 

int sctp_connectx(int sockfd, const struct sockaddr *addrs, int addrcnt);
Возвращает: 0 в случае успешного завершения, -1 в случае ошибки

Функция sctp_connectx используется для соединения с многоинтерфейсным узлом. При ее вызове мы должны указать адреса собеседника в параметре addrs (количество адресов определяется параметром addrcnt). Формат структуры addrs представлен на рис. 9.3. Стек SCTP устанавливает ассоциацию, используя один или несколько адресов из переданного списка. Все адреса addrs считаются действующими и подтвержденными.

9.5. Функция sctp_getpaddrs

Функция getpeername не предназначена для использования протоколом, рассчитанным на работу с многоинтерфейсными узлами. Для сокетов SCTP она способна вернуть лишь основной адрес собеседника. Если нужны все адреса, следует вызывать функцию sctp_getpaddrs.

#include 

int sctp_getpaddrs(int sockfd, sctp_assoc_t id, struct sockadrrd **addrs);
Возвращает: 0 в случае успешного завершения, -1 в случае ошибки

Аргумент sockfd представляет собой дескриптор сокета, возвращаемый функцией socket. Второй аргумент задает идентификатор ассоциации для сокетов типа «один-ко-многим». Для сокетов типа «один-к-одному» этот аргумент игнорируется. addrs — адрес указателя, который функция sctp_getpaddrs заполнит упакованным списком адресов, выделив под него локальный буфер (см. рис. 9.3 и листинг 23.12). Для освобождения буфера, созданного sctp_getpaddrs, следует использовать вызов sctp_freepaddrs.

9.6. Функция sctp_freepaddrs

Функция sctp_freepaddrs освобождает ресурсы, выделенные вызовом sctp_getpaddrs.

#include 

void sctp_freepaddrs(struct sockaddr *addrs);

Здесь аргумент addrs — указатель на массив адресов, возвращаемый sctp_getpaddrs.

9.7. Функция sctp_getladdrs

Функция sctp_getladdrs может использоваться для получения списка локальных адресов, относящихся к определенной ассоциации. Эта функция бывает необходима в тех случаях, когда приложению требуется узнать, какие именно локальные адреса оно использует (набор адресов, напомним, может быть произвольным подмножеством всех адресов системы).

#include 

int sctp_getladdrs(int sockfd, sctp_assoc_t id, struct sockaddr **addrs);
Возвращает: количество локальных адресов, помещенных в addrs, или -1 в случае ошибки.

Здесь sockfd — дескриптор сокета, возвращаемый функцией socket. Аргумент id — идентификатор ассоциации для сокетов типа «один-ко-многим». Поле id игнорируется для сокетов типа «один-к-одному». Параметр представляет собой адрес указателя на буфер, выделяемый и заполняемый функцией sctp_getladdrs. В этот буфер помещается упакованный список адресов. Структура списка представлена на рис. 9.3 и в листинге 23.12. Для освобождения буфера процесс должен вызвать функцию sctp_freeladdrs.

9.8. Функция sctp_freeladdrs

Функция sctp_freeladdrs освобождает ресурсы, выделенные при вызове sctp_getladdrs.

#include 

void sctp_freeladdrs(struct sockaddr *addrs);

Здесь addrs указывает на список адресов, возвращаемый sctp_getladdrs.

9.9. Функция sctp_sendmsg

Приложение может управлять параметрами SCTP, используя функцию sendmsg со вспомогательными данными (см. главу 14). Однако из-за неудобств, связанных с применением вспомогательных данных, многие реализации SCTP предоставляют дополнительный библиотечный вызов (который на самом деле может быть и системным вызовом), упрощающий обращение к расширенным функциям SCTP. Вызов функции должен иметь следующий формат:

ssize_t sctp_sendmsg(int sockfd, const void *msg, size_t msgsz,
 const struct sockaddr *to, socklen_t tolen, uint32_t ppid,
 uint32_t flags, uint16_t stream, uint32_t timetolive,
 uint32_t context);
Возвращает: количество записанных байтов в случае успешного завершения, -1 в случае ошибки

Использование sctp_sendmsg значительно упрощает отправку параметров, но требует указания большего количества аргументов. В поле sockfd помещается дескриптор сокета, возвращенный системным вызовом socket. Аргумент msg указывает на буфер размера msgsz, содержимое которого должно быть передано собеседнику. В поле tolen помещается длина адреса, передаваемого через аргумент to. В поле ppid помещается идентификатор протокола, который будет передан вместе с порцией данных. Поле flags передается стеку SCTP. Разрешенные значения этого поля приводятся в табл. 7.5.

Номер потока SCTP указывается вызывающим приложением в аргументе stream. Процесс может указать время жизни сообщения в миллисекундах в поле lifetime. Значение 0 соответствует бесконечному времени жизни. Пользовательский контекст, при наличии такового, может быть указан в поле context. Пользовательский контекст связывает неудачную передачу сообщения (о которой получено уведомление) с локальным контекстом, имеющим отношение к приложению. Например, чтобы отправить сообщение в поток 1 с флагом отправки MSG_PR_SCTP_TTL, временем жизни равным 1000 мс, идентификатором протокола 24 и контекстом 52, процесс должен сделать следующий вызов:

ret =
 sctp_sendmsg(sockfd, data, datasz, &dest, sizeof(dest), 24,
  MSG_PR_SCTP_TTL, 1, 1000, 52);

Этот подход значительно проще выделения памяти под необходимые вспомогательные данные и настройки структур, входящих в msghdr. Обратите внимание, что если функция sctp_sendmsg реализована через вызов sendmsg, то поле flags в последнем устанавливается равным 0.

9.10. Функция sctp_recvmsg

Функция sctp_recvmsg, подобно sctp_sendmsg, предоставляет удобный интерфейс к расширенным возможностям SCTP. С ее помощью пользователь может получить не только адрес собеседника, но и поле msg_flags, которое обычно заполняется при вызове recvmsg (например, MSG_NOTIFICATION, MSG_EOR и так далее). Кроме того, функция дает возможность получить структуру sctp_sndrcvinfo, которая сопровождает сообщение, считанное в буфер. Обратите внимание, что если приложение хочет получать информацию, содержащуюся в структуре sctp_sndrcvinfo, оно должно быть подписано на событие sctp_data_io_event с параметром сокета SCTP_EVENTS (по умолчанию эта подписка включена).

ssize_t sctp_recvmsg(int sockfd, void *msg, size_t msgsz,
 struct sockaddr *from, socklen_t *fromlen,
 struct sctp_sndrcvinfo *sinfo, int *msg_flags);
Возвращает, количество считанных байтов в случае успешного завершения, -1 в случае ошибки

По возвращении из этого вызова аргумент msg оказывается заполненным не более, чем msgsz байтами данных. Адрес отправителя сообщения помещается в аргумент from, а размер адреса — в аргумент fromlen. Флаги сообщения будут помещены в аргумент msg_flags. Если уведомление sctp_data_io_event включено (а по умолчанию это так и есть), структура sctp_sndrcvinfo заполняется подробными сведениями о сообщении. Обратите внимание, что если функция sctp_recvmsg реализована через вызов recvmsg, то поле flags в последнем устанавливается равным нулю.

9.11. Функция sctp_opt_info

Эта функция предназначена для тех приложений, которым недостаточно возможностей, предоставляемых функциями getsockopt для протокола SCTP. Дело в том, что некоторые параметры сокетов SCTP (например, SCTP_STATUS) требуют использования переменных типа «значение-результат» для передачи идентификатора ассоциации. Если функция getsockopt не поддерживает работу с такими переменными, разработчику придется вызывать sctp_opt_info. В системах типа FreeBSD, разрешающих указывать переменные типа «значение-результат» с параметрами сокетов, функция sctp_opt_info представляет собой оболочку, передающую аргументы функции getsockopt в нужном формате. В целях обеспечения переносимости разработчикам приложений рекомендуется использовать sctp_opt_info для всех параметров, требующих работы с переменными типа «значение-результат» (см. раздел 7.10).

int sctp_opt_info(int sockfd, sctp_assoc_t assoc_id, int opt,
 void *arg, socklen_t *siz);
Возвращает: 0 в случае успешного завершения, -1 в случае ошибки

Здесь sockfd — дескриптор сокета, с параметрами которого хочет работать пользователь. Аргумент assoc_id задает идентификатор ассоциации, которую нужно выделить из списка всех ассоциаций данного сокета. Аргумент opt задает параметр сокета для SCTP (список параметров приводится в разделе 7.10). Arg — аргумент параметра сокета, siz — указатель на переменную типа socklen_t, в которой хранится размер аргумента параметра сокета.

9.12. Функция sctp_peeloff

Как отмечалось ранее, любую ассоциацию, установленную через сокет типа «один- ко-многим», можно выделить в собственный сокет типа «один-к-одному». По семантике новая функция подобна accept с дополнительным аргументом. Процесс передает дескриптор sockfd сокета типа «один-ко-многим» и идентификатор id выделяемой ассоциации. Функция возвращает дескриптор нового сокета. Этот дескриптор имеет тип «один-к-одному», и он изначально связан с выбранной ассоциацией.

int sctp_peeloff(int sockfd, sctp_assoc_t id);

Возвращает: дескриптор нового сокета в случае успешного завершения, -1 в случае ошибки

9.13. Функция shutdown

Обсуждавшаяся в разделе 9.6 функция shutdown может использоваться с конечной точкой SCTP, использующей интерфейс типа «один-к-одному». Поскольку архитектура SCTP не предусматривает наполовину закрытого состояния, реакция на вызов shutdown конечной точки SCTP отличается от реакции TCP. Когда конечная точка SCTP инициирует процедуру завершения ассоциации, оба собеседника должны закончить передачу данных, находящихся в очереди, после чего закрыть ассоциацию. Конечная точка, выполнявшая активное открытие, может вызвать shutdown вместо close для того, чтобы впоследствии подключиться к новому собеседнику. В отличие от TCP, закрывать сокет функцией close, а затем создавать его снова здесь не требуется. SCTP разрешает конечной точке вызвать shutdown, а после завершения этой функции — открывать новые ассоциации через тот же сокет. Обратите внимание, что если конечная точка не дождется завершения последовательности закрытия ассоциации, установка нового соединения закончится неудачей. На рис. 9.4 приведена типичная временная диаграмма вызовов для этого сценария.

Рис. 9.4. Закрытие ассоциации SCTP вызовом shutdown

Обратите внимание, что на рис. 9.4 мы подразумеваем, что процесс подписан на события MSG_NOTIFICATION. Если же он не подписался на эти события, функция read считает нулевое количество байтов. Результаты вызова shutdown для TCP были описаны в разделе 6.6. В документации howto на функцию shutdown для SCTP перечислены следующие константы:

■SHUT_RD — та же семантика, что и для TCP (см. раздел 6.6); никаких особых действий протокол SCTP не предусматривает;

■SHUT_WR — запрещает отправку сообщений и инициирует процедуру завершения ассоциации SCTP. Этот параметр не дает возможности работать в наполовину закрытом состоянии, однако позволяет локальной конечной точке считать все данные, которые собеседник отправит до получения сообщения SCTP SHUTDOWN;

■SHUT_RDWR — запрещает вызовы read и write и инициирует процедуру завершения ассоциации SCTP. Данные, передававшиеся в момент вызова shutdown на локальную конечную точку, будут подтверждены и сброшены без всякого уведомления процесса.

9.14. Уведомления

SCTP предоставляет разработчику приложений большое количество разнообразных уведомлений. С их помощью процесс может отслеживать состояние ассоциаций, с которыми он работает. Уведомления сообщают о событиях транспортного уровня, включая изменения состояния сети, установку ассоциаций, протокольные ошибки удаленного узла и неудачи при доставке сообщений. По умолчанию уведомления обо всех событиях отключены для сокетов обоих типов. Исключение делается для события sctp_data_io_event. Пример использования уведомлений будет приведен в разделе 23.7.

Параметр сокета SCTP_EVENTS позволяет подписаться на восемь событий. Из них семь штук генерируют дополнительные данные, которые процесс может получить через обычный дескриптор сокета. Уведомления добавляются к обычным данным, приходящим на соответствующий сокет, по мере того, как происходят события, генерирующие эти уведомления. При чтении из сокета, для которого включена подписка на уведомления, пользовательские данные и сообщения смешиваются друг с другом. Чтобы различить их, процесс должен использовать функции recvmsg или sctp_recvmsg. Для уведомлений о событиях поле msg_flags содержит флаг MSG_NOTIFICATION. Этот флаг говорит приложению о том, что считанное сообщение представляет собой не обычные данные, принятые от собеседника, а уведомление о каком-либо событии от локального стека SCTP.

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

Два уведомления содержат поле кода причины ошибки SCTP (SCTP error cause field). Значения этого поля перечислены в разделе 3.3.10 RFC 2960 [118] и в разделе «CAUSE CODES» (коды причин) документа http://www.iana.org/assignments/sctp-parameters.

Уведомления определяются следующим образом.

struct sctp_tlv {
 u_int16_t sn_type;
 u_int16_t sn_flags;
 u_int32_t sn_length;
};

/* уведомление о событии */
union sctp_notification {
 struct sctp_tlv sn_header;
 struct sctp_assoc_change sn_assoc_change;
 struct sctp_paddr_change sn_paddr_change;
 struct sctp_remote_error sn_remote_error;
 struct sctp_send_failed sn_send_failed;
 struct sctp_shutdown_event sn_shutdown_event;
 struct sctp_adaption_event sn_adaption_event;
 struct sctp_pdapi_event sn_pdapi_event;
};

Обратите внимание, что для интерпретации значения типа используется поле sn_header. Таблица 9.2 содержит значения, которые могут помещаться в поля sn_header, sn_type, а также соответствующие значения поля подписки, которые используются с параметром сокета SCTP_EVENTS.

Таблица 9.2. Тип и поле подписки

sn_type	Поле подписки
SCTP_ASSOC_CHANGE	sctp_association_event
SCTP_PEER_ADDR_CHANGE	sctp_address_event
SCTP_REMOTE_ERROR	sctp_peer_error_event
SCTP_SEND_FAILED	sctp_send_failure_event
SCTP_SHUTDOWN_EVENT	sctp_shutdown_event
SCTP_ADAPTION_INDICATON	sctp_adaption_layer_event
SCTP_PARTIAL_DELIVERY_EVENT	sctp_partial_delivery_event

У каждого уведомления имеется своя собственная структура, которая содержит подробную информацию о произошедшем событии.

■SCTP_ASSOC_CHANGE

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

struct sctp_assoc_change {
 u_int16_t sac_type;
 u_int16_t sac_flags;
 u_int32_t sac_length;
 u_int16_t sac_state;
 u_int16_t sac_error;
 u_int16_t sac_outbound_streams;
 u_int16_t sac_inbound_streams;
 sctp_assoc_t sac_assoc_id;
 uint8_t sac_info[];
};

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

□SCTP_COMM_UP — создана новая ассоциация. Поля входящих и исходящих потоков (inbound_streams и outbound_streams) говорят о том, сколько потоков доступно в соответствующих направлениях. Идентификатор ассоциации позволяет взаимодействовать со стеком SCTP;

□SCTP_COMM_LOST — ассоциация закрыта из-за превышения порога недоступности (заданное количество раз был превышен тайм-аут) или собеседник выполнил аварийное закрытие ассоциации (при помощи параметра сокета SO_LINGER или вызовом sendmsg с флагом MSG_ABORT). Пользовательские данные могут быть помещены в поле sac_info;

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

□SCTP_SHUTDOWN_COMP — закончено завершение соединения, инициированное локальной конечной точкой (вызовом shutdown или sendmsg с флагом MSG_EOF). После получения этого сообщения сокет типа «один-к-одному» может быть использован для подключения к другому собеседнику;

□SCTP_CANT_STR_ASSOC — собеседник не ответил при попытке установления ассоциации.

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

■SCTP_PEER_ADDR_CHANGE Это уведомление говорит об изменении состояния одного из адресов собеседника. Изменение может заключаться либо в отказе (отсутствии подтверждения отправленных на этот адрес данных), либо в восстановлении (ответе отказавшего ранее адреса). Структура данных имеет следующий формат:

struct sctp_paddr_change {
 u_int16_t spc_type;
 u_int16_t spc_flags;
 u_int32_t spc_length;
 struct sockaddr_storage spc_aaddr;
 u_int32_t spc_state;
 u_int32_t spc_error;
 sctp_assoc_t spc_assoc_id;
};

Поле spc_aaddr содержит адрес собеседника, с которым связано данное событие. Поле spc_state может принимать одно из значений, перечисленных в табл. 9.3.

Таблица 9.3. Уведомление о состоянии адреса собеседника

spc_state	Значение
SCTP_ADDR_ADDED	Адрес добавлен к ассоциации
SCTP_ADDR_AVAILABLE	Адрес доступен
SCTP_ADDR_CONFIRMED	Адрес подтвержден и считается действующим
SCTP_ADDR_MADE_PRIM	Адрес сделан основным
SCTP_ADDR_REMOVED	Адрес удален из списка адресов ассоциации
SCTP_ADDR_UNREACHABLE	Адрес недоступен

Данные, отправленные на недоступный (SCTP_ADDR_UNREACHABLE) адрес, будут направляться на альтернативный адрес. Некоторые состояния доступны только в тех реализациях SCTP, которые поддерживают динамическую адресацию (в частности, SCTP_ADDR_ADDED и SCTP_ADDR_REMOVED).

Поле spc_error содержит код ошибки, дающий больше сведений о событии, а поле spc_assoc_id, как обычно, хранит идентификатор ассоциации.

■SCTP_REMOTE_ERROR

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

struct sctp_remote_error {
 u_int16_t sre_type;
 u_int16_t sre_flags;
 u_int32_t sre_length;
 u_int16_t sre_error;
 sctp_assoc_t sre_assoc_id;
 u_int8_t sre_data[];
};

Поле sre_error содержит код причины ошибки протокола SCTP; sre_assoc_id — идентификатор ассоциации, a sre_data — ошибочную порцию данных в сетевом формате.

■SCTP_SEND_FAILED

Сообщение, которое невозможно доставить собеседнику, возвращается отправителю в этом уведомлении. За таким уведомлением обычно следует уведомление об отказе ассоциации. В большинстве случаев доставка сообщения оказывается невозможной именно по причине отказа ассоциации. Если же используется режим частичной надежности SCTP, сообщение может быть возвращено и в том случае, если отказа ассоциации реально не произошло.

Данные, возвращаемые приложению с этим уведомлением, имеют следующий формат:

struct sctp_send_failed {
 u_int16_t ssf_type;
 u_int16_t ssf_flags;
 u_int32_t ssf_length;
 u_int32_t ssf_error;
 struct sctp_sndrcvinfo ssf_info;
 sctp_assoc_t ssf_assoc_id;
 u_int8_t ssf_data[];
};

Поле ssf_flags может иметь одно из двух значений:

□SCTP_DATA_UNSENT — сообщение не было послано собеседнику (управление потоком не позволило отправить сообщение до истечения его времени жизни);

□SCTP_DATA_SENT — сообщение было передано по крайней мере один раз, но собеседник не подтвердил его получение. Собеседник мог получить сообщение, но он не смог подтвердить его.

Эта разница может быть существенной для протоколов обработки транзакций, которые при восстановлении соединения могут предпринимать разные действия в зависимости от того, было принято конкретное сообщение или нет. Поле ssf_error может содержать код ошибки, относящейся к конкретному уведомлению, или быть нулевым. Поле ssf_info содержит сведения, переданные ядру при отправке данных (например, номер потока, контекст и так далее). Поле ssf_assoc_id содержит идентификатор ассоциации, а в поле ssf_data помещается недоставленное сообщение.

■SCTP_SHUTDOWN_EVENT

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

struct sctp_shutdown_event {
 uint16_t sse_type;
 uint16_t sse_flags;
 uint32_t sse_length;
 sctp_assoc_t sse_assoc_id;
};

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

■SCTP_ADAPTION_INDICATION

Некоторые реализации поддерживают параметр индикации адаптирующего уровня (adaption layer indication). Этот параметр передается в пакетах INIT и INIT-ACK и уведомляет собеседника о выполняемой адаптации приложения. Уведомление имеет следующий формат:

struct sctp_adaption_event {
 u_int16_t sai_type;
 u_int16_t sai_flags;
 u_int32_t sai_length;
 u_int32_t sai_adaption_ind;
 sctp_assoc_t sai_assoc_id;
};

Поле sai_assoc_id содержит обычный идентификатор ассоциации. Поле sai_adaption_ind представляет собой 32-разрядное целое число, переданное собеседником локальной конечной точке в сообщении INIT или INIT-ACK. Уровень адаптации для исходящих сообщений устанавливается при помощи параметра сокета SCTP_ADAPTION_LAYER (см. раздел 7.10). Все это описано в стандарте [116], а пример использования параметра для удаленного прямого доступа к памяти и прямой записи данных описывается в [115].

■SCTP_PARTIAL_DELIVERY_EVENT

Интерфейс частичной доставки используется для передачи больших сообщений пользователю через буфер сокета. Представьте, что процесс отправил сообщение размером 4 Мбайт. Сообщение такого размера может сильно перегрузить системные ресурсы. Реализация SCTP не смогла бы обработать такое сообщение, если бы у нее не было механизма доставки сообщений по частям до полного их получения. Реализация, обеспечивающая частичную доставку, называется интерфейсом частичной доставки (partial delivery API). SCTP передает данные приложению, не устанавливая флаги в поле msg_flags до тех пор, пока не будет готов последний сегмент сообщения. Для этого сегмента устанавливается флаг MSG_EOR (конец записи). Обратите внимание, что если приложение рассчитывает принимать большие сообщения, оно должно использовать функции recvmsg и sctp_recvmsg, чтобы иметь возможность проверять поле msg_flags на наличие флага окончания записи.

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

struct sctp_pdapi_event {
 uint16_t pdapi_type;
 uint16_t pdapi_flags;
 uint32_t pdapi_length;
 uint32_t pdapi_indication;
 sctp_assoc_t pdapi_assoc_id;
};

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

9.15. Резюме

SCTP предлагает разработчику приложений два вида интерфейсов: «один-к-одному», облегчающий миграцию существующих TCP-приложений на SCTP, и «один-ко-многим», реализующий все новые возможности SCTP. Функция sctp_peeloff позволяет выделять ассоциации из множественных сокетов в одиночные. Кроме того, SCTP предоставляет множество уведомлений о событиях транспортного уровня, на которые приложение при необходимости может подписываться. События помогают приложению управлять ассоциациями, с которыми оно работает.

Поскольку протокол SCTP ориентирован на многоинтерфейсные узлы, не все стандартные функции сокетов, рассмотренные в главе 4, оказываются эффективны при работе с ним. Функции sctp_bindx, sctp_connectx, sctp_getladdrs и sctp_getpaddrs позволяют управлять адресами и ассоциациями. Функции sctp_sendmsg и sctp_recvmsg упрощают использование расширенных возможностей SCTP. В главах 10 и 23 мы приведем примеры, наглядно демонстрирующие рассмотренные в этой главе новые концепции.

Упражнения

1. В какой ситуации разработчик приложения скорее всего воспользуется функцией sctp_peeloff?

2. Говоря о сокетах типа «один-ко-многим», мы утверждаем, что на стороне сервера также происходит автоматическое закрытие. Почему это верно?

3. Почему передача пользовательских данных в третьем пакете рукопожатия возможна только для сокетов типа «один-ко-многим»? (Подсказка: нужно иметь возможность отправлять данные во время установки ассоциации.)

4. В какой ситуации пользовательские данные могут быть переданы в третьем и четвертом пакетах четырехэтапного рукопожатия?

5. В разделе 9.7 говорится о том, что набор локальных адресов может быть подмножеством связанных адресов. В какой ситуации это возможно?

Глава 10