|
| |
 |
Главная » Мануалы 1 ... 25 26 27 28 29 30 31 32 Глава 7 Логическое проектирование многоуровневых систем: пример с применением протокола информационного обмена X. 25 7.1. Введение в данной главе мы рассмотрим решение задачи нроектирования многоуровневых систем, используя для примера многоуровневые протоколы обмена. Для большей определенности будет рассмотрен трехуровневый протокол X. 25 Международного консультативного комитета по телеграфной и телефонной связи, однако при этом подразумевается, что используемые методы применимы к многоуровневым системам различного типа. Особый интерес представляют системы, реализующие семиуровневую модель взаимодействия открытых систем, предложенную Международной организацией по стандартизации. Из трех уровней протокола обмена Х.25 в этой главе будет рассмотрен только верхний уровень 3 (так называемый сетевой уровень). Уровень 2 этого протокола {канальный) является более сложной версией протокола управления логическим обменом кадрами данных, используемого в подсистеме СОММ (см. гл. 6). Этот протокол линий связи называется высокоуровневым протоколом управления каналом передачи данных High-Level Data Link Control (HDLC). Появившееся в нем усложнение может быть скрыто в теле пакета, реализующего канальный уровень протокола; тогда его спецификация будет полностью аналогична спецификации управляющего пакета логического обмена кадрами данных, описанного в гл. 6. Общая внутренняя структура этого пакета вполне подходит для наших целей, требуется изменить лишь некоторые детали. Однако мы не станем вдаваться в подробности проектирования такого пакета, а будем предполагать, что он уже существует. Наша основная цель в данной главе,- используя протокол Х.25 в качестве примера, показать, как вышеописанная методология проектирования может быть применена при разработке систем с многоуровневой структурой, отражающих реальные сложные проблемы. В нашу зарачу не входят ни детальное рассмотрение протокола X.25, ни встесторонняя разработка системы, реализующей его функции. На каждом этапе проектирования будут вводиться в рассмотрение только те аспекты протокола Х.25, которые, безусловно, необходимы для принятия конкретных решений; процесс разработки будет обрываться в ТОТ момент, когда полученная структура оказывается ясно и однозначно объяснимой с помощью рисунков и на словах. При работе над реальным проектом, перед тем как приступить к рассмотрению деталей и написанию программ, необходимо провести анализ основных принятых проектных решений. Принимая во внимание иные цели данной главы, мы не приводим здесь примеров программ, полагаясь на то, что в предыдущих главах уже было показано, как идеи, выраженные в форме структурного графа, могут воплощаться в программы. Для читателей, не знакомых со структурой пакета Х.25, в разд. 7.2 дается его краткое описание, достаточное для понимания материала этой главы. В разд. 7.3 разрабатывается программный пакет, реализующий сетевой уровень обмена данными с использованием протокола X. 25, разд. 7.4 содержит заключительные замечания к проекту, в разд. 7.5 рассмотрены возможные подходы к созданию более сложных многоуровневых протоколов, требуемых при организации взаимодействия открытых систем, разд. 7.6 завершает гл. 7, часть П1 и всю книгу. 7.2. Основные особенности протокола Х.25 Протокол х.25 предоставляет абонентам возможность создания множества виртуальных каналов связи с удаленными системами и обмена пакетами данных по этим каналам. Виртуальный канал представляет собой логический маршрут информационного обмена, который вместе с другими виртуальными каналами может быть подсоединен к общедоступной сети передачи данных с помощью одной физической линии связи. Для каждой линии связи имеется заранее определенное множество номеров, используемых как абонентами, так и в сети для идентификации конкретных виртуальных каналов обмена, упакованных в данную физическую линию. Входящие и исходящие пакеты содержат номер соответствующего виртуального канала. На практике протокол Х.25 реализуется специальным управляющим модулем, имеющимся в каждой системе. Однако при этом технические требования, вытекающие нз спецификации протокола Х.25, не навязывают какой-либо строго определенной структуры модуля. Спецификация этого протокола иг.1еет отношение только к движению потоков данных между различными взаимодействующими системами. Поэтому она определяет правила форматирования и упорядочения, а также функциональные возможности протокольных блоков данных (ПБД). Прн использовании протокола Х.25 ПБД, применяемые на сетевом уровне, называются пакетами, а на канальном - кадрами.  О Условные обозначения: и абонент, X модуль, реализующий протокол Х.25, L локальный сетевой интерфейс. Рис. 7.1. Логическое представление виртуальных каналов, управляемых протО' колом Х.25. Рис. 7.1 иллюстрирует характер применения протокола Х.25. Управляющие программы протокола передачи данных обеспечивают (модулям одного абонента) возможность создавать виртуальные каналы обмена, связываюн1ие их с модулями другого, удаленного абонента. Основные цели введения сетевого и канального уровней формулируются следующим образом: 1. Канальный уровень обеспечивает безошибочную, упорядоченную требуемым образом передачу кадров по единственному физическому каналу (управляемую потоком информации). На этом уровне осуществляется также включение и выключение линии. 2. Сетевой уровень в свою очередь обеспечивает безошибочную, упорядоченную, управляемую потоком информации передачу пакетов по каждому из виртуальных каналов Кроме того, на этом уровне реализуются запросы на установление виртуальных каналов связи между двумя абонентами и их ликвидация. Хотя иллюстрируемые на рис. 7.1 понятия, используемые в протоколе Х.25, в основном касаются взаимодействия пользовательских модулей посредством виртуальных каналов, многие из требований протокола связаны с организацией внутреннего интерфейса сети, т. е. обмен между абонентами не является сквозным. Однако запросы на установление и разъединение канальных соединений, а также ответы на них реализуются путем сквозных передач, и, следовательно, рассматриваемое соединение по своему характеру является сквозным. Структура системы, реализующей протокол X. 25, не зависит от того, будут ли некоторые из взаимодействий сквозными, но на функционирование верхних уровней это может оказать влияние. Управление единственным виртуальным каналом обмена на сетевом уровне в логическом смысле очень похоже на управление единственной линией связи на канальном уровне. Виртуальные каналы обмена и линии связи являются коммуникационными соединениями, которые могут быть открыты или закрыты по желанию. Поэтому опыт, приобретенный нами в гл. 6 во время проектирования управляющего пакета логического обмена кадрами по единственной лин.ии связи, будет использован при создании управляющих программ для каждого виртуального канала обмена на сетевом уровне. Ниже перечислены основные дополнительные возможности, предоставляемые сетевым уровнем обмена, которые нам понадобятся в дальнейшем: наличие большого числа виртуальных каналов, которыми необходимо управлять; динамический характер функционирования виртуальных каналов (число активных каналов изменяется во времени); мультиплексирование активных виртуальных каналов с помощью единственного физического канала, реализующего нижний уровень информационного обмена. Данные абонента, а также управляющая информация, используемая при обмене на сетевом уровне, передаются пакетами, длина которых обычно колеблется между 128 и 256 байт. Управляющая информация пакета, например номер используемого виртуального канала, тип пакета, номер пакета, передаваемого по данному каналу, и т. п., содержится в его заголовке. Канальная управляющая информация - исходящие и входящие номера, а также код проверочной суммы - образует заголовок и концевик кадра. Спецификация пакета Х.25 стандартизует следующие виды информации: типы и форматы пакетов; возможные состояния виртуальных каналов (например, свободен, запрос на соединение, передача данных, разъединение); требуемые изменения состояний при приеме пакета, по истечении некоторого заданного интервала времени и т. п.; пакеты, необходимость передачи которых вызвана изменением состояний. Многочисленные детали усложняют обсуждение структуры этой информации, но основные принципы ее формирования знакомы нам по предыдущим примерам, рассмотренным в гл. 4-6. Таблца 7.1. Типы и назначение абонентских пакетов, реализующих подмножество функций протокола X. 25
Этими соображениями вызвано использование конечных автоматов при проектировании модулей, управляющих упорядочением событий. При модульном проектировании технические подробности, связанные со спецификацией протокола Х.25, оказывают влияние только на детали схемы конечного автомата. Для наших целей вполне достаточно будет определить типы и назначение используемых пакетов обмена. В табл. 7.1 эта информация приведена для некоторого подмножества функций протокола Х.25. 7.3. Разработка проекта многоуровневой системы С протоколом Х.25 в соответствии с общими концепциями и результатами, рассмотренными в гл. 6, было бы вполне естественным программу, реализующую протокол Х.25, разбить на уровни. Прием запроса Ожидание запроса Отказ от запроса Передача Прием Функции управления Пакет управления сетевым уровнем обмена с использованием протокола Х.25 Передача Прием Функции управления Пакет управления канальным уровнем обмена Рис, 7.2. Характер внешних интерфейсов пакетов, реализующих протокол Х.25. соответствующие уровням протокола, и реализовать каледый из них с помощью активного пакета, как показано на рис. 7.2. Описание параметров и условии ожидания событий, представленных на этом рисунке, будет дано в подразд. 7.3.2 в соответствии со структурой внутреннего потока данных на сетевом уровне (обмен пакетами), проектируемой ниже. 7.3.1. Проектирование внутреннего потока данных на сетевом уровне Используя опыт создания систем BANK, (гл. 3 и 5), AGENT-POOL (гл. 5) и СОММ (гл. 6), можно сразу приступить к фазе проектирования потока данных, причем способ определения требуемой созокупиостн основных внутренних задач будет основываться непосредственно на результатах примеров. После этого мы рассмотрим вопросы маршрутизации межзадачных пакетов и управления потоками данных. На рис. 7.3 схематически изображены внутренние задачи пакета, реализующего сетевой уровень обмена, и информационные потоки между ними. Многие из проектных решений, неявно отраженных на этом рисунке, знакомы нам по предыдущим примерам. В частности, необходимость использования задач, реализующих функции управления несколькими виртуальными каналами (УВК), и задачи, осуществляющей функции диспетчера, естественным образом следует нз примеров подснстем BANK и AGENT-POOL. С самого начала мы увидим, что  У Задача у DISPATCHER / УстановлениЕ / канального соединс.ЖЯ / Разъединение / канального ..... соединения Прием запроса Стандартная задача управления   Буфер ТХ обмы Кадр данных Кадр данных Рис. 7.3, Информационный поток на сетевом уровне, Указывает условие регулирования потока или столкновения запросов в виртуальном канале Пакеты данных, OTBeprHytbte при Приеме в результате регулирования потока в данном виртуальном канале Входящие пакеты с запросам/т, отвергнутые при приеме / вследствие конфликта / в сети применение структуры такого типа имеет большое практическое значение. Здесь, так же как и в примерах, рассмотренных ранее, каждой задаче пула присваивается свой постоянный номер, полностью ее идентифицируюший, В данном случае указанный номер определяет виртуальный канал, управляемый соответствуюшей задачей. Задача-диспетчер, представленная на рис. 7.3, имеет несколько более широкий набор функций по сравнению с управ-ляюшими модулями, рассмотренны.ми ранее, поскольку теперь запросы на организацию виртуальных каналов могут исходить не только от абонентов системы, но и от сети. Диспетчер следит за состоянием задач УВК (свободны или заняты) и выделяет их абонентам в ответ на входящие или исходящие запросы на соединение. Каждая из задач УВК осуществляет обмен пакетами по соответствующему виртуальному каналу как при реализации функций управления (установление и разъединение канальных соединений), так и при передаче информации. Необходимость их взаимодействия с задачей-диспетчером может быть вызвана либо регистрацией поступающих вызовов, либо сообщением о том, что после разъединения задача свободна, либо получением адресов абонентов, указанных в исходящих запросах. В других случаях задачи УВК взаимодействуют с абонентами через задачи ROUTER IN и BUFFER-OUT. Каждой задаче УВК соответствует постоянный номер обслуживаемого ею виртуального канала, который хранится в локальной переменной и передается в случае необходимости диспетчеру или абонентам. Наличие такого номера дает им всем возможность взаимодействовать с данной задачей. Одним из важнейших проектных решений, не отраженным непосредственно на рис. 7.3, является то, что задачи УВК могут взаимодействовать с другими задачами, пока соответствующие им каналы разъединены. Такое решение позволяет им непосредственно обрабатывать входящие пакеты, благодаря чему схема потока данных, изображенная на рис. 7.3, оказывается понятной и простой. На рис. 7.3 показана также единственная задача, осуществляющая транспортировку информации при приеме. Эта задача имеет название ROUTER-IN (ВХОДНОИ-ТРАССИРОВ-ЩИК), поскольку в ее функции входят выбор маршрута (трассы) и доставка поступающих пакетов соответствующим задачам (УВК). Обслуживание нескольких задач УВК может осуществляться одной подобной задачей, поскольку существует единственный способ организации ожидания входящих информационных пакетов - с помощью процедуры RCVE программного пакета, реализующего канальный уровень обмена. Доставка входящих пакетов соответствующей задаче УВК выполняется задачей R0UTER IN. В том случае, когда задача УВК не может их принять, управление сразу возвращается задаче ROUTER IN, которая просто отвергает эти пакеты. Регулирование информационного потока--не единственная причина того, что задача УВК не в состоянии принять входящие пакеты. Дополнительной причиной служит так называемое столкновение запросов, т. е. ситуация, когда один и тот же номер виртуального канала появляется одновременно в па- кетах, соответствующих исходящему и входящему запросам на обмен. Для этого случая в протоколе Х.25 принято правило, согласно которому более высокий приоритет имеет исходящий запрос, а входящий игнорируется. В соответствии с этим правилом при столкновении запросов задача ROUTER IN просто отвергает входящие пакеты. В протоколе Х.25 термин столкновение запросов относится к пакетам, прием и передача которых осуществляются в данный момент. Попытка абонента переслать запрос на обмен данными посредством задачи УВК, которая к тому моменту уже приняла входящий запрос, не приводит в рамках этого протокола к столкновению, поскольку пакет с исходящим запросом просто не был послан, а следовательно, он и не будет принят. Предназначенные для приема по виртуальному каналу пакеты в момент отказа от их приема могут находиться еще в модуле управления канальным уровнем обмена. При необходимости регулирования информационного потока до того, как эти пакеты будут восприняты задачей ROUTER IN, осуществится их пересылка (наверняка неправильно) соответствующей задаче УВК. Однако, согласно требованиям протокола Х.25, пакеты будут отвергнуты в этом месте вследствие разрыва в последовательности порядковых номеров, вызванного тем, что в первый раз пакеты не были приняты. На рис. 7.3 схематически изображена также задача ROU-TER OUT (ВЫХОДНОЙ ТРАССИРОВЩИК), осуществляющая транспортировку пакетов. Для обслуживания нескольких задач УВК требуется только одна такая задача при условии, что, кроме нее (как показано на рисунке), существует еще промежуточная задача BUFFER OUT, с помощью которой буферизуются пакеты данных, поступающие из всех задач УВК. Задача ROUTER OUT осуществляет передачу пакетов по каналу связи после получения разрешения на обмен в форме выделенного буфера для кадров ТХ. До тех пор пока такое разрешение не получено, исходящие пакеты накапливаются задачей BUFFER OUT; возможное количество их при этом определяется емкостью буфера. Если эта емкость равна сумме величин, каждая из которых определяется окном регулирования потока данных при передаче, осуществляемой соответствующей задачей УВК, то этим задачам не требуется получать локальное разрешение на обмен в форме буфера ТХ. Вышеописанный механизм вполне согласуется со способом предоставления разрешения на обмен, реализованным в управляющем пакете логического обмена кадрами, который был описан в гл. 6. Однако это противоречит исходным предпосылкам, приведенным в предыдущих главах для обоснования указанного способа. Напомним, что упомянутые предпосылки были введены для того, чтобы избежать выделения 6y4f~poB для передачи тех сообщений, которые не могут быть отправлены немедленно. Это противоречие не возникало в гл. 6, поскольку там не использовалось мультиплексирование для реализации мнол<ества логических соединений с.помощью одного физического канала, как мы это делаем в данной главе. Здесь указанное противоречие неизбежно, так как невозможно заранее правильно организовать совместное исиользование буфера ТХ, являющегося разрешением на обмен, отдельными виртуальными каналами. 7.3.2. Проектирование внутренней структуры сетевого уровня обмена В предыдущем разделе уже были определены внутренние задачи и потоки данных, которые должны быть реализованы на сетевом уровне, поэтому в данном подразделе нашей основной целью будет рассмотрение структуры взаимодействий и исследование функциональных возможностей. Большинство из затрагиваемых вопросов уже обсуждалось в предыдущих главах. Внутренняя структура может быть частично определена при рассмотрении деталей интерфейса, опущенных на рис. 7.2. Более полный граф, описывающий структуру взаимодействий, показан на рис. 7.4. По поводу процедур изображенного на рис. 7.4 пакета, реализующего сетевой уровень обмена, необходимо сделать ряд важных замечаний: При возврате управления из процедуры WAIT FOR CALL один из параметров содержит номер уже подсоединенного виртуального канала. В случае если поступление запроса не ожидается (на что указывает параметр, содержащий адрес абонента), соответствующей реакцией будет немедленное исиользование процедуры CLEAR. Для простоты процедура SEND определяется как процедура, в которой обслуживание производится без задержки на ожидание (в предположении, что соответствующие входы внутренних задач не защищены предохранителями). У процедуры SEND отсутствует параметр, значение которого могло бы служить разрешением на выполнение обмена. Сообщением о необходимости регулирования потока служит значение параметра, описывающего состояние системы после попытки обращения к этой процедуре. 1 ... 25 26 27 28 29 30 31 32 |