Лекции 2010-го года (1130544), страница 37
Текст из файла (страница 37)
Это, конечно. решение проблемы, но по-прежнему наподтверждения будет тратиться полезная пропускная способность канала.А что, если для подтверждения использовать полезные кадры с данными? Получатель несразу отправляет подтверждение, а ожидает от сетевого уровня очередного пакета. Кактолько такой пакет возникает, то канальный уровень помещает в кадр с пакетом такжеуведомление о получении в специальное поле ack.
Такой прием позволяет полнееиспользовать имеющуюся пропускную способность канала. Меньше кадров - меньшепрерываний на канальном уровне на их обработку, меньше затрат на буферизацию.Однако применение этой идеи усложняет протокол. Что делать, если тайм-аут уотправителя на получения подтверждения заканчивается, а с сетевого уровня получателяне поступает запроса на передачу пакета? Поэтому на канальном уровне должен бытьфиксированный интервал времени, в течение которого канальный уровень ждет отсетевого попутного кадра. Если до истечения этого срока пакет с сетевого уровня непоступил, то канальный уровень отправляет подтверждение отдельным кадром.18Рассмотренный здесь протокол является представителем класса протоколов скользящегоокна. Кроме вышесказанного, протоколы этого класса делают следующее: у отправителя иполучателя есть определенная константа n - число кадров, которое отправитель можетпослать, не ожидая подтверждения для каждого кадра. По мере получения подтвержденийотправленные кадры будут сбрасываться из буфера отправителя, и буфер будетпополняться новыми кадрами.Мы уже сталкивались с подобными протоколами (старт-стопный протокол).
В них n былоравно 1. Обычно n=2k-1. У получателя и отправителя есть набор последовательных чисел номеров кадров, которые отправитель может отправить, не ожидая подтверждениякаждого. Эти кадры образуют окно отправки. Аналогично, у получателя есть буфер дляполучения и временного хранения получаемых кадров - окно получения.Хотя в этих условиях у отправителя есть определенная свобода в порядке отправлениякадров, мы по-прежнему будем считать, что кадры отправляют в соответствии спорядковыми номерами. У окон отправки и получения есть верхняя и нижняя границы.Порядковые номера кадров в окне отправки - кадры отправленные, но неподтвержденные. Как только от сетевого уровня поступил еще один пакет, емуприсваивают первый свободный наибольший номер, и верхняя граница окна отправителяподнимается.
Как только приходит подтверждение, нижняя граница окна поднимается.Таким образом, в окне все время находятся неподтвержденные кадры.Рисунок 3-12 показывает работу такого протокола для n=1 в форме диаграммы.Рисунок 3-12. Протокол скользящего окна3.4.1. Протокол скользящего окна в 1 битПрежде чем переходить к общему случаю, рассмотрим протокол скользящего окна смаксимальным размером окна в 1 бит. Такой протокол использует старт-стопный режими, послав кадр, не шлет другой, пока не придет подтверждение на первый.19На рисунке 3-13 показан текст протокола для этого простейшего случая.
Как и все, онначинается с определения переменных. Next_frame_to_send указывает, какой кадрпосылается. Переменная frame_expected определяет, какой кадр получатель ожидает. Естьтолько два значения - 0 или 1.Рисунок 3-13. Протокол скользящего окна в 1 битЕсть два случая: первый - простой и наиболее удобный, когда только один из канальныхуровней первым начинает передачу. В этом случае вне тела основного цикла одной изпрограмм канального уровня есть обращения к процедурам to_phisical_layer и start_timer.Случай, когда оба уровня одновременно могут начинать передачу, описывается позже,поскольку он требует более детального рассмотрения.Машина, инициирующая обмен, берет пакет от сетевого уровня, формирует кадр ипосылает его. Когда он (или любой другой кадр) поступает, канальный уровеньполучатель проверяет: не является ли этот кадр дубликатом.
Если поступивший кадр тот,что ожидался, то он передается на сетевой уровень и окно получателя сдвигается вверх.Поле уведомления содержит номер последнего кадра, полученного без ошибок. Если этотномер согласуется с номером кадра, который уровень-отправитель старается послать, тоон считает, что кадр, хранящийся в буфере, послан, и сбрасывает его оттуда, забираяновый с сетевого уровня. Если номера не согласуются, то отправитель старается послатьтот же кадр еще раз. В любом случае, после получения кадра отправляется новый кадр.На рисунке 3-14 показан протокол 4. Если у А очень короткий тайм-аут, то все дубликатыкадра пойдут с одним и тем же значением полей seq и ask.
Поэтому, получив исправныйкадр, В установит значение переменной frame_expected равным 1 и пошлет20подтверждение. Все последующие дубликаты будут им отвергнуты, так как он будетожидать кадра с 1, а не 0.Случай, когда оба канальных уровня начинаю передачу одновременно, показан нарисунке 3-14 (b). В нем возникает много повторных передач одного и того же кадра дажепри отсутствии ошибок в передаче.Рисунок 3-14. Два сценария для протокола 43.4.2. Протокол с возвратом на n кадров и протокол свыборочным повторомДо сих пор мы предполагали, что время доставки кадра и время доставки подтвержденияпренебрежимо малы.
В некоторых случаях это предположение очевидно не работает. Ономожет приводить к серьезным бесполезным тратам пропускной способности канала.Рассмотрим пример спутникового канала на 50 Кбит/сек. с общей задержкой 500 мсек.Пусть мы хотим использовать протокол 4 для передачи кадров размером 1000 бит поэтому каналу. В момент t=0 отправитель отправляет первый кадр. В t=20 мсек. кадрполностью отправлен, в t=270 мсек он принят и в t=520 мсек.
отправитель получилподтверждение. Эти цифры говорят о том, что отправитель был блокирован в течение500/520, т.е. 96% времени. А это - потеря пропускной способности канала.Эта проблема есть следствие правила, по которому отправитель ждет подтвержденияпрежде, чем пошлет следующий кадр. Это требование можно ослабить - разрешитьотправителю отправлять до w кадров, не дожидаясь их подтверждения. Надлежащимвыбором значения w отправитель может заполнить все время, необходимое на отправкукадра и получение его подтверждения. В вышеприведенном примере w должно бытьравным, по крайней мере, 26. Это то количество кадров, какое отправитель успеетотправить за 520 мсек., прежде чем придет подтверждение на кадр 0.
Таким образом,неподтвержденными будут 25 из 26 кадров, размер окна отправителя будет равным 26кадров.Эта техника известна как конвейер. Ее применение в случае ненадежного каналанаталкивается на ряд проблем. Первая - что делать, если в середине потока пропадет или21попадется поврежденный кадр? Получатель уже получит большое количество кадров ктому моменту, когда отправитель обнаружит, что что-то произошло.
Когда получательполучил поврежденный кадр, он его должен сбросить, что делать с последующимикадрами? Помните, что канальный уровень обязан передавать пакеты на сетевой уровень втом порядке, в каком их отправлял отправитель.Есть два приема для решения этих вопросов: откат и выборочный повтор. При откате всекадры, поступившие после поврежденного кадра, сбрасываются и не подтверждаются.Отправитель по тайм-ауту повторно отправляет все кадры, начиная с первогонеподтвержденного кадра. Этот подход показан на рисунке 3-15 (а), где размер окна уполучателя - 1.Рисунок 3-15.
Влияние ошибки при окне размером 1 (a) и окне большого размера (b)При выборочном повторе у получателя длина окна такая же, как и у отправителя.Отправитель отмечает неподтвержденный кадр и посылает его еще раз. Получатель непередает на сетевой уровень последовательность пакетов, если в ней есть разрывы. Этотподход показан на рисунок 3-15 (b).Раздел 3.5. Примеры протоколов канала данных.3.5.1. Протокол HDLC (High Level Data Link Control)До сих пор мы рассматривали решение основных проблем, с которыми приходится иметьдело на канальном уровне.
Теперь мы познакомимся с группой давно известных, но попрежнему широко используемых на практике протоколов. Все они имеют одногопредшественника - SDLC (Synchronous Data Link Control) - протокола управлениясинхронным каналом, предложенного фирмой IBM в рамках архитектуры SNA. ISOмодифицировало этот протокол и выпустило под название HDLC - High level Data Link22Control. МКТТ модифицировало HDLC для X.25 и выпустило под именем LAP - LinkAccess Procedure.
Позднее он был модифицирован в LAPB.Все эти протоколы построены на одних и тех же принципах. Они используют техникувставки специальных последовательностей битов и являются бит–ориентированнымипротоколами. Различия между ними незначительные.Рисунок 3-16. Типовая структура кадра протокола HDLCНа рисунке 3-16 показана типовая структура кадра протокола HDLC.• Поле Address используют для адресации терминала, если их несколько на линии.Для линий точка-точка это поле используется для того, чтобы отличать команду отответа.• Поле Control используется для последовательных номеров кадров, подтвержденийи других нужд.• Поле Data может быть сколь угодно большим и используется для передачи данных.Надо только иметь в виду, что чем длиннее это поле, тем больше вероятностьповреждения кадра на линии.• Поле Checksum - это поле используется для передачи CRC-кода.Флаговые последовательности 01111110 используются для разделения кадров и постояннопередаются по незанятой линии в ожидании кадра.
Существует три вида кадров:Information, Supervisory, Unnumbered. Организация поля Control для этих трех видовкадров показана на рисунке 3-17. Как видно из размера поля Seq, в окне отправителяможет находиться до 7 неподтвержденных кадров. Поле Next используется для отправкиподтверждения вместе с передаваемым кадром. Подтверждение может быть в форменомера последнего правильно переданного кадра, а может быть в форме первого, еще непереданного кадра. Какой вариант будет использован - зависит от параметров протокола.Рисунок 3-17.
Поле Control для кадров: Information (a), Supervisory (b), Unnumbered (c)23Разряд P/F используют при работе с группой терминалов. Когда компьютер приглашаеттерминал к передаче, он устанавливает этот разряд в P (все кадры, посылаемыетерминалами, имеют здесь P). Если это последний кадр, посылаемый терминалом, тозначение этого разряда устанавливается в F.Кадры Supervisory бывают четырех типов.• Тип 0 - уведомление в ожидании следующего кадра (RECEIVE READY).Используется, когда нет встречного трафика, чтобы передать уведомление в кадрес данными.• Тип 1 - негативное уведомление (REJECT) - указывает на ошибку при передаче.Поле Next указывает номер кадра, начиная с которого надо перепослать кадры.• Тип 2 - RECEIVE NOT READY.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
