Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
VPS/VDS серверы. 30 локаций на выбор

Серверы VPS/VDS с большим диском

Хорошие условия для реселлеров

4VPS.SU - VPS в 17-ти странах

2Gbit/s безлимит

Современное железо!

Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

3.2. Подуровень конвергенции

В задачи подуровня конвергенции входит принятие от пользователя кадров данных размером до 65535 байт (как раз максимальный размер IP-пакета) и обеспечение на приеме контроля за правильностью доставки информации. Под контролем понимается наблюдение за обнаружение сбоев в последовательности принятых блоков и т.д.

Формат протокольного блока подуровня конвергенции представлен на рис.12. В его составе имеется 4-байтный заголовок и 4-байтный концевик. Поле PAD - это неинформационные добавочные биты, доводящие размер поля данных до величины, кратной 4 байтам.

Формат CPCS-PDU в AAL типа 3/4

Рис. 12. Формат CPCS-PDU в AAL типа 3/4

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

Поле Btag - начальная метка работает в паре с полем Etag - конечная метка. Дело в том, что поскольку размер протокольного блока может быть очень длинный, то когда подуровень сборки/разборки нарежет из этого блока много маленьких блоков фиксированной длины, начало и конец исходного блока попадут в разные селлы при передаче. На приеме же необходимо иметь жесткую связку начала и конца протокольного блока. Поэтому метки начала и конца в каждом блоке всегда одинаковые и увеличиваются на единицу после окончания формирования блока. Нумерация меток ведется в диапазоне от 0 до 255.

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

Итак, рассмотрим процесс работы подуровня конвергенции в комплексе. Когда соединение установлено, передатчик активизирует счетчик, по данным которого будет устанавливаться начальная и конечная метка первого блока. Когда этот блок приходит, передатчик создает заголовок протокольного блока, соединяет его блоком абонентских данных, дополняет объем этого абонентского блока до величины, кратной 4 байтам и прибавляет концевик. В результате получился протокольный блок подуровня конвергенции. Все это целиком отправляется на подуровень сборки/разборки, который нарежет его на куски фиксированной длины по 44 байта, присвоит каждому из них порядковый номер, защитит проверочным полиномом и отправит в канал.

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

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

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

 

Назад | Содержание | Вперед

 

VPS в 21 локации

От 104 рублей в месяц

Безлимитный трафик. Защита от ДДоС.

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...