Э. Таненбаум, Д. Уэзеролл - Компьютерные сети (1114668), страница 77
Текст из файла (страница 77)
Канальный уровеньЛистинг 3.7 (продолжение)inc(ack_expected);/* передвинуть нижний крайокна отправителя */}break;case cksum_err: if (no_nak) send_frame(nak, 0, frame_expected, out_buf);break; /* поврежденный кадр */case timeout: send_frame(data, oldest_frame, frame_expected, out_buf);break; /* время истекло */case ack_timeout: send_frame(ack,0,frame_expected, out_buf);/* истек период ожидания "попутки" для подтверждения; послать подтверждение */}if (nbuffered < NR_BUFS) enable_network_layer(); else disable_network_layer();}}Способность протокола принимать кадры в произвольном порядке накладываетдополнительные ограничения на порядковые номера кадров по сравнению с протоколами, в которых все пакеты принимались строго по порядку номеров.
Проще всегопроиллюстрировать это на примере. Предположим, что порядковый номер кадрасостоит из 3 бит, так что отправитель может посылать до семи кадров, прежде чемперейти в режим ожидания подтверждения. Начальное состояние окон отправителяи получателя изображено на рис. 3.15, а. Отправитель передает кадры с 0 по 6. Окнополучателя позволяет ему принимать любые кадры с номерами от 0 по 6 включительно.
Все семь кадров прибывают успешно, поэтому получатель подтверждает их приеми передвигает окно для приема кадров с номерами 7, 0, 1, 2, 3, 4 и 5, как показано нарис. 3.15, б. Все семь буферов помечаются как свободные.Рис. 3.15. Пример работы протокола: а — начальная ситуация при размере окна 7; б — 7 кадровбыли посланы и приняты, но не подтверждены; в — начальная ситуация при размере окна 4;г — ситуация после того, как 4 кадра были отправлены и получены, но не подтвержденыИменно в этот момент происходит какое-нибудь бедствие, например молния ударяет в телефонный столб и стирает все подтверждения.
Протокол обязан отработатьправильно, несмотря ни на какие чрезвычайные ситуации. Отправитель, не дождавшись подтверждений, посылает повторно кадр 0. К сожалению, кадр 0 попадает в новоеокно и поэтому принимается получателем (рис. 3.15, б). Получатель снова отправляетподтверждение для кадра 6, поскольку были приняты все кадры с 0 по 6.3.4.
Протоколы скользящего окна 267Отправитель с радостью узнает, что все переданные им кадры успешно достиглиадресата, поэтому он тут же передает кадры 7, 0, 1, 2, 3, 4 и 5. Кадр 7 принимаетсяполучателем, и содержащийся в нем пакет передается сетевому уровню. Сразу послеэтого принимающий канальный уровень проверяет наличие кадра 0, обнаруживаетего и передает старый буферизированный пакет сетевому уровню как новый. Такимобразом, сетевой уровень получает неверный пакет; это означает, что протокол сосвоей задачей не справился.Причина неудачи в том, что при сдвиге приемного окна новый интервал допустимых номеров кадров перекрыл старый интервал. Соответственно, присылаемый наборкадров может содержать как новые кадры (если все подтверждения были получены),так и повторно высланные старые кадры (если подтверждения были потеряны).
У принимающей стороны нет возможности отличить одну ситуацию от другой.Решением данной проблемы является предоставление гарантии того, что в сдвинутом положении окно не перекроет исходное окно. Для этого размер окна не долженпревышать половины от количества порядковых номеров (это показано на рис. 3.15, ви 3.15, г.) Например, если для порядковых номеров используются 3 бита, они должны изменяться в пределах от 0 до 7. В таком случае, в любой момент времени толькочетыре кадра могут быть неподтвержденными. Таким образом, если будут полученыкадры с 0 по 3 и будет передвинуто окно для приема кадров с 4 по 7, получатель сможетбезошибочно отличить повторную передачу (кадры с 0 по 3) от новых кадров (с 4 по 7).Поэтому в протоколе 6 применяется окно размером (MAX_SEQ + 1)/2.Возникает новый вопрос: сколько буферов должно быть у получателя? Ни прикаких условиях он не должен принимать кадры, номера которых не попадают в окно.Поэтому количество необходимых буферов равно размеру окна, а не диапазонупорядковых номеров.
В приведенном выше примере 3-битовых порядковых номеровтребуется четыре буфера с номерами от 0 до 3. Когда прибывает кадр i, он помещаетсяв буфер i mod 4. Обратите внимание на то, что хотя i и (i + 4), взятые по модулю 4,«соревнуются» за один и тот же буфер, они никогда не оказываются в одном окнеодновременно, потому что это привело бы к увеличению размера окна, по крайнеймере, до 5.По этой же причине количество необходимых таймеров также равно числу буферов, а не диапазону порядковых номеров. Таким образом, удобно связать каждыйтаймер со своим буфером. Когда интервал времени истекает, содержимое буфера высылается повторно.Протокол 6 также ослабляет неявное предположение о том, что загрузка каналадовольно высока.
Мы сделали это предположение в протоколе 5, в котором подтверждение «ехало верхом» на встречном информационном кадре. Если обратный потокинформации невелик, подтверждения могут задерживаться на довольно большойпериод времени, создавая проблемы. В экстремальной ситуации, если в одном направлении посылается много информации, а во встречном — вообще ничего, протоколостанавливается, когда окно отправителя достигает максимума.В протоколе 6 эта проблема решена. По прибытии последовательного кадра с данными процедура start_ack_timer запускает вспомогательный таймер.
Если таймер сработает раньше, чем появится кадр с данными для передачи, то будет послан отдельныйкадр с подтверждением. Прерывание от вспомогательного таймера называется собы-268 Глава 3. Канальный уровеньтием ack_timeout. При такой организации возможен однонаправленный поток данных,так как отсутствие встречных информационных кадров, на которых можно было быотправлять подтверждения, больше не является препятствием.
Требуется всего одинтаймер. При вызове процедуры start_ack_timer, если таймер уже запущен, ничего непроисходит. Таймер не сбрасывается и не продляется, так как он нужен лишь для обеспечения некоторого минимального количества подтверждений.Важно, что период времени вспомогательного таймера должен быть существеннокороче интервала ожидания подтверждения. При этом условии подтверждение в ответ на полученный правильный кадр должно приходить прежде, чем у отправителяистечет период ожидания, и он пошлет этот кадр второй раз.Протокол 6 использует более эффективную стратегию обработки ошибок, чемпротокол 5. Как только у получателя появляются подозрения, что произошла ошибка,он высылает отправителю отрицательное подтверждение (NAK). Получатель можетделать это в двух случаях: если он получил поврежденный кадр или если прибыл кадрс номером, отличным от ожидаемого (возможность потери кадра).
Чтобы избежатьпередачи нескольких запросов на повторную передачу одного и того же кадра, получатель должен запоминать, был ли уже послан NAK для данного кадра. В протоколе 6для этой цели применяется переменная no_nak, принимающая значение true, если NAKдля ожидаемого кадра (с номером frame_expected) еще не был послан. Если NAK повреждается или теряется по дороге, в этом нет большой беды, так как у отправителя,в конце концов, истечет период ожидания положительного подтверждения, и он, такили иначе, вышлет недостающий кадр еще раз.
Если после того, как NAK будет выслани потерян, прибудет не тот кадр, переменной no_nak опять будет присвоено true и будетзапущен вспомогательный таймер. Когда время истечет, будет послано положительное подтверждение (ACK) для восстановления синхронизации текущих состоянийотправителя и получателя.В некоторых ситуациях время, необходимое для прохождения кадра по каналу, егообработки и отсылки обратно подтверждения, практически остается неизменным.
В таких ситуациях отправитель может поставить время ожидания лишь немного большеожидаемого интервала между отправкой кадра и получением подтверждения. NAKв таких случаях применять неэффективно.Однако в других случаях время может сильно варьироваться. Если встречный поток данных нерегулярен, то время прихода подтверждений также будет непостоянным,уменьшаясь при наличии встречного потока и увеличиваясь при его отсутствии. Передотправителем возникает непростой выбор значения времени ожидания. Если выбратьслишком короткий интервал, то увеличится риск ненужных повторных передач. Привыборе слишком большого значения протокол будет тратить много времени на ожидания после ошибки.
В обоих случаях пропускная способность на что-то тратится.В целом, если среднеквадратичное отклонение интервала ожидания подтверждениявелико по сравнению с самим интервалом, то таймер может быть установлен довольно«свободно», и отрицательные подтверждения могут существенно ускорить повторнуюпередачу потерянных или поврежденных кадров.С вопросом тайм-аутов и отрицательных подтверждений тесно связана проблемаопределения кадра, вызвавшего тайм-аут.
В протоколе 5 это всегда кадр с номеромack_expected, поскольку он является старшим. В протоколе 6 нет столь простого способаопределить кадр, интервал ожидания которого истек. Предположим, были переданы3.5. Примеры протоколов передачи данных 269кадры с 0 по 4, то есть список неподтвержденных кадров выглядит так: 01234 (отпервого к последнему). Теперь допустим, что у кадра 0 истекает интервал ожиданияи он передается повторно, затем посылается кадр 5 (новый), потом интервал ожиданияистекает у кадров 1 и 2 и посылается кадр 6 (также новый). В результате список неподтвержденных кадров принимает вид: 3405126, начиная с самого старого и заканчиваясамым новым.
Если весь встречный поток данных потеряется, интервалы ожиданияэтих семи кадров истекут именно в таком порядке.Чтобы не усложнять и без того непростой пример протокола, мы не показываемподробностей управления таймером. Вместо этого предполагается, что переменнойoldest_frame при наступлении тайм-аута присваивается номер кадра, интервал временикоторого истек.3.5.
Примеры протоколов передачи данныхВ пределах одного здания для связи компьютеров широко применяются локальныесети, однако большинство глобальных сетей построено на двухточечных линиях.С локальными сетями мы познакомимся в главе 4. Здесь мы рассмотрим протоколыканального уровня, которые применяются на двухточечных каналах в Интернетев двух наиболее распространенных ситуациях.
Первая — это передача пакетов по оптоволокну SONET. Например, такие каналы соединяют маршрутизаторы, установленныев разных концах сети поставщика услуг Интернета.Вторая ситуация описывает каналы ADSL����������������������������������������������������������������������������������в пределах локального контура телефонной сети. Такие связи соединяют с Интернетом миллионы отдельных пользователейи компаний.Пользователям необходимы для подключения к Интернету такие двухточечныесвязи, а также телефонные модемы, арендованные линии, кабельные модемы и т. д.Для пересылки пакетов по таким каналам используется стандартный протокол подназванием PPP (Point-to-Point Protocol, протокол двухточечного соединения).Протокол PPP описан в стандарте RFC 1661 и доработан в более поздних документахRFC 1662 и др.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
