Книга: UNIX: взаимодействие процессов

Глава 16

Глава 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 байта.

При использовании UDP единственное отличие будет заключаться в отсутствии поля флага и длины (4 байта). При этом размер запроса будет 44 байта, а ответа — 28 байтов, что можно проверить с помощью tcpdump.

9. Да. Отличие в обработке аргументов у клиента и сервера не зависит от пакетов, передаваемых по сети. Функция main клиента вызывает функцию заглушки для отправки пакета, а функция main сервера вызывает функцию заглушки сервера для обработки этого пакета. Передаваемая по сети запись RPC определяется протоколом RPC, и ее содержимое остается неизменным вне зависимости от того, поддерживается ли многопоточность.

10. Библиотека XDR выделяет место под эти строки (динамически). Мы можем проверить это, добавив следующую строку к пpoгрaммe read:

printf(sbrk()= %p, buff = %p, in.vstring_arg = %pn", sbrk(NULL), buff, in.vstring_arg);

Функция sbrk возвращает текущий адрес вершины сегмента данных программы, а функция malloc обычно выделяет память непосредственно под этим адресом. Запустив программу, получим:

sbrk() = 29638, buff = 25е48, in.vstring_arg = 27e58

Это показывает, что указатель vstring_arg указывает на область, выделенную mallос. Буфер buff размером 8192 байта занимает адреса с 0х25е48 по 0х27е47, а строка помещается непосредственно под ним.

11. В листинге Г.11 приведен текст программы-клиента. Обратите внимание, что последним аргументом clnt_call является сама структура timeval, а не указатель на нее. Также отметьте, что третий и пятый аргументы clnt_call должныбыть ненулевыми указателями на подпрограммы XDR, поэтому мы указываем в этих аргументах xdr_void (функция, которая ничего не делает). Вы можете проверить, что именно так нужно вызывать функцию без аргументов и возвращаемых значений, написав тривиальный файл спецификации RPC, определяющий такую функцию, запустив rpcgen и посмотрев на содержимое созданной заглушки клиента.

//sunrpc/square10/client.c
1  #include "unpipc.h" /* our header */
2  #include "square.h" /* generated by rpcgen */
3  int
4  main(int argc, char **argv)
5  {
6   CLIENT *cl;
7   struct timeval tv;
8   if (argc != 3)
9    err_quit("usage: client <hostname> <protocol>");
10  cl = Clnt_create(argv[1], SQUARE_PROG, SQUARE_VERS, argv[2]);
11  tv.tv_sec = 10;
12  tv.tv_usec = 0;
13  if (clnt_call(cl, NULLPROC, xdr_void, NULL,
14   xdr_void, NULL, tv) != RPC_SUCCESS)
15  err_quit("%s", clnt_sperror(cl, argv[1]));
16  exit(0);
17 }

12. Получающийся размер дейтаграммы UDP (65536+20+дополнительные расходы RPC) превосходит 65535 — максимальный размер дейтаграммы в IPv4. В табл. А.2 отсутствуют значения для Sun RPC с использованием UDP для сообщений размером 16384 и 32768, поскольку старая реализация RPCSRC 4.0 ограничивала размер дейтаграммы UDP некоторым значением около 9000 байт.

Оглавление книги