, он может идентифицировать клиента только одним способом - вызвать функцию
getpeername
. Это происходит, когда функция
inetd
(см. раздел 13.5) вызывает функции
fork
и
exec
для создания сервера TCP. Этот сценарий представлен на рис. 4.9. Функция
inetd
вызывает функцию
accept
(верхняя левая рамка), после чего возвращаются два значения: дескриптор присоединенного сокета
connfd
(это возвращаемое значение функции), а также IP-адрес и номер
порта клиента, отмеченные на рисунке небольшой рамкой с подписью «адрес собеседника» (структура адреса сокета Интернета). Далее вызывается функция
fork
и создается дочерний процесс функции
inetd
. Поскольку дочерний процесс запускается с копией содержимого памяти родительского процесса, структура адреса сокета доступна дочернему процессу, как и дескриптор присоединенного сокета (так как дескрипторы совместно используются родительским и дочерним процессами). Но когда дочерний процесс с помощью функции
exec
запускает выполнение реального сервера (скажем, сервера Telnet), содержимое памяти дочернего процесса заменяется новым программным файлом для сервера Telnet (то есть структура адреса сокета, содержащая адрес собеседника, теряется). Однако во время выполнения функции
exec
дескриптор присоединенного сокета остается открытым. Один из первых вызовов функции, который выполняет сервер Telnet, — это вызов функции
getpeername
для получения IP-адреса и номера порта клиента.
Рис. 4.9. Порождение сервера демоном inetd
Очевидно, что в приведенном примере сервер Telnet при запуске должен знать значение функции
connfd
. Этого можно достичь двумя способами. Во-первых, процесс, вызывающий функцию
exec
, может отформатировать номер дескриптора как символьную строку и передать ее в виде аргумента командной строки программе, выполняемой с помощью функции
exec
. Во-вторых, можно заключить соглашение относительно определенных дескрипторов: некоторый дескриптор всегда присваивается присоединенному сокету перед вызовом функции
exec
. Последний случай соответствует действию функции
inetd
— она всегда присваивает дескрипторы 0, 1 и 2 присоединенным сокетам.
Пример: получение семейства адресов сокета
Функция
sockfd_to_family
, представленная в листинге 4.4, возвращает семейство адресов сокета.
Листинг 4.4. Возвращаемое семейство адресов сокета
//lib/sockfd_to_family.c
1 #include "unp.h"
2 int
3 sockfd_to_family(int sockfd)
4 {
5 union {
6 struct sockaddr sa;
7 char data[MAXSOCKADDR];
8 } un;
9 socklen_t len;
10 len = MAXSOCKADDR;
11 if (getsockname(sockfd, (SA*)un.data, &len) < 0)
12 return (-1);
13 return (un.sa.sa_family);
14 }
Выделение пространства для наибольшей структуры адреса сокета
5-8
Поскольку мы не знаем, какой тип структуры адреса сокета нужно будет разместить в памяти, мы используем в нашем заголовочном файле
unp.h
константу
MAXSOCKADDR
,
которая представляет собой размер наибольшей структуры адреса сокета в байтах. Мы определяем массив типа
char
соответствующего размера в объединении, включающем универсальную структуру адреса сокета.
Вызов функции getsockname
10-13
Мы вызываем функцию
getsockname
и возвращаем семейство адресов.
Поскольку POSIX позволяет вызывать функцию
getsockname
на неприсоединенном сокете, эта функция должна работать для любого дескриптора открытого сокета.
4.11. Резюме
Все клиенты и серверы начинают работу с вызова функции
socket
, возвращающей дескриптор сокета. Затем клиенты вызывают функцию
connect
, в то время как серверы вызывают функции
bind
,
listen
и
accept
. Сокеты обычно закрываются с помощью стандартной функции
close
, хотя в разделе 6.6 вы увидите другой способ закрытия, реализуемый с помощью функции
shutdown
. Мы также проверим влияние параметра сокета
SO_LINGER
(см. раздел 7.5).
Большинство серверов TCP являются параллельными. При этом для каждого клиентского соединения, которым управляет сервер, вызывается функция
fork
. Вы увидите, что большинство серверов UDP являются последовательными. Хотя обе эти модели успешно использовались на протяжении ряда лет, имеются и другие возможности создания серверов с использованием программных потоков и процессов, которые мы рассмотрим в главе 30.
Упражнения
1. В разделе 4.4 мы утверждали, что константы
INADDR_
, определенные в заголовочном файле
<netinet/in.h>
, расположены в порядке байтов узла. Каким образом мы можем это определить?
2. Измените листинг 1.1 так, чтобы вызвать функцию
getsockname
после успешного завершения функции
connect
. Выведите локальный IP-адрес и локальный порт, присвоенный сокету TCP, используя функцию
sock_ntop
. В каком диапазоне (см. рис. 2.10) будут находиться динамически назначаемые порты вашей системы?
3. Предположим, что на параллельном сервере после вызова функции
fork
запускается дочерний процесс, который завершает обслуживание клиента перед тем, как результат выполнения функции
fork
возвращается родительскому процессу. Что происходит при этих двух вызовах функции
close
в листинге 4.3?
4. В листинге 4.2 сначала измените порт сервера с 13 на 9999 (так, чтобы для запуска программы вам не потребовались права привилегированного пользователя). Удалите вызов функции
listen
. Что происходит?
5. Продолжайте предыдущее упражнение. Удалите вызов функции
bind
, но оставьте вызов функции
listen
. Что происходит?
Глава 5
Пример TCP-соединения клиент-сервер
5.1. Введение
Напишем простой пример пары клиент-сервер, используя элементарные функции из предыдущей главы. Наш простой пример — это эхо-сервер, функционирующий следующим образом:
1. Клиент считывает строку текста из стандартного потока ввода и отправляет ее серверу.
2. Сервер считывает строку из сети и отсылает эту строку обратно клиенту.
3. Клиент считывает отраженную строку и помещает ее в свой стандартный поток вывода.
На рис. 5.1 изображена пара клиент-сервер вместе с функциями, используемыми для ввода и вывода.