2. Протоколи корекції помилок
Строго кажучи, протиставлення протоколу V.42 CCITT (the International Telegraph and Telephone Consultative Committee) і MNP (the Microcom Networking Protocol) не цілком коректно. Справа в тому, що Рекомендація V.42 CCITT - єдиний стандарт (за традицією званий "Рекомендація"), що описує всі розглянуті протоколи корекції оши-пліч. Те, що в побуті називається MNP2 і MNP3, є відповідно байт-орієнтований і біт-орієнтований режими протоколу, описаного в Додатку A до Рекомендації V.42, а то, що називається протоколом
V.42, - протокол, описаний в основній частині Рекомендації. Однак исто-річескі склалося так, що поява протоколів фірми Microcom пред-крокувало виходу "Блакитний Книги" CCITT з Рекомендацією V.42. Тому в подальшому застосовується склалася термінологія, яка хоч і не цілком коректна, зате проста і компактна.
Те, що через непорозуміння називають протоколом MNP4, протоколом насправді не є. Це не більше, ніж модифікована реалізація протоколів MNP2 і MNP3. А тому, зважаючи на відсутність предмета, згадка MNP4 в подальшому викладі відсутній.
Протокол корекції помилок визначає формат кадру, перелік до-допустимих типів кадрів, логічну структуру кадру кожного типу і влас-твенно протокол, тобто порядок установки режиму корекції помилок, виходу з режиму і допустимого чергування кадрів.
Протокол корекції помилок MNP2 є знак-орієнтованим про-токолом типу BSC (Binary Synchronous Communications). Його наявність або відсутність ніяк не зачіпає формат передачі байта по каналу: він піддається асинхронно-синхронного перетворення відповідно до Ре-комендації V.14 CCITT. Кожен елемент кадру - байт - складається з 8 ін-формаційних біт, передається по каналу послідовно, молодшим бітом вперед; видача першого біта передує стартовим бітом (0), службовцям синхросигналом приймача; після передачі останнього біта видається сто-повий біт (1). Якщо наступний байт не готовий до видачі, передається потік степових бітів. Таким чином можна вважати, що байт складається як міні-мум з 10 біт, включаючи один стартовий і один стоповий біти (абстрагується-Ясь від незначних в даному контексті подробиць, пов'язаних з ви-равніваніем швидкостей на комунікаційних інтерфейсах передавача і приймача).
З цієї обставини є два дуже істотних слідства. По-перше, процедура входу в протокол прозора і не вимагає спеці-ного синхронного перемикання обох модемів в якийсь специфічний режим роботи асинхронно-синхронного перетворення даних. У будь-який мо-мент модем може почати передачу символів, що не є самоцінним даними, а службовим полем кадру протоколу MNP2. Аби приймач був готовий на логічному рівні ідентифікувати цю обставину. По-дру-яких, реалізація протоколу може бути винесена на рівень програмного забезпечення комп'ютера, залишаючи модем і зовсім в невіданні щодо наявності протоколу корекції помилок. Добре це чи погано - предмет від-ділового розмови, але це додатковий ступінь свободи, що надають-ється (або, вірніше, не забирає) протоколом.
Формат кадру MNP2 наступний:
- керуючий поле початкового прапора, що включає три байта: SYN, DLE і STX (16h, 10h, 2h);
- прозорі призначені для користувача дані змінної довжини;
- керуючий поле кінцевого прапора, що включає 2 байти: DLE і ETX
- двухбайтовая контрольна послідовність кадру, підрахована за допомогою утворює полінома X ^ 16 + X ^ 15 + X ^ 2 + 1.
Кодова прозорість керуючих полів забезпечується байтом DLE, сигналізує про спеціальному значенні наступного за ним байти. Якщо ж цей байт зустрічається в призначених для користувача даних, то він повинен дублюють-тися, чим забезпечується прозорість самих даних користувача. Іноді процедуру вставки байти DLE в призначені для користувача дані в протоках-ле типу BSC називають байтстаффінгом. Оскільки протокол MNP2 - знак-орієнтований, в ньому немає спеціального межкадрового заповнювач. Їм служить банальний межбайтовий заповнювач - потік степових бітів.
У протоколі MNP2 існують 6 типів кадрів: LR, LD, LT, LA, LN і LNA. Кожен тип кадру в поле прозорих призначених для користувача даних має свою власну логічну структуру, в якій кодується ознака ти-па кадру, а також властиві йому параметри і призначена для користувача інформація.
Протокол корекції помилок MNP3 є біт-орієнтованим про-токолом. Кадровий формат його радикальним чином відрізняється від вишеіз-лежання і повністю відповідає основній частині Рекомендації V.42, включаючи асинхронно-синхронне перетворення байти, підрахунок двухбайто-вої контрольної послідовності кадру з точністю до утворює по-Ліном, забезпечення прозорості даних і міжкадровий заповнювач. Все це докладніше буде розглянуто нижче, в розділі, присвяченому протоколу
V.42. Все ж інше - перелік типів кадрів, їх логічна структура і власне протокол - повністю ідентичне протоколу MNP2. По суті MNP3 - це паліатив між MNP2 і V.42.
При безспірному зниження накладних витрат, обумовленому перехо-дом на синхронний кадровий формат, MNP3 не досягає кондицій V.42, ті-ряя в гнучкості в порівнянні з MNP2. Навіть економії обчислювальних ресур-сов неможливо домогтися, відмовляючись від реалізації байт-орієнтовано-го режиму MNP. З тієї простої причини, що процедура входу в протокол MNP3 полягає в обміні сторонами кадрами LR в байт-орієнтованому режимі. Тільки погодивши з допомогою цього кадру застосування надалі біт-орієнтованого режиму, сторони синхронно в нього перемикаються. Таким чином, всі обчислювальні процедури, властиві MNP2 - формирова-ня кадру специфічного формату, обчислення контрольної послідовник-ності за специфічним утворює полиному, байтстаффінг тощо. - все це необхідно реалізовувати для установки протоколу MNP3. І в зв'язку з цим абсолютно незрозуміла логіка розробників деяких дорогих модемів, в яких байт-орієнтований режим MNP вважається застарілим і не підтримується (наприклад, ZyXEL U-1496). Не кажучи вже про те, що це є прямим порушенням Рекомендації V.42: "An error-correcting entity that supports framing mode 3 must also support framing mode 2." (CCITT, Blue Book, Volume VIII - Fascicle VIII.1, Data communication over the telephone network, Geneva 1989, p. 349).
Як замітки на полях, хотілося б звернути увагу sysop'ов BBS, що користуються ZyXEL, на таку його поведінку. Вважаючи, що настільки непогано зарекомендував себе модем вміє все робити сам, опера-тори станції не підключають драйвери, емулює MNP2. І тим самим практично виключають з числа своїх абонентів тих нещасних, модеми яких апаратно не підтримують протоколи корекції помилок і які змушені сподіватися тільки на програмну реалізацію MNP2.
Інформація про роботу «Модеми (модемні протоколи корекції помилок)»
бод і кодуванням дібіт (4-позиційний DPSK), а 4800 біт / с - швидкістю 1600 бод і кодуванням трібіта (8-позиційний DPSK). Варто відзначити, що існують ще маловживаних модемні протоколи даного сімейства - V.27 і V.27bis, які відрізняються від V.27ter, головним чином, типом каналу (виділений чотирьохпровідний), для якого вони призначені. V.29 У цьому протоколі застосовується.
ITU-T серії V, реалізований в обох модемах. На цьому етапі з'єднання встановлюється згідно з Рекомендаціями V.25 і V.8. Якщо обидва модему підтримують протокол V.34, то вони переходять до другої фази, в ході якої проводиться класифікація каналу зв'язку. Протягом 3 і 4 фази відбувається навчання адаптивного еквалайзера, ехокомпен-сатора і ряду інших систем модему. Після встановлення з'єднання.
досить імовірно, то що вам доведеться розщедритися на придбання сертифіката. Крім того, навіть порівняно недорогі пристрої пройшли належний контроль і офіційно схвалені для використання у вітчизняних мережах нерідко характеризуються дуже високими показники. Чудовим прикладом є модеми фірми ElineCom. Отже, модему який же фірми віддати перевагу. Дати однозначну відповідь.
і доступний для читання і запису з боку ЦП. За допомогою цього регістра здійснюється обмін даними між контролером і ЦП, а також службової інформа-цією - завантаженням команди і читанням з регістрів станів і покажчиків. Запис і читання службової інформації здійснюється в певній послідовності, відповідно до структури команд. Основний регістр стану RS доступний тільки для.