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

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

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

Жанр: Компьютеры и Интернет / ОС и Сети

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

Автор: Стивенс Уильям Ричард

Дата добавления: 16 январь 2020

Количество просмотров: 389

Читать онлайн

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

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

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

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

ВПЕРЕД

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

11 cliaddr = Malloc(MAXSOCKADDR);

12 len = MAXSOCKADDR;

13 Getpeername(0, cliaddr, &len);

14 err_msg("connection from %s", Sock_ntop(cliaddr, len));

15 ticks = time(NULL);

16 snprintf(buff, sizeof(buff), "%.24srn", ctime(&ticks));

17 Write(0, buff, strlen(buff));

18 Close(0); /* закрываем соединение TCP */

19 exit(0);

20 }

В программе сделано два важных изменения. Во-первых, исчез весь код создания сокета: вызовы функций

tcp_listen

accept

. Эти шаги выполняются демоном

inetd

, и мы ссылаемся на соединение TCP, используя нулевой дескриптор (стандартный поток ввода). Во-вторых, исчез бесконечный цикл

for

, поскольку сервер активизируется по одному разу для каждого клиентского соединения. После предоставления сервиса клиенту сервер завершает свою работу.

Вызов функции getpeername

11-14

Поскольку мы не вызываем функцию

tcp_listen

, мы не знаем размера структуры адреса сокета, которую она возвращает, а поскольку мы не вызываем функцию

accept

, то не знаем и адреса протокола клиента. Следовательно, мы выделяем буфер для структуры адреса сокета, используя нашу константу

MAXSOCKADDR

и вызываем функцию

getpeername

с нулевым дескриптором в качестве первого аргумента.

Чтобы выполнить этот пример в нашей системе Solaris, сначала мы присваиваем службе имя и порт, добавляя следующую строку в

/etc/services

mydaytime 9999/tcp

Затем добавляем строку в

/etc/inetd.conf

mydaytime stream tcp nowait andy

/home/andy/daytimetcpsrv3 daytimetcpsrv3

(Мы разбили длинную строку на более короткие.) Мы помещаем выполняемый код в заданный файл и отправляем демону

inetd

сигнал

SIGHUP

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

netstat

, чтобы проверить, что на порте TCP 9999 создан прослушиваемый сокет:

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

*.9999 *.* 0 0 49152 0 LISTEN

Затем мы запускаем сервер с другого узла:

linux % <b>telnet solaris 9999</b>

Trying 192.168.1.20...

Connected to solaris.

Escape character is '^]'.

Tue Jun 10 11:04:02 2003

Connection closed by foreign host.

Файл

/var/amd/messages

(в который, как указано в нашем файле

/etc/syslog.conf

, должны направляться наши сообщения с аргументом

facility=LOG_USER

) содержит запись:

Jun 10 11:04:02 solaris daytimetcpsrv3[28724]: connection from 192.168.1.10.58145

13.7. Резюме

Демоны — это процессы, выполняемые в фоновом режиме независимо от управления с терминалов. Многие сетевые серверы работают как демоны. Все выходные данные демона обычно отправляются демону

syslogd

при помощи вызова функции

syslog

. Администратор полностью контролирует все, что происходит с этими сообщениями, основываясь на том, какой демон отправил данное сообщение и насколько оно серьезно.

Чтобы запустить произвольную программу и выполнять ее в качестве демона, требуется пройти несколько шагов: вызвать функцию

fork

для запуска в фоновом режиме, вызвать функцию

setsid

для того, чтобы создать новый сеанс POSIX и стать главным процессом сеанса, снова вызвать функцию

fork

, чтобы избежать перехода в режим управления с терминала, изменить рабочий каталог и маску режима создания файла и закрыть все ненужные файлы. Наша функция

daemon_init

выполняет все эти шаги.

Многие серверы Unix запускаются демоном

inetd

. Он осуществляет все необходимые шаги по превращению процесса в демон, и при запуске действительного сервера открывается сокет для стандартных потоков ввода, вывода и сообщений об ошибках. Это позволяет нам опустить вызовы функций

socket

bind

listen

accept

, поскольку все эти шаги выполняются демоном

inetd

Упражнения

1. Что произойдет в листинге 13.2, если мы отложим вызов функции

daemon_init

до завершения обработки аргументов командной строки и функция

err_quit

будет вызвана до того, как программа станет демоном?

2. Как вы думаете, какие из 10 серверов, перечисленных в табл. 2.1 (учитываются версии TCP и UDP для каждой из пяти служб, управляемых демоном

inetd

), реализуются с помощью вызова функции fork, а какие не требуют этой функции?

3. Что произойдет, если мы создадим сокет UDP, свяжем порт 7 с сокетом (стандартный эхо-сервер в табл. 2.1) и отправим дейтаграмму UDP-серверу

chargen

4. В руководстве Solaris 2.x для демона

inetd

описывается флаг

-t

, заставляющий демон

inetd

вызывать функцию

syslog

(с аргументами

facility=LOG_DAEMON

level=LOG_NOTICE

) для протоколирования клиентского IP-адреса и порта любой службы TCP, которые обрабатывает демон

inetd

. Как демон

inetd

получает эту информацию?

В этом же руководстве сказано, что демон

inetd

не может выполнить это для сокета UDP. Почему?

Есть ли способ обойти эти ограничения для служб UDP?

Глава 14

Дополнительные функции ввода-вывода

14.1. Введение

Эта глава охватывает разнообразные функции и технологии, которые мы помещаем в общую категорию «расширенного ввода-вывода». Сначала мы описываем установку тайм-аута для операции ввода-вывода, которую можно выполнить тремя различными способами. Затем мы рассматриваем три варианта функций

read

write

recv

send

, допускающие четвертый аргумент, содержащий флаги, передаваемые от процесса к ядру;

readv

writev

, позволяющие нам задавать массив буферов для ввода или вывода;

recvmsg

sendmsg

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