Интересно, каким образом сетевые устройства определяют где начинается фрейм, а где заканчивается. Понятное дело, что флаги в начале фрейма, содержащие определенную последовательность битов с этим как-то справляются. Но как же тогда решается проблема с тем, что данные с той же последовательностью бит как у флага могут встречаться в середине фрейма? Если взять PPP, то поскольку он построен поверх HDLC, то у него флаг 01111110.
PPP может работать на синхронных и асинхронных последовательных (serial) каналах, что определяет тип stuffing-a.
Синхронный канал - это тот канал, на котором при связи двух устройств используется два сигнала: один синхронизирующий, а второй передающий. Пульс на первом сигнале говорил о том, когда нужно считывать бит на втором.
Асинхронный канал - это тот канал, который позволяет прямо в процессе передачи контролировать ее скорость, а точнее частоту считывания бодов. Присутствует всего 1 сигнал. Пульс для считывания определяется получающим устройством - он его задает с помощью:
- автоматического определения скорости передачи данных в бодах (Authomatic baud rate detection, или autobaud, ABR), которое позволяет, анализируя синхронизирующее слово (syncword), определить эту скорость. Поскольку PPP основано на HDLC, то в данном случае специального синхронизирующего слова не надо, поскольку HDLC является самосинхронизирующимся кодом. Это означает, что любое слово кода четко определяет свои границы. То есть, если совместить два слова кода подряд в строку, то никакая подстрока этой строки, начиная со второго символа и заканчивая предпоследним, не будет верным кодовым словом.
- затем, определив скорость, с помощью фазовой автоподстройки частоты (Phase-locked loop) и задаются локально временные импульсы для последующего считывания данных.
Оборудование для поддержки синхронного канала более дорогое и сложное, но это компенсируется меньшим количеством накладных расходов на синхронизацию, а значит и большей производительностью каналов.
Асинхронными являются в первую очередь аналоговые телефонные линии, также часто каналы T3, которые включают в себя несколько синхронных каналов T1, взаимодействие между которыми в асинхронном режиме.
Синхронные - это цифровые каналы, как ISDN, в некоторых случаях T3 тоже является синхронным (технология SYNTRAN).
В синхронных каналах используется bit stuffing, поскольку считывание данных идет побитового. Поскольку в HDLC флаг = 01111110, то встает вопрос, как избавить данные, от вкрапления той же последовательности бит. После последовательности из пяти единиц в отправляемых данных вставляется ноль при отправлении, а при получении - эти биты изымаются. То есть, если в данных последовательность 0111110 -> 01111100 , если 0111111 -> 01111101.
В асинхронных каналах считывание чаще всего происходит по длине кодового слова, в первую очередь при синхронизации, поэтому bit stuffing неудобен. При character stuffing во фрейме последовательность бит, равная флаг 01111110 ( = 0x7E в 16-ричной системе счисления), заменяется на 0x7D-5E. 7D еще называют экранирующим символом (escape character) в PPP. Если же в поле данных встречается 0x7D, то оно заменяется на 0x7D-5D. На принимающей стороне все это декодируется обратно. Казалось бы, почему бы просто после всех нефлаговых 7E не добавлять какой-то байт? Такая сложность связана с тем, что после получения синхронизирующего флага 7E получатель уже должен быть готов получать новый фрейм, а не анализировать, идет ли после него дальше определенный байт.
PPP может работать на синхронных и асинхронных последовательных (serial) каналах, что определяет тип stuffing-a.
Синхронный канал - это тот канал, на котором при связи двух устройств используется два сигнала: один синхронизирующий, а второй передающий. Пульс на первом сигнале говорил о том, когда нужно считывать бит на втором.
Асинхронный канал - это тот канал, который позволяет прямо в процессе передачи контролировать ее скорость, а точнее частоту считывания бодов. Присутствует всего 1 сигнал. Пульс для считывания определяется получающим устройством - он его задает с помощью:
- автоматического определения скорости передачи данных в бодах (Authomatic baud rate detection, или autobaud, ABR), которое позволяет, анализируя синхронизирующее слово (syncword), определить эту скорость. Поскольку PPP основано на HDLC, то в данном случае специального синхронизирующего слова не надо, поскольку HDLC является самосинхронизирующимся кодом. Это означает, что любое слово кода четко определяет свои границы. То есть, если совместить два слова кода подряд в строку, то никакая подстрока этой строки, начиная со второго символа и заканчивая предпоследним, не будет верным кодовым словом.
- затем, определив скорость, с помощью фазовой автоподстройки частоты (Phase-locked loop) и задаются локально временные импульсы для последующего считывания данных.
Оборудование для поддержки синхронного канала более дорогое и сложное, но это компенсируется меньшим количеством накладных расходов на синхронизацию, а значит и большей производительностью каналов.
Асинхронными являются в первую очередь аналоговые телефонные линии, также часто каналы T3, которые включают в себя несколько синхронных каналов T1, взаимодействие между которыми в асинхронном режиме.
Синхронные - это цифровые каналы, как ISDN, в некоторых случаях T3 тоже является синхронным (технология SYNTRAN).
В синхронных каналах используется bit stuffing, поскольку считывание данных идет побитового. Поскольку в HDLC флаг = 01111110, то встает вопрос, как избавить данные, от вкрапления той же последовательности бит. После последовательности из пяти единиц в отправляемых данных вставляется ноль при отправлении, а при получении - эти биты изымаются. То есть, если в данных последовательность 0111110 -> 01111100 , если 0111111 -> 01111101.
В асинхронных каналах считывание чаще всего происходит по длине кодового слова, в первую очередь при синхронизации, поэтому bit stuffing неудобен. При character stuffing во фрейме последовательность бит, равная флаг 01111110 ( = 0x7E в 16-ричной системе счисления), заменяется на 0x7D-5E. 7D еще называют экранирующим символом (escape character) в PPP. Если же в поле данных встречается 0x7D, то оно заменяется на 0x7D-5D. На принимающей стороне все это декодируется обратно. Казалось бы, почему бы просто после всех нефлаговых 7E не добавлять какой-то байт? Такая сложность связана с тем, что после получения синхронизирующего флага 7E получатель уже должен быть готов получать новый фрейм, а не анализировать, идет ли после него дальше определенный байт.
