UNIX: взаимодействие процессов
вернуться

Стивенс Уильям Ричард
Шрифт:
Листинг 16.10. Клиент для изучения свойств соединения по TCP

//sunrpc/square9/client.c

1 #include "unpipc.h" /* наш заголовочный файл*/

2 #include "square.h" /* создается rpcgen */

3 int

4 main(int argc, char **argv)

5 {

6 CLIENT, *cl;

7 square_in in;

8 square_out *outp;

9 if (argc != 3)

10 err_quit("usage: client <hostname> <integer-value>");

11 cl = Clnt_create(argv[1], SQUARE_PROG, SQUARE_VERS, "tcp");

12 in.arg1 = atol(argv[2]);

13 if ((outp = squareproc_1(&in, cl)) == NULL)

14 err_quit("%s", clnt_sperror(c1, argv[1]));

15 printf("result: %ld\n", outp->res1);

16 in.arg1 *= 2;

17 if ((outp = squareproc_1(&in, cl)) == NULL)

18 err_quit("%s", clnt_sperror(cl, argv[1]));

19 printf("result: %ld\n", outp->res1);

20 clnt_destroy(cl);

21 pause;

22 exit(0);

23 }

После запуска получим ожидаемый результат:

solaris % client kalae 5

result: 25

result: 100

программа в состоянии ожидания, пока мы не завершим ее вручную

Однако проверить наши предыдущие утверждения можно лишь с помощью результатов работы программы tcpdump. Она показывает, что создается одно соединение по TCP (вызовом clnt_create) и оно используется для обоих запросов клиента. Соединение завершается вызовом clnt_destroy, хотя клиент при этом и не завершает свою работу.

Идентификатор транзакций

Другая часть стратегии тайм-аутов и повторных передач заключается в использовании идентификаторов транзакций (transaction ID или XID) для распознавания запросов клиента и ответов сервера. Когда клиент вызывает функцию RPC, библиотека присваивает этому вызову 32-разрядный целочисленный номер и это значение отсылается в запросе RPC. Сервер должен добавить к своему ответу этот номер. При повторной отсылке запроса идентификатор не меняется. Служит он двум целям:

1. Клиент проверяет, что XID ответа совпадает с XID запроса. Если совпадения нет, ответ игнорируется. Если используется протокол TCP, у клиента практически нет шансов получить ответ с неправильным идентификатором, но при использовании протокола UDP поверх плохой сети вероятность получения неправильного XID достаточно высока.

2. Серверу разрешается помещать отсылаемые ответы в кэш, и для проверки идентичности ответов используется, в частности, именно XID. Об этом мы вскоре расскажем.

Пакет TI-RPC использует определенный алгоритм вычисления XID для нового запроса. Алгоритм этот описан ниже. Значок ^ означает побитовую операцию XOR (исключающее ИЛИ):

struct timeval now;

gettimeofday(&now, NULL);

xid = getpid ^ now.tv_sec ^ now.tv_usec;

Кэш повторных ответов

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

#include <rpc/rpc.h>

int svc_dg_enablecache(SVCXPRT *xprt, unsigned long size);

/* Возвращает 1 в случае успешного завершения. 0 – в случае ошибки */

Здесь xprt представляет собой транспортный дескриптор, являющийся полем структуры svc_req (раздел 16.4). Адрес этой структуры является аргументом процедуры сервера. Размер определяет количество записей в выделяемом кэше.

Итак, эта функция включает поддержку кэширования всех отсылаемых ответов в очереди размером size записей. Каждый ответ однозначно определяется следующими параметрами:

■ номером программы;

■ номером версии;

■ номером процедуры;

■ XID;

■ адресом клиента (IP-адрес + порт UDP).

При получении запроса клиента библиотека RPC ищет в кэше ответ на такой запрос. В случае его наличия ответ отсылается клиенту без повторного вызова процедуры сервера.