Салимóненко Дмитрий Александрович

При этом взаимодействие будет иметь примерно такой вид:

Итак, необходимо создать программы клиент и сервер, которые:

• Сервер, получив в качестве аргумента запроса (от клиента) целое число, равное 2, открывает файл с именем text.txt, читает его в строку и возвращает ее клиенту;
• Клиент вначале открывает файл, имя которого задается вторым параметром в командной строке (при запуске клиента). Это - text.txt. Читает этот файл и выводит на экран его содержимое. Затем он делает запрос к серверу. Если второй (последний) параметр в командной строке равен text.txt, то клиент передает серверу целое число, равное 2, иначе должно передаваться число 0.

Разработка программных кодов клиента и сервера

Перед тем, как приводить программные коды, целесообразно обсудить оптимизацию программ. В частности, речь идет о вышеупомянутых параметрах, представляющих собой имя узла сети, номер программы, номер версии программы, номер процедуры в этой программе. Отметим сразу, что эти параметры должны быть указана в ОБОИХ программах, как в клиенте, так и в сервере. Это, своего рода, идентифицирующая клиента и сервера информация, подобно тому, как номер порта и IP-адрес узла идентифицируют программы сервер и клиент в технологии сокетов.

Следовательно, целесообразно выделить эти четыре параметра в отдельный файл и затем подключить его при помощи директивы include. Это могло бы выглядеть следующим образом. Создаем подключаемый файл common.h со следующим содержимым:

#define MY_PROG  (u_long) 0x20000001
#define MY_VER   (u_long) 1
#define MY_PROC1 (u_long) 1

Этот файл следует подключить как к клиенту, так и к серверу следующим образом:

#include "common.h"

Состав задания (файлы проекта)

Наш с Вами проект будет состоять из следующих файлов:

• text.txt (текстовый файл, который будет считываться сервером и клиентом)
• common.h (файл с константами – номер и версия программы)
• server_RPC.c (исходный код сервера на языке С)
• client_RPC.c  (исходный код клиента на языке С)
• read_file.c (исходный код модуля, читающего файл и возвращающего его содержимое в виде строки)
• client_RPC (исполняемый файл клиента)
• server_RPC (исполняемый файл сервера)
• Makefile (makefile для сборки клиента и сервера)

Файл text.txt

Этот файл имеет следующее содержимое:

Вы можете задать любые другие символы – поэкспериментируйте. Можно попробовать вставить туда даже китайские, японские, арабские буквы (их можно найти на соответствующих сайтах в интернете). Потом они будут выведены на экран – как клиентом, так и сервером. Кодировка UTF-8 позволяет выводить на экран практически все символы.

Обратите внимание, что кодировка файла является UTF-8 без BOM (byte order marker). Мы потом поэкспериментируем с кодировками.

Подключаемый файл common.h

В этом файле содержатся параметры программы (которые потом службой RPC неявным образом преобразуются в номер порта, по которому и происходит взаимодействие клиента и сервера на основе сокетов). Например, параметры могут быть такие:

#define MY_PROG  (u_long) 0x20000001
#define MY_VER   (u_long) 1
#define MY_PROC1 (u_long) 1

Так как здесь заданы типы этих параметров (констант), то в кодах клиента и сервера нет необходимости их указывать.

Еще раз: они должны быть полностью идентичными как для клиента, так и для сервера. Это достигается подключением файла common.h к обоим этим программам.

Программный код сервера

Теперь рассмотрим программный код сервера:

1. #include <rpc/rpc.h>
2. #include <stdio.h>
3. #include "common.h"
4. // Объявляем функцию, т.к. вызов ее идет до ее описания
5. char ** proc1 (char* indata_p);
6. int main ()
7. {
8. printf ("Begin Server - Only ONE output.\n"); // А почему эта команда срабатывает только 1 раз при запуске сервера?
9. int i;
10. i = registerrpc (MY_PROG, MY_VER, MY_PROC1, (char*)proc1, (xdrproc_t)xdr_int, (xdrproc_t) xdr_wrapstring);
11. svc_run();
12. fprintf (stderr, "Error: svc_run returned \n");
13. exit (1);
14. }
15. // Функция proc1()
16. char ** proc1 (char *indata_p)
17. {
18. static char *res;
19. // Выводим на экран аргумент функции proc1(),
20. printf ("arg recieved is: %d\n", *indata_p);
21. static char* file_name;
22. file_name = "";
23. if(*indata_p == 2) {
24. file_name = "text.txt";
25. }else{
26. fprintf (stderr, "Error: Wrong arg\n");
27. exit (2);
28. }
29. char *open_read_file(char *file_name);
30. // Имя открываемого файла - text.txt
31. printf ("file_name: %s\n",  file_name);
32. static char* string;
33. string = (char*) open_read_file( (char*) file_name);
34. printf ("  From server_RPC:\n%s\n", string);
35. printf ("Number of bytes: %lu\n\n", strlen(string));
36. res = string;
37. return &res;
38. }

Описание программного кода сервера

Строки 1...2 описывают подключаемые файлы, содержащие определения для всех необходимых структур данных.

Строка 3 подключает файл common.h, в котором содержатся константы, задающие номер, версию программы (общие как для сервера, так и для клиента).

Строка 5 объявляет тип функции proc1. Необходимость объявления вызвана тем, что в программе эта функция используется (см. стр. 10) раньше, чем определяется (стр. 16).

В строке 10 эта функция регистрируется, при помощи registerrpc(), в качестве процедуры-сервера, которая имеет аргумент целого типа, а возвращаемый ею результат является строкой символов.

Кстати, применяя registerrpc() несколько раз, возможна регистрация требуемого количества процедур-серверов с соответствующими номерами программ и версий.

В строке 11 программа посредством обращения к функции svc_run() переводится в состояние ожидания запросов клиента. Как уже отмечалось, если эта функция выполнилась успешно, дальнейший программный код выполнен НЕ будет. Т.е. строки 12 и 13 выполнятся только в том случае, если возникнет ошибка.

Строки 12...28 содержат тело описания функции proc1(). Как видим, эта функция работает с указателями на ее аргумент и результат.

В строке 29 производится вызов функции open_read_file(), которая имеет аргументом имя файла, например, text.txt. Эту функция открывает файл, читает его выводит содержимое в консоль и, окончательно, возвращает его в виде строки.

Таким образом, при работе сервера (точнее, при каждом ответе сервера клиенту) должен наблюдаться вывод на экран (в консоль, в которой запущен сервер) примерно в следующем виде:

arg recieved is: 2
file_name: text.txt
 From open_read_file:
x����1234567ПЛ
Number of bytes: 17
 From server_RPC:
x����1234567ПЛ
Number of bytes: 17

Символы «1234567ПЛ» - это содержимое файла text.txt, который должен содержаться в том же каталоге, что и другие файлы, используемые в данном задании. Как видим, файл содержит 7 цифр и две русские буквы П и Л. Символы «x����» представляют собой символы, добавленные программой-сервером (об этом - ниже).

Т.е. содержимое текстового файла выводится дважды: из модуля open_read_file() (строки 31-32, см. ниже)  и из самой программы server_RPC (строки 33-35). Как видим, оба результата вывода - тождественны, но содержат в начале некие символы. Которые, кстати, меняются при запуске клиента.

Модуль open_read_file()

Как уже говорилось, это – модуль, читающий текстовый файл и возвращающий его содержимое в виде строки байтов (отображаемых на экране, как символы):

1. // Функция, читающая файл (#5)
2. #include <rpc/rpc.h>
3. #include <stdio.h>
4. char *open_read_file (char *file_name) {
5. #define BS 2
6. size_t bytes_read;
7. char buf[BS+1], *str;
8. ssize_t count;
9. int i = 0;
10. FILE *fd = fopen(file_name, "r");
11. // Выделяем 1 байт памяти, для начала
12. if((str = (char*)malloc(10)) == NULL){
13. perror("Allocation error.");
14. exit (0);
15. }
16. // Читаем файл до тех пор, пока не дойдем до его конца
17. while(!feof(fd))  {
18. i++;
19. // Очищаем массив (подумайте, кстати, для чего?...)
20. memset(buf, 0, sizeof(buf));
21. //Считываем не более, чем BS байтов из файла за 1 итерацию цикла
22. if(fgets(buf, BS, fd))
23. // Добавляем еще BS байтов памяти перед тем, как записать считанные байты в массив str
24. if((str = (char*)realloc(str, i*BS+1)) == NULL){
25. perror("Allocation error.");
26. exit (0);
27. }
28. strncat(str, buf, BS);
29. }
30. if (str == "")  {printf("Not to read from file");}
31. printf ("  From open_read_file: \n%s\n",  str);
32. printf ("Number of bytes: %lu\n\n",  strlen(str));
33. fclose(fd);return str;
34. }

Данная функция практически совпадает с этой функцией.

Запуск сервера

Прежде, чем запускать сервер, лучше бы убедиться, что на Вашем хосте (узле) запущена служба RPC. Это можно сделать при помощи команды rpcinfo

Если служба запущена, то она выведет примерно следующее:

Как видим, слева направо идут: номер программы, версия, транспортный протокол, IP-адрес и сервис, работающий по этому адресу и имя владельца.

Введя команду

rpcinfo -p localhost,

получим более сокращенный перечень. Причем, при этом будут показаны порты, к которым подключились удаленные процедуры.

Можно, для проверки, проверить, подключена ли служба RPC на каком-нибудь хосте в интернете.

Например:
rpcinfo -p 4846d.ru

Получим примерно следующее:

Видим, что на сайте 4846d.ru запущен ряд служб. К ним можно обратиться при помощи RPC, используя номер программы и номер версии (третьим параметром, хостом при этом будет, естественно, доменное имя).

Вот теперь, убедившись, что служба RPC запущена, можно попробовать запустить сервер (см. предыдущий листинг). Он может не запуститься, может возникнуть ошибка такого рода:

Cannot register service: RPC: Unable to receive; errno = Success
couldn't register prog 536870913 vers 1

Это означает, что, несмотря на то, что служба RPC запущена, все-таки не запущена служба rpcbind. Запустить ее в Ubuntu можно командой:

/etc/init.d/rpcbind start

Итак, запустили сервер (на одной консоли). Далее, открываем еще одну консоль и в ней нужно будет запустить клиент.

Программный код клиента

1. #include <rpc/rpc.h>
2. #include <stdio.h>
3. #include "common.h"
4. int main (int argc, char** argv)
5. {
6. char *answer;
7. int stat;
8. if (argc < 3) exit (1);
9. int arg;
10. // Если нужно объявлять другие переменные, помимо int, например, массивы типа char (не знаю, как насчет других типов), следует объявлять их статическими. Иначе возникает ошибка сегментации (переполнение). Видимо, это - особенность использования службы RPC. Как это часто бывает, никакой информации об этом нет (ну, а зачем, мол). Ну, я, по крайней мере, не нашел.
11. static char* file_name;
12. file_name = argv[2];
13. char *open_read_file(char *file_name);
14. // Имя открываемого файла - второй параметр при запуске этой программы
15. printf ("file_name: %s\n", file_name);
16. static char* string;
17. string = (char*) open_read_file( (char*) file_name);
18. printf (" From client_RPC:\n%s\n", string);
19. printf ("Number of bytes: %lu\n\n", strlen(string));
20. arg = 0;
21. if(strcmp (file_name, "text.txt") == 0) {arg = 2;}
22. if (stat = callrpc (argv[1], MY_PROG, MY_VER, MY_PROC1, (xdrproc_t)xdr_int, (char*)&arg, (xdrproc_t) xdr_wrapstring, (char *)&answer) != 0) {
23. clnt_perrno (stat);
24. exit (2);
25. };
26. printf (" From server_RPC (answer):\n%s\n", answer);
27. printf ("Number of bytes: %lu\n\n", strlen(answer));
28. exit (0);
29. }

Как видим, в  клиенте (равно как и в сервере – см. выше) используется функция open_read_file(). Он объявляется в строке 13, а вызов ее происходит в строке 17. Как и в сервере, подключаться она будет при помощи Makefile.

В строке 8 проверяется количество аргументов командной строки, с помощью которой программа-клиент вызывается на выполнение (аргументов не должно быть меньше двух). Здесь следует подумать – какие аргументы должны быть при вызове клиента. Дело в том, что если Вы просто запустите данную программу, не указав параметров, в виде

./client_RPC ,

то ничего не произойдет. Необходимо ввести верные аргументы. Какие именно, а также порядок их ввода следует выяснить, проанализировав приведенные выше программные коды.

В строке 22 вызывается удаленная процедура-сервер, выполняющаяся на узле сети, на котором запущен сервер. При запуске на локальном компьютере как клиента, так и сервера необходимо, следовательно, ввести имя  соответствующего узла. Об этом уже говорилось выше. Процедуре передается указатель на ее аргумент (целое число), сама же она возвращает также указатель на свой результат (при этом память под возвращаемую строку символов нужного размера автоматически выделяется XDR-функцией xdr_wrapstring()).

Строка 23 содержит обращение к функции clnt_perrno, которая выводит в stderr текст сообщения, характеризующего ошибку, которая по разным причинам может возникнуть при выполнении вызова удаленной процедуры.

Строки 26-27 выводят на экран (т.е. в стандартный поток вывода stdout) сообщение, содержащее ответ удаленной процедуры-сервера и его длину в байтах.

Вывод клиента в консоли (после очередного запуска) будет иметь примерно такой вид:

file_name: text.txt
 From open_read_file:
1234567ПЛ
Number of bytes: 11
 From client_RPC:
1234567ПЛ
Number of bytes: 11
 From server_RPC (answer):
(x����1234567ПЛ
Number of bytes: 17
Makefile

Выше уже говорилось, что как к клиенту, так и к серверу необходимо будет подключить модуль с функцией open_read_file(). Makefile для оптимизации сборки клиента и сервера может иметь следующий вид:

Анализ работы клиента и сервера

Итак, запустив сервер (на одной консоли), запускаем клиент (на другой консоли. После чего на экранах консолей возникнут результаты работы этих программ, соответственно.

Видим любопытную вещь. Клиент, вызывая функцию open_read_file(), читает файл text.txt как положено, выводы символы 1234567ПЛ на экран. Количество байтов «почему-то» равно 11, что превышает число символов, которое равно 7+2 = 9.

Дело в том, что в Linux используется кодировка UTF-8, а в ней кириллические (русские) буквы кодируются ДВУМЯ байтами каждая. Соответственно, буквы «ПЛ» кодируются четырьмя байтами. Тогда как для кодирования цифр используется по одному байту. Поэтому получается 7+2*2 = 11 байтов.

Так вот, клиент, как и полагается, читает и выводит на экран ровно те самые символы (9 символов, закодированных 11 байтами в кодировке UTF-8), которые и содержатся в текстовом файле. А вот сервер, как видим, добавляет к ним в начале строки еще 6 байтов. Т.е., будучи подключенной и к клиенту, и к серверу, одна и та же функция open_read_file() ведет себя по-разному.

Причем, добавляемые дополнительно байты меняются после каждого запроса клиента. Чтобы в этом убедиться, можно в консоли вместо кодировки UTF-8 выбрать другую кодировку.

К сожалению, мне НЕ УДАЛОСЬ пока выяснить, что представляют собой эти байты. Информации об этом я не нашел. Возможно, они представляют собой некий хэш, на основе которого происходит распознавание клиентов. Правда, если это хэш – то весьма слабый – всего-то 6 байт.

Теперь попробуем изменить кодировку файла text.txt:

{UTF-8 без BOM} -> {UTF-8}
Для этого в Notepadqq делаем
Encoding -> Convert to UTF-8

Сохраняем файл. Запуская вновь клиент, видим, что количество байтов увеличилось на 3 – как в консоли клиента, так и в консоли сервера. Это означает, что добавился ВОМ (а он как раз и составляет 3 байта). Однако, как видно, в видимом содержимом файла – ни в текстовом редакторе, ни в выводе в консоль эти байты не показываются. Что вызвано, видимо, тем, что операционная система, при возврате содержимого файла, не выводит их, однако, учитывает в общем количестве байтов файла.

Заключение

В заключение следует сказать, что в данном задании приведены лишь основные механизмы RPC по взаимодействию клиента и сервера. На самом деле, такой механизм является опасным, так как обратиться к удаленному серверу может любая программа, получившая к нему доступ. В таком виде механизм реализации RPC-взаимодействия для проектов, требующих ограничения прав доступа, применяться не должен. Должны быть использованы, как минимум, аутенификация, авторизация клиентов и, возможно, шифрование передаваемых сообщений. До недавнего времени в операционной системе Windows неоднократно находили уязвимости, обусловленные этой службой. Отчасти они устранены, конечно. Одно время даже была рекомендация: отключить службу RPC на компьютере, если нет в ней особой необходимости. Так что ее использование, на мой взгляд, если и целесообразно, так лишь для неопасных операций. На сокетах - оно как-то надежнее будет. Хотя, и не очень кроссплатформенно.

Задание для самостоятельной разработки:

1. Необходимо изучить коды клиента и сервера, запустить их и опробовать на практике;
2. Напишите и зарегистрируйте на сервере (при помощи функции registerrpc()  ) еще одну функцию, например, proc2. Эта функция должна считать сумму чисел, полученных от клиента и возвращать эту сумму клиенту;
3. Для вызова функции proc2 (например, для подсчета суммы чисел, введенных в качестве параметра, в виде одного многозначного числа, при запуске клиента) реализуйте вторую, аналогичную программу-клиент. Кроме того, следует внести соответствующие изменения в файл common.h, добавив в него еще три параметра для программы proc2. Конечно, эти три параметра нужны только для сервера (т.е. всего их для него будет шесть) и для второго клиента. Первому клиенту, если он не будет обращаться ко второй процедуре, необходимости в этих параметрах нет. Однако, чтобы обойтись единым файлом common.h, лучше указать в нем параметры для обоих процедур.

Иными словами, Ваш сервер должен быть рассчитан на обслуживание двух клиентов, в зависимости от запросов к нему.