Особенности и алгоритмы кодирования голоса

2.1. Алгоритмы работы каналов

В реальной жизни мы сталкиваемся с самыми разными задачами при передаче данных. Вариации проблем сопряжены с объемами пересылаемых данных, со скоростями обмена, требуемыми задержками, надежностью и т.д. На будущее будем считать, что физический, канальный и сетевой уровни передачи данных являются независимыми процессами.

Предположим также, что машина А собирается передать машине Б поток данных с гарантированной доставкой (обычно это называется передачей, ориентированной на соединение). Вообще говоря, вполне реалистичен сценарий, когда машина Б одновременно намерена передавать данные машине А. В рассматриваемой модели будем считать, что имеется неограниченный объем данных, подлежащих передаче, и не требуется времени по их извлечению. Данные обычно передаются форматированными порциями, называемыми пакетами или кадрами.

С точки зрения канального уровня пакет, пришедший от сетевого уровня, является просто данными, каждый бит которых должен быть доставлен сетевому уровню места назначения. Тот факт, что сетевой уровень места назначения будет интерпретировать какие-то биты, как заголовок, канальным уровнем игнорируется. Когда канальный уровень получает пакет, он инкапсулирует его в свой кадр, добавляя некоторую управляющую информацию (протокольный заголовок). Заголовок обычно структурируется и содержит несколько полей различной длины. Этот преобразованный пакет передается другому канальному уровню. Здесь предполагается, что существует необходимая библиотека процедур для приема-передачи кадров на физическом уровне. Приемное устройство является пассивным и просто ждет прихода пакета. Получив кадр, входной сетевой интерфейс осуществляет проверку контрольной суммы этого кадра — если она некорректна, канальный уровень информируется об этом. Если все в порядке, производится разборка заголовка. Хорошей практикой является правило, запрещающее передачу любых полей заголовка с уровня на уровень (это гарантирует их независимость). Этот принцип упрощает модификацию программного обеспечения, ведь программы сетевого уровня не обязаны что-либо знать о канальном протоколе и наоборот.

Канал предполагается ненадежным, по этой причине возможно искажение или даже потеря пакета. Факт потери пакета может быть установлен в случае отсутствия отклика получателя, подтверждающего успешную доставку. В случае искажения пакета подтверждение не посылается. При посылке пакета запускается таймер; если за время работы таймера отклик не получен, пакет считается потерянным. Как было указано выше, пакеты образуют последовательность (поток). По этой причине нужно уметь определять, доставка какого пакета подтверждена. Для решения этой задачи в заголовок пакета включается уникальный номер, которым снабжается и отклик. Такой номер позволяет найти соответствие между посланным пакетом и откликом, подтверждающим его доставку. Код номера пакета лежит в интервале 0 — MAX_SEQ (различно для разных протоколов.).

Простейший вариант протокола предполагает, что очередной пакет может быть послан лишь после получения подтверждения доставки предыдущего ( Simplex Stop-and-Wait ), причем данные следуют только в одном направлении.

На практике большинство протоколов предполагают двухсторонний обмен (full duplex), кроме того, при больших временах доставки алгоритм Stop-and-Wait сильно ограничивает скорость обмена. В таких случаях используется алгоритм со скользящим окном, где можно послать несколько пакетов, не дожидаясь отклика (см., например, описание протокола TCP ). Размер окна определяет число посылаемых пакетов до того, как будет получено подтверждение на первый посланный пакет в рамках окна. После получения отклика окно смещается на единицу и позволяет послать еще один пакет. При размере скользящего окна, равном 1, такой протокол становится эквивалентен схеме Stop-and-Wait. Алгоритм со скользящим окном известен в системах обработки данных как конвейер ( pipelining ). Он требует наличия таймера для каждого из посланных пакетов в пределах окна. В этом алгоритме возникает проблема, когда теряется какой-то пакет. Что делать с кадрами, посланными вслед за ним и получившими подтверждение? Следует учесть, что приемный канальный уровень обязан обрабатывать пакеты сетевого уровня строго по порядку (ведь они образуют единую последовательность).

Здесь существует два решения. Первое: выбросить все подтвержденные пакеты, посланные после потерянного, и повторить их пересылку еще раз (так работает базовая версия протокола TCP ), приемный буфер при этом предназначен для записи лишь одного пакета. При двустороннем обмене отклики могут "прикрепляться" к информационным пакетам, движущимся в противоположном направлении. Если загрузка канала велика и вероятность потери пакета составляет несколько процентов, этот алгоритм весьма неэффективен. При сильно асимметричном трафике пакеты-отклики могут посылаться и самостоятельно. Для этого должен быть введен дополнительный таймер. Если за время выдержки нет ни одного "попутного" информационного пакета, то отклик посылается сам по себе. Время выдержки такого таймера должно быть достаточно коротким, чтобы не слишком замедлять работу алгоритма обмена.

Другой стратегией является селективная повторная пересылка лишь потерянного кадра (метод реализуется в протоколе XTP ). Эта схема требует большого объема памяти на канальном уровне, если размер окна достаточно велик. При получении очередного пакета проверяется его порядковый номер. Если этот номер соответствует окну, пакет записывается в буфер, даже если его номер не является тем, который ожидается. Эта операция производится на канальном уровне и пакет не передается сетевому уровню, пока не будут получены пакеты, посланные раньше. Размер приемного буфера в этом случае должен соответствовать ширине скользящего окна. Здесь возможны вариации стратегии, когда, например, отклик приходит на пакет с номером 2 (в пределах окна), но на пакет 1 его пока нет (а именно подтверждение прихода этого пакета дает команду на сдвиг окна, разрешающего посылку очередного пакета).

Рассмотрим пример, когда посылается группа пакетов 01234. Теперь предположим, что пакет 0 по таймауту признан неподтвержденным, послан пакет 5, пакет 2 не подтвержден и послан пакет 6. Тогда список пакетов, ждущих подтверждения, приобретет вид 3405126. Если признать, что имеется возможность не подтверждения некоторых из этих пакетов, то структура этого списка еще более усложнится. Отсюда видно, что формирование и обслуживание такого рода очередей — отнюдь не простая задача.

Предположим, что MAX_SEQ = 10, отправитель послал 10 пакетов, один из них был потерян и послан повторно. После этого началась посылка очередных 10 пакетов и получение откликов на их доставку. Возникает вопрос: где гарантия того, что пришедший отклик не относится к пакету, "потерянному" в предыдущей последовательности? Здесь все зависит от значения удвоенной задержки доставки ( RTT — Round Trip Time). Если канал является быстродействующим, а задержка велика, как это имеет место в спутниковых каналах, такое вполне возможно. В этом случае следует подумать об увеличении MAX_SEQ. Помимо обычного подтверждения, в случае обнаружения ошибки может быть послано "отрицательное" подтверждение ( NAK ), которое представляет собой запрос повторной посылки оговоренного в отклике пакета. Причиной посылки NAK может быть получение поврежденного пакета, или нарушение порядка поступления кадров, что вызвало подозрение потери пакета. Получатель должен отслеживать ситуацию, чтобы исключить повторную посылку NAK для одного и того же кадра. Потеря NAK не опасна, так как отправитель, не получив подтверждения, все равно запустит процедуру повторной пересылки пакета. Величина RTT и его дисперсия определяют устанавливаемое значение таймаута.

Историческими предшественниками стека Интернет были протоколы, возникшие на базе разработанного компанией IBM стандарта SDLC (Synchronous Data Link Control). Этот стандарт был предложен компанией в ANSI и в организацию ISO в качестве международного проекта. ANSI модифицировала его, и он превратился в ADCCP (Advanced Data Communication Control Procedure), а ISO на основе предложенного протокола разработала стандарт HDLC (high-level Data Link Control). Международная организация по телекоммуникациям CCITT адаптировала HDLC для протокола X.25 ( LAP - Link Access Procedure). Все они бит-ориентированы и используют bit-stuffing. Формат используемых кадров показан на рис. 2.15 (в нижней части рисунка приведены размеры полей в битах). Октеты - разграничители кадров F несут в себе код 0x7E.

Рис. 2.15. Формат кадров бит-ориентированных протоколов

Поле адрес служит для выделения определенного терминала (идентификатор терминала). При соединении "точка-точка" это поле иногда служит для разделения запроса и отклика.

Поле управление служит для записи номера по порядку для установления соответствия между посланным кадром и откликом.

Поле информация может иметь произвольную длину, а поле FCS (Frame Control Sum) является контрольной суммой, вычисляемой согласно алгоритму CRC. Минимально кадр содержит 4 байта, не считая стартового и финального разграничителей. Предусмотрено три типа кадров: информационные, управляющие (supervisory) и ненумерованные. Коды поля управления этих кадров представлены на рис. 2.16. Протокол использует при передаче алгоритм скользящего окна со значением номера по порядку, имеющим 3 бита. В любой момент времени до семи ненумерованных кадров могут ожидать подтверждения. Для современных коммуникаций 3 бита для номера по порядку ( MAX_SEQ ) крайне мало.

Рис. 2.16. Формат поля управления для информационных (I), управляющих (II) и ненумерованных (III) кадров

В верхней части рис. 2.16 указаны размеры полей в битах. Поле Seq содержит порядковый номер кадра. Поле следующий служит для подтверждения успешно доставленных кадров. Допускается также размещение здесь номера следующего (ожидаемого) кадра. Поле P/F (Poll/Final) используется, когда ЭВМ обращается к группе терминалов. P = 1, когда машина предлагает терминалу прислать данные. Все кадры, приходящие от терминала, кроме последнего, содержат P = 1. Равенство бита нулю означает, что это последний кадр (F). В некоторых модификациях протокола бит P/F используется, чтобы заставить другую машину прислать управляющий кадр, а не сменить направление обмена данными. Тип управляющего (supervisory) кадра определяется содержимым поля тип. Возможные значения этого поля приведены в таблице 2.2.

Как видно из таблицы, тип = 0 означает, что кадр служит для подтверждения получения предыдущего кадра и готовности получить следующий. Тип = 1 является отрицательным подтверждением (NAK). Тип = 3 призывает повторить посылку кадра с указанным номером.

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

Люди, работающие на ЭВМ дома, часто подсоединяются к Интернету посредством модема через коммутируемую телефонную сеть с привлечением протоколов SLIP или PPP. Схема подключения показана на рис. 2.17.

Рис. 2.17. Подключение ЭВМ через модем и цифровую телефонную станцию

Рис. 2.18. Подключение к Интернету через модемный пул

Если телефонная станция — аналоговая, то кодеки не нужны. Число промежуточных телефонных станций может варьироваться в широких пределах. Сервис-провайдеры обычно имеют у себя модемные пулы, которые позволяют подключиться большому числу клиентов одновременно ( рис. 2.18).

В традиционной телефонной сети для соединения с требуемым клиентом используются аппаратные коммутаторы. Если коммутатор имеет N входов и N выходов, то число коммутирующих ключей будет равно N² и одновременно можно реализовать не более N связей. Реально это число всегда меньше, и клиент слышит в трубке "короткие гудки" сигнала "занято". На рис. 2.19 показана обобщенная схема большой телефонной сети.

Рис. 2.19. Схема телефонной сети