1.3.1 Protocol 0: Session Management (or Core Protocol)

Topic Version1Published10/31/2016
For StandardETP v1.1

ETP includes the notion of a session. This session is separate and unrelated to any HTTP session that exists as part of the WebSocket connection and upgrade. The creation and management of session happens through the first ETP subprotocol, known as the Coreprotocol, and identified as Protocol 0.

When a session is created, it is assigned a universally unique identifier (UUID). The major purpose of the session is to allow for a context within which various domain objects can be referenced in messages by identifiers, as opposed to their character-based names. This approach allows for much smaller messages on the wire and more efficient processing of messages in code. Figure 1.3.1-1 shows the layout of an ETP message.

Figure 1.3.1-1 : ETP message layout.

Each message begins with a common message header. The main purposes of the header are:

  • To identify the message subprotocol within ETP.
  • To identify the type of message being sent (messageType), which implicitly defines the schema for the message data.
  • To identify the ID of the message itself. Each message in an ETP session is uniquely numbered. The number is unique within the context of the session and agent type (client/server).
  • The message header contains an optional correlationId attribute. Its purpose is somewhat context-sensitive, depending on the specific message, but in general it is used to correlate messages that are in response to some previous request. For example, when a consumer makes ChannelRangeRequest, all of the resulting ChannelData messages will have a correlationId that is the value of the original ChannelRangeRequest message.
  • Finally, each message has an optional messageFlags attribute. This attribute acts as a bit-field and allows multiple Boolean flags to be set on the message. Three flags are currently defined:
  • One that says this is a multi-part response (i.e., more data messages are coming related to this request).
  • One that identifies a message as the final part of a multi-part message.
  • One that identifies a message as ‘NoData’.

Note that unlike SOAP and XML, no begin/end message tags are used, so there is no concept of an ‘envelope’ with ETP messages.