Полный курс лекций 2009-го года (1130357), страница 37
Текст из файла (страница 37)
Времяобработки данных игнорируется. Предполагается, что буфер неограниченного размера. Данные в каналене теряются и не искажаются.Рисунок 3-9. Симплексный протокол канального уровня3.3.2. Симплексный старт-стопный протоколТеперь снимем одно из ограничений предыдущего протокола - способность сетевого уровняобрабатывать поступающие данные сколь угодно быстро. Все остальные предположения остаются в силе:канал абсолютно надежный, трафик однонаправленный.Основная проблема - как предотвратить ситуацию, когда отправитель «заваливает» даннымиполучателя.
Если получателю требуется время Dt, чтобы исполнить from_physical_layer плюсto_network_layer, то отправитель должен передавать данные со средней скоростью один кадр в Dt.Решением такой проблемы может быть введение коротких специальных служебных сообщений.Получатель, получив один или несколько кадров, отправляет отправителю короткий специальный кадр,означающий, что отправитель может передавать следующий. Это так называемый старт-стопный протокол,показанный на рисунке 3-10.Рисунок 3-10. Однонаправленный старт-стопный протокол канального уровня3.3.3. Симплексный протокол для канала с шумомОсновная проблема при передаче состоит в том, что кадр с подтверждением о получении можетпотеряться целиком.
Как отличить кадр, переданный первый раз, от кадра, переданного повторно?Одно из очевидных решений - нумерация передаваемых кадров. Однако сколько места отводить подэту нумерацию? Поскольку проблема различения стоит для кадров m и m+1, то достаточно одногоразряда. 0 - для только что посланного кадра и 1 - для следующего ожидаемого. Все кадры, несодержащие корректной нумерации, просто сбрасываются при приеме.На рисунке 3-11 показана программа для этого варианта протокола.Рисунок 3-11. Протокол с подтверждением и восстановлением3.4.
Протоколы скользящего окнаВ рассмотренных выше протоколах канального уровня кадры передавались только в одномнаправлении. Для передачи в обоих направлениях можно потребовать на физическом уровне двухсимплексных каналов. Один для передачи кадров, другой - для передачи подтверждений. Однакоиспользование канала только для подтверждений - довольно дорогое удовольствие. Можно смешиватькадры с данными и кадры с подтверждениями на одном канале.
Это, конечно. решение проблемы, но попрежнему на подтверждения будет тратиться полезная пропускная способность канала.А что, если для подтверждения использовать полезные кадры с данными? Получатель не сразуотправляет подтверждение, а ожидает от сетевого уровня очередного пакета. Как только такой пакетвозникает, то канальный уровень помещает в кадр с пакетом также уведомление о получении вспециальное поле ack. Такой прием позволяет полнее использовать имеющуюся пропускную способностьканала.
Меньше кадров - меньше прерываний на канальном уровне на их обработку, меньше затрат набуферизацию.Однако применение этой идеи усложняет протокол. Что делать, если тайм-аут у отправителя наполучения подтверждения заканчивается, а с сетевого уровня получателя не поступает запроса напередачу пакета? Поэтому на канальном уровне должен быть фиксированный интервал времени, в течениекоторого канальный уровень ждет от сетевого попутного кадра. Если до истечения этого срока пакет ссетевого уровня не поступил, то канальный уровень отправляет подтверждение отдельным кадром.Рассмотренный здесь протокол является представителем класса протоколов скользящего окна. Кромевышесказанного, протоколы этого класса делают следующее: у отправителя и получателя естьопределенная константа n - число кадров, которое отправитель может послать, не ожидая подтверждениядля каждого кадра.
По мере получения подтверждений отправленные кадры будут сбрасываться из буфераотправителя, и буфер будет пополняться новыми кадрами.Мы уже сталкивались с подобными протоколами (старт-стопный протокол). В них n было равно 1.Обычно n = 2k - 1. У получателя и отправителя есть набор последовательных чисел - номеров кадров,которые отправитель может отправить, не ожидая подтверждения каждого. Эти кадры образуют окноотправки. Аналогично, у получателя есть буфер для получения и временного хранения получаемых кадров- окно получения.Хотя в этих условиях у отправителя есть определенная свобода в порядке отправления кадров, мыпо-прежнему будем считать, что кадры отправляют в соответствии с порядковыми номерами.
У оконотправки и получения есть верхняя и нижняя границы. Порядковые номера кадров в окне отправки кадры отправленные, но не подтвержденные. Как только от сетевого уровня поступил еще один пакет, емуприсваивают первый свободный наибольший номер, и верхняя граница окна отправителя поднимается.Как только приходит подтверждение, нижняя граница окна поднимается. Таким образом, в окне все времянаходятся неподтвержденные кадры.Рисунок 3-12 показывает работу такого протокола для n=1 в форме диаграммы.Рисунок 3-12. Протокол скользящего окна3.4.1. Протокол скользящего окна в 1 битПрежде чем переходить к общему случаю, рассмотрим протокол скользящего окна с максимальнымразмером окна в 1 бит.
Такой протокол использует старт-стопный режим и, послав кадр, не шлет другой,пока не придет подтверждение на первый.На рисунке 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 и пошлет подтверждение. Все последующие дубликатыбудут им отвергнуты, так как он будет ожидать кадра с 1, а не 0.Случай, когда оба канальных уровня начинаю передачу одновременно, показан на рисунке 314 (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 кадров.Эта техника известна как конвейер. Ее применение в случае ненадежного канала наталкивается наряд проблем.
Первая - что делать, если в середине потока пропадет или попадется поврежденный кадр?Получатель уже получит большое количество кадров к тому моменту, когда отправитель обнаружит, чточто-то произошло. Когда получатель получил поврежденный кадр, он его должен сбросить, что делать споследующими кадрами? Помните, что канальный уровень обязан передавать пакеты на сетевой уровень втом порядке, в каком их отправлял отправитель.Есть два приема для решения этих вопросов: откат и выборочный повтор. При откате все кадры,поступившие после поврежденного кадра, сбрасываются и не подтверждаются. Отправитель по тайм-аутуповторно отправляет все кадры, начиная с первого неподтвержденного кадра. Этот подход показан нарисунке 3-15 (а), где размер окна у получателя - 1.Рисунок 3-15.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
