Linux API. Исчерпывающее руководство полностью

• MSG_NOSIGNAL — делает так, что передача данных через подключенный сокет не генерирует сигнал SIGPIPE, если другой конец соединения закрыт. При этом вызов send() завершается ошибкой EPIPE. Такого же поведения можно добиться, проигнорировав сигнал SIGPIPE; разница лишь в том, что флаг MSG_NOSIGNAL влияет на отдельные вызовы.

• MSG_OOB — отправляет сокету внеканальные данные (см. подраздел 57.13.1).

Из всех флагов, перечисленных выше, только MSG_OOB входит в стандарт SUSv3. Флаг MSG_DONTWAIT встречается в ряде других систем, а MSG_NOSIGNAL и MSG_MORE поддерживаются только в Linux.

Дополнительные флаги, которые здесь не упоминаются, описаны на страницах send(2) и recv(2) руководства.

Таким приложениям, как файловые и веб-серверы, часто приходится передавать через (подключенный) сокет точную копию содержимого файла, хранящегося на диске. Один из способов, с помощью которого это можно сделать, выглядит следующим образом:

while ((n = read(diskfilefd, buf, BUZ_SIZE)) > 0)

write(sockfd, buf, n);

Во многих случаях такой цикл является вполне приемлемым. Но если часто передавать через сокет большие файлы, то данный подход перестает быть эффективным. Для передачи файла следует задействовать два системных вызова (возможно, по нескольку раз, поместив их в цикл): один — для копирования содержимого файла из буферного кэша ядра в пользовательское пространство, а другой — для обратного копирования, чтобы данные можно было передать через сокет. Этот сценарий показан на рис. 57.1, а. Такой двухэтапный процесс получается слишком расточительным, если приложение никак не обрабатывает данные перед отправкой. Для оптимизации процесса предусмотрен системный вызов sendfile(). При его использовании содержимое файла направляется непосредственно в сокет, минуя пространство пользователя (см. рис. 57.1, б). Эта методика называется передачей с нулевым копированием.

Рис. 57.1. Передача содержимого файла через сокет

#include

ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

Возвращает количество переданных байтов или -1 при ошибке

Системный вызов sendfile() передает данные из файла, на который ссылается дескриптор in_fd, дескриптору out_fd, ссылающемуся на сокет. Аргумент in_fd должен указывать на файл, к которому можно применить вызов mmap(); в реальных приложениях для этого чаще всего берется обычный файл. Такая манипуляция в определенной мере ограничивает применение вызова sendfile(). Можно использовать его для передачи данных из файла в сокет, но не наоборот, и нельзя с помощью этого вызова передать данные непосредственно из одного сокета в другой.

Если аргумент offset не равен NULL, то должен указывать на значение типа off_t, определяющее начальный сдвиг в файле in_fd, с которого необходимо начинать передачу данных. Этот аргумент применяется для возвращения результата. После завершения вызова он содержит сдвиг, начинающийся вслед за последним байтом, переданным из in_fd. В таком случае вызов sendfile() не изменяет файловый сдвиг.

Если аргумент offset равен NULL, то данные файла in_fd начинают передаваться с его текущего сдвига, а сам сдвиг обновляется с каждым переданным байтом.

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

Вызов sendfile() не предусмотрен стандартом SUSv3. Его разновидности доступны в некоторых UNIX-системах, но их аргументы обычно отличаются от версии, реализованной в Linux.

Параметр сокета TCP_CORK

Для дальнейшего повышения эффективности TCP-приложений, использующих вызов sendfile(), иногда имеет смысл применить параметр сокета TCP_CORK (доступный только в Linux). В качестве примера рассмотрим веб-сервер, который возвращает страницу в ответ на запрос веб-браузера. Ответ сервера состоит из двух частей: HTTP-заголовков (возможно, полученных с помощью вызова write()) и тела страницы (скажем, сформированного с применением вызова sendfile()). Обычно в таком случае передается два TCP-сегмента: сначала отсылаются заголовки (небольшого объема), а затем следуют данные самой страницы. Это приводит к неэффективному расходу ресурсов сети. К тому же может потребоваться дополнительная работа обеих сторон TCP-соединения, так как во многих случаях HTTP-заголовки и данные страницы можно вместить в единственный TCP-сегмент. Параметр TCP_CORK призван оптимизировать описанную процедуру.