#include <sys/sem.h>
#include <sys/shm.h>
#include "shmem.h"
main() {
Message *msgptr;
key_t key;
int shmid, semid;
/* Получим ключ. Один и тот же ключ можно использовать как
для семафора, так и для разделяемой памяти */
if ((key = ftok("server", 'A')) < 0) {
printf("Невозможно получить ключn");
exit(1);
}
/* Получим доступ к разделяемой памяти */
if ((shmid = shmget(key, sizeof(Message), 0)) < 0) {
printf("Ошибка доступаn");
exit(1);
}
/* Присоединим ее */
if ((msgptr = (Message*)shmat(shmid, 0, 0)) < 0) {
prinf("Ошибка присоединенияn);
exit(1);
}
/* Получим доступ к семафору */
if ((semid = semget(key, 2, PERM)) < 0) {
printf("Ошибка доступаn");
exit(1);
}
/* Заблокируем разделяемую память */
if (semop(semid, &mem_lock[0], 2) < 0) {
printf("Невозможно выполнить операциюn");
exit(1);
}
/* Уведомим сервер о начале работы */
if (semop(semid, &proc_start[0], 1) < 0) {
printf("Невозможно выполнить операциюn");
exit(1);
}
/* Запишем в разделяемую память сообщение */
sprintf(msgptr->buff, "Здравствуй, Мир!n");
/* Освободим разделяемую память */
if (semop(semid, &mem_unlock[0], 1) < 0) {
printf("Невозможно выполнить операциюn");
exit(1);
}
/* Ждем, пока сервер в свою очередь не освободит
разделяемую память */
if (semop(semid, &mem_lock[0], 2) < 0) {
printf(Невозможно выполнить операциюn");
exit(1);
}
/* Отключимся от области */
if (shmdt(msgptr) < 0) {
printf("Ошибка отключенияn");
exit(1);
}
/* Удалим созданные объекты IPC */
if (shmctl(shmid, IPC_RMID, 0) < 0) {
printf("Невозможно удалить областьn");
exit(1);
}
if (semctl(semid, 0, IPC_RMID) < 0) {
printf("Невозможно удалить семафорn");
exit(1);
}
exit(0);
}
Межпроцессное взаимодействие в BSD UNIX. Сокеты
Разработчики системы межпроцессного взаимодействия BSD UNIX руководствовались рядом соображений:
Во-первых, взаимодействие между процессами должно быть унифицировано, независимо от того, выполняются ли они на одном компьютере или на разных хостах сети. Наиболее оптимальная реализация межпроцессного взаимодействия, удовлетворяющего этому требованию, должна иметь модульную структуру и базироваться на общей подсистеме поддержки сети UNIX. При этом могут быть использованы различные схемы адресации объектов, их расположение, протоколы передачи данных и т.д. В этой связи было введено понятие коммуникационный домен (communication domain), описывающее набор обозначенных характеристик взаимодействия.
Для обозначения коммуникационного узла, обеспечивающего прием и передачу данных для объекта (процесса), был предложен специальный объект — сокет (socket). Сокеты создаются в рамках определенного коммуникационного домена, подобно тому как файлы создаются в рамках файловой системы. Сокеты имеют соответствующий интерфейс доступа в файловой системе UNIX, и так же как обычные файлы, адресуются некоторым целым числом — дескриптором. Однако в отличие от обычных файлов, сокеты представляют собой виртуальный объект, который существует, пока на него ссылается хотя бы один из процессов.
Во-вторых, коммуникационные характеристики взаимодействия должны быть доступны процессам в некоторой унифицированной форме. Другими словами, приложение должно иметь возможность затребовать определенный тип связи, например, основанный на виртуальном канале (virtual circuit) или датаграммах (datagram), причем эти типы должны быть согласованы для всех коммуникационных доменов. Все сокеты условно можно разделить на несколько типов, в зависимости от предоставляемых коммуникационных характеристик. Полный набор этих характеристик включает:
□ Упорядоченную доставку данных
□ Отсутствие дублирования данных
□ Надежную доставку данных
□ Сохранение границ сообщений
□ Поддержку передачи экстренных сообщений
□ Предварительное установление соединения
Например, каналы, рассмотренные ранее, обеспечивают только первые три характеристики. При этом данные имеют вид сплошного потока, вычленение сообщений из которого должно при необходимости быть обеспечено взаимодействующими приложениями.
Поддержка передачи экстренных сообщений предполагает возможность доставки данных вне нормального потока. Как правило, это сообщения, связанные с некоторыми срочными событиями, требующими немедленной реакции.
Взаимодействие с предварительным установлением соединения предполагает создание виртуального канала между источником и получателем данных. Это избавляет от необходимости идентифицировать передающую сторону в каждом пакете данных. Идентификация происходит на начальном этапе установления связи и затем сохраняется для всех пакетов, принадлежащих данному виртуальному каналу.
В BSD UNIX реализованы следующие основные типы сокетов:
□ Сокет датаграмм (datagram socket), через который осуществляется теоретически ненадежная, несвязная передача пакетов.
□ Сокет потока (stream socket), через который осуществляется надежная передача потока байтов без сохранения границ сообщений. Этот тип сокетов поддерживает передачу экстренных данных.
□ Сокет пакетов (packet socket), через который осуществляется надежная последовательная передача данных без дублирования с предварительным установлением связи. При этом сохраняются границы сообщений.
□ Сокет низкого уровня (raw socket), через который осуществляется непосредственный доступ к коммуникационному протоколу.
Наконец, для того чтобы независимые процессы имели возможность взаимодействовать друг с другом, для сокетов должно быть определено пространство имен. Имя сокета имеет смысл только в рамках коммуникационного домена, в котором он создан. Если для IPC System V используются ключи, то имена сокетов представлены адресами.
Программный интерфейс сокетов
Итак, сокеты являются коммуникационным интерфейсом взаимодействующих процессов. Конкретный характер взаимодействия зависит от типа используемых сокетов, а коммуникационный домен, в рамках которого создан сокет, определяет базовые свойства этого взаимодействия. В табл. 3.6 приведены типы сокетов и их названия.
Таблица 3.6. Типы сокетов в системе BSD UNIX
Название Тип SOCK_DGRAM Сокет датаграмм SOCK_STREAM Сокет потока SOCK_SEQPACKET Сокет пакетов SOCK_RAW Сокет низкого уровня
Для создания сокета процесс должен указать тип сокета и коммуникационный домен, в рамках которого будет использоваться сокет. Поскольку коммуникационный домен может поддерживать использование нескольких протоколов, процесс может также указать конкретный коммуникационный протокол для взаимодействия. Если таковой не указан, система выберет наиболее подходящий из списка протоколов, доступных для данного коммуникационного домена. Если же в рамках указанного домена создание сокета данного типа невозможно, т.е. отсутствует соответствующий коммуникационный протокол, запрос процесса завершится неудачно.
Для создания сокета используется системный вызов socket(2)[44], имеющий следующий вид:
#include <sys/types.h>
#include <sys/socket.h>
int socket(int domain, int type, int protocol);
Здесь аргумент domain определяет коммуникационный домен, type — тип сокета, a protocol — используемый протокол (может быть не указан, т.е. приравнен 0). В случае успеха системный вызов возвращает положительное целое число, аналогичное файловому дескриптору, которое служит для адресации данного сокета в последующих вызовах.
По существу коммуникационный домен определяет семейство протоколов (protocol family), допустимых в рамках данного домена. Возможные значения аргумента domain включают:
