SCTP предлагает разработчику приложений два вида интерфейсов: «один-к-одному», облегчающий миграцию существующих TCP-приложений на SCTP, и «один-ко-многим», реализующий все новые возможности SCTP. Функция sctp_peeloff
Поскольку протокол 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
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)
4 {
5 int sock_fd, msg_flags;
6 char readbuf[BUFFSIZE];
7 struct sockaddr_in servaddr, cliaddr;
8 struct sctp_sndrcvinfo sri;
9 struct sctp_event_subscribe evnts;
10 int stream_increment=1;
11 socklen_t len;
12 size_t rd_sz;
13 if (argc == 2)
14 stream_increment = atoi(argv[1]);