freebsd4% <b>sctpclient01 10.1.1.5</b>
<b>[0]Hello </b> <i>Отправка сообщения по потоку 0</i>
From str:1 seq:0 (assoc:0xc99e15a0):[0]Hello <i>Эхо-ответ сервера в потоке 1</i>
<b>[4]Message two</b> <i>Отправка сообщения по потоку 4</i>
From str:5 seq:0 (assoc.0xc99e15a0):[4]Message two <i>Эхо-ответ сервера</i>
<i> в потоке 5</i>
<b>[4]Message three</b> <i>Отправка сообщения по потоку 4</i>
From str:5 seq:1 (assoc 0xc99e15a0):[4]Message three <i>Эхо-ответ сервера</i>
<i> в потоке 5</i>
<b>^D</b> <i>Ввод символа EOF</i>
freebsd4%
Обратите внимание, что клиент отправляет сообщения по потокам 0 и 4, а сервер отвечает ему по потокам 1 и 5. Именно такое поведение и ожидается в том случае, когда наш сервер запускается без аргументов командной строки. Заметьте также, что порядковый номер сообщения по пятому потоку увеличился на единицу при приеме третьего сообщения, как и должно было произойти.
10.5. Блокирование очереди
Наш сервер позволяет отправлять текстовые сообщения по любому из нескольких потоков. Поток SCTP — это вовсе не поток байтов, как в TCP. Это последовательность сообщений, упорядоченных в пределах ассоциации. Потоки с собственным порядком используются для того, чтобы обойти блокирование очереди (head-of-line blocking), которое может возникать в TCP.
Блокирование возникает при потере сегмента TCP при передаче и приходе следующего за ним сегмента, который удерживается до тех пор, пока утраченный сегмент не будет передан повторно и получен адресатом. Задержка доставки последующих сегментов гарантирует, что приложение получит данные в том порядке, в котором они были отправлены. Это совершенно необходимая функция, которая, к сожалению, обладает определенными недостатками. Представьте, что семантически независимые сообщения передаются по одному соединению TCP. Например, веб-сервер может передать браузеру три картинки для отображения на экране. Чтобы картинки выводились на экран одновременно, сервер передает сначала часть первого изображения, затем часть второго и часть третьего. Процесс повторяется до тех пор, пока все три картинки не будут переданы клиенту целиком. Что произойдет, если потеряется сегмент TCP, относящийся к первому изображению? Клиент не получит никаких данных до тех пор, пока недостающий сегмент не будет передан повторно и доставлен ему. Задержаны будут все три изображения, хотя сегмент относился только к одному из них (первому). Эту ситуацию иллюстрирует рис. 10.2.
Рис. 10.2. Отправка трех изображений по одному TCP-соединению
ПРИМЕЧАНИЕ
Хотя HTTP работает иначе, были предложены расширения этого протокола, такие как SCP [108] и SMUX [33], которые обеспечивают описанную функциональность поверх TCP. Эти протоколы мультиплексирования позволяют избежать проблем, связанных с параллельными TCP-соединениями, не имеющими общей информации о состоянии [123]. Несмотря на то что создание одного TCP-соединения для каждого изображения (как обычно и делают клиенты HTTP) позволяет избежать блокирования, каждому соединению приходится тратить время на определение времени обращения и доступной пропускной способности. Потеря сегмента, относящегося к одному соединению (признак затора на линии) не обязательно приводит к замедлению передачи по остальным соединениям. В результате совокупное использование загруженных сетей падает.
Для приложения было бы лучше, если бы транспортный протокол вел себя иначе. В идеале задерживаться должны только сегменты первой картинки, тогда как сегменты второй и третьей должны доставляться так, как если бы сегмент первой картинки не был утерян вовсе.
Многопоточный режим SCTP позволяет свести к минимуму блокирование очереди. На рис. 10.3 мы показываем процесс отправки тех же трех изображений. На этот раз сервер использует потоки, так что блокируется только одно изображение, а второе и третье доставляются без помех. Первое изображение не доставляется до тех пор, пока не будет восстановлен порядок сегментов.
Рис. 10.3. Отправка трех изображений по потокам SCTP
Теперь мы можем привести полный код нашего клиента (с функцией
sctpstr_cli_echoall
, листинг 10.4), чтобы на его примере продемонстрировать устранение проблем с блокированием очереди при помощи SCTP. Новая функция аналогична
sctpstr_cli
за тем исключением, что клиент больше не требует указания номера потока в квадратных скобках в каждом сообщении. Функция передает сообщение пользователя по всем потокам, количество которых определяется константой
SERV_MAX_SCTP_STRM
. После отправки сообщения клиент ждет прихода всех ответных сообщений сервера. Запуская сервер, мы передаем ему аргумент командной строки, указывающий на то, что сервер должен отвечать на сообщения по тем же потокам, по которым они приходят. Это позволяет пользователю отслеживать ответы и порядок их прибытия.
Листинг 10.4. Функция sctp_strcliecho
1 #include "unp.h"
2 #define SCTP_MAXLINE 800
3 void
4 sctpstr_cli_echoall(FILE *fp, int sock_fd, struct sockaddr to,
5 socklen_t tolen)
6 {
7 struct sockaddr_in peeraddr;
8 struct sctp_sndrcvinfo sri;
9 char sendline[SCTP_MAXLlNE], recvline[SCTP_MAXLINE];
10 socklen_t len;
11 int rd_sz, i, strsz;
12 int msg_flags;
13 bzero(sendline, sizeof(sendline));
14 bzero(&sri, sizeof(sri));
15 while (fgets(sendline, SCTP_MAXLINE - 9, fp) != NULL) {
16 strsz = strlen(sendline);
17 if (sendline[strsz-1] == '\n') {
18 sendline[strsz-1] = '\0';
19 strsz--;
20 }
21 for (i=0; i<SERV_MAX_SCTP_STRM; i++) {
22 snprintf(sendline + strsz, sizeof(sendline) - strsz,
