Протокол «Утопия» абсолютно нереалистичен, так как он не умеет ни управлять потоком данных, ни исправлять ошибки. Принцип его работы схож с сервисом без подтверждения и без установки соединения, который надеется, что все эти проблемы решаются на более высоких уровнях. Однако даже такой сервис все же обладает некоторыми способностями распознавать ошибки.

3.3.2. Симплексный протокол с ожиданием для канала без ошибок

Теперь мы отбросим самое нереальное предположение, использованное в протоколе 1, — способность получающего сетевого уровня мгновенно обрабатывать приходящие данные. Очень часто возникают ситуации, когда отправитель посылает данные слишком быстро, и получатель не успевает обработать их. Следовательно, очень важно предотвращать такие заторы. Сохраняется предположение о том, что в канале связи нет ошибок. Линия связи остается симплексной.

Одно из решений — сконструировать получатель таким образом, чтобы его мощности хватало на обработку непрерывного потока последовательных кадров (или же определить канальный уровень так, чтобы информация пересылалась достаточно медленно, не вызывая перегрузки получателя). У получателя должен быть буфер большого объема, а его скорость должна быть не ниже скорости пересылки данных. Кроме того, он должен уметь быстро отдавать кадры сетевому уровню. Это наихудшее из возможных решений. Оно требует специального оборудования, и если линия загружена слабо, то ресурсы расходуются зря. Кроме того, он всего лишь перекладывает проблему слишком быстрой пересылки кадров на чужие плечи: в данном случае ее приходится решать сетевому уровню.

Лучшим решением данной проблемы является обратная связь со стороны получателя. Передав пакет сетевому уровню, получатель посылает небольшой управляющий пакет отправителю, разрешая тем самым посылать следующий кадр. Отправитель, отослав кадр, должен ждать разрешения на отправку следующего кадра. Подобная задержка — это простейший пример протокола с управлением потоком.

Протоколы, в которых отправитель посылает один кадр, после чего ожидает подтверждения, называются протоколами с ожиданием (stop-and-wait). В листинге 3.3 приведен пример симплексного протокола с ожиданием.

Листинг 3.3. Симплексный протокол с ожиданием

Хотя пересылка данных в этом примере осуществляется по симплексному принципу, только от отправителя получателю, кадры в действительности путешествуют в обоих направлениях. Следовательно, коммуникационный канал между двумя канальными уровнями должен поддерживать пересылку информации в обе стороны. Однако данный протокол диктует строгое чередование направлений пересылки: сначала отправитель посылает кадр, затем получатель посылает кадр, потом снова отправитель, потом получатель и т. д. Для такой реализации хватило бы полудуплексного физического канала.

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

Единственное отличие процедуры receiver2 от receiverl заключается в том, что после передачи пакета сетевому уровню receiver2 посылает кадр подтверждения обратно отправителю, после чего идет на следующую итерацию цикла. Поскольку для отправителя важно только прибытие ответного кадра, а не его содержание, то получателю не нужно заполнять кадр специальной информацией.

3.3.3. Симплексный протокол с ожиданием для зашумленных каналов

Теперь рассмотрим реальную ситуацию: канал связи, в котором могут быть ошибки. Кадры могут либо портиться, либо теряться. Однако мы будем предполагать, что если кадр будет поврежден при передаче, то приемная аппаратура определит это при подсчете контрольной суммы. Если кадр будет поврежден таким образом, что контрольная сумма совпадет, что очень маловероятно, то этот протокол (и любой другой протокол) передаст неверный пакет сетевому уровню.

На первый взгляд может показаться, что нужно лишь добавить таймер к протоколу 2. Получатель будет возвращать подтверждение только в случае получения правильных данных. Неверные пакеты будут просто игнорироваться. Через некоторое время у отправителя истечет интервал времени, и он отправит кадр еще раз. Этот процесс будет повторяться до тех пор, пока кадр, наконец, не прибудет в целости.

В приведенной выше схеме имеется один критический недостаток. Прежде чем читать дальше, попытайтесь понять, что же неверно в данном алгоритме.

Чтобы осознать, чем плох данный вариант протокола, вспомните, что цель канального уровня заключается в предоставлении безошибочной прозрачной связи между

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

Рассмотрим следующий сценарий.

1.    Сетевой уровень машины A передает пакет 1 своему канальному уровню. Пакет доставляется в целости на машину B и передается ее сетевому уровню. Машина B посылает кадр подтверждения назад на машину A.

2.    Кадр подтверждения полностью теряется в канале связи. Он просто не попадает на машину A. Все было бы намного проще, если бы терялись только информационные — но не управляющие — кадры, однако канал связи, к сожалению, не делает между ними большой разницы.

3.    У канального уровня машины A внезапно истекает отведенный интервал времени. Не получив подтверждения, он предполагает, что посланный им кадр с данными был поврежден или потерян, и посылает этот кадр еще раз.

4.    Дубликат кадра в целости прибывает на канальный уровень машины B и передается на сетевой уровень. Если машина A посылала на машину B файл, то часть этого файла продублировалась, таким образом, копия файла на машине B будет неверной. Другими словами, протокол допустил ошибку.

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

Поскольку протокол должен быть нейтральным и эффективным, отводить в кадре много места под заголовок нежелательно. Возникает вопрос: каково минимальное количество бит, достаточное для порядкового номера кадра? В заголовке можно выделить 1 бит, несколько бит, 1 байт или несколько байт. Важно, чтобы порядковые номера были достаточно большими для правильной работы протокола, или же от протокола будет мало толку.

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