After your server has successfully delivered a property request, property announcement, or instant message for you, and the destination server has not raised any errors, your server will let your client know by sending an RX_ACK message.
The format for an RX_ACK message is:
RX_ACK tag code [detail]
where
| tag | is the label of the message being confirmed; |
| code | is the positive acknowledgement code in hexadecimal; and |
| detail | is an optional envelop detailing the operation |
Values for acknowledgement codes are defined as follows:
| value | name | meaning (in the voice of the receiver's server) | additional fields |
|---|---|---|---|
| 0x0000 | ACK_OK | Your datagram was successfully processed and there are no abnormal conditions to report. | none |
| 0x8000 | ACK_BUFFERED | Your instant message datagram was received, but the intended receiver is off-line. That's OK, however, because I have buffered the message and will deliver it when the receiver reconnects. | none |
The values of these codes are intended to be distinct from the values of all server-to-server action codes, server-to-client negative acknowledgement codes, and server-to-client failure codes. Implementors may assume that this will always be the case.
Because clients and servers send messages to each other asynchronously, it is unreasonable for your client to expect a message's RX_ACK to be returned immediately after it was issued. (Clients implemented with this expectation will bomb.) Other messages may arrive first and will require processing.
If a TX_* command fails, an RX_NAK or FAILED_TX message may be returned instead of an RX_ACK message.