tanenbaum_seti_all.pages (525408), страница 71
Текст из файла (страница 71)
Соо таг) М (аггтчеб[г.яецЖИВ /а1яе)) ( /* кадры могут приникаться в побои порядке */ аггзчеб[г.яец Ж Ий ВОЕ5] = Сгце: /* поиетить буфер как занятый 1п Ьцт[г.яец Ж Ий ВОЕ5] = г.(пто: /* поместить данные в буфер ыц11е (агг(чеб[[гаше ехресСеб Ж Ий ВОЕ5]) ( /* передать пакет сетевону уровне и сдвинуть окно "/ Со петыоги )ауег(ятп бы[[[гаже ехресСеб Ж ИК ВОЕ5]): по пад = Сгце: аггтчеб[тгаше ехрестеб Ж Ий ВОЕ5] = та1яе; тпс([гаже ехрестеб); /* передвинуть нижний край окна получателя */ 1пс(Соа /аг); /* передвинуть верхний край окна получателя */ ятагС аск С1шег(); !* запустить вспонатательный таймер на случай.
если потребуется пересылка подтверждения отдельным кадрои */ ) ) т/((г.Стоб==паХ) ЖЖ Ьетыееп(асц ехрес(еб.(г.вод+1)Ж(МАХ 5[0+)) пехС /гаже Со яепб)) яепб /гаже(бата. (г.асць1) Ж (МАХ 5[О + 7), [гаже ехрестеб. оцС ьцт); ыц11е (Ьетыееп(асц ехресСеб, г.асц, пехС /гаже Со яепб)) ( поцттегеб = поц([егеб — 7: !* отправить подтверждение вместе с инфориационным кадром *l я(ор Стшег(асц ехрес(еб Ж Ий ВОЕ5); /* кадр прибыл в целости */ 1пс(асх ехрес(еб); /* передвмнуть нижний край окна отправителя */ ) Ьгеац; поцт(егеб = поцттегеб + 1, /* увеличить окно отправителя */ (гоп песыогХ 1ауег(йоцС Ьцт[пехС /гаже Со яепб Ж Ий ВОЕ5]); /* получить новый пакет у сетевого уровня */ яепб /гаже(баса.
пехС /гаже Со яепб. глаше ехресСеб, оцС Ьцт); /* передать кадр */ тпс(пехс (гаже Со яепб); /* увеличить верхний край окна отправителя */ Ьгеац; Протоколы скользящего окна 267 сазе сквои егг: 1/ (по пвх) вепб Сгвие(пвк. О. /гаке ехресСеб оиС Ьцт); Ьгевк; /* поврекденний кедр */ севе С(аеооС: вепб тгвве(бвСв.
о1бевС тгвае, тгвае ехресСеб. оиС Ьцт); Ьгевд; /* врекя истекло */ саве век с1веоцс: вепб /гвве(век.О./гвве ехрессеб, оос ьцг): /* истек период окидвнкя «попутки» для водтверкдения: послать подтверкденяе */ (Г (пвц(/егеб < Кй ВВГ5) епвЬ)е пе(иогх 1вуег(). е1ве б1ввЬ)е пе(ногк 1вуег(); Способность протокола принимать кадры в произвольном порядке вызывает некоторые проблемы, отсутствовавшие в предыдущих протоколах, в которых все пакеты принимались строго по порядку номеров. Проще всего проиллюстрировать это на примере. Предположим, что порядковый номер кадра состоит из 3 бит, так что отправитель может посылать до ссмп кадров, прежде чем перейти в режим ожидания подтверждения.
Начальное состояние окон отправителя и получателя изображено на рис. 3,13, а. Отправитель передает кадры с О по 6. Окно получателя позволяет ему принимать любые кэлры с номерами от О по 6 включительно. Все семь кадров прибывают успешно, поэтому получатель подтверждает их прием и передвигает окно для приема кадров с номерами 7, О, 1, 2, 3, 4 и 5, как показано на рис. 3.12, б. Все семь буферов помечаются как свободныс, 2~4 ~~~~~2 1 П[г 2]~ 2~~~~6~Я Рис. 3.13. Начальная ситуация при размере окна 7 (з)', у кадров были посланы и приняты, но не подтвер:кдвны (б); начальная ситуация при размере окна 4 (в)) ситуация после того, как 4 кадра были отправлены и получены, но не подтверждены (г) Имсино в этот момент происходит какое-нибудь бедствие — например, молния ударяст в телефонный столб н стирает все подтверждения, Отправитель, не дождавшись подтверждений, посылает повторно кадр О, К сожалению, кадр О попадает в новое окно и поэтому принимается получателем (рис, 3.13, б).
Получатель снова отправляет подтверждение для кадра 6, поскольку были приняты все кадры с О по 6. Отправитель с радостью узнает, что все переданные им кадры успешно достигли адресата, поэтому он тут жс передает кадры 7, О, 1, 2, 3, 4 и 5. Кадр 7 принимается получателем,и содержащийся в нем пакет передается сетевому уРовню. Сразу после этого принимающий уровень передачи данных проверяет наличие кадра О, обнаруживает его и передаст внедренный пакет сетевому уровню. Таким образом, сетевой уровень получает неверный пакет; это означает, что протокол со своей задачей не справился. 268 Глава 3. уровень передачи данных Причина неудачи в том, что при сдвиге приемного окна новый интервал допустимых номеров кадров перекрыл старый интервал.
Соответственно, присылаемый набор кадров может содержать как новые кадры (если все подтверждения были получены), так и повторно высланные старые кадры (если подтверждения были потеряны). У принимающей стороны нет возможности отличить олну ситуацию от другой. Решением данной проблемы является предоставление гарантии того, что в сдвинутом положении окно не перекроет исходное окно. Для этого размер окна не должен превышать половины от количества порядковых номеров (это показано на рис.
3.13, в и г). Например, если для порядковых номсров используются 4 бита, они должны изменяться в пределах от О до 15. В таком случае в любой момент времени только восемь кадров могут быть неподтвержденными. Таким образом, если будут получены кадры с О по 7 и будет передвинуто окно для приема кадров с 8 по 15, получатель сможет безошибочно отличить повторную передачу (кадры с О по 7) от новых кадров (с 8 по 15), Поэтому в протоколе 6 применяется окно РазмеРом (МАХ 5ЕЯ + 1)гг2.
Возникает новый вопрос: сколько буферов должно быть у получателя? Нн при каких условиях он не должен принимать кадры, номера которых не попадают в окно. Поэтому количество необходимых буферов равно размеру окна, а не диапазону порядковых номеров. В приведенном выше примере для 4-битовых порядковых номеров требуется восемь буферов с номерами от О до 7.
Котла прибывает кадр й он помещается в буфер 1 гной 8. Обратите внимание на то, что хотя 1 и (1 + 8), взятые по модулю 8, «соревнуютсяь за один и тот же буфер, они никогда не оказываются в одном окне одновременно, потому что это привело бы к увеличению размера окна по крайней мере до 9. По этой жс причине количество необходимых таймеров также равно числу буферов, а не диапазону порядковых номеров.
Таким образом, удобно связать каждый таймер со своим буфером. Когда интервал времени истекает, содержимое буфера высылается повторно. В протоколе 5 предполагалось, что загрузка канала довольно высока. Когда прибывал кадр, он не подтверждался сразу. Вместо этого подтверждение «ехало верхом«на встречном информационном кадре.
Если обратный поток информации был невелик, подтверждсния задерживались на довольно большой периол времени. Если в одном направлении посылалось много информации, а во встречном — вообще ничего, то высылалось только МАХ ба пакетов, после чего протокол останавливался. В протоколе 6 эта проблема решена. По прибытии кадра с данными процедуРа з1эг1 ас~ 1ивег запускает вспомогательный таймер. Если таймер сработает Раньше, чем появится кадр с данными для передачи, то будет послан отдельный кадр с подтверждением.
Прерывание от вспомогательного таймера называется собъ1тисм ас1 11ееовЕ При такой организации возможен однонаправленный поток данных, так как отсутствие встречных информационных кадров, на котоРых можно было бы отправлять подтверждения, больше не является препятствием. Для этого требуется всего один таймер. При вызове процедуры згим ас7г отец Протоколы скользящего окна 269 если таймер уже был запушен, его параметры персустанавливаются на отсчст полного интервала времени, Важно, что периол времени вспомогательного таймера должен быть существенно короче интервала ожидания подтверждения.
При этом условии подтверждение в ответ на полученный правильный калр должно приходить прежде, чем у отправителя истечст период ожидания и он пошлет этот кадр второй раз, Протокол 6 использует более эффективную стратегию обработки ошибок, чем протокол 5. Как только у получателя появляются подозрения, что произошла ошибка, он высылает отправителю отрицательное подтвсржление (МАК).
Получатель может делать это в двух случаях: если он получил поврежденный кадр или если прибыл кадр с номером, отличным от ожидаемого (возможность потери кадра). Чтобы избежать передачи нескольких запросов на повторную передачу одного и того же кадра, получатель должен запоминать, был ли уже послан МАК для данного кадра, В протоколе 6 для этой цели применяется переменная по пах, принимающая значение йгэе, если )чАК лля ожидаемого кадра (с номером ~гаге ехрестео) еще не был послан. Если МАК повреждается или теряется по дороге, в этом нет большой беды, так как у отправителя в конце концов истечет период ожидания положнтелыюго подтверждения и он, так или иначе, вьпплет недостающий кадр еще раз. Если после того как ХАК будет выслан н потерян прибудет не тот кадр, переменной по пзк опять будет присвоено ггэе н будет запушен вспомогательный таймер.
Когда время истечет, будет послано положительное подтверждение (АСК) для восстановления синхронизации текущих состояний отправителя н получателя. В некоторых ситуациях время, необходимое для прохождения кадра по каналу, его обрабютки и отсылки обратно подтверждения, остается практически неизменным. В таких ситуациях отправитель может поставить время ожидания несколько больше ожидаемого интервала между отправкой кадра и получснисм подтверждения. Однако сели это время меняется в широких прелелах, перед отправителем возникает непростой выбор значения времени ожидания.
Если выбрать слишком короткий интервал, то увеличится риск ненужных повторных псредач, следовательно, снизится производительность канала. При выборе слишком большого значения протокол будет тратитыпюго времени на ожидания, что также снизит пропускную способность. В любом случае пропускная способность на что-то тратится. Если встречный поток данных нерсгулярен, то время прихода подтверждений также будет непостоянным, уменьшаясь при наличии встречного потока и увеличиваясь при его отсутствии. Переменное время обработки кадров получателем также может вызвать ряд проблем. Итак, если среднеквадратичное отклонение интервала ожидания подтверждения невелико по сравнению с самим интервалом, то таймер может быть установлен довольно «туго» и польза от отрицательных подтверждений (ХАК) не очень высока. В противном случае таймер может быть установлен довольно «свободно», и отрицательные подтверждения могут существенно ускоРить повторную передачу потерянных или поврежденных кадров.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
