Уильям Стивенс - UNIX: разработка сетевых приложений

From str:1 seq:0 (assoc.0xc99e15a0):Hello.msg.1

From str:2 seq:0 (assoc:0xc99e15a0):Hello.msg.2

From str:3 seq:0 (assoc 0xc99e15a0):Hello.msg.3

From str:4 seq:0 (assoc.0xc99e15a0):Hello.msg.4

From str:5 seq:0 (assoc:0xc99e15a0):Hello.msg.5

From str:6 seq:0 (assoc.0xc99e15a0):Hello.msg.6

From str:7 seq:0 (assoc:0xc99e15a0):Hello.msg.7

From str:8 seq:0 (assoc:0xc99e15a0):Hello.msg.8

From str:9 seq:0 (assoc:0xc99e15a0).Hello.msg.9

^D

freebsd4%

В отсутствие потерь при передаче клиент получает ответы сервера в том же порядке, в котором отправляет запросы. Изменим параметры маршрутизатора таким образом, чтобы терять 10% всех пакетов, передаваемых в обоих направлениях, и перезапустим клиент.

freebsd4% sctpclient01 10.1.4.1 echo

Echoing messages to all streams

Hello

From str:0 seq:0 (assoc:0xc99e15a0):Hello.msg.0

From str:2 seq:0 (assoc:0xc99e15a0):Hello.msg.2

From str:3 seq:0 (assoc:0xc99e15a0):Hello.msg.3

From str:5 seq:0 (assoc:0xc99e15a0):Hello.msg.5

From str:1 seq:0 (assoc:0xc99e15a0):Hello.msg.1

From str:8 seq:0 (assoc:0xc99e15a0):Hello.msg.8

From str:4 seq:0 (assoc:0xc99e15a0):Hello.msg.4

From str:7 seq:0 (assoc:0xc99e15a0):Hello.msg.7

From str:9 seq:0 (assoc:0xc99e15a0):Hello.msg.9

From str:6 seq:0 (assoc:0xc99e15a0):Hello msg.6

^D

freebsd4%

Можно проверить, действительно ли сообщения в каждом из потоков доставляются в правильном порядке, если изменить клиента так, чтобы он отправлял по два сообщения в поток. Кроме того, мы добавим к сообщению суффикс с его номером, чтобы отличать эхо-ответы друг от друга. Измененная функция клиента представлена в листинге 10.5.

Листинг 10.5. Изменения в функции sctp_strcliecho

//sctp/sctp_strcliecho2.c

21 for (i =0; i < SERV_MAX_SCTP_STRM; i++) {

22 snprintf(sendline + strsz, sizeof(sendline) - strsz,

23 ".msg.%d 1", i);

24 Sctp_sendmsg(sock_fd, sendline, sizeof(sendline),

25 to, tolen, 0, 0, i, 0, 0);

26 snprintf(sendline + strsz, sizeof(sendline) - strsz,

27 ".msg.%d 2", i);

28 Sctp_sendmsg(sock_fd, sendline, sizeof(sendline),

29 to, tolen, 0, 0, i, 0, 0);

30 }

31 for (i = 0; i < SERV_MAX_SCTP_STRM*2, i++) {

32 len = sizeof(peeraddr);

22-25 Клиент добавляет к первому сообщению его номер, с помощью которого мы сможем отслеживать отправленные сообщения. Затем сообщение отсылается вызовом sctp_sendmsg.

26-29 Номер сообщения изменяется с единицы на двойку, после чего сообщение отсылается по тому же потоку.

31 Здесь требуется лишь одно незначительное изменение: количество ожидаемых ответов эхо-сервера должно быть удвоено.

Запустив сервер и измененный клиент, мы получаем следующий результат:

freebsd4% sctpclient01 10.1.4.1 echo

Echoing messages to all streams

Hello

From str:0 seq:0 (assoc:0xc99e15a0):Hello.msg.0 1

From str:0 seq:1 (assoc:0xc99e15a0):Hello.msg.0 2

From str:1 seq:0 (assoc:0xc99e15a0):Hello.msg.1 1

From str:4 seq:0 (assoc:0xc99e15a0):Hello.msg.4 1

From str:5 seq:0 (assoc:0xc99e15a0):Hello.msg.5 1

From str:7 seq:0 (assoc:0xc99e15a0):Hello.msg.7 1

From str:8 seq:0 (assoc:0xc99e15a0):Hello.msg.8 1

From str:9 seq:0 (assoc:0xc99e15a0):Hello.msg.9 1

From str:3 seq:0 (assoc:0xc99e15a0):Hello.msg.3 1

From str:3 seq:0 (assoc:0xc99e15a0):Hello.msg.3 2

From str:1 seq:0 (assoc:0xc99e15a0):Hello.msg.1 2

From str:5 seq:0 (assoc:0xc99e15a0):Hello.msg.5 2

From str:2 seq:0 (assoc:0xc99e15a0):Hello.msg.2 1

From str:6 seq:0 (assoc:0xc99e15a0):Hello.msg.6 1

From str:6 seq:0 (assoc:0xc99e15a0):Hello.msg.6 2

From str:2 seq:0 (assoc:0xc99e15a0):Hello.msg.2 2

From str:7 seq:0 (assoc:0xc99e15a0):Hello.msg.7 2

From str:8 seq:0 (assoc:0xc99e15a0):Hello.msg.8 2

From str:9 seq:0 (assoc:0xc99e15a0):Hello.msg.9 2

From str:4 seq:0 (assoc:0xc99e15a0):Hello.msg.4 2

^D

freebsd4%

Как видно из вывода, сообщения действительно теряются, но при этом задерживаются только те, которые относятся к конкретному потоку. Данные в остальных потоках не задерживаются. Потоки SCTP могут послужить мощным средством борьбы с блокированием очереди, позволяющим в то же время сохранять порядок данных в рамках конкретного набора сообщений.

Мы рассмотрели пример использования потоков SCTP, но пока что мы не знаем, каким образом можно контролировать количество потоков, запрашиваемых конечной точкой в процессе инициализации ассоциации. В предыдущих примерах мы работали с тем количеством исходящих потоков, которое было установлено в системе по умолчанию. В реализации SCTP для FreeBSD, созданной в рамках проекта KAME, это значение равно 10. А что, если серверу и клиенту нужно больше десяти потоков? В листинге 10.6 мы приводим модификацию кода сервера, позволяющую увеличивать количество потоков, запрашиваемое при создании ассоциации. Обратите внимание, что данный параметр сокета должен быть изменен до создания ассоциации.

Листинг 10.6. Вариант сервера, допускающий увеличение числа потоков

//sctp/sctpserv02.c

14 if (argc 2)

15 stream_increment = atoi(argv[1]);

16 sock_fd = Socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP);

17 bzero(&initm, sizeof(initm));

18 initm.sinit_num_ostreams = SERV_MORE_STRMS_SCTP;

19 Setsockopt(sock_fd, IPPROTO_SCTP, SCTP_INITMSG, &initm, sizeof(initm));

14-16 Как и в предыдущей версии программы, сервер устанавливает флаг stream_incrementв соответствии с дополнительным параметром командной строки, после чего открывает сокет.

17-19 Все сделанные модификации относятся именно к этим строкам. Сначала сервер обнуляет структуру sctp_initmsg. Это изменение гарантирует, что вызов setsockoptне приведет к непреднамеренному изменению каких-либо иных значений кроме того, которое нас интересует. Затем сервер устанавливает поле sinit_max_ostreamsравным количеству запрашиваемых потоков. После этого вызывается функция setsockoptс параметром сокета SCTP_INITMSGдля установки параметров сообщения INIT.

Альтернативой установке параметра сокета может быть вызов функции sendmsgсо вспомогательными данными, запрашивающими требуемое количество потоков. Передача вспомогательных данных приведет к желаемому результату только для сокетов типа «один-ко-многим».

В наших примерах на клиента была возложена ответственность по завершению ассоциации, для чего ему приходилось закрывать сокет. Но закрытие сокета не всегда является желаемой операцией с точки зрения приложения. Кроме того, серверу не нужно оставлять ассоциацию открытой после отправки эхо-ответа. В описанных ситуациях применяются альтернативные механизмы завершения ассоциации. Для сокетов типа «один-ко-многим» доступно два метода: корректное и аварийное закрытие.

Если сервер хочет закрыть ассоциацию после отправки сообщения, он должен добавить флаг MSG_EOF в это сообщение, поместив его в поле sinfo_flagsструктуры sctp_sndrcvinfo. Этот флаг закрывает ассоциацию после подтверждения приема отсылаемого сообщения. Альтернативный метод состоит в установке флага MSG_ABORTв том же поле sinfo_flags. При этом происходит немедленное закрытие ассоциации с отправкой порции ABORT (аналог TCP-сегмента RST). Данные, находящиеся в буфере отправки, сбрасываются. Однако закрытие сеанса SCTP порцией ABORT не приводит к негативным последствиям типа пропущенного состояния TIME_WAIT, как это происходит в TCP. В листинге 10.7 показана новая версия эхо-сервера, инициирующая корректное завершение соединения одновременно с отправкой эхо-ответа клиенту. В листинге 10.8 показана версия клиента, отправляющая порцию ABORT перед закрытием сокета.