Hi,

(I wrote this before seeing your second post)

At least initially I would go with “this doesn’t make sense” option. Some reasons:

(But before that I would like to ask that do you have an actual/real problem scenario you are trying to solve/prevent or this more … theoretical stuff?)

1.
As far as I’m aware, the specification doesn’t consider a flooding scenario (outside of the service calls needed for the initial connection handling) exactly like this (see 3.). I assume here that you mean flood controls as e.g. too many Read service calls per second.

2.
As the specification doesn’t have this (1.), it in turn means no client would be “flood aware”. For example UaClient will usually do around 100 requests when it connects (or at least on the first interaction with UaNodes), which in normal cases the server should of course respond immediately. Additionally e.g. when a PublishResponse is received back a new one must immediately be sent. It would be hard to know what would be too much. And usually if the session would be closed, the usualy way for a client to properly react would be to reconnect (which in practice most likely would end up taking more resources, unless you would block that client). Generally I would say the risk is too high to fail something real. Especially when (3.).

3.
In a normal use-case an OPC UA Server will trust it’s clients (and vise-versa) and no untrusted clients are allowed to connect. Generally this should eliminate most of the problem cases by itself.

4.
(already mentioned in 3. a bit) If a server closes a Session, client will respond by making a new one. The same is if the connection terminates. You would basically need to ban the client either by not trusting it’s certificate anymore or with a firewall if you support None security mode in the server, but generally this is not the case, except for closed networks (shouldn’t be a problem usually here) or public demo servers (in which case you should use a firewall)

However if you really want to close the session manually, currently there is no exactly designed direct public API to do so. But you can do the following steps and it should work:
– Subtype UaServer
– Override protected UaServer.createSessionManager, return a subtyped SessionManager
– Override protected SessionManager.closeSession(NodeId authenticationToken, boolean deleteSubscriptions), (it must call the super impl)
– Store the subtyped SessionManager somehow or cast UaServer.getSessionManager()
– Call the closeSession with Session.getAuthenticationToken() for the NodeId and you probably want to delete the Subscriptions as well (they have different life-cycle from a Session and could be transferred to other Sessions)

Ok, just note that I would then recommend very clearly documenting the fact you are doing something like this as it is non-standard (as far as I’m aware). And if it is non-standard then it means no client can prepare for that, meaning it can cause interop problems, thus not sure if you can really call that as proper OPC UA. IF the application would pass the compliance tests of the OPC Foundation then probably it would be OK.

I would recommend highly consulting the OPC Foundation, as a lot less important things have been added in the specification in the past and lately, so I wouldn’t rule out e.g. some flood controls being added to the OperationLimits node for example. Then clients would have at least some chance of discovering the limits and try to obey them.