Проектирование и технология электронных средств. № 2, 2004,
УДК 681:324
АНАЛИЗ АЛГОРИТМОВ СЕАНСОВОГО УРОВНЯ МОДЕЛИ ISO/OSI
При решении задач управления сеансом в модели ISO/OSI принципиальное значение имеет выбор способа поддержания соединения, так как от него зависят многие ключевые параметры, в первую очередь безопасность и эффективность прикладных алгоритмов (управление взаимодействием клиента и сервера). Таким образом, большое значение приобретает выбор моделей управления сеансом по некоторым признакам. В статье сделана попытка сравнительного анализа двух наиболее популярных алгоритмов сеансового уровня. Кроме того, рассмотрен ряд аспектов уровня представления данных и прикладного уровня.
Модель ISO/OSI (семиуровневая архитектура открытых систем) разработана на основе концепции взаимодействия процессов пользователей (прикладных процессов) через транспортную сеть с помощью метода обмена сообщениями (рис. 1) [1]. При этом в задачу транспортной сети входит доставка сообщений из одной точки в другую без всякой их интерпретации, а также маскирование механизма доставки сообщений (т. е. сглаживание различных реализаций сегментов сети, или обеспечение прозрачности). Таким образом, в соответствии с концепцией, сеть представляется процессам пользователей однородной, или гомогенной.
Рис.1. Концепция модели ISO/OSI
Модель ISO/OSI (рис.2) является детализацией рассмотренной концепции. Помимо детализации, модель производит упорядочивание процессов по вертикали (интерфейсные взаимодействия) и горизонтали (протокольные взаимодействия).
Рис. 2. Модель ISO/OSI
Рассмотрим основные особенности модели ISO/OSI (далее просто модели). Как видно из рисунка, для ее рассмотрения необходимо наличие как минимум двух систем. На рисунке эти две системы обозначены как система А и система В. Нижние четыре уровня (транспортный - физический) в соответствии с концепцией образуют транспортную сеть, прозрачную для процессов высоких уровней (прикладной – сеансовый). Протоколы для транспортной сети в настоящее время стандартизованы (например, семейство протоколов IP или Х.25). Механизмы взаимодействия процессов в соответствии с этими протоколами хорошо описаны в литературе [1, 4, 5] и в документации по стандартам (RFC и МККТТ), поэтому мы их касаться не будем. Отметим лишь, что протокол транспортного уровня называется сквозным (end-to-end). Процессы именно этого уровня предоставляют в рамках систем единый для всей сети интерфейс (интерфейс транспортного уровня).
Рассмотрим взаимодействие процессов на сеансовом уровне. По определению, основная задача этих процессов состоит в выделении ресурсов, необходимых для проведения сеанса связи между прикладными процессами, расположенными в разных системах (как правило, между клиентским и серверным процессами). Поддержка протоколов сеансового уровня осуществляется операционной системой [4, 5]. При этом выполняются следующие шаги:
1. Идентификация пользователя (установление его уникального имени).
2. Аутентификация (проверка подлинности пользователя).
3. Авторизация (предоставление пользователю соответствующих прав и выделение необходимых для поддержания сеанса ресурсов).
4. Контроль (на протяжении всего сеанса) за корректностью использования ресурсов, а также (при необходимости) ведение статистики взаимодействия процессов-участников сеанса.
Основной трудностью при организации сеанса является решение задачи построения логической звезды процессов (рис. 3), т. е. построение алгоритма взаимного исключения при множественном доступе (МД) процессов к общему ресурсу (серверу) в режиме разделения времени [4, 5]. Эта задача является достаточно сложной даже для сосредоточенных систем с централизованным управлением; в распределенных системах она усложняется, как минимум, на порядок. Целью задачи является устранение конфликта, возникающего при МД, и, как следствие, обеспечение безопасного управления общими ресурсами (ОР). Приведем способы решения задачи взаимного исключения, реализованные в семействе протоколов TCP/IP. (Transport Control Protocol/Internet Protocol).
Рис.3. Звезда обслуживания
Первый способ реализован в протоколе UDP (User Datagram Protocol) (рис. 4). Способ предполагает, что имеется некий централизованный процесс-сервер, обеспечивающий упорядочивание запросов с помощью общей очереди. В этом случае задача разделения ресурса при МД решается достаточно тривиально с помощью монитора Хоора [4]. Недостаток способа состоит в том, что в случае цепочечных запросов (т. е. запросов, состоящих из нескольких связанных команд) серверу необходимо хранить предысторию каждого из своих клиентов, что является достаточно трудной задачей. Тем не менее, способ достаточно широко используется именно в силу простоты решения проблемы МД. Более того, в работе [6] приведен метод, позволяющий организовать хранение предыстории в области памяти клиентских процессов. В этом методе предложено после выполнения каждой элементарной команды посылать клиенту те только данные (результат), но и текущее состояние серверного процесса (контекст). При этом клиент при каждом запросе посылает серверу не только команду с необходимыми данными, но также и сохраненный контекст. Таким образом, сервер как бы возобновляет обслуживание с точки выполнения последней команды клиента. Недостатком метода является невозможность его использования в распределенных телекоммуникационных системах (РТКС) с низкой скоростью передачи данных. Однако, на этот недостаток можно закрыть глаза в силу многократного увеличения быстродействия компьютеров, объема их памяти и возросшими на несколько порядков скоростями передачи даных в РТКС.
Рис. 4. Обслуживание с общей очередью
Следующий способ организации взаимодействия процессов основан на распараллеливании сервера (рис. 5). При этом на серверной машине постоянно присутствует некий порождающий процесс. При каждом подключении нового клиента этот процесс запускает копию сервера так, что у каждого клиента возникает своя очередь запросов. Таким образом, хранение предыстории и сохранение контекста возлагается на операционную систему.
Способ реализован в протоколе TCP/IP. К его вышеперечисленным недостаткам следует отнести также и необходимость решать задачу взаимного исключения. Как правило, эта задача возлагается на операционную систему (ОС) серверной машины. Таким образом, при администрировании РТКС или РИС необходимо обратить внимание прежде всего на ОС сервера.
Рис. 5. Обслуживание с распараллеливанием
. Схема весьма популярна в силу простоты ее реализации, и применяется в широком классе систем «клиент-сервер» (например, в WWW – всемирной паутине. Однако, в силу отсутствия в схеме общей очереди запросов, в ней возникает необходимость решения доступа к общему ресурсу – например, базе данных, и проблемы синхронизации транзакций встают на первый план. Типичная ситуация для таких систем – отказ в обслуживании, когда все время тратится на разрешение конфликта [4,5], или некорректное обслуживание (продажа двух билетов на одно и то же место – система «Сирена»).
Рассмотрим следующий интересующий нас уровень модели ISO/OSI – уровень представления данных (ПД). Если на сеансовом уровне решается задача защиты ресурса от разрушения при МД, то на уровне ПД должна решаться задача шифрации передаваемых данных. Модель ISO/OSI предоставляет такую возможность в силу своей открытости. Если на нижних уровнях модели мы не имеем права на использование нестандартных протоколов (ибо в этом случае разрушится сама РТКС), то на верхних уровнях, помимо общепризнанных стандартов (например, FTP, SMTP, HTTP и так далее) мы имеем право на разработку и использование собственных методов, алгоритмов и процедур управления ресурсами.
Последний, самый высокий уровень модели ISO/OSI – прикладной позволяет нам решать любые задачи с случае, если их невозможно решить с помощью штатных средств ОС. Например, в ОС UNIX и Microsoft Windows задача МД решается с помощью флага блокировки ресурса, что фактически приводит нас к случайным алгоритмам обслуживания со всеми вытекающими негативными последствиями (перегрузка систем, отказ в обслуживании и так далее). Поэтому в безопасных РИС и РТКС необходимо размещать соответствующие алгоритмы (работа с очередями FIFO, HPF, RR и так далее) на прикладном уровне.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Zimmermann H. OSI Reference Model – the ISO Model of Architecture for Open Systems Interconnection. IEEE mun.,1980, V 28, N 4, p. 425-432.
2. , , . Локальные микропроцессорные вычислительные сети. М.: Наука, 1984, 176с.
3. , . Микропроцессорные системы. М.: Наука, 1980, 236с.
4. Д. Цикритзис, Ф. Бернстайн. Операционные системы. М., Мир, 1977, 336 с.
5. Д. Донован. Системное программирование. М:, Мир, 1975, 540 с.
6. , , . Организация множественного доступа к файлам в локальной вычислительной сети. В кн.: Программное обеспечение ЭВМ. Базовое программное обеспечение и программное обеспечение сетей и систем телеобработки. Материалы Международной научно-технической конференции «Программное обеспечение ЭВМ». Калинин, НПО «Центрпрограммсистем», 1984, с.61-64.
