Подтверждение (сети передачи данных)

Сигнал, подтверждающий получение сообщения без ошибок

В сетях передачи данных , телекоммуникациях и компьютерных шинах подтверждение ( ACK ) — это сигнал , который передается между взаимодействующими процессами , компьютерами или устройствами для обозначения подтверждения или получения сообщения в рамках протокола связи . Соответственно, отрицательное подтверждение ( NAK или NACK [ ^1] ) — это сигнал, который отправляется для отклонения ранее полученного сообщения или для указания на какую-либо ошибку. Подтверждения и отрицательные подтверждения информируют отправителя о состоянии получателя, чтобы он мог соответствующим образом скорректировать свое собственное состояние.

Типы сигналов подтверждения

Кодовая точка ASCII для ACK — 0x06 (двоичный 0000 0110). По соглашению принимающее устройство отправляет ACK, чтобы указать, что оно успешно получило сообщение. ASCII также предоставляет кодовую точку NAK (0x15, двоичный 0001 0101), которая может использоваться для указания того, что принимающее устройство не может или не будет выполнять сообщение. ^[2]Unicode предоставляет видимые символы для этих символов ASCII, U+2406 (␆) и U+2415 (␕).

Символы ACK и NAK могут также иметь форму отдельных битов или битовых полей в зависимости от определения уровня канала передачи данных протокола или даже в виде выделенного провода на физическом уровне .

Использование протокола

Многие протоколы основаны на подтверждении, что означает, что они положительно подтверждают получение сообщений. Протокол управления передачей (TCP) в Интернете является примером протокола, основанного на подтверждении. Когда компьютеры взаимодействуют через TCP, полученные пакеты подтверждаются отправкой ответного пакета с установленным битом ACK. ^[3]

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

Некоторые протоколы основаны на NAK, что означает, что они реагируют на сообщения только в случае возникновения проблем. Примерами служат многие надежные многоадресные протоколы, которые отправляют NAK, когда получатель обнаруживает отсутствующие пакеты ^[4], или протоколы, которые используют контрольные суммы для проверки целостности полезной нагрузки и заголовка .

Другие протоколы используют как NAK, так и ACK. Примерами являются Binary Synchronous Communications (Bisync) и Adaptive Link Rate (для Energy-Efficient Ethernet ).

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

В IBM Binary Synchronous Communications NAK используется для указания того, что в ранее полученном блоке была обнаружена ошибка передачи и что приемник готов принять повторную передачу этого блока. Bisync не использует один символ ACK, а имеет две управляющие последовательности для альтернативного подтверждения четного/нечетного блока.

Методологии на основе ACK и NAK — не единственные парадигмы проектирования протоколов. Некоторые протоколы, такие как RC-5 , протокол пользовательских датаграмм (UDP) и протоколы X10 , выполняют слепую передачу без подтверждения, часто передавая одно и то же сообщение несколько раз в надежде, что хотя бы одна копия сообщения будет доставлена.

Аппаратное подтверждение

Некоторые компьютерные шины имеют выделенный провод подтверждения в шине управления, используемый для подтверждения операций шины: DACK используется для ISA DMA ; DATACK используется в STEbus , контакт подтверждения передачи данных Motorola 68000 , который вдохновил на название DTACK Grounded и т. д. Некоторые компьютерные шины не ждут подтверждения каждой передачи, см., например, опубликованную запись .

Последовательная шина I²C имеет временной интервал для бита подтверждения после каждого байта. ^[5]^[6]

Смотрите также

Ссылки

^ Строительные блоки NACK-Oriented Reliable Multicast (NORM). Ноябрь 2004 г. doi : 10.17487/RFC3941 . RFC 3941.
^ "Управляющие символы в ASCII и Unicode" . Получено 2020-03-04 .
^ Постел, Джон (сентябрь 1981 г.). Протокол управления передачей. doi : 10.17487/RFC0793 . RFC 793.
^ Diot, C.; Dabbous, W.; Crowcroft, J. (апрель 1997 г.). «Многоточечная связь: обзор протоколов, функций и механизмов» (PDF) . Журнал IEEE по избранным областям в коммуникациях . 15 (3): 277– 290. doi :10.1109/49.564128.
^ «Спецификация шины I2C».
^ "Понимание шины I2C" (PDF) . Рисунок 8.

В этой статье использованы материалы из Федерального стандарта 1037C. Администрация общих служб . Архивировано из оригинала 2022-01-22. (в поддержку MIL-STD-188 ).

Внешние ссылки

Петр Рукавина. «ACK против NAK» . Проверено 04 марта 2020 г.

[1] Строительные блоки NACK-Oriented Reliable Multicast (NORM). Ноябрь 2004 г. doi : 10.17487/RFC3941 . RFC 3941.

[2] "Управляющие символы в ASCII и Unicode" . Получено 2020-03-04 .

[3] Постел, Джон (сентябрь 1981 г.). Протокол управления передачей. doi : 10.17487/RFC0793 . RFC 793.

[4] Diot, C.; Dabbous, W.; Crowcroft, J. (апрель 1997 г.). «Многоточечная связь: обзор протоколов, функций и механизмов» (PDF) . Журнал IEEE по избранным областям в коммуникациях . 15 (3): 277– 290. doi :10.1109/49.564128.

[5] «Спецификация шины I2C».

[6] "Понимание шины I2C" (PDF) . Рисунок 8.