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

Мультипроцессорные системы. Использование нескольких нитей в одном процессе является эффективным способом использования возможности параллельной работы.

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

Оперативность серверных приложений. Серверные приложения обрабатывают запросы, приходящие от клиентов. Одновременно может прийти несколько запросов. В случае однонитевого приложения запросы будут выполняться последовательно, и выполнение сложного запроса может надолго отложить выполнение других, более простых и важных запросов. Много нитевая структура в этом отношении представляется более адаптивной, т. к. каждый запрос пользователя может быть обработан согласно его сложности и важности. Другой проблемой для серверных приложений является взаимные запросы. Это происходит если сервер 1, обрабатывая клиентский запрос, делает запрос к серверу 2, который в свою очередь при его обработке обращается обратно к серверу 1. В однонитевом приложении это приведет к зависанию обоих серверов, т. к. единственная нить сервера 1 уже занята обработкой запроса и не может обработать запрос сервера 2. Использование нескольких нитей решает эту проблему, т. к. для каждого запроса выделяется отдельная нить, которая выполняется независимо от других.

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

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

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

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

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

Нить 1 Нить 2

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

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

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

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

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

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

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

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

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

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

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

#include <unistd.h>

int pipe (int filedes[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);

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 вида нитей:

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

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

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

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

Нить работы с сетью. Задачей данной нити является непрерывная проверка порта на наличие пакета и прием запросов от других модулей на отсылку пакетов. Работа данной нити начинается с открытия порта (функция 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»);

return NULL;

}

Как видно из данного части исходного кода программы, локальный 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 байт занимает Initiator Cookie - иидентификатор попытки установления соединения со стороны инициатора. Значение данного поля выбирается на стороне инициатора (случайным или предопределенным образом) и служит при дальнейшем распределении пакетов. Responder Cookie играет такое же значение, но для ответчика.

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

Следующим полем идет Next Payload, которое показывает тип компонента (payload) следующего за заголовком. Version показывает версию используемого протокола. Exchange type говорит о режиме, при котором используется данный пакет (Main Mode, Aggressive Mode, Quick Mode и т.п.). Флаги содержат информацию о состоянии пакета, например, зашифрован он или нет. Еще одним идентификатором пакета является Message ID. Последние 4 байта содержат длину всего пакета, включая сам заголовок.

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

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

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9