Hi,

(Sorry, this is a bit long)

No in that sense that the situation is the same as above, SDK does not contain any specific support for Durable Subscriptions at the moment. You are pretty much the only one who has asked for it.

I would still recommend the same thing Heikki explained above. If there is a use-case that it cannot solve I would like to know.

But in general even if we had support for Durable Subscriptions, I might still suggest going HistoryRead way as it would be easier in most cases.

With both you would need a database, but in the HistoryRead way you will only need to store the actual data (+the NodeId from where it came), with Durable Subscriptions you would need to store all the parameters of the sub + the queue data etc. If you have multiple clients, data storage size is O(1) in HistoryRead (they can share the data), in durable subs I would say it would be O(n) as each would need to store their own queue etc.

However I do agree that if it is not known beforehand which nodes would be used for durable subscriptions, they might be more dynamic than the HistoryRead way, as you would need to configure which nodes are storing history data. However that still would be at most one custom Method (+maybe another to stop), compared to the need that all clients softwares would need to support Durable Subscriptions (they need to call the SetSubscriptionDurable method + some extra requirements mentioned in the 1.04 Part 4 section 6.8). Depending on the data storage needs, it could be easier either way (if you have fixed amount of data per time unit, the db could just periodically delete it, if not then with HistoryRead you might need to call HistoryUpdate to delete it manually + cases with multiple clients could get tricky).

Now then, if you have (a lot of) spare time for experimenting, you could try the following:

Add a CallableListener (like MyMethodManagerListener in the samples) to NodeManagerRoot, intercept (and implement) SetSubscriptionDurable method to avoid Bad_NotImplemented return to clients.

Extend the following classes and methods (non-exhaustive list and some might not be needed):
– UaServer
– createSubscriptionManager
– createSessionManager (not sure if needed, you might need a listener to it)
– SubscriptionManager
– addSubscription
– createMonitoredDataItem
– transferSubscription (fake and create the sub before “transfering” it, or do as part of the Session creation via SessionManager)
– Subscription
– getNextSequenceNumber
– probably all or most of the other protected methods to store data sent to the client
– addDataItem, (you need to call Subscription.addItem for it inside the impl)
– MonitoredDataItem

Note! I have not tested that it is doable, it is very likely that you will hit some roadblock that cannot be solved. You would maybe need to fake some CreateSubscription and CreateMonitoredItemsRequests internally and pass these to the overridden methods.

NOTE! It might be hard or impossible at the moment to put the notifications inside the MonitoredDataItem

If you decide to try implementing, let me know if there are any problems.