Самодел 2 (1114717), страница 16

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 16)

#include <sys/types.h>

#include <sys/ipc.h>

#include <sys/sem.h>

#include <string.h>

#define NMAX 256

int main(int argc, char **argv)

{

key_t key;

int semid, shmid;

struct sembuf sops;

char *shmaddr;

char str[NMAX];

key = ftok(“/usr/ter/exmpl”,’S’);

/* создаем уникальный ключ */

semid = semget(key, 1, 0666 | IPC_CREAT);

/* создаем один семафор с определенными правами доступа */

shmid = shmget(key, NMAX, 0666 | IPC_CREAT);

/*создаем разделяемую память на 256 элементов */

shmaddr = shmat(shmid, NULL, 0);

/* подключаемся к разделу памяти, в shaddr – указатель на буфер с разделяемой памятью*/

semctl(semid,0,SETVAL, (int) 0);

/*инициализируем семафор значением 0 */

sops.sem_num = 0;

sops.sem_flg = 0;

do { /* запуск цикла */

printf(“Введите строку:”);

if (fgets(str, NMAX, stdin) == NULL) /* окончание ввода */

/* пишем признак завершения – строку “Q” */

strcpy(str, “Q”);

/* в текущий момент семафор открыт для этого процесса*/

strcpy(shmaddr, str); /* копируем строку в разд. память */

/* предоставляем второму процессу возможность войти */

sops.sem_op=3; /* увеличение семафора на 3 */

semop(semid, &sops, 1);

/* ждем, пока семафор будет открыт для 1го процесса - для следующей итерации цикла*/

sops.sem_op=0; /* ожидание обнуления семафора */

semop(semid, &sops, 1);

} while (str[0] != ‘Q’);

/* в данный момент второй процесс уже дочитал из разделяемой памяти и отключился от нее – можно ее удалять*/

shmdt(shmaddr) ; /* отключаемся от разделяемой памяти */

shmctl(shmid, IPC_RMID, NULL);

/* уничтожаем разделяемую память */

semctl(semid, 0, IPC_RMID, (int) 0);

/* уничтожаем семафор */

return 0;

}

2й процесс:

int main(int argc, char **argv)

{

key_t key;

int semid, shmid;

struct sembuf sops;

char *shmaddr;

char str[NMAX];

key = ftok(“/usr/ter/exmpl”,’S’);

/* создаем тот же самый ключ */

semid = semget(key, 1, 0666 | IPC_CREAT);

shmid = shmget(key, NMAX, 0666 | IPC_CREAT);

/* аналогично предыдущему процессу - инициализации ресурсов */

shmaddr = shmat(shmid, NULL, 0);

sops.sem_num = 0;

sops.sem_flg = 0;

/* запускаем цикл */

do {

printf(“Waiting… \n”); /* ожидание на семафоре */

sops.sem_op=-2;

/* будем ожидать, пока “значение семафора” + ”значение sem_op” не станет положительным, т.е. пока значение семафора не станет как минимум 3 (3-2=1 > 0) */

semop(semid, &sops, 1);

/* теперь значение семафора равно 1 */

strcpy(str, shmaddr); /* копируем строку из разд.памяти */

/*критическая секция - работа с разделяемой памятью - в этот момент первый процесс к разделяемой памяти доступа не имеет*/

if (str[0] == ‘Q’)

/*завершение работы - освобождаем разделяемую память */

shmdt(shmaddr);

/*после работы – обнулим семафор*/

sops.sem_op=-1;

semop(semid, &sops, 1);

printf(“Read from shared memory: %s\n”, str);

} while (str[0] != ‘Q’);

return 0;

}

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

Механизм сокетов

Средства межпроцессного взаимодействия ОС UNIX, представленные в системе IPC, решают проблему взаимодействия двух процессов, выполняющихся в рамках одной операционной системы. Однако, очевидно, их невозможно использовать, когда требуется организовать взаимодействие процессов в рамках сети. Это связано как с принятой системой именования, которая обеспечивает уникальность только в рамках данной системы, так и вообще с реализацией механизмов разделяемой памяти, очереди сообщений и семафоров, – очевидно, что для удаленного взаимодействия они не годятся. Следовательно, возникает необходимость в каком-то дополнительном механизме, позволяющем общаться двум процессам в рамках сети. Однако если разработчики программ будут иметь два абсолютно разных подхода к реализации взаимодействия процессов, в зависимости от того, на одной машине они выполняются или на разных узлах сети, им, очевидно, придется во многих случаях создавать два принципиально разных куска кода, отвечающих за это взаимодействие. Понятно, что это неудобно и хотелось бы в связи с этим иметь некоторый унифицированный механизм, который в определенной степени позволял бы абстрагироваться от расположения процессов и давал бы возможность использования одних и тех же подходов для локального и нелокального взаимодействия. Кроме того, как только мы обращаемся к сетевому взаимодействию, встает проблема многообразия сетевых протоколов и их использования. Понятно, что было бы удобно иметь какой-нибудь общий интерфейс, позволяющий пользоваться услугами различных протоколов по выбору пользователя.

Обозначенные проблемы был призван решить механизм, впервые появившийся в Берклиевском UNIX – BSD, начиная с версии 4.2, и названный сокетами (sockets). Ниже подробно рассмотривается этот механизм.

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

Общая схема работы с сокетами:

Механизм сокетов чрезвычайно удобен при разработке взаимодействующих приложений, образующих систему «клиент-сервер». Клиент посылает серверу запросы на предоставление услуги, а сервер отвечает на эти запросы. Схема использования механизма сокетов для взаимодействия в рамках модели «клиент-сервер» такова. Процесс-сервер запрашивает у ОС сокет и, получив его, присваивает ему некоторое имя (адрес), которое предполагается заранее известным всем клиентам, которые захотят общаться с данным сервером. После этого сервер переходит в режим ожидания и обработки запросов от клиентов. Клиент, со своей стороны, тоже создает сокет и запрашивает соединение своего сокета с сокетом сервера, имеющим известное ему имя (адрес). После того, как соединение будет установлено, клиент и сервер могут обмениваться данными через соединенную пару сокетов. Ниже мы подробно рассмотрим функции, выполняющие все необходимые действия с сокетами, и напишем пример небольшой серверной и клиентской программы, использующих сокеты.

Средства взаимодействия процессов в сети

Типы сокетов.

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

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

2. Датаграммное соединение

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

Коммуникационный домен.

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

Мы будем рассматривать два основных домена:

для локального взаимодействия – домен AF_UNIX

для взаимодействия в рамках сети – домен AF_INET

(префикс AF обозначает сокращение от address family – семейство адресов).

В домене AF_UNIX формат адреса – это допустимое имя файла, в домене AF_INET адрес образуют имя хоста + номер порта.

Заметим, что фактически коммуникационный домен определяет также используемые семейства протоколов. Так, для домена AF_UNIX это будут внутренние протоколы ОС, для домена AF_INET – протоколы семейства TCP/IP. BSD UNIX поддерживает также третий домен – AF_NS, использующий протоколы удаленного взаимодействия Xerox NS, но мы его рассматривать не будем.

Создание Сокета

#include <sys/types.h>

#include <sys/socket.h>

int socket (int domain, int type, int protocol);

domain – коммуникационный домен, к которому должен принадлежать создаваемый сокет. Для двух рассмотренных нами доменов соответствующие константы будут равны, как мы уже говорили, AF_UNIX и AF_INET.

type – тип соединения, которым будет пользоваться сокет (тип сокета)

SOCK_STREAM - виртуальный канал

SOCK_DGRAM - датаграммы

protocol –протокол, который будет использоваться в рамках данного коммуникационного домена для создания соединения. Если установить значение данного аргумента в 0, система автоматически выберет подходящий протокол. В наших примерах мы так и будем поступать. Однако здесь для справки приведем константы для протоколов, используемых в домене AF_INET:

IPPROTO_TCP – обозначает протокол TCP (корректно при создании сокета типа SOCK_STREAM)

IPPROTO_UDP – обозначает протокол UDP (корректно при создании сокета типа SOCK_DGRAM)

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

Возвращает:

В случае неудачи (например, при некорректном сочетании коммуникационного домена, типа сокета и протокола), функция возвращает –1.

Связывание

#include <sys/types.h>

#include <sys/socket.h>

int bind (int sockfd, struct sockaddr *myaddr, int addrlen);

sockfd – дескриптор сокета, возвращенный функцией socket().

myaddr – указатель на структуру, содержащую адрес сокета

1.

Для домена AF_UNIX

#include <sys/un.h>

struct sockaddr_un

{

short sun_family; /* == AF_UNIX */

char sun_path[108];

};

2.Для домена AF_INET

#include <netinet/in.h>

struct sockaddr_in

{

short sin_family; /* == AF_INET */

u_short sin_port; /* port number */

struct in_addr sin_addr; /* host IP address */

char sin_zero[8]; /* not used */

};

addrlen – последний аргумент функции задает реальный размер структуры, на которую указывает myaddr.

Отметим, что если мы имеем дело с локальными сокетами и адрес сокета представляет собой имя файла, то при выполнении функции bind система в качестве побочного эффекта создает файл с таким именем. Поэтому для успешного выполнения bind необходимо, чтобы такого файла не существовало к данному моменту. Это следует учитывать, если мы «зашиваем» в программу определенное имя и намерены запускать нашу программу несколько раз – необходимо удалять этот файл перед связыванием.

Характеристики

Список файлов лекций