2.2.1 Requirements for ChannelStreaming Protocol

Topic Version1Published10/31/2016
For StandardETP v1.1

Requirement

Type

Description

Message Order

Behavior
  1. Streaming data points MUST be sent in index order (as described in ChannelMetadata for the channel).
  2. ChannelRangeRequest responses MUST be sent in index order.
  3. Index order is always as appropriate for the 2.2.1 Requirements for ChannelStreaming Protocol of a Channel.
  4. The same primary index value MUST NOT appear more than once in any ChannelData record (unless it is correlated to ChannelRangeRequest).

Range Requests

Behavior
  1. The from and to indexes in a ChannelRangeRequest MUST be in index order.
  2. The from and to indexes in a ChannelRangeRequest MUST always reference the primary index.

Session Survivability

Behavior

For the ChannelStreaming protocol:

  1. Channel Metadata (including channelId) remains valid, provided that all ChannelMetadata records have been received (remembering ChannelMetadata can be a multipart response).
  2. Multipart responses to ChannelRangeRequest messages are not completed on session re-connect. If the consumer has not received all parts to a response, it MUST re-issue the ChannelRangeRequest.

On re-connect, a producer MUST send all ChannelDataChange, ChannelStatusChange, and ChannelRemove messages that would have been sent had the connection remained alive. The consumer MAY receive a duplicate message.
Figure 2.2.1-1 : Protocol 1 - Simple Streaming

The simple streaming diagram shows the minimal session interaction for a simple producer of data (Protocol 1). This scenario describes how a simple device can perform the functions of something like WITS-0 over this protocol.

Note that the notions of client and server are independent of this sequence. The roles of producer/consumer will have been requested and agreed in the session initiation sequence of Protocol 0.

For simple streaming:

  • The producer MUST provide a name-value pair in the protocolCapabilities field of the SupportedProtocol record, which indicates it does not accept requests to stream individual channels but always sends all of its channels. The name of the variable is SimpleStreamer and it MUST have a Boolean value of true.
  • The producer MUST NOT send any data until the Start message is received. The Start message indicates that the consumer is ready to receive data and establishes any rate-control or throttling parameters.
  • The producer sends at least one ChannelMetadata message, indicating the channels it will stream. For many producers, this MAY BE the only such message to be sent. However, if additional channels appear over time, it MAY send additional such messages.
  • After this, the producer can begin streaming ChannelData.

When a producer identifies itself as a SimpleStreamer, the producer and the consumer MUST NOT use any messages other than Start, ChannelMetadata and ChannelData. To avoid adding complexity to a protocol option that is designed to simplify producers, any use of unsupported messages in a SimpleStreamer session are ignored (i.e., if those messages are used, there is no requirement that the producer or consumer issue exceptions).

Figure 2.2.1-2 : Protocol 1 - Channel Streaming

The channel streaming diagram shows the full range of messages that might be exchanged over Protocol 1. Before streaming channels, or requesting specific ranges, the consumer starts by sending a ChannelDescribe message for at least one URI. The resulting ChannelMetadata messages provide a unique channelId (valid only for the life of the session) which is then used in subsequent ChannelStreamStart or ChangeRangeRequest messages.