UNIX: разработка сетевых приложений

На нашем литературном портале можно бесплатно читать книгу UNIX: разработка сетевых приложений, Стивенс Уильям Ричард-- . Жанр: ОС и Сети. Онлайн библиотека дает возможность прочитать весь текст и даже без регистрации и СМС подтверждения на нашем литературном портале bazaknig.info.
UNIX: разработка сетевых приложений
Название: UNIX: разработка сетевых приложений
Дата добавления: 16 январь 2020
Количество просмотров: 771
Читать онлайн

UNIX: разработка сетевых приложений читать книгу онлайн

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

Новое издание книги, посвященной созданию веб-серверов, клиент-серверных приложений или любого другого сетевого программного обеспечения в операционной системе UNIX, — классическое руководство по сетевым программным интерфейсам, в частности сокетам. Оно основано на трудах Уильяма Стивенса и полностью переработано и обновлено двумя ведущими экспертами по сетевому программированию. В книгу включено описание ключевых современных стандартов, реализаций и методов, она содержит большое количество иллюстрирующих примеров и может использоваться как учебник по программированию в сетях, так и в качестве справочника для опытных программистов.

Внимание! Книга может содержать контент только для совершеннолетних. Для несовершеннолетних чтение данного контента СТРОГО ЗАПРЕЩЕНО! Если в книге присутствует наличие пропаганды ЛГБТ и другого, запрещенного контента - просьба написать на почту [email protected] для удаления материала

Перейти на страницу:

solaris % <b>sock -s -u 8888 &amp;</b> <i>запускаем первый</i>

[1] 24051

solaris % <b>sock -s -u 8888</b>

can't bind local address: Address already in use

solaris % <b>sock -s -u -A 8888 &amp;</b> <i>снова пробуем запустить второй с -A:</i>

<i>                               работает</i>

solaris % <b>netstat -na | grep 8888</b> <i>мы видим дублированное связывание</i>

*.8888 Idle

* 8888 Idle

В этой системе задавать параметр

SO_REUSEADDR
было необходимо только для второго связывания. Наконец, запускаем сценарий в MacOS X 10.2.6, где поддерживается как многоадресная передача, так и параметр
SO_REUSEPORT
. Сначала пробуем использовать
SO_REUSEADDR
для обоих серверов, но это не работает.

macosx % <b>sock -u -s -A 7777 &amp;</b>

[1] 17610

macosx % <b>sock -u -s -A 7777</b>

can't bind local address: Address already in use

Тогда пробуем использовать параметр

SO_REUSEPORT
только для второго сервера. Это также не работает, так как полностью дублированное связывание требует включения данного параметра для всех сокетов, совместно использующих соединение.

macosx % <b>sock -u -s 8888 &amp;</b>

[1] 17612

macosx % <b>sock -u -s -T 8888</b>

can't bind local address: Address already in use

Наконец, задаем параметр

SO_REUSEPORT
для обоих серверов, и этот вариант работает.

macosx % <b>sock -u -s -Т 9999 &amp;</b>

[1] 17614

macosx % <b>sock -u -s -T 9999 &amp;</b>

[2] 17615

macosx % <b>netstat -na | grep 9999</b>

udp4 0 0 *.9999 *.*

udp4 0 0 *.9999 *.*

7.7. Этот параметр (

-d
) не делает ничего, поскольку программа
ping
использует ICMP-сокет, а параметр сокета
SO_DEBUG
влияет только на TCP-сокеты. Описание параметра сокета
SO_DEBUG
всегда было довольно расплывчатым, наподобие «этот параметр допускает отладку на соответствующем уровне протокола», и единственный уровень протокола, где реализуется данный параметр — это TCP.

7.8. Временная диаграмма приведена на рис. Д.4.

UNIX: разработка сетевых приложений - img_188.png

Рис. Д.4. Взаимодействие алгоритма Нагла с задержанными сегментами ACK

7.9. Установка параметра сокета

TCP_NODELAY
приводит к немедленной отправке данных из второй функции
write
, даже если имеется еще один небольшой пакет, ожидающий отправки. Это показано на рис. Д.5. Полное время в данном примере превышает 150 мс.

UNIX: разработка сетевых приложений - img_189.png

Рис Д.5. Предотвращение алгоритма Нагла путем установки параметра TCP_NODELAY

7.10. Как показано на рис. Д.6, преимущество данного решения состоит в уменьшении числа пакетов.

UNIX: разработка сетевых приложений - img_190.png

Рис. Д.6. Использование функции writev вместо параметра сокета TCP_NODELAY

7.11. В разделе 4.2.3.2 говорится: «задержка ДОЛЖНА быть меньше 0,5 с, а в потоке полноразмерных сегментов СЛЕДУЕТ использовать сегмент ACK по крайней мере для каждого второго сегмента». Беркли-реализации задерживают сегмент ACK не более, чем на 200 мс [128, с. 821].

7.12. Родительский процесс сервера в листинге 5.1 большую часть времени блокирован в вызове функции

accept
, а дочерний процесс в листинге 5.2 большую часть времени блокирован в вызове функции
read
, который содержится в функции
readline
. Проверка работоспособности с помощью параметра
SO_KEEPALIVE
не влияет на прослушиваемый сокет, поэтому в случае, если клиентский узел выйдет из строя, родительский процесс не пострадает. Функция read дочернего процесса возвратит ошибку
ETIMEDOUT
примерно через 2 ч после последнего обмена данными через соединение.

7.13. Клиент, приведенный в листинге 5.4, большую часть времени блокирован вызовом функции

fgets
, который, в свою очередь, блокирован операцией чтения из стандартной библиотеки ввода-вывода на стандартном устройстве ввода. Когда примерно через 2 ч после последнего обмена данными через соединение истечет время таймера проверки работоспособности и проверочные сообщения не выявят работоспособности сервера, ошибка сокета, ожидающая обработки, примет значение
ETIMEDOUT
. Но клиент блокирован вызовом функции
fgets
, поэтому он не увидит этой ошибки, пока не осуществит чтение или запись на сокете. Это одна из причин, по которой в главе 6 листинг 5.4 был изменен таким образом, чтобы использовать функцию
select
.

7.14. Этот клиент большую часть времени блокирован вызовом функции

select
, которая сообщит, что сокет готов для чтения, как только ожидающая обработки ошибка будет установлена в
ETIMEDOUT
(как показано в предыдущем решении).

7.15. Происходит обмен только двумя сегментами, а не четырьмя. Вероятность того, что таймеры двух систем будут строго синхронизированы, очень мала, следовательно, на одном конце соединения таймер проверки работоспособности сработает немного раньше, чем на другом. Первый из сработавших таймеров посылает проверочное сообщение, заставляя другой конец послать в ответ сегмент ACK. Но получение проверочного сообщения приводит к тому, что таймеру проверки работоспособности с более медленными часами будет присвоено новое значение — он сдвинется на 2 ч вперед.

7.16 Изначально в API сокетов не было функции

listen
. Вместо этого четвертый аргумент функции
socket
содержал параметр сокета, а параметр
SO_ACCEPTCONN
использовался для задания прослушиваемого сокета. Когда добавилась функция
listen
, флаг остался, но теперь его может устанавливать только ядро [128, с. 456].

Глава 8

8.1. Да. Функция

read
возвращает 4096 байт данных, а функция
recvfrom
возвращает 2048 байт (первую из двух дейтаграмм). Функция
recvfrom
на сокете дейтаграмм никогда не возвращает больше одной дейтаграммы, независимо от того, сколько приложение запрашивает.

Перейти на страницу:
Комментариев (0)
название