1.6 Сетевое программное обеспечение

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

1.6.1 Иерархия протоколов

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

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

Рис.1-9

Уровень n непосредственно с уровнем n не взаимодействует. Он передает данные нижележащему уровню.

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

Набор уровней и протоколов называется архитектурой сети .

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

Конкретный набор протоколов, используемый на конкретной машине, называется стеком протоколов. Архитектуры сетей, стеки протоколов, сами протоколы - вот основные предметы, рассматриваемые в данном курсе.

Пример рис.1-10.

Пример рис. 1-11.

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

Виртуальное и фактическое взаимодействие; протокол и интерфейс - это принципиально разные сущности.

1.6.2 Основные вопросы организации уровней

1.6.3 Интерфейсы и сервис

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

Активные элементы уровня будем называть активностями. Активности могут быть программными и аппаратными. Активности одного и того же уровня на разных машинах называются равнозначными активностями. Активности уровня n+1 являются пользователями сервиса, создаваемого активностями уровня n, которые называются поставщиками сервиса. Сервис может подразделяться на классы, например, быстрая и дорогостоящая связь или медленная и дешевая.

Доступ к сервису осуществляется через, так называемые, точки доступа к сервису - SAPs ( service access points). Каждая точка доступа к сервису имеет уникальный адрес. Например, телефонная розетка на стене - это точка доступа к сервису АТС. Каждой розетке сопоставлен определенный номер - номер телефона.

Для того чтобы осуществить обмен информации между двумя уровнями надо определить интерфейс между ними. Типичный интерфейс: активность на уровне n+1 передает IDU (Interface Data Unit - интерфейсную единицу данных) активности на уровне n через SAP (рис.1-12). IDU состоит из SDU (Service Data Unit - сервисной единицы данных) и управляющей информации. SDU передается по сети равнозначной сущности, а затем - на уровень n+1. Управляющая информация нужна нижележащему уровню, чтобы правильно передать SDU, но она не является частью передаваемых данных.

Для того чтобы передать SDU по сети нижележащему уровню может потребоваться разбить его на части. Каждая часть снабжается заголовком (header) и передается как самостоятельная единица данных протокола - PDU (Protocol Data Unit - единица данных протокола). Заголовок в PDU используется равнозначной активностью чтобы реализовать равнозначный протокол. Он определяет какой PDU содержит управляющую информацию, а какой данные, порядковый номер и т.д.

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

В старых протоколах это различие не поддерживалось либо поддерживалось не до конца.

1.6.4 Cервис с соединением и сервис без соединения

Уровни могут предоставлять вышележащим два вида сервисов: ориентированный на соединение и без соединения.

Сервис с соединением предполагает, что между получателем и отправителем сначала устанавливается соединение, и только потом доставляется сервис. Пример - телефонная сеть.

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

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

Надежный сервис с соединением имеет две разновидности: последовательность сообщений и поток байтов. В первом случае четко различаются границы каждого сообщения. Если было послано два сообщения по 1МВ, то получено будет два сообщения по 1МВ. Ни при каких условиях у получателя не окажется одно сообщение в 2МВ.

В случае потока байтов, получатель получит 2МВ. У него нет способа распознать, то ли это 2 сообщения по 1МВ, 1 в 2МВ и 2048 по 1 байту.

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

Пример приложения, не требующего соединения, - электронная почта. Вряд ли отправитель второстепенного сообщения захочет ждать установки и разрыва соединения, чтобы передать второстепенное сообщение. Ему вряд ли требуется стопроцентная гарантия доставки , особенно, если это связано с увеличением стоимости. Все, что ему нужно - простой способ передать сообщение, которое с большой вероятностью будет принято, но без всяких гарантий. Ненадежный сервис (т.е. без уведомления) часто называют дейтаграммным (datagramm), по аналогии с телеграммным без уведомления. Однако, для тех приложений, где необходима гарантия доставки даже небольшого сообщения, используется datаgramm сервис с подтверждением, подобно телеграмме с уведомлением о получении.

Другой разновидностью дейтаграммного сервиса является запрос-ответ сервис. Он типичен для взаимодействия между клиентами и сервером.

Рис. 1-13.

1.6.5 Примитивы сервиса

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

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

Рис. 1-14.

Для иллюстрации работы примитивов рассмотрим, как соединение устанавливается и разрывается. Сначала активность выполняет CONNECT.request, в результате чего в сеть выпускается пакет. Получатель получает CONNECT.indication, указывающий на то, что с ним хотят установить соединение. В ответ получатель через примитив CONNECT.response сообщает, готов ли он установить соединение или отказывает в установлении соединения. В результате, активность - инициатор установления соединения получает ответ, чего следует ожидать через примитив CONNECT.confirm.

Большинство примитивов имеет параметры. Параметры примитива CONNECT.request определяют машину соединения, желаемый тип обслуживания и максимальный размер сообщения, допустимый для данного соединения. Параметры примитива CONNECT.indication указывают, кто обратился, желаемый уровень обслуживания, предлагаемый размер сообщений. Если активность, к которой обратились, не согласна, например, с предлагаемым размером сообщений, то она предлагает свой размер через response, который становится известным активности, добивающейся соединения, через примитив confirm. Подробности этих переговоров - существо протокола. Например, в случае конфликта при установлении максимального размера сообщения, протокол может установить, что выбирается наименьший из предложенных. Услуга может быть либо с подтверждением, либо без подтверждения. При услуге с подтверждением, действуют все четыре примитива request, indication, response, confirm. При услуге без подтверждения, используются только два примитива request и indication.

Услуга CONNECT обязательно должна быть с подтверждением. Услуга DATA_TRANSFER может быть как с подтверждением, так и без, в зависимости от того, нужно отправителю уведомление или нет. Оба вида услуг используется в сетях.

Продемонстрируем концепцию услуг на следующем примере простых услуг с соединением со следующими 8-ю примитивами:

  1. CONNECT.request - запрос на установление соединения.
  2. CONNECT.indication - сигнал для удаленной активности.
  3. CONNECT.response - используется удаленной активностью для согласия/несогласия на соединение.
  4. CONNECT.confirm - cообщает активности, инициирующей соединение, принято оно или нет.
  5. DATA.request - запрос на передачу данных.
  6. DATA.indication - сигнал поступления данных.
  7. DISCONNECT.request - запрос на разрыв соединения.
  8. DISCONNECT.indication - сигнал равнозначной активности о запросе.

В этом примере CONNECT - услуга без подтверждения. Продемонстрируем этот пример следующей аналогией.

  1. CONNECT.request - Вы набираете номер друга.
  2. CONNECT.indication - Он слышит звонок.
  3. CONNECT.response - Он берет трубку.
  4. CONNECT.confirm - Вы слышите, что гудки прекратились.
  5. DATA.request - Вы предлагаете ему встретиться.
  6. DATA.indication - Он слышит Ваше приглашение.
  7. DATArequest - Он говорит, что согласен.
  8. DATA.indication - Вы слышите его ответ.
  9. DISCONNECT.request - Он кладет трубку.
  10. DISCONNECT.indication - Вы слышите, что он положил трубку и кладете трубку

На рис. 1-15 показана эта последовательность действий. На этом рисунке Вы и Ваш друг - уровень n+1 - пользователи услуг, а уровень n - телефонная компания - поставщик услуг.

1.6.6 Взаимосвязь услуг и протоколов

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

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