There is currently a property called MaxMonitoredItemsPerCall which contains a limit on the number of MIs that can be in each call to one the MonitoredItems API. This does not help the client determine how many total MIs it can create.

A server can have limits on how many MontoredItems can be created, which can be per session or for all sessions. The server will return the status code BadTooManyMonitoredItems when this limit is reached. However, unless it is a custom app, the client has no way to know what this limit is.

This forces the client to handle the error and possibly do runtime error recovery - but the client still does not know what the limit is, so it may encounter this error over and over again as it retries smaller amounts. Error prevention is better error recovery - It would be better if this could be handled at design time as a configuration issue by making the limit known by reading a Node from the server or out of a NodeSet.

Suggestion: add an optional Property called MaxMonitoredItemsPerSession. If not defined then the server does not support this. If defined and set to 0 then the server imposes no limit. If set to any other value then it is the max number of MIs per session. There may be a need for a similar property for all sessions combined.