Each packet has a header consisting of a 32-bit packet ID. This packet ID increases with each packet sent, and makes it possible for the receiving end to know if a particular packet has been lost during the transfer.
When an implementation notices one or more lost packets it will have to notify the other side by sending a negative acknowledgment (NAK), and each packet that is successfully received has to be confirmed by sending a positive acknowledgment (ACK).
The nak and ack commands are like any other command defined in the command specification. If a packet arrives, all non-received commands since the last received commands are considered lost, and the implementation can immediately decode and use the information in the arrived packet without waiting for data to be resent. If a lost packet later arrives out of order, it should be ignored. Both sides must store history of sent data to be able to re-send any data that may have been lost.
The NAK and ACK commands both include a single parameter; a 32-bit packet ID number. For NAK, the semantics are that the indicated packet was lost and needs to be re-sent. The sending end must look it up in its packet history, and re-send it. For ACK, the semantics are the inverse: the indicated packet was successfully received, and can be removed from the history buffers.
If one side of a Verse connection fails, the other side's history buffer will eventually fill up. It is then free to give up. Protocol implementations should provide a way for applications to determine how large the history buffer is, so they can make the decision to terminate.
As described above, all commands sent out by a Verse application are buffered by the implementation, to be available for resend should a NAK arrive. However, they are not simply buffered and forgotten until (possibly) re-sent. When a command is added to the history buffer, a search is done for a command with the same address. If a match is found, we know the one in the buffer has been made obsolete by the new command, and it is thus replaced in the buffer. The comparison operation needed by the search can be implemented in two discrete steps:
Compare the command bytes. If they differ, there can be no match.
Compare the address information. The address is always a contiguous sequence of bytes, and has the same (fixed) size for all instances of a given command, so this is fairly simple.
This updating of sent commands with new data means that if a client repeatedly sends out N commands addressing the same data (say, for instance, that it is periodically changing the color of some object), only one single command will be stored in the history buffer. This way of automatically filtering out repeated changes to the same data, keeping only the most recent, is called event compression.
Because of event compression, the command that is (re)sent in response to a NAK might not be the same command that was actually lost, since it might have been replaced by a more recent command changing the same data.