Главная » Мануалы

1 ... 22 23 24 25 26 27 28 ... 32

О-фактический поток данных

,0-концептуальный noTJOK данных ПБД Протокольный блок данных

Система 1

Система 2

Буферы кадров/ содержащие ПБД

Рис. 6.7. Схема взаимодействия равноправных модулей в подсистеме СОММ, расположенных в различных узлах сети.

дящему информационному потоку управляющего модуля обмена сообщениями. Что же касается протокола установления связи, то он никак не затрагивает процесс обмена сообщениями, а имеет свои собственные автономные функции, выполнение которых приводит к формированию и восприятию специальных ПБД.

Условные обозначения:

Теперь, приняв во внимание все вышеперечисленные соображения, мы можем продолжить проектирование нашей системы.

6.5. Рабочее проектирование подсистемы СОММ

В этом разделе мы проработаем детали проекта подсистемы СОММ на основе идей и решений, принятых в разд. 6.4. Сначала рассмотрим поток данных, а затем перейдел1 к синтезу структуры и внутренней логики подсистемы.

S.5.I. Информационный поток

На рис, 6.8 представлена схема, иллюстрируюшая в информационном аспекте основные решения (как явные так и неявные), принятые в качестве отправных для более детального проектирования системы. При этом модули Е, М и F полностью соответствуют иерархической многоуровневой структуре, изображенной на рис. 6.3, б, с той лишь разницей, что модуль М реализуется без использования задач, поскольку он является пассивным связуюшим звеном. Модуль Р служит драйвером ввода-вывода, и поэтому для выполнения присущих ему функций требуются две задачи, осушествляюшие ввод и вывод данных. На рис. 6.8 уже показаны некоторые структурные элементы системы (пакеты и задачи), однако подробное обсуждение механизма их взаимодействия мы проведем несколько позже. Единственным важным недостаюш,им элементом на этом рисунке является способ выдачи локального разрешения на обмен данными, реализуемый в интерфейсах M/F и F/P.

Интерфейс систем DIALOGUE и COMM. В соответствии с результатами обсуждения, приведенными в подразд. 6.4.1, предполагается, что при взаимодействии систем DIALOGUE и СОММ в оперативной памяти имеются постоянно выделенные буферы для передачи и приема сообшений, а выдача разрешения на обмен сообщениями организована в рамках интерфейса DIALOGUE/COMM путем предоставления свободных буферов.

Модуль дешифратора событий. Правила управления потоком буферов сообщений, иллюстрируемые рис. 6.8, можно кратко сформулировать следующим образом:

При начальном запуске системы модуль Е предоставляет свободный буфер модулю М для приема сообщений; затем после приема каждого сообщения и последующего освобождения экрана дисплея оператором модуль Е возвращает этот буфер модулю М.

Условные обозначения;

О-*- заполненные буферы О-свободные буферы

физическое

г копирование данных управляющие буферы

Смешанный поток \

, /FIX \ PRX

atj zip

Отвергнутые

сообщения >Р Пул

.VcTBowj Т

(из-за превышеиип/ кедровых размера окна!/ буферов

информационных \л\-

управляющих :1ссыяки]

входящий н исходящий потоки символов

Рис. 6.8. Общая схема взаимодействий системы DIALOGUE с подсистемой COMM.

При нажатии оператором клавиши SEND модуль Е пересылает заполненный буфер модулю М для передачи по линии связи; после того как модуль М скопировал сообщение в буферные блоки обмена кадрами, он возвращает исходный буфер модулю Е для повторного использования.

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

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

С точки зрения оператора модуль Е расширяет возможности получения кредита на передачу информации: когда оператор запрашивает разрешение, нажимая клавишу RESERVE (РЕЗЕРВИРОВАНИЕ), то, начиная с этого момента (при условии, что буфер ТХ свободен), экран становится доступным ему для ввода сообщения; когда оператор нажимает клавишу SEND (ПЕРЕСЫЛКА), модуль Е блокирует выдачу соответствующего разрешен]1Я до тех пор, пока вновь не освободится буфер ТХ.

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

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

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

модуль М получает буфер ТХ, заполненный сообщением, поступившим от модуля Е в момент времени, определяемый Е;

модуль М возвращает освободившийся буфер модулю Е после копирования сообщения в буферные блоки для передачи;

= модуль М получает свободный буфер RX для приема сообщений при начальном запуске системы;

после того как произведено копирование последнего кадра поступившего сообщения в буфер RX модуль М направляет его модулю Е;

. в момент времени, определяемый модулем Е, освободившийся буфер RX поступает обратно из Е в модуль М;

модуль М направляет кадры, заполненные данными, модулю F только при получении от F разрешения па передачу в форме предоставления свободного буфера ТХ;

кадры, заполненные данными, поступают в модуль М из F тогда, когда эти кадры доступны, и модуль М готов к их приему.

Управляющий модуль логического обмена кадрами данных.

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

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

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

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

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

6.5.2. Структура и логика системы

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

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

Модифицированный интерфейс систем. Исходную схему модуля дешифратора событий системы DIALOGUE, изображенную на рис. 4.31 и 4.32, теперь следует изменить с учетом ранее не рассматривавшихся возможностей буферизации данных и условий управления информационным потоком. Новая схема приведена на рис. 6.9. Ввиду того что вызов процедуры SEND из пакета М влечет за собой для инициатора вызова потенциально большое условное время ожидания конца копирования всего сообщения в буферные блоки, между модулем дешифратора событий и данной процедурой необходимо ввести как промежуточный уровень задачу ЕТХ, осуществляющую транспортировку информации при передаче. Ранее задача, выполнявшая аналогичную функцию при приеме, была обозначена как ERX.

Вышеупомянутый вход PUT MSG (ПОМЕСТИТЬ СО-ОБЩЕНИЕ) дешифратора событий (Е) получает теперь имя PUT. Он обеспечивает передачу входных сообщений без временных задержек. Три новых входа задачи Е указывают на точки синхронизации, в которых задачи ЕТХ и ERX, осуществляющие перенос данных, могут ожидать исходящего сообщения (вход GET), уведомлять о завершении передачи сообщения с одновременным возвратом освободившегося буфера ТХ (вход RETURN) и захватывать освобожденный буфер RX (вход PICKUP).

Задача Е предоставляет свободный буфер модулю М при начальном запуске системы через вход PICKUP и сразу после освобождения оператором буфера RX, который содержал выданное на экран сообщение.

В теле задачи ЕТХ реализуется цикл, в котором ожидание сообщения осуществляется путем вызова входа E.GET, посылка сообщения - путем обращения к входу M.SEND, а получение уведомления о завершении передачи и возврат освободившегося буфера - путем вызова Е.RETURN.

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

Поток символов, считываемых

с клавиатуры Задача дешифратора событий Е

~Jl <:г^ RETURNy PUT ?\Q.K\j? I I

д закрыт, Q\ 3 не будет Л

Вход Пока

заполненного буфера ТХ

Вход закрыт до тех лор, пока не будет свободного буфера RX

I ЕТХ I I ERX J

ol. i fo DIALOGUE

\\X \\ \ Задачи-курьеры

SEND

COMM

Вызывающий модуль вызывающий ожидает завершения

копирования сообщения--;-ожидает

в буферы кадров; сообщения

по окснчании передачи осуществляется возврат освободившегося буфера

Активный управляющий пакет обмена сообщениями h\

Рис. 6.9. Модифицированная структура интерфейса DIALOGUE/COMM.

буфера и ожидание окончания его заполнения поступившим со< обшением - путем вызова E.RCVE, а последующая передача сообщения -- путем вызова входа E.PUT,

Модифицированный модуль дешифратора событий в диалоговой системе. Рис. 6.10 в целом иллюстрирует усовершенствованную схему работы задачи Е, причем на рис. 6.10, а изображен модифицированный конечный автомат, управляющий ее функционированием, а на рис. 6.10,6 представлена соответствующая программа на языке Ада. Новые возможности этого автомата получены путем добавления двух дополнительных состояний: READY TO SEND (ГОТОВНОСТЬ К-ПЕРЕСЫЛ-КЕ) и SENDING (ПЕРЕСЫЛКА),), а также двух вспомогательных переменных: IN MSG (ВХОДЯЩЕЕ-СООБЩЕНИЕ) и RX DONE (БУФЕР РХ СВОБОДЕН). Состояние READY

Условные обозначения:

О * заполненные буферы

р >~ свободные буферы

:TO SEND обеспечивает выполнение условий защиты оператора приема, принадлежащего входу GET (который открыт только в этом состоянии). В состоянии SENDING активизируются средства, которые позволяют заблокировать поток символов от оператора в буфер ТХ до момента, когда последний освободится. До того как это произойдет, невозможен переход в состояние IDLE, являющееся единственным состоянием конечного автомата, в котором действия оператора не зависят от состояния буферов ТХ. Переменная IN MSG используется для того, чтобы регистрировать факт наличия сообщения после вызова входа PUT; эти вызовы могут быть приняты в любом состоянии конечного автомата, но смена состояний реализуется только в одном из них (IDLE). Иными словами, роль переменной Ш MSG заключается в регистрации факта обращения к входу PUT, с тем чтобы при наступлении других событий могли быть

Прием вькювэ PUT Нажатие

любой клавиши

Прием вьгзова RETURN

при IN MSG = FALSE

Прием . вызова PUT

Освобождение при IN MSG = TRUE

Резервироранме

(а} Конечный автомат.

task EVENT DECODER is entry PUT STROKE (К : in ...); --НАЖАТИЕ КЛАВИШИ (ОЖИДАНИЕ ОТСУТСТВУЕТ), entry GEK ...);-- УСЛОВНОЕ ОЖИДАНИЕ ИСХОДЯЩЕГО СООБЩЕНИЯ entry PUT(...);-- ВХОДЯЩЕЕ СООБЩЕНИЕ (БЕЗ ОЖИДАНИЯ) entry RETURN(..,); - ВОЗВРАТ ОСВОБОДИВШЕГОСЯ БУФЕРА (БЕЗ ОЖИДАНИЯ) entry PICKUPf.,.); -- УСЛОВНОЕ ОЖИДАНИЕ СВОБОДНОГО БУФЕРА СООБЩЕНИЙ

md EVENT DECODER; щьнии

tasic body EVENT DECODER is

type STATE is (IDLE, BUSY LOCAL, BUSY: REMOTE, READY,:.TO SEND, SENDING); S ; STATE : = IDLE;

IN MSG, RX DONE : BOOLEAN : = FALSE;

begin loop select

accept PUT STROKE (K ; ,); do- .

If К = RELEASE and IN MSG trten IN MSG ! = FALSE; SCREEN.SWITCH; end if; case S is when IDLE = > if К = RESERVE then S ; = BUSY LOCAL; else RINGBELL; end if; when BUSY LOCAL = > case К Is when RELEASE = > if not IN MSG then S ; = IDLE; SCREEN.CLEAR; elseif IN MSG then S : = BUSY REMOTR SCREEN.SWITCH; end if; when SEND = >

S : = READY TO SEND; when in LEGAL CHAR = >

SCREEN.WRITE (K; when OTHERS = >

RING BELL! end case; when BUSY REMOTE = > if К = RELEASE then S : = IDLE; SCREEN.CLEAR; RX DONE : = TRUE; else RING BELL; end if; end case; end;

I6j Скелет Ада-программы.

accept PUTiM :...); do , IN MSG : = TRUE; if S = IDLE or S = SENOINe then

SCREEN.SWITCH; end if; if S = IDLE then S : = BUSY. REMOTE; 9nd If; end;

when RX DONE = > accept PICKUP (. ); do

GIVE EMPTY BUFFER; IN MSG : = FALSE; RX DONE : = FALSE; end;

When S = SENDING = > accept RETURN (M :.,.); do

if not IN MSG then S ; = IDLE; elseif IN MSG then S : = BUSY REMOTE; end if; end; end select; end loop; end EVENT DECODER;

(6) Скелет Ада-программы (продолжение!.

Рис. 6.10. Схема функционирования модифицированного модуля дешифратора событий. (Примечание. 1. События, инициируемые оператором путем нажатия клавиш, подчеркнуты. 2. Логическая переменная IN-MSG указывает, можно ли вывести на экран дисплея сообщение из буфера RX, или оно уже было выведено. 3. Нажатие клавиши RELEASE вызывает возврат свободного буфера (если он есть) модулю М независимо от состояния, в котором он находится.)

произведены соответствующие изменения состояний. Вызовы входа PUT допускаются в любом состоянии, поскольку разрешение модулю М на прием информации выдается задачей Е путем предоставления свободного буфера; поэтому отсутствует необходимость в регулировании потока данных, поступающих в буфер RX, посредством установки предохранителя (guard) на входе PUT, как это было сделано выше при проектировании диалоговой системы в ее исходном варианте. Переменная RX DONE используется в качестве предохранителя на входе PICKUP: в любом состоянии системы при нажатии клавиши RELEASE переменная RX DONE принимает значение TRUE ИСТИНА) при условии, что IN MSQ принимает такое же

1 ... 22 23 24 25 26 27 28 ... 32