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

 2 void
 3 str_cli(FILE *fp, int sockfd)
 4 {
 5  pid_t pid;
 6  char sendline[MAXLINE], recvline[MAXLINE];
 7  if ((pid = Fork()) == 0) { /* дочерний процесс: сервер -> stdout */
 8   while (Readline(sockfd, recvline, MAXLINE) > 0)
 9    Fputs(recvline, stdout);
10   kill(getppid(), SIGTERM); /* в случае, если родительский процесс
                                 все еще выполняется */
11   exit(0);
12  }
13  /* родитель: stdin -> сервер */
14  while (Fgets(sendline, MAXLINE, fp) != NULL)
15   Writen(sockfd, sendline, strlen(sendline));
16  Shutdown(sockfd, SHUT_WR); /* конец файла на stdin, посылаем FIN */
17  pause();
18  return;
19 }
Нам нужно снова вспомнить о последовательности завершения соединения. Обычное завершение происходит, когда в стандартном потоке ввода встречается конец файла. Родительский процесс считывает конец файла и вызывает функцию 
shutdown
 для отправки сегмента FIN. (Родительский процесс не может вызвать функцию 
close
, см. упражнение 16.1.) Но когда это происходит, дочерний процесс должен продолжать копировать от сервера в стандартный поток вывода, пока он не получит признак конца файла на сокете.
Также возможно, что процесс сервера завершится преждевременно (см. раздел 5.12), и если это происходит, дочерний процесс считывает признак конца файла на сокете. В таком случае дочерний процесс должен сообщить родительскому, что нужно прекратить копирование из стандартного потока ввода в сокет (см. упражнение 16.2). В листинге 16.6 дочерний процесс отправляет родительскому процессу сигнал 
SIGTERM
, в случае, если родительский процесс еще выполняется (см. упражнение 16.3). Другим способом обработки этой ситуации было бы завершение дочернего процесса, и если родительский процесс все еще выполнялся бы к этому моменту, он получил бы сигнал 
SIGCHLD
.
Родительский процесс вызывает функцию 
pause
, когда заканчивает копирование, что переводит его в состояние ожидания того момента, когда будет получен сигнал. Даже если родительский процесс не перехватывает никаких сигналов, он все равно переходит в состояние ожидания до получения сигнала 
SIGTERM
 от дочернего процесса. По умолчанию действие этого сигнала — завершение процесса, что вполне устраивает нас в этом примере. Родительский процесс ждет завершения дочернего процесса, чтобы измерить точное время для этой версии функции 
str_cli
. Обычно дочерний процесс завершается после родительского, но поскольку мы измеряем время, используя команду оболочки 
time
, измерение заканчивается, когда завершается родительский процесс.
Отметим простоту этой версии по сравнению с неблокируемым вводом-выводом, представленным ранее в этом разделе. Наша неблокируемая версия управляла четырьмя различными потоками ввода-вывода одновременно, и поскольку все четыре были неблокируемыми, нам пришлось иметь дело с частичным чтением и частичной записью для всех четырех потоков. Но в версии с функцией 
fork
 каждый процесс обрабатывает только два потока ввода-вывода, копируя из одного в другой. В применении неблокируемого ввода-вывода не возникает необходимости, поскольку если нет данных для чтения из потока ввода, то и в соответствующий поток вывода записывать нечего.
    
Сравнение времени выполнения различных версий функции str_cli
 
Итак, мы продемонстрировали четыре различных версии функции 
str_cli
. Для каждой версии мы покажем время, которое потребовалось для ее выполнения, в том числе и для версии, использующей программные потоки (см. листинг 26.1). В каждом случае было скопировано 2000 строк от клиента Solaris к серверу с периодом RTT, равным 175 мс:
■ 354,0 с, режим остановки и ожидания (см. листинг 5.4);
■ 12,3 с, функция 
select
 и блокируемый ввод-вывод (см. листинг 6.2);
■ 6,9 с, неблокируемый ввод-вывод (см. листинг 16.1);
■ 8,7 с, функция 
fork
 (см. листинг 16.6);
■ 8,5 с, версия с потоками (см. листинг 26.1).
Наша версия с неблокируемым вводом-выводом почти вдвое быстрее версии, использующей блокируемый ввод-вывод с функцией 
select
. Наша простая версия с применением функции 
fork
 медленнее версии с неблокируемым вводом- выводом. Тем не менее, учитывая сложность кода неблокируемого ввода-вывода по сравнению с кодом функции 
fork
, мы рекомендуем более простой подход.
  
16.3. Неблокируемая функция connect
 
Когда сокет TCP устанавливается как неблокируемый, а затем вызывается функция 
connect
, она немедленно возвращает ошибку 
EINPROGRESS
, однако трехэтапное рукопожатие TCP продолжается. Далее мы с помощью функции 
select
 проверяем, успешно или нет завершилось установление соединения. Неблокируемая функция connect находит применение в трех случаях:
1. Трехэтапное рукопожатие может наложиться на какой-либо другой процесс. Для выполнения функции 
connect
 требуется один период обращения RTT (см. раздел 2.5), и это может занять от нескольких миллисекунд в локальной сети до сотен миллисекунд или нескольких секунд в глобальной сети. Это время мы можем провести с пользой, выполняя какой-либо другой процесс.
2. Мы можем установить множество соединений одновременно, используя эту технологию. Этот способ уже стал популярен в применении к веб-браузерам, и такой пример мы приводим в разделе 16.5.
3. Поскольку мы ждем завершения установления соединения с помощью функции 
select
, мы можем задать предел времени для функции 
select
, что позволит нам сократить тайм-аут для функции 
connect
. Во многих реализациях тайм-аут функции connect лежит в пределах от 75 с до нескольких минут. Бывают случаи, когда приложению нужен более короткий тайм-аут, и одним из решений может стать использование неблокируемой функции 
connect
. В разделе 14.2 рассматриваются другие способы помещения тайм-аута в операции с сокетами.
Как бы просто ни выглядела неблокируемая функция 
connect
, есть ряд моментов, которые следует учитывать.
■ Даже если сокет является неблокируемым, то когда сервер, с которым мы соединяемся, находится на том же узле, обычно установление соединения происходит немедленно при вызове функции 
connect
.