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

1 ... 26 27 28 29 30 31 32

<

WAIT CALL

IS- i 1

9 m

PLACE

CALL -V~

CLEAR

si is

RCVC

Функции упрааленип системой

Ожмдэиие Ожидание \ отсутствует отсутствует

0>кидан;ие Ожидзние посгуплекип освобождения ВК запросов и освобождения

Сетевой уровень обмена

Ожидание поступления пакегоа данных г.ри установленном соединении)

с: а

Функции управлении системой

Ожидание получения разрешенная на передачу

Ожидание поступления кадрое данных

Канальный уровень обмена

Рис. 7.4. Конкретизироваппые интерфейсы пакетов, реализующих протокол Х25,

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

Читатель должен четко различать два возможных значения слова вызов, как, например, в предложении: Абонент вызывает процедуру WAIT FOR CALL, реализующую ожидание поступления вызова от другого абонента . В первом случае речь идет об обращении, а во второ.м - о запросе; как и понятие совмещения процедур в языке Ада, конкретное значение слова вызов становится очевидным из контекста.

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

Представленный на рис. 7.5 граф внутренней структуры системы естественным образом вытекает из

схемы интерфейса, изображенной на рис. 7.4;

графа потоков данных, который приведен на рис. 7.3;

стремления к исиользованию линейных структур взаимо действий задач;



Адрес 1 а, абонента ts] I

i 1 Адрес , i ф абонента

Номер ВК

\ Параметр состояния

Номер

Q Нок } ВК

Номер Б К 9 Пакет J Номеп ВК

Параметр состояния \ Пакет

WAIT P0R CALL

PLACE CALL

CUAR

Необслу- . женных

Разъединение ВК или выделение ВК согласно поступившему запросу от абонента .


Соединение установлено, но пакет не поступает

Рис. 7.5, Внутренняя структура пакета, реализующего сетевой уровень обмена.

результатов проектирования системы AGENT POOL; основополагаюидего проектного решения, согласно которому освободившиеся задачи УВК не ожидают того момента, когда диспетчер выделит им для обслуживания виртуальные каналы, а сразу же с переходом в состояние FREE (СВОБОДЕН) реализуют ожидание вызовов по своим входам.

Номера виртуальных каналов определяют одновременно как виртуальные каналы, так и соответствующие им управляющие задачи.

Формулирование на языке Ада спецификаций интерфейсов, необходимых различным задачам, схематически изображенным



на рис. 7.5, мы оставляем читателю, так как на этом этапе не нужно привлекать никаких новых концепций.

Ниже кратко будут описаны функциональные возможности каждой из уже рассмотренных задач, а также способы их взаимодействий.

Задача DISPATCHER. Диспетчер распределяет свободные задачи менаду абонентами следующим образом:

при поступлении запросов он возвращает выделенный номер виртуального канала в качестве выходного параметра обращения к входу WAIT FOR-CALL; этот номер указывает на задачу УВК, которая осуществила прием запроса и обратилась к входу REPORT (если ни один из абонентов не ожидает по входу WAIT FOR CALL поступления запроса, то задача УВК, вызвавшая вход REPORT, оповещается об этом путем возврата соответствующего значения параметра состояния системы, в соответствии с которым она отвергнет запрос);

при локальных запросах диспетчер возвращает вызывающему модулю свободный номер ВК в качестве выходного параметра обращения к входу PLACE CALL; вызывающий модуль (которым является процедура пакета PLACE CALL) имеет возможность обратиться по этому номеру к свободной задаче УВК и передать ей запрос, вызвав вход CONNECT.

Задачи, реализующие функции управления виртуальными каналами (УВК). Задачи УВК (VCM) реализуют все детали взаимодействий, обеспечиваемых виртуальными каналами. Управляющая задача виртуального канала во многом аналогична задаче FS, выполняющей сервисные функции (напомним, что эта задача принадлежит управляющему пакету логического обмена кадрами, используемому в подсистеме СОММ). Фактически новыми важными воиросами, возникшими в связи с использованием задач VCM, являются их распределение между абонентами и организация доступа к ним. Их индивидуальное проектирование не представляет трудностей и не порождает никаких новых проблем. Каждая задача VCM внутренне должна быть структурирована точно так же, как задача FS, на основе протокола равноправного обмена, который реализуется пассивным пакетом, включающим задачи FSM сетевого уровня обмена.

Управление запросами. Процедура PLACE-CALL вначале вызывает вход PLACE-CALL задачи-дисиетчера для того, чтобы получить номер виртуального канала. Затем она обращается к входу CONNECT соответствующей задачи VCM и передает ей адрес требуемого абонента. В случае если непосредственно перед этим данная задача VCM приняла запрос на



установление соединения, при возврате управления из оиератора приема CONNECT параметр, описывающий состояние, будет указывать на то, что канал больше не доступен. Если же канал доступен, процедура PLACE CALL обратится к выходу WArr; тем временем задача VCM отправит пакет, содержащий запрос на установление соединения. Как только этот пакет будет передан по каналу путем обращения к входу PUT, будет выполнен оператор приема, принадлежащий входу WAIT, и абонент получит возможность использовать виртуальный канал для обмена данными.

Свободная задача VCM, получив ио входу PUT пакет, содержащий запрос на установление соединения, передает его и уведомляет диспетчера о поступлении запроса (путем вызова входа REPORT). Если требуемый абонент отсутствует, то при возврате из процедуры REPORT задаче посылается уведомление об этом путем передачи соответствующего значения параметра состояния системы, которое позволяет ей отвергнуть запрос. В противном случае диспетчером выполняется оператор приема, принадлежащий входу WAIT FOR-CALL, и абоненту передается адрес отправителя и номер виртуального канала. Если в момент поступления запросного пакета задача VCM занята, он отвергается в соответствии с правилами протокола Х.25, касающимися столкновения запросов.

При поступлении запроса CLEAR (РАЗЪЕДИНИТЬ) от локального абонента задача VCM прекращает передачу информации, пересылает пакет с запросом на разъединение и ожидает поступления подтверждающего сообщения для перехода в состояние FREE. Если пакет с запросом на разъединение поступил от удаленного абонента, эта задача действует аналогичным образом: прекращает передачу информации, пересылает пакет, содержащий подтверждение разъединения, и после этого сразу сообщает диспетчеру о своем свободном состоянии путем вызова входа REPORT. В любом случае, когда задача VCM прекращает передачу данных, все очереди, содержащие информационные пакеты, аннулируются и все входящие пакеты, поступающие на вход PUT, отвергаются до тех пор, пока не будет получен новый запрос на соединение.

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



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

В состоянии передачи данных вызовы входов SEND, PUT и CLEAR принимаются задачей VCM в любой момент времени, вызов же входа RCVE - только в том случае, если очередь на прием не пуста. В результате выполнения оператора приема по некоторому входу задача VCM реализует требуемые операции, корректируя при этом очереди и передавая информационные пакеты, а затем управление возвращается оператору отбора для организации ожидания следующего вызова. В тех случаях, когда длина одной из очередей на повторную передачу или прием достигает максимума, определяемого величиной соответствующего окна, регулирование информационного потока при передаче данных будет осуществляться с вышестоящего уровня, а при приеме - с нижестоящего. Регулирование информационного потока при передаче проводится задачей VCM путем завершения рандеву без выполнения оператора приема SEND, в результате чего очередной пакет отвергается; при возврате из процедуры значение параметра STATUS служит вызывающему модулю указанием на возникновение условий регулирования. Регулирование истока данных при приеме осуществляется аналогичным образом путем прекращения рандеву по входу PUT, в результате чего пакет отвергается (однако управляющие пакеты принимаются в любом случае).

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

Задачи ROUTERlIN, ROUTTER OUT и BUFFER. Задача ROUTER IN ожидает поступления кадров данных, передаваемых пакетом управления канальным уровнем обмена, осуще-



ствляет их декодирование, формирует из них информационный пакет для конкретного виртуального канала и, наконец, вызывает вход PUT соответствующей задачи VCM для передачи этого пакета абоненту. В зависимости от значения параметра STATUS, возвращаемого оператором приема PUT, ио окончании рандеву может возникнуть необходимость отвергнуть пакет (возвратить его в пул свободных буферов кадров); такая ситуация может возникнуть, либо если задача VCM в данный момент осуществляет регулирование входящего информационного потока, либо если в момент поступления пакета, реализующего запрос на установление соединения, задача не находится в сО стоянии FREE.

Задача ROUTER OUT выполняет функции простой транспортировки данных, осуществляя перенос информации за один раз (один пакет) между задачей BUFFER и пакетом LINK при наличии у него разрешения в виде буфера ТХ.

Задача BUFFER реализует функции накопления исходящих пакетов, предназначенных для передачи ио виртуальным каналам.

7.4. Заключительные замечания к проекту

Большинство замечаний, сделанных в гл. 6 при обсуждении проекта подсистемы СОММ, справедливы и в отношении рассматриваемого проекта и их нет нужды повторять.

Проектное решение в том виде, в котором оно отображено на рис. 7.5, возникло после нескольких неудачных попыток упростить сложную внутреннюю логику задачи-дисиетчера путем введения несколько иной структуры системы обмена. При реализации этой структуры требовалось, чтобы пакеты, содержащие запросы на установление соединения, поступали сначала в задачу-диспетчер, а не в свободную задачу VCAl. В результате возникающая трехэтапная схема взаимодействия (задачи ROUTER IN, выделенной задачи VCM и абонента) становилась слишком громоздкой для составления ее описания. Независимо от причин, по которым возникла такая структура, внутренняя логика задачи-диспетчера оказалась чрезвычайно сложной по сравнению с достаточно простой проблемой распределения виртуальных каналов. Существует одно контрольное правило, действующее при проектировании систем и написании программ, которое часто оказывается полезнььм в подобных ситуациях. Оно гласит: когда пытаются сказать что-либо трудно формулируемое, возможно, что высказываемая мысль ошибочна. Как только мы остановились на схеме, изображенной на рис. 7.5, все проблемы, связанные с внутренней логикой задачи-диспетчера, сразу исчезли. Значит, дело здесь в том, что



7.4.1. Дополнения к проекту

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

Пакет , PACKET LAYER

WAIT FOB CALL

А

PLACE CALL

RCVE


Рис. 7.6. Внутренние сопряжения на сетевом уровне, используемые для реализации механизма временных задержек (показаны не все процедуры и входы задач).

МЫ пытались высказать ошибочную мысль! Структура, при попытке использования которой возникли отмеченные выше трудности, согласно критериям гл. 6, обладает меньшей степенью модульности, чем схема, изображенная на рис. 7.5. Следовательно, если бы мы приняли в нашем проекте указанную выше структуру, то у нас могли бы появиться дополнительные проблемы.

Упомянутые неудобства, связанные с использованием этой схемы, возникли главным образом из-за того, что было реализовано фиксированное назначение номеров виртуальных каналов задачам VCM. Однако и простота решения, приведенного на рис. 7.5, тоже определяется в первую очередь использованием такого фиксированного распределения. Динамическое распределение номеров мо.жет потребовать совершенно иного подхода.



Чтобы учесть Тот случай, когда абоненты ожидают появленил других событий (например, поступления запросов на соединение или получение пакетов данных), требуется использование условных вызовов входов. Абоненты, попадая в одно из этих состояний, должны иметь дополнительные возможности обнаружения событий, поэтому повторный вызов входа REPORT осущестолятьсн не будет


Рассылка уведомлений о событиях всем абонентам

Прполнительныи

События отсутствуют

CHECK


Вход REPORT реализует расширеннр1е функциональные возможности по сравнению , с входом, описанным ранее

VCFREE TX FLOW CONTR0L OFP

Пакет PACKEf LAYER

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

ность такой ситуации, когда они будут застревать>? в состоянии ожидания временного вызова, поскольку это приводило бы к тупику. Напомним, что тупиковая ситуация может возникнуть в том случае, если временной вызов входа будет принят задачей в связи с определенным значением относящегося к этому входу атрибута COUNT (ЧИСЛО ВЫЗОВОВ), а в конечном итоге окажется, что в промежутке между вычислением значения атрибута и приемом вызова истечет время, отведенное на ожидание.

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



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

На рис. 7.7 представлен возможный вариант организации уведомления абонентов о регулировании очереди входящих пакетов, не требующий повторной передачи информации. Задача CHECKER (КОНТРОЛЕР) вызывает новый вход CHECK (ПРОВЕРКА) задачи-диспетчера и ожидает поступления сообщений о событиях, происходящих на сетевом уровне обмена. Единственным рассматриваемым здесь существенным событием является начало регулирования очереди входящих пакетов, передаваемых по виртуальному каналу, но, вообще говоря, возможна регистрация и других событий. При возникновении интересующего нас события задача CHECKER уведомляет о нем абонентов, реализуя условные вызовы входов. Указанные обращения должны быть условными потому, что абоненты в данный момент могут ожидать появления какого-либо другого события.

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

7.4.2. Альтернативные проектные решения

Полученный в процессе проектирования пакет, реализующий функции сетевого уровня протокола Х.25, содержит N + 4 задачи, где N - число виртуальных каналов. Ниже рассматривается вариант использования меньшего числа задач.

Вместо того чтобы выделять каждому виртуальному каналу свою задачу УВК, можно использовать одну или две задачи, функционирующие на сетевом уровне обмена и управляющие! работой всех виртуальных каналов сразу; при этом либо одна главная задача управляет всеми каналами, либо вводится пара задач, одна из которых осуществляет функции установления связи, а вторая - передачу данных. В этих задачах должны храниться в явном виде таблицы состояниях всех виртуальных каналов и предусматриваться счетчики передаваемых пакетов данных. Кроме того, требуются еще задачи ROUTER IN и ROUTER OUT, однако отпадает необходимость в использовании задачи DISPATCHER. Задача BUFFER требуется только



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

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

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

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



1 ... 26 27 28 29 30 31 32

Яндекс.Метрика