UNIX Network Programming. Volume 2 Second Edition. Interprocess Communications

9   printf("thread id %ld, arg = %ld\n", pr_thread_id(NULL), arg);

10  result = arg * arg;

11  Door_return((char *) result, sizeof(result), NULL, 0);

12 }

13 int

14 main(int argc, char **argv)

15 {

16  int fd;

17  if (argc != 2)

18   err_quit("usage: server9 server-pathname");

19  fd = Door_create(servproc, fd, 0);

20  unlink(argv[1]);

21  Close(Open(argv[1], O_CREAT | O_RDWR, FILE MODE));

22  Fattach(fd, argv[1]);

23  for(;;)

24   pause;

25 }

Мы легко могли бы изменить листинги 5.17 и 5.18, поскольку указатель cookie доступен функции my_thread (через структуру door_info_t), которая передает указатель на эту структуру создаваемому потоку (которому нужно знать дескриптор для вызова door_bind).

10. В этом примере атрибуты потока не меняются, поэтому их достаточно инициализировать лишь единожды (в функции main).

Глава 16

1. Программа отображения портов (port mapper) не проверяет серверы на работоспособность во время регистрации. После завершения сервера отображения остаются в силе, в чем мы можем убедиться с помощью пpoгрaммы rpcinfо. Поэтому клиент, связывающийся с программой отображения портов, получит информацию, которая была актуальной до завершения сервера. Когда клиент попытается связаться с сервером по TCP, библиотека RPC получит RST в ответ на пакет SYN (предполагается, что другие процессы не успели подключиться к порту завершенного сервера), что приведет к возврату ошибки функцией clnt_create. Вызов по протоколу UDP будет успешен (поскольку устанавливать соединение не нужно), но при отправке дейтаграмм через устаревший порт ответ получен не будет и функция клиента выйдет по тайм-ауту.

2. Библиотека RPC возвращает первый ответ сервера клиенту сразу по получении, то есть через 20 секунд после вызова клиента. Следующий ответ будет храниться в сетевом буфере для данной конечной точки до тех пор, пока эта точка не будет закрыта или не будет выполнена операция чтения из нее библиотекой RPC. Предположим, что клиент отправит второй вызов серверу сразу после получения первого ответа. Если потерь в сети не произойдет, следующей прибывшей дeйтaгрaммoй будет ответ сервера на повторно переданную клиентом дейтаграмму. Но библиотека RPC проигнорирует этот ответ, поскольку XID будет совпадать с первым вызовом процедуры, который не может быть равным XID для второго вызова.

3. Соответствующая структура в С — это char c[10], но она будет закодирована XDR как десять 4-байтовых целых. Если вы хотите использовать строку фиксированной длины, используйте скрытый тип данных фиксированной длины.

4. Вызов xdr_data возвращает FALSE, поскольку вызов xdr_string (прочитайте содержимое файла data_xdr.c) возвращает FALSE.

Максимальная длина строки указывается в качестве последнего аргумента xdr_string. Если максимальная длина не указана, этот аргумент принимает значение 0 в дополнительном коде (2³²–1 для 32-разрядного целого).

5. Пoдпpoгрaммы XDR проверяют наличие достаточного объема свободной памяти в буфере для кодирования данных и возвращают ошибку FALSE при переполнении буфера. К сожалению, отличить одну ошибку от другой для подпpoгрaмм XDR невозможно.

6. В принципе, можно сказать, что использование последовательных номеров в TCP для обнаружения повторов эквивалентно кэшу повторных запросов, поскольку эти последовательные номера позволяют обнаружить любой устаревший сегмент. Для конкретного соединения (IP-адреса и порта клиента) размер этого кэша соответствует половине 32-разрядного последовательного номера TCP, то есть 2³¹ или 2 Гбайт.

7. Поскольку все пять значений для конкретного запроса должны в точности равняться пяти значениям в кэше, первое сравнение должно выполняться для того поля, которое может отличаться с наибольшей вероятностью. Реальный порядок сравнений в пакете TI-RPC таков: (1) XID, (2) номер процедуры, (3) номер версии, (4) номер программы, (5) адрес клиента. Разумно сравнивать XID в первую очередь, поскольку именно это значение меняется от запроса к запросу.

8. На рис. 16.5 имеется двенадцать 4-байтовых полей, начиная с поля флага и длины и включая 4 байта на аргумент типа long. Получается 48 байт. При использовании нулевой аутентификации данные о пользователе и проверочные данные будут отсутствовать. При этом они займут по 8 байтов: 4 байта на тип аутентификации (AUTH_NONE) и 4 байта на длину аутентификационных данных (0).

В переданном ответе (взгляните на рис. 16.7, но помните, что используется протокол TCP, поэтому 4 байта флага и длины будут идти перед XID) будет восемь 4-байтовых полей, начиная с поля флага и длины и заканчивая результатом типа long. Вместе они дают 32 байта.