Уильям Стивенс - UNIX: разработка сетевых приложений
- Название:UNIX: разработка сетевых приложений
- Автор:
- Жанр:
- Издательство:Питер
- Год:2007
- Город:Санкт-Петербург
- ISBN:5-94723-991-4
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Уильям Стивенс - UNIX: разработка сетевых приложений краткое содержание
Новое издание книги, посвященной созданию веб-серверов, клиент-серверных приложений или любого другого сетевого программного обеспечения в операционной системе UNIX, — классическое руководство по сетевым программным интерфейсам, в частности сокетам. Оно основано на трудах Уильяма Стивенса и полностью переработано и обновлено двумя ведущими экспертами по сетевому программированию. В книгу включено описание ключевых современных стандартов, реализаций и методов, она содержит большое количество иллюстрирующих примеров и может использоваться как учебник по программированию в сетях, так и в качестве справочника для опытных программистов.
UNIX: разработка сетевых приложений - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Есть два способа оптимизации, которые мы не используем в этом примере (чтобы не усложнять его еще больше). Во-первых, мы можем завершить цикл for в листинге 16.13, когда мы обработали число дескрипторов, которые, по сообщению функции select
, были готовы. Во-вторых, мы могли, где это возможно, уменьшить значение maxfd
, чтобы функция select
не проверяла биты дескрипторов, которые уже сброшены. Поскольку число дескрипторов, используемых в этом коде, в любой момент времени, вероятно, меньше 10, а не порядка тысяч, вряд ли какая-либо из этих оптимизаций стоит дополнительных усложнений.
Эффективность одновременных соединений
Каков выигрыш в эффективности при установлении множества одновременных соединений? В табл. 16.1 показано время, необходимое для выполнения определенной задачи, которая состоит в том, чтобы получить от веб-сервера домашнюю страницу и девять картинок. Время обращения RTT для данного соединения с сервером равно приблизительно 150 мс. Размер домашней страницы — 4017 байт, а средний размер девяти файлов с изображениями составил 1621 байт. Размер сегмента TCP равен 512 байт. Для сравнения мы также представляем в этой таблице значения для многопоточной версии данной программы, которую мы создаем в разделе 26.9.
Таблица 16.1. Время выполнения задания для разного количества одновременных соединений в разных версиях программы
Количество одновременных соединений | Затраченное время (в секундах), отсутствие блокирования | Затраченное время (в секундах), использование потоков |
---|---|---|
1 | 6,0 | 6,3 |
2 | 4,1 | 4,2 |
3 | 3,0 | 3,1 |
4 | 2,8 | 3,0 |
5 | 2,5 | 2,7 |
6 | 2,4 | 2,5 |
7 | 2,3 | 2,3 |
8 | 2,2 | 2,3 |
9 | 2,0 | 2,3 |
Мы показали пример использования одновременных соединений, поскольку он служит хорошей иллюстрацией применения неблокируемого ввода-вывода, а также потому, что в данном случае эффективность применения одновременных соединений может быть измерена. Это свойство также используется в популярном приложении — веб-браузере Netscape. В этой технологии могут появиться некоторые «подводные камни», если сеть перегружена. В главе 21 [111] подробно описываются алгоритмы TCP, называемые алгоритмами медленного старта (slow start) и предотвращения перегрузки сети (congestion avoidance). Когда от клиента к серверу устанавливается множество соединений, то взаимодействие между соединениями на уровне TCP отсутствует. То есть если на одном из соединений происходит потеря пакета, другие соединения с тем же сервером не получают соответствующего уведомления, и вполне возможно, что другие соединения вскоре также столкнутся с потерей пакетов, пока не замедлятся. По этим дополнительным соединениям будет продолжаться отправка слишком большого количества пакетов в уже перегруженную сеть. Эта технология также увеличивает нагрузку на сервер.
Максимальное увеличение эффективности происходит при трех одновременных соединениях (время уменьшается вдвое), а при четырех и более одновременных соединениях прирост производительности значительно меньше.
16.6. Неблокируемая функция accept
Как было сказано в главе 6, функция select
сообщает, что прослушиваемый сокет готов для чтения, когда установленное соединение готово к обработке функцией accept
. Следовательно, если мы используем функцию select
для определения готовности входящих соединений, то нам не нужно делать прослушиваемый сокет неблокируемым, потому что когда функция select
сообщает нам, что соединение установлено, функция accept
обычно не является блокируемой.
К сожалению, существует определенная проблема, связанная со временем, способная запутать нас [34]. Чтобы увидеть эту проблему, изменим код нашего эхо- клиента TCP (см. листинг 5.3) таким образом, чтобы после установления соединения серверу отсылался сегмент RST. В листинге 16.14 представлена новая версия.
Листинг 16.14. Эхо-клиент TCP, устанавливающий соединение и посылающий серверу сегмент RST
//nonblock/tcpcli03.c
1 #include "unp.h"
2 int
3 main(int argc, char **argv)
4 {
5 int sockfd;
6 struct linger ling;
7 struct sockaddr_in servaddr;
8 if (argc != 2)
9 err_quit("usage: tcpcli ");
10 sockfd = Socket(AF_INET, SOCK_STREAM, 0);
11 bzero(&servaddr, sizeof(servaddr));
12 servaddr.sin_family = AF_INET;
13 servaddr.sin_port = htons(SERV_PORT);
14 Inet_pton(AF_INET, argv[1], &servaddr.sin_addr);
15 Connect(sockfd, (SA*)&servaddr, sizeof(servaddr));
16 ling.l_onoff = 1; /* для отправки сегмента RST при закрытии соединения */
17 ling.l_linger = 0;
18 Setsockopt(sockfd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling));
19 Close(sockfd);
20 exit(0);
21 }
16-19
Как только соединение устанавливается, мы задаем параметр сокета SO_LINGER
, устанавливая флаг l_onoff
в единицу и обнуляя время l_linger
. Как утверждалось в разделе 7.5, это вызывает отправку RST на сокете TCP при закрытии соединения. Затем с помощью функции close
мы закрываем сокет.
Потом мы изменяем наш сервер TCP, приведенный в листингах 6.3 и 6.4, с тем чтобы после сообщения функции select
о готовности прослушиваемого сокета для чтения, но перед вызовом функции accept
наступала пауза. В следующем коде, взятом из начала листинга 6.4, две добавленные строки помечены знаком +
.
if (FD_ISSET(listenfd, &rset)) { /* новое соединение */
+ printf("listening socket readable\n");
+ sleep(5);
clilen = sizeof(cliaddr);
connfd = Accept(listenfd, (SA*)&cliaddr, &clilen);
Здесь мы имитируем занятый сервер, который не может вызвать функцию accept
сразу же, как только функция select
сообщит, что прослушиваемый сокет готов для чтения. Обычно подобное замедление со стороны сервера не вызывает проблем (на самом деле именно для этих ситуаций предусмотрена очередь полностью установленных соединений). Но поскольку после установления соединения от клиента прибыл сегмент RST, у нас возникает проблема.
В разделе 5.11 мы отмечали, что когда клиент разрывает соединение до того, как сервер вызывает функцию accept
, в Беркли-реализациях прерванное соединение не возвращается серверу, в то время как другие реализации должны возвращать ошибку ECONNABORTED
, но часто вместо нее возвращают ошибку EPROTO
. Рассмотрим Беркли-реализацию.
■ Клиент устанавливает соединение и затем прерывает его, как показано в листинге 16.14.
■ Функция select
сообщает процессу сервера, что дескриптор готов для чтения, но у сервера вызов функции accept
занимает некоторое, хотя и непродолжительное, время.
■ После того, как сервер получил сообщение от функции select
, и прежде, чем была вызвана функция accept
, прибыл сегмент RST от клиента.
Интервал:
Закладка: