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

Важная характеристика срочного режима TCP заключается в следующем: заголовок TCP указывает на то, что отправитель вошел в срочный режим (то есть флаг URG установлен вместе со срочным смещением), но фактической отправки байта данных, на который указывает срочный указатель, не требуется. Действительно, если поток данных TCP остановлен функциями управления потоком (когда буфер приема сокета получателя заполнен и TCP получателя объявил нулевое окно для отправляющего TCP), то срочное уведомление отправляется без каких-либо данных [128, с. 1016–1017], как показано в листингах 24.8 и 24.9. Это одна из причин, по которой в приложениях используется срочный режим TCP (то есть внеполосные данные): срочное уведомление всегда отсылается собеседнику, даже если поток данных остановлен функциями управления потоком TCP.
Что произойдет, если мы отправим несколько байтов внеполосных данных, как в следующем примере?
send(fd, "abc", 3, MSG_OOB);
В этом примере срочный указатель TCP указывает на байт, следующий за последним байтом, и таким образом, последний байт (
с
) считается байтом внеполосных данных.
Посмотрим теперь, как выглядит процесс отправки внеполосных данных с точки зрения принимающей стороны.
1. Когда TCP получает сегмент, в котором установлен флаг URG, срочный указатель проверяется для выяснения того, указывает ли он на новые внеполосные данные. Иначе говоря, проверяется, впервые ли этот конкретный байт передается в срочном режиме TCP. Дело в том, что часто отправляющий TCP посылает несколько сегментов (обычно в течение короткого промежутка времени), содержащих флаг URG, в которых срочный указатель указывает на один и тот же байт данных. Только первый из этих сегментов фактически уведомляет принимающий процесс о прибытии новых внеполосных данных.
2. Принимающий процесс извещается о том, что прибыли новые внеполосные данные. Сначала владельцу сокета посылается сигнал 
SIGURG
. При этом предполагается, что для установления владельца сокета была вызвана функция 
fcntl
 или 
ioctl
 (см. табл. 7.9) и что для данного сигнала процессом был установлен обработчик сигнала. Затем, если процесс блокирован в вызове функции 
select
, которая ждет возникновения исключительной ситуации для дескриптора сокета, происходит возврат из этой функции.
Эти два уведомления действуют в том случае, когда прибывает новый срочный указатель, вне зависимости от того, принят ли байт, на который он указывает.
В потоке данных может быть только одна отметка OOB (один срочный указатель). Если новый срочный байт отправляется до того, как будет принят старый, последний просто сбрасывается и перестает быть срочным.
3. Когда байт данных, на который указывает срочный указатель, фактически прибывает на принимающий TCP, этот байт может быть помещен отдельно или оставлен вместе с другими данными. По умолчанию параметр сокета 
SO_OOBINLINE
 не установлен, поэтому внеполосный байт не размещается в приемном буфере сокета. Вместо этого содержащиеся в нем данные помещаются в отдельный внеполосный буфер размером в один байт, предназначенный специально для этого соединения [128, с. 986–988]. Для процесса единственным способом прочесть данные из этого специального однобайтового буфера является вызов функции 
recv
, 
recvfrom
 или 
recvmsg
 с заданием флага 
MSG_OOB
. Если новый срочный байт прибывает до того, как будет считан старый, новое значение записывается в буфер поверх прежнего.
Однако если процесс устанавливает параметр сокета 
SO_OOBINLINE
, то байт данных, на который указывает срочный указатель TCP, остается в обычном буфере приема сокета. В этом случае процесс не может задать флаг 
MSG_OOB
 для считывания данных, содержащихся во внеполосном байте. Процесс сможет распознать этот байт, только когда дойдет до него и проверит отметку внеполосных данных (out-of-band mark) для данного соединения, как показано в разделе 24.3. Возможны следующие ошибки:
  
1. Если процесс запрашивает внеполосные данные (то есть устанавливает флаг 
MSG_OOB
), но собеседник таких данных не послал, возвращается 
EINVAL
.
2. Если процесс был уведомлен о том, что собеседник послал содержащий внеполосные данные байт (например, с помощью функции 
select
 или сигнала 
SIGURG
), и пытается считать эти данные, когда указанный байт еще не прибыл, возвращается ошибка 
EWOULDBLOCK
. В такой ситуации все, что может сделать процесс, — это считать данные из приемного буфера сокета (возможно, сбрасывая данные, если отсутствует свободное место для их хранения), чтобы освободить место в буфере для приема байта внеполосных данных, посылаемых собеседником.
3. Если процесс пытается считать одни и те же внеполосные данные несколько раз, возвращается ошибка 
EINVAL
.
4. Если процесс установил параметр сокета 
SO_OOBINLINE
, а затем пытается считать внеполосные данные, задавая флаг 
MSG_OOB
, возвращается 
EINVAL
.
  
Простой пример использования сигнала SIGURG
 
Теперь мы рассмотрим тривиальный пример отправки и получения внеполосных данных. В листинге 24.1 [1] показана программа отправки этих данных.
Листинг 24.1. Простая программа отправки внеполосных данных
//oob/tcpsend01.c
 1 #include "unp.h"
 2 int
 3 main(int argc, char **argv)
 4 {
 5  int sockfd;
 6  if (argc != 3)
 7   err_quit("usage: tcpsend01 <host> <port#>");
 8  sockfd = Tcp_connect(argv[1], argv[2]);
 9  Write(sockfd, "123", 3);
10  printf("wrote 3 bytes of normal data\n");
11  sleep(1);
12  Send(sockfd, "4", 1, MSG_OOB);
13  printf("wrote 1 byte of OOB data\n");
14  sleep(1);
15  Write(sockfd, "56", 2);
16  printf("wrote 2 bytes of normal data\n");
17  sleep(1);
18  Send(sockfd, "7", 1, MSG_OOB);
19  printf("wrote 1 byte of OOB data\n");