UNIX: разработка сетевых приложений
UNIX: разработка сетевых приложений читать книгу онлайн
Новое издание книги, посвященной созданию веб-серверов, клиент-серверных приложений или любого другого сетевого программного обеспечения в операционной системе UNIX, — классическое руководство по сетевым программным интерфейсам, в частности сокетам. Оно основано на трудах Уильяма Стивенса и полностью переработано и обновлено двумя ведущими экспертами по сетевому программированию. В книгу включено описание ключевых современных стандартов, реализаций и методов, она содержит большое количество иллюстрирующих примеров и может использоваться как учебник по программированию в сетях, так и в качестве справочника для опытных программистов.
Внимание! Книга может содержать контент только для совершеннолетних. Для несовершеннолетних чтение данного контента СТРОГО ЗАПРЕЩЕНО! Если в книге присутствует наличие пропаганды ЛГБТ и другого, запрещенного контента - просьба написать на почту [email protected] для удаления материала
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_echoallsctpstr_cliSERV_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] = ' ';19 strsz--;20 }21 for (i=0; i<SERV_MAX_SCTP_STRM; i++) {22 snprintf(sendline + strsz, sizeof(sendline) - strsz,
