3.3.11 Record: MessageHeader
Topic Version | 1 | Published | 10/31/2016 | |
For Standard | ETP v1.1 |
The protocol control block sent at the beginning of every message. On the wire, every message sent contains this block first. From an Avro perspective, the message header can be thought of as the first member of every message; however, it is normally processed independently. This independent processing allows agents to inspect the protocol and message type fields to determine the appropriate serializer for the rest of the message.
Avro Schema |
---|
{ "type": "record", "namespace": "Energistics.Datatypes", "name": "MessageHeader", "fields": [ { "name": "protocol", "type": "int" }, { "name": "messageType", "type": "int" }, { "name": "correlationId", "type": "long" }, { "name": "messageId", "type": "long" }, { "name": "messageFlags", "type": "int" } ] } |
Attribute |
Description |
Data Type |
Min |
Max |
---|---|---|---|---|
protocol |
Identifies the protocol for which the message is intended. The values MUST come from theProtocolId enumeration. |
int |
1 |
1 |
messageType |
Contains the enumerated value (a protocol-specific value) for the accompanying message. Thus a client or server can read the message type from the message header and then know which schema proxy to use to decode the rest of the message. |
int |
1 |
1 |
correlationId |
ETP generally does not follow a request/response pattern, thus the correlationId is used to allow servers and clients to match, asynchronously, related messages. For example, an exception message MUST have as its correlationId the number of the message that caused the exception to be raised. |
long |
1 |
1 |
messageId |
The unique identifier for this message within an ETP session. |
long |
1 |
1 |
messageFlags |
A bit map of flags that apply to a message. It has the following bits defined:
|
int |
1 |
1 |