Текст книги "Основы программирования в Linux"

Автор книги: Нейл Мэтью

Соавторы: Ричард Стоунс
сообщить о нарушении

Текущая страница: 51 (всего у книги 67 страниц)

Интерфейс сервера server.c

Если у клиента есть интерфейс для обращения к программе app_ui.c, серверу также нужна программа для управления (переименованной) программой cd_access.c, теперь cd_dbm.c. Далее приведена функция main сервера.

1. Начните с объявления нескольких глобальных переменных, прототипа функции process_command и функции перехвата сигнала для обеспечения чистого завершения.

#include

#include

#include

#include

#include

#include

#include

#include

#include

#include

#include «cd_data.h»

#include «cliserv.h»

int save errno;

static int server_running = 1;

static void process_command(const message_db_t mess_command);

void catch_signals() {

 server_running = 0;

}

2. Теперь переходите к функции main. После проверки успешного завершения подпрограмм захвата сигнала программа проверяет, передали ли вы -i в командной строке. Если да, она создаст новую базу данных. Если вызов подпрограммы database_initialize в файле cd_dbm.c завершится аварийно, будет выведено сообщение об ошибке. Если все хорошо и сервер работает, любые запросы от клиента направляются функции process_command, которую вы вскоре увидите.

int main(int argc, char *argv[]) {

 struct sigaction new_action, old_action;

 message_db_t mess command;

 int database_init_type = 0;

 new_action.sa_handler = catch_signals;

 sigemptyset(&new_action.sa_mask);

 new_action.sa_flags = 0;

 if ((sigaction(SIGINT, &new_action, &old_action) != 0) ||

  (sigaction(SIGHUP, &new_action, &old_action) != 0) ||

  (sigaction(SIGTERM, &new_action, &old_action) != 0)) {

  fprintf(stderr, «Server startup error, signal catching failedn»);

  exit(EXIT_FAILURE);

 }

 if (argc > 1) {

  argv++;

  if (strncmp(«-i», *argv, 2) == 0) database_init_type = 1;

 }

 if (!database_initialize(database_init_type)) {

  fprintf(stderr, "Server error :-

   could not initialize databasen");

  exit (EXIT_FAILURE);

 }

 if (!server starting()) exit(EXIT_FAILURE);

 while(server_running) {

  if (read_request_from_client(&mess_command)) {

   process_command(mess_command);

  } else {

   if (server_running) fprintf(stderr,

    «Server ended – can not read pipen»);

   server_running = 0;

  }

 } /* while */

 server_ending();

 exit(EXIT_SUCCESS);

}

3. Любые сообщения клиентов направляются в функцию process_command, где они обрабатываются в операторе case, который выполняет соответствующие вызовы из файла cd_dbm.c.

static void process_command(const message_db_t comm) {

 message_db_t resp;

 int first_time = 1;

 resp = comm; /* копирует команду обратно,

                 затем изменяет resp, как требовалось */

 if (!start_resp_to_client(resp)) {

  fprintf(stderr, "Server Warning:

   start_resp_to_client %d failedn", resp.client_pid);

  return;

 }

 resp.response = r_success;

 memset(resp.error_text, '', sizeof(resp.error_text));

 save_errno = 0;

 switch(resp.request) {

 case s_create_new_database:

  if (!database initialize(1))

   resp.response = r_failure;

  break;

 case s_get_cdc_entry:

  resp.cdc_entry_data =

   get_cdc_entry(comm.cdc_entry_data.catalog);

  break;

 case s_get_cdt_entry:

  resp.cdt_entry_data =

   get_cdt_entry(comm.cdt_entry_data.catalog,

   comm.cdt_entry_data.track_no);

  break;

 case s_add_cdc_entry:

  if (!add_cdc_entry(comm.cdc_entry_data))

   resp.response = r_failure;

  break;

 case s_add_cdt_entry:

  if (!add_cdt_entry(comm.cdt_entry_data))

   resp.response = r_failure;

  break;

 case s_del_cdc_entry:

  if (!del_cdc_entry(comm.cdc_entry_data.catalog))

   resp.response = r_failure;

  break;

 case s_del_cdt_entry:

  if (!del_cdt_entry(comm.cdt_entry_data.catalog,

   comm.cdt_entry_data.track_no)) resp.response = r_failure;

  break;

 case s_find_cdc_entry:

  do {

   resp.cdc_entry_data =

    search_cdc_entry(comm.cdc_entry_data.catalog, &first_time);

   if (resp.cdc_entry_data.catalog[0] != 0) {

    resp.response = r_success;

    if (!send_resp_to_client(resp)) {

     fprintf(stderr,

      «Server Warning:– failed to respond to %dn», resp.client_pid);

     break;

    }

   } else {

    resp.response = r_find_no_more;

   }

  } while (resp.response == r_success);

  break;

 default:

  resp.response = r_failure;

  break;

 } /* switch */

 sprintf(resp.error_text,

  «Command failed:nt%sn», strerror(save_errno));

 if (!send_resp_to_client(resp)) {

  fprintf(stderr,

   «Server Warning:– failed to respond to %dn», resp.client_pid);

 }

 end_resp_to_client();

 return;

}

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

В этой реализации ситуация немного сложнее, т.к. в запросе на поиск клиент передает серверу одну команду и затем ждет один или несколько ответов от сервера. Это усложняет программу, особенно клиентскую часть.

Рис. 13.9

Канал

Далее показан файл реализации канала pipe_imp.с, в котором содержатся клиентские и серверные функции.

Примечание

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

Заголовочный файл для реализации канала

1. Прежде всего, директивы #include:

#include «cd_data.h»

#include «cliserv.h»

2. Вы также определяете в файле программы несколько значений, нужных вам в разных функциях:

static int server_fd = -1;

static pid_t mypid = 0;

static char client_pipe_name[PATH_MAX + 1] = {''};

static int client_fd = -1;

static int client_write_fd = -1;

Функции серверной стороны

Далее нужно рассмотреть функции серверной стороны. В следующем разделе показаны функции, открывающие и закрывающие именованный канал и читающие сообщения от клиентов. В следующем за ним разделе приведен программный код, который открывает и закрывает клиентские каналы и пересылает по ним сообщения, основываясь на идентификаторе процесса, который клиент включает в свое сообщение.

Функции сервера

1. Подпрограмма server_starting создает именованный канал, из которого сервер будет считывать команды. Далее она открывает канал для чтения. Этот вызов open будет блокировать выполнение, пока клиент не откроет канал для записи. Используйте режим блокировки для того, чтобы сервер мог выполнить блокировку вызовов read в канале в ожидании отправляемых ему команд.

int server_starting(void) {

#if DEBUG_TRACE

 printf(«%d server_starting()n», getpid());

#endif

 unlink(SERVER_PIPE);

 if (mkfifo(SERVER_PIPE, 0777) == -1) {

  fprintf(stderr, «Server startup error, no FIFO createdn»);

  return(0);

 }

 if ((server_fd = open(SERVER_PIPE, O_RDONLY)) == -1) {

  if (errno == EINTR) return(0);

  fprintf(stderr, «Server startup error, no FIFO openedn»);

  return(0);

 }

 return(1);

}

2. Когда сервер завершает работу, он удаляет именованный канал, для того чтобы клиенты могли установить, что нет действующего сервера.

void server_ending(void) {

#if DEBUG_TRACE

 printf(«%d:– server_ending()n», getpid());

#endif

 (void)close(server_fd);

 (void)unlink(SERVER_PIPE);

}

3. Функция read_request_from_client будет блокировать чтение в серверном канале до тех пор, пока клиент не запишет в него сообщение.

int read_request_from_client(message_db_t *rec_ptr) {

 int return_code = 0;

 int read_bytes;

#if DEBUG_TRACE

 printf(«%d :– read_request_from_client()n», getpid());

#endif

 if (server_fd != -1) {

  read_bytes = read(server_fd, rec_ptr, sizeof(*rec_ptr));

  ...

 }

 return(return_code);

}

4. В особом случае, когда ни у одного клиента нет канала, открытого для записи, вызов read вернет 0, т.е. он обнаружит EOF (метку конца файла). Затем сервер закроет канал и откроет его снова так, что канал блокируется до тех пор, пока клиент также не откроет канал. Выполняется то же, что и при первом запуске сервера; вы инициализировали сервер повторно. Вставьте этот программный код в предыдущую функцию.

if (read_bytes == 0) {

 (void)close(server_fd);

 if ((server_fd = open(SERVER_PIPE, O_RDONLY)) == -1) {

  if (errno != EINTR) {

   fprintf(stderr, «Server error, FIFO open failedn»);

  }

  return(0);

 }

 read_bytes = read(server_fd, rec_ptr, sizeof(*rec_ptr));

}

if (read_bytes == sizeof(*rec_ptr)) return_code = 1;

Сервер – это единственный процесс, способный одновременно обслуживать множество клиентов. Поскольку каждый клиент применяет свой канал для получения ответов, адресованных ему, сервер, для того чтобы отправить ответы разным клиентам, должен писать в разные каналы. Поскольку файловые дескрипторы – это ограниченный ресурс, сервер открывает клиентский канал для записи только тогда, когда у него есть данные для отправки.

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

Прокладка каналов

1. Сначала откройте канал клиента.

int start_resp_to_client(const message_db_t mess_to_send) {

#if DEBUG_TRACE

 printf(«%d :– start_resp_to_client()n», getpid());

#endif

 (void)sprintf(client_pipe_name, CLIENT_PIPE,

  mess_to_send.client_pid);

 if ((client_fd = open(client_pipe_name, O_WRONLY)) == -1) return(0);

 return(1);

}

2. Все сообщения отправляются с помощью данной функции. Соответствующие клиентские функции, которые принимают сообщение, вы увидите позже.

int send_resp_to_client(const message_db_t mess_to_send) {

 int write_bytes;

#if DEBUG_TRACE

 printf(«%d :– send_resp_to_client()n», getpid());

#endif

 if (client_fd == -1) return(0);

 write_bytes = write(client_fd, &mess_to_send, sizeof(mess_to_send));

 if (write_bytes != sizeof(mess_to_send)) return(0);

 return(1);

}

3. В заключение закройте клиентский канал.

void end resp_to_client(void) {

#if DEBUG_TFACE

 printf(«%d :– end_resp_to_client()n», getpid());

#endif

 if (client_fd != -1) {

  (void)close(сlient_fd);

  client_fd = -1;

 }

}

Функции на стороне клиента

Дополнение к серверу – клиентские функции в файле pipe_imp.c. Они очень похожи на серверные функции за исключением функции с интригующим именем send_mess_to_server.

Клиентские функции

1. После проверки доступности сервера функция client_starting инициализирует канал клиентской стороны.

int client_starting(void) {

#if DEBUG_TFACE

 printf(«%d client_startingn», getpid());

#endif

 mypid = getpid();

 if ((server_fd = open(SERVER_PIPE, O_WRONLY)) == -1) {

  fprintf(stderr, «Server not runningn»);

  return(0);

 }

 (void)sprintf(client pipe name, CLIENT_PIPE, mypid);

 (void)unlink(client_pipe_name);

 if (mkfifo(client_pipe_name, 0777) == -1) {

  fprintf(stderr, «Unable to create client pipe %sn», client_pipe_name);

  return(0);

 }

 return(1);

}

2. Функция client_ending закрывает файловые дескрипторы и удаляет ненужный теперь именованный канал.

void client_ending(void) {

#if DEBUG_TRACE

 printf(«%d client_ending()n», getpid());

#endif

 if (client_write_fd != -1) (void)close(client_write_fd);

 if (client_fd != -1) (void)close(client_fd);

 if (server_fd != -1) (void)close(server_fd);

 (void)unlink(client_pipe_name);

}

3. Функция send_mess_to_server передает запрос через канал сервера.

int send_mess_to_server(message_db_t mess_to_send) {

 int write_bytes;

#if DEBUG_TRACE

 printf(«%d send_mess_to_server()n», getpid());

#endif

 if (server_fd == -1) return(0);

 mess_to_send.client_pid = mypid;

 write_bytes = write(server_fd, &mess_to_send, sizeof(mess_to_send));

 if (write_bytes != sizeof(mess_to_send)) return(0);

 return(1);

}

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

Получение результатов с сервера

1. Данная клиентская функция запускается для ожидания ответа сервера. Она открывает канал клиента только для чтения и затем повторно открывает файл канала только для записи. Чуть позже в этом разделе вы поймете почему.

int start_resp_from_server(void) {

#if DEBUG_TRACE

 printf(«%d :– start_resp_from_server()n», getpid());

#endif

 if (client_pipe_name[0] == '') return(0);

 if (client_fd != -1) return(1);

 client_fd = open(client_pipe_name, O_RDONLY);

 if (client_fd != -1) {

  client_write_fd = open(client_pipe_name, O_WRONLY);

  if (client_write_fd != -1) return(1);

  (void)close(client_fd);

  client_fd = -1;

 }

 return(0);

}

2. Далее приведена основная операция read, которая получает с сервера совпадающие элементы базы данных.

int read_resp_from_server(message_db_t *rec_ptr) {

 int read_bytes;

 int return_code = 0;

#if DEBUG_TRACE

 printf(«%d :– reader_resp_from_server()n», getpid());

 #endif

 if (!rec_ptr) return(0);

 if (client_fd = -1) return(0);

 read_bytes = read(client_fd, rec_ptr, sizeof(*rec_ptr));

 if (read_bytes = sizeof(*rec_ptr)) return_code = 1;

 return(return_code);

}

3. И в заключение приведена клиентская функция, помечающая конец ответа сервера.

void end_resp_from_server(void) {

#if DEBUG_TRACE

 printf(«%d :– end_resp_from_server()n», getpid());

#endif

 /* В реализации канала эта функция пустая */

}

Второй дополнительный вызов open канала клиента для записи в start_resp_from_server

client_write_fd = open(client_pipe_name, O_WRONLY);

применяется для защиты от ситуации гонок, когда серверу необходимо быстро откликаться на несколько запросов клиента,

Для того чтобы стало понятнее, рассмотрим такую последовательность событий:

1. Клиент пишет запрос к серверу.

2. Сервер читает запрос, открывает канал клиента и отправляет обратно ответ, но приостанавливает выполнение до того, как успеет закрыть канал клиента.

3. Клиент открывает канал для чтения, читает первый ответ и закрывает свой канал.

4. Далее клиент посылает новую команду и открывает клиентский канал для чтения.

5. Сервер возобновляет работу, закрывая свой конец клиентского канала.

К сожалению, в этот момент клиент пытается считать из канала ответ на свой следующий запрос, но read вернет 0 байтов, поскольку ни один процесс не открыл клиентский канал для записи.

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

Резюме, касающееся приложения

Вы разделили приложение, управляющее базой данных компакт-дисков, на клиентскую и серверную части, что позволило разрабатывать независимо пользовательский интерфейс и внутреннюю технологию работы с базой данных. Как видите, четко определенный интерфейс базы данных дает возможность каждому важному элементу приложения наилучшим образом использовать машинные ресурсы. Если пойти чуть дальше, можно было бы заменить реализацию с помощью каналов на сетевой вариант и применить выделенный компьютер для сервера базы данных. В главе 15 вы узнаете больше об организации сети.

Резюме

В этой главе вы рассмотрели передачу данных между процессами с помощью каналов. Сначала вы познакомились с неименованными каналами, которые создаются вызовом popen или pipe, и посмотрели, как, применяя канал и вызов dup, можно передать данные из одной программы в стандартный ввод другой. Далее вы перешли к именованным каналам и узнали, как можно передавать данные между несвязанными программами. В заключение вы реализовали простой пример клиент– серверного приложения, используя каналы FIFO для обеспечения не только синхронизации процессов, но и организации двунаправленного потока данных.

Глава 14
Семафоры, совместно используемая память и очереди сообщений

В этой главе мы обсудим набор средств, обеспечивающих взаимодействие процессов и первоначально введенных в версии ОС UNIX AT&T System V.2. Поскольку все эти средства появились в одном выпуске системы и обладают одинаковым программным интерфейсом, их часто называют средствами IPC (Inter-Process Communication, взаимодействие между процессами) или более полно System V IPC. Как вы уже видели, это далеко не единственный способ установления связи между процессами, но термин «System V IPC» обычно применяется для обозначения именно этих конкретных средств.

В данной главе мы рассмотрим следующие темы:

□ семафоры для управления доступом к ресурсам;

□ совместно используемая память для эффективного использования общих данных разными программами;

□ обмен сообщениями как легкий способ передачи данных между программами.

Семафоры

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

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

В первом приложении-примере в главе 7, использующем средство dbm для доступа к базе данных, данные могли бы быть повреждены множественными программами, пытавшимися обновить базу данных в одно и то же время. Никакого сбоя не произойдет, если две разные программы запрашивают у двух разных пользователей ввод данных для базы данных, единственная потенциальная проблема кроется в частях программного кода, обновляющих базу данных. Эти секции программы, действительно выполняющие обновления и нуждающиеся в монопольном режиме выполнения, называются критическими секциями. Часто они занимают всего несколько строк кода в гораздо больших по объему программах.

Для устранения проблем, вызванных одновременным обращением нескольких программ к совместно используемому ресурсу, вам нужен способ генерации и применения маркера, гарантирующего в любой момент, времени доступ в критическую секцию только одному потоку исполнения. В главе 12 вы вкратце познакомились с ориентированным на потоки использованием мьютексов или семафоров для управления доступом в критические секции многопоточной программы. В этой главе мы вернемся к теме семафоров, но акцентируем внимание на их применении для взаимодействия разных процессов.

Примечание

Функции семафоров, применяемые в потоках и обсуждавшиеся в главе 12, не относятся к наиболее общим функциям, которые мы рассматриваем в этой главе, поэтому будьте внимательны и не путайте функции этих двух типов.

Написать программный код общего назначения, который гарантирует одной программе монопольный доступ к конкретному ресурсу, на удивление сложно, несмотря на то, что существует решение, известное как алгоритм Деккера (Dekker's Algorithm). К сожалению, этот алгоритм полагается на состояние активного ожидания или спин-блокировки, в котором процесс выполняется непрерывно, ожидая изменения адреса памяти. В многозадачной среде, какой является ОС Linux, это нежелательные расходы ресурсов ЦПУ. Ситуация существенно облегчается, когда для обеспечения монопольного доступа есть аппаратная поддержка, обычно в виде специальных команд ЦПУ. Примером аппаратной поддержки могла бы быть команда обращения к ресурсу и приращения регистра атомарным образом, так чтобы никакая другая команда (даже прерывание) не могла появиться между операциями чтения/инкремента/записи.

Одним из возможных решений проблемы можно считать уже знакомое вам создание файла с помощью флага O_EXCL в функции open, обеспечивающей атомарное создание файла. Этот метод хорош для простых задач, но становится довольно путанным и очень неэффективным при решении более сложных примеров.

Важный шаг вперед в сфере параллельного программирования был сделан, когда голландский специалист в области компьютерных наук Эдсгер Дейкстра (Edsger Dijkstra) предложил идею семафоров. Как уже кратко упоминалось в главе 12, семафор – это специальная переменная, которая принимает только целые положительные значения и с помощью которой программы могут действовать только атомарно. В этой главе мы расширим данное ранее упрощенное определение. Будет более подробно рассказано, как действуют семафоры и как для взаимодействия отдельных процессов применяются функции общего назначения вместо особого случая многопоточных программ, которые рассматривались в главе 12.

Определяя более строго, семафор – это специальная переменная, для которой разрешены только две операции, формально именуемые ожиданием или приостановкой (wait) и оповещением (signal). Поскольку в программировании Linux у приостановки и оповещения уже есть специальные значения, мы будем применять оригинальное обозначение:

□ P(переменная-семафор) для приостановки (wait);

□ V(переменная-семафор) для оповещения (signal).

Эти буквы взяты из голландских слов для приостановки (passeren – проходить, пропускать как в случае контрольной точки перед критической секцией) и для оповещения (vrijgeven – предоставлять или освобождать, как в случае отказа от контроля критической секции). Вы можете встретить термины «вверх» (up) и «вниз» (down), применяемые в отношении семафоров по аналогии с использованием сигнальных флажков.