Hi,

I guess a better definition is https://reference.opcfoundation.org/Onboarding/v105/docs/3.1.2:
“3.1.2 ApplicationUri
a globally unique identifier for an OPC UA Application running on a particular Device. “
So basically it must be a “network-wide” unique identifier, i.e. for each connection address within a network an UA Client could take there must be an unique ApplicationURI behind it.

Applications such as the https://www.prosysopc.com/products/opc-ua-gateway/, https://www.prosysopc.com/products/opc-ua-historian/ and https://www.prosysopc.com/products/opc-ua-forge/ that can aggregate multiple OPC UA servers do use the ApplicationURI (as it must be unique) as a prefix for the NamespaceUris (as these are server-unique).

So, in short it depends that can the clients here chose which server/port they wish to connect to (or maybe even connect to more than one at a time), OR is there some external load balancer that chooses to which server the client is routed to and the fact that there are multiple servers is completely transparent to the client.

The OPC UA Specification has some parts regarding redundancy, please read https://reference.opcfoundation.org/Core/Part4/v104/docs/6.6.2 (though note that the SDK doesn’t support all of them and basically the ones supported need manual work for failover handling):
If Transparent:
“
6.6.2.3 Transparent Redundancy
6.6.2.3.1.1 Client Behaviour

To a Client the transparent Redundant Server Set appears as if it is just a single Server and the Client has no Failover actions to perform. All Servers in the Redundant Server Set have an identical ServerUri and an identical EndpointUrl.”

And it might not be that clear from the text, but (https://reference.opcfoundation.org/Core/Part4/v105/docs/3.1.13) the “ServerUri” in this context means the ApplicationURI.

IF Non-Transparent: then https://reference.opcfoundation.org/Core/Part5/v104/docs/6.3.9, and the server should have:
“ServerUriArray is an array with the URI of all redundant Servers of the OPC UA Server. See OPC 10000-4 for the definition of redundancy in this standard. In a non-transparent redundancy environment, the Client is responsible to subscribe to the redundant Servers. Therefore the Client might open a session to one or more redundant Servers of this array. The ServerUriArray shall contain the local Server.”
Basically the clients would use the ApplicationURI here as a key, so it must be unique.

P.S.
For the Transparent Redundancy the EndpointUrl requirement might not make sense sort of, but basically this is something the load balancer should magically fix maybe.
I should also note that this topic is complex and basically redundancy hasn’t been that much used yet.

P.S.2
This is somewhat in a way related, so mentioning https://forum.prosysopc.com/forum/opc-ua-java-sdk/connection-via-vpn-tunnel/ (and the next release will contain a fix that will allow mapping to different port, might be relevant for this thread as well).

Sorry, I made one mistake in the post. So, a server can have multiple endpoints, so it would be possible to “arrive” to the same server via multiple addresses, though like typically this is just e.g. using the IP address instead of the hostname and so on. Binding a second port for the same server wouldn’t exactly make sense (I have not seen this done), but e.g. from outside a NAT the port could be different.

Also, a clarification: The ApplicationURI doesn’t directly have anything to do with a connection address. In our SDK samples and our applications they sort of have related data, because it does also produce an unique ApplicationURI, but it can be any valid URI e.g. ‘urn:uuid:some_uuid_here’ and so on, as long as it is unique to the network.

From your explanation I interpret that these are basically 4 compelety separate OPC UA Servers that just happen to be hosted on the same machine? I know little of the HPE NonStop, but I am a bit a aware that it was a bit special platform, but I’m not sure does it matter here at least OPC UA Specification-wise. I’m not … 100% sure could you “stretch the spec” to intrepret these being separate endpoints each having own set of users allowed to use those endpoints and having complete custom data for the “same server”. I would not recommend trying (at least with the info I have), instead each server should have unique ApplicationURI.

I do realize that it might be sort of a pain to manage the certs in this case, but since it is theoretically possible for an application to connect to all these servers (e.g. you could have https://www.prosysopc.com/products/opc-ua-monitor/ showing each status etc.), and they are different servers, they should all have unique ApplicationURIs. If you would effectively segment the network so that it is technically impossible to connect to them from a single network, then maybe the same ApplicationURI could be used. But you might then someday wish to tunnel all these to a single aggregated point e.g. via UaGateway, and thus you would have the issue again, and it might be a pain to then change to use unique ApplicationURIs (or maybe even impossible). Plus interaction with a LDS (LocalDiscoveryServer) and/or GDS (GlobalDiscoveryServer) might be problematic. By default each Server should try to register to the LDS when they start, so they would overwrite each-others for example. Basically “many things” do key on the ApplicationURI.

It is possible that you would never use or run into the above scenario (and maybe you do not run a LDS). Or maybe I made a mistake in the assumption that it would be possible to connect to all of them (it sort of “doesn’t matter”, spec-wise, if you artificially limit this via credentials, the GetEndpoints is used without security/credentials and any client in the network could do that for example).

This is a bit complicate topic, thus the answer is the same.., what do you think about this?

P.S.
Could you explain a bit more on the multithreading limitations of the platform? Because basically this all would be so much easier if you can just run a single server and limit what each user can see. Or maybe I did misunderstand something, but what I did find quickly on the internet (https://www.hpe.com/psnow/doc/4aa6-6097enw.pdf) it should basically just support java thus I would find it odd if there would be any major issues (but maybe this is not the device you have but e.g. some older etc.).

The https://reference.opcfoundation.org/Core/Part6/v105/docs/6.2.2 for subjectAltName says “…Shall include a uniformResourceIdentifier which is equal to the applicationUri. …”. Which I would assume to mean “no”.

But this case is interesting and maybe somewhat unique, so maybe you should ask the OPC Foundation directly: https://opcfoundation.org/forum/ (maybe link this thread).

Assuming my assumption holds (at least it does for our SDK and apps), basically every existing OPC UA Client would just check here here: ‘urn:tsystem.com:OPCUA:ServerProcess*’ not equals ‘urn:tsystem.com:OPCUA:ServerProcessX’ and report an error (or require some override).