Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Deleting Custom NodeManager nodes
April 12, 2013
14:37, EEST
Avatar
TimK
Member
Members
Forum Posts: 41
Member Since:
June 27, 2012
sp_UserOfflineSmall Offline

I have multiple custom NodeManagers based on BigNodeManager, and I want to be able to make one of them go away dynamically.
I suppose I could just stop reporting all of the references and info about the nodes it controls, but it seems like there’s probably a better way to do this.
What’s the best practice here?

April 12, 2013
15:32, EEST
Avatar
Jouni Aro
Moderator
Moderators
Forum Posts: 960
Member Since:
December 21, 2011
sp_UserOfflineSmall Offline

That’s a good question đŸ™‚ Which means that I do not have a very good answer at hand.

Biggest problem is, if you have references to your nodes from other node managers – or from monitored items. In which case it is a bit uncertain what will actually happen.

But you might be able to just remove the NodeManager from NodeManagerTable (available from UaServer). It’s NamespaceURI will be kept in the NamespaceTable, so the indexes should not change, but the nodes will not be found any more.

Please, let us know how you manage with it.

April 12, 2013
19:10, EEST
Avatar
TimK
Member
Members
Forum Posts: 41
Member Since:
June 27, 2012
sp_UserOfflineSmall Offline

Heh, that’s not the answer I was hoping for đŸ™‚

I’m not worried about references from other node managers, each of mine will be self-contained.

What about calling beginModelChange() and then deleteNode()? Does that handle monitored items?
Is there no way within the spec to tell the client that a node went away?

April 15, 2013
8:53, EEST
Avatar
Jouni Aro
Moderator
Moderators
Forum Posts: 960
Member Since:
December 21, 2011
sp_UserOfflineSmall Offline

Oh yes, that is the correct way to tell the clients that the nodes have been deleted. The specification defines that you must support the NodeVersion property for objects, before you should send ModelChange-events, though. And you must increase the NodeVersion value for each affected node when the event is sent.

The SDK updates the NodeVersion automatically for UaNode-based nodes (which have initialized the NodeVersion, e.g. by calling BaseNode.initNodeVersion()) and also ensures that changes related to such nodes are included in an open ModelChange.

You will need to do that yourself with your own nodes and you can use these NodeManagerRoot-methods:

beginModelChange() opens a model change,
addModelChange() adds changes to an open one
endModelChange() triggers the event (remember to update the NodeVersion).

or you can just construct the GeneralModelChangeEventType object yourself.

The event is reported always for the Server object (whole address space) or a View Node.

April 15, 2013
14:56, EEST
Avatar
TimK
Member
Members
Forum Posts: 41
Member Since:
June 27, 2012
sp_UserOfflineSmall Offline

It looks like this would work – I could start a model change, and then send NodeDeleted model changes for each node.

How would updating the NodeVersion work if I deleted the node? It wouldn’t have the property anymore, right? I guess I would need to have the property in the first place, so that the client expects the model change events on that node, but I don’t see how getting a new value of the property would work when the node has disappeared.

The other issue I see is that I would have to send a LOT of NodeDeleted events. The reason I’m creating a custom node manager in the first place is the large # of nodes in the namespace – I could have several hundred thousand, so it seems like that could be a pretty big performance/network issue. Is there a way to say that a whole tree was deleted from the namespace? I suppose I could just send notifications for the subscribed values, and then maybe send another notification if any of the other deleted values are requested later?

April 16, 2013
6:38, EEST
Avatar
Jouni Aro
Moderator
Moderators
Forum Posts: 960
Member Since:
December 21, 2011
sp_UserOfflineSmall Offline

Yes, I was wondering about that too. I had got this so that you could just define the NodeVersion for some top level objects and then notify that they are deleted, which should imply that the complete structure has been removed under it.

The Monitored Items can be treated also by sending a Bad_NodeIdUnknown status for them to imply that the nodes have been removed.

April 16, 2013
16:37, EEST
Avatar
Jouni Aro
Moderator
Moderators
Forum Posts: 960
Member Since:
December 21, 2011
sp_UserOfflineSmall Offline

I asked some advice from other experts and it seems that the correct strategy is indeed to define NodeVersion only for a reasonable number of objects, for example, for devices that have a known structure – or if that seems too much, for even higher level nodes.

For each node that has NodeVersion, you should add a NodeDeleted + ReferenceDeleted plus one ReferenceDeleted for the (or each) node that has a reference to the deleted node.

If you still suspect that this will make a too big ModelChange message, you may considering breaking it to several smaller once (one for every 1000 devices, for example), to ensure that the message does not exceed the message size limits of the UA stack at either end (server or client).

But you have free control over it by defining NodeVersion only to nodes that you consider to really need the notification.

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 267

Currently Online:
23 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 124

pramanj: 86

ibrahim: 74

rocket science: 65

kapsl: 57

Sabari: 51

gjevremovic: 49

Xavier: 43

fred: 41

TimK: 41

Member Stats:

Guest Posters: 0

Members: 1749

Moderators: 15

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1323

Posts: 5649

Newest Members:

WalterFOUNC, datafastproxiespx01, LenkaLok, seoninet, justinevillanuev, namtrott5457, DonaldWibip, AlfredoEthix, andreidla, everangel7021

Moderators: Jouni Aro: 960, Otso Palonen: 32, Tuomas Hiltunen: 5, Pyry: 1, Petri: 0, Bjarne Boström: 860, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 25, Teppo Uimonen: 21, Markus Johansson: 42, Niklas Nurminen: 0, Matti Siponen: 222, Lusetti: 0

Administrators: admin: 1