Acknowledgement (data networks)
In data networking, telecommunications, and computer buses, an acknowledgement (ACK) is a signal that is passed between communicating processes, computers, or devices to signify acknowledgment, or receipt of message, as part of a communications protocol. Correspondingly a negative-acknowledgement (NAK or NACK[1]) 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
[edit]The ASCII 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 (0x15, binary 0001 0101) which can be used to indicate the receiving device cannot, or will not, comply with the message.[2] 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 fields depending on the protocol data link layer definition or even as a dedicated wire at physical layer.
Protocol usage
[edit]Many protocols are acknowledgement-based, meaning that they positively acknowledge receipt of messages. The internet's Transmission Control Protocol (TCP) is an example of an acknowledgement-based protocol. When computers communicate via TCP, received packets are acknowledged by sending a return packet with an ACK bit set.[3]
While some protocols send an acknowledgement per each packet received, other protocols such as TCP and 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 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 protocols which send a NAK when the receiver detects missing packets [4] or protocols that use checksums to verify the integrity of the payload and header.
Still other protocols make use of both NAKs and ACKs. Binary Synchronous Communications (Bisync) and Adaptive Link Rate (for Energy-Efficient Ethernet) are examples.
The acknowledgement function is used in the 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 or underrun at the receiver, and to become aware of any missed frames.
In IBM 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 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, User Datagram Protocol (UDP), and X10 protocols perform 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 acknowledgment
[edit]Some computer buses have a dedicated acknowledge wire in the control bus used to acknowledge bus operations: DACK used for ISA DMA; DATACK used in the STEbus, the data transfer acknowledge pin of the Motorola 68000 that inspired the title of DTACK Grounded, etc. Some computer buses do not wait for acknowledgement of every transmission, see for instance posted write.
The I²C serial bus has a time slot for an acknowledgment bit after each byte.[5][6]
See also
[edit]References
[edit]- ^ Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks. November 2004. doi:10.17487/RFC3941. RFC 3941.
- ^ "Control characters in ASCII and Unicode". Retrieved 2020-03-04.
- ^ Postel, Jon (September 1981). Transmission Control Protocol. doi:10.17487/RFC0793. RFC 793.
- ^ Diot, C.; Dabbous, W.; Crowcroft, J. (April 1997). "Multipoint communication: A survey of protocols, functions, and mechanisms" (PDF). IEEE Journal on Selected Areas in Communications. 15 (3): 277–290. doi:10.1109/49.564128.
- ^ "I2C Bus Specification".
- ^ "Understanding the I2C Bus" (PDF). Figure 8.
This article incorporates public domain material from Federal Standard 1037C. General Services Administration. Archived from the original on 2022-01-22. (in support of MIL-STD-188).
External links
[edit]- Peter Rukavina. "ACK vs. NAK". Retrieved 2020-03-04.