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

В качестве первого примера мы рассмотрим самый простой протокол. Данные передаются только в одном направлении, и он даже не задумывается о том, что где-то может произойти ошибка. Сетевой уровень на передающей и приемной стороне находится в состоянии постоянной готовности. Временем обработки можно пренебречь. Размер буфера неограничен. И что лучше всего, канал связи между канальными уровнями никогда не теряет и не искажает кадры. Этот совершенно нереальный протокол, который мы назовем «Утопия», показан в листинге 3.2. Он всего лишь демонстрирует базовую структуру, необходимую для построения настоящего протокола.

Протокол состоит из двух процедур, senderl (отправитель) и receiverl (получатель). Процедура senderl работает на канальном уровне посылающей машины, а процедура receiverl — на канальном уровне принимающей машины. Ни последовательные номера, ни подтверждения не используются, поэтому MAX_SEQ не требуется. Единственным возможным событием является frame_arrival (то есть прибытие неповрежденного кадра).

Процедура sender1 представляет собой бесконечный цикл, начинающийся с оператора while, посылающий данные на линию с максимально возможной скоростью. Тело цикла состоит из трех действий: получения пакета (всегда обязательное) с сетевого уровня, формирования исходящего пакета с помощью переменной s и отсылки пакета адресату. Из служебных полей кадра данный протокол использует только поле info, поскольку другие поля относятся к обработке ошибок и управлению потоком, которые в данном протоколе не применяются.

Процедура принимающей стороны ничуть не сложнее. Вначале она ожидает, пока что-нибудь произойдет, причем единственно возможным событием в данном протоколе может быть получение неповрежденного пакета. Когда пакет появляется, процедура wait_for_event возвращает управление, при этом переменной event присваивается значение frame_arrival (которое все равно игнорируется). Обращение к процедуре from_physical_layer удаляет вновь прибывший кадр из аппаратного буфера и помещает его в переменную r. Наконец, порция данных передается сетевому уровню, а канальный уровень отправляется ждать следующий кадр.

Листинг 3.2. Неограниченный симплексный протокол «Утопия»

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

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

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

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

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

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

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