3.8.4 Client Sequence Number Processing

The client implements filtering logic to make sure that each command is executed in order and only executed once.

The client keeps track of the sequence number of the last command executed (LastSeqNum) and the expected sequence number of the next command (NextSeqNum).

Prior to the client performing any command sequence number processing/filtering, the command must have already passed the Transport Layer integrity checks. See the Client Command Processing and Response Generation section of the specification for more details on when the sequence number processing/filtering occurs.

The client uses the following checks/logic to accomplish the following tasks.

  • Client Sequence Number Synchronization:
    • When an update starts, the host doesn’t know what the client’s LastSeqNum and NextSeqNum value are. Since clients reject incoming commands that don’t have C_SEQUENCE equal to NextSeqNum, the host uses the synchronization mechanism to set the client’s sequence number.
    • The first command (and only the first command) of the update that the host sends to the client has the SYNC bit set to 1 which tells the client to synchronize its sequence number to the host sequence number.
    • The client accepts this command for execution.
  • Valid Sequence Number Command Processing:
    • When the command from the host has C_SEQUENCE equal to NextSeqNum, the client accepts this command for execution.
  • Corrupted Response Retrieval:
    • When a response is corrupted, the host resends the command to the client. If the client has already executed this command (C_SEQUENCE equals LastSeqNum), the client must prevent repeated execution of the command and simply resend the response from the first time that command was executed.
    • IMPORTANT: After executing a command, a client must retain the response to that command until the client can conclude that the host will not request that specific response be resent. Clients can discard the response to the LastSeqNum command only when they receive a new command with C_SEQUENCE equal to the next expected sequence number (NextSeqNum) or when the host synchronizes the sequence number.
  • Invalid Sequence Number Signaling:
    • If the host ever sends a command with the SYNC bit cleared to 0 and with a sequence number different from NextSeqNum or LastSeqNum, this sequence number is invalid and the command must not be executed.
    • Clients must reply to the host and request that the command with the next expected sequence number (NextSeqNum) be resent by the host. This is accomplished by creating an ephemeral resend request response:
      • Response Sequence
        • RESEND = 1
        • R_SEQUENCE = NextSeqNum
      • Response Status = COMMAND_NOT_EXECUTED
      • Response data can either be empty or contain the SEQUENCE_NUMBER_INVALID cause code
    • This ephemeral resend request response is not the result of executing a command, and the client does not need to retain this response after it has been sent as the client will never resend this response.

3.8.4.1 Processing Algorithm Diagram

The following figure defines the client sequence number processing/filtering algorithm.

Figure 3-11. Client Sequence Number Processing/Filtering

3.8.4.2 Client Sequence Number Processing Examples

The following examples show the details of the command and response sequence fields for the four scenarios discussed above.

3.8.4.2.1 Client Sequence Number Synchronization Example

Figure 3-12. Client Sequence Number Synchronization

3.8.4.2.2 Valid Sequence Number Command Processing Example

Figure 3-13. Client Receiving Next Expected Sequence Number

3.8.4.2.3 Corrupted Response Retrieval Example

Figure 3-14. Client Resends Response from LastSeqNum Command

3.8.4.2.4 Invalid Sequence Number and Resend Request

Figure 3-15. Client Requests the Next Expected Command from Host