Hi,

Well, in short “Rate limiting” is not a thing in OPC UA (as far as I’m aware, could be wrong, but basically this is how it has been the last 10-15 years).
Connections could be limited (specification talks about this), though our SDK doesn’t offer a way to limit them (we might someday). It can be done outside the application/SDK in the firewall level, which is also probably a better idea to prevent DOS attacks etc. Also an IP address might not be a good metric, companies and some ISPs do use NATs thus the same IP might be for very many connections and all could in theory be valid.

SDK does limit the number of Sessions (that is by default 100, in SessionManager of the UaServer).

Once there is a valid Session, in general it would not be expected for e.g. a Read to “randomly fail” due to any “rate limiting” etc. a response would just be returned once possible. This is to say, clients would not know how to deal with this kind of a failure and I do not think there is exactly any suitable status code. There is Bad_TcpNotEnoughResources, but that would be only if the tcp connection could not be formed. Probably clients would just resend the request immediately.

Is there a specific use-case you have in mind that would require this (for Read/Browse)?

Anyway, in technical terms, there is a shared 64 thread “blocking work pool” in StackUtils, which is used in very many things (more in the “stack layer”) due to historical reasons, but it also basically means at max 64 service calls are processed concurrently. It doesn’t exactly prevent clients for sending more (though at some point the Selector that multiplexes all sockets would get slown down as well and then the tcp buffers would fill and that would maybe eventually on the tcp level prevent clients sending more), but I guess can somewhat be thought as a “rate limiter”, but not in application level sense.

In that case I do want to note a bit more.

I do not think it would be typical OPC UA (though you can ask the OPC Foundation, they would probably be better to answer that).

IF you meant like this, there is a status code, https://reference.opcfoundation.org/v104/Core/docs/Part4/7.34.2/, Bad_LicenseLimitsExceeded, though I do not think it is at least intended to be used exactly like this. Plus it might be a bit newer definition, thus older clients would not know what it means.

The biggest “problem” (and half of the point of OPC UA) probably is that OPC UA is self-descriptive, i.e. there is a lot of “metadata” in the information modelling in addition to the “real data”. It might be hard to differentiate that (maybe on the namespace level it is easy, after that harder). Basically the clients must be able to read this metadata, always, repeatedly maybe, or they will fail. This is to say, at least half of the point of OPC UA is that clients can read this metadata about the data.

Also, we do read the ServerStatus once per second. This must work, a failure would trigger a reconnect. I would expect other clients to do something similar.

Also nowadays we do read the whole Types part of the server. While that is a bit crazy, it works out quite well in practice in most cases, and is somewhat needed anyway for custom Structures (and basically getting all/rest of the types at the same time is somewhat efficient). That is typically around ~50000 operations (which on our defaults server+client will get packed to around 5-10 service calls) on connect (this can also be disabled, though any interaction with UaNodes will then result in ~100 service calls instead; depending a bit what is done as the meta info are also nodes and it kinda works recursively one-by-one if we have not read them on connect).

In tech terms “yes”, but as a general concept, “no”.
I will repeat that as far as I know or remember (of the ~10 years I have been working with OPC UA) it would be the first Server to do this (obiviously I will see just a slice of the world, but still) . So Clients _really_ would NOT be expecting it. Also clients might not be able to directly control when they Read, for example our client side SDK using UaNodes will automatically re-read or Browse things on cache misses and expirations.

Also note that OPC UA has Subscriptions, thus any Read limits would be meaningless for clients using those. And limiting those is kinda hard in tech terms, as it is not, well, part of OPC UA. I’ll note that in the MyBigNodeManager the monitored items are controlled more as that example is a bit lower-API (doesn’t use UaNodes), but anything UaNodes might be hard to control, as SDK internally processes the value to the items (sort of what MyBigNodeManager does manually).

I would recommend asking the OPC Foundation, they might have ideas (or verify my “this is not a good idea” note).

In technincal terms with the SDK, there are lot of listeners, and things could be subtyped and protected methods overridden. Not all, but most things eventually become possible, though we might not like support every possible thing made this way, i.e. https://www.prosysopc.com/services/ might be needed as it might require a lot of time to investigate is X possible.

However, that exact method doesn’t help, it gives a note that client requested changes in e.g. sampling interval. It could be used in MyBigNodeManager-style managers who are managing the monitored items on their own, as they must also do the data-changes manually to the items. IF you do all your own namespace managers like MyBigNodeManager, you could limit the data (though you cannot then use UaNodes). It still would not be like per specification I guess to do that or it would be a gray area of what exactly should happen. I guess you could push a DataValue with the statuscode mentioned above posts, but I would expect you to get lots of questions from people using your server.

So, in short in normal conditions and using UaNodes, you could prevent creation of an item or subscription or revise e.g. publishing interval, but once the item is done and active it will operate and (simplified) any value set on the UaNode will be seen by all the clients who have made an item to that node.

So you could e.g. have a limit of items/subscriptions in total per a session. Servers typically have some limits on these. But it would not affect how much data client will see form the item. I guess in theory you could have different revise logic for e.g. publishinng intervals, though that too would be a bit weird I think.