About ACK

Integer ASCII code: 6
Binary code: 0000 0110
Octal code: 6
Hexadecimal code: 06
Group: control
Seq: ^F

Unicode symbol: , int code: 9222 (html &#9222) hex code: 2406 (html &#x2406)


Answer (indication) to an ENQ of successful message receipt.

An acknowledgement (or simply ASK) is widely used in data networking, telecommunications, computer buses. It's a signal that is transmitted between communicating processes, computers, or devices in order to designate acknowledgement, or message receipt. It makes only one section of a communications protocol. The negative-acknowledgement (NAK or NACK) signal has a function of rejecting a message that was received earlier. There is one more function of indicating some kind of error. Acknowledgements and negative acknowledgements show a sender the state of the receiver. This way it can respectively adjust its own state.

Acknowledgement characters

Each very terminal has a function of sending an enquiry character in order to check the condition of the other one, when the ASCII code is used to communicate between computer terminals. The one, who received this character, can answer either with ACK (00001102 or 616) to show that it works properly, or NAK (00101012 or 1516) to show that there is some error. Unicode has visible symbols for these characters, U+2406 (␆) and U+2415 (␕).

Protocol usage

Lots of protocols are somehow based on the acknowledgement. That means that they positively acknowledge the message receipt. The good example of the protocol based on the acknowledgement is the internet's Transmission Control Protocol (TCP). When computers communicate with each other with the help of TCP, received packets of information are confirmed by sending back a packet with an ACK bit set. Such confirmations are let to be included with data that is sent in the opposite direction by TCP protocol.

There can be different cases. One group of protocols sends just one confirmation per packet of information. The other group of protocols, for example TCP and ZMODEM are OK to send lots of packets before receiving acknowledgement for any of them. This procedure must necessary fill high bandwidth-delay product links with a great number of bytes in flight.

All the other unmentioned protocols are based on NAK. This way they only respond to messages in case of a problem. The most credible multicast protocols which send a NAK when the receiver finds out that there are packets, included in the example. Nevertheless, other protocols normally use both NAKs and ACKs. The examples are Binary Synchronous Communications (Bisync) and Adaptive Link Rate (for Energy-Efficient Ethernet)

There are some protocols, for example the RC-5, User Datagram Protocol (UDP), and X10 protocols, that blindly send information with no acknowledgement of the received information. They frequently send the same message for a couple of times. Doing this, they hope that at least one copy of the message will be received.

The function of acknowledgement is also used in the automatic repeat request (ARQ) function. Acknowledgement frames are of the same number that the received frames are. Later they are sent to the transmitter. This way the transmitter avoids overflow or underrun at the receiver. Besides, he becomes aware of any missed frames.

The NAK is also used in Binary Synchronous Communications. Here its function is to show the transmission error that occurred in the previously received block and that the receiver is ready to accept retransmission of that block. Bisync doesn't use ACK characters at all. Instead of it, it has two control sequences in order to rotate even/odd block acknowledgement.


input value base type output hash
ACK char MD5 06eca1b437c7904cc3ce6546c8110110
ACK char SHA1 2d0134ed3b9de132c720fe697b532b4c232ff9fe
6 dec MD5 1679091c5a880faf6fb5e6087eb1b2dc
6 dec SHA1 c1dfd96eea8cc2b62785275bca38ac261256e278
00000110 bin MD5 c5e2270f5281d012c7d325d7f275cea3
00000110 bin SHA1 4406cb5e84a652e0099d3102dc03d993f2a808da
0000 0110 bin MD5 983b7f2902ee63d1671ee035d5c87e30
0000 0110 bin SHA1 6d66f88b265e0cf98f86504032d4789bc808d682
6 oct MD5 1679091c5a880faf6fb5e6087eb1b2dc
6 oct SHA1 c1dfd96eea8cc2b62785275bca38ac261256e278
06 hex MD5 faeac4e1eef307c2ab7b0a3821e6c667
06 hex SHA1 7316b3d5fef9b3562d32f7c39f154a3bc3ab9c58
0x06 hex MD5 ee4ee5fbf05578a56ae5a2cf3bde97c2
0x06 hex SHA1 afccd2a6961ead3d5fafc141887e4d020afb3603
Back to ASCII table

 2018 © Dmytro Koshovyi. Ukraine, Mykolayiv.