Симплексный протокол для зашумленных каналов
На первый взгляд может показаться, что нужно лишь добавить таймер к протоколу 2. Получатель будет возвращать подтверждение только в случае получения правильных данных. Неверные пакеты будут просто игнорироваться. Через некоторое время у отправителя истечет интервал времени, и он отправит кадр еще раз. Этот процесс будет повторяться до тех пор, пока кадр, наконец, не прибудет в целости.
В приведенной выше схеме имеется один критический недостаток. Прежде чем читать дальше, попытайтесь понять, что же неверно в данном алгоритме.
Чтобы осознать, чем плох данный вариант протокола, вспомните, что задача уровня передачи данных заключается в предоставлении безошибочной прозрачной связи между двумя процессами сетевого уровня.
Сетевой уровень машины А передает серию пакетов своему уровню передачи данных, который должен гарантировать доставку идентичной серии пакетов сетевому уровню машины В ее уровнем передачи данных. В частности, сетевой уровень машины В не может распознать недостачу пакета или дублирование пакета, поэтому уровень передачи данных должен гарантировать, что дублирования пакетов не произойдет ни при каких обстоятельствах.Рассмотрим следующий сценарий.
1. Сетевой уровень машины А передает пакет 1 своему уровню передачи данных. Пакет доставляется в целости на машину В и передается ее сетевому уровню. Машина В посылает кадр подтверждения назад на машину А.
2. Кадр подтверждения полностью теряется в канале связи. Он просто не попадает на машину А. Все было бы намного проще, если бы терялись только информационные — но не управляющие — кадры, однако канал связи, к сожалению, не делает между ними большой разницы.
3. У уровня передачи данных машины А внезапно истекает отведенный интервал времени. Не получив подтверждения, он предполагает, что посланный им кадр с данными был поврежден или потерян, и посылает этот кадр еще раз.
4. Дубликат кадра прибывает на уровень передачи данных машины В и передается на сетевой уровень. Если машина А посылала на машину В файл, то часть этого файла продублировалась, таким образом, копия файла на машине В будет неверной. Другими словами, протокол допустил ошибку.
5. Понятно, что необходим некий механизм, с помощью которого получатель смог бы отличать новый кадр от переданного повторно. Наиболее очевидным способом решения данной проблемы является помещение отправителем порядкового номера кадра в заголовке кадра. Тогда по номеру кадра получатель смо-
—- жет понять, новый это кадр или дубликат.
Поскольку отводить в кадре много места под заголовок нежелательно, возникает вопрос: каково минимальное количество бит, достаточное для порядкового номера кадра? Единственная неопределенность в данном протоколе может возникнуть между кадром т и следующим за ним кадром т + 1. Если кадр т потерян или поврежден, получатель не подтвердит его и отправитель пошлет его еще раз. Когда он будет успешно принят, получатель пошлет отправителю подтверждение. Именно здесь находится источник потенциальной проблемы. В зависимости от того, будет получено подтверждение или нет, отправитель может послать кадр т или кадр т + 1.
Отправитель может начать посылать кадр т + 2 только когда получит подтверждение получения кадра т + 1. Но это означает, что кадр т уже был отправлен и подтверждение его получения было отправлено и получено. Следовательно, неопределенность может возникнуть только между двумя соседними кадрами.
Таким образом, должно быть достаточно всего одного бита информации (со значением 0 или 1). В каждый момент времени получатель будет ожидать при
бытия кадра с определенным порядковым номером. Кадр с неверным номером будет отбрасываться как дубликат. Кадр с верным номером принимается, передается сетевому уровню, после чего номер следующего ожидаемого кадра увеличивается по модулю 2 (то есть 0 становится 1, а 1 — 0).
Пример подобного протокола приведен в листинге 3.4. Протоколы, в которых отправитель ожидает положительного подтверждения, прежде чем перейти к пересылке следующего кадра, часто называются PAR (Positive Acknowledgement with Retransmission — положительное подтверждение с повторной передачей) или ARQ, (Automatic Repeat reQuest — автоматический запрос повторной передачи). Подобно протоколу 2, он также передает данные только в одном направлении.
Листинг 3.4. Протокол с положительным подтверждением и повторной передачей
Протокол 3 отличается от своих предшественников тем, что и отправитель, и получатель запоминают номера кадров. Отправитель запоминает номер следующего кадра в переменной пех1_1тате_бо_5епб, а получатель запоминает порядковый номер следующего ожидаемого кадра в переменной ^ате_ехрес1еб. Перед бесконечным циклом в каждой процедуре размещена короткая фаза инициализации.
Передав кадр, отправитель запускает таймер. Если он уже был запущен, он настраивается на отсчет нового полного интервала времени. Период выбирается достаточно большим, чтобы даже в худшей ситуации кадр успел дойти до получателя, получатель успел его обработать и подтверждение успело вернуться к отправителю. Только по истечении отведенного времени можно утверждать, что потерялся кадр или его подтверждение, а значит, необходимо послать дубликат.
Если время, после которого наступает тайм-аут, сделать слишком коротким, то передающая машина будет повторно посылать слишком много кадров, в которых нет необходимости. Хотя лишние кадры в данном случае не повлияют на правильность приема данных, они повлияют на производительность системы.После передачи кадра отправитель запускает таймер и ждет какого-либо события. Возможны три ситуации: либо придет неповрежденный кадр подтверждения, либо будет получен поврежденный кадр подтверждения, либо просто истечет интервал времени. В первом случае отправитель возьмет у сетевого уровня следующий пакет и положит его в буфер поверх старого пакета. Кроме того, он увеличит порядковый номер кадра. Если же прибудет поврежденный кадр подтверждения или подтверждение не придет вовсе, то ни буфер, ни номер не будут изменены и будет послан дубликат кадра.
Когда неповрежденный кадр прибывает к получателю, проверяется его номер. Если это не дубликат, то кадр принимается и передается сетевому уровню, после чего формируется подтверждение. Дубликаты и поврежденные кадры на сетевой уровень не передаются.
Еще по теме Симплексный протокол для зашумленных каналов:
- В. Г. Олифер, Н. А. Олифер. 54 Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов. 3-е изд, 2006
- 9.13. Передне-срединный канал, VC (фр.), круглосуточно, канал "инь"
- 9.2. Канал толстой кишки, GI (франц.), 5-7 час., канал "ян"
- 9.19. Лечебно-профилактический массаж по системе До-Ин (общий для всех каналов)
- 9.6. Канал тонкой кишки, IG (фр.), 13-15 час., канал "ян"
- 9.4. Канал селезенки-поджелудочной железы, RP, 9-11 час., канал "ян"
- Рекомендации Крайона Магнитному Каналу и всем каналам Духа
- 9.8. Канал почек, R (фр.), 17-19 час., канал "инь"
- 9.12. Канал печени, F (фр.), 1-3 час., канал "инь"
- 9.14. Задне-срединный канал, VG, (фр.), круглосуточно, канал "ян"
- Выбор кода для входа в информационный канал Вселенной и правила работы маятником на информационном уровне находятся вне компетенции автора.
- Глава 4. Киотский протокол в Украине
- § 6. Протокол судебного заседания
- Судебные протоколы вообще