Hi,

As far as I’m aware right now, what your customer is asking is not exactly part of OPC UA. This is meaning that in practice OPC UA Clients are not expecting the server to do that. If I would see this kind of behaviour I would expect the server to be buggy (at least that would be my first reaction). Depending how clients handle things there might be significant overhead on reconnections. Also data might be lost e.g. on subscriptions depending on things and parameters.

Like yes, the server can close the session, but it is upto interpretations; I have found this part in the specification: https://reference.opcfoundation.org/v104/Core/docs/Part1/5.5/
“
Sessions terminate based on Client or Server request, or based on inactivity of the Client. The inactivity time interval is negotiated during Session establishment.
“

and

https://reference.opcfoundation.org/v104/Core/docs/Part4/5.6.2/
“
Sessions are created to be independent of the underlying communications connection. Therefore, if a communications connection fails, the Session is not immediately affected. The exact mechanism to recover from an underlying communication connection error depends on the SecureChannel mapping as described in OPC 10000-6.

Sessions are terminated by the Server automatically if the Client fails to issue a Service request on the Session within the timeout period negotiated by the Server in the CreateSession Service response. This protects the Server against Client failures and against situations where a failed underlying connection cannot be re-established. Clients shall be prepared to submit requests in a timely manner to prevent the Session from closing automatically. Clients may explicitly terminate Sessions using the CloseSession Service.

…

If a Client invokes the CloseSession Service then all Subscriptions associated with the Session are also deleted if the deleteSubscriptions flag is set to TRUE. If a Server terminates a Session for any other reason, Subscriptions associated with the Session, are not deleted. Each Subscription has its own lifetime to protect against data loss in the case of a Session termination. In these cases, the Subscription can be reassigned to another Client before its lifetime expires.
“

So if we take the Part 1 to mean that yes server is allowed to terminate the Session if no messages are handled for timeout period, then it maybe could be argued that the server should not close the session “at will; without a cause”. But IF we take it to mean that it can do it for any reason, then I guess it is fine. Though in general for unspecified things servers usually might do their own server-specific implementations.

So in general, I would like to know why your customer has requested it. I could see some analogy to e.g. normal www-webpages persisting the login to a time, but I could also argue that should those analogies be used here. Depends a lot of which kind of Server this would be.

Anyway, the process to make this to work is, subtype UaServer, override protected SessionManager createSessionManager() to return a subtyped SessionManager. Then override/or call there protected void closeSession(NodeId authenticationToken, boolean deleteSubscriptions) with false for the subscription deletion and the authentication token can be obtained from a Session object (which can be obtained from SessionManager.getSessions()). But as said, exactly right now I not sure how wise that would be (which is also somewhat the reason it is not part of the direct public API). You will need to keep track of time yourself. If you like, you can subtype Session as well and override SessionManager.provideSession to return the subtype, then you could record the inital creation time in that object and make some watchdog thread to close them at times etc.

In practice all clients do periodically read the Server/ServerStatus node to prevent the timeout.

In general as far as I have understood, typically in OPC UA it is the client’s responsibilty to close the Session and connection when the client is done (unless it is continuous, which means the client is intended to forever be connected to the server). The rest is basically just a safety net to prevent resource usage on the server if the client applications crash etc. and could not terminate connections/sessions.

Thus in this case, once the clients do no longer need to access the data, they should close the session and connection by themselves.

So if you want to do anything special in the server so that it would close them instead, you will really need to do the option I mentioned in the last section of the previous post (but as said, I’m not sure is it intended for an OPC UA server to behave like that). This is to say, there is no concept of “connection time” in OPC UA. There is the timeout time for sessions, but by the specification clients should do operations fast enough to prevent timeouts, and it is only a fallback mechanism for the server to recover lost resources.

This is at least how I see it now, but probably we should ask the OPC Foundation is situations like these supposed to be supported in some way.