# Acknowledgement (data networks)

> Mediated Wiki article. Canonical URL: https://mediated.wiki/source/Acknowledgement_(data_networks)
> Markdown URL: https://mediated.wiki/source/Acknowledgement_(data_networks).md
> Source: https://en.wikipedia.org/wiki/Acknowledgement_(data_networks)
> Source revision: 1339034882
> License: Creative Commons Attribution-ShareAlike 4.0 International (https://creativecommons.org/licenses/by-sa/4.0/)

{{Short description|Signal confirming receipt of a message without errors}}
{{redirect-multi|3|Nak|NAK|NACK|other uses|Nak (disambiguation)|and|Nack (disambiguation)}}
{{Use British English|date=January 2020}}

In [data networking](/source/data_networking), [telecommunication](/source/telecommunication)s, and [computer bus](/source/computer_bus)es, an '''acknowledgement'''{{Ref RFC|813}}{{Ref RFC|2883}} ('''ACK''') or '''acknowledgment'''{{Ref RFC|2018}}{{Ref RFC|6675}} is a [signal](/source/signal) that is passed between communicating [processes](/source/process_(computing)), [computer](/source/computer)s, or devices to signify acknowledgement, or receipt of message, as part of a [communications protocol](/source/communications_protocol). Correspondingly a '''negative-acknowledgement''' ('''NAK''' or '''NACK'''<ref>{{cite IETF |rfc=3941 |title=Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks |date=November 2004}}</ref>) is a signal that is sent to reject a previously received message or to indicate some kind of error. Acknowledgments and negative acknowledgments inform a sender of the receiver's state so that it can adjust its own state accordingly.

==Acknowledgment signal types==
The [ASCII](/source/ASCII) [code point](/source/code_point) for ACK is 0x06 (binary 0000 0110). By convention, a receiving device sends an ACK to indicate it successfully received a message.  [ASCII also provides a NAK code point](/source/ASCII) (0x15, binary 0001 0101), which can be used to indicate the receiving device cannot, or will not, comply with the message.<ref>{{cite web |url=https://www.aivosto.com/articles/control-characters.html |title=Control characters in ASCII and Unicode |access-date=2020-03-04}}</ref> [Unicode](/source/Unicode) provides visible symbols for these ASCII characters, U+2406 (␆) and U+2415 (␕).

ACK and NAK symbols may also take the form of single bits or [bit field](/source/bit_field)s depending on the protocol [data link layer](/source/data_link_layer) definition or even as a dedicated wire at [physical layer](/source/physical_layer).

==Protocol usage==
Many protocols are acknowledgement-based, meaning that they positively acknowledge receipt of messages. The Internet's [Transmission Control Protocol](/source/Transmission_Control_Protocol) (TCP) is an example of an acknowledgement-based protocol. When computers communicate via TCP, received [packets](/source/Network_packet) are acknowledged by sending a return packet with an ACK bit set.<ref>{{Cite IETF |last=Postel |first=Jon |date=September 1981 |rfc=793 |title=Transmission Control Protocol}}</ref> 

While some protocols send an acknowledgement for each [packet](/source/network_packet) received, other protocols, such as TCP and [ZMODEM](/source/ZMODEM), allow many packets to be transmitted before sending an acknowledgement for the set of them, a procedure necessary to fill high [bandwidth-delay product](/source/bandwidth-delay_product) links with a large number of bytes in flight.

Some protocols are NAK-based, meaning that they only respond to messages if there is a problem. Examples include many [reliable multicast](/source/reliable_multicast) protocols which send a NAK when the receiver detects missing packets <ref>{{Cite journal| last1 = Diot | first1 = C.| last2 = Dabbous | first2 = W.| last3 = Crowcroft | first3 = J. |author-link3 = Jon Crowcroft| doi = 10.1109/49.564128| title = Multipoint communication: A survey of protocols, functions, and mechanisms| journal = IEEE Journal on Selected Areas in Communications| volume = 15| issue = 3| pages = 277–290| date=April 1997 | url = http://planete.inria.fr/dabbous/publis/jsac97.pdf}}</ref> or protocols that use [checksum](/source/checksum)s to verify the integrity of the [payload](/source/payload_(computing)) and [header](/source/header_(computing)).

Still other protocols make use of ''both'' NAKs and ACKs. [Binary Synchronous Communications](/source/Binary_Synchronous_Communications) (Bisync) and Adaptive Link Rate (for [Energy-Efficient Ethernet](/source/Energy-Efficient_Ethernet)) are examples.

The acknowledgement function is used in the [automatic repeat request](/source/automatic_repeat_request) (ARQ) function. Acknowledgement frames are numbered in coordination with the frames that have been received and then sent to the transmitter. This allows the transmitter to avoid [overflow](/source/Buffer_overflow) or [underrun](/source/underrun) at the receiver, and to become aware of any missed [frames](/source/frame_(networking)).

In IBM [Binary Synchronous Communications](/source/Binary_Synchronous_Communications), the NAK is used to indicate that a transmission error was detected in the previously received block and that the receiver is ready to accept [retransmission](/source/Retransmission_(data_networks)) of that block. Bisync does not use a single ACK character but has two control sequences for alternate even/odd block acknowledgement.

ACK- and NAK-based methodologies are not the only protocol design paradigms.  Some protocols, such as the [RC-5](/source/RC-5), [User Datagram Protocol](/source/User_Datagram_Protocol) (UDP), and [X10](/source/X10_(industry_standard)) protocols, perform [blind transmission](/source/blind_transmission) with no acknowledgement, often transmitting the same message multiple times in hopes that at least one copy of the message gets through.

== Hardware acknowledgement ==
Some [computer bus](/source/computer_bus)es have a dedicated acknowledge wire in the [control bus](/source/control_bus) used to acknowledge bus operations: DACK used for [ISA DMA](/source/direct_memory_access); DATACK used in the [STEbus](/source/STEbus), the data transfer acknowledge pin of the [Motorola 68000](/source/Motorola_68000) that inspired the title of [DTACK Grounded](/source/DTACK_Grounded), etc. Some computer buses do not wait for acknowledgement of every transmission, see for instance [posted write](/source/posted_write).

The [I²C](/source/I%C2%B2C) serial bus has a time slot for an acknowledgement bit after each byte.<ref>{{cite web|url=http://i2c.info/i2c-bus-specification|title=I2C Bus Specification}}</ref><ref>{{cite web|url=http://www.ti.com/lit/an/slva704/slva704.pdf|title=Understanding the I2C Bus|at=Figure 8}}</ref>

== See also ==
*[C0 and C1 control codes](/source/C0_and_C1_control_codes)
*[Flow control (data)](/source/Flow_control_(data))
*[NACK-Oriented Reliable Multicast](/source/NACK-Oriented_Reliable_Multicast)

==References==
{{reflist}}
{{refbegin}}
*{{FS1037C MS188}}
{{refend}}

==External links==
* {{cite web |url=https://ruk.ca/content/ack-vs-nak |title=ACK vs. NAK |author=Peter Rukavina |access-date=2020-03-04}}

Category:Control characters
Category:Data transmission
Category:Error detection and correction
Category:Flow control (data)
Category:Network protocols
Category:Routing protocols

---
Adapted from the Wikipedia article [Acknowledgement (data networks)](https://en.wikipedia.org/wiki/Acknowledgement_(data_networks)) by Wikipedia contributors ([contributor history](https://en.wikipedia.org/wiki/Acknowledgement_(data_networks)?action=history)). Available under [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/). Changes may have been made.