Организация взаимодействия процессов в сетях

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

В частности процесс – это одно из основных понятий систем типа Unix, к примеру, серверных систем Windows.

Процесс в широком смысле слова – это последовательность каких-то событий, действий.

Если говорить о вычислительных системах, то под процессом обычно понимаются:

1. Сама выполняемая программа (ее исходный код, команды процессору)

2. Данные, обрабатываемые этой программой

3. Ресурсы:

a. Память

b. Ресурсы процессора, его время.

c. Электричество

d. Воздух

e. Вода (в некоторых современных системах охлаждения)

и т. д.

4. Порты ввода-вывода.

Обмен информации между объектами вычислительной системы происходит через порты. Не физические порты ввода-вывода, а порты процессора. Причем не порты, которые используются при описании стеков сетевых протоколов, а именно порты процессора.

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

Некоторые порты являются стандартными, жестко закрепленными за определенными устройствами (клавиатурой, мышью и т.д.).

Рассмотрим, как происходит взаимодействие процессов в Unix и во всех системах ей подобных. Во первых, в описание процесса входит: идентификатор процесса, описание файлов, доступных этому процессу, какие файлы сейчас открыты, информация о текущем каталоге, переменных окружениях и т.д.

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

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

На начальном этапе создания и развития различного рода телекоммуникационных систем создавались централизованные системы. Они состояли из одной большой машины (mainframe) и подключенных к ней, через каналы передачи данных, терминалов. На начальных этапах терминалы были простыми аналогами электрических пишущих машин, затем появились терминалы, включающие в себя дисплей и клавиатуру. Это были простые, неинтеллектуальные терминалы. Минимальные средства для предварительной обработки данных в терминалах появились позже, с появлением микропроцессоров и развитием соответствующих технологий. Всеми процессами, которые проходили в этой системе, управляла единственная центральная машина. На центральном компьютере выполнялись прикладные программы, здесь же находились базы данных и СУБД, и, кроме того, центральный компьютер обеспечивал управление процессами передачи по всем каналам и связь с терминалами. Т.е. все функции выполнялись в одном единственном центре.

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

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

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

Допустим необходимо решить некую оптимизационную задачу с использованием информации из базы данных.

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

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

некую программу оптимизации, которая выполняет какие-то вычислительные операции и обрабатывает информацию из некоторой базы данных. Процесс B обеспечивает управление этой базой данных. Т.е. из A идет запрос на некоторую информацию, в B этот запрос обрабатывается и в каком-то фиксированном формате выдается результат обработки этого запроса.

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

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

Допустим, в какой-то точке программы A появляется необходимость получения информации из базы данных. В программе A может быть сформирован некоторый запрос, который нужно будет где-то разместить (например, в оперативной памяти или каком-то буфере). Причем адрес области должен быть известен как процессу A, так и процессу В. Если процесс А размещает по этому адресу некий запрос в фиксированном формате, то процесс В должен быть в состоянии считать информацию по этому адресу. Для этого он должен знать начальный адрес этого запроса, в каком формате представлен запрос. Кроме того, так как процессы работают параллельно, независимо друг от друга, процесс B должен как-то получить информацию о том, что по данному адресу размещен запрос, который необходимо прочитать и обработать. Другими словами, процесс A должен каким-то образом просигнализировать о размещении запроса.

Отсюда появляются 2 задачи:

1. Обмен управляющими сигналами

2. Обеспечение согласованного доступа к общим областям памяти

(В системах, подобных Unix, существуют средства обмена сигналами между процессами.)

Теперь немного усложним представленную выше задачу.

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

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

Как быть в этом случае? Ведь никакого согласования в этом случае изначально не предусматривалось. Как в этом случае можно организовать взаимодействие?

Эта ситуация была типична для 60-ых годов, когда появилось довольно много разных разработчиков ПО, стали создаваться достаточно сложные системы и пакеты прикладных программ, различные СУБД. Поэтому начался поиск некоторого универсального подхода к решению подобного рода задач. Задач объединения уже готовых модулей.

Был предложен следующий подход. Для того чтобы эти модули могли взаимодействовать между собой, было предложено функции взаимодействия и согласования выполнять в отдельных, дополнительных модулях, специально разрабатываемых для этих целей, которые так и назвали «Управление Представлением» (Presentation) (УПр).

Получается некая симметричная картина: к процессу A добавляется модуль управления представлением (УПр) и к процессу B добавляется такой же модуль. Эти модули как раз и берут на себя функции согласования форматов, согласования кодировок; для того чтобы процессы могли понимать друг друга.

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

Таким образом, для установления связи между процессами A и B.

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

Модули управления сеансами «договариваются», к примеру, о том, в каком режиме обмена пройдет весь диалог (дуплексном, полудуплексном), кто может быть инициатором этого диалога (только сторона A, только сторона B или диалог может быть равноправным), какая сторона является ответственной за обеспечение надежности передачи, какая сторона должна взять на себя восстановление сеанса связи при сбое и т.д.

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

Таким образом, в прикладной программе A формируется некоторое пользовательское сообщение, запрос. К этому сообщению добавляется заголовок, в котором размещается различная служебная информация от модулей управления представлением и управления сеансами. Затем это сообщение передается из процесса A в процесс B.

Обмен происходит через некоторые логические точки. Эти точки входа в тот или иной процесс называются портами.

На приемной стороне процесс B получает это сообщение. Модуль управления сеансами связи интерпретирует адресованные ему поля в заголовке сообщения, и, в зависимости от того, какая информация там записана, принимает решение об установлении сеанса связи, или, наоборот, об отказе в этом.

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

По результатам выполнения этого запроса, в той же последовательности, происходит передача ответа.

Модули управления представлением и управления сеансами связи позволяют автоматизировать взаимодействие между двумя независимо разработанными и независимо выполняющимися процессами.

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

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

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

Очевидно, что необходимо как-то обеспечить управление этими каналами. Для этих целей КПД обеспечивает передачу цифрового сигнала, отдельных символов, отдельных байтов. Для обеспечения надежности передачи на базе каналов создается новая система, которая, в рамках модели, которой мы рассматривали, называется Звеном Передачи Данных (Link). А модули – модули управления звеном передачи данных (УЗПД). ЗПД (Link) или информационный канал обеспечивает надежную передачу информационных блоков, называемых кадрами (frame). Как это происходит?

Используются контрольные суммы, записываемые в концевик кадра: вычисление контрольных сумм на передаче, вычисление контрольных сумм на приеме, сравнение контрольных сумм, повторная передача кадров по необходимости и т.д.

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

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

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

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

Допустим, у нас есть процессы P₁₁, P₁₂, …, P_1n, которые находятся в одной системе, к примеру, на сервере. У нас есть вторая система, которая взаимодействует с первой. Допустим это некая рабочая станция, в которой открыто один или несколько браузеров, которые обращаются к разным веб сайтам, выполняющимся на нашем сервере. Поэтому, даже если организовать все это по схеме соединения двух компьютеров, разнесенных в пространстве, ясно, что физическая связь (электрическая, оптическая или радио) будет организовываться с помощью одного канала и, соответственно, с помощью одного звена.

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

Мы рассмотрели случай, когда взаимодействуют два компьютера, но более реалистичной была бы следующая картина:

Абонентский комплекс одновременно получает доступ к нескольким серверам. Там выполняются разные клиентские программы. Для того чтобы при передаче выбрать нужное звено ПД, необходим исходящий канал.

Эту ситуацию легко продемонстрировать на примере узлов коммутации. К узлу коммутации с помощью звеньев передачи данных подключаются различного рода абоненты, абонентские комплексы.

Модуль управления сетью (УС) выполняет функцию маршрутизации. Это одна из основных функций узлов коммутации в сетях передачи данных. Поскольку в составе сети появляется дополнительный управляющий модуль, то формирующиеся сообщения поступают в модуль управления сетью, где упаковываются в пакеты. Это еще одна разновидность информационного блока, наряду с сообщением и кадром, основной функцией которого является маршрутизация.

Рассмотрим ситуацию, когда несколько звеньев подключено к группе процессоров. Модуль УС при передаче каждый раз выбирает, в какое исходящее звено отправить соответствующее сообщение. Затем берет это сообщение, формирует на его базе пакет и передает дальше в соответствующее звено. На приеме выполняются обратные действия. Допустим, у нас имеется некая принимающая сторона, на которой работает несколько процессов. Эта некая система взаимодействует с другими. На звенья поступают кадры, в которых передаются пакеты. Модуль управления сетью работает именно с пакетами. Модуль управления сетью анализирует заголовки пакетов, где указывается порядковый номер пакета, адрес получателя, номер его порта. Для того чтобы выполнить распределение получаемых, уже не пакетов, а сообщений по нужным портам в эту модель добавляется еще один модуль – модуль управления передачей (УП).

Модуль УС извлекает сообщения из пакетов и передает их в модуль управления передачей. В заголовке сообщений, помимо всего прочего, передается номер порта, по которому идентифицируется прикладной процесс.

Модули управления передачей и сетью являются общими для всех процессов.

Одна из основных функций модуля управления передачей – внутренняя маршрутизация. Вторая основная функция связана с повышением надежности передачи.

Представим себе следующую ситуацию. С одной системы в другую необходимо передавать какие-то блоки длиной по 500000 байт. При этом коэффициент надежности сети 10^-5. Мы передаваем блоки по 100 тыс. байт каждый. Поскольку надежность 10^-5, то в каждом блоке, в среднем, возникает 1 ошибка. Принимающая сторона, получает блок, обнаруживает ошибку, информирует об этом передающую сторону. Блок с ошибкой стирается. Передающая сторона передает блок заново, а поскольку коэффициент надежности не изменился, то возникает еще одна ошибка, быть может, уже и в другом месте. Получается некий замкнутый круг. Как попытаться из него выйти?

Можно разбить блоки еще больше, к примеру, каждый блок еще на 500 по 200 байтов каждый. Тогда поскольку надежность та же, то, в среднем, 499 блоков будет передано правильно, и только 1 будет передан с ошибкой. Его то и нужно будет передавать повторно.

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

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

На приемной стороне модуль УП собирает фрагменты в исходные сообщения и отправляет их нужному процессу.

Дата добавления: 2014-01-05