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

Сокет типа «один-ко-многим» дает разработчику приложения возможность написать сервер, не использующий большого количества дескрипторов сокетов. Один дескриптор для такого сервера будет представлять несколько ассоциаций, подобно сокету 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. Временная диаграмма работы сокета типа «один-ко-многим»