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

Рис. 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 <netinet/sctp.h>
int sctp_bindx(int <i>sockfd</i>, const struct sockaddr *<i>addrs</i>, int <i>addrcnt</i>, int <i>flags</i>);
<i>Возвращает: 0 в случае успешного завершения, -1 в случае ошибки</i>
Аргумент 
sockfd
 представляет собой дескриптор сокета, возвращаемый функцией 
socket
. Второй аргумент — указатель на упакованный список адресов. Каждая структура адреса сокета помещается в буфер непосредственно после предшествующей структуры, без всяких дополняющих нулей (пример приводится на рис. 9.3).