OPC UA PubSub Sniffing concepts: Difference between revisions
Line 41: | Line 41: | ||
| {{Style=Identifier|All}} || All || A grouping of capture types. Contains all message types (non-terminal and terminal). | | {{Style=Identifier|All}} || All || A grouping of capture types. Contains all message types (non-terminal and terminal). | ||
|} | |} | ||
; {{Style=Identifier|NetworkTraffic}}: This grouping is an opposite of {{Style=Identifier|AllPubSubMessages}}. It is useful when you are interested in the basic physical characteristics of the messages, such as which network traffic is actually present, whether it is actually an OPC UA PubSub traffic, and eventually "who is publishing (or discovering)". | |||
; {{Style=Identifier|AllPubSubMessages}}: This grouping is an opposite of {{Style=Identifier|NetworkTraffic}}. It is useful when you are not interested in the physical characteristics of the messages, but only in their logical meaning with regard to OPC UA PubSub. | |||
== Terminal and non-terminal messages == | == Terminal and non-terminal messages == |
Revision as of 09:40, 14 August 2022
Introduction
The sniffing mechanism for OPC UA PubSub allows you to observe network traffic that relates to OPC UA PubSub, and to certain degree, inspect and analyze the contents of the messages. Its uses can be e.g.:
- To discover which OPC UA PubSub participants are active on the network, and what kind of information they provide.
- In some phases of automated OPC UA PubSub discovery process.
- To capture the received message data, for troubleshooting, or for processing of non-standard messages.
The OPC UA PubSub Sniffing is not a substitute for a low-level network analysis, such as that provided by WireShark. Its purpose is somewhat different. Specifically, the OPC UA PubSub Sniffing is not meant to be always able to help with issues related to conformance with OPC UA standards. If the messages received are badly malformed, OPC UA PubSub Sniffing may have problems analyzing them, and that is OK. The OPC UA PubSub Sniffing is designed to help with configuration issues of otherwise correctly operating software.
Capture types
(TBD)
Individual capture types
(TBD)
If the transport message cannot be parsed as an OPC UA PubSub message, the TransportMessage is the only capture emitted for the message. Otherwise, there is a NetworkMessage capture emitted following the TransportMessage, containing the network message header information specific to OPC UA PubSub. In special cases (such as with non-standard OPC UA PubSub extensions), there can even be more NetworkMessage captures for one TransportMessage.
(TBD)
(TBD - mapping auto-detection)
Capture type groupings
(TBD)
Name | Display Name | Description |
---|---|---|
NetworkTraffic | Network Traffic | A grouping of capture types. Contains all network traffic messages. |
AllPubSubMessages | All PubSub Messages | A grouping of capture types. Contains all OPC UA PubSub (terminal) messages. |
AllDataSetMessages | All DataSet Messages | A grouping of capture types. Contains all dataset messages (parsed and unparsed). |
AllDiscoveryMessages | All Discovery Messages | A grouping of capture types. Contains all discovery messages (probes and announcements). |
AllDiscoveryProbes | All Discovery Probes | A grouping of capture types. Contains all (parsed and unparsed) discovery probe messages. |
AllDiscoveryAnnouncements | All Discovery Announcements | A grouping of capture types. Contains all (parsed and unparsed) discovery announcement messages. |
All | All | A grouping of capture types. Contains all message types (non-terminal and terminal). |
- NetworkTraffic
- This grouping is an opposite of AllPubSubMessages. It is useful when you are interested in the basic physical characteristics of the messages, such as which network traffic is actually present, whether it is actually an OPC UA PubSub traffic, and eventually "who is publishing (or discovering)".
- AllPubSubMessages
- This grouping is an opposite of NetworkTraffic. It is useful when you are not interested in the physical characteristics of the messages, but only in their logical meaning with regard to OPC UA PubSub.
Terminal and non-terminal messages
The capture types denote either non-terminal or terminal messages.
- non-terminal message
- The message is further structured and can contain other non-terminal or terminal messages. Consequently, there can be more captures arising out of a single non-terminal message.
- terminal message
- The message is not structured (or cannot be parsed) to further sub-messages. No further capture will be emitted for the terminal message.
Parsed and unparsed messages
Normally, the capture mechanism parses all parts of the message that are necessary to collect the information provided by the message. When the message or its part is encrypted, it is possible that the capture mechanism will not be able to decrypt (and parse) the full message contents, but will still be able to determine the type of the message and some PubSub header information. Such case is indicated by one of the unparsed capture types.
For more information to when the unparsed capture types are used, see Security and sniffing.
Capture header
(TBD)
Special cases
Security and sniffing
(TBD)
Data capture with sniffing
(TBD)
Transport message transformations
Some transports may not provide exactly the transport message received, but may transform it in some way. In such case, the OPC UA PubSub sniffer will not "see" the very original message as received, but will only be provided and see the transformed message data. This can happen, for example, if the transport provides an option to decompress the data.
Specifically: QuickOPC has an option to detect and auto-decompress data received in GZip format. This option is turned on by default in the MQTT transport, and turned off in the other transports (UDP, Ethernet). This means that when you use MQTT, and a GZip-ped message appears on the input, its capture data will already be decompressed in the TransportMessage capture. The fact that the data has been decompressed is indicated by the fact that the Compressed flag (property) is set in the Capture header.