Streaming
Overview
Once the client establishes a connection with the server, it can begin streaming measured data using a subscription-based model. Here’s how it works:
-
Streaming initialization: The client initiates the streaming process by sending an initialization request to the server. In response, the server sends packages containing information about each available signal. Once all signals are accounted for, the server sends an acknowledgment package to complete the initialization.
-
Available/unavailable signal information: The package sent by the server to notify the client about an available signal includes a unique non-zero numeric ID assigned by the server, a symbolic ID (global ID of the openDAQ™ signal), and a serialized string containing all relevant signal information, such as the signal descriptor and associated domain signal symbolic ID. The server notifies the client of any changes in signal availability - it sends packages to inform the client when new signals become available or when previously available signals become unavailable.
-
Signal subscription: After initialization, the client can subscribe or unsubscribe to any available signals at any time. When the server processes a subscription or unsubscription request, it sends a corresponding acknowledgment notification package to the client.
-
Signal packet streaming: For subscribed signals, the server sends packages containing the signal’s packets.
Streaming packages types
Streaming initialization request
To initiate the streaming flow after connecting to the server, the client should send the corresponding request package:
Package type |
Streaming initialization request |
Package type code |
0xB |
Direction |
client → server |
Header-only package |
The server will respond with Signal available notification packages, one for each available signal, and acknowledge the completion of streaming initialization with a Streaming initialization done acknowledgement package.
Streaming initialization done acknowledgement
After the server completes streaming initialization by sending Signal available notification packages for all available signals in response to the Streaming initialization request, it sends a header-only notification package to the client. This helps the client to be aware that the initialization step is completed.
Package type |
Streaming initialization done acknowledgement |
Package type code |
0x6 |
Direction |
server → client |
Header-only package |
Signal available notification
The server sends a signal available notification package for each available signal during the streaming initialization stage. Additionally, after initialization is completed, it is also send to notify the client that a new signal has become available. The notification contains signal numeric and symbolic IDs, and the serialized signal form presented as a null-terminated JSON string, adhering to the standard openDAQ™ serialization format:
Package type |
Signal available notification |
Package type code |
0x2 |
Direction |
server → client |
Payload structure:
Bytes group | Start position offset (in bytes) | Value type | Size in bytes |
---|---|---|---|
Signal numeric ID |
0 |
Unsigned 32 bit integer |
4 |
Signal symbolic ID size (in bytes) |
4 |
Unsigned 16 bit integer |
2 |
Signal symbolic ID |
6 |
String |
Signal symbolic ID size |
Serialized signal string |
6 + Signal symbolic ID size |
String |
Rest of the payload size |
Serialized signal string example:
{
"__type": "Signal",
"domainSignalId": "/DomainSignal",
"dataDescriptor": {
"__type": "DataDescriptor",
"name": "",
"sampleType": 2,
"dimensions": [],
"rule": {
"__type": "DataRule",
"ruleType": 3,
"params": {
"__type": "Dict",
"values": []
}
},
"origin": "",
"metadata": {
"__type": "Dict",
"values": []
},
"structFields": []
},
"public": true,
"description": "Value signal description",
"name": "ValueSignalName"
}
Signal unavailable notification
Once any previously available signal becomes unavailable, the server sends a signal unavailable notification package:
Package type |
Signal unavailable notification |
Package type code |
0x3 |
Direction |
server → client |
Payload structure:
Bytes group | Start position offset (in bytes) | Value type | Size in bytes |
---|---|---|---|
Signal numeric ID |
0 |
Unsigned 32 bit integer |
4 |
Signal symbolic ID |
4 |
String |
Rest of the payload size |
Signal subscribe request
After connecting to the server and completing the streaming initialization, the client can request to subscribe to any of the available signals at any time. If the subscribed signal is a value signal, then the corresponding domain signal should also be subscribed to by the client side. If the client is using the openDAQ™ SDK, the domain signal is automatically subscribed along with the value signal. For custom client implementations, it is the developer’s responsibility to ensure that the domain signal subscribe request is sent along with the subscribe request for the value signal. Subscribing to the domain signal should always precede that of the value signal.
The subscribe request package contains the signal numeric and symbolic IDs:
Package type |
Signal subscribe request |
Package type code |
0x4 |
Direction |
client → server |
Payload structure:
Bytes group | Start position offset (in bytes) | Value type | Size in bytes |
---|---|---|---|
Signal numeric ID |
0 |
Unsigned 32 bit integer |
4 |
Signal symbolic ID |
4 |
String |
Rest of the payload size |
Signal unsubscribe request
To unsubscribe previously subscribed signal, client sends corresponding request package:
Package type |
Signal unsubscribe request |
Package type code |
0x5 |
Direction |
client → server |
Payload structure:
Bytes group | Start position offset (in bytes) | Value type | Size in bytes |
---|---|---|---|
Signal numeric ID |
0 |
Unsigned 32 bit integer |
4 |
Signal symbolic ID |
4 |
String |
Rest of the payload size |
Signal subscribe acknowledgement
To notify the client that the requested signal subscription has been completed by the server, it sends a corresponding acknowledgment notification package:
Package type |
Signal subscribe acknowledgement |
Package type code |
0x7 |
Direction |
server → client |
Payload structure:
Bytes group | Start position offset (in bytes) | Value type | Size in bytes |
---|---|---|---|
Signal numeric ID |
0 |
Unsigned 32 bit integer |
4 |
Signal unsubscribe acknowledgement
To notify the client that the requested signal unsubscription has been completed by the server, it sends a corresponding acknowledgment notification package:
Package type |
Signal unsubscribe acknowledgement |
Package type code |
0x8 |
Direction |
server → client |
Payload structure:
Bytes group | Start position offset (in bytes) | Value type | Size in bytes |
---|---|---|---|
Signal numeric ID |
0 |
Unsigned 32 bit integer |
4 |
Signal packet
After the client subscribes to the signal and server sends the corresponding acknowledgment, the server proceeds to transmit packages containing openDAQ™ packets. These packages encapsulate measured data packets or serialized openDAQ™ event packets.
Package type |
Signal packet |
Package type code |
0x1 |
Direction |
server → client |
Payload structure:
Bytes group | Start position offset (in bytes) | Value type | Size in bytes |
---|---|---|---|
Packet buffer generic header |
0 |
Binary data |
12 |
Packet buffer extra header + payload |
12 |
Binary data |
Rest of the payload size |
The structure of the packet buffer header and payload is detailed in the packet streaming protocol specification