Semantic-Data
over the Message Queue Telemetry Transport (MQTT) to be compliant with the specifications mentioned in the section Normative references.Messages
exchange over the MQTT protocol is out of the scope of this project. The library intentionally is designed to use any transport protocol meeting some basic requirements using external components. External components implementing MQTT connectivity can be seamlessly integrated with this SDK using dependency injection concept illustrated by the following domain model:Client
/Server
publish/subscribe messaging transport protocol. The protocol runs over TCP/IP, WebSocket or over other network protocols that provide ordered, lossless, bi-directional connections. According to the specification its features include:Application Message
. The Application Message
is the data carried by the protocol across the network for the application. When Application Messages
are transported they have an associated Quality of Service
(QoS
) and a Topic Name
. Topic Name
is the label attached to an Application Message
which is matched against the Subscriptions
known to the Server
. The Server
sends a copy of the Application Message
to each Client that has a matching Subscription
.Server
(called also a broker) acts as an intermediary between Clients
which publish Application Messages
and Clients
which have made Subscriptions
. The Server
:Network Connections
from Clients
.Application Messages
published by Clients
.Clients
.Application Messages
that match Client
Subscriptions
.Server
may persist Application Messages
so they can be delivered even if the Subscriber
is not online.Client
establishes the Network Connection
to the Server
. It can:Application Messages
that other Clients
might be interested in.Subscription
to request Application Messages
that it is interested in receiving.Subscription
) to remove a request for Application Messages
.Server
.Subscription
comprises a Topic Filter
and a maximum QoS
. A Subscription
is associated with a single Session
. A Session
can contain more than one Subscription
. Each Subscription
within a Session
has a different Topic Filter
. Topic Filter
is an expression contained in a Subscription
, to indicate an interest in one or more topics. A Topic Filter
can include wildcard characters.Client
and a Server
. Some Sessions
last only as long as the Network Connection
, others can span multiple consecutive Network Connections
between a Client
and a Server
.Client
and Server
is controlled using Control Packet
. The Control Packet
is a packet of data that is sent across the Network Connection
. The specification defines fourteen different types of Control Packet
, one of which (the PUBLISH packet) is used to convey Application Messages
.Keep Alive
attribute. It is a time interval measured in seconds and expressed as a 16-bit word. It is the maximum time interval that is permitted to elapse between the point in time at which the Client finishes transmitting one Control Packet
and the point it starts sending the next. It is the responsibility of the Client
to ensure that the interval between Control Packets
being sent does not exceed the Keep Alive
value.Topic Name
. If present, it divides the Topic Name
into multiple topic levels. A Subscription’s
Topic Filter
can contain special wildcard characters, which allow Client
to subscribe to multiple topics at once.Publisher
: is the actor that pushes NetworkMessage
structures to an underlying transport layer.Subscriber
: is the actor that consumes data encapsulated by the NetworkMessage
structure, which is polled from the underlying transport layer.Publisher
and Subscriber
don't have any subscriptions management functionality, namely, they follow a communication paradigm called unsolicited notification. When unsolicited notification occurs, a client receives a message that it has never requested. The Subscriber
must use a filtering mechanism to process only messages it is interested in.Server
.Application Message
encodingApplication Message
which means the OPC.UA.PubSub Subscriber
entities shall be configured in advance with knowledge of the expected encoding. Publisher
entities should only publish NetworkMessages
using a single encoding to a unique MQTT Topic Name
.Application Message
. It is expected that the software used to receive the message can process it without needing to know that it was transported via MQTT instead of UDP for example.Server
limits it should be broken into multiple chunks as described in the OPC.UA.PubSub Specification.QueueName
with the name $Metadata
. The MQTT RETAIN flag shall be set for metadata messages.Client
and the Server
, however, this requires that the Server
must be trusted. For that reason, it may be necessary to provide end-to-end security. Applications that require end-to-end security with MQTT need to use the binary message encoding and apply security protection defined in the OPC.UA.PubSub specification.mqtts://<domain name>[:<port>][/<path>]
wss://<domain name>[:<port>][/<path>]
Keep Alive
KeepAliveTime
is set on a WriterGroup
, a value slightly higher than the configured value of the group in seconds should be set as MQTT Keep Alive
ensuring that the connection is disconnected if the keep alive message was not sent by any writer in the specified time.Quality of Service
BrokerTransportQualityOfService
values map to MQTT Quality of Service
settings as follows:IMessageHandlerFactory
:ConsumerMessageHandlerFactory
- to create communication infrastructure for the consumer roleProducerMessageHandlerFactory
- to create communication infrastructure for the producer roleBinaryUDPPackageReader
- implements IMessageReader
inheriting from BinaryDecoder
BinaryUDPPackageWriter
- implements IMessageWriter
inheriting from BinaryEncoder