Эндрю Уэзеролл - Компьютерные сети. 5-е издание

Единственная неопределенность в данном протоколе может возникнуть между кадром m и следующим за ним кадром m + 1. Если кадр m потерян или поврежден, получатель не подтвердит его, и отправитель пошлет его еще раз. Когда он будет успешно принят, получатель пошлет отправителю подтверждение. Именно здесь находится источник потенциальной проблемы. В зависимости от того, будет получено подтверждение или нет, отправитель может послать кадр m или кадр m + 1.

На стороне отправителя событием, запускающим передачу кадра m + 1, является прибытие подтверждения получения кадра m. Но это означает, что кадр m - 1 уже был отправлен и подтверждение его получения было отправлено и получено. В противном случае протокол не стал бы посылать новый кадр. Следовательно, неопределенность может возникнуть только между двумя соседними кадрами.

Таким образом, должно быть достаточно всего одного бита информации (со значением 0 или 1). В каждый момент времени получатель будет ожидать прибытия кадра

с определенным порядковым номером. Кадр с верным номером принимается, передается сетевому уровню, затем отправляется подтверждение его получения. Номер следующего ожидаемого кадра увеличивается по модулю 2 (то есть 0 становится 1, а 1 — 0). Кадр с неверным номером отбрасывается как дубликат. Однако последнее подтверждение повторяется, чтобы сообщить отправителю, что кадр получен полностью.

Пример подобного протокола приведен в листинге 3.4. Протоколы, в которых отправитель ожидает положительного подтверждения, прежде чем перейти к пересылке следующего кадра, часто называются PAR( Positive Acknowledgement with Retransmission— положительное подтверждение с повторной передачей) или ARQ ( Automatic Repeat reQuest— автоматический запрос повторной передачи). Подобно протоколу 2, он также передает данные только в одном направлении.

Листинг 3.4.Протокол с положительным подтверждением и повторной передачей

/* Протокол 3 (PAR) обеспечивает симплексную передачу данных по ненадежному каналу. */

Листинг 3.4 (продолжение)

Протокол 3 отличается от своих предшественников тем, что и отправитель, и получатель запоминают номера кадров. Отправитель запоминает номер следующего кадра в переменной next_frame_to_send, а получатель запоминает порядковый номер следующего ожидаемого кадра в переменной frame_expected. Перед бесконечным циклом в каждой процедуре размещена короткая фаза инициализации.

Передав кадр, отправитель запускает таймер. Если он уже был запущен, он настраивается на отсчет нового полного интервала времени. Период выбирается достаточно большим, чтобы даже в худшей ситуации кадр успел дойти до получателя, получатель успел его обработать и подтверждение успело вернуться к отправителю. Только по истечении отведенного времени можно утверждать, что потерялся кадр или его подтверждение, а значит, необходимо послать дубликат. Если время, после которого наступает тайм-аут, сделать слишком коротким, то передающая машина будет повторно посылать слишком много кадров, в которых нет необходимости. Хотя лишние кадры в данном случае не повлияют на правильность приема данных, они повлияют на производительность системы.

После передачи кадра отправитель запускает таймер и ждет какого-либо события. Возможны три ситуации: либо придет неповрежденный кадр подтверждения, либо будет получен поврежденный кадр подтверждения, либо просто истечет интервал времени. В первом случае отправитель возьмет у сетевого уровня следующий пакет и положит его в буфер, поверх старого пакета. Кроме того, он увеличит порядковый номер кадра. Если же прибудет поврежденный кадр подтверждения или время истечет, то ни буфер, ни номер не будут изменены, и будет послан дубликат кадра. В любом случае затем отправляется содержимое буфера (либо следующий пакет, либо дубликат предыдущего).

Когда неповрежденный кадр прибывает к получателю, проверяется его номер. Если это не дубликат, то кадр принимается и передается сетевому уровню, после чего формируется подтверждение. Дубликаты и поврежденные кадры на сетевой уровень не передаются, но при их получении подтверждается прибытие последнего правильного кадра, благодаря чему отправитель понимает, что нужно перейти к следующему кадру или повторить пересылку поврежденного.

3.4. Протоколы скользящего окна

В предыдущих протоколах информационные кадры передавались только в одну сторону. В большинстве практических ситуаций требуется передача данных в обоих направлениях. Один из способов получения дуплексной передачи — использование двух экземпляров описанных выше протоколов, каждый из которых передает данные по отдельной симплексной связи (в противоположных направлениях). При этом физический канал имеет прямой канал для данных и обратный канал для подтверждений. В обоих случаях пропускная способность обратных каналов почти не используется.

Более прогрессивной идеей представляется использование одного канала для передачи данных в обоих направлениях. В конце концов, ведь в протоколах 2 и 3 кадры уже передавались по каналу в двух направлениях, а обратный канал обладает той же пропускной способностью, что и прямой. В такой модели кадры с данными от машины A для машины B перемешиваются с кадрами подтверждений от A к B. Получатель может отличить кадр с данными от кадра с подтверждением по специальному полю kind заголовка кадра.

Помимо чередования кадров с подтверждениями и информационных кадров, возможно и другое улучшение протокола. Приняв кадр с данными, получатель может не посылать сразу кадр с подтверждением, а подождать, пока сетевой уровень даст ему следующий пакет. Подтверждение добавляется к исходящему информационному кадру с помощью поля ack заголовка кадра. В результате для передачи подтверждения почти не будет затрачено ресурсов. Подобная техника называется piggybacking (комбинированная или ярусная перевозка).

Основное преимущество совмещения передачи прямых и обратных пакетов заключается в улучшенном использовании пропускной способности канала. Поле ack в заголовке кадра занимает всего несколько бит, тогда как отдельный кадр потребует заголовка и контрольной суммы. Кроме того, чем меньше количество прибывающих кадров, тем меньше нагрузка на получателя. В следующем рассматриваемом нами протоколе расходы на совмещение передачи прямых и обратных пакетов составляют всего 1 бит заголовка кадра. Эти расходы редко превышают несколько бит.