Underlying Transport over UDP
The main goal of this document is to provide instruction on how to expand the transport layer for OOI Networking of the
Semantic-Dataover the User Datagram Protocol (UDP) to be compliant with the specifications mentioned in the section Normative references.
A reference implementation of the
Transportover UDP is provided by the project Networking.UDPMessageHandler. Because intentionally the SDK is designed to use any transport protocol, a custom external component implementing UDP connectivity can be seamlessly integrated with this SDK using dependency injection concept illustrated by the following domain model:
Figure 1. Domain Model
Instruction for implementers has been covered in the section Notices for Implementer.
The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application.
The User Datagram Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks. This protocol assumes that the IP protocol is used as the underlying protocol.
This protocol provides a procedure for application programs to send
Messagedatagrams to other programs with a minimum of protocol mechanism. Using this protocol the messages delivery and duplicate protection are not guaranteed.
The protocol is transparent for the user payload sent as the
data octets(stream of bytes). The
Lengthfield in the protocol header contains the length in octets of the user datagram including the header and the
To identify the communication parties (processes) the following information is used:
Source Port: - indicates the port of the sending process;
Destination Port: indicates the port of the ultimate destination process;
Destination Porthave a meaning only within the context of a particular internet address.
The OPC.UA.PubSub offers the publish-subscribe communication pattern as an option to client-server pattern and is a consistent part of the OPC UA specifications suit. The detailed description of the OPC.UA.PubSub has been covered by the document OPC Unified Architecture Part 14: PubSub Main Technology Features.
The specification defines the following actors:
Publisher: pushes messages to an underlying transport` layer.
Subscriber: polls messages from the underlying transport layer.
Publisheris the actor that pushes
NetworkMessagestructures to an underlying transport layer. It represents a certain data source, for example, a control device, a manufacturing process, a weather station, or a stock exchange. It may be also OPC UA Clients, OPC UA Servers or in general any applications that understand the syntax and semantics of the
Subscriberactors are the consumers of
NetworkMessagestructure, which are polled from the underlying transport layer. They may be OPC UA Clients, OPC UA Servers or in general any applications that understand the syntax and semantics of the
According to the specification the
Subscriberdon'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
Subscribermust use a filtering mechanism to process only messages it is interested in.
Lack of subscriptions management functionality defined by the PubSub could be mitigated by applying the IP Multicast option defined by the RFC 1112. IP multicasting is the transmission of an IP datagram to a "host group", a set of zero or more hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams. Internetwork forwarding of IP multicast datagrams is handled by "multicast routers". It means that the router must be multicast enabled. Further discussion related to this topic is outside of the scope of this document.
There must be mapping defined for:
- Messages Transport: the PubSub
NetworkMessagestructure serialized as the UDP
Destination Portand appropriate Internet address must be provided by the PubSub upper communication layer.
Publishershall support all variations it allows through configuration. The required set of features is defined through profiles defined in OPC UA Part 7: Profiles. A
Subscribershall be able to process all possible
NetworkMessagetypes and shall be able to skip information the
Subscriberis not interested in. The
Subscribermay not support all security policies.
NetworkMessageis sent as the UDP
data octets. It is expected that the
Subscriberprocess receiving the
NetworkMessagecan process it without needing to know that it was transported via UDP.
The syntax of the UDP transporting protocol URL has the following form:
The host is either an IP address or a registered name like a host name or domain name. IP addresses can be unicast, multicast or broadcast addresses. It is the destination of the UDP datagram.
The IANA registered OPC UA port for UDP communication is
4840. This is the default and recommended port for broadcast, multicast, and unicast communication. Alternative ports may be defined.
It is assumed that the IP multicasting is supported by the UDP protocol stock stack and the network infrastructure.
The article Reactive Networking of Semantic-Data Library contains description covering instruction for the external UDP handling components. An example how to implement the
Transportlayer for the UDP protocol is illustrated by the project UA Data Example Application. This library implements the
IMessageHandlerFactoryin the class
MessageHandlerFactoryused to create communication infrastructure for the
Producerrole as well.
JoinMulticastGroupmethod subscribes the
UdpClientto a multicast group using the specified
IPAddress. After calling the
JoinMulticastGroupmethod, the underlying
Socketsends an Internet Group Management Protocol (IGMP) packet to the router requesting membership to the multicast group. The multicast address range is
220.127.116.11. If you specify an address outside this range or if the router to which the request is made is not multicast enabled,
UdpClientwill throw a
SocketException. Once the
UdpClientis listed with the router as a member of the multicast group, it will be able to receive multicasted datagrams sent to the specified
Publisherdo not need to belong to a multicast group to send datagrams to a multicast IP address. To get more details visit the MSDN online documentation.