Выбор одной из двух приведенных ранее стратегий является вопросом компромисса между пропускной способностью и размером буфера уровня передачи данных. В зависимости от того, что в конкретной ситуации является более критичным, может использоваться тот или иной метод. В листинге 3.6 показан конвейерный протокол, в котором принимающий уровень передачи данных принимает кадры по порядку. Все кадры, следующие за ошибочным, игнорируются. В данном протоколе мы впервые отказались от предположения, что у сетевого уровня всегда есть неограниченное количество пакетов для отсылки. Когда у сетевого уровня появляется пакет, который он хочет отправить, уровень инициирует событие network_layer_ready. Однако чтобы ограничить количество неподтвержденных пакетов числом МАХ_ЗEQ{2, уровень передачи данных должен иметь возможность отключать на время сетевой уровень. Для этой цели служит пара библиотечных процедур — enable_network_layer и disable_network_layer .Базы данных Информатика
Обратите внимание на то, что в любой момент времени может быть МАХ_SEQ, а не МАХ_SEQ + 1 неподтвержденных пакетов, хотя различаются МАХ_ SEQ + 1 порядковых номеров: от 0 до МАХ_SEQ. Чтобы понять, почему необходимо такое ограничение, рассмотрим сценарий с МАХ_SEQ = 7.
Отправитель посылает кадры с 0 по 7.
Подтверждение для кадра 7 наконец прибывает к отправителю.
Отправитель посылает следующие восемь кадров, снова с номерами с 0 по 7.
Еще одно подтверждение для кадра 7 прибывает к отправителю.
Но вот вопрос: все восемь кадров, входящих во второй набор, благополучно дошли до адресата или все они потерялись (включая игнорированные кадры после ошибочного)? В обоих случаях получатель отправит кадр 7 в качестве подтверждения. У отправителя нет способа отличить один случай от другого. По этой причине максимальное количество неподтвержденных кадров должно быть ограничено числом МЛХ_SEQ.
Хотя в протоколе 5 кадры, поступившие после ошибки, не буферизируются получателем, тем не менее, отправитель должен хранить отправленные кадры в своем буфере, пока не получит на них подтверждение. Если поступает подтверждение на кадр n, кадры n - 1, n - 2 (то есть все предыдущие кадры) автоматически считаются подтвержденными. Эта особенность наиболее важна в случае потери или повреждения какого-либо кадра с подтверждением. Получив подтверждение, уровень передачи данных проверяет, не освободился ли у него какой-нибудь буфер. Если буфер освобождается, то заблокированному ранее сетевому уровню можно снова разрешить инициировать события network_layer_ready.
Для этого протокола предполагается, что всегда есть обратный трафик, по которому можно отправлять подтверждение. Если же это условие не выполняется, то никакие подтверждения отосланы не будут. Протокол 4 не нуждается в подобном допущении, поскольку за каждым принятым кадром следует обратный, даже если только что уже был отправлен какой-то кадр в сторону отправителя. В следующем протоколе проблема отсутствия обратного трафика будет решена гораздо элегантней.
Поскольку протокол 5 хранит несколько неподтвержденных кадров, ему требуется несколько таймеров, по одному на кадр. Для каждого кадра время считается независимо от других. Все таймеры могут симулироваться программно, используй единственные аппаратные часы, вызывающие периодические прерывания. Данные таймеров могут храниться в программе в виде связанного списка, каждый узел которого будет хранить количество временных интервалов системных часов, оставшихся до истечения срока ожидания, номер кадра и указатель на следующий узел списка.
Рис. 3.12. Программная симуляция работы нескольких таймеров
В качестве иллюстрации приводится рис. 3.12, на котором показана программная реализация нескольких таймеров. Предположим, что часы изменяют свое состояние каждые 100 мс. Пусть начальное значение реального времени будет 10:00:00.0, и имеются три таймера тайм-аутов, установленные на время 10:00:00.5, 10:00:01.3 и 10:00:01.9. Каждый раз, когда аппаратные часы изменяют свое значение, реальное время обновляется и счетчик этих изменений в голове списка уменьшается на единицу. Когда значение счетчика становится равным нулю, инициируется тайм-аут, а узел удаляется из списка, как показано на рис. 3.12, б. Такая организация таймеров не требует выполнения большой работы при каждом прерывании от системных часов, хотя при работе процедур start_timer и stop_t.imer требуется сканирование списка. В протоколе у данных процедур имеется входной параметр, означающий номер кадра, таймер которого нужно запустить или остановить.