На стороне отправителя событием, запускающим передачу кадра 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 бит заголовка кадра. Эти расходы редко превышают несколько бит.
Однако при совмещении передачи прямых и обратных пакетов в протоколе появляются новые проблемы. Как долго должен канальный уровень ждать пакета, с которым следует переслать подтверждение? Если канальный уровень будет ждать дольше, чем отправитель, то последний пошлет кадр повторно, что неприемлемо. Если бы канальный уровень мог предсказывать будущее, он бы знал, ждать ему пакета или отправлять подтверждение отдельным кадром. Это, конечно, невозможно, поэтому следует установить еще один интервал ожидания (меньший, чем интервал ожидания отправителя), по истечении которого подтверждение отправляется отдельным кадром. Если же сетевой уровень успеет передать уровню передачи данных пакет, то подтверждение будет отослано вместе с этим пакетом в одном кадре.
Следующие три протокола являются двунаправленными и принадлежат к классу протоколов скользящего окна (sliding window). Как будет показано ниже, они отличаются друг от друга эффективностью, сложностью и требованиями к размерам буфера. Во всех протоколах скользящего окна каждый исходящий кадр содержит порядковый номер (варьирующийся от 0 до некоего максимума). Поскольку на этот номер обычно отводится поле размером n бит, максимальное значение номера составляет 2п - 1. В протоколах скользящего окна с ожиданием обычно на это поле отводится всего один бит, что ограничивает порядковый номер значениями 0 и 1, однако в более сложных версиях может использоваться произвольное значение п.
Сущность всех протоколов скользящего окна заключается в том, что в любой момент времени отправитель работает с определенным набором порядковых номеров, соответствующих кадрам, которые ему разрешено посылать. Про такие кадры говорят, что они попадают в посылающее окно. Аналогично получатель работает с принимающим окном, соответствующим набору кадров, которые ему позволяется принять. Окно получателя и окно отправителя не обязаны иметь одинаковые нижний и верхний пределы и даже не обязаны быть одного размера. В одних протоколах размеры фиксируются, а в других размеры могут увеличиваться или уменьшаться по мере передачи или приема кадров.
