Log In
Home
03/24/2017
Offline
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?
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.
03/24/2017
Offline
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.
1 Guest(s)
Usage Policy