Уильям Стивенс - UNIX: разработка сетевых приложений
- Название:UNIX: разработка сетевых приложений
- Автор:
- Жанр:
- Издательство:Питер
- Год:2007
- Город:Санкт-Петербург
- ISBN:5-94723-991-4
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Уильям Стивенс - UNIX: разработка сетевых приложений краткое содержание
Новое издание книги, посвященной созданию веб-серверов, клиент-серверных приложений или любого другого сетевого программного обеспечения в операционной системе UNIX, — классическое руководство по сетевым программным интерфейсам, в частности сокетам. Оно основано на трудах Уильяма Стивенса и полностью переработано и обновлено двумя ведущими экспертами по сетевому программированию. В книгу включено описание ключевых современных стандартов, реализаций и методов, она содержит большое количество иллюстрирующих примеров и может использоваться как учебник по программированию в сетях, так и в качестве справочника для опытных программистов.
UNIX: разработка сетевых приложений - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:

Рис. 7.1. Действие функции close, заданное по умолчанию: немедленное завершение
Мы предполагаем, что когда приходят данные клиента, сервер временно занят. Поэтому данные добавляются в приемный буфер сокета его протоколом TCP. Аналогично, следующий сегмент (сегмент FIN клиента) также добавляется к приемному буферу сокета (каким бы образом реализация ни сохраняла сегмент FIN). Но по умолчанию клиентская функция close
сразу же завершается. Как мы показываем в этом сценарии, клиентская функция close
может завершиться перед тем, как сервер прочитает оставшиеся данные в приемном буфере его сокета. Если узел сервера выйдет из строя перед тем, как приложение-сервер считает оставшиеся данные, клиентское приложение никогда об этом не узнает.
Клиент может установить параметр сокета SO_LINGER
, задав некоторое положительное время задержки. Когда это происходит, клиентская функция close
не завершается до тех пор, пока все данные клиента и его сегмент FIN не будут подтверждены протоколом TCP сервера. Мы показываем это на рис. 7.2.

Рис. 7.2. Закрытие сокета с параметром SO_LINGER и положительным l_linger
Но у нас остается та же проблема, что и на рис. 7.1: если на узле сервера происходит сбой до того, как приложение-сервер считает оставшиеся данные, клиентское приложение никогда не узнает об этом. Еще худший вариант развития событий показан на рис. 7.3, где значение SO_ LINGER
было установлено слишком маленьким.

Рис. 7.3. Закрытие сокета с параметром SO_LINGER при малом положительном l_linger
Основным принципом взаимодействия является то, что успешное завершение функции close
с установленным параметром сокета SO_LINGER
говорит нам лишь о том, что данные, которые мы отправили (и наш сегмент FIN) подтверждены протоколом TCP собеседника. Но это не говорит нам, прочитало ли данные приложение собеседника. Если мы не установим параметр сокета SO_LINGER
, мы не будем знать, подтвердил ли другой конец TCP отправленные ему данные.
Чтобы узнать, что сервер прочитал данные клиента, клиент может вызвать функцию shutdown
(со вторым аргументом SHUT_WR
) вместо функции close
и ждать, когда собеседник закроет с помощью функции close
свой конец соединения. Этот сценарий показан на рис. 7.4.

Рис. 7.4. Использование функции shutdown для проверки того, что собеседник получил наши данные
Сравнивая этот рисунок с рис. 7.1 и 7.2, мы видим, что когда мы закрываем наш конец соединения, то в зависимости от вызванной функции ( close
или shutdown
) и от того, установлен или нет параметр сокета SO_LINGER
, завершение может произойти в один из трех различных моментов времени: '
1. Функция close
завершается немедленно, без всякого ожидания (сценарий, заданный по умолчанию, см. рис. 7.1).
2. Функция close
задерживается до тех пор, пока не будет получен сегмент ACK, подтверждающий получение сервером сегмента FIN от клиента (см. рис. 7.2).
3. Функция shutdown
, за которой следует функция read
, ждет, когда мы получим сегмент FIN собеседника (в данном случае сервера) (см. рис. 7.2).
Другой способ узнать, что приложение-собеседник прочитало наши данные, — использовать подтверждение на уровне приложения , или ACK приложения . Например, клиент отправляет данные серверу и затем вызывает функцию read
для одного байта данных:
char ack;
Write(sockfd, data, nbytes); /* данные от клиента к серверу */
n = Read(sockfd, &ack, 1); /* ожидание подтверждения на уровне приложения */
Сервер читает данные от клиента и затем отправляет ему 1-байтовый сегмент — подтверждение на уровне приложения:
nbytes = Read(sockfd, buff, sizeof(buff)); /* данные от клиента */
/* сервер проверяет, верное ли количество данных он получил от клиента */
Write(sockfd, 1); /* сегмент ACK сервера возвращается клиенту */
Таким образом, мы получаем гарантию, что на момент завершения функции read на стороне клиента процесс сервера прочитал данные, которые мы отправили. (При этом предполагается, что либо сервер знает, сколько данных отправляет клиент, либо существует некоторый заданный приложением маркер конца записи, который мы здесь не показываем.) В данном случае сегмент ACK на уровне приложения представляет собой нулевой байт, но вообще содержимое этого сегмента можно использовать для передачи от сервера к клиенту сообщений о других условиях. На рис. 7.5 показан возможный обмен пакетами.

Рис. 7.5. ACK приложения
В табл. 7.4 описаны два возможных вызова функции shutdown
и три возможных вызова функции close
, а также их влияние на сокет TCP.
Таблица 7.4. Итоговая таблица сценариев функции shutdown и параметров сокета SO_LINGER
Функция | Описание |
---|---|
shutdown, SHUT_RD | Через сокет больше нельзя принимать данные; процесс может по-прежнему отправлять данные через этот сокет; приемный буфер сокета сбрасывается; все данные, получаемые в дальнейшем, игнорируются протоколом TCP (см. упражнение 6.5); не влияет на буфер отправки сокета |
shutdown, SHUT_WR | Через сокет больше нельзя отправлять данные; процесс может по-прежнему получать данные через этот сокет; содержимое буфера отправки сокета отсылается на другой конец соединения, затем выполняется обычная последовательность действий по завершению соединения TCP (FIN); не влияет на приемный буфер сокета |
close, l_onoff = 0 (по умолчанию) | Через сокет больше нельзя отправлять и получать данные; содержимое буфера отправки сокета отсылается на другой конец соединения. Если счетчик ссылок дескриптора становится нулевым, то следом за отправкой данных из буфера отправки сокета выполняется нормальная последовательность завершения соединения TCP (FIN), данные из приемного буфера сокета сбрасываются |
close, l_onoff = 1 l_linger = 0 | Через сокет больше нельзя отправлять и получать данные. Если счетчик ссылок дескриптора становится нулевым, то на другой конец соединения посылается сегмент RST, соединение переходит в состояние в CLOSED (минуя состояние TIME_WAIT), данные из буфера отправки и приемного буфера сокета сбрасываются |
close, l_onoff = 1 l_linger = 0 | Через сокет больше нельзя отправлять и получать данные; содержимое буфера отправки сокета отсылается на другой конец соединения. Если счетчик ссылок дескриптора становится нулевым, то следом за отправкой данных из буфера отправки сокета выполняется нормальная последовательность завершения соединения TCP (FIN), данные из приемного буфера сокета сбрасываются, и если время задержки истекает, прежде чем оставшиеся в буфере данные будут посланы и будет подтвержден их прием, функция close возвратит ошибку EWOULDBLOCK |
Параметр сокета SO_OOBINLINE
Интервал:
Закладка: