Лекция №7. Связь между процессами по сети посредством виртуальных каналов.

План лекции.

1. Виртуальные каналы

2. Виртуальные процессы

3. Общение по сети с помощью виртуальных каналов.

4. Прекращение виртуальных каналов

1. Виртуальные каналы

Приложения QNX могут обращаться к процессу на другом компьютере в сети так же, как если бы он шел на той же самой машине. Вообще то приложение просто не видит разницы между локальным и удаленным ресурсом.

Эта высокая степень прозрачности достигается путем виртуальных каналов (virtual circuits или VC), которые являются путями, предоставляемыми Network Manager-ом для передачи сообщений, proxies, и сигналов по сети.

VC вообще позволяют эффективнее использовать ресурсы в сети QNX и вот по каким причинам:

• Когда создается VC - ему дается возможность работать с сообщениями не больше определенного размера; это значит, что вы можете заранее распределить ресурсы. Тем не менее, когда вам надо предать сообщение большего размера VC автоматически расширяется, чтобы пропустить его.

• Если два процесса находящиеся на разных нода общаются друг с другом используя более чем один VC -- то VC объединяются; существует только один реальный виртуальный канал (типа каламбур - прим. пер.) между этими процессами. Эта ситуация обычно возникает когда процесс работает одновременно с несколькими файлами из удаленной файловой системы.

• Если процесс подключается к уже существующему совместно используемому VC и ему надо буфер больше чем он есть на данный момент - то размер буфера автоматически увеличивается.

• Когда процесс прекращается - связанные с ним VC автоматически освобождаются.

2. Виртуальные процессы

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

Например, на этой иллюстрации виртуальный канал соединяет PID 1 с PID 2. На ноде 20—где находится PID 1—VID представляет собой PID 2. На ноде 40—где находится PID 2—VID представляет собой PID 1. И PID 1 и PID 2 могут обращаться к VID на своем ноде, как если бы это был локальный процесс: посылать и принимать сообщения, выдавать сигналы, ожидать и т.д. Таким образом, например, PID 1 может послать сообщение VID на своем конце, и этот VID передаст это сообщение по сети VID-у представляющему PID 1 на другом конце. А этот VID уже передаст сообщение PID 2.

node 20 node 40

3. Общение по сети с помощью виртуальных каналов.

Когда PID 1 отсылает <сообщение> VID-у 2, то посланный запрос передается по виртуальному каналу, заставляя VID 1 отсылать <сообщение> PID 2.

Каждый VID обслуживает соединение, которое содержит следующую информацию:

• местный pid

• удаленный pid

• удаленный nid (идентификатор нода)

• удаленный vid

По всей вероятности вам не придется часто сталкиваться с VC. Например, когда приложение хочет получить доступ по сети к ресурсу ввода/вывода - то VC создается библиотечной функцией open() по просьбе приложения. Само приложение не принимает непосредственного участия в создании или использовании VC. Когда приложение устанавливает местонахождение сервера с помощью функции С qnx_name_locate(), VC создается автоматически по просьбе приложения. Для самого приложения VC выглядит просто как PID.

Для дальнейшей информации о qnx_name_locate(), смотри дискуссию о символических именах процессов (discussion of process symbolic names) в главе 3.

4. Прекращение виртуальных каналов

Процесс может оказаться неспособным к связи по VC по следующим причинам:

• Компьютер, на котором он работал, выключили

• Компьютер отключили от сети

• Удаленный процесс, с которым происходило общение прекращен

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

Менеджер процессов на каждом ноде проверяет целостность своих VC. Он осуществляет это следующим образом:

1) Каждый раз когда по VC была осуществлена успешная операция обновляется связанная с этим VC метка, которая показывает время последнего события на нем.

2) По истечению установленных интервалов менеджер осматривает каждый VC. Если в этом канале не было никаких событий, то менеджер посылает пакет проверки целостности сети менеджеру процессов на нод на другом конце канала.

3) Если ответ не получен или обнаружена другая проблема выставляется флаг что VC имеет проблемы. После этого производится установленное количество попыток восстановить контакт.

4) Если попытки не удаются то VC прекращается; любой процесс заблокированный на VC переводится в READY. (Процесс видит возвращаемый коммуникационным примитивом VC код ошибки.)

Для управления параметрами проверки целостности используйте утилиту netpoll.