Нейл Мэтью - Основы программирования в Linux
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" обычно применяется для обозначения именно этих конкретных средств.
В данной главе мы рассмотрим следующие темы:
□ семафоры для управления доступом к ресурсам;
□ совместно используемая память для эффективного использования общих данных разными программами;
