Subscription closure and StatusChangeNotification|OPC UA Standard|Forum|OPC Foundation

Avatar
Search
Forum Scope


Match



Forum Options



Minimum search word length is 3 characters - maximum search word length is 84 characters
Lost password?
sp_Feed sp_PrintTopic sp_TopicIcon
Subscription closure and StatusChangeNotification
Avatar
Viacheslav Usov
Member
Members
Forum Posts: 11
Member Since:
03/24/2017
sp_UserOfflineSmall Offline
1
03/24/2017 - 09:23
sp_Permalink sp_Print

As described in Part 4, 5.13.1. a subscription may enter the state CLOSED. Because this is the state for a subscription “not yet created”, this can be interpreted as if the server were not required to maintain any state for subscriptions in this state.

When a subscription enters this state because of the “lifetime” counter’s reaching zero (row 27 in Table 83), the server has to issue StatusChangeNotification and make the subscription’s state CLOSED.

Now, the very nature of this transition implies that there are no Publish requests queued for the session that the subscription is associated with. So this cannot be delivered to the client before the subscription becomes CLOSED. Then, if the subscription becomes CLOSED, the server (per my interpretation above) does not need to maintain any state, and so it does not need to save this notification for any future use.

Which effectively means everything about StatusChangeNotification can be ignored. Which probably means my interpretation is not correct, and the server has to keep some state for a CLOSED subscription, if it has been created earlier.

Then the question is, what happens next? Am I right assuming that at some point later the client may still send a Publish request for that session, in which case the StatusChangeNotification can be happily delivered and the subscription made really CLOSED? What if the client never sends anything within that session?

Avatar
Guest
Guests
2
03/27/2017 - 04:08
sp_Permalink sp_Print

Publish handling is on Session level. As long as the Session is valid, Clients shall continue to issue Publish requests until a “Bad_NoSubscription” is returned. The Server will not delete a CLOSED subscription until it has sent the final notification. The spec defines:

“Closing the Subscription causes its MonitoredItems to be deleted. In addition the Server shall issue a StatusChangeNotification notificationMessage with the status code Bad_Timeout.”

If the Session gets invalid before a Publish request is received, the Session and the stored StatusChangeNotification can be deleted too.

Avatar
Viacheslav Usov
Member
Members
Forum Posts: 11
Member Since:
03/24/2017
sp_UserOfflineSmall Offline
3
03/27/2017 - 06:40
sp_Permalink sp_Print

Many thanks for your response. I understand the intended behaviour now.

However, I think that this is not clear from reading the standard. In my opinion, a new state, say CLOSED_WAIT, should be defined, so that the subscription enters this state in row 27 of Table 83, and two further transitions must be defined from CLOSED_WAIT, one upon having a Publish request, another upon the termination of the owning session; in either case the subscription transitions into CLOSED, but in the former case StatusChangeNotification is issued.

Forum Timezone: America/Phoenix
Most Users Ever Online: 510
Currently Online:
Guest(s) 12
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Forum Stats:
Groups: 2
Forums: 10
Topics: 1444
Posts: 4887