UNIX: взаимодействие процессов - Уильям Стивенс

bsdi % client solaris 33 tcp

solaris: RPC: Timed out 

После завершения работы потока сервера соединение с клиентом по TCP не разрывается. Оно остается открытым, поэтому клиенту не отсылается пакет FIN. Клиент выходит по тайм-ауту. Мы увидели бы то же сообщение об ошибке, если бы узел, на котором находится сервер, прекратил работу после получения запроса от клиента и отправки уведомления.

Досрочное завершение клиента

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

Чтобы сымитировать такую ситуацию, клиент вызывает alarm(3) непосредственно перед вызовом процедуры сервера, а процедура сервера вызывает slеер (6). Так же мы поступили и в нашем примере с дверьми в листингах 15.25 и 15.26. Поскольку клиент не перехватывает сигнал SIGALRM, процесс завершается ядром примерно за 3 секунды до отправки ответа серверу. Запустим клиент в BSD/OS, а сервер в Solaris:

bsdi % client solaris 44 tcp

Alarm call

Случилось то, что мы и ожидали. А вот на сервере не происходит ничего необычного. Процедура сервера благополучно заканчивает 6-секундную паузу и возвращается. Если мы взглянем на передаваемую по сети информацию с помощью tcpdump, мы увидим следующее:

■ при завершении работы клиента (через 3 секунды после запуска) серверу отправляется пакет FIN, и сервер высылает уведомление о его приеме. В TCP для этого используется термин half-close (наполовину закрытое соединение, раздел 18.5 [22]);

■ через 6 секунд после запуска клиента сервер отсылает ответ, который переправляется клиенту протоколом TCP. По соединению TCP можно отправлять данные после получения FIN, поскольку соединения TCP являются двусторонними, о чем говорится в книге [24, с. 130-132]. Клиент отвечает пакетом RST, поскольку он уже завершил работу. Он будет получен сервером при следующем открытии этого соединения, но это ни к чему не приведет.

Подведем итоги.

■ При использовании UDP клиенты и серверы RPC не имеют возможности узнать о досрочном завершении одного из них. Они могут выходить по тайм-ауту, если ответ не приходит, но тип ошибки при этом определить не удастся: причина может быть в досрочном завершении процесса, сбое узла, недоступности сети и т. д.

■ Клиент RPC, использующий TCP, может узнать о возникших на сервере проблемах, поскольку при досрочном завершении сервера его конец соединения автоматически закрывается. Это, однако, не помогает, если сервер является многопоточным, поскольку такой сервер не закрывает соединение в случае отмены потока с процедурой сервера. Мы также не получаем информации в случае сбоя узла, поскольку при этом соединение TCP не закрывается. Во всех этих случаях следует использовать выход по тайм-ауту.

16.8. XDR: представление внешних данных

В предыдущей главе мы использовали двери для вызова процедуры одного процесса из другого процесса. При этом оба процесса выполнялись на одном узле, поэтому необходимости в преобразовании данных не возникало. Однако RPC используется для вызова процедур на разных узлах, которые могут иметь различный формат хранения данных. Прежде всего могут отличаться размеры фундаментальных типов (в некоторых системах long имеет длину 32 бита, а в других — 64). Кроме того, может отличаться порядок битов (big-endian и little-endian, о чем говорится в книге [24, с. 66-69 и 137-140]. Мы уже столкнулись с этой проблемой, когда обсуждали листинг 16.3. Сервер у нас работал на компьютере с little-endian х86, а клиент — на big-endian Sparc, но мы могли без проблем обмениваться данными (в нашем примере — одно длинное целое).

Sun RPC использует стандарт XDR (External Data Representation — представление внешних данных) для описания и кодирования данных (RFC 1832 [19]). XDR является одновременно языком описания данных и набором правил для их кодирования. В XDR используется скрытая типизация (implicit typing), то есть отправитель и получатель должны заранее знать тип и порядок данных. Например, два 32-разрядных целых, одно число с плавающей точкой и одинарной точностью и строка символов.

ПРИМЕЧАНИЕ

Приведем сравнение из мира OSI. Для описания данных обычно используется нотация ASN.1 (Abstract Syntax Notation one), а для кодирования — BER (Basic Encoding Rules). Эта схема также использует явную типизацию, то есть перед каждым значением указывается его тип. В нашем примере поток байтов содержал бы: спецификатор типа целого, целое, спецификатор типа целого, целое, спецификатор типа single, число с плавающей точкой и одинарной точностью, спецификатор типа строки символов, строку символов.

Представление всех типов согласно XDR требует количества байтов, кратного четырем. Эти байты всегда передаются в порядке big-endian. Целые числа со знаком передаются в дополнительном коде, а числа с плавающей точкой передаются в формате IEEE. Поля переменной длины могут содержать до 3 байтов дополнения в конце, так чтобы подогнать начало следующего элемента до адреса, кратного четырем. Например, 5-символьная строка АSСII будет передана как 12 байтов:

■ 4-байтовое целое, содержащее значение 5;

■ 5-байтовая строка;

■ 3 байта со значением 0 (дополнение).

При описании XDR и поддерживаемых типов данных следует уточнить три момента.

1. Как объявляются переменные различных типов в файле спецификации RPC (файл с расширением .х)? В наших примерах пока что использовалось только длинное целое.

2. В какой тип языка С преобразуется данный тип программой rpcgen при составлении заголовочного файла?

3. Каков реальный формат передаваемых данных?

Таблица 16.2 содержит ответы на первых два вопроса. Для составления этой таблицы мы создали файл спецификации RPC со всеми поддерживаемыми стандартом XDR типами. Этот файл был обработан rpcgen, после чего мы изучили получившийся заголовочный файл.

Таблица 16.2. Типы данных, поддерживаемые xdr и rpcgen 

№ Файл спецификации RPC (.x) Заголовочный файл языка С (.h) 1 const name = value #define name value 2 typedef declaration; typedef declaration; 3 char var; short var; int var; long var; hyper var; char var; short var; int var; long var; longlong_t var; 4 unsigned char var; unsigned short var; unsigned int var; unsigned long var; unsigned hyper var; u_char var; u_short var; u_int var; u_long var; u_longlong_t var; 5 float var; double var; quadruple var; float var; double var; quadruple var; 6 bool var; bool_t var; 7 enum var {name = const, …} enum var {name = const, …}; typedef enum var var; 8 opaque var[n]; char var[n]; 9 opaque var<m>; struct { u_int var_len; char *var_val; } val; 10 string var<m> char *var; 11 datatype var[n]; datatype var[n]; 12 datatype var<m> struct { uint var_len; datatype *var_val; } var; 13 struct var {members … }; struct var {members … }; typedef struct var var; 14 union var switch (int disc) { case discvalueA: armdeclA; case discvalueB: amrdeclB; … default: defaultdecl; }; struct var { int disc; union { armdeclA; armdeclB; …  defaultdecl; } var_u; }; typedef struct var var; 15 datatype *name; datatype *name;

Опишем содержимое таблицы более подробно.

1. Декларация const преобразуется в #define.

2.  Декларация typedef преобразуется в typedef.

3. Пять целых типов со знаком. Передаются XDR как 32-разрядные значения (первые четыре типа), а последний — как 64-разрядное.

ПРИМЕЧАНИЕ

64-разрядное целое поддерживается многими компиляторами С как формат long long int или просто long long. Многие, но не все компиляторы и операционные системы поддерживают такой формат. Поскольку в созданном заголовочном файле объявляются переменные типа longlong_t, в другом заголовочном файле должно содержаться следующее определение: