Integer ASCII code: | 6 |
Binary code: | 0000 0110 |
Octal code: | 6 |
Hexadecimal code: | 06 |
Group: | control |
Seq: | ^F |
Unicode symbol: ␆, int code: 9222 (html ␆) hex code: 2406 (html ␆)
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.
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 (␕).
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 | output hash |
---|---|---|
ACK | char | 06ECA1B437C7904CC3CE6546C8110110 |
6 | dec | 1679091C5A880FAF6FB5E6087EB1B2DC |
00000110 | bin | C5E2270F5281D012C7D325D7F275CEA3 |
0000 0110 | bin | 983B7F2902EE63D1671EE035D5C87E30 |
6 | oct | 1679091C5A880FAF6FB5E6087EB1B2DC |
06 | hex | FAEAC4E1EEF307C2AB7B0A3821E6C667 |
0x06 | hex | EE4EE5FBF05578A56AE5A2CF3BDE97C2 |
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 |
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== |