8.4.4Пример протокола

Рассмотрим простой пример протокола, который состоит из двух агентов: отправителя и получателя. Задачей протокола является организация доставки кадров от отправителя получателю через ненадёжный канал связи (который может искажать и терять передаваемые кадры).

Работа протокола происходит следующим образом.

1.Отправитель получает сообщения от процесса, не входящего в протокол, который называется сетевым уровнем (СУ) отправителя. Эти сообщения называются пакетами. Задача отправителя заключается в периодическом выполнении следующих действий:

•получить очередной пакет от своего СУ

•сформировать из этого пакета кадр

•послать этот кадр в канал связи и включить таймер

•если таймер пришлёт сигнал timeout (который означает, что время ожидания подтверждения посланного кадра закончилось, и, видимо, этот кадр до получателя не дошёл), то послать этот кадр ещё раз

•если придёт подтверждение от получателя, то это означает, что текущий кадр дошёл до него успешно, и можно

–получать следующий пакет от своего СУ,

–формировать из него кадр,

–и т.д.

Блок-схема, представляющая описанное выше поведение, выглядит следующим образом:

259

Операторы, входящие в эту блок-схему, имеют следующий смысл.

•In ? x – получение отправителем очередного пакета от своего СУ, и запись этого пакета в переменную x

•C ! ϕ(x) – отправление в канал связи кадра ϕ(x)

•start ! – включение таймера

•timeout ? – получение от таймера сигнала timeout

•C ? – получение из канала связи сигнала подтверждения

Процесс, представляемый этой блок-схемой, обозначается знакосочетанием Sender и имеет следующий вид:

260

timeout ?

Процесс отправителя является параллельной композицией (с ограничением)

•процесса Sender, и

•процесса Timer, представляющего поведение таймера, и имеющего вид

Начальное условие процесса Timer: t = 0.

В этой модели мы не детализируем величину промежутка времени между

–запуском таймера (действие start?), и

–посылкой им сигнала timeout.

2.Канал связи (называемый ниже просто каналом) в каждый момент времени может содержать не более одного кадра или сигнала. Он может выполнять следующие действия:

•получение кадра от отправителя, и

–пересылка этого кадра получателю, или

–пересылка получателю искажённого кадра, или

261

–потеря кадра

•получение сигнала подтверждения от получателя, и

–пересылка этого сигнала отправителю, или

–потеря сигнала.

Поведение канала представляется следующим процессом:

> ? > ?

В этом процессе мы используем следующую абстракцию: символ ‘ ’ означает “искажённый кадр”. Мы не уточняем, как именно искажаются кадры в канале. Каждый кадр, поступивший в канал

•либо передаётся из канала в неизменном виде получателю,

•либо пребразуется в абстрактное значение ‘ ’, и это значение передаётся из канала получателю

•либо пропадает, что выражается переходом процесса (8.22) с меткой > ?

3.Получатель периодически выполняет следующие действия:

•получение из канала очередного кадра

•проверка наличия искажений в кадре

•если кадр не искажён, то

–извлечение из кадра пакета,

262

–передача этого пакета процессу, называемому сетевой уровень (СУ) получателя (этот процесс не входит в протокол)

–посылка отправителю через канал сигнала подтверждения

•если кадр искажён, то получатель его игнорирует (предполагая, что отправитель, не дождавшись подтверждения, пошлёт это кадр ещё раз)

Блок-схема, представляющая описанное выше поведение, выглядит следующим образом:

Операторы, входящие в эту блок-схему, имеют следующий смысл.

•C ? f – получение из канала очередного кадра, и запись его в переменную f

•(f = ) – проверка наличия искажения в кадре f

•Out ! info(f) – отправление пакета info(f), извлечённого из кадра f, своему СУ

•C ! – посылка сигнала подтверждения

Процесс, представляемый этой блок-схемой, обозначается знакосочетанием Receiver и имеет следующий вид:

263

a YHH

6HHH

Out ! info(f)

Процесс Protocol, соответствующий всему протоколу, определяется как параллельная композиция (с ограничением) вышеперечисленных процессов:

Потоковый граф этого процесса имеет следующий вид:

T imer

264

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

Если мы хотим специфицировать только свойства внешних действий, выполняемых этим протоколом (т.е. действий, имеющих вид In ? v и Out ! v), то спецификация может выглядеть следующим образом: поведение данного протокола совпадает с поведением буфера размера 1, т.е. процесс Protocol наблюдаемо эквивалентен процессу Buf , который имеет вид

При построении процесса с СО, соответствующего выражению (8.23), и его редукции, получается диаграмма

которая наблюдаемо эквивалентна диаграмме

In ? x * 6

> ? Out ! info(ϕ(x)) (8.26)

YHH

HH

> ?HHHH ?

265

Если мы предположим, что функция info извлечения пакетов из кадров является обратной к функции ϕ формирования кадров, т.е. для каждого пакета x имеет место соотношение

info(ϕ(x)) = x

то диаграмму (8.26) можно перерисовать следующим образом:

In ? x * 6

> ? Out ! x (8.27)

YHH

HH

> ?HHHH ?

Процесс (8.27) можно редуцировать, в результате чего получается процесс

При сопоставлении процессов (8.28) и (8.25) можно заключить, что данные процессы не могут быть эквивалентными ни в каком приемлемом смысле. Например,

•процесс (8.25) после получения пакета x может только

–передать этот пакет СУ получателя, и

–перейти в состояние ожидания следующего пакета

•в то время как процесс (8.28) может после получения пакета x передать этот пакет СУ получателя несколько раз.

Такая повторная передача может происходить, например, при следующем варианте работы протокола.

266