Управління потоком даних.

Для керування потоком даних (Flow Control) можуть використовуватися два варіанти протоколу — апаратний і програмний. Іноді керування потоком плутають із квітуванням. Квітування (handshaking) має на увазі посилку повідомлення про одержання елемента, у той час як керування потоком припускає посилку повідомлення про можливість чи неможливість наступного прийому даних.

Апаратний протокол керування потоком RTS/CTS (hardware flow control) використовує сигнал CTS, що дозволяє зупинити передачу даних, якщо приймач не готовий до їх прийому . Передавач «випускає» черговий байт тільки при включеній лінії CTS. Байт, що вже почав передаватися, затримати сигналом CTS неможливо (це гарантує цілісність посилки). Апаратний протокол забезпечує найшвидшу реакцію передавача на стан приймача. Мікросхеми асинхронних прийомопередавачів мають не менш двох регістрів у прийомної частини — що зрушує, для прийому чергової посилки, і що зберігає, з якого зчитується прийнятий байт. Це дозволяє реалізувати обмін по апаратному протоколу без утрати даних.

Апаратний протокол зручний при підключенні принтерів і плотерів, якщо вони його підтримують. При безпосередньому (без модемів) з'єднанні двох комп'ютерів апаратний протокол вимагає перехресного з'єднання ліній RTS - CTS.

При безпосередньому з'єднанні в передавального термінала повинне бути забезпечений стан «включено» на лінії CTS (з'єднанням власних ліній RTS — CTS). У противному випадку передавач буде «мовчати».

Застосовувані в IBM PC прийомопередавачі 8250/16450/16550 сигнал CTS апаратно не відпрацьовують, а тільки показують його стан у регістрі MSR (див. нижче). Реалізація протоколу RTS/CTS покладається на драйвер BIOS Int 14h, і називати його «апаратним» не зовсім коректно. Якщо ж програма, що користається СОМ-портом, взаємодіє з UART на рівні регістрів (а не через BIOS), то обробкою сигналу CTS для підтримки даного протоколу вона займається сама. Ряд комунікаційних програм дозволяє ігнорувати сигнал CTS (якщо не використовується модем), і для них не потрібно з'єднання входу CTS з виходом свого сигналу RTS. Однак існують і інші прийомопередавачі (наприклад, 8251), у яких сигнал CTS відпрацьовується апаратно. Для них, а також для «чесних» програм використання сигналу CIS на роз’ємах (а то і на кабелях) обов'язково. Перевага протоколу RTS/CTS у часі реакції в порівнянні з програмним протоколом XON/XOFF залишається лише для буферованої (у режимі FIFO) передачі.

Програмний протокол керування потоком XON/XOFF припускає наявність двонаправленого каналу передачі даних. Працює протокол у такий спосіб: якщо пристрій, що приймає дані, виявляє причини, по яких воно не може їх далі приймати, воно по зворотному послідовному каналі посилає байт-символ XOFF (13h). Протилежний пристрій, прийнявши цей символ, припиняє передачу. Коли приймаючий пристрій стає готовим до прийому даних, він посилає символ XON (1lh), прийнявши який протилежний пристрій відновляє передачу. Час реакції передавача на зміну стану приймача в порівнянні з апаратним протоколом збільшується принаймні на час передачі символу (XON чи XOFF) плюс час реакції програми передавача на прийом символу. З цього випливає, що дані без утрат можуть прийматися тільки приймачем, що має додатковий буфер прийнятих даних і, що сигналізує про неготовність завчасно (маючи в буфері вільне місце).

Перевага програмного протоколу полягає у відсутності необхідності передачі керуючих сигналів інтерфейсу — мінімальний кабель для двостороннього обміну може мати тільки 3 провода. Недоліком, крім вимоги наявності буфера і більшого часу реакції (що знижує загальну продуктивність каналу через очикування сигналу XON), є складність реалізації повнодуплексного режиму обміну. У цьому випадку з потоку прийнятих даних повинні виділятися (і оброблятися) символи керування потоком, що обмежує набір переданих символів.

Крім цих двох розповсюджених стандартних протоколів, підтримуваних і ПЗ, і ОС, існують і інші.