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)


Information


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.


Hash


MD5 Acknowledge

input value base output hash
ACK char 06ECA1B437C7904CC3CE6546C8110110
6 dec 1679091C5A880FAF6FB5E6087EB1B2DC
00000110 bin C5E2270F5281D012C7D325D7F275CEA3
0000 0110 bin 983B7F2902EE63D1671EE035D5C87E30
6 oct 1679091C5A880FAF6FB5E6087EB1B2DC
06 hex FAEAC4E1EEF307C2AB7B0A3821E6C667
0x06 hex EE4EE5FBF05578A56AE5A2CF3BDE97C2

SHA256 Acknowledge

input value base output hash
ACK char 67586E98FAD27DA0B9968BC039A1EF34C939B9B8E523A8BEF89D478608C5ECF6
6 dec E7F6C011776E8DB7CD330B54174FD76F7D0216B612387A5FFCFB81E6F0919683
00000110 bin 69EDAB7FA2D6B23A61EE4E315CAAA9519B9F3700C7BBC3D6D55FBF6FD599EF7A
0000 0110 bin 274F6BC074DAABD0923285B1F57B0FEA78A6B99F9DDBB01FEB481FF1A7E0F655
6 oct E7F6C011776E8DB7CD330B54174FD76F7D0216B612387A5FFCFB81E6F0919683
06 hex AACD834B5CDC64A329E27649143406DD068306542988DFC250D6184745894849
0x06 hex 9AE3BA65BA61C9713C2E5F6B981F5950E333E5B5678D8092CC5DC80FE54DE09D

Base64 Acknowledge

input value base output hash
ACK char Bg==
6 dec Ng==
00000110 bin MDAwMDAxMTA=
0000 0110 bin MDAwMCAwMTEw
6 oct Ng==
06 hex MDY=
0x06 hex MHgwNg==
Back to ASCII table

 2018-2024 © Dmytro Koshovyi. Ukraine, Mykolayiv.