Уильям Стивенс - UNIX: разработка сетевых приложений

2 ssize_t

3 readline(int fd, void *vptr, size_t maxlen)

4 {

5 ssize_t n, rc;

6 char c, *ptr;

7 ptr = vptr;

8 for (n = 1; n < maxlen; n++) {

9 again:

10 if ((rc = read(fd, &c, 1)) == 1) {

11 *ptr++ = c;

12 if (c == '\n')

13 break; /* записан символ новой строки, как в fgets() */

14 } else if (rc == 0) {

15 if (n == 1)

16 return (0); /* EOF, данные не считаны */

17 else

18 break; /* EOF, некоторые данные были считаны */

19 } else {

20 if (errno == EINTR)

21 goto again;

22 return (-1); /* ошибка, errno задается функцией read() */

23 }

24 }

25 *ptr = 0; /* завершаем нулем, как в fgets() */

26 return (n);

27 }

Если функция чтения или записи ( readили write) возвращает ошибку, то наши функции проверяют, не совпадает ли код ошибки с EINTR (прерывание системного вызова сигналом, см. раздел 5.9). В этом случае прерванная функция вызывается повторно. Мы обрабатываем ошибку в этой функции, чтобы не заставлять процесс снова вызвать readили write, поскольку целью наших функций является предотвращение обработки нехватки данных вызывающим процессом.

В разделе 14.3 мы покажем, что вызов функции recvс флагом MSG_WAITALLпозволяет обойтись без использования отдельной функции readn.

Заметим, что наша функция readlineвызывает системную функцию readодин раз для каждого байта данных. Это очень неэффективно, поэтому мы и написали в примечании «Ужасно медленно!». Возникает соблазн обратиться к стандартной библиотеке ввода-вывода ( stdio). Об этом мы поговорим через некоторое время в разделе 14.8, но учтите, что это может привести к определенным проблемам. Буферизация, предоставляемая stdio, решает проблемы с производительностью, но при этом создает множество логистических сложностей, которые в свою очередь порождают скрытые ошибки в приложении. Дело в том, что состояние буферов stdioнедоступно процессу. Рассмотрим, например, строчный протокол взаимодействия клиента и сервера, причем такой, что могут существовать разные независимые реализации клиентов и серверов (достаточно типичное явление; например, множество веб-браузеров и веб-серверов были разработаны независимо в соответствии со спецификацией HTTP). Хороший стиль программирования заключается в том, что эти программы должны не только ожидать от своих собеседников соблюдения того же протокола, но и контролировать трафик на возможность получения непредвиденного трафика. Подобные нарушения протокола должны рассматриваться как ошибки, чтобы программисты имели возможность находить и устранять неполадки в коде, а также обнаруживать попытки взлома систем. Обработка некорректного трафика должна давать приложению возможность продолжать работу. Буферизация stdioмешает достижению перечисленных целей, поскольку приложение не может проверить наличие непредвиденных (некорректных) данных в буферах stdioв любой конкретный момент.

Существует множество сетевых протоколов, основанных на использовании строк текста: SMTP, HTTP, FTP, finger. Поэтому соблазн работать со строками будет терзать вас достаточно часто. Наш совет: мыслить в терминах буферов, а не строк. Пишите код таким образом, чтобы считывать содержимое буфера, а не отдельные строки. Если же ожидается получение строки, ее всегда можно поискать в считанном буфере.

В листинге 3.12 приведена более быстрая версия функции readline, использующая свой собственный буфер (а не буферизацию stdio). Основное достоинство этого буфера состоит в его открытости, благодаря чему вызывающий процесс всегда знает, какие именно данные уже приняты. Несмотря на это, использование readlineвсе равно может вызвать проблемы, как мы увидим в разделе 6.3. Системные функции типа selectничего не знают о внутреннем буфере readline, поэтому неаккуратно написанная программа с легкостью может очутиться в состоянии ожидания в вызове select, при том, что данные уже будут находиться в буферах readline. По этой причине сочетание вызовов readnи readlineне будет работать так, как этого хотелось бы, пока функция readnне будет модифицирована с учетом наличия внутреннего буфера.

Листинг 3.12. Улучшенная версия функции readline

//lib/readline.c

1 #include "unp.h"

2 static int read_cnt;

3 static char *read_ptr;

4 static char read_buf[MAXLINE];

5 static ssize_t

6 my_read(int fd, char *ptr)

7 {

8 if (read_cnt <= 0) {

9 again:

10 if ((read_cnt = read(fd, read_buf, sizeof(read_buf))) < 0) {

11 if (errno == EINTR)

12 goto again;

13 return(-1);

14 } else if (read_cnt == 0)

15 return(0);

16 read_ptr = read_buf;

17 }

18 read_cnt--;

19 *ptr = *read_ptr++;

20 return(1);

21 }

22 ssize_t

23 readline(int fd, void *vptr, size_t maxlen)

24 {

25 ssize_t n, rc;

26 char c, *ptr;

27 ptr = vptr;

28 for (n = 1; n < maxlen; n++) {

29 if ((rc = my_read(fd, &c)) == 1) {

30 *ptr++ = c;

31 if (c== '\n')

32 break; /* Записан символ новой строки, как в fgets() */

33 } else if (rc == 0) {

34 *ptr = 0;

35 return(n - 1); /* EOF, считано n-1 байт данных */

36 } else

37 return(-1); /* ошибка, read() задает значение errno */

38 }

39 *ptr = 0; /* завершающий нуль, как в fgets() */

40 return(n);

41 }

42 ssize_t

43 readlinebuf(void **vptrptr)

44 {

45 if (read_cnt)

46 *vptrptr = read_ptr;

47 return(read_cnt);

48 }

2-21 Внутренняя функция my_readсчитывает до MAXLINEсимволов за один вызов и затем возвращает их по одному.

29 Единственное изменение самой функции readlineзаключается в том, что теперь она вызывает функцию my_readвместо read.

42-48 Новая функция readlinebufвыдает сведения о состоянии внутреннего буфера, что позволяет вызывающим функциям проверить, нет ли в нем других данных, помимо уже принятой строки.

К сожалению, использование переменных типа static в коде readline.c для поддержки информации о состоянии при последовательных вызовах приводит к тому, что функция больше не является безопасной в многопоточной системе (thread-safe) и повторно входимой (reentrant). Мы обсуждаем это в разделах 11.18 и 26.5. Мы предлагаем версию, безопасную в многопоточной системе, основанную на собственных данных программных потоков, в листинге 26.5.

Структуры адресов сокетов являются неотъемлемой частью каждой сетевой программы. Мы выделяем для них место в памяти, заполняем их и передаем указатели на них различным функциям сокетов. Иногда мы передаем указатель на одну из этих структур функции сокета, и она сама заполняет поля структуры. Мы всегда передаем эти структуры по ссылке (то есть передаем указатель на структуру, а не саму структуру) и всегда передаем размер структуры в качестве дополнительного аргумента. Когда функция сокета заполняет структуру, длина также передается по ссылке, и ее значение может быть изменено функцией, поэтому мы называем такой аргумент «значение-результат» (value-result).