Log In
Home
05/05/2015
Offline
I am having difficulties reading the UA 1.03 specifications with respect to endpoint URLs in the context of a server application.
1. url-path handling
The scheme syntax used for "opc.tcp" uses the Common Internet Scheme Syntax and hence seems to allow for an url-path after the port specification. In fact, in Part 4, 7.4 a well known address like "opc.tcp://localhost:4840/UADiscovery" is listed for a discovery endpoint URL.
However, I am not sure how the url-path is to be interpreted (in both discovery and session endpoints). Would a server application be allowed to return a different set of endpoint descriptions in e.g. the GetEndpoints service based on (discovery) endpoint URLs that differ only in their url-path?
Also, would a CreateSession service implementation be allowed to return a service error in case the url-path is not known? If yes, what status code would be appropriate?
2. Multiple discovery URLs
I have a server application (a single process) that listens on endpoints with different host names and port numbers. E.g.
Server Application (single process) ├ opc.tcp://host1:4841 (server / discovery endpoint) │ └ Basic128 Sign (session endpoint) ├ opc.tcp://host1:4842 (server / discovery endpoint) │ └ Basic256 Sign&Encrypt (session endpoint) └ opc.tcp://localhost:5000 (server / discovery endpoint) └ None None (session endpoint)
The session endpoints all access the same underlying system and there is one ServerUri for the whole process (server application).
Is it correct to assume that according to the specifications, the ApplicationDescription returned in the FindServers call (using any of the server endpoint URLs as a discovery URL) may contain three discovery URLs, one for each server endpoint?
A client using the GetEndpoints service with a particular discovery URL would then only get the EndpointDescriptions for the session endpoints associated with the endpoint URL used to access the discovery endpoint, e.g.
GetEndpoints("opc.tcp://localhost:5000") -> "None None" (session endpoint)
I would highly appreciate any clarifying comments if my reading of the specifications is correct or if there is a more standard-conforming way of organizing such a server structure.
Thanks,
Sascha
05/12/2015
Offline
1) The path handling is up to the server. Many UA servers do not care about the path and will simply ignore it. You can develop a server that does make use of it.
2) Multiple DiscoveryUrls exist because not all Clients will support all of the protocols supported by the Server or have access to every NIC used by the Server. The expectation is FindServers/GetEndpoints must return the same information for the same Server no matter what DiscoveryUrl is used.
05/05/2015
Offline
Thanks for 1), that is clear now.
For 2) I would appreciate it if you could comment on the specific example below:
Assume a host machine with two NICs and a server application that listens on e.g. three addresses (made up)
opc.tcp://1.1.1.1:1
opc.tcp://1.1.1.1:2
opc.tcp://2.2.2.2:2
The server sockets are bound to those addresses. If a client connects to one of those addresses, would the following be expected behavior?
a) On a FindServers call, return only one DiscoveryUrl, where the host name in the DiscoveryUrl matches the host name the client used to connect to the server.
b) On a GetEndpoints call using the DiscoveryUrl returned in a), return a list of EndpointDescriptions from all three server endpoints that are accessible to the client (according to Part 4 v1.03, 5.4.4.1). So (assuming the client has no route to access 2.2.2.2)
GetEndpoints("opc.tcp://1.1.1.1:1") -> { "opc.tcp://1.1.1.1:1", "opc.tcp://1.1.1.1:2"}
but for another client who can access 2.2.2.2 but not 1.1.1.1, it would get
GetEndpoints("opc.tcp://2.2.2.2:2") -> { "opc.tcp://2.2.2.2:2" }
But this is contrary to the expectation you mentioned, that GetEndpoints should return the same list independent of the used DiscoveryUrl.
I am also confused by the possibility of returning multiple DiscoveryUrls in a call to FindServers. Is there a use case for this in the context of a regular server (no gateway, explicit LDS or GDS, etc.)?
Thank you for your help,
Sascha
05/05/2015
Offline
After reading through 5.4.4.1 (GetEndpoints service) again, in particular
A Server may have multiple HostNames. For this reason, the Client shall pass the URL it used to connect to the Endpoint to this Service. The implementation of this Service shall use this information to return responses that are accessible to the Client via the provided URL.
I am even more confused. If GetEndpoints is supposed to return the same set of endpoints independent of the DiscoveryUrl being used, how can it possible know what "responses" are accessible to the Client via the provided URL in the GetEndpoints call? Referring to the example in the previous post, who would the server know if it should include the 2.2.2.2:2 endpoint in the response to a client connecting via 1.1.1.1:1?
I think I am missing or misunderstanding something very basic here...
Thanks,
Sascha
05/12/2015
Offline
Section 5.4.4.1 does not make sense because the server cant know what the client can and cannot access (even in the case of dual NICs the client could have access to both networks in a redundancy scenario).
I had thought we had removed that text from the spec already. I will see about removing it in 1.04.
Servers should always return all endpoints/discoveryurls (unless filtered by TransportProfileUr in GetEndpoints) because these services are meant to help clients figure out how to connect to a server. If an endpoint is security sensitive then it should not have to be returned to any client and clients would have to be configured out-of-band to connect.
05/05/2015
Offline
Okay, thanks a lot for your help.
It is both Section 5.4.4.1 and the following which got me confused:
Section 5.4.2.2 FindServers and 5.4.4.2 GetEndpoints endpointUrl parameter:
The Server uses this information for diagnostics and to determine what URLs to return in the response.
What does "determine" mean in that context? Does it relate to the host-name, the url-path, or both?
1 Guest(s)
Usage Policy