[08.09.11] Лекция №2 (Конспекты - Сетевое ПО)

Лекция №2 [08.09.11]

Архитектура приложений "клиент-сервер"

В роли клиента выступает однопользовательский ПК, обеспечивающий дружественный интерфейс для конечного пользователя. Каждый сервер обеспечивает для клиента множество совместно используемых сервисов. Например, сервер БД - позволяет использовать для управления БД высокопроизводительную вычислительную систему для одновременного доступа многих клиентов. Связь между всеми ними обеспечивает сеть.

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

Шестиуровневая модель распределения:

1) самый верхний. Средства представления на стороне клиента (данных на мониторе, GUI);

2) логика представления. Сценарий взаимодействия для реализации средств представления (меню, списки);

3) логика приложения. Вычислительные процедуры, операции;

4) логика данных. Операции с данными, которые хранятся в некоторой базе;

5) внутренние операции БД. Операции СУБД;

6) файловые операции. Средства на уровне локальных ОС.

На основе этой модели можно построить несколько схем распределения частей приложения между узлами сети. Классы приложений клиент-сервер:

1) обработка на одном узле. Рабочая станция выполняет имитацию терминала;

2) обработка на сервере. Каждый клиент отвечает за обеспечение GUI, а вся обработка осуществляется на сервере. Такой вариант характерен для ранних конфигураций Клиент-Сервер. Называется тонким клиентом;

3) обработка у клиента. Практически вся обработка реализуется на клиенте, а сервер используется только для хранения данных (БД и СУБД). Называется толстым клиентом. Ещё и жирным называют. Этот вариант более распространён;

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

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

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

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

Логическая организация архитектуры Клиент-Сервер:

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

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

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

В заголовке содержится следующая информация:

- адрес. Набор символов, уникально определяющий отправляющий и получающий процесс. Адрес состоит из двух частей: адрес отправителя и адрес получателя. Причём, в сетевых системах адрес уникален и имеет свою структуру;

- идентификатор сообщения. Некоторый последовательный номер сообщения.

Данные – некоторая структурированная информация:

- тип данных. Может быть указание на то, являются данные резидентными (непосредственно в сообщении) или нерезидентными (находятся где-то в другом месте, а тут только указатель на это место);

- поле длины данных (данные могут быть переменной длины);

- собственно данные.

В любой ОС имеется подсистема передачи сообщений, которая обеспечивает набор средств для организации взаимодействия процессов по сети. Эта подсистема скрывает детали сложных сетевых протоколов, тогда передача сообщений может осуществляться с помощью некоторых примитивов. Например, send и receive.

Вопросы, решаемые при передаче сообщений и влияющие на её эффективность:

1) способ задания адреса получателя;

2) количество получателей;

3) требуется ли гарантированная доставка сообщений (нужно ли подтверждение получения);

4) как отправитель, получатель и система передачи сообщений должны реагировать на отказы узлов или каналов во время взаимодействия;

5) нужна ли буферизация сообщений и как себя вести при переполнении буфера;

6) может ли приёмник менять порядок обработки сообщений.

От того, как протокол передачи сообщений отвечает на эти вопросы, зависит семантика протокола передачи.

Синхронизация процессов при передаче сообещний

Коммуникационные примитивы делятся на блокирующие (синхронные) и неблокирующие (асинхронные).

При использовании блокирующего примитива send процесс, выдавший запрос на его выполнение, приостанавливается до выдачи сообщения о том, что приёмник получил сообщение, а вызов блокирующего примитива receive приостанавливает выполнение процесса-получателя до получения сообщения. Вот так вот:

При использовании неблокирующих примитивов, управление возвращается процессу немедленно. Для того, чтобы получить информацию о том, что процесс P1 получил сообщение, процесс P2 должен использовать примитив test, чтобы определить. Вот так:

Можно ещё использовать механизм прерываний.