Use of opc.https is not recommended in products developed with our SDK. We recommend using opc.tcp endpoints instead. Support for opc.https is deprecated, so new integrations should not rely on it.

You seem to be correct. Looking at the code, the DataSetReader implementation currently holds only one lastDataSetSequenceNumber, which is used when producing that warning log. Consequently, if multiple DataSetWriters are received by the same DataSetReader, the implementation does not distinguish the source of the sequence number.

Based on this, the sequence number validation should likely be tracked at least per DataSetWriter, even when the DataSetReader is the same.

I’ll create an issue for this. Thanks for the report.

I have a UDP publisher publishing 2 DataSets in 2 different DataSetWriterGroups at different publishingIntervals (1000ms and 2000ms).

The subscriber uses a single DataSetReader/group without preconfigured writer/publisher/.. ids to receive all possible messages on that multicast socket.

When logging the subscriber side, the SDK warns about old sequenceNumbers, comparing the sequenceNumbers from both received DataSetWriters. It is my understanding from the Standard Part 14, 7.2.4.5.4 DataSetMessage header, that the SequenceNumber is related to the DataSet and not to a publisher. Is the SDK sequence number evaluation possibly incorrect here?

One PubSubSystem with multiple connections appears to support adding connections on the fly without stopping existing ones. Multiple PubSubSystems are not required just to avoid interruption when adding another multicast subscriber, based on the implementation. Additionally the docs show that the configuration updates are applied live meaning start/stop shouldnt be required when adding connections:

https://documentation.prosysop.....bFunction-

Of course, multiple PubSubSystems could provide better Application-level isolation (e.g. if you want separate life cycles/listeners for each connection) but based on your question, a single one should be suitable.

thanks for your reply.
We need to add connections (subscribers on additional multicast addresses) on the fly, while the subscriber/s on the first connection is/are already active. It is my understanding that the PubSubSystem configuration is, once created, mostly immutable. Adding a second connection would probably mean to stop the first PubSubSystem, update the configuration (or even create a new one if an update is not possible) and then start the new configuration with the added connection. Having multiple PubSubSystems would avoid that interruption.

My educated guess is that a singular PubSubSystem is the cleaner option since that supports your stated requirement of handling multiple connections. Do you have more requirements left unstated in the message? If you have something specific to point out, I could try to take a look and see if I can something more specific related to that.

P.S.
If you wish to wait, you'll likely get a more nuanced and direct answer once relevant people return from vacation 🙂

Are there any benefits of one over the other option apart from the possibility to start/stop each individually or together?

The updated SDK is now able to transmit the desired meta-data. As a quick trial I sent the EngineeringUnits as an EUInformation structure and it is easily retrievable from the metadata.

Thank you very much for providing the SDK update so quickly.

Have an enjoyable holiday time.
-HU

Now in the Publisher in com.prosysopc.ua.samples.pubsub.SamplePubSubConfiguration.addPublishedVariableDataSet(Builder, UaNodeId) you can add e.g.
variableConfBuilder.putMetaDataPropertyMap(UaQualifiedName.standard("Test"), "TestValue");
Tested via in Subscriber side in com.prosysopc.ua.pubsub.PubSubSystem.addEventListener if you print the event/metadata.

Note that the SDK doesn't support 'metadata versioning' and it is only created when the PubSubSystem starts. Thus only constant values work. Depending how things go, maybe at some point there could be some "selector" configuration similar to how EventFilter works in opc.tcp events that would select sub-node values from a node being published (and maybe even monitor those ..), but that is possible future exploration.

Also, use namespaces for the UaQualifiedName(s) that are known for both sides. We sort of did a bit of a mistake in the design that both sides are assumed to know the types, but for a generic Subscriber it would instead need a separate "type realm" for each PublisherId+WriterId combination. The DataSetMetaData inherits from DataTypeSchemaHeader (from which also UABinaryFileDataType inherits) that is intended to list types used by the Publisher (though, in a case where the data would get pushed to a node on the server, then it must also follow that the server must know the type, or there wouldn't be much sense as far as I can think of use-cases).

Basically there is almost no information modelling in the PubSub side.

The metadata SamplePubSubConfiguration is related to which MQTT Broker topic the DataSetMetaData is published. You might be referring to the FieldMetaData https://reference.opcfoundatio...../6.2.3.2.4 that is contained in the DataSetMetaData. Currently there is no way in the SDK to cause anything be sent in the 'Properties' field related to it.

In UDP the Subscriber must ask for the metadata via the multicast network, the Publisher would then send a message that contains the DataSetMetaData. It would seem the spec also nowadays allows cyclic publishing (we could implement this in the future).

The only info our SDK Subscriber side would currently look from the DataSetMetaData are the field names. Custom types are not supported (but will probably work, if the Subscriber side already knows them) nor is the RAWDATA mode. Our Subscriber side will invent Field#### style names for fields of datasets for which it doesn't know the metadata. It will also send the "discovery request" messages for which our Publisher side will respond with the DataSetMetaData messages.

The received metadatas will cause SDK to update the PubSubSystemConf of the PubSubSystem. They can also be manually set via PubSubSystemConf.Builder.addDataSetMetaDatas(PubSubDataSetMetaDataConf). This only works for the Subscriber side, not for the Publisher side. The idea at least was that the SDK calculates the metadata from the nodes, as they already contain the information.

The com.prosysopc.ua.samples.pubsub.SampleUtils.addPubSubSystemListeners(PubSubSystem) shows how to listen for DataSet and DataSetMetaData messages. The metadata can be obtained also from PubSubDataSetMessage.getDataSetMetaData(), assuming it is known.

P.S.
The PubSubSystemConf PubSubDataSetMetaDataConf is only used in the Subscriber side.

PubSubPublishedVariableConf.getMetaDataPropertyMap() I believe at the moment does nothing. Probably should be categorized as a missing feature or bug, some of the thing were originally added 1:1 mirroring the spec configuration. It probably should go to com.prosysopc.ua.pubsub.PubSubFieldMetaDataConf.getProperties(), then I think it might get sent.

P.S.2
Vacation season starts soon, thus it might take after summer to do much

P.S.3
If a Subscriber would need instead a .uabinaryfile for the publisher configuration (this used to be common), there is a prototype implementation via PubSubSystem.commands().execute(PubSubSystemCommands.INTERNAL_PUB_SUB_SYSTEM_CONF_TO_UABINARYFILE, command) and give PubSubSystemConfToUaBinaryFileCommand as the command. Then com.prosysopc.ua.UaBinaryFile.toBinary() and write the ByteString.getValue byte[] to a file.

Could you please provide a short example of adding meta-data on the publisher side and retrieving it on the subscriber side? Both sides would be servers as well.

Many thanks

PS: I tried using PubSubPublishedVariableConf.putMetaDataPropertyMap` and `PubSubSystemConf.addDataSetMetaData'. But neither seems to serialize the meta data on the wire

Sorry, not supported by the SDK.

It might be implementable in the application level. However, some notes might be of use. To begin with, it would need to be differentiated do we talk about the ... "complicated hierarchical version" or "single FileType node version" of the address space. Also the use-case would need more details.

Seems nowadays the spec actually has an official "single FileType way" https://reference.opcfoundatio.....14/9.1.3.7. Something like this was typically seen as a custom solution when PubSub came out. Implementing the original information model is complicated, not sure has anyone done that. And if has, then does anything actually use it. For example, UaExpert back then had PubSub configuration view just writing a UABinaryFile to a custom FileType node. Lets just say PubSub is more "work-in-progress" than 'opc.tcp' (in general and our SDK-wise).

Probably the FileType way (PubSubConfigurationType) is a lot easier to implement in an application and since it is also atomic swap it probably would be the way to go for tools. Though, it is harder to visualize, as it needs to be read first.

PubSubConfigurationType might be implementable using SDK 5.7.0 by implementing custom FileTypeNode.FileWrapper + FileTypeNode.RandomAccessFileWrapper. You will also need to set an implementation of the com.prosysopc.ua.types.opcua.server.PubSubConfigurationTypeNodeBase.setCloseAndUpdateMethodImplementation(PubSubConfigurationTypeCloseAndUpdateMethod) as the PubSubConfigurationType methods are not implemented in the SDK. This could be something we could maybe implement in the SDK itself, though unlikely to happen "exactly now", maybe after summer.

For the "complicated hierarchical version" I can mention that UaServer.setPubSubConfigurator(PubSubConfigurator) was originally created as a hook for all the Method calls related to PubSub (https://documentation.prosysop.....rator.html, there is a lot, Codegen creates code that handles the routing to this interface). Though, in addition one would need to handle other services as well such as some Writes. Maybe this model could better serve as a read-only variation and possibly for e.g. restarting a failed Writer or something like that (as that is not a configuration change, sort of).

One of the downsides of us going with our own configuration style com.prosysopc.ua.pubsub.PubSubSystemConf, is that you need to convert it to com.prosysopc.ua.stack.core.PubSubConfiguration2DataType and back. SDK does not yet offer a method for this. Skipping details.

com.prosysopc.ua.UaBinaryFile offers some support for com.prosysopc.ua.stack.core.UABinaryFileDataType. Skipping a lot of details about custom types.

I am undertaking my first steps using the Prosys SDK for PubSub (UDP Binary). One benefit of an OPC UA server used for pubsub, as advertised by the OPC UA standard, is the ability to configure pubsub via the Server/PublishSubscribe part of the Server addressSpace.

Is there any support for this built-in to the SDK? I created a publisher as per pubsub tutorial and samplepublishserver, yet the addressSpace does not reflect anything of that configuration. Is there any automatic synchronization in either direction between the server addressSpace and the effective pubsub configuration or is this to be managed in application code?

Many thanks, Hans-Uwe

Let me reformulate my "wish" for an ideal code generator:
Assuming a / any valid nodeset.xml as an input, the generated code should be compileable without errors and expose all features of the nodeset design. I am very aware that this presents a real challenge and that this is hardly - if at all- ever accomplishable. So this is not any criticism - just a Christmas wish 🙂