user = root
server = /usr/sbin/vsftpd
}
Сервис
daytime
, к которому подключается программа
getdate
, обычно обрабатывается самой программой xinetd (он помечен как внутренний) и может включаться с помощью как сокетов типа
SOCK_STREAM
(tcp), так и сокетов типа
SOCK_DGRAM
(udp).
Сервис передачи файлов
ftp
подключается только сокетами типа
SOCK_STREAM
и предоставляется внешней программой, в данном случае vsftpd. Демон будет запускать эту внешнюю программу, когда клиент подключится к порту
ftp
.
Для активизации конфигурационных изменений сервиса можно отредактировать конфигурацию xinetd и отправить сигнал отбоя (hang-up) процессу-демону, но мы рекомендуем использовать более дружелюбный способ настройки сервисов. Для того чтобы разрешить вашему клиенту подключаться к сервису
daytime
, включите этот сервис с помощью средств, предоставляемых системой Linux. В системах SUSE и openSUSE сервисы можно настраивать из SUSE Control Center (Центр управления SUSE), как показано на рис. 15.1. У версий Red Hat (и Enterprise Linux, и Fedora) есть похожий интерфейс настройки. В нем сервис
daytime
включается для TCP- и UDP-запросов.
Рис. 15.1
Для систем, применяющих программу inetd вместо xinetd, далее приведено эквивалентное извлечение из файла конфигурации inetd, /etc/inetd.conf, которое программа inetd использует для принятия решения о запуске серверов:
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
# Echo, discard, daytime и chargen используются в основном для
# тестирования.
#
daytime stream tcp nowait root internal
daytime dgram udp wait root internal
#
# Это стандартные сервисы.
#
ftp stream tcp-nowait root /usr/sbin/tcpd /usr/sbin/wu.ftpd
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
#
# Конец файла inetd.conf.
Обратите внимание на то, что в нашем примере сервис ftp предоставляется внешней программой wu.ftpd. Если в вашей системе выполняется демон inetd, вы можете изменить набор предоставляемых сервисов, отредактировав файл /etc/inetd.conf (знак # в начале строки указывает на то, что это строка комментария) и перезапустив процесс inetd. Сделать это можно, отправив сигнал отбоя (hang-up) с помощью команды
kill
. Для облегчения этого процесса некоторые системы настроены так, что программа inetd записывает свой ID в файл. В противном случае можно применить команду
killall
:
# <b>killall -HUP inetd</b>
Параметры сокета
Существует много параметров, которые можно применять для управления поведением соединений на базе сокетов — слишком много для подробного описания в этой главе. Для манипулирования параметрами используют функцию
setsockopt
:
<b>#include <sys/socket.h></b>
<b>int setsockopt(int socket, int level, int option_name,</b>
<b> const void *option value, size_t option len);</b>
Задавать параметры можно на разных уровнях иерархии протоколов. Для установки параметров на уровне сокета вы должны задать
level
равным
SOL_SOCKET
. Для задания параметров на более низком уровне протоколов (TCP, UDP и т.д.) приравняйте параметр level номеру протокола (полученному либо из заголовочного файла netinet/in.h, либо из функции
getprotobyname
).
В аргументе
option_name
указывается имя задаваемого параметра, аргумент
option_value
содержит произвольное значение длиной
option_len
байтов, передаваемое без изменений обработчику низкоуровневого протокола.
Параметры уровня сокета определены в заголовочном файле sys/socket.h и включают приведенные в табл. 15.4 значения.
Таблица 15.5
| Параметр | Описание |
SO_DEBUG
| Включает отладочную информацию |
SO_KEEPALIVE
| Сохраняет активными соединения при периодических передачах |
SO_LINGER
| Завершает передачу перед закрытием |
Параметры
SO_DEBUG
и
SO_KEEPALIVE
принимают целое значение
option_value
для установки или включения (1) и сброса или выключения (0). Для параметра
SO_LINGER
нужна структура типа
linger
, определенная в файле sys/socket.h и задающая состояние параметра и величину интервала задержки.
Функция
setsockopt
возвращает 0 в случае успеха и -1 в противном случае. На страницах интерактивного справочного руководства описаны дополнительные параметры и ошибки.
Множественные клиенты
До сих пор в этой главе вы видели, как применяются сокеты для реализации клиент-серверных систем, как локальных, так действующих, в сети. После установки соединения на базе сокетов они ведут себя как низкоуровневые открытые файловые дескрипторы и во многом как двунаправленные каналы.
Теперь необходимо рассмотреть случай множественных клиентов, одновременно подключающихся к серверу. Вы видели, что, когда серверная программа принимает от клиента запрос на соединение, создается новый сокет, а исходный сокет, ожидающий запросы на соединение, остается доступен для последующих запросов. Если сервер не сможет немедленно принять поступившие позже запросы на соединения, они сохранятся в очереди ожидания.
Тот факт, что исходный сокет все еще доступен, и что сокеты ведут себя как файловые дескрипторы, дает нам метод одновременного обслуживания многих клиентов. Если сервер вызовет функцию
fork
для создания своей второй копии, открытый сокет будет унаследован новым дочерним процессом. Далее он сможет обмениваться данными с подключившимся клиентом, в то время как основной сервер продолжит прием последующих запросов на соединение. В действительности в вашу программу сервера нужно внести очень простое изменение, показанное в упражнении 15.7.
