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

1. Загрузить значение переменной в регистр

2. Увеличить регистр

3. Записать значение регистра в переменную

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

Нить 1 Нить 2

1 Загрузить значение переменной в регистр

2 Увеличить регистр

3 Записать значение регистра в переменную

2 Увеличить регистр

3 Записать значение регистра в переменную

В этом случае нить 1 перезапишет значение записанной нитью 2, и переменная увеличится лишь на единицу вместо двух. Такие места в коде называют критическими секциями и организуют работу так, что они гарантировано выполняются только одной нитью.

Использование многонитевого принципа построения моей программы вызвано двумя причинами:

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

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

Механизм обмена информации между нитями

В процессе работы программы нитями необходимо обмениваться информацией. В основном это передача пакетов и запросов с параметрами. Для осуществления обмена использовался механизм pipe [8]. Pipe представляет собой модуль для передачи данных. Единственным его ограничением является то, что этот модуль создает однонаправленный поток данных. Создание производится с помощью функции pipe.

#include <unistd.h>

intpipe (intfiledes[2]);

Функция возвращает 0 в случае успеха и –1 при ошибке. Параметрами в функцию предается массив из двух дескрипторов, которые заполняются внутри функции. В первый дескриптор (filedes[0]) предназначен для чтения из pipe, а второй (filedes[1]) для записи в pipe. Чтение из pipe и запись в него производятся с помощью стандартных функций read и write. Для этих функций дескриптор pipe ничем не отличается от дескриптора файла.

#include <unistd.h>

ssize_t read (int fildes, void *buf, size_t nbyte);

Вторым параметром в функции передается указатель на буфер, куда записывать данные (для read) или откуда считывать их (для write). Третьим параметром для read передается максимальное число читаемых данных, я для write число записываемых байт.

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

Рис. 8. Структура передаваемых запросов

Первым байтом в сообщении идет тип данного сообщения, который говорит, какие именно данные содержаться. Если тип сообщения не предусмотрен в месте, куда это сообщение пришло, сообщается об ошибке и из pipe считывается буфер максимальной длины. Следующие за типом сообщения 4 байта содержат длину передаваемых данных. Если тип сообщения налагает какие-либо ограничения на длину данных (например, если передается IP адрес, то его длина должна быть 4 байта) и считанная длина этим ограничениям не удовлетворяет, то также сообщается об ошибке, и стараемся все вычитать из pipe. После этого из pipe достаются данные указанной длины. После обработки считанного запроса процедура повторяется заново, начиная с получения типа сообщения. Такой формат сообщения и приведенный порядок его обработки гарантирует, что никакое сообщение не будет потеряно.

Нитевая структура программы

В этом разделе будет рассмотрено, из каких нитей состоит программа, их назначение и как они взаимодействуют друг с другом. На рисунке 9 представлена нитевая структура программа.

Рис. 9. Нитевая структура программы

На рисунке окружностями условно показаны нити, одинарными стрелками передача данными между нитями, а двойными взаимодействие с таблицей (добавление, поиск и удаление). Программа содержит 4 вида нитей:

1. Нить работы с сетью

2. Нить распределения пакетов

3. Нить выполнения первой фазы

4. Нить выполнения второй фазы

Нить работы с сетью. Задачей данной нити является непрерывная проверка порта на наличие пакета и прием запросов от других модулей на отсылку пакетов. Работа данной нити начинается с открытия порта (функция socket) и указания адреса и порта, с которым мы будем работать[9].

struct sockaddr_in serveraddr;

if ((sockdscr = socket (AF_INET, SOCK_DGRAM, 0)) == -1) {

printf («Server error: cannot open socket\n»);

return NULL;

}

memset (&serveraddr, 0, sizeof(serveraddr));

serveraddr.sin_family = AF_INET;

serveraddr.sin_port = htons (Conf. LocalPort);

serveraddr.sin_addr.s_addr = inet_addr (Conf. LocalAddress); if (bind(sockdscr, (struct sockaddr *)&serveraddr, sizeof(serveraddr))==-1) {

printf («Server error: cannot bind\n»);

returnNULL;

}

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

#include <sys/time.h>

int select (int nfds, fd_set *readfds, fd_set *writefds,

fd_set *errorfds, struct timeval *timeout);

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

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

FD_SET (sockdscr, &rfds); /* Добавление в массив дескриптора порта*/

FD_SET (pipefd[0],&rfds); /* Добавление в массив дескриптора pipe*/

retval=select (1024,&rfds, NULL, NULL, NULL);

if (SOCKET_ERROR == retval) {

/* Обработкаошибки*/

}

if (FD_ISSET (sockdscr, &rfds)) {

/* Действия, выполняемые при приходе пакета */

}

if (FD_ISSET (pipefd[0], &rfds)) {

/* Действия, выполняемые при получении запроса */

}

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

Нить распределения пакетов. В задачу данной нити входит предварительный разбор заголовка пакета, проверка правильности структуры пакета и передача пакета нити, для которой он предназначен. Вся информация для проверки пакета и нахождения нити приемника берется из ISAKMP заголовка пакета. Данный заголовок должен находиться в начале каждого пакета и служит для определения, к какой именно попытке установления соединения принадлежит данный пакет. Структура ISAKMP заголовка приведена на рисунке 10 [4].

Первые 8 байт занимает InitiatorCookie – иидентификатор попытки установления соединения со стороны инициатора. Значение данного поля выбирается на стороне инициатора (случайным или предопределенным образом) и служит при дальнейшем распределении пакетов. Responder Cookie играет такое же значение, но для ответчика.

Рис. 10. Структура ISAKMP заголовка

Следующим полем идет NextPayload, которое показывает тип компонента (payload) следующего за заголовком. Version показывает версию используемого протокола. Exchangetype говорит о режиме, при котором используется данный пакет (MainMode, AggressiveMode, QuickModeи т.п.). Флаги содержат информацию о состоянии пакета, например, зашифрован он или нет. Еще одним идентификатором пакета является MessageID. Последние 4 байта содержат длину всего пакета, включая сам заголовок.

Идентификация пакета проводится по следующим принципам. В первом пакете инициатор проставляет Initiator Cookie, а Responder Cookie оставляет нулевым, давая возможность ответчику при ответе заполнить его. Message ID служит для идентификации разных попыток установления соединения во второй фазе, идущих под защитой одной и той же первой фазы, а, следовательно, имеющих одинаковые CookieI и CookieR.

Порядок обработки пакета следующий

1. Проверка длины пакета. Производится простым сравнением длины полученного пакета, которую мы узнаем при чтении пакета из порта и значением соответствующего поля в ISAKMP заголовке. Данная проверка является очень простой, но в то же время весьма эффективной, т. к. позволяет быстро (фактически на самом первом этапе), без затрачивания больших ресурсов отсечь случайные пакеты. Здесь мы впервые встречаемся с проблемой разного способа хранения чисел на разных архитектурах. Если рассмотреть конкретный пример, то число 0x01020304 в системе с процессором SunSparc будет представлено в виде

Программа установки защищенных сетевых соединений с использованием протокола ISAKMP (стр. 4 из 12)

Механизм обмена информации между нитями

Нитевая структура программы