20 }
8-16 Полное имя считывается из стандартного потока ввода и затем отправляется на сервер с помощью функции mesg_send.
17-19 Клиент вызывает функцию mesg_recv в цикле, считывая все приходящие от сервера сообщения. По соглашению, когда mesg_recv возвращает нулевую длину сообщения, это означает конец передаваемых сервером данных. Мы увидим, что сервер добавляет символ перевода строки к каждому сообщению, отправляемому клиенту, поэтому пустая строка будет иметь длину сообщения 1. В листинге 4.16 приведен текст функции-сервера.
//pipemesg/server.c
1 #include "mesg.h"
2 void
3 server(int readfd, int writefd)
4 {
5 FILE *fp;
6 ssize_t n;
7 struct mymesg mesg;
8 /* считывание полного имени из канала */
9 mesg.mesg_type = 1;
10 if ((n = Mesg_recv(readfd, &mesg)) == 0)
11 err_quit("pathname missing");
12 mesg.mesg_data[n] = '\0'; /* полное имя, завершающееся 0 */
13 if ((fp = fopen(mesg.mesg_data, "r")) == NULL) {
14 /* ошибка, нужно сообщить клиенту */
15 snprintf(mesg.mesg_data + n, sizeof(mesg.mesg_data) – n,
16 ": can't open, %s\n", strerror(errno));
17 mesg.mesg_len = strlen(mesg.mesg_data);
18 Mesg_send(writefd, &mesg);
19 } else {
20 /* файл успешно открыт, передача данных */
21 while (Fgets(mesg.mesg_data, MAXMESGDATA, fp) != NULL) {
22 mesg.mesg_len = strlen(mesg.mesg_data);
23 Mesg_send(writefd, &mesg);
24 }
25 Fclose(fp);
26 }
27 /* отправка сообщения нулевой длины для обозначения конца связи */
28 mesg.mesg_len = 0;
29 Mesg_send(writefd, &mesg);
30 }
8-18 Сервер принимает от клиента имя файла. Хотя значение mesg_type, равное 1, нигде не используется (оно затирается функцией mesg_recv из листинга 4.14), мы будем использовать ту же функцию при работе с очередями сообщений System V (листинг 6.8), а в данном случае в этом значении уже возникает потребность (см., например, листинг 6.11). Стандартная функция ввода-вывода fopen открывает файл, что отличается от листинга 4.3, где вызывалась функция open для получения дескриптора файла. Причина, по которой мы воспользовались fopen, заключается в том, что в этой пpoгрaммe мы пользуемся библиотечной функцией fgets для считывания содержимого файла построчно и затем отправляем клиенту строку за строкой.
19-26 Если вызов fopen оказывается успешным, содержимое файла считывается с помощью функции fgets и затем отправляется клиенту построчно. Сообщение с нулевой длиной означает конец файла.
При использовании пpoгрaммныx каналов или FIFO мы могли бы также закрыть канал IPC, чтобы дать клиенту знать о том, что передача файла завершена. Однако мы используем передачу сообщения нулевой длины, потому что другие типы IPC не поддерживают концепцию конца файла.
Функции main, вызывающие новые функции client и server, вообще не претерпели никаких изменений. Мы можем использовать либо версию для работы с каналами (листинг 4.1), либо версию для работы с FIFO (листинг 4.6).
4.11. Ограничения программных каналов и FIFO
На программные каналы и каналы FIFO системой накладываются всего два ограничения:
■ OPEN_MAX — максимальное количество дескрипторов, которые могут быть одновременно открыты некоторым процессом (Posix устанавливает для этой величины ограничение снизу — 16);
■ PIPE_BUF — максимальное количество данных, для которого гарантируется атомарность операции записи (описано в разделе 4.7; Posix требует по меньшей мере 512 байт).
Значение OPEN_MAX можно узнать, вызвав функцию sysconf, как мы вскоре покажем. Обычно его можно изменить из интерпретатора команд с помощью команды ulimit (в Bourne shell и KornShell, как мы вскоре покажем) или с помощью команды limit (в С shell). Оно может быть изменено и самим процессом с помощью вызова функции setrlimit (подробно описана в разделе 7.11 [21]).
Значение PIPE_BUF обычно определено в заголовочном файле <limits.h>, но с точки зрения стандарта Posix оно представляет собой переменную, зависимую от полного имени файла. Это означает, что ее значение может меняться в зависимости от указываемого имени файла (для FIFO, поскольку каналы имен не имеют), поскольку разные имена могут относиться к разным файловым системам и эти файловые системы могут иметь различные характеристики. Это значение можно получить в момент выполнения пpoгрaммы, вызвав либо pathconf, либо fpathconf. В листинге 4.17 приведен пример, выводящий текущее значение этих двух oгрaничeний.
//pipe/pipeconf.c
1 #include "unpipc.h"
2 int
3 main(int argc, char **argv)
4 {
5 if (argc != 2)
6 err_quit("usage: pipeconf <pathname>");
7 printf("PIPE_BUF = %ld. OPEN_MAX = %ld\n",
8 Pathconf(argv[1], _PC_PIPE_BUF), Sysconf(_SC_OPEN_MAX));
9 exit(0);
10 }
Вот несколько примеров, в которых указываются имена файлов, относящиеся к различным файловым системам:
solaris % pipeconf / значения по умолчанию в Solaris 2.6
PIPE_BUF = 5120, OPEN_MAX = 64
solaris % pipeconf /home
PIPE_BUF = 5120, OPEN_MAX = 64
solaris % pipeconf /tmp
PIPE_BUF = 5120, OPEN_MAX = 64
alpha % pipeconf / значения по умолчанию в Digital Unix 4.0B
PIPE_BUF = 4096, OPEN_MAX = 4096
alpha % pipeconf /usr
PIPE_BUF = 4096, OPEN_MAX = 4096
Покажем теперь, как изменить значение OPEN_MAX в Solaris, используя интерпретатор KornShelclass="underline"
solaris % ulimit –nS отображение максимального количества дескрипторов, мягкоео граничение
64
solaris % ulimit –Nh отображение максимального количества дескрипторов, жесткое ограничение
1024
solaris % ulimit –nS 512 установка мягкого ограничения в 512
solaris % pipeconf / проверка внесенных изменений
PIPE_BUF = 5120, OPEN_MAX = 512
ПРИМЕЧАНИЕ
Хотя значение PIPE_BUF для FIFO, в принципе, может меняться в зависимости от файловой системы, к которой относится файл, на самом деле это очень редкий случай.
В главе 2 [21] описаны функции fpathconf, pathconf и sysconf, которые предоставляют информацию о некоторых ограничениях ядра во время выполнения программы. Стандарт Posix.1 определяет 12 констант, начинающихся с _РС_, и 52, начинающихся с _SC_. Системы Digital Unix 4.0B и Solaris 2.6 расширяют последнее ограничение, определяя около 100 констант, значения которых могут быть получены в момент выполнения программы с помощью sysconf.