Errata exists for this version of the document.
The security header is always followed by the sequence header which is defined in Table 44. The sequence header ensures that the first encrypted block of every Message sent over a channel will start with different data.
|
Name |
Data Type |
Description |
|
SequenceNumber |
UInt32 |
A monotonically increasing sequence number assigned by the sender to each MessageChunk sent over the SecureChannel. |
|
RequestId |
UInt32 |
An identifier assigned by the Client to OPC UA request Message. All MessageChunks for the request and the associated response use the same identifier. |
A SequenceNumber may not be reused for any TokenId. The SecurityToken lifetime should be short enough to ensure that this never happens; however, if it does the receiver should treat it as a transport error and force a reconnect.
The SequenceNumber shall also monotonically increase for all Messages and shall not wrap around until it is greater than 4 294 966 271 (UInt32.MaxValue – 1 024). The first number after the wrap around shall be less than 1 024. Note that this requirement means that a SequenceNumber does not reset when a new TokenId is issued. The SequenceNumber shall be incremented by exactly one for each MessageChunk sent unless the communication channel was interrupted and re-established. Gaps are permitted between the SequenceNumber for the last MessageChunk received before the interruption and the SequenceNumber for first MessageChunk received after communication was re-established. Note that the first MessageChunk after a network interruption is always an OpenSecureChannel request or response. If gaps occur in any other case the receiver shall close the SecureChannel.
The sequence header is followed by the Message body which is encoded with the OPC UA Binary encoding as described in 5.2.9. The body may be split across multiple MessageChunks.