Создание структур IPC и доступ к ним

Нормальное поведение программ, желающих воспользоваться механизмами System V IPC для обмена данными, заключается в следующем. Процесс сначала создает структуру IPC посредством доступного системного вызова xxxget(), используя заранее оговоренный ключ. Другие процессы после этого могут использовать xxxget() для получения доступа к этой же ранее созданной структуре. При ``нормальной'' IPC первый процесс инициирует ``установку'' адекватных структур внутри ядра. При последующих вызовах xxxget() просто возвращается значение числового идентификатора, которое может использоваться для обращения к структуре. Таким образом, все перечисленные процессы будут использовать одну структуру и манипулировать ею.

DIPC пытаются ``скрыть'' эту ситуацию настолько, насколько возможно. Процессам на разных машинах нужно использовать один и тот же ключ, чтобы обращаться к одной структуре IPC. При DIPC, когда процесс желает организовать или получить доступ к структуре IPC с определенным ключом, локальное ядро в первую очередь отслеживает, используется ли уже данный ключ. При ``нормальной'' IPC эти процессы очень похожи. Если структура найдена, запрос обрабатывается локально, без обращения к арбитру. Но если структура IPC с указанным ключом не найдена, то арбитру нужно осуществить поиск и выяснить, используется ли уже такой ключ в кластере. Арбитр ищет ключ в своих таблицах и сообщает запрашивающему процессу, найден ключ или нет и, если найден, является ли он распределенным ключом или нет. Арбитр может ответить незамедлительно, если ключ присутствует или отсутствует, но ни одна из машин не запрашивает его. После посылки информации в запрашивающий компьютер арбитр ожидает подтверждения, создала ли данная машина локально структуру IPC с этим ключом или нет, чтобы при необходимости смочь обновить свою информацию. Но если ключ не найден, а арбитр уже послал соответствующее сообщение машине, то он не отвечает на все последующие запросы такого ключа, пока машина не ответит, создала ли она структуру IPC. Когда информация поступит, арбитр сможет обслужить прочие поступающие запросы.

Такой централизованный (последовательный) алгоритм прост и легок в реализации. Распределенный алгоритм может быть комплексным, требующим большого числа обменов сообщениями. Также считается, что на создание структуры IPC затрачивается относительно малая доля времени, затраченного на выполнение программы.

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

В табл. 6 показано, как процесс решает, может ли он при необходимости создать ранее не существовавшую структуру IPC (xxxget() с флагом IPC_CREAT).

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

Проверка подразумевает выполнение действий с целью получения гарантии того, что указанные флаги для xxxget() и права доступа к распределенной структуре IPC позволяют процессу получить доступ к структуре. В успешном случае, ``действие'' становится ``созданием''.

В данном случае, правила проверки флагов близки к правилам для обычной IPC. Например, указание IPC_EXCL и IPC_DIPC при одном системном вызове приводит к ошибке, если структура IPC с указанным распределенным ключом уже присутствует на другой машине. Метод, применяющийся для проверки прав доступа: имя эффективного пользовательского логина, наряду со всеми параметрами xxxget() передается машине, которая имеет структуру с распределенным ключом. Затем dipcd исполняет системный вызов xxxget() на этом компьютере. Если он завершается успешно, то осуществляется попытка выполнения тех же действий на оригинальной запрашивающей машине. Если любое из приведенных действий завершается ненормально, то и оригинальный xxxget() также потерпит неудачу. Для получения более подробной информации о том, как DIPC обрабатывает имена пользователей, обратитесь к разделу о безопасности.

Если ``действие'' - это ``создание'', локальная структура будет создана даже в том случае, если иная структура с тем же самым ключом присутствует где-либо еще в кластере. Короче говоря, на любой машине, где определенные процессы используют ключ для коммуникаций, есть структура с этим ключом.

Ниже показано, как DIPC обрабатывает запрос о новом создании IPC.

Первая фаза: поиск Сеть (Запрашивающий компьютер) | (Арбитрирующий компьютер) |-1->back_end >-2-+ | | | ядро|<--------6--employer --3-------|-> referee | | | +-5-< front_end <-|<-----4-+

Предполагается, что структура IPC с указанным ключом на вызывающей машине не заменяется. В этом случае back_end находит запрос о поиске ключа (1) и раздваивает employer для его обработки (2); employer вызывает referee и ``спрашивает'' его (3); referee посылает ответ (нашел или нет ...) процессу front_end запрашивающего компьютера (4) и затем ответ доставляется оригинальному employer (5), который отдает результаты назад в ядро (6). Ядро должно однозначно определить, может быть создана структура IPC или нет. По ходу дела referee запускает таймер - для того, чтобы гарантировать своевременное предоставление информации. После этого может начинаться вторая фаза (непосредственная передача).

Вы можете обратиться к предыдущей схеме для понимания второй фазы. Во время фазы непосредственной передачи referee информируется о результате работы системного вызова xxxget(). Все действия аналогичны действиям во время предыдущей фазы:
back_end находит сведения о результате работы xxxget() (1) и информирует referee (2 и 3), но на сей раз целью действий (4), (5) и (6) является обеспечение гарантии того, что исходный запрашивающий процесс будет продолжен только после того, как информация referee будет обновлена.

Рассмотрите следующий алгоритм, показывающий, насколько часть ядра DIPC зависит от того, как создается новая структура или происходит доступ к ней. Символ (*) нужен для индикации возможного привлечения сети. НАЧАЛО ЕСЛИ указанный ключ используется в локальной структуре ТО ~КОНЕЦ~алгоритма ЕСЛИ dipcd присутствует и вызывающий процесс - это не dipcd ТО искать с помощью referee ключ (*) ЕСЛИ ключ найден ТО протестировать совместимость запрашиваемой структуры с удаленной структурой. В СЛУЧАЕ если обе структуры являются распределенными ВЫПОЛНИТЬ проверку прав доступа (*). ЕСЛИ все условия обеспечены ТО попытаться создать структуру информировать referee о результатах (непосредственная передача)(*) КОНЕЦ Проблемы с back_end и employer мгновенно передаются ядру. Прочие ошибки обнаруживаются с помощью механизмов тайм-аута для employer и referee.

Если в системе отсутствует возможность получения необходимой информации от referee, то принимается, что данный ключ не используется, и она ведет себя так, как будто referee сказал ``да''. Это значит, что система будет проявлять себя ``владельцем'' (см. следующий раздел). Хотя такой подход и заставляет процесс продолжаться, он может создать проблемы тогда, когда структуры IPC с тем же самым ключом будут на других машинах. Аналогичные проблемы могут возникнуть, если во время непосредственного обмена не окажется с referee. В таком случае будет наступать тайм-аут, а referee будет предполагать, что запрашивающий процесс при попытке создания структуры завершился ненормально. Таким образом, referee может владеть ошибочной информацией.