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

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

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

Рис. 6.6 соответствует предположению о том, что кадры данных сохраняются в буферах обмена для осуществления повторной передачи до тех пор, пока не поступит подтверждение об их приеме. Это предположение естественным образом следует из рассуждений, которые привели нас к введению понятия кадра в разд. 6.2.

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

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

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

Источниками возможных ошибок при проектировании и реализации системы в соответствии с рассмотренными принципами могут служить множественность ссылок (aliasing), т. е. существование нескольких копий ссылочной переменной, указывающих

на- ОДИН и тот же буфер, и тупики, возникающие вследствие состязания за получение свободных буферов и управления потоком заполненных буферов между модулями.

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

Используя рис. 6.5, а, размножение ссылок можно объяснить следующим образом. Предположим, что модули передают друг другу указатели (ссылочные переменные) буферов. Очевидно, что при работе системы могут возникать ситуации, когда несколько модулей будут обладать копиями ссылки на один и тот же буфер, хотя при правильном функционировании только один модуль может иметь право использовать такую ссылку в данный момент. Ада и другие аналогичные языки не запрещают использовать эту ссылку тогда, когда другой модуль обладает ее копией. При проектировании системы эту языковую возможность можно реализовать на основе требования, чтобы модуль, временно владеющий копией ссылки, уничтожал ее, когда отпадет необходимость в ее использовании; исходный владелец указателя может затем использовать его повторно. Например, как видно из рис. 6.5, а, модуль физического обмена кадрами после передачи может уничтожить свою копию ссылки на буфер, если модуль логического обмена F сохраняет оригинал этой ссылки.

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

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

модействии различных систем, соединенных теми же средствами связи.

Различного рода блокировки потоков данных, изображенных на рис. 6.6, могут приводить к тупиковым ситуациям

в модуле, управляющем работой пула свободных буферов, из-за того, что этот пул пуст;

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

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

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

Предотвращение тупиков, вызванных блокировками изображенных на рис. 6.6 потоков кадров данных, требует на уровне управления кадрами выполнения ряда условий:

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

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

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

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

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

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

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

Механизмы локального регулирования потока данных. Как

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

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

Для организации более сложного межмодульного взаимодействия требуется, чтобы отправитель сообщения, перед тем как запрашивать свободные буферы для занесения в них информации, сначала получил разрешение на передачу одного или нескольких информационных объектов. Этот механизм удобнее в случаях, когда получение такого разрешения зависит еще и от доступности других ресурсов, а не только от наличия свободного буфера; иллюстрацией служит взаимодействие модулей М и F подсистемы COMM. Например, в модуле F для хранения кадров данные прием которых не подтвержден, отведена память фиксированного объема - независимо от числа доступных буферов. Как будет видно в подразд. 6.4.2, эта величина является параметром, зависящим от протокола обмена кадрами данных между равноправными модулями F, принадлежащими различным системам. Действительно, при взаимодействии с модулем М управление потоком передаваемых данных (блокирование) могло бы осуществляться модулем F даже при наличии свободных буферных блоков в пуле В.

До сих пор механизм получения кредита на передачу обсуждался только в аспекте обмена блоками прикладных данных

/в данном случае терминальными сообщениями или их фрагментами); поэтому на рис. 6.6 схематически показано движение лишь потока именно такой информации. Однако, как мы увидим далее, в подразд. 6.4.2, межмодульные потоки данных могут иметь смешанный характер и содержать не только прикладные данные, но и управляющую информацию, зависящую от структуры внутрисистемных протоколов. Например, при взаимодействии модулей F и Р некоторые кадры будут содержать только протокольные сообщения с такими функциями, как установление связи или (глобальное) управление межсистемным потоком кадров данных.

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

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

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

ИЛИ задерживали выполнение программ, вызывающих процедуру RECEIVE, до момента получения разрешения на обмен данными.

6.4.2. Использование протоколов обмена данными

для обнаружения внешних ошибок функционирования и устранения их последствий

Протокол обмена данными представляет собой диалог между равноправными модулями одного логического уровня в различных системах, обеспечивающий надежное взаимодействие между ними. Для реализации надежного взаимодействия всех систем может потребоваться введение протоколов информационного обмена на нескольких уровнях. Протокол предусматривает обмен соответствующими протокольными сообщениями между равноправными модулями. Чтобы отличать эти протокольные сообщения от сообщений других типов, назовем их протокольными блоками данных [ИЪЩ; это название соответствует терминологии, используемой специалистами, занимающимися стандартизацией протоколов. Ниже рассматриваются требования к протоколам различных уровней подсистемы COMM.

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

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

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

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

Управление потоком кадров может основываться также на идее определения максимально допустимого диапазона порядковых номеров кадров, для которых не получено подтверждение приема. Этот допустимый диапазон, называемый окном, и определяет необходимую емкость модуля F, упоминавшуюся ранее. В тот момент, когда число отправленных, но не квитированных, или принятых, но не обработанных кадров превышает размер окна, осуществляется регулирование исходящего или входящего потока соответственно. Оно выполняется без использования управляющих кадров: при передаче исходящий поток просто блокируется на время, пока окно буфера ТХ остается заполненным (это правило не касается кадров, передаваемых повторно); при приеме поступающие кадры данных просто отвергаются до тех пор, пока остается заполненным окно буфера RX. При таком подходе с точки зрения отправителя регулирование информационного потока дистанционным получателем не отличается от регулирования в случае отказа линии связи или узла сети; до тех пор пока оно продолжается, отправитель не получит подтверждений приема кадров данных, и его действия, связанные с повторной передачей, будут бесполезны.

Использование получателем управляющих кадров для уведомления отправителей информации о начале регулирования потока данных {RECEIVE-NOT-READY, К-ПРИЕМУ НЕ-ГО-ТОВ) или о его завершении (RECEIVE-READY, К-ПРИЕМУ ГОТОВ) повышает эффективность работы системы, поскольку предупреждает бесполезные повторные передачи информации и возможные ошибочные заключения о неисправности линии связи, возникающие в противном случае. Для упрощения изложения существа рассматриваемого проекта мы не будем останавливаться на анализе структуры управляющих кадров.

Таким образом, управляющие кадры в нашем примере используются только для первоначального установления связи, а поскольку их последовательная нумерация не требуется, необходимо индивидуальное квитирование каждого из них. При этом используются кадры двух типов: блок START (ЗАПУСК) и блок START-ACK (ПОДТВЕРЖДЕНИЕ-ЗАПУСКА).

С учетом вышеизложенного требования к нужному нам протоколу обмена можно резюмировать следующим образом:

Кадры должны иметь фиксированный размер и в добавление к фрагменту сообщения содержать два порядковых номера (исходящий и входящий).

. Порядковые номеры кадров данных должны вычисляться по модулю величины, равной размеру окна (известному заранее).

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

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

Для первоначального установления связи необходимо два ненумеруемых управляющих кадра (START и START-ACK).

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

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

Анализ протоколов обмена в подсистеме COMM. Далее мы можем двигаться в двух направлениях: либо сначала разработать протоколы обмена данными (форматы ПБД, правила упорядочения, перечень состояний и т. п.), не приступая к непосредственному проектированию системы, либо сразу же начать с ее проектирования, а обращаться к деталям протоколов по мере появления вопросов, требующих разрешения. Мы остановимся здесь на втором подходе-методе пошаговой детализации, но попутно отметим, что в большинстве практических ситуаций при проектировании системы протокол обмена (если он нужен) чаще всего бывает задан и система должна конструироваться в точном соответствии с ним. Однако у нас уже достаточно информации для того, чтобы приступить к проектированию системы, не особенно вдаваясь пока в детали построения Протокола.

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

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

На концептуальном уровне равноправные модули управления информационным обменом взаимодействуют друг с другом непосредственно через сообщения, появляющиеся на экране Дисплея, а равноправные модули управления логическим обменом кадрами данных - с помощью протокольных блоков данных (ПБД). Физически каждый из этих уровней взаимодействия реализуется системными модулями нижестоящего уровня.

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

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

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