Let me reformulate my "wish" for an ideal code generator:
Assuming a / any valid nodeset.xml as an input, the generated code should be compileable without errors and expose all features of the nodeset design. I am very aware that this presents a real challenge and that this is hardly - if at all- ever accomplishable. So this is not any criticism - just a Christmas wish 🙂

As far as I'm aware, AccessLevel in the InstanceDeclarations is more like a "default value", not a "contract". At least based on the base spec I mean. A companion spec might be able to limit this (in the text, not in a way for Codegen to know). Some Attributes have limits, https://reference.opcfoundatio.....00-3/6.2.7 + https://reference.opcfoundatio.....00-3/6.2.8, but to my knowledge nothing is said for AccessLevel. Also, the generated setters are mostly for server side, but there it is usable always for setting the value, even if it would be read-only from a client's point of view.

Just be careful to remove the component-setter version from all of the generated files (i.e. not accidentally removing the method one in e.g. one file). The method one does also have ServiceException in addition to the StatusException. Note that the only difference to the Codegen-InstanceDeclaration-exclusion-way is that the getter and "node-getter" generated methods exist still (but this could be important).

P.S.
This of course causes me to think could we have some day an option to exclude "any generated method". We do have class-level exclusions https://documentation.prosysop.....ut-classes, basically to avoid generating XXXTypeNodes that are in version control due to implemented methods.

Though it would still be more of a workaround than an actual solution.

I am reluctant to exclude anything from code generation because most of the variables/components/methods are indeed important and required.
While the nodeset design is a bit unfortunate from a code generation perspective, it is still quite common to use explicit UA methods as setters and have likewise named read-only variables. It would be "cool" if some time in the future the code generator could consider the accesslevel of a variable.as well. if it is "CurrentRead", then not generate a setter, if it is CurrentWrite and a setter method exists as well, then emit a warning.

I created (or rather Github Copilot) a gradle task to analyze the generated code, looking for setter and method definitions with conflicting signatures and remove just the duplicate setters. This way I don't need to exclude any components and the code is compiling okay.

Once again, many thanks for looking into this.

It is a known issue: https://documentation.prosysop.....own-issues

The model https://reference.opcfoundatio.....0020/6.6.3 defines both a CalculatedPosition component and a SetCalculatedPosition Method. Thus it will conflict when we create the setter for the CalculatedPosition component and then the actual method for calling the Method. Codegen is not yet smart enough that it would detect and report this as an error directly. (There are also few other types in this model that do the same); we can hopefully do this at some point.

You must exclude one of them via https://documentation.prosysop.....generation. I would recommend excluding the CalculatedPosition component, as it is easier to get via the generic UaNode.getComponent(QualifiedName) than implementing the Method call via https://documentation.prosysop.....tener.html style.

Thus, something like this in the Codegen configuration should do it:

(...some day better code-snippet way.... but anyway have "http://opcfoundation.org/UA/MDIS:CalculatedPosition" without quotes as the 'instanceDeclaration' tag data)
Note that it does exclude the CalculatedPosition node from all types of http://opcfoundation.org/UA/MDIS. This was originally designed to avoid conflicts with the SDK API itself.

P.S.
Personally I would say it is a bit of an odd choice in the model that there seems to be Methods that just serves the same role as what a simple Write operation could do. There is maybe a bit of nuances regarding the async clause https://reference.opcfoundatio.....0020/6.6.7 though Write does have that as well https://reference.opcfoundatio.....4/5.11.4.4. (though only in the presence of an "intermediate system", though an UA Client doesn't anyway know nothing of that so.. why does it matter). However, this is not the first time we see such models, so it is probably too late anyway to try to change them. Also, there could be valid cases, if more parameters would be involved the very least. (Or there could be something I miss here).

P.S.2.
It is possible we some day do something for this. Though it is .. somewhat complicated to find a good solution that doesn't involve excluding. We could e.g. start to use prefixes for methods i.e. 'callXXX' instead of 'xXX' where XXX is the method name (though this would change all existing ones). It could maybe be a flag in the Codegen configuration, though then it gets tricky with overriding of methods (even more if doing so from the core model that is already generated in the SDK). We could try doing that only for methods starting with 'set'/'get', but then it is different based on the name (and could still maybe theoretically conflict). We could add a unused parameter as the first java-parameter in the method, but that too is a bit clunky solution.

I would like to generate code from the MDIS Companion standard, v1.3. The code generation itself succeeds without warnings or errors. The code does not compile, though, because some method declarations occur twice within the same class or interface.

Is this a problem with/of the companion standard or does the code generator need to be configured in a custom way?

As an example:

Edit: Taking a closer look at the nodeset / companion standard, there is a read-only variable for each method, reflecting the value, which the method is expected to set. It looks like the code generator creates a setter method for those variables nonetheless. Another indicator for this are the declared exception types.
Is there any way to configure the code generator to NOT generate setters for any variable at all?

Define 'isolation' and 'user'.

Some levels of 'isolation' is impossible, as the network and execution environment is shared. For example, the message processing does use a shared thread pool (but even if not, individual threads would share the CPU). You would need a separate server per user and different hardware or container execution limits to avoid that. (Then you could use https://prosysopc.com/products.....-ua-forge/ to aggregate them to create an "admin view" server).

For 'user' are we talking about your customers (i.e. "your users") or an OPC UA 'User'. Note that the UA User is only known at ActivateSession, before that you do not know it, thus you can only have "global limits". Non-UA-users would then be e.g. IP-ranges (socket connection), ApplicationUris (client certificates, UA Applications, OpenSecureChannel) or ApplicationDescription (CreateSession, has more detail than just ApplicationUri, though not much more). Personally I would say socket-level limitations should be done on the firewall already, maybe we some-day have things in the SDK, but at the moment it is not possible to limit on that level (other than the global limit).

There is a thing UaServer.setOperationLimits(OperationLimits) (set before UaServer.init()), that does control how many operations a ServiceRequest can contain. Default is 10000 in each type. This is also global though. And assuming relatively normal hardware I would keep it at 10000. One reason is that our client side by default does Read/Browse the entire Types part of the address space on connect (skipping some details, but mostly for Structure metadata; not ideal, but I would say best option so far). It doesn't typically result in that many individual ServiceRequests, but the total number of operations of them might be in 10000-30000 range total.

P.S.
This forum will most likely be down for a few hours later today due to infrastructure changes.

Bjarne Boström said
SDK already limits sessions and connections.

Yes, but those limits are global and not user-specific, right? As I said, we have a multi-tenant service (OPCUA as a service), where users should be isolated from each other and handled individually.

The SessionServiceHandler lacks the protected xxx(ServiceContext serviceContext, XXXRequest request, XXXResponse response) methods what are in the others. It goes more directly to the SessionManager. In the others they are sort of a "last effort place" to try to implement something, but regarding sessions SDK already should be implementing it .. completely (compared to e.g. data related to a Node's Attributes).

We do have intended ways for this as well: UaServer.getSessionManager().addListener(SessionManagerListener) see https://documentation.prosysop.....tener.html. Also, for just user-validation there is UaServer.setUserValidator(UserValidator).

We have also build ways to override the SessionManager via a subtype, similar to the handlers, though the raw ServiceRequest is not available (but the relevant parameters of it are, in the protected methods). It is also possible to use a subtyped Session.

Note that SDK already limits sessions and connections. They are separate things, though most of the time it is 1:1. By default SessionManager.getMaxSessionCount() defines max number of sessions and by default 10% more (at least +1) opc.tcp connections can be made. This so that a client can see that the server is at session limit. UaServer.setMaxOpcTcpConnections(Integer) can be used to set a different limit. Note that in the SDK (and per UA spec), non-properly-ActivateSession'd connections are dropped if at connection limit and a new one arrives. Note that there is not a way to observe the actual connections (we might build this some day).

> In practice we have not encountered that much “real world examples”
Yes, I guess our usecase is special: we are providing access to dynamically registered devices, kinda "OPCUA as a service" thing. But anyways, “Simple things should be simple, complex things should be possible.” is also valid here 🙂

One more question: You said you don't recommend overwriting SessionServiceHandler - for what reason? It would also be interesting for us to listen and monitor attempts to create (or activate) sessions, as those indicate the number of connections. And it would be good to use the same technique as with the other requests.

Thanks!

I did mean the EndpointServiceRequest version, but as long as you have not used UaServer.getLoopbackClient() (skipping details) then validateRequest(ServiceRequest, ServerSecureChannel) is ok as well.

In practice we have not encountered that much "real world examples". Like, the best one is our public Simulation Server instance which sometimes get "stuck" when someone makes many sessions so that the max sessions/connections limit is reached. But then again normally one has firewall rules that only accepts connections from defined sources, so not sure does even this count.

I will try the proposed approach and let you know, but it looks promising! I just guess you meant `com.prosysopc.ua.server.ServiceHandler.validateRequest(ServiceRequest, ServerSecureChannel)` ?

Regarding the rate limiting, yes, what you say makes sense, but how can an OPC UA server then deal with misconfigured clients and prevent being taken down by an unintended DoS? Do you have any recommendations or experience? I already asked about this in particular in this old thread, but a real-world solution was not found: https://forum.prosysopc.com/fo.....or-server/

There exists ServiceHandler.setRequestResponseListener(RequestResponseListener), which could be used for a logging-only scenario, you can get the XXXServiceHandlers from UaServer. This listener is called just before sending back the response (which should not be modified here). This is what our Simulation Server Application's Req/Res Log tab uses. Though, seems we have not used ServiceContext here in this Listener, thus the logic relies on com.prosysopc.ua.server.SessionManager.getSession(NodeId) using the authentication token from the header (though, this is what is also used for forming the ServiceContext).

Not exactly, as the point of an OPC UA SDK, in general, is to provide a higher-level abstraction and thus to try hiding the complex raw communication details.

10+ years ago the communication layers of OPC UA typically looked like:

+----------------------+
|         TCP            |
+----------------------+
|      UA Stack       |
+----------------------+
|       UA SDK        |
+----------------------+
|  UA Application  |
+----------------------+

Stacks were responsible to handling the raw socket connections, encoding messages to binary and then provide a raw request-response layer for the actual services. SDKs then abstract things more and provide something more use-able. What you basically say you would want would have been inside the Stack level, though 'SecurityToken' is not actually a "user token", but instead details related to the opc.tcp SecureChannel.

Nowadays Stacks are basically gone extinct. Some history regarding our SDK: https://documentation.prosysop.....ck-changes .We did make a mistake 15+ years ago that the stack classes were used directly in the SDK APIs, unfortunately fixing that might be impossible at this point. But basically other than those (and some util classes), classes being in 'com.prosysopc.ua.stack' package and subpackage should be considered to be "SDK private API".

That all is to say that it is not intended that you would normally handle the raw requests and doing so could break SDK's own functionality.

That being said, we do have some options, but it does require a bit more work. We would instead recommend using things that the sampleconsoleserver example shows, those are the intended ways, though that does involve attaching numerous XXXListeners to places for access control.

Anyway, you could try the following and let us know how it goes:
Subtype UaServer, override protected createXXXServiceHandler methods. Return sub-typed XXXServiceHandlers where 'XXX' is either 'Attribute', 'NodeManagement' or 'Subscription'. There exist also a SessionServiceHandler, but we recommend not to touch that one. Note that there are some methods that are final, those are historical Stack-to-SDK entry points and cannot be overridden.

However, you could override the com.prosysopc.ua.server.ServiceHandler.validateRequest(EndpointServiceRequest). It is recommended to call super first, to receive the ServiceContext that needs to be returned. You could throw ServiceException to fail the entire service. The ServiceRequest can be obtained from EndpointServiceRequest.getRequest(). However, I would be very cautious on doing any 'rate limiting' attempts, it is not something expected by UA Clients, they will either break or retry immediately, which would defeat the point.

The ServiceContext does tell the Session and from the Session you can get the ServerUserIdentity, which is server-side variation of the UserIdentity a client would use. The ServiceContext is a parameter in most of the recommended Listener-ways for handling authorization, it is passed along the call chain, see below.

An alternative is to look for methods such as https://documentation.prosysop.....dResponse- , and override them. These are called after the validate and then some of them will then split up more to other protected methods, then eventually they will go to YYYManagers. XXX and YYY might not be the same, but e.g. in Sessions it will go to SessionManager, which you can get normally from UaServer. It would provide info (a bit) about the sessions (UA has a Diagnostics concept). Many of YYY will have also YYYListener, here SessionManagerListener, that provides handles to react to their creation etc.

As this post is already quite long, I'll stop here for now, but please ask more and explain more about specifics what you would want to do.

I need finer control over client connections for various reasons (monitoring, statistics, access control, rate limiting, licensing, etc.).
I am interested in intercepting *all* low-level requests such as Create Session, Activate Session, Read, Write, Browse, etc.

Inspecting the code, the best would be to have a callback in the method `handleSecureMessage` of `OpcTcpServerConnection` (line 721), where I have access to the current `ServiceRequest` as well as `SecurityToken`. Unfortunately, the API doesn't provide access to this part of the code.

I also do not see any option in the `UaServer` API to inject any listener to handle requests on this level of granularity. Ideally, with the User token included.

Is there any option to intercept all requests, or would it be possible to build such an option in?

Thanks!

I've tested it and worked 😉