Acknowledgement (data networks)

In data networking, telecommunications, and computer buses, an acknowledgment (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. The 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.

"Nak", "NAK", and "NACK" redirect here. For other uses, see Nak (disambiguation) and Nack (disambiguation).

Many protocols contain checksums to verify the integrity of the payload and header. Checksums are used to detect data corruption. If a message is received with an invalid checksum (that is, the data received would have a different checksum than the message had), the receiver can know that some information was corrupted. Most often, when checksums are employed, a corrupted message received will either not be served an ACK signal, or will be served a NAK signal.

Acknowledgment characters

ASCII code includes an ACK character (00001102 or 616) which can be transmitted to indicate successful receipt and a NAK character (00101012 or 1516) which can be transmitted to indicate an inability or failure to receive.[2] Unicode provides visible symbols for these characters, U+2406 (␆) and U+2415 (␕).

Protocol usage

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 back a packet with an ACK bit set. The TCP protocol allows these acknowledgements to be included with data that is sent in the opposite direction.

Some protocols send a single acknowledgement per packet of information. Other protocols such as TCP and ZMODEM allow many packets to be transmitted before receiving acknowledgement for any of them, a procedure necessary to fill high bandwidth-delay product links with a large number of bytes in flight.

Other protocols are NAK-based, meaning that they only respond to messages if there is a problem. Examples include most reliable multicast protocols which send a NAK when the receiver detects missing packets. Still other protocols make use of both NAKs and ACKs. Binary Synchronous Communications (Bisync) and Adaptive Link Rate (for Energy-Efficient Ethernet) are examples.

Still other 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.

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 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.

Hardware acknowledgment

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 always acknowledge every write; some or all of the writes use a posted write.

The I²C serial bus has a time slot for an acknowledgment bit after each byte.[3][4]

See also

References
  1. Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks. November 2004. doi:10.17487/RFC3941. RFC 3941.
  2. "Control characters in ASCII and Unicode". Retrieved 2020-03-04.
  3. "I2C Bus Specification".
  4. "Understanding the I2C Bus" (PDF). Figure 8.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.