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

Рассмотрим пример, иллюстрирующий листинг 4.3. Прежде всего, на рис. 4.5 показано состояние клиента и сервера в тот момент, когда сервер блокируется при вызове функции accept и от клиента приходит запрос на соединение.
Рис. 4.5. Состояние соединения клиент-сервер перед завершением вызванной функции accept
Сразу же после завершения функции 
accept
 мы получаем сценарий, изображенный на рис. 4.6. Соединение принимается ядром и создается новый сокет — 
connfd
. Это присоединенный сокет, и теперь данные могут считываться и записываться по этому соединению.
Рис. 4.6. Состояние соединения клиент-сервер после завершения функции accept
Следующим действием параллельного сервера является вызов функции 
fork
. На рис. 4.7 показано состояние соединения после вызова функции 
fork
.
Рис. 4.7. Состояние соединения клиент-сервер после вызова функции fork
Обратите внимание, что оба дескриптора 
listenfd
 и 
connfd
 совместно используются родительским и дочерним процессами.
Далее родительский процесс закрывает присоединенный сокет, а дочерний процесс закрывает прослушиваемый сокет. Это показано на рис. 4.8.
Рис. 4.8. Состояние соединения клиент-сервер после закрытия родительским и дочерним процессами соответствующих сокетов
Это и есть требуемое конечное состояние сокетов. Дочерний процесс управляет соединением с клиентом, а родительский процесс может снова вызвать функцию 
accept
 на прослушиваемом сокете, чтобы обрабатывать следующее клиентское соединение.
  
4.9. Функция close
 
Обычная функция Unix 
close
 также используется для закрытия сокета и завершения соединения TCP.
#include <unistd.h>
int close(int <i>sockfd</i>);
По умолчанию функция 
close
 помечает сокет TCP как закрытый и немедленно возвращает управление процессу. Дескриптор сокета больше не используется процессом и не может быть передан в качестве аргумента функции 
read
 или 
write
. Но TCP попытается отправить данные, которые уже установлены в очередь, и после их отправки осуществит нормальную последовательность завершения соединения TCP (см. раздел 2.5).
В разделе 7.5 рассказывается о параметре сокета 
SO_LINGER
, который позволяет нам изменять последовательность закрытия сокета TCP. В этом разделе мы также назовем действия, благодаря которым приложение TCP может получить гарантию того, что приложение-собеседник получило данные, поставленные в очередь на отправку, но еще не отправленные.
  
Счетчик ссылок дескриптора
 
В конце раздела 4.8 мы отметили, что когда родительский процесс на нашем параллельном сервере закрывает присоединенный сокет с помощью функции 
close
, счетчик ссылок дескриптора уменьшается лишь на единицу. Поскольку счетчик ссылок при этом все еще оставался больше нуля, вызов функции 
close
 не инициировал последовательность завершения TCP-соединения, состоящую из четырех пакетов. Нам нужно, чтобы наш параллельный сервер с присоединенным сокетом, разделяемым между родительским и дочерним процессами, работал именно по этому принципу.
  
Если мы хотим отправить сегмент FIN по соединению TCP, вместо функции 
close
 должна использоваться функция 
shutdown
 (см. раздел 6.6). Причины мы рассмотрим в разделе 6.5.
Необходимо также знать, что происходит с нашим параллельным сервером, если родительский процесс не вызывает функцию 
close
 для каждого присоединенного сокета, возвращаемого функцией 
accept
. Прежде всего, родительский процесс в какой-то момент израсходует все дескрипторы, поскольку обычно число дескрипторов, которые могут быть открыты процессом, ограничено. Но что более важно, ни одно из клиентских соединений не будет завершено. Когда дочерний процесс закрывает присоединенный сокет, его счетчик ссылок уменьшается с 2 до 1 и остается равным 1, поскольку родительский процесс не закрывает присоединенный сокет с помощью функции 
close
. Это помешает выполнить последовательность завершения соединения TCP, и соединение останется открытым.
  
4.10. Функции getsockname и getpeername
 
Эти две функции возвращают либо локальный (функция 
getsockname
), либо удаленный (функция 
getpeername
) адрес протокола, связанный с сокетом.
#include &lt;sys/socket.h&gt;
int getsockname(int <i>sockfd</i>, struct sockaddr *<i>localaddr</i>,
 socklen_t *<i>addrlen</i>);
int getpeername(int <i>sockfd</i>, struct sockaddr *<i>peeraddr</i>,
 socklen_t *<i>addrlen</i>);
Обратите внимание, что последний аргумент обеих функций относится к типу «значение-результат», то есть обе функции будут заполнять структуру адреса сокета, на которую указывает аргумент 
localaddr
 или 
peeraddr
.
 
ПРИМЕЧАНИЕ
 
Обсуждая функцию bind, мы отметили, что термин «имя» используется некорректно. Эти две функции возвращают адрес протокола, связанный с одним из концов сетевого соединения, что для протоколов IPv4 и IPv6 является сочетанием IP-адреса и номера порта. Эти функции также не имеют ничего общего с доменными именами (глава 11).
 
Функции 
getsockname
 и 
getpeername
 необходимы нам по следующим соображениям:
■ После успешного выполнения функции 
connect
 и возвращения управления в клиентский процесс TCP, который не вызывает функцию 
bind
, функция 
getsockname
 возвращает IP-адрес и номер локального порта, присвоенные соединению ядром.
■ После вызова функции 
bind
 с номером порта 0 (что является указанием ядру на необходимость выбрать номер локального порта) функция 
getsockname
 возвращает номер локального порта, который был задан.
■ Функцию 
getsockname
 можно вызвать, чтобы получить семейство адресов сокета, как это показано в листинге 4.4.
■ Сервер TCP, который с помощью функции 
bind
 связывается с универсальным IP-адресом (см. листинг 1.5), как только устанавливается соединение с клиентом (функция 
accept
 успешно выполнена), может вызвать функцию 
getsockname
, чтобы получить локальный IP-адрес соединения. Аргумент 
sockfd
 (дескриптор сокета) в этом вызове должен содержать дескриптор присоединенного, а не прослушиваемого сокета.