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

 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 Пример SCTP-соединения клиент-сервер

10.1. Введение

Воспользуемся некоторыми элементарными функциями из глав 4 и 9 для написания полнофункционального приложения SCTP с архитектурой клиент-сервер типа «один-ко-многим». Сервер из нашего примера будет аналогичен эхо-серверу из главы 5. Приложение будет функционировать следующим образом:

1. Клиент считывает строку текста из стандартного потока ввода и отсылает ее серверу. Строка имеет формат [#]text, где номер в скобках обозначает номер потока SCTP, по которому должно быть отправлено это текстовое сообщение.

2. Сервер принимает текстовое сообщение из сети, увеличивает номер потока, по которому было получено сообщение, на единицу и отправляет сообщение обратно клиенту через поток с новым номером.

3. Клиент считывает полученную строку и выводит ее в стандартный поток вывода, добавляя к ней номер потока и порядковый номер для данного потока.

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

Рис. 10.1. Простое потоковое приложение SCTP с архитектурой клиент-сервер

Две стрелки между клиентом и сервером обозначают два однонаправленных потока (ассоциация в целом является полностью двусторонней). Функции fgets и fputs входят в стандартную библиотеку ввода-вывода. Мы не пользуемся функциями writen и readline из раздела 3.9, потому что в них нет необходимости. Вместо них мы вызываем sctp_sendmsg и sctp_recvmsg из разделов 9.9 и 9.10 соответственно.

Сервер в нашем примере будет относиться к типу «один-ко-многим». Этот вариант был выбран нами по одной важной причине. Примеры из главы 5 могут быть переделаны под SCTP внесением крайне незначительных изменений: достаточно изменить вызов socket, указав в качестве третьего аргумента IPPROTO_SCTP вместо IPPROTO_TCP. Однако приложение, полученное таким образом, не использовало бы дополнительные возможности, предоставляемые SCTP, за исключением поддержки многоинтерфейсных узлов. Написав сервер типа «один-ко-многим», мы смогли показать все достоинства SCTP.

10.2. Потоковый эхо-сервер SCTP типа «один-ко-многим»: функция main

Наши клиент и сервер SCTP вызывают функции в последовательности, представленной на рис. 9.2. Код последовательного сервера представлен в листинге 10.1 [1] .

Листинг 10.1. Потоковый эхо-сервер SCTP

 //sctp/sctpserv01.c
  1 #include "unp.h"
  2 int
  3 main(int argc, char **argv)

1

Все исходные коды программ, опубликованные в этой книге, вы можете найти по адресу http://www.piter.com.