16 int fd:

17 if (argc != 2)

18 err quit( usage: server9 <server-pathname> );

19 fd = Door create(servproc. &fd. 0):

20 unlinkCargvEl]):

21 Close(Open(argv[l]. 0 CREAT 0 RDWR. FILE MODE)):

22 FattachCfd. argv[l]):

23 for ( : ; )

24 pauseC):

25 }

Мы легко могли бы изменить листинги 5.17 и 5.18, поскольку указатель cooki е доступен функции my thread (через структуру door i nfo t), которая передает указатель на эту структуру создаваемому потоку (которому нужно знать дескриптор для вызова door bi nd).

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

Глава 16

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

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

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

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

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

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

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

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

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

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

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

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

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

printf( sbrk()= %р. buff = %р, in,vstring arg = %р\п . sbrk(NULL), buff. in.vstring arg):

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

sbrkо = 29638. buff = 25е48, in.vstring arg = 27е58 Это показывает, что указатель vstring arg указывает на область, выделенную mal 1 ос. Буфер buff размером 8192 байта занимает адреса с Ох25е48 по Ох27е47, а строка помещается непосредственно под ним.

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

Листинг Г.11. Клиент, вызывающий нулевую процедуру сервера

sunrpc/squarelO/client.c

1 linclude unpipc.h /* our header */

2 linclude square.h /* generated by rpcgen */

3 int

4 mainCint argc, char **argv)

6 CLIENT *cl:

7 struct timeval tv:

8 if (argc != 3)

9 err quit( usage; client <hostname> <protocol> ):

10 cl = Clnt create(argv[l]. SQUARE PROG. SQUAREJERS. argv[2]);

11 tv.tv sec = 10:

12 tv.tv usec = 0;

13 if (clnt can(cl. NULLPROC. xdr void, NULL,

14 xdr void, NULL, tv) != RPCJUCCESS)

15 err quit( s . clnt sperror(cl, argv[l])):

16 exit(O):

17 }

12. Получающийся размер дейтаграммы UDP (65 536-1-20-1-дополнительные расходы RPC) превосходит 65 535 - максимальный размер дейтаграммы в IPv4. В табл. А.2 отсутствуют значения для Sun RPC с использованием UDP для сообщений размером 16 384 и 32 768, поскольку старая реализация RPCSRC 4.0 ограничивала размер дейтаграммы UDP некоторым значением около 9000 байт.